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

Ole Troan <otroan@employees.org> Fri, 08 October 2010 08:07 UTC

Return-Path: <ichiroumakino@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 F124E3A6846; Fri, 8 Oct 2010 01:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.423
X-Spam-Level:
X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, 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 YLXrR2XrfJxS; Fri, 8 Oct 2010 01:07:25 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1FECE3A67A6; Fri, 8 Oct 2010 01:07:24 -0700 (PDT)
Received: by ewy21 with SMTP id 21so471846ewy.31 for <multiple recipients>; Fri, 08 Oct 2010 01:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=IjSaFvk9e03Js6CHreT0bPVCCLgff0hxXhH5CIblBT0=; b=GZjNyCnbipLdqmQYRdXc7vTNh/Il1gO64lNqyWvqxRZ6xy8EQKd15/Ghx9pFttdjbX /hWaqanWzXP1mL1mnNs/vdJGhsbFzYZJDUPiFdHydTq1SDVtZiAt/twaS+4DgnISjPmq W9tI1P3aTVWfheXDhBImzBtnqk0TA8g/S3ihA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ZAhuLh1Poiq3WJEHfOJ/iDW0jPC7oukFnZjFp1JZ07hDclaV3sz7lTfvU9XhxxtdtF 3R/AfE/dKl0X6A0GIosqiUqbDFfXQzOstXNd6fMmEhn9wBiJppOX086XrOufChr42hSg PdQT4ogCJB6gM47OWqnjuCAri+s/6XcxnlA9Q=
Received: by 10.213.34.79 with SMTP id k15mr1164680ebd.26.1286525308374; Fri, 08 Oct 2010 01:08:28 -0700 (PDT)
Received: from ams3-vpn-dhcp4939.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id u3sm1088761eeh.7.2010.10.08.01.08.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 Oct 2010 01:08:27 -0700 (PDT)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <otroan@employees.org>
In-Reply-To: <A58E71DE-93E6-4886-BE2B-E57244927AA0@free.fr>
Date: Fri, 08 Oct 2010 10:08:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <39C9D597-9C35-4A3F-88C9-84214DCC6620@employees.org>
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> <A58E71DE-93E6-4886-BE2B-E57244927AA0@free.fr>
To: Rémi Després <remi.despres@free.fr>
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 08:07:27 -0000

Remi,

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

I was thinking of another native IPv6 node in the same home. as 6a44 doesn't enable IPv6 support in the home network I don't see how this would work.

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

I was thinking of the case of a routed home. no additional NATS. I don't see how the mechanism would work across routers. since you don't get a prefix for the site. the homegate/homenet WG proposal was rejected by the IESG, but it would have been useful to have the home network architecture document as background for this discussion...

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

if a 6a44 node is multi-homed to 3 networks, the 6a44 network the IPV4 network and possibly a native IPv6 network (e.g. ULA in the home), would you need to distribute SAS/NH/DNS policy?

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

that doesn't give me ability to filter on IPv6 applications on the network border... not specific to 6a44, this is just an artifact of host tunneling.

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

my suggestion is to use L2TP, which has none of those particular shortcomings.

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

is the in-depth study available?

cheers,
Ole