Return-Path: X-Original-To: softwires-archive@megatron.ietf.org Delivered-To: ietfarch-softwires-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FFB3A6A4C; Fri, 7 Nov 2008 06:17:02 -0800 (PST) X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8E43A690A; Fri, 7 Nov 2008 06:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, J_CHICKENPOX_13=0.6, 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 q4vIAdH1VRh4; Fri, 7 Nov 2008 06:16:59 -0800 (PST) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by core3.amsl.com (Postfix) with ESMTP id 79C543A67A1; Fri, 7 Nov 2008 06:16:59 -0800 (PST) Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id AF4E61979A; Fri, 7 Nov 2008 15:16:27 +0100 (CET) Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g19.free.fr (Postfix) with ESMTP id C13BC19708; Fri, 7 Nov 2008 15:16:20 +0100 (CET) Message-ID: <49144D53.4010706@free.fr> Date: Fri, 07 Nov 2008 15:14:43 +0100 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Dave Thaler References: <4911CDAB.2010309@free.fr> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040904060804040701040808" Cc: Softwires WG , "v4v6interim-bounces@ietf.org" , Behave WG Subject: Re: [Softwires] [BEHAVE] Stateless Address Mappings (SAMs) - new draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: softwires-bounces@ietf.org Errors-To: softwires-bounces@ietf.org This is a multi-part message in MIME format. --------------040904060804040701040808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave,

Thanks for your detailed comments, and for the useful pointers to relevant RFCs and I-Ds.

More comments below.

Regards,

RD

Dave Thaler (1-12/1-31/200x) 11/5/08 9:47 PM:

I have read this draft.  In my opinion, it is within the scope of Softwires
but may be of interest to some Behave folks.  The only real part I can see
that might be within the scope of Behave is section 3.6 where it discusses
scrambling IPv6 addresses as packets flow through a SAM.

Yes, section 3.6 is clearly in the scope of Behave.

IMU, this is also the case for section 3.2.3 on the port-prefix based extended IPv4 addresses: it concerns "Division of port space to share one IPv4 addresses among multiple endpoints at the same time", which Magnus Westerlund announced to be in Behave's scope (e-mail attached).

  I'd suggest this
be separated into its own draft since it's largely orthogonal to the rest
of the document (which is more about encapsulation, not translation).

As this has strong relationship with Margaret's NAT66 draft, trying to regroup the contents could IMHO make sense, but to be discussed more.

Technical comments:

1) The draft doesn't say what will break and probably should (ping,
   well-known ports, etc).  Some of the same problems that occur with
   multilink subnets (RFC 4903) occur in this proposal too, since
   not everything will be aware that the "subnet" isn't an IP prefix.
   Similarly, the required Subnet-Router Anycast addresses (RFC
   4291 section 2.6.1) may not work correctly.

- With extended IPv4 addresses, pings are indeed impossible (like across NATs or any address sharing mechanism).
- I agree that a sentence on it is appropriate (I even had one at some stage, but lost it later on.)

- Whether a problem related to multilink subnets does appear with the proposal is still unclear to me.
- It seems unnecessary that "everything" be aware that a subnet IT is longer than 64 to keep the rule of only one link per subnet. Note that in 3.2.3 the mentioned prefix is that of a "subnetwork", not that of a "subnet" as defined for IPv6. Instead of "subnetwork", "local routing domain" should be better .

2) The draft assumes that the first fragment always arrives first.
   As discussed in draft-iab-ip-model-evolution-01.txt section 3.1.7,
   this is not a safe assumption today.

- I tried not to assume completely that it was that way, but I agree that the point should be developped.
- Would you have details on a real case where a provider routinely disorders packets having same source and same destination (the only case of concern here). IMU, this would be _very bad_ for many TCP implementations.

3) The use of the "u" bit in IIDs seems problematic for several reasons.
   One, it only applies to IPv6 addresses that don't start with binary 000.

Right, the next version should clarify that what is said about the "u" bit only applies to addresses that don't start with 000.

   Two, the semantics of the bit defined in RFC 4291 have to do with
   making it easy to configure non-conflicting addresses, and are not
   about privacy demands; overloading this bit for a second purpose
   seems problematic.

Right. Saying it as I did in section 3.6 is a bug. Thanks for seeing it.

Actually, the SAM privacy protection should rather be applicable only to v6E addresses. The level of privacy achieved with the SAA privacy extension of RFC 4941 would then stands for itself in global addresses.

4) Regarding the IPv6 address scrambling in section 3.6, not defining
   the scrambling (or at least not providing requirements for it) would be
   problematic in two regards.  1) If you allow asymmetric paths then
   you need the same algorithm in each SAM at the edge of your network;
   2) some implementations may pick a weak method that allows an
   outsider to guess the algorithm.

Yes, all external edge SAMs must obviously have the same scrambling method.
At least for this reason, standardizing a default scrambling is useful, I agree (coexistence of edge SAMs from different suppliers etc.)

It remains that vendors may propose, as options, whatever scrambling method they feel may be better .

Comments inline (along with a bunch of editorial nits) in PDF attached.

-Dave

-----Original Message-----
From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf Of Rémi Després
Sent: Wednesday, November 05, 2008 8:46 AM
To: Softwires WG; Behave WG
Cc: v4v6interim-bounces@ietf.org
Subject: [BEHAVE] Stateless Address Mappings (SAMs) - new draft

The new draft on SAMs is at
http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt.

It deal with global connectivity, in IPv4, IPv6,  and extended IPv4,
across local domains where routing is different.

- Its automatic tunneling aspects are in the new scope of Softwires
- Its IPv4 address extension aspects, based on dynamic-port prefixes,
are in the scope of Behave.

Regards
RD

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

--------------040904060804040701040808 Content-Type: message/rfc822; name="[v4v6interim] Status of IPv4-IPv6 Coexistence Work.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[v4v6interim] Status of IPv4-IPv6 Coexistence Work.eml" X-Account-Key: account3 X-Mozilla-Keys: $label1 Return-Path: Delivered-To: online.fr-remi.despres@free.fr Received: (qmail 13534 invoked from network); 27 Oct 2008 12:54:50 -0000 Received: from 64.170.98.32 (HELO mail.ietf.org) (64.170.98.32) by mrelay1-g25.free.fr with SMTP; 27 Oct 2008 12:54:50 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3B33A6A98; Mon, 27 Oct 2008 05:54:46 -0700 (PDT) X-Original-To: v4v6interim@core3.amsl.com Delivered-To: v4v6interim@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43083A6A8F; Mon, 27 Oct 2008 05:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.035 X-Spam-Level: X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_40=-0.185, HELO_EQ_SE=0.35, J_BACKHAIR_44=1, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 jVgPznI5YHxY; Mon, 27 Oct 2008 05:54:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A8CAA3A680D; Mon, 27 Oct 2008 05:54:40 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 23171206D0; Mon, 27 Oct 2008 13:54:39 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-77-4905ba0e6c39 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F04E720242; Mon, 27 Oct 2008 13:54:38 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 13:54:38 +0100 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 13:54:37 +0100 Message-ID: <4905BA0E.7000502@ericsson.com> Date: Mon, 27 Oct 2008 13:54:38 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Behave WG , 46Translation <46translation@employees.org>, v4v6interim@ietf.org, IETF V6OPS WG , softwires@ietf.org, Internet Area , TSV Area X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 27 Oct 2008 12:54:37.0889 (UTC) FILETIME=[2B5ECB10:01C93833] X-Brightmail-Tracker: AAAAAA== Subject: [v4v6interim] Status of IPv4-IPv6 Coexistence Work X-BeenThere: v4v6interim@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: v4v6interim-bounces@ietf.org Errors-To: v4v6interim-bounces@ietf.org IETF Community, There has been a lot of activity on the topic of improving IPv4 and IPv6 coexistence, deployment of IPv6, and coping with the increasing shortage of unassigned IPv4 addresses. This work crosses a number of layer and area boundaries, which has led to new lists, cross-posting, etc. In order to limit confusion, we'd like to give some guidance on where to discuss what on which lists. The intent is not to declare any work as in or out of charter with this message, only to try and direct list discussion. These are only general guidelines, so please don't be alarmed if we missed something in particular. Our hope is that this will help everyone to continue the rich dialog on this important topic. 1. softwires@ietf.org Softwires is chartered to work on combinations of IPv4/IPv6 and IPv6/IPv4, including "dual-stack lite" functionality. This includes discussion related to: - All types of IPv4/IPv6 tunnels, including encapsulation, control plane, etc. - Affects of tunnel endpoints terminating into a concentrator performing IPv4 to IPv4 NAT - Discovery of tunnel endpoints - Tunnels initiated by hosts or gateways - Tunnels automatically setup by routing and special prefixes Thus, if it involves a tunnel or encapsulation of IPvX over IPvY, softwires is the place to go. 2. behave@ietf.org The Behave WG is currently being rechartered. If the new charter is approved, behave will work on various types of IPv4<->IPv6 translation. Please direct all discussion related to: - IPv4 to IPv6 and IPv6 to IPv4 translation - IPv6 to IPv6 NAT - Division of port space to share one IPv4 addresses among multiple endpoints at the same time - Affects on applications and transport protocols - ALGs - IPv4 to IPv4 NAT functionality, including for ISP deployments Thus, if discussion involves an IP translator or the internal function of a NAT, behave is the place to go. 3. v6ops@ietf.org - Operational discussions on the topic of coexistence in general - IPv6-only deployment Thus, if it involves operational issues of IPv6 or IPv4 exhaustion, go to v6ops. 4. The v4v6interim@ietf.org list will be removed after the Minneapolis IETF meeting. Jari Arkko Ron Bonica Lars Eggert Mark Townsley Magnus Westerlund Resources: WGs Behave: http://www.ietf.org/html.charters/behave-charter.html Softwire: http://www.ietf.org/html.charters/softwire-charter.html v6ops: http://www.ietf.org/html.charters/v6ops-charter.html _______________________________________________ v4v6interim mailing list v4v6interim@ietf.org https://www.ietf.org/mailman/listinfo/v4v6interim --------------040904060804040701040808 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --------------040904060804040701040808--