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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 08 October 2010 00:11 UTC

Return-Path: <brian.e.carpenter@gmail.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 E8D4B3A6FDE; Thu, 7 Oct 2010 17:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.073
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FR0-9thBpRi; Thu, 7 Oct 2010 17:11:36 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (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; d=gmail.com; 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; d=gmail.com; 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 10.236.108.178 with SMTP id q38mr3396716yhg.9.1286496759543; Thu, 07 Oct 2010 17:12:39 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id t53sm1465753yhf.23.2010.10.07.17.12.36 (version=SSLv3 cipher=RC4-MD5); Thu, 07 Oct 2010 17:12:39 -0700 (PDT)
Message-ID: <4CAE61ED.9030400@gmail.com>
Date: Fri, 08 Oct 2010 13:12:29 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Olivier Vautrin <ovautrin@juniper.net>
References: <31672657-0CCB-4C2B-B44A-AEE73B588960@free.fr> <4CAB8F97.90501@gmail.com> <84600D05C20FF943918238042D7670FD37326C5FF3@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD37326C5FF3@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Fri, 08 Oct 2010 00:11:40 -0000

Olivier,

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.

Regards
   Brian

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: http://yorickdowne.wordpress.com/2008/01/26/ipv6-at-home-part-1-overview-teredo/
> 
> /Olivier
> 
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On
>> Behalf Of Brian E Carpenter
>> Sent: Tuesday, October 05, 2010 9:51 PM
>> To: Softwires
>> Cc: v4tov6transition@ietf.org
>> 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 (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).
>>
>>     Brian
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires