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

Brian E Carpenter <> Fri, 08 October 2010 00:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8D4B3A6FDE; Thu, 7 Oct 2010 17:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.073
X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9FR0-9thBpRi; Thu, 7 Oct 2010 17:11:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8A4CB3A6B95; Thu, 7 Oct 2010 17:11:36 -0700 (PDT)
Received: by ywa6 with SMTP id 6so202099ywa.31 for <multiple recipients>; Thu, 07 Oct 2010 17:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DMMrDK34W7VxCBQsXCncMCT6YRStmGYeEwpa5vgVOW0=; b=ZpbA858mJEZLm7Zi1R4/H1xRu8L7zEXF0BQenMgzpJYOE79M1d2kC27ttcn07vIp5F DKcPGsLHT9F5v7t3qVLZ+K+e6Ix+iIeD/sJ0EfhBZrhBnT3w9XfyAzVG7NBJrvtPFEt4 kC3O2D0bgdxjII7+HRSxvZKreeCCKR41THzPk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=SYgHxwU9YEscOPE8oilbPI63CRnj5B9EBqcp8KxQMTny9Q3xXef7fj9guMA2WLfO8x ccCwligg+Bu2zelg/h+jflUSyvSnFKgyDrwQ6f4Of/sjLNhxiDLEDIesgpv4qmPrZlK7 Ld3s2IDvJOvjoFDgVz/OI2VLgsfiw8NJ866v8=
Received: by with SMTP id q38mr3396716yhg.9.1286496759543; Thu, 07 Oct 2010 17:12:39 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id t53sm1465753yhf.23.2010. (version=SSLv3 cipher=RC4-MD5); Thu, 07 Oct 2010 17:12:39 -0700 (PDT)
Message-ID: <>
Date: Fri, 08 Oct 2010 13:12:29 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Olivier Vautrin <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Fri, 08 Oct 2010 00:11:40 -0000


Rémi has mainly answered you. In particular, the operational problems
caused by missing Teredo servers don't just harm the customers of
the ISP concerned; like missing 6to4 relays, they also harm customers
of *other* ISPs. 6a44 doesn't have this problem.

> I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed.

I believe that a separate draft on "operational problems with Teredo"
would be useful (in v6ops, most likely). Personally, I'd rather keep
the 6a44 draft more focussed.


On 2010-10-07 16:21, Olivier Vautrin wrote:
> Hi all, very interesting draft.
> I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed.
> In this draft, I see 2 issues described for Teredo:
> 1) "clients sometimes believing that they have Teredo connectivity when in fact they don't"
> Clients could have the same issue in 6a44 AFAIK. There is no mechanism in 6a44 to check the data path connectivity. I think the real issue here is lack of reliable teredo relay or lack of reliable data path (MTU issues).
> 2) "Teredo server and relay being very remote"
> Both issues can be fixed if ISPs deploy their own Teredo server/relay. Which is basically what they will do with 6a44. So, I don't really see the issues described in the paper as important enough to create another protocol.
> I do think there are other issues with Teredo:
> 1) Use of a WK prefix instead of an ISP prefix. This means the return path can be broken as with 6to4.
> 2) Most client Teredo implementation need a full cone NAT on the CPE. Most CPE use symmetric NAT. so a CPE upgrade could be needed.
> 3) Most OS still prefer IPv4 over Teredo. This means it does not increase the Ipv6 traffic.
> 4) On vista, it seems that traffic is sent to a Teredo tunnel only if another Ipv6@ is created (I didn't check this though). Source:
> /Olivier
>> -----Original Message-----
>> From: [] On
>> Behalf Of Brian E Carpenter
>> Sent: Tuesday, October 05, 2010 9:51 PM
>> To: Softwires
>> Cc:
>> Subject: Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs -
>> Proposed 6a44 Specification
>> On 2010-10-05 22:26, Rémi Després wrote:
>>> Hi all,
>>> Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has
>> just been posted (
>> 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).
>>     Brian
>> _______________________________________________
>> Softwires mailing list