Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification

["Templin, Fred L" <[e-mail]>]

Hi Brian, 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, October 06, 2010 3:10 PM
> To: Ole Troan
> Cc: Softwires; [e-mail]
> Subject: Re: [Softwires] ISP support of Native IPv6 across 
> NAT44 CPEs -Proposed 6a44 Specification
> 
> On 2010-10-06 19:57, Ole Troan wrote:
> > Brian,
> > 
> >>> Draft-despres-softwire-6a44-00, coauthored with Brian and 
> Sheng, has just been posted 
> (http://tools.ietf.org/html/draft-despres-softwire-6a44-00).
> >>> It describes a solution for ISPs to offer native IPv6 
> across IPv4-only CPEs (NAT44 CPEs).
> >>>
> >>> It results from convergence discussion between authors of 
> draft-carpenter-6man-sample-00 and 
> draft-despres-softwire-6rdplus-00, taking into account 
> comments made by authors of draft-lee-softwire-6rd-udp-01, 
> and those made other Softwire WG participants since IETF 78.
> >>>
> >>> It is submitted to become, after discussion in the WG, a 
> Softwire I-D.
> >> By the way, we do discuss in the draft why it's a useful 
> alternative to
> >> both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't
> >> explicitly discuss why we think it's also a useful 
> alternative to an L2TP
> >> solution, but the arguments are, I think, similar to those 
> for the tunnel
> >> brokers (apart from our "hobbyist" comment).
> > 
> > perhaps you could also add some deployment considerations 
> with regards to host tunneling versus "network" tunneling?
> 
> OK, if there is enough interest to continue this work. Of 
> course, in the
> context of legacy CPE, there is no alternative to host tunnels.

I agree that the tunnel endpoint device in the end user
network needs to configure the 6a44 tunnel interface as a
host interface, but if the device also configures another
tunnel over *that* then the inner tunnel could be used as
a router interface.

If you can bear with me for a moment (*), consider the 6a44
tunnel as an underlying interface over which the tunnel
endpoint device configures an IRON tunnel. Yes, that would
make for nested encapsulations - in particular, the nesting
would be IPv6-in-IPv6-in-UDP-in-IPv4. But, the inner tunnel
could be used as a router interface to service a PI IPv6
prefix. This would work even if the inner tunnel was
configured over multiple underlying 6a44 tunnels - one
each for each ISP the end user network connects to.

(*) Of course, the sticking point once again is the pesky
tunnel MTU issue. 6a44 appears to be punting on MTU yet
again and setting a static 1280 MTU. That means that there
is not enough available MTU to configure another tunnel
over the 6a44 tunnel without fragmentation. If 6a44 is
already implementing a control message protocol as per
the I-D, however, it could also add a 6a44 "Packet Too
Big" control message and use the IRON/SEAL method for
reporting fragmentation as a means for supporting path
MTU discovery. If you'd like a more detailed discussion
of this idea, let me know.

Thanks - Fred
[e-mail]

> (Except for the idea in draft-lee-softwire-6rd-udp of a tiny
> relay plugged into the customer LAN.)
> 
>      Brian
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>