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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 06 October 2010 23:21 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9B03A6B95; Wed, 6 Oct 2010 16:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level:
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VeIcrymPHXQ; Wed, 6 Oct 2010 16:21:06 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 0DEE93A6CAB; Wed, 6 Oct 2010 16:21:05 -0700 (PDT)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o96NLsZk018432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Oct 2010 16:21:54 -0700 (PDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o96NLrx1013686; Wed, 6 Oct 2010 16:21:53 -0700 (PDT)
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o96NLros013683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 6 Oct 2010 16:21:53 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Wed, 6 Oct 2010 16:21:53 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>
Date: Wed, 6 Oct 2010 16:21:51 -0700
Thread-Topic: [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Thread-Index: ActlqdIGu1dYQTloSA6e+ZVmJnpudwAAPoSQ
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C59B78DA4@XCH-NW-01V.nw.nos.boeing.com>
References: <31672657-0CCB-4C2B-B44A-AEE73B588960@free.fr><4CAB8F97.90501@gm ail.com><B8BAD5B0-9C9B-475E-BF53-7DF76ABF5213@employees.org> <4CACF3D3.8060006@gmail.com>
In-Reply-To: <4CACF3D3.8060006@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires <softwires@ietf.org>, "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
Subject: Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2010 23:21:07 -0000

Hi Brian, 

> -----Original Message-----
> From: softwires-bounces@ietf.org 
> [mailto:softwires-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Wednesday, October 06, 2010 3:10 PM
> To: Ole Troan
> Cc: Softwires; v4tov6transition@ietf.org
> 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
fred.l.templin@boeing.com

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