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

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

Hi Yiu, 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Yiu L. Lee
> Sent: Wednesday, October 06, 2010 5:57 PM
> To: Templin, Fred L; Brian E Carpenter; Ole Troan
> Cc: Softwires; [e-mail]
> Subject: Re: [v4tov6transition] [Softwires] ISP support of 
> Native IPv6across NAT44 CPEs -Proposed 6a44 Specification
> 
> Hi Fred,
> 
> This is an interesting idea, but I will argue this is as 
> complex as L2TP
> softwire. When Brian, Remi and I discussed, we would like to 
> have a simple
> and cost effective technology that could be deployed by SP 
> w/o upgrading the
> CPE. This double tunneling tech seems scary.

I used the double tunneling example as something that
could be done and not necessarily something that should
be done - it is not at all a requirement of IRON, and
would not be as efficient as deploying IRON alone without
also deploying 6a44 or the like. But, it might be worth
noting that the hard-coded 1280 MTU precludes configuring
other tunnels over 6a44 tunnels.

AFAICT, if the ISPs want to let their customers set up
native IPv6 networks behind unmodified IPv4 NATs the
two choices are to 1) do nothing, and let outside
agencies deploy the IRON service, or 2) deploy the IRON
service themselves.

This gets back to a point that needs to be bumped up a
level in visibility. Some of these proposed approaches
are strictly provider-aggregated, which may be good for
the ISPs but maybe not so optimal for the customers. IRON
provides the customers with a provider-independent routing
and addressing service that can be carried over any ISP(s)
the customers happens to procure their basic connectivity
services from.

About complexity comparisons, based on my limited knowledge
of L2TP the IRON architectural principles don't have a
parallel in the L2TP model. But, when it comes to control
and data plane messaging, I can say with some confidence
based on the code I am writing that IRON is much simpler.

Thanks - Fred
[e-mail]
 

> Thanks,
> Yiu
> 
> 
> On 10/6/10 7:21 PM, "Templin, Fred L" 
> <[e-mail]> wrote:
> 
> > 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
> >> 
> > _______________________________________________
> > Softwires mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/softwires
> 
> _______________________________________________
> v4tov6transition mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v4tov6transition
>