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

Rémi Després <remi.despres@free.fr> Fri, 08 October 2010 07:43 UTC

Return-Path: <remi.despres@free.fr>
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 344973A6828; Fri, 8 Oct 2010 00:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.453
X-Spam-Level:
X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 rByCXPtKOhD7; Fri, 8 Oct 2010 00:42:58 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id 227443A67A3; Fri, 8 Oct 2010 00:42:58 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id BE5D77000089; Fri, 8 Oct 2010 09:44:01 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id 249917000097; Fri, 8 Oct 2010 09:43:55 +0200 (CEST)
X-SFR-UUID: 20101008074359150.249917000097@msfrf2104.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <90B266CA-8D13-4F4C-8FED-273F07A3F7CE@employees.org>
Date: Fri, 08 Oct 2010 09:43:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A58E71DE-93E6-4886-BE2B-E57244927AA0@free.fr>
References: <C8D29306.3EDBD%yiu_lee@cable.comcast.com> <FC864BDE-D5C7-4EEF-AE66-18AF523CDB67@free.fr> <8F8FE644-4E46-4579-8D77-9C5613F6419E@employees.org> <0BEE26F5-AB86-407C-98B2-FACADF2BBC95@free.fr> <90B266CA-8D13-4F4C-8FED-273F07A3F7CE@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <softwires@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 07:43:00 -0000

Le 7 oct. 2010 à 21:28, Ole Troan a écrit :
> ...
> issues I have with host tunneling:
> - how to communicate with native IPv6 nodes on the same network?

The 6a44-S decapsulates IPv6 packets coming from a 6a44 host and, if not destined to another 6a44 host of its network, forwards them in IPv6, in this case on the same network.

   
> - how to communicate to another 6a44 host on a different link in the same home?

6a44 is only for hosts on a LAN behind a NAT44 attached to a 6a44-capable ISP network.
If the LAN has several bridged links, it does apply.
Links that are behind extra NATs in the site are out of scope.

As I said to Olivier Vautrin in a previous mail on this thread, these extra NATs should be configured so that hosts behind them never receive 6a44 IPv6-Address-Indication messages. (e;g. with the 6a44 well-known port bound to an unassigned internal address.
This point isn't in the draft yet but, if co-authors agree, should be in the next version.


> - do you need non-congruent topology multi-homing policy?
>   http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01
>   how do you distribute that policy when you don't have a on-link router?

Not sure to understand the question.
The answer should be NO: 6a44 only needs classical topologies.


> - a general unease that now every host is supposed to have a "VPN" connection?
>   how do I configure my own firewall and other network border policy?

If the NAT binds the 6a44 well-known port to an unassigned internal address, no host will be able to receive a 6a44 IPv6 address. 
Besides, a firewall could filter all packets having this port, source or destination.

> how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.)
> I really liked the dongle idea by the way. perhaps with a L2TP LAC.

The dongle idea of 6rd-UDP, if without a stateful NAT66 in the dongle, needs an assigned /16 to the function. (The /64 subnet prefix has to contain the site IPv4 address plus the port of the tunnel).
This is in general not realistic.

Now, if there is a NAT66 in the dongle, it can work with a 6a44 external address.


I hope it helps to understand that 6a44 isn't just one more design for the pleasure to make one, but a pragmatic solution to a real problem, specified after an in depth study. 

Cheers,
RD

> 
> cheers,
> Ole