draft-despres-v6ops-6rd-ipv6-rapid-deployment

[james woodyatt <jhw@apple.com>]

everyone--

I suppose I should offer comments on this draft, too, since it  
envisions things happening in residential gateway CPE that do not  
currently happen today.
It seems to me that 2002::/16, the 6to4 prefix, can be regarded as a  
special case of 6rd ISP prefix allocated by IANA and unassigned to any  
particular organization.  What 6RD does is allow each ISP to define  
their own 6to4-like routing domain, provided that CPE functions are  
properly loaded with the 6rd ISP prefix to use as distinguished from  
the 2002::/16 prefix assigned by IANA.
The draft defines a new DHCPv4 option used by 6RD ISP to configure 6RD- 
enabled CPE, i.e. hosts or dual-stack IPv4/IPv6 routers with 6RD- 
tunneling functions.  I very much doubt that getting vendors of  
consumer retail CPE, e.g. host operating systems, consumer routers,  
etc., to adopt this DHCP client feature will be easy.  For that  
reason, I don't expect 6RD to be deployable except with provider- 
provisioned CPE.
Finally, the section where it's noted that RFC 1918 addresses can be  
used to construct 6RD site addresses is interesting, but it implies  
that those ISP's which are large enough to provide service to more  
IPv4 endpoints than will fit inside the RFC 1918 portion of the  
addressing realm will need to use more than one 6RD ISP prefix to  
disambiguate the realms.  Does this conflict with the statement on  
page 6, "For this, a simple approach consists in each 6rd ISP to chose  
one and only one of its IPv6 unicast prefixes as the '6rd ISP prefix'  
which appears at the start of 6rd site addresses addresses, and to  
have this prefix known by 6rd CPEs."  It seems to me that such ISP's  
will be required to operate more than one 6RD relay and ensure that  
interior routes are plumbed properly for traffic to flow between  
them.  To do this, it seems that such ISP's will need more than one  
RIR-allocated prefix.  Is that a problem?
Also, multicast?


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering