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

From: james woodyatt <[email-masked]>
Date: Tue, 11 Mar 2008 14:44:35 -0400

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 <[email-masked]>
member of technical staff, communications engineering

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Mar 2008 21:36:29 +0200 (EET)

On Tue, 11 Mar 2008, james woodyatt wrote:
> 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.

Agreed about deployment caveats and that part of 6rd being a trivial 
extension of 6to4 concept.  That'll no longer be the case if you don't 
embed the complete v4 address in IPv6 prefix.

I'd be opposed to specifying a mechanism which would require an ISP to 
use a whole /32 prefix for this because that would screw up existing 
allocations and would deter ISPs from applying this mechanism.

One major point to consider in this context is whether you want the 
hosts/routers to be able to communicate directly with each other (in 
which case they also need to know how to calculate the IPv4 address if 
the full IPv4 address is not provided in the IPv6 prefix) or whether 
it's sufficient to just tunnel everything to the ISP's IPv6 
aggregation boxes.

The former is more difficult to generalize but provides better p2p 
traffic optimization.

The latter approach and specifically how you could do a partial map 
map from subset of v4 to v6 was described in 2003-2004 around Section 
5.3 of: http://tools.ietf.org/html/draft-savola-v6ops-conftun-setup-02 
This also supports multicast without a problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: james woodyatt <[email-masked]>
Date: Tue, 11 Mar 2008 16:07:43 -0400

> The former is more difficult to generalize but provides better p2p  

Some would say that it provides *worse* P2P traffic optimization, i.e.  
it makes it more difficult for vertically integrated service providers  
to keep P2P traffic from consuming valuable network resources better  
used for value-added, intermediated communications.

Pardon me, please-- I'm not sure I see where optimizing IPv6  
operations for P2P traffic is a goal of this working group.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Mar 2008 16:17:38 +1300

On 2008-03-12 07:44, james woodyatt wrote:
...
> 6RD-tunneling functions.  I very much doubt that getting vendors of
> 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.

And that is unfortunate, because it will lock customers into
a /64 world until the ISP moves on from 6RD to a real IPv6
deployment, which as just noted on another thread, is a
problem in itself. I sympathise with the goal of rapid deployment,
of course, as long as it doesn't become a dead end.

    Brian

---

From: Joe Abley <[email-masked]>
Date: Thu, 13 Mar 2008 18:59:55 -0400

> operations for P2P traffic is a goal of this working group.

It could be argued that *all* traffic is p2p traffic, at a fundamental  
level (a host is a host/from coast to coast/...).

Joe