Subject: Re: Residential ISPs & IPv6 NAT

From: Brandon Butterworth <[email-masked]>
Date: Tue, 25 Mar 2014 08:44:25 GMT

> > I agree with this as well, ISPs should delegate shorter that /64 
> > prefixes to their customers, especially when requested to do so by the 
> > customer, a customer SHOULD NOT have to do anything more than ask for a 
> > prefix at least as short as /60.  I prefer /56 or /48, but at least /60.
> > 
> While not ideal, another option for customers who are stuck in this
> situation would be to get much larger amounts of IPv6 address space
> from an IPv6-over-IPv6 pr IPv6-over-IPv4 tunnel service provider

They could but the ISP not giving enough space is more likely to
tell them to NAT than to tell them about such a service. If
they are that intent on not supplying space they would probably
supply CPE with NAT on by default.

> It'd be an unfortunate tax to pay to have to get around a stuck
> in IPv4-think ISP

I do not know of a valid reason to not supply sufficient space so I
will assume those ISPs are staffed by muppets in which case the only
way you can influence this is to make it impossible to do stupid things

brandon

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 26 Mar 2014 00:23:40 -0700 (PDT)

----- Original Message -----
> From: Brandon Butterworth <[email-masked]>
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: 
> Sent: Tuesday, 25 March 2014 7:44 PM
> Subject: Re: Residential ISPs & IPv6 NAT
> 
> tell them to NAT than to tell them about such a service.
>
> If

> supply CPE with NAT on by default.

If you know your ISP is being stingy with IPv6 address space, and you have no alternative but to use them, I'm sure you'll treat any of their advice on how to solve the problem with the contempt it deserves.

> way you can influence this is to make it impossible to do stupid things

The only way to prevent these sorts of stupid things is to prevent any choice or options, which comes at the cost of flexibility. Less choice is a good thing, as it reduces stupidity or accidental misconfiguration, but sometimes we need flexibility to mitigate future risks and their costs and consequences (e.g., avoid repeating the sorts of costs incurred when going from Classful to Classless in the mid-1990s).

Regards,
Mark.