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

Olivier Vautrin <> Thu, 07 October 2010 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3850F3A6D53; Wed, 6 Oct 2010 20:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.506
X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sbL8Uj85QnxZ; Wed, 6 Oct 2010 20:21:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD0973A6C43; Wed, 6 Oct 2010 20:21:34 -0700 (PDT)
Received: from source ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 06 Oct 2010 20:22:36 PDT
Received: from ([fe80::c821:7c81:f21f:8bc7]) by ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 6 Oct 2010 20:21:06 -0700
From: Olivier Vautrin <>
To: Brian E Carpenter <>, Softwires <>
Date: Wed, 6 Oct 2010 20:21:02 -0700
Thread-Topic: [Softwires] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification
Thread-Index: Actkzvxqwpwxgg7tQnu5mZEaWIjmeAA/KUMQ
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 07 Oct 2010 18:34:08 -0700
Cc: "" <>
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: Thu, 07 Oct 2010 03:21:36 -0000

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:


> -----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