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

"Templin, Fred L" <> Wed, 06 October 2010 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F9B03A6B95; Wed, 6 Oct 2010 16:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1VeIcrymPHXQ; Wed, 6 Oct 2010 16:21:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0DEE93A6CAB; Wed, 6 Oct 2010 16:21:05 -0700 (PDT)
Received: from ( []) by (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 (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o96NLrx1013686; Wed, 6 Oct 2010 16:21:53 -0700 (PDT)
Received: from ( []) by (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 ([]) by ([]) with mapi; Wed, 6 Oct 2010 16:21:53 -0700
From: "Templin, Fred L" <>
To: Brian E Carpenter <>, Ole Troan <>
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: <>
References: <><4CAB8F97.90501@gm><> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires <>, "" <>
Subject: Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Oct 2010 23:21:07 -0000

Hi Brian, 

> -----Original Message-----
> From: 
> [] On Behalf Of Brian E Carpenter
> Sent: Wednesday, October 06, 2010 3:10 PM
> To: Ole Troan
> Cc: Softwires;
> 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 
> (
> >>> 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

> (Except for the idea in draft-lee-softwire-6rd-udp of a tiny
> relay plugged into the customer LAN.)
>      Brian
> _______________________________________________
> Softwires mailing list