Re: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach

[Rémi Després <remi.despres@free.fr>]

Rémi Denis-Courmont wrote :
> Lets clear: /64 subnet at the CPE plain simply SUCKS. Badly.
WOW!
Please note that many users now have real IPv6, without any NAT 
traversal tricks, thanks to the proposed new technique, and thanks to 
its first deployment by Free (which for some practical reasons was 
initially limited  to /64 prefixes).
On my home LAN, it doesn't suck at all. It just works to my complete 
satisfaction.
Clearly it is desirable to do much better than this /64 first step, but 
one step after another is sometimes a good way to progress.

In view of your strong reaction though, the following sentence will have 
IMO to be rewritten:
"This is expected to be satisfactory initially for the vast majority of 
residential sites, where the number of hosts is small."

> Next thing is IPv6 NAT, when people try to "cascade" access points/routers 
> within their home network.
You are free to believe that IPv6 to IPv6 NATs would be the proposed 
next step.
But not by me, for sure.

> Like it or not, CPEs MUST get more than /64, and 
> MUST support downstream prefix delegation.
Where did you get that I might not like shorter than /64 prefixes !!!.

I wrote myself that /64 "is a real restriction which would 
advantageously be avoided with RIRs cooperation" (sec. 3,2).

Free has already obtained a shorter than /32 prefix, just to have 
multiple subnet customer sites.

> Last time I checked, Free was not assigned the whole IPv4 address space. I 
> assume they don't want to provide the Rapid Deployment service to customers 
> of *other* ISPs. So while they do only have a /32 IPv6 prefix, they don't 
> need to burn 32 further bits to keep track of each of the IPv4 address of 
> each of their customers. Storing the 24 lower order bits should be 
> sufficient. And this leaves 64-32-24=8 rouable bits per customer.

You are right, they could have done that.
But IMO the additional complexity would not have been justified, 
especially since it was expected to be only provisional.
It would also have made addresses less readable.

Section 3.2 says:
"In view of the potential of 6rd to facilitate IPv6 availability, RIRs 
could be advised to consider assigning /24 prefixes to ISPs that
deploy 6rd, and to endorse that these ISPs make their first IPv6 
deployments with /56s distributed to their customers."

May be more flexibility on this point would be appropriate, in 
particular by relaxing the restriction that 6rd ISP prefixes are 
multiple of 8 bits.


Rémi