From ichiroumakino@gmail.com Wed Feb 1 06:01:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125711E857A for ; Wed, 1 Feb 2012 06:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id remTRfehyhI7 for ; Wed, 1 Feb 2012 06:01:06 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 200BD11E8577 for ; Wed, 1 Feb 2012 06:01:05 -0800 (PST) Received: by wgbgn7 with SMTP id gn7so6151495wgb.1 for ; Wed, 01 Feb 2012 06:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=C2Hpo1EhSvez6Ivrpra/NPwyRD4HzW9hXJbgKEBjM/E=; b=e8L59AyrXpnm9mi+vW1TjwNPS/7glzg+5f9sFKDwJDCmAUCJHzQits2Ig8VlkhUdMd HAX+7e9alX9n5kA5ooDe3N0Ehy3be0jqCiawuuhUEwdzwMutcJCRw7pjSHpNuBSRqV56 Kt+IZBnbWFjyizJ5Z9JLohj0puykDSTnbhpO4= Received: by 10.180.77.228 with SMTP id v4mr18991298wiw.2.1328104865271; Wed, 01 Feb 2012 06:01:05 -0800 (PST) Received: from [10.147.13.29] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n5sm73970063wiw.7.2012.02.01.06.01.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Feb 2012 06:01:03 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 1 Feb 2012 15:01:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8617EB83-AD23-4B65-BD76-A817153ACE33@employees.org> References: <067E6CE33034954AAC05C9EC85E2577C073C63F7@XMB-RCD-111.cisco.com> To: Leaf yeh X-Mailer: Apple Mail (2.1251.1) Cc: softwires WG Subject: Re: [Softwires] More changes to revision 03. - Sent again in text X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:01:07 -0000 Leaf, > Rajiv - I would very much favor having a sharing ratio as a 'given' = variable. >=20 > Though Rajiv prefers 'sharing ratio' to 'EA-bit length', which is a = little different from the text of section 5, >=20 > I'd also like the draft could define an explicit format for the = expression of the MAP rules including BMR, FMR & DMR. the current document specifies which parameters make up the rule. the = only time a rule would be passed on the wire is for provisioning, it is = explicitly defined in the DHCP option draft. > BTW, more questions on the example of DMR in section 5.4, >=20 > - {2001:db8:0001:0000:<interface-id>:/128 (Rule IPv6 = prefix), > 0.0.0.0/0 (Rule IPv4 prefix), > 192.0.2.1 (BR IPv4 address)} >=20 > Q1. What does =91<=92 mean here? XML artifact. '<' =3D> less than =3D> '<' > Q2. Does =91interface-id>:/128=92 sound a prefix here? yes. MAP-T forwards traffic towards a "default prefix", while MAP-E = sends to an address. > Q3. Is the BR IPv4 address (192.0.2.1) necessary here? There seems no = IPv4 address in the BMR & FMR, but they also work well for the MAP = forwarding function. if the Rule IPv4 prefix is used to indicate default route 0/0, then = there is nothing to give the IPv4 prefix part. so the complete address = is given as a parameter. this is to help implementations requiring that = the next-hop is of the same address family as the route in the RIB. it = will never make it onto the wire, so strictly speaking it isn't needed. = useful for troubleshooting though, so that you can IPv4 ping your = default router. cheers, Ole= From mark@townsley.net Wed Feb 1 06:13:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96DD21F8A2F for ; Wed, 1 Feb 2012 06:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6irN+atgwfsr for ; Wed, 1 Feb 2012 06:13:51 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23A8221F8A8F for ; Wed, 1 Feb 2012 06:13:47 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so1004182wgb.13 for ; Wed, 01 Feb 2012 06:13:46 -0800 (PST) Received: by 10.180.94.68 with SMTP id da4mr41420276wib.22.1328105626794; Wed, 01 Feb 2012 06:13:46 -0800 (PST) Received: from ams-townsley-8715.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q7sm45023269wix.5.2012.02.01.06.13.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Feb 2012 06:13:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Date: Wed, 1 Feb 2012 15:13:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:13:53 -0000 While I appreciate the functional modularity in understanding the = solution space, I do wish that DT had come up with a way to make this = one document to present to the world rather than four. I fear organ = rejection when tossing a list of RFCs for one function to the CPE = industry.=20 In current form, each document has more or less than 10 pages of = substantive text, with considerable overlap between them (how many = "framework" and "architecture" sections do we really need for what are = really just two variants of something 95% the same?). As further = evidence of the problem, there are no less than 19 references to = mdt-softwire-mapping-address-and-port from = draft-mdt-softwire-map-translation-00. One page has 5 references alone. = It's is like reading a single book with every other page in a different = binding.=20 Could we not eliminate the overlap, and just boil this down to one less = than 40 page document? In fact, I bet if you tried you could get it down = to half that. Looks like Remi's new document is on the right track in = this regard.=20 I'm in favor of the chairs stating that we will adopt a WG document = based on the text in these documents, but I would like to see a = stipulation that they be combined into one (perhaps two but with only = the DHCP option separate) and the overlap eliminated among MAP, T and E = eliminated.=20 - Mark On Jan 30, 2012, at 12:31 PM, Ole Tr=F8an wrote: > hi, >=20 > the MAP (Mapping of address and port) design team has now written and = published the following sets of drafts. >=20 > the base document (port mapping algorithm): > = http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-mapping-address-an= d-port-03.txt >=20 > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 >=20 > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 >=20 > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 >=20 > there is a MAP deployment document coming soon. >=20 > the solution described in this set of documents, are written to = satisfy the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6=20 > - develop a solution motivation document to be published as an = RFC=20 > - develop a protocol specification response to the solution=20 > motivation document; this work item will not be taken through=20= >=20 > in the design team's view, this set of documents are ready to be = adopted as working group documents. >=20 > comments? >=20 > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Wed Feb 1 06:33:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F3311E823C for ; Wed, 1 Feb 2012 06:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23ypvF5yUWr5 for ; Wed, 1 Feb 2012 06:33:56 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2EE11E815D for ; Wed, 1 Feb 2012 06:33:56 -0800 (PST) Received: by werm10 with SMTP id m10so1220332wer.31 for ; Wed, 01 Feb 2012 06:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=5H7SftP4cszcK9gjfN2bWsKEBBYsYCeHY2/Tnl+OZpo=; b=vuFEZhRtJDfa8tJKtb+4sN38Xhn5deKjs5KR+RQzRShM0afURqObM4u40+DUarOWfV 4ZIpJrFMjd2eZSc0sWXDmCBib6GeRLa2PAv53rshDk38fpm3U1yC+4HWrJKalteGWdOl PfRj0z40EFO6RHyGAq6oEVZIbVy4d4qqtYb/E= Received: by 10.216.136.202 with SMTP id w52mr2836157wei.57.1328106835272; Wed, 01 Feb 2012 06:33:55 -0800 (PST) Received: from [10.147.13.29] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id d9sm45149817wiy.2.2012.02.01.06.33.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Feb 2012 06:33:54 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> Date: Wed, 1 Feb 2012 15:33:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1251.1) Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:33:57 -0000 Mark, > While I appreciate the functional modularity in understanding the = solution space, I do wish that DT had come up with a way to make this = one document to present to the world rather than four. I fear organ = rejection when tossing a list of RFCs for one function to the CPE = industry.=20 >=20 > In current form, each document has more or less than 10 pages of = substantive text, with considerable overlap between them (how many = "framework" and "architecture" sections do we really need for what are = really just two variants of something 95% the same?). As further = evidence of the problem, there are no less than 19 references to = mdt-softwire-mapping-address-and-port from = draft-mdt-softwire-map-translation-00. One page has 5 references alone. = It's is like reading a single book with every other page in a different = binding.=20 >=20 > Could we not eliminate the overlap, and just boil this down to one = less than 40 page document? In fact, I bet if you tried you could get it = down to half that. Looks like Remi's new document is on the right track = in this regard.=20 >=20 > I'm in favor of the chairs stating that we will adopt a WG document = based on the text in these documents, but I would like to see a = stipulation that they be combined into one (perhaps two but with only = the DHCP option separate) and the overlap eliminated among MAP, T and E = eliminated.=20 with regards to document organization we've been over that a few times. = my understanding of the Beijing interim meeting was to have the = organization of documents we have now. largely because there were = discussions on different document status for the different documents. = e.g. experimental versus standards track. yes, it is certainly possible to merge the 3 documents (MAP, T, E), with = separate sections that only apply to encapsulation and some that apply = to translation. what I feat is that you will pollute the text with lots = of "does not apply in the translation case", "fragmentation issues are = slightly different", and so on. this is obviously something the working group has to decide on, but I = don't think that needs to be done before adopting this document set. cheers, Ole= From adurand@juniper.net Wed Feb 1 08:32:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA921F8C5D for ; Wed, 1 Feb 2012 08:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.979 X-Spam-Level: X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTLJKfhQBHzu for ; Wed, 1 Feb 2012 08:32:53 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 57B4121F8A9C for ; Wed, 1 Feb 2012 08:32:48 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTylpL+2PAqh+ki4UDk/3+HgM/vmAehgm@postini.com; Wed, 01 Feb 2012 08:32:53 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 1 Feb 2012 08:28:43 -0800 From: Alain Durand To: Softwires WG Date: Wed, 1 Feb 2012 08:28:40 -0800 Thread-Topic: Moving forward with 4rd-T, 4rd-E & 4rd-U Thread-Index: Aczg/o/r7v3+nerQQUWkiU5+ojD5Aw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yong Cui , Ralph Droms Subject: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 16:32:54 -0000 Dear wg, We now have a number of documents and solutions on the table in the 4rd cat= egory: all the MAP effort, including 4rd-T & 4rd-E, and, somehow separately, the 4rd-U effort. I will claim that there is a ver= y large overlap between all those solution and somehow small differences. For the sake of this discussion, I'll say the overlap is about 90%, the exa= ct number is irrelevant, what matters is that this number is much more than= 50% I have expressed many times that, in my view, the main role of a standard p= rocess is to pick one solution when multiple are available. Not that the others are bad, but that the fact of not choosing and pushing through t= he process a number of solutions that are 90% or more identical is not doin= g the community any good. Back at Beijin interim meeting, we agreed on 'publishing' a number of docum= ents, but did not agree on status and/or recommendation attached to 4rd-E and 4rd-T. later, 4rd-U came as an attempt at unifying th= en. At stake here is not so much the organization of the document set, nor whic= h document(s) are accepted as wg item(s) right now on the basis that they are somehow technologically 'ready'. At stake now is how many solutions that are 90% overlapping we are going to= send to the IESG. In other words, at stake is the capability of this wg to make clear recommendations as to = what to implement and what to deploy. At this point in time, I think the wg as the choice between a number of pat= hs forward: 1) Declare failure to reach consensus and stop working on this 4rd space. 2) Declare a Pyrrhic(*) victory, publish everything on the standard track w= ithout any recommendation as to which one to use 3) Declare partial victory, publish everything as Experimental, let the mar= ket decide and come back in two years to put the winner on the standard track. 4) Converge to a consensus toward one 'recommended' solution, publish that = one as Standard track and publish the other ones as experimental/informational, THEN declare victory. Note t= hat using standard track vs experimental is just one way to make recommendations on status, there are others, such as publishin= g a recommendation document or adding recommendation text in a boiler plate inside each document. I'd think that we would all agree that 1) is the least preferred option. 2) might be appealing as a short term solution to (not solve) the recommend= ation problem we are faced with, but if we do that, I would claim that the wg would have not done its job and would have simply= added to the confusion around which transition mechanism to choose. Hence my qualification of this soluti= on as 'Pyrrhic' victory. As wg co-chair, my perspective is that we should do either 3) or 4) I would like to encourage the wg to start a discussion toward 4) on the mai= ling list so that we could have a productive conversation in Paris, where I intend to ask for wg feedback on this question. More over, 4rd-U claims to solves a number of issues that the MAP suite of = documents does not address. It would be beneficial to have a discussion on the mailing list to see if a) those issues are important o= r not and b), if they are, are they properties of 4rd-U or could they be so= lved as well in MAP, they just have not been addressed there yet. In the mean time, I believe we should hold off accepting any document as wg= item. I'd like to use the upcoming Paris meeting next month as a forcing function to make progress and I encourage discussio= n on the mailing list on thee above topics until then. Alain, Softwire wg co-chair. (*)See http:// en.wikipedia.org/wiki/Pyrrhic_victory= From despres.remi@laposte.net Wed Feb 1 08:43:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974A511E80A0 for ; Wed, 1 Feb 2012 08:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbzDYzx6y2Lk for ; Wed, 1 Feb 2012 08:43:00 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 96DDA11E8071 for ; Wed, 1 Feb 2012 08:42:57 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id EDE33940238; Wed, 1 Feb 2012 17:42:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> Date: Wed, 1 Feb 2012 17:42:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E0CF34A-0989-4C69-8094-136EAEC7BBE1@laposte.net> References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 16:43:00 -0000 Le 2012-02-01 =E0 15:13, Mark Townsley a =E9crit : >=20 > While I appreciate the functional modularity in understanding the = solution space, I do wish that DT had come up with a way to make this = one document to present to the world rather than four. I fear organ = rejection when tossing a list of RFCs for one function to the CPE = industry.=20 >=20 > In current form, each document has more or less than 10 pages of = substantive text, with considerable overlap between them (how many = "framework" and "architecture" sections do we really need for what are = really just two variants of something 95% the same?). As further = evidence of the problem, there are no less than 19 references to = mdt-softwire-mapping-address-and-port from = draft-mdt-softwire-map-translation-00. One page has 5 references alone. = It's is like reading a single book with every other page in a different = binding.=20 >=20 > Could we not eliminate the overlap, and just boil this down to one = less than 40 page document? In fact, I bet if you tried you could get it = down to half that. Looks like Remi's new document is on the right track = in this regard.=20 >=20 > I'm in favor of the chairs stating that we will adopt a WG document = based on the text in these documents, but I would like to see a = stipulation that they be combined into one (perhaps two but with only = the DHCP option separate) and the overlap eliminated among MAP, T and E = eliminated.=20 Well, this seems similar to taking the new 4rd document and analyzing = what is missing or is unnecessary. Except for the fact that double RF46145 is replaced by the = self-contained Header mapping variant, more transparent, but about which = there is an ongoing discussion with Maoke, the last 4rd-U draft is, in = my understanding, largely what you are looking for. It avoids all the complexity of GMA port-mapping, a nice piece of = technology but near to 5 pages that don't seem to serve real needs (a = fixed PSID is enough in practice AFAIK).=20 Avoiding to review the unified draft because of some NIH syndrome would = be IMHO a way to miss a good opportunity for progress. I do look forward to technical comments on draft-despres-softwire-4rd-U. RD >=20 > - Mark >=20 >=20 > On Jan 30, 2012, at 12:31 PM, Ole Tr=F8an wrote: >=20 >> hi, >>=20 >> the MAP (Mapping of address and port) design team has now written and = published the following sets of drafts. >>=20 >> the base document (port mapping algorithm): >> = http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-mapping-address-an= d-port-03.txt >>=20 >> the encapsulation document (MAP-E): >> http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 >>=20 >> the translation document (MAP-T): >> http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 >>=20 >> the DHCP option (MAP-DHCP): >> http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 >>=20 >> there is a MAP deployment document coming soon. >>=20 >> the solution described in this set of documents, are written to = satisfy the following from the softwires charter: >> 4. Developments for stateless legacy IPv4 carried over IPv6=20 >> - develop a solution motivation document to be published as an RFC=20= >> - develop a protocol specification response to the solution=20 >> motivation document; this work item will not be taken through=20 >>=20 >> in the design team's view, this set of documents are ready to be = adopted as working group documents. >>=20 >> comments? >>=20 >> for the MAP design team, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Feb 1 09:33:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA211E8149 for ; Wed, 1 Feb 2012 09:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rgE4jjDdEIf for ; Wed, 1 Feb 2012 09:33:28 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B65E11E814C for ; Wed, 1 Feb 2012 09:33:26 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 495D69402B2; Wed, 1 Feb 2012 18:33:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-95--229437050 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 1 Feb 2012 18:33:17 +0100 Message-Id: References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] New version of 4rd-U - Header mapping (4rd-H vs 4rd-T) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 17:33:29 -0000 --Apple-Mail-95--229437050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-01 =E0 03:04, Maoke a =E9crit : >=20 >=20 > 2012/1/30 R=E9mi Despr=E9s >=20 >> and definitely there is no compatibility to single translation in = RFC6145 at all. as the result, RFC6145 provides a unified solution, = while 4rd-U requires ISP (who prefer to use translation) disjointly = deploy their networks for single and double translations. >> =20 >> =20 >>=20 >> If you have a specific configuration that illustrates your concern, = it could be discussed with more details. >=20 > Could you, for the sake of a less abstract discussion, describe at = least one configuration you have in mind, in which some IPv4 addresses = are statelessly shared, and in which there is the RFC6145 compatibility = you are talking about. > Without that, I can't figure out what you mean.=20 > (The goal remains customer service, without harm if this happens to be = possible without full support of RFC4125, right?) >=20 > to my best understanding, one of the merits of the translation = approach is: when an end system changes its stack from ipv4 to ipv6, If it is on a V6-only network, isn't the end system already dual stack? Then, if it needs to be reachable in IPv4, why would it change IPv6-only = while the 4rd service remains available? RD > as long as the ipv4-translatable ipv6 address is applied, its peers in = the past can keep using the same ipv4 address (as the temporal-unique = identifier) to have access to it. in other words, the stack-changing = doesn't impact already-existing peers, but enlarges the opportunity for = the new connections from native ipv6 peers. separating single = translation and double translation with deploying disjoint ipv4 (as well = as corresponding ipv6) spaces is meaningless in this term. ... --Apple-Mail-95--229437050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/1/30 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

and definitely there is no compatibility to = single translation in RFC6145 at all. as the result, = RFC6145 provides a unified solution, while 4rd-U requires ISP (who = prefer to use translation) disjointly deploy their networks for = single and double translations.
 
 

If you have a specific configuration = that illustrates your concern, it could be discussed with more = details.

<= /div>
Could you, for the sake of a less abstract discussion, = describe at least one configuration you have in mind, in which some IPv4 = addresses are statelessly shared, and in which there is the RFC6145 = compatibility you are talking about.
Without that, I can't figure out what you = mean. 
(The goal remains customer service, without harm = if this happens to be possible without full support of RFC4125, = right?)

to my best understanding, one of the merits of the = translation approach is: when an end system changes its stack from ipv4 = to ipv6,

If it is on a = V6-only network, isn't the end system already dual = stack?
Then, if it needs to be reachable in IPv4, why would it = change IPv6-only while the 4rd service remains = available?

RD

as long as the = ipv4-translatable ipv6 address is applied, its peers in the past can = keep using the same ipv4 address (as the temporal-unique identifier) to = have access to it. in other words, the stack-changing doesn't impact = already-existing peers, but enlarges the opportunity for the new = connections from native ipv6 peers. separating single translation and = double translation with deploying disjoint ipv4 (as well as = corresponding ipv6) spaces is meaningless in this term. =

...


= --Apple-Mail-95--229437050-- From fibrib@gmail.com Wed Feb 1 19:26:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2B411E8098 for ; Wed, 1 Feb 2012 19:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3xXrC6LwQuh for ; Wed, 1 Feb 2012 19:26:36 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 048B711E8087 for ; Wed, 1 Feb 2012 19:26:35 -0800 (PST) Received: by qan41 with SMTP id 41so1318486qan.10 for ; Wed, 01 Feb 2012 19:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=shkyyHQlhGIKkTNy/wYWwEytZbN1dyBkEMuzH/JWlSg=; b=snfdwWqX0qXfPMB4iqu5/sP/+iI/Yn9gRKcqDfU21tBy6Hap5EPKSeyaHsQB6lXHOR EnXHzcaIXbAhyZ6M/PQADEsKJF3Oj4YLFhgqqpE2uA28vojd5tGbRoQo7yDOhTKEbDJs xu2TJ4dhq/hM7wBBNRhGlGDrf2jjB1JnmYQ7o= MIME-Version: 1.0 Received: by 10.224.202.65 with SMTP id fd1mr1825969qab.12.1328153195550; Wed, 01 Feb 2012 19:26:35 -0800 (PST) Received: by 10.229.211.72 with HTTP; Wed, 1 Feb 2012 19:26:35 -0800 (PST) In-Reply-To: References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> Date: Thu, 2 Feb 2012 12:26:35 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30050eea6d996104b7f2c322 Cc: Softwires WG Subject: Re: [Softwires] New version of 4rd-U - Header mapping (4rd-H vs 4rd-T) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 03:26:36 -0000 --20cf30050eea6d996104b7f2c322 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/2/2 R=E9mi Despr=E9s > > > > to my best understanding, one of the merits of the translation approach > is: when an end system changes its stack from ipv4 to ipv6, > > > If it is on a V6-only network, isn't the end system already dual stack? > dual stack doesn't mean dual networking, which is costy in operation and management. > Then, if it needs to be reachable in IPv4, why would it change IPv6-only > while the 4rd service remains available? > it need to be reachable in both IPv4 and native IPv6, and it is expected that the latter will be more and more in the future. - maoke > > RD > --20cf30050eea6d996104b7f2c322 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/2/2 R=E9mi Despr=E9s = <despres.r= emi@laposte.net>



to my best understanding, one of the merits of the translati= on approach is: when an end system changes its stack from ipv4 to ipv6,

If it is on a V6-only network, isn= 't the end system already dual stack?

dual stack doesn't mean du= al networking, which is costy in operation and management.=A0
=A0=
Then, if it needs to be reach= able in IPv4, why would it change IPv6-only while the 4rd service remains a= vailable?

it need to be r= eachable in both IPv4 and native IPv6, and it is expected that the latter w= ill be more and more in the future.=A0

- maoke=A0
=A0

RD

--20cf30050eea6d996104b7f2c322-- From eleven.fuyu@huawei.com Wed Feb 1 19:33:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2568A11E8098 for ; Wed, 1 Feb 2012 19:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKvIWUfYGHzi for ; Wed, 1 Feb 2012 19:33:05 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 022C311E8087 for ; Wed, 1 Feb 2012 19:33:05 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYQ00E5FXUX6C@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 02 Feb 2012 11:32:57 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYQ003CXXUXH4@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 02 Feb 2012 11:32:57 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGT18627; Thu, 02 Feb 2012 11:32:57 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 02 Feb 2012 11:32:33 +0800 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.21]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Thu, 02 Feb 2012 11:32:49 +0800 Date: Thu, 02 Feb 2012 03:32:48 +0000 From: "Eleven Fu(Yu)" X-Originating-IP: [10.108.4.119] To: softwires WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-fu-softwire-4rd-mib-00.txt Thread-index: AQHM4LA4NWUkN9AwSEW8OBFSJ2lJB5Yo76rw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [Softwires] FW: New Version Notification for draft-fu-softwire-4rd-mib-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 03:33:06 -0000 Hi All, A new draft " Definitions of Managed Objects for 4rd " has been submitted to the WG. It defines managed objects for 4rd, more exactly, for the MAP-E scenario. Your review and comments are much appreciated. Best regards, Yu, Sheng, Jiang & Peng -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, February 01, 2012 3:08 PM To: Eleven Fu(Yu) Cc: weapon@csnet1.cs.tsinghua.edu.cn; Sheng Jiang; dongjiang@csnet1.cs.tsinghua.edu.cn; Eleven Fu(Yu) Subject: New Version Notification for draft-fu-softwire-4rd-mib-00.txt A new version of I-D, draft-fu-softwire-4rd-mib-00.txt has been successfully submitted by Yu Fu and posted to the IETF repository. Filename: draft-fu-softwire-4rd-mib Revision: 00 Title: Definitions of Managed Objects for 4rd Creation date: 2012-02-01 WG ID: Individual Submission Number of pages: 15 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for 4rd. The IETF Secretariat From fibrib@gmail.com Wed Feb 1 19:38:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C56F11E80E8 for ; Wed, 1 Feb 2012 19:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpUWEOUSBcdf for ; Wed, 1 Feb 2012 19:38:27 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA3EE11E80DE for ; Wed, 1 Feb 2012 19:38:26 -0800 (PST) Received: by qcsg13 with SMTP id g13so1315246qcs.31 for ; Wed, 01 Feb 2012 19:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Oc6lmIgc4vcZrwMlRslJNB067helFRJDqwXaHi6vH7k=; b=lheBGilxDwrkzNtTGfq8eeH0BsudUH9/iazkLozsOyWvvLLZTqavafi3WNFc5IPDnc DLG28sSMXNd6m0/tW+75osDAJz5eEEXBEFVDuQWv9pO0bAel4QvBhc5eLOezZ2ACUO+I qQlnEA81J6xsvXKiwQOVpr7hPV2vzi+z+GeAM= MIME-Version: 1.0 Received: by 10.229.75.137 with SMTP id y9mr329113qcj.123.1328153906435; Wed, 01 Feb 2012 19:38:26 -0800 (PST) Received: by 10.229.211.72 with HTTP; Wed, 1 Feb 2012 19:38:26 -0800 (PST) In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Date: Thu, 2 Feb 2012 12:38:26 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=00235429d794ccd68804b7f2ed82 Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 03:38:28 -0000 --00235429d794ccd68804b7f2ed82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/1/30 Ole Tr=F8an > hi, > the MAP (Mapping of address and port) design team has now written and > published the following sets of drafts. > > the base document (port mapping algorithm): > http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-0= 3 > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-mapping-address-a= nd-port-03.txt > > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 > > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 > > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 > > there is a MAP deployment document coming soon. > > the solution described in this set of documents, are written to satisfy > the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an RFC > - develop a protocol specification response to the solution > motivation document; this work item will not be taken through > > in the design team's view, this set of documents are ready to be adopted > as working group documents. > support. and the set becoming WG document will help the deployment guidance drafting. - maoke > > comments? > > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00235429d794ccd68804b7f2ed82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/1/30 Ole Tr=F8an = <otroan@employees.org>
hi,=A0

the MAP (Mapping of address and port) design team has now written and publi= shed the following sets of drafts.

the base document (port mapping algorithm):
=A0http://tools.ietf.org/html/draft-mdt-softw= ire-mapping-address-and-port-03
=A0http://tools.ietf.org/rfcdif= f?url2=3Ddraft-mdt-softwire-mapping-address-and-port-03.txt

the encapsulation document (MAP-E):
=A0http://tools.ietf.org/html/draft-mdt-softwire-map= -encapsulation-00

the translation document (MAP-T):
=A0http://tools.ietf.org/html/draft-mdt-softwire-map-t= ranslation-00

the DHCP option (MAP-DHCP):
=A0http://tools.ietf.org/html/draft-mdt-softwire-map-d= hcp-option-02

there is a MAP deployment document coming soon.

the solution described in this set of documents, are written to satisfy the= following from the softwires charter:
=A0 4. Developments for stateless legacy IPv4 carried over IPv6
=A0 =A0 =A0- develop a solution motivation document to be published as an = RFC
=A0 =A0 =A0- develop a protocol specification response to the solution
=A0 =A0 =A0 =A0motivation document; this work item will not be taken throu= gh

in the design team's view, this set of documents are ready to be adopte= d as working group documents.

support. = and the set becoming WG document will help the deployment guidance drafting= .=A0

- maoke=A0
=A0

comments?

for the MAP design team,
Ole
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--00235429d794ccd68804b7f2ed82-- From fibrib@gmail.com Wed Feb 1 20:20:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270B411E80BF for ; Wed, 1 Feb 2012 20:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwHdfTXx9zTk for ; Wed, 1 Feb 2012 20:20:55 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8504A11E80B4 for ; Wed, 1 Feb 2012 20:20:55 -0800 (PST) Received: by qcsg13 with SMTP id g13so1332354qcs.31 for ; Wed, 01 Feb 2012 20:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MV7b0b58muwmbOR2E4vekombk43p+fHLg8PhcXSzdqU=; b=Tmvne77YMokFWjMbX7vAQJjucVa4gb1bsLw3ixGFYlugj/nXni7o4BY7zUrgc+xzSS e/qSDk9rO10OfFUWSI8bYsUeuqx/WClMU+nQN4K+bjBPnVacagietMiBBohGOvp9Wd2n fMQGmcb9WNUuzhaJ9hVOobaT+dS7T4Jjcafuc= MIME-Version: 1.0 Received: by 10.224.202.65 with SMTP id fd1mr1952031qab.12.1328156455079; Wed, 01 Feb 2012 20:20:55 -0800 (PST) Received: by 10.229.211.72 with HTTP; Wed, 1 Feb 2012 20:20:55 -0800 (PST) In-Reply-To: <6E0CF34A-0989-4C69-8094-136EAEC7BBE1@laposte.net> References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> <6E0CF34A-0989-4C69-8094-136EAEC7BBE1@laposte.net> Date: Thu, 2 Feb 2012 13:20:55 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30050eeab60fad04b7f3853a Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 04:20:56 -0000 --20cf30050eeab60fad04b7f3853a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/2/2 R=E9mi Despr=E9s > > Except for the fact that double RF46145 is replaced by the self-contained > Header mapping variant, more transparent, but about which there is an > ongoing discussion with Maoke, the last 4rd-U draft is, in my > understanding, largely what you are looking for. > briefly summary my action and understanding in order to avoid confusion. 1. my detailed re-study on RFC6145 behavior in double translation has been finished and i have NO new protocol or algorithm proposal which is worthy sharing to the community; 2. (because) RFC6145 has provided (not thorough but) good enough transparency when used in double translation, and accordingly it is NOT needed to be updated; 3. carrying ICMPv4 directly in IPv6 payload will be a harmful idea and less feasible. basically i doubt it is significant enough to make a document explaining the RFC6145 behavior in double-translation, as well as the corresponding concerns. however, if some people would like to have such an informational document, i'd love to elaborate. - maoke --20cf30050eeab60fad04b7f3853a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/2/2 R=E9mi Despr=E9s = <despres.remi@laposte.net>

Except for the fact that double RF46145 is replaced by the self-contain= ed Header mapping variant, more transparent, but about which there is an on= going discussion with Maoke, the last 4rd-U draft is, in my understanding, = largely what you are looking for.

briefly summary my action and understandin= g in order to avoid confusion. 1. my detailed re-study on RFC6145 behavior = in double translation has been finished and i have NO new protocol or algor= ithm proposal which is worthy sharing to the community; 2. (because) RFC614= 5 has provided (not thorough but) good enough transparency when used in dou= ble translation, and accordingly it is NOT needed to be updated; 3. carryin= g ICMPv4 directly in IPv6 payload will be a harmful idea and less feasible.= =A0

basically i doubt it is significant enough to make a do= cument explaining the RFC6145 behavior in double-translation, as well as th= e corresponding concerns. however, if some people would like to have such a= n informational document, i'd love to elaborate.=A0

- maoke=A0
--20cf30050eeab60fad04b7f3853a-- From moulchan@cisco.com Wed Feb 1 23:16:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D229021F8AE1 for ; Wed, 1 Feb 2012 23:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.276 X-Spam-Level: X-Spam-Status: No, score=-8.276 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7e7QjP4EoYA for ; Wed, 1 Feb 2012 23:16:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B182121F8AD3 for ; Wed, 1 Feb 2012 23:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moulchan@cisco.com; l=4472; q=dns/txt; s=iport; t=1328166974; x=1329376574; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=scXGosPDZQH7OGxNa2P1GYmkoS+vbr4BBP7QrvaruUs=; b=mukKCzPStIrYjNZ1LSDFyMtA/p/7fAnCl5+rX2hT4hDHH9Jf9H4SM67r EteYf06YjwxCme7jrUMJ+LrQBDOgMUbnLtAhjA9nUYIs/+6J4KfV/zWRj itNIyhLhL9bt1dq5r+axUTzlW16AKFCh/1sf1IS/Zmurr/C+3f4NI72xZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFk3Kk+tJXG9/2dsb2JhbABDrwmBBYFyAQEBBAEBAQ8BHQoNJwsMBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAESCAwHB4djmXABkEiOEotJKzUMAoQygnVjBIhCn1Q X-IronPort-AV: E=Sophos;i="4.71,608,1320624000"; d="scan'208";a="55719369" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 02 Feb 2012 07:16:14 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q127GDbI030933; Thu, 2 Feb 2012 07:16:13 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 01:16:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Feb 2012 01:16:07 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U Thread-Index: Aczg/o/r7v3+nerQQUWkiU5+ojD5AwAey44Q References: From: "Mouli Chandramouli (moulchan)" To: "Alain Durand" , "Softwires WG" X-OriginalArrivalTime: 02 Feb 2012 07:16:12.0933 (UTC) FILETIME=[8B7C2350:01CCE17A] Cc: Yong Cui , "Ralph Droms \(rdroms\)" Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 07:16:15 -0000 Hello, To evaluate the merits/demerits of these approaches, there can be also be a benchmark of use cases (V6 transition network scenarios). It may be useful to have prototypes implemented and results can be published for these scenarios, which can help in converging and narrowing down the methods.=20 Thanks=20 Mouli -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Alain Durand Sent: Wednesday, February 01, 2012 9:59 PM To: Softwires WG Cc: Yong Cui; Ralph Droms (rdroms) Subject: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U Dear wg, We now have a number of documents and solutions on the table in the 4rd category: all the MAP effort, including 4rd-T & 4rd-E, and, somehow separately, the 4rd-U effort. I will claim that there is a very large overlap between all those solution and somehow small differences. For the sake of this discussion, I'll say the overlap is about 90%, the exact number is irrelevant, what matters is that this number is much more than 50% I have expressed many times that, in my view, the main role of a standard process is to pick one solution when multiple are available. Not that the others are bad, but that the fact of not choosing and pushing through the process a number of solutions that are 90% or more identical is not doing the community any good. Back at Beijin interim meeting, we agreed on 'publishing' a number of documents, but did not agree on status and/or recommendation attached to 4rd-E and 4rd-T. later, 4rd-U came as an attempt at unifying then. At stake here is not so much the organization of the document set, nor which document(s) are accepted as wg item(s) right now on the basis that they are somehow technologically 'ready'. At stake now is how many solutions that are 90% overlapping we are going to send to the IESG. In other words, at stake is the capability of this wg to make clear recommendations as to what to implement and what to deploy. At this point in time, I think the wg as the choice between a number of paths forward: 1) Declare failure to reach consensus and stop working on this 4rd space. 2) Declare a Pyrrhic(*) victory, publish everything on the standard track without any recommendation as to which one to use 3) Declare partial victory, publish everything as Experimental, let the market decide and come back in two years to put the winner on the standard track. 4) Converge to a consensus toward one 'recommended' solution, publish that one as Standard track and publish the other ones as experimental/informational, THEN declare victory. Note that using standard track vs experimental is just one way to make recommendations on status, there are others, such as publishing a recommendation document or adding recommendation text in a boiler plate inside each document. I'd think that we would all agree that 1) is the least preferred option. 2) might be appealing as a short term solution to (not solve) the recommendation problem we are faced with, but if we do that, I would claim that the wg would have not done its job and would have simply added to the confusion around which transition mechanism to choose. Hence my qualification of this solution as 'Pyrrhic' victory. As wg co-chair, my perspective is that we should do either 3) or 4) I would like to encourage the wg to start a discussion toward 4) on the mailing list so that we could have a productive conversation in Paris, where I intend to ask for wg feedback on this question. More over, 4rd-U claims to solves a number of issues that the MAP suite of documents does not address. It would be beneficial to have a discussion on the mailing list to see if a) those issues are important or not and b), if they are, are they properties of 4rd-U or could they be solved as well in MAP, they just have not been addressed there yet. In the mean time, I believe we should hold off accepting any document as wg item. I'd like to use the upcoming Paris meeting next month as a forcing function to make progress and I encourage discussion on the mailing list on thee above topics until then. Alain, Softwire wg co-chair. (*)See http:// en.wikipedia.org/wiki/Pyrrhic_victory _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Thu Feb 2 00:06:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B3721F8AAD for ; Thu, 2 Feb 2012 00:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge1hyOtduzVR for ; Thu, 2 Feb 2012 00:06:21 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id AE84221F8ACB for ; Thu, 2 Feb 2012 00:06:18 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 2BED29401D7; Thu, 2 Feb 2012 09:06:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-96--177066607 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 2 Feb 2012 09:06:07 +0100 Message-Id: References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> <6E0CF34A-0989-4C69-8094-136EAEC7BBE1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 08:06:21 -0000 --Apple-Mail-96--177066607 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-02 =E0 05:20, Maoke a =E9crit : >=20 > 2012/2/2 R=E9mi Despr=E9s >=20 > Except for the fact that double RF46145 is replaced by the = self-contained Header mapping variant, more transparent, but about which = there is an ongoing discussion with Maoke, the last 4rd-U draft is, in = my understanding, largely what you are looking for. >=20 > briefly summary my action and understanding in order to avoid = confusion. > 1. my detailed re-study on RFC6145 behavior in double translation has = been finished and i have NO new protocol or algorithm proposal which is = worthy sharing to the community; No misunderstanding on this. > 2. (because) RFC6145 has provided (not thorough but) good enough = transparency when used in double translation, and accordingly it is NOT = needed to be updated; Full transparency, based on clear theory, remains AFAIK better than = "good enough" based on some collected statistic at a given time. > 3. carrying ICMPv4 directly in IPv6 payload will be a harmful idea and = less feasible. I don't see where you see that ICMPv4 payload tunneled in a mapped = header isn't easily feasible. Stating it is harmful is of course not a proof. Discussion on this point can continue with more details in other e-amils = based on configurations you have in mind. =20 RD > basically i doubt it is significant enough to make a document = explaining the RFC6145 behavior in double-translation, as well as the = corresponding concerns. however, if some people would like to have such = an informational document, i'd love to elaborate.=20 >=20 > - maoke=20 --Apple-Mail-96--177066607 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

2012/2/2 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Except for the fact that double RF46145 is replaced by the = self-contained Header mapping variant, more transparent, but about which = there is an ongoing discussion with Maoke, the last 4rd-U draft is, in = my understanding, largely what you are looking for.

briefly summary my action and = understanding in order to avoid confusion. =

1. my detailed re-study on RFC6145 behavior = in double translation has been finished and i have NO new protocol or = algorithm proposal which is worthy sharing to the community; =

No misunderstanding on = this.

2. (because) RFC6145 has provided (not = thorough but) good enough transparency when used in double translation, = and accordingly it is NOT needed to be = updated;

Full transparency, = based on clear theory, remains AFAIK better than "good enough" based on = some collected statistic at a given time.

3. carrying ICMPv4 = directly in IPv6 payload will be a harmful idea and less = feasible.

I don't see where = you see that ICMPv4 payload tunneled in a mapped header isn't easily = feasible.

Stating it is harmful is of course = not a proof.
Discussion on this point can continue with more = details in other e-amils based on configurations you have in mind. =  

RD

basically i doubt it is significant enough = to make a document explaining the RFC6145 behavior in = double-translation, as well as the corresponding concerns. however, if = some people would like to have such an informational document, i'd love = to elaborate. 

- maoke 

= --Apple-Mail-96--177066607-- From fibrib@gmail.com Thu Feb 2 01:28:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEB121F8978 for ; Thu, 2 Feb 2012 01:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWTUAumYa1hD for ; Thu, 2 Feb 2012 01:27:59 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9F21F8974 for ; Thu, 2 Feb 2012 01:27:58 -0800 (PST) Received: by qan41 with SMTP id 41so1447404qan.10 for ; Thu, 02 Feb 2012 01:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z0zWhygTUn8mxWhKsYQU1kBt9nyWNe+ZIi4d3Dc1UOc=; b=eASaVPQkkAvLgi7kUdDjR7dmOck0gp4YMT8AqfMg+yopcOhnoS1NqLSYRqFI0Mz4Cw 4MkM6CeAPyrJGRg1k/YIAtibwQc3e7TEr1D/OOi29UUKGuUBZFp0T22cY2w/NZtu7yql jnBnCe+8gIXyQvCDZELpqhijA/bOEKxHIe+5E= MIME-Version: 1.0 Received: by 10.224.190.6 with SMTP id dg6mr2746589qab.25.1328174877673; Thu, 02 Feb 2012 01:27:57 -0800 (PST) Received: by 10.229.211.72 with HTTP; Thu, 2 Feb 2012 01:27:57 -0800 (PST) In-Reply-To: References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> <6E0CF34A-0989-4C69-8094-136EAEC7BBE1@laposte.net> Date: Thu, 2 Feb 2012 18:27:57 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300fb37fc8897d04b7f7cfe3 Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:28:00 -0000 --20cf300fb37fc8897d04b7f7cfe3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/2/2 R=E9mi Despr=E9s > > > 2. (because) RFC6145 has provided (not thorough but) good enough > transparency when used in double translation, and accordingly it is NOT > needed to be updated; > > > Full transparency, based on clear theory, remains AFAIK better than "good > enough" based on some collected statistic at a given time. > as i stated, we want to have better transparency but only if it is not costly and the solution has no other obvious flaws. > > 3. carrying ICMPv4 directly in IPv6 payload will be a harmful idea and > less feasible. > > > I don't see where you see that ICMPv4 payload tunneled in a mapped header > isn't easily feasible. > not feasible in term of supporting the operation where the single/double translations are needed simultaneously and are needed to be treated statelessly. > > Stating it is harmful is of course not a proof. > Discussion on this point can continue with more details in other e-amils > based on configurations you have in mind. > i have proposed a concrete problem rather than a simple statement at least twice in the past mail dialogues. ;-) - maoke --20cf300fb37fc8897d04b7f7cfe3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/2/2 R=E9mi Despr=E9s <despres.remi@laposte.ne= t>


2. (because) RFC6145 has provided (not= thorough but) good enough transparency when used in double translation, an= d accordingly it is NOT needed to be updated;

Full transparency, based on cl= ear theory, remains AFAIK better than "good enough" based on some= collected statistic at a given time.

as i stated, we want to have better transparency but only if= it is not costly and the solution has no other obvious flaws.=A0
=A0

3. carrying ICMPv4 directly = in IPv6 payload will be a harmful idea and less feasible.

I don't see where you see that ICMPv4 payload= tunneled in a mapped header isn't easily feasible.

not feasible in term of supporting the opera= tion where the single/double translations are needed simultaneously and are= needed to be treated statelessly.=A0
=A0

Stating it is harmful is of course not a pro= of.
Discussion on this point can continue with more details in other e-ami= ls based on configurations you have in mind. =A0

i have proposed a concrete problem rather than a si= mple statement at least twice in the past mail dialogues. ;-)=A0

- maoke=A0

--20cf300fb37fc8897d04b7f7cfe3-- From despres.remi@laposte.net Thu Feb 2 01:30:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9903221F8A58 for ; Thu, 2 Feb 2012 01:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWXBOSr5ArBc for ; Thu, 2 Feb 2012 01:30:58 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C880D21F8A27 for ; Thu, 2 Feb 2012 01:30:55 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id F192F940204; Thu, 2 Feb 2012 10:30:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-97--171986897 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 2 Feb 2012 10:30:47 +0100 Message-Id: <23CE9B9D-5469-4537-B4D8-607834D13EBF@laposte.net> References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] No change to RFC6145 needed for 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:30:58 -0000 --Apple-Mail-97--171986897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-01 =E0 03:04, Maoke a =E9crit : > ... >=20 > i have investigated, technically, what if we had updated RFC6145 with = carrying ICMPv4 messages in IPv6 directly instead of translating to = ICMPv6, specially for double translation, Introducing ICMPv4 messages in IPv6 packets "instead of" ICMPv6 messages = in RFC6145 would be an incompatible change.=20 I don't think anyone proposed that. =20 What might be envisaged without the same backward incompatibility, is = that IPv6-only hosts would accept in IPv6 packets BOTH IPv6 ICMP = messages and ICMPv4 messages. Yet, it remains to be analyzed whether it would be useful in real world. This depends on a detailed use case being identified, where double = RFC6145 translation would have a substantial advantage over the = header-mapping variant of 4rd-U-03 (4rd-H). (This advantage would have = to compensate for the loss of IPv4 transparency as good as that of = 4rd-E, and for the loss of the tunnel-specific traffic class which can = be used in 4rd-E.)=20 This use case, key for this discussion, is subject of another e-mail = thread. RD --Apple-Mail-97--171986897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
...

i have investigated, = technically, what if we had updated RFC6145 with carrying ICMPv4 = messages in IPv6 directly instead of translating to ICMPv6, specially = for double = translation,

Introducing = ICMPv4 messages in IPv6 packets "instead of" ICMPv6 messages in RFC6145 = would be an incompatible change. 
I don't think anyone = proposed that.
 
What might be envisaged = without the same backward incompatibility, is that IPv6-only hosts would = accept in IPv6 packets BOTH IPv6 ICMP messages and ICMPv4 = messages.

Yet, it remains to be analyzed = whether it would be useful in real world.

This = depends on a detailed use case being identified, where double RFC6145 = translation would have a substantial advantage over the header-mapping = variant of 4rd-U-03 (4rd-H). (This advantage would have to compensate = for the loss of IPv4 transparency as good as that of 4rd-E, and for the = loss of the tunnel-specific traffic class which can be used in = 4rd-E.) 

This use case, key for this = discussion, is subject of another e-mail = thread.

RD


<= /html>= --Apple-Mail-97--171986897-- From despres.remi@laposte.net Thu Feb 2 01:32:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3070721F85D8 for ; Thu, 2 Feb 2012 01:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKD-wz9b0lyA for ; Thu, 2 Feb 2012 01:32:23 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D621F85D6 for ; Thu, 2 Feb 2012 01:32:21 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1179594023D; Thu, 2 Feb 2012 10:32:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-98--171900794 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 2 Feb 2012 10:32:13 +0100 Message-Id: <96370448-0F56-4C0A-9AEB-86BFEED319D0@laposte.net> References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] 4via6 use case where compatibility with single translation would be useful? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:32:24 -0000 --Apple-Mail-98--171900794 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-01 =E0 03:04, Maoke a =E9crit : > 2012/1/30 R=E9mi Despr=E9s ... > Could you, for the sake of a less abstract discussion, describe at = least one configuration you have in mind, ... > to my best understanding, one of the merits of the translation = approach is: when an end system changes its stack from ipv4 to ipv6, as = long as the ipv4-translatable ipv6 address is applied, its peers in the = past can keep using the same ipv4 address (as the temporal-unique = identifier) to have access to it. ... > i think this is a clear-enough use-case but if i still make any = confusion, i may draw some pictures for you offline.=20 This discussion IMHO deserves to remain online. Could you, for this use case: - indicate applicable mapping rules=20 - clarify whether there is a NAT64 or not (pictures don't seem necessary at this stage)=20 We should be able to analyze what is won and what is lost compared to = other solutions. Regards, RD --Apple-Mail-98--171900794 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
2012/1/30 = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
...
Could you, for the sake of = a less abstract discussion, describe at least one configuration you have = in = mind,
...
to my best understanding, = one of the merits of the translation approach is: when an end system = changes its stack from ipv4 to ipv6, as long as the ipv4-translatable = ipv6 address is applied, its peers in the past can keep using the same = ipv4 address (as the temporal-unique identifier) to have access to = it.
...
i think this is a clear-enough use-case but if i still make any = confusion, i may draw some pictures for you = offline. 

This discussion = IMHO deserves to remain online.
Could you, for this use = case:
- indicate applicable mapping rules 
- = clarify whether there is a NAT64 or not
(pictures don't seem = necessary at this stage) 

We should be = able to analyze what is won and what is lost compared to other = solutions.

Regards,
RD

= = --Apple-Mail-98--171900794-- From ichiroumakino@gmail.com Thu Feb 2 02:12:07 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0521F8A6D for ; Thu, 2 Feb 2012 02:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV5bD5YilnBT for ; Thu, 2 Feb 2012 02:12:07 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDB4B21F8A6B for ; Thu, 2 Feb 2012 02:12:06 -0800 (PST) Received: by werm10 with SMTP id m10so2049537wer.31 for ; Thu, 02 Feb 2012 02:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=I+zyfm/YCJjNO8DcZYREKkqFwCrFRcIGn5QAZwe/w6s=; b=nyoWv7JB4sVizkHOvqkIykGNKqgQGdW4uQl6UZ1VMneuluTHFKKu0tYh62Ozmj0Ism Cwdu24jTvD0J5b0vckdyEbM04N1nET03J8bD2flMnyn/pS4c7nGdNb4Bh1IBnSh7JBvP Y6jt2f4eTi3O/Tp2AGKGmXzQM3T2xlgx/PzoE= Received: by 10.216.139.87 with SMTP id b65mr804375wej.59.1328177525904; Thu, 02 Feb 2012 02:12:05 -0800 (PST) Received: from [10.147.13.173] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id m8sm5696931wia.11.2012.02.02.02.12.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 02:12:05 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 2 Feb 2012 11:12:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> References: To: softwires WG X-Mailer: Apple Mail (2.1251.1) Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 10:12:07 -0000 > More over, 4rd-U claims to solves a number of issues that the MAP = suite of documents does not address. It would be beneficial to have > a discussion on the mailing list to see if a) those issues are = important or not and b), if they are, are they properties of 4rd-U or = could they be solved as well > in MAP, they just have not been addressed there yet. here is a comparison table of the feature differences between MAP and = 4rd-U. (try a fixed width font if it doesn't survive your particular MUA mail = mangling algorithm.) Appendix A. Comparions of stateless A+P solutions +-------------------------------+----------------+------------------+ | Feature | MAP | 4rd-U | +-------------------------------+----------------+------------------+ | Encapsulation | Y | Y | | Translation | Y | Y | | Hub and Spoke mode | Y | Y | | Nested CPE | N | Y | | End-user prefixes > 64 | Y | N | | E-mode: Support for IPv4 | Y | N | | options | | | | T-mode: MF bit and TOS bits | N | Y | | transparency | | | | T-mode: Checksum | L4 rewrite | CNP | | H & S set bit 79 needed | N | Y | | Interface-id | RFC6052 | V octet | | MAP traffic identified by | Address/prefix | Interception of | | | | V octet | | Port mapping algorithm | GMA. Prog. | GMA. Fixed | | Fragment forwarding on BR | N | Y | | without reassembly | | | | Shared fragmentation id space | N | Y | | BR rewrite fragmentation | N | Y | | MSS update | Y | N | | Complete IPv6 address / | Y | N | | prefix | | | | Provisioned with DHCP | Y | Y | +-------------------------------+----------------+------------------+ Table 1: A+P comparison let us make it clear that these two solutions are solving exactly the = same problem, and they solve it in the same fundamental way (A+P). the = differences we're talking about here are what whistles, bells (and = dongs) we want to add on to the base specification. consider it a = buffet, any feature from one of them can be applied to the other. cheers, Ole= From fibrib@gmail.com Thu Feb 2 03:00:07 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396A121F8A9A for ; Thu, 2 Feb 2012 03:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X6Xa6eE1mpx for ; Thu, 2 Feb 2012 03:00:06 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05C0821F8A96 for ; Thu, 2 Feb 2012 02:59:59 -0800 (PST) Received: by qcsg13 with SMTP id g13so1510635qcs.31 for ; Thu, 02 Feb 2012 02:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G/KVxLxSuvOYLL7+pqBLW+IrDCNsJbXwMtbeZhlgLlo=; b=qEFusqPqmkicCwaHR42HvYq11yWY7naz7+INoqB0SEant0sgClwNOt1iN86lZpJLWq z8kksZHaZS+XhSIgtyVn74cuKmKJp/mC0t5/nwiypC6Hy6LzKvzea+grk9Rzf+p75DAD RhmeE7tNWR6ZYK4RlQS3hC5RliFCFEYOaE+ko= MIME-Version: 1.0 Received: by 10.229.75.137 with SMTP id y9mr730048qcj.123.1328180399485; Thu, 02 Feb 2012 02:59:59 -0800 (PST) Received: by 10.229.211.72 with HTTP; Thu, 2 Feb 2012 02:59:59 -0800 (PST) In-Reply-To: <23CE9B9D-5469-4537-B4D8-607834D13EBF@laposte.net> References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> <23CE9B9D-5469-4537-B4D8-607834D13EBF@laposte.net> Date: Thu, 2 Feb 2012 19:59:59 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235429d794e8b56104b7f9180e Cc: Softwires WG Subject: Re: [Softwires] No change to RFC6145 needed for 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 11:00:07 -0000 --00235429d794e8b56104b7f9180e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, sorry but your change of the title of this thread is misleading. i mean: no change to RFC6145 needed for practice of operation. my observation on the ICMP transparency of RFC6145 in double translation is relatively independent, without much relationship to 4rd-U. well, the only connection is: 4rd-U REQUIRES IPv6 carrying ICMPv4 messages without translation. 2012/2/2 R=E9mi Despr=E9s > > Le 2012-02-01 =E0 03:04, Maoke a =E9crit : > > ... > > i have investigated, technically, what if we had updated RFC6145 with > carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv= 6, > specially for double translation, > > > Introducing ICMPv4 messages in IPv6 packets "instead of" ICMPv6 messages > in RFC6145 would be an incompatible change. > I don't think anyone proposed that. > > What might be envisaged without the same backward incompatibility, is tha= t > IPv6-only hosts would accept in IPv6 packets BOTH IPv6 ICMP messages and > ICMPv4 messages. > > Yet, it remains to be analyzed whether it would be useful in real world. > > This depends on a detailed use case being identified, where double RFC614= 5 > translation would have a substantial advantage over the header-mapping > variant of 4rd-U-03 (4rd-H). (This advantage would have to compensate for > the loss of IPv4 transparency as good as that of 4rd-E, and for the loss = of > the tunnel-specific traffic class which can be used in 4rd-E.) > > This use case, key for this discussion, is subject of another e-mail > thread. > i (and others) have tested the single/double-compatibility in practice and confirmed it is useful at least for some users. another mail thread might fall into pure philosophical debate, which is not preferred, especially considering that carrying ICMPv4 in IPv6 is not secure. in other words, even if the philosopher had thought the compatibility with single translation was useless, he'd better not to deploy the IPv6 network carrying ICMPv4 payload without IPv4 header encapsulated. - maoke > > RD > --00235429d794e8b56104b7f9180e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,

sorry but your change of the titl= e of this thread is misleading. i mean: no change to RFC6145 needed for pra= ctice of operation. my observation on the ICMP transparency of RFC6145 in d= ouble translation is relatively independent, without much relationship to 4= rd-U. well, the only connection is: 4rd-U REQUIRES IPv6 carrying ICMPv4 mes= sages without translation.=A0

2012/2/2 R=E9mi Despr=E9s <despres.remi@laposte.= net>

Le 2012-02-01 =E0 03:04, = Maoke a =E9crit :
...

i have investiga= ted, technically, what if we had updated RFC6145 with carrying ICMPv4 messa= ges in IPv6 directly instead of translating to ICMPv6, specially for double= translation,

Introducing ICMPv4 messages in IPv6 = packets "instead of" ICMPv6 messages in RFC6145 would be an incom= patible change.=A0
I don't think anyone proposed that.
=A0
What might be envisaged without the same backward incomp= atibility, is that IPv6-only hosts would accept=A0in IPv6 packets BOTH IPv6= =A0ICMP messages and ICMPv4 messages.

Yet, it rema= ins to be analyzed whether it would be useful in real world.

This depends on a detailed use case being identified, w= here double RFC6145 translation would have a substantial advantage over the= header-mapping variant of 4rd-U-03 (4rd-H). (This advantage would have to = compensate for the loss of IPv4 transparency as good as that of 4rd-E, and = for the loss of the tunnel-specific traffic class which can be used in 4rd-= E.)=A0

This use case, key for this discussion, is subject of a= nother=A0e-mail thread.

i= (and others) have tested the single/double-compatibility in practice and c= onfirmed it is useful at least for some users. another mail thread might fa= ll into pure philosophical debate, which is not preferred, especially consi= dering that carrying ICMPv4 in IPv6 is not secure. in other words, even if = the philosopher had thought the compatibility with single translation was u= seless, he'd better not to deploy the IPv6 network carrying ICMPv4 payl= oad without IPv4 header encapsulated.=A0

- maoke=A0
=A0

RD

--00235429d794e8b56104b7f9180e-- From mark@townsley.net Thu Feb 2 05:49:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7E21F88A3 for ; Thu, 2 Feb 2012 05:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvKlWujKFLdY for ; Thu, 2 Feb 2012 05:49:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA38821F88A1 for ; Thu, 2 Feb 2012 05:49:08 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so1944309wgb.13 for ; Thu, 02 Feb 2012 05:49:07 -0800 (PST) Received: by 10.180.24.202 with SMTP id w10mr4704018wif.9.1328190547920; Thu, 02 Feb 2012 05:49:07 -0800 (PST) Received: from ams-townsley-8715.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l6sm51716810wiv.11.2012.02.02.05.49.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 05:49:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-46--156490952 From: Mark Townsley In-Reply-To: <23CE9B9D-5469-4537-B4D8-607834D13EBF@laposte.net> Date: Thu, 2 Feb 2012 14:49:03 +0100 Message-Id: References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> <23CE9B9D-5469-4537-B4D8-607834D13EBF@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] No change to RFC6145 needed for 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 13:49:09 -0000 --Apple-Mail-46--156490952 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 2, 2012, at 10:30 AM, R=E9mi Despr=E9s wrote: >=20 > Le 2012-02-01 =E0 03:04, Maoke a =E9crit : >> ... >>=20 >> i have investigated, technically, what if we had updated RFC6145 with = carrying ICMPv4 messages in IPv6 directly instead of translating to = ICMPv6, specially for double translation, As I watch double-translation slowly morph into tunnel encapsulation one = step at a time right before my eyes.... - Mark --Apple-Mail-46--156490952 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Le = 2012-02-01 =E0 03:04, Maoke a =E9crit :
...

i have = investigated, technically, what if we had updated RFC6145 with carrying = ICMPv4 messages in IPv6 directly instead of translating to ICMPv6, = specially for double = translation,

As I watch double-translation slowly morph into tunnel encapsulation = one step at a time right before my eyes....

- = Mark

= --Apple-Mail-46--156490952-- From despres.remi@laposte.net Thu Feb 2 07:56:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3EA21F85B1 for ; Thu, 2 Feb 2012 07:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoG8ZzNgJ9iV for ; Thu, 2 Feb 2012 07:56:25 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E973621F8577 for ; Thu, 2 Feb 2012 07:56:22 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0B65794020F; Thu, 2 Feb 2012 16:56:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> Date: Thu, 2 Feb 2012 16:56:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 15:56:25 -0000 Hi Ole, This kind of table you have below is IMHO the tool we need at this stage = :-). It has however to be more detailed: so far, it covers 4rd-H (the = header-mapping variant of the last 4rd-U), but not 4rd-E (its = encapsulation variant). A 4 columns table would be ideal. Also, It could have a sign identifying = points that are N in current drafts, but could easily become Y if the = final consensus is that they are worth the additional complexity. I can work on it if you are interested. More specific points below. They can be discussed one by one. Le 2012-02-02 =E0 11:12, Ole Tr=F8an a =E9crit : >> More over, 4rd-U claims to solves a number of issues that the MAP = suite of documents does not address. It would be beneficial to have >> a discussion on the mailing list to see if a) those issues are = important or not and b), if they are, are they properties of 4rd-U or = could they be solved as well >> in MAP, they just have not been addressed there yet. >=20 > here is a comparison table of the feature differences between MAP and = 4rd-U. > (try a fixed width font if it doesn't survive your particular MUA mail = mangling algorithm.) >=20 > Appendix A. Comparions of stateless A+P solutions >=20 > +-------------------------------+----------------+------------------+ > | Feature | MAP | 4rd-U | > +-------------------------------+----------------+------------------+ > | Encapsulation | Y | Y | > | Translation | Y | Y | > | Hub and Spoke mode | Y | Y | > | Nested CPE | N | Y | > | End-user prefixes > 64 | Y | N | (1)It is AFAIK also a "Y" for 4rd. (Not sure to understand the point.) > | E-mode: Support for IPv4 | Y | N | > | options | | | (2) 4rd-U draft 03 has excluded IPv4 options for both 4rd-H and 4rd-E = but, for 4rd-E, they can easily be put back if found useful. (My vote is = NO, but a WG consensus on YES for 4rd-E would not be a problem at all). > | T-mode: MF bit and TOS bits | N | Y | > | transparency | | | > | T-mode: Checksum | L4 rewrite | CNP | (3) The functional point is guaranteeing IPv4-payload preservation, with = compatibility with ALL protocols using TCP-like checksum, present of = future, with checksums anywhere in the payload.=20 > | H & S set bit 79 needed | N | Y | (4) The functional point is to permit use cases like that of 5.3 of the = last 4rd-U draft. The added complexity for this is close to nil, and applies ONLY to H&S = scenarios. If abandoned (which is easy), it should be with due WG consciousness of = which use cases are thus abandoned. > | Interface-id | RFC6052 | V octet | > | MAP traffic identified by | Address/prefix | Interception of | > | | | V octet | (5) The main functional point of the V octet is to avoid interfering = with subnet assignments in customer sites. (6) Not sure to understand what you mean by "Interception of V octet". = IPv6 routing within CEs or BRs is sufficient to orient IPv6 packets to = the 4rd function. > | Port mapping algorithm | GMA. Prog. | GMA. Fixed | (7) Substantial complexity added for GMA isn't justified, in my = understanding, by real use cases that would need it.=20 This could easily be added to 4rd-U if so decides the WG (a waste IMHO). > | Fragment forwarding on BR | N | Y | > | without reassembly | | | > | Shared fragmentation id space | N | Y | > | BR rewrite fragmentation | N | Y | > | MSS update | Y | N | (8) I found no reference to MSS in MAP-E, and no reference to MSS update = in MAP-T. Did I miss them? > | Complete IPv6 address / | Y | N | > | prefix | | | (9) Not sure what you mean by a complete IPv6 prefix. I see no = functional limitation of 4rd-U with prefix lengths. > | Provisioned with DHCP | Y | Y | > +-------------------------------+----------------+------------------+ >=20 > Table 1: A+P comparison Cheers, RD >=20 > let us make it clear that these two solutions are solving exactly the = same problem, and they solve it in the same fundamental way (A+P). the = differences we're talking about here are what whistles, bells (and = dongs) we want to add on to the base specification. consider it a = buffet, any feature from one of them can be applied to the other. >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From adurand@juniper.net Thu Feb 2 09:37:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867D121F8525 for ; Thu, 2 Feb 2012 09:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.139 X-Spam-Level: X-Spam-Status: No, score=-106.139 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+xNTICnBoja for ; Thu, 2 Feb 2012 09:37:29 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5EF21F851C for ; Thu, 2 Feb 2012 09:37:27 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTyrJ1Dj7szHRj7m9jJWHyb8xqtngMGZ1@postini.com; Thu, 02 Feb 2012 09:37:29 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Feb 2012 09:35:09 -0800 From: Alain Durand To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= Date: Thu, 2 Feb 2012 09:35:08 -0800 Thread-Topic: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U Thread-Index: Aczh0QJbyQrxU/MASwyi3FjHeOpG8A== Message-ID: <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> In-Reply-To: <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 17:37:30 -0000 UGxlYXNlLCBSZW1pLCBkbyBidWlsZCBzdWNoIGEgdGFibGUhIFRoYXQgd291bGQgYmUgdmVyeSB1 c2VmdWwuDQoNCkFsYWluLg0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQpPbiBGZWIgMiwgMjAxMiwg YXQgMTA6NTYgQU0sICJSw6ltaSBEZXNwcsOpcyIgPGRlc3ByZXMucmVtaUBsYXBvc3RlLm5ldD4g d3JvdGU6DQoNCj4gSGkgT2xlLA0KPiANCj4gVGhpcyBraW5kIG9mIHRhYmxlIHlvdSBoYXZlIGJl bG93IGlzIElNSE8gdGhlIHRvb2wgd2UgbmVlZCBhdCB0aGlzIHN0YWdlIDotKS4NCj4gDQo+IEl0 IGhhcyBob3dldmVyIHRvIGJlIG1vcmUgZGV0YWlsZWQ6IHNvIGZhciwgaXQgY292ZXJzIDRyZC1I ICh0aGUgaGVhZGVyLW1hcHBpbmcgdmFyaWFudCBvZiB0aGUgbGFzdCA0cmQtVSksIGJ1dCBub3Qg NHJkLUUgKGl0cyBlbmNhcHN1bGF0aW9uIHZhcmlhbnQpLg0KPiBBIDQgY29sdW1ucyB0YWJsZSB3 b3VsZCBiZSBpZGVhbC4gQWxzbywgSXQgY291bGQgaGF2ZSBhIHNpZ24gaWRlbnRpZnlpbmcgcG9p bnRzIHRoYXQgYXJlIE4gaW4gY3VycmVudCBkcmFmdHMsIGJ1dCAgY291bGQgZWFzaWx5IGJlY29t ZSBZIGlmIHRoZSBmaW5hbCBjb25zZW5zdXMgaXMgdGhhdCB0aGV5IGFyZSB3b3J0aCB0aGUgYWRk aXRpb25hbCBjb21wbGV4aXR5Lg0KPiBJIGNhbiB3b3JrIG9uIGl0IGlmIHlvdSBhcmUgaW50ZXJl c3RlZC4NCj4gDQo+IE1vcmUgc3BlY2lmaWMgcG9pbnRzIGJlbG93Lg0KPiBUaGV5IGNhbiBiZSBk aXNjdXNzZWQgb25lIGJ5IG9uZS4NCj4gDQo+IA0KPiBMZSAyMDEyLTAyLTAyIMOgIDExOjEyLCBP bGUgVHLDuGFuIGEgw6ljcml0IDoNCj4gDQo+Pj4gTW9yZSBvdmVyLCA0cmQtVSBjbGFpbXMgdG8g c29sdmVzIGEgbnVtYmVyIG9mIGlzc3VlcyB0aGF0IHRoZSBNQVAgc3VpdGUgb2YgZG9jdW1lbnRz IGRvZXMgbm90IGFkZHJlc3MuIEl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gaGF2ZQ0KPj4+IGEg ZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0ICB0byBzZWUgaWYgYSkgdGhvc2UgaXNzdWVz IGFyZSBpbXBvcnRhbnQgb3Igbm90IGFuZCBiKSwgaWYgdGhleSBhcmUsIGFyZSB0aGV5IHByb3Bl cnRpZXMgb2YgNHJkLVUgb3IgY291bGQgdGhleSBiZSBzb2x2ZWQgYXMgd2VsbA0KPj4+IGluIE1B UCwgdGhleSBqdXN0IGhhdmUgbm90IGJlZW4gYWRkcmVzc2VkIHRoZXJlIHlldC4NCj4+IA0KPj4g aGVyZSBpcyBhIGNvbXBhcmlzb24gdGFibGUgb2YgdGhlIGZlYXR1cmUgZGlmZmVyZW5jZXMgYmV0 d2VlbiBNQVAgYW5kIDRyZC1VLg0KPj4gKHRyeSBhIGZpeGVkIHdpZHRoIGZvbnQgaWYgaXQgZG9l c24ndCBzdXJ2aXZlIHlvdXIgcGFydGljdWxhciBNVUEgbWFpbCBtYW5nbGluZyBhbGdvcml0aG0u KQ0KPj4gDQo+PiBBcHBlbmRpeCBBLiAgQ29tcGFyaW9ucyBvZiBzdGF0ZWxlc3MgQStQIHNvbHV0 aW9ucw0KPj4gDQo+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+IHwgRmVhdHVyZSAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICBNQVAgICAgICB8ICAgICAgIDRyZC1VICAgICAgfA0KPj4gKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0rDQo+PiB8IEVuY2Fwc3VsYXRpb24gICAgICAgICAgICAgICAgIHwgICAgICAgIFkgICAgICAg fCAgICAgICAgIFkgICAgICAgIHwNCj4+IHwgVHJhbnNsYXRpb24gICAgICAgICAgICAgICAgICAg fCAgICAgICAgWSAgICAgICB8ICAgICAgICAgWSAgICAgICAgfA0KPj4gfCBIdWIgYW5kIFNwb2tl IG1vZGUgICAgICAgICAgICB8ICAgICAgICBZICAgICAgIHwgICAgICAgICBZICAgICAgICB8DQo+ PiB8IE5lc3RlZCBDUEUgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIE4gICAgICAgfCAgICAg ICAgIFkgICAgICAgIHwNCj4+IHwgRW5kLXVzZXIgcHJlZml4ZXMgPiA2NCAgICAgICAgfCAgICAg ICAgWSAgICAgICB8ICAgICAgICAgTiAgICAgICAgfA0KPiANCj4gKDEpSXQgaXMgQUZBSUsgYWxz byBhICJZIiBmb3IgNHJkLg0KPiAoTm90IHN1cmUgdG8gdW5kZXJzdGFuZCB0aGUgcG9pbnQuKQ0K PiANCj4+IHwgRS1tb2RlOiBTdXBwb3J0IGZvciBJUHY0ICAgICAgfCAgICAgICAgWSAgICAgICB8 ICAgICAgICAgTiAgICAgICAgfA0KPj4gfCBvcHRpb25zICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8DQo+IA0KPiAoMikgNHJkLVUgZHJh ZnQgMDMgaGFzIGV4Y2x1ZGVkIElQdjQgb3B0aW9ucyBmb3IgYm90aCA0cmQtSCBhbmQgNHJkLUUg YnV0LCBmb3IgNHJkLUUsIHRoZXkgY2FuIGVhc2lseSBiZSBwdXQgYmFjayBpZiBmb3VuZCB1c2Vm dWwuIChNeSB2b3RlIGlzIE5PLCBidXQgYSBXRyBjb25zZW5zdXMgb24gWUVTIGZvciA0cmQtRSB3 b3VsZCBub3QgYmUgYSBwcm9ibGVtIGF0IGFsbCkuDQo+IA0KPiANCj4+IHwgVC1tb2RlOiBNRiBi aXQgYW5kIFRPUyBiaXRzICAgfCAgICAgICAgTiAgICAgICB8ICAgICAgICAgWSAgICAgICAgfA0K Pj4gfCB0cmFuc3BhcmVuY3kgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICB8DQo+PiB8IFQtbW9kZTogQ2hlY2tzdW0gICAgICAgICAgICAgIHwgICBM NCByZXdyaXRlICAgfCAgICAgICAgQ05QICAgICAgIHwNCj4gDQo+ICgzKSBUaGUgZnVuY3Rpb25h bCBwb2ludCBpcyBndWFyYW50ZWVpbmcgSVB2NC1wYXlsb2FkIHByZXNlcnZhdGlvbiwgd2l0aCBj b21wYXRpYmlsaXR5IHdpdGggQUxMIHByb3RvY29scyB1c2luZyBUQ1AtbGlrZSBjaGVja3N1bSwg cHJlc2VudCBvZiBmdXR1cmUsIHdpdGggY2hlY2tzdW1zIGFueXdoZXJlIGluIHRoZSBwYXlsb2Fk LiANCj4gDQo+PiB8IEggJiBTIHNldCBiaXQgNzkgbmVlZGVkICAgICAgIHwgICAgICAgIE4gICAg ICAgfCAgICAgICAgIFkgICAgICAgIHwNCj4gDQo+ICg0KSBUaGUgZnVuY3Rpb25hbCBwb2ludCBp cyB0byBwZXJtaXQgdXNlIGNhc2VzIGxpa2UgdGhhdCBvZiA1LjMgb2YgdGhlIGxhc3QgNHJkLVUg ZHJhZnQuDQo+IFRoZSBhZGRlZCBjb21wbGV4aXR5IGZvciB0aGlzIGlzIGNsb3NlIHRvIG5pbCwg YW5kIGFwcGxpZXMgT05MWSB0byBIJlMgc2NlbmFyaW9zLg0KPiANCj4gSWYgYWJhbmRvbmVkICh3 aGljaCBpcyBlYXN5KSwgaXQgc2hvdWxkIGJlIHdpdGggZHVlIFdHIGNvbnNjaW91c25lc3Mgb2Yg IHdoaWNoIHVzZSBjYXNlcyBhcmUgdGh1cyBhYmFuZG9uZWQuDQo+IA0KPiANCj4+IHwgSW50ZXJm YWNlLWlkICAgICAgICAgICAgICAgICAgfCAgICAgUkZDNjA1MiAgICB8ICAgICAgViBvY3RldCAg ICAgfA0KPj4gfCBNQVAgdHJhZmZpYyBpZGVudGlmaWVkIGJ5ICAgICB8IEFkZHJlc3MvcHJlZml4 IHwgIEludGVyY2VwdGlvbiBvZiB8DQo+PiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgfCAgICAgIFYgb2N0ZXQgICAgIHwNCj4gDQo+ICg1KSBUaGUgbWFp biBmdW5jdGlvbmFsIHBvaW50IG9mIHRoZSBWIG9jdGV0IGlzIHRvIGF2b2lkIGludGVyZmVyaW5n IHdpdGggc3VibmV0IGFzc2lnbm1lbnRzIGluIGN1c3RvbWVyIHNpdGVzLg0KPiAoNikgTm90IHN1 cmUgdG8gdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGJ5ICJJbnRlcmNlcHRpb24gb2YgViBvY3Rl dCIuIElQdjYgcm91dGluZyB3aXRoaW4gQ0VzIG9yIEJScyBpcyBzdWZmaWNpZW50IHRvIG9yaWVu dCBJUHY2IHBhY2tldHMgdG8gdGhlIDRyZCBmdW5jdGlvbi4NCj4gDQo+PiB8IFBvcnQgbWFwcGlu ZyBhbGdvcml0aG0gICAgICAgIHwgICBHTUEuIFByb2cuICAgfCAgICBHTUEuIEZpeGVkICAgIHwN Cj4gDQo+ICg3KSAgU3Vic3RhbnRpYWwgY29tcGxleGl0eSBhZGRlZCBmb3IgR01BIGlzbid0IGp1 c3RpZmllZCwgaW4gbXkgdW5kZXJzdGFuZGluZywgYnkgcmVhbCB1c2UgY2FzZXMgdGhhdCB3b3Vs ZCBuZWVkIGl0LiANCj4gVGhpcyBjb3VsZCBlYXNpbHkgYmUgYWRkZWQgdG8gNHJkLVUgaWYgc28g ZGVjaWRlcyB0aGUgV0cgKGEgd2FzdGUgSU1ITykuDQo+IA0KPj4gfCBGcmFnbWVudCBmb3J3YXJk aW5nIG9uIEJSICAgICB8ICAgICAgICBOICAgICAgIHwgICAgICAgICBZICAgICAgICB8DQo+PiB8 IHdpdGhvdXQgcmVhc3NlbWJseSAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgIHwNCj4+IHwgU2hhcmVkIGZyYWdtZW50YXRpb24gaWQgc3BhY2UgfCAgICAgICAg TiAgICAgICB8ICAgICAgICAgWSAgICAgICAgfA0KPj4gfCBCUiByZXdyaXRlIGZyYWdtZW50YXRp b24gICAgICB8ICAgICAgICBOICAgICAgIHwgICAgICAgICBZICAgICAgICB8DQo+IA0KPiANCj4+ IHwgTVNTIHVwZGF0ZSAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgWSAgICAgICB8ICAgICAg ICAgTiAgICAgICAgfA0KPiANCj4gKDgpIEkgZm91bmQgbm8gcmVmZXJlbmNlIHRvIE1TUyBpbiBN QVAtRSwgYW5kIG5vIHJlZmVyZW5jZSB0byBNU1MgdXBkYXRlIGluIE1BUC1ULg0KPiBEaWQgSSBt aXNzIHRoZW0/DQo+IA0KPj4gfCBDb21wbGV0ZSBJUHY2IGFkZHJlc3MgLyAgICAgICB8ICAgICAg ICBZICAgICAgIHwgICAgICAgICBOICAgICAgICB8DQo+PiB8IHByZWZpeCAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwNCj4gDQo+ICg5 KSBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IGEgY29tcGxldGUgSVB2NiBwcmVmaXguIEkgc2Vl IG5vIGZ1bmN0aW9uYWwgbGltaXRhdGlvbiBvZiA0cmQtVSB3aXRoIHByZWZpeCBsZW5ndGhzLg0K PiANCj4+IHwgUHJvdmlzaW9uZWQgd2l0aCBESENQICAgICAgICAgfCAgICAgICAgWSAgICAgICB8 ICAgICAgICAgWSAgICAgICAgfA0KPj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiANCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgVGFibGUgMTogQStQIGNvbXBhcmlzb24NCj4gDQo+IA0KPiBDaGVlcnMsDQo+ IFJEDQo+IA0KPiANCj4+IA0KPj4gbGV0IHVzIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGVzZSB0d28g c29sdXRpb25zIGFyZSBzb2x2aW5nIGV4YWN0bHkgdGhlIHNhbWUgcHJvYmxlbSwgYW5kIHRoZXkg c29sdmUgaXQgaW4gdGhlIHNhbWUgZnVuZGFtZW50YWwgd2F5IChBK1ApLiB0aGUgZGlmZmVyZW5j ZXMgd2UncmUgdGFsa2luZyBhYm91dCBoZXJlIGFyZSB3aGF0IHdoaXN0bGVzLCBiZWxscyAoYW5k IGRvbmdzKSB3ZSB3YW50IHRvIGFkZCBvbiB0byB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uLiBjb25z aWRlciBpdCBhIGJ1ZmZldCwgYW55IGZlYXR1cmUgZnJvbSBvbmUgb2YgdGhlbSBjYW4gYmUgYXBw bGllZCB0byB0aGUgb3RoZXIuDQo+PiANCj4+IGNoZWVycywNCj4+IE9sZQ0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFNvZnR3aXJlcyBtYWls aW5nIGxpc3QNCj4+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4gU29m dHdpcmVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c29mdHdpcmVzDQo= From xing@cernet.edu.cn Thu Feb 2 18:13:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1018621F850C for ; Thu, 2 Feb 2012 18:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.902 X-Spam-Level: X-Spam-Status: No, score=-98.902 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onbjjlfYV4ah for ; Thu, 2 Feb 2012 18:13:04 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8A21F8504 for ; Thu, 2 Feb 2012 18:13:03 -0800 (PST) Received: from [127.0.0.1] (unknown [223.198.205.58]) by centos (Coremail) with SMTP id AQAAf3DbAAMeQitPVpcHAA--.33008S2; Fri, 03 Feb 2012 10:10:39 +0800 (CST) Message-ID: <4F2B42AA.30200@cernet.edu.cn> Date: Fri, 03 Feb 2012 10:12:58 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: =?UTF-8?B?T2xlIFRyw7hhbg==?= References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3DbAAMeQitPVpcHAA--.33008S2 X-Coremail-Antispam: 1UD129KBjvJXoW7AFy7Gw1UWryUXF1DGryxAFb_yoW8KFy3pr W0kw12kFnxAr1Iyw18Zw1Fvr1Fvrs5JrW3Ja45tr4ku345Ga48Kr47t34Y9ayUur4rZF1j vrWqkFy5Ca1DZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28EF7xvwVC0I7IYx2 IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E 87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzx vE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU GVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI4 8JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWU JVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7V AKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j 6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8Jw CI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07beJ5wUUUUU = X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 02:13:05 -0000 于 2012/2/1 22:33, Ole Trøan 写é“: > Mark, > >> While I appreciate the functional modularity in understanding the solution space, I do wish that DT had come up with a way to make this one document to present to the world rather than four. I fear organ rejection when tossing a list of RFCs for one function to the CPE industry. >> >> In current form, each document has more or less than 10 pages of substantive text, with considerable overlap between them (how many "framework" and "architecture" sections do we really need for what are really just two variants of something 95% the same?). As further evidence of the problem, there are no less than 19 references to mdt-softwire-mapping-address-and-port from draft-mdt-softwire-map-translation-00. One page has 5 references alone. It's is like reading a single book with every other page in a different binding. >> >> Could we not eliminate the overlap, and just boil this down to one less than 40 page document? In fact, I bet if you tried you could get it down to half that. Looks like Remi's new document is on the right track in this regard. >> >> I'm in favor of the chairs stating that we will adopt a WG document based on the text in these documents, but I would like to see a stipulation that they be combined into one (perhaps two but with only the DHCP option separate) and the overlap eliminated among MAP, T and E eliminated. > with regards to document organization we've been over that a few times. my understanding of the Beijing interim meeting was to have the organization of documents we have now. largely because there were discussions on different document status for the different documents. e.g. experimental versus standards track. > > yes, it is certainly possible to merge the 3 documents (MAP, T, E), with separate sections that only apply to encapsulation and some that apply to translation. what I feat is that you will pollute the text with lots of "does not apply in the translation case", "fragmentation issues are slightly different", and so on. > > this is obviously something the working group has to decide on, but I don't think that needs to be done before adopting this document set. I agree with Ole. Regards, xing > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Fri Feb 3 02:15:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB4921F85D4 for ; Fri, 3 Feb 2012 02:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVMRH9dMqBXO for ; Fri, 3 Feb 2012 02:15:48 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id EA48E21F85D1 for ; Fri, 3 Feb 2012 02:15:44 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id A7E649401B8; Fri, 3 Feb 2012 11:15:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-105--82898252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 3 Feb 2012 11:15:36 +0100 Message-Id: References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> <23CE9B9D-5469-4537-B4D8-607834D13EBF@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] No change to RFC6145 needed for 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 10:15:49 -0000 --Apple-Mail-105--82898252 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-02 =E0 11:59, Maoke a =E9crit : > dear Remi, >=20 > sorry but your change of the title of this thread is misleading. i = mean: no change to RFC6145 needed for practice of operation. my = observation on the ICMP transparency of RFC6145 in double translation is = relatively independent, without much relationship to 4rd-U. > well, the only connection is: 4rd-U REQUIRES IPv6 carrying ICMPv4 = messages without translation.=20 4rd-U is indeed proposed with all IPv4 payloads transparently = transmitted, including ICMPv4. This could be changed if ICMPv4 if there would be a convincing need. Honestly, what you have provided so far hasn't been convincing.=20 > 2012/2/2 R=E9mi Despr=E9s >=20 > Le 2012-02-01 =E0 03:04, Maoke a =E9crit : >> ... >>=20 >> i have investigated, technically, what if we had updated RFC6145 with = carrying ICMPv4 messages in IPv6 directly instead of translating to = ICMPv6, specially for double translation, >=20 > Introducing ICMPv4 messages in IPv6 packets "instead of" ICMPv6 = messages in RFC6145 would be an incompatible change.=20 > I don't think anyone proposed that. > =20 > What might be envisaged without the same backward incompatibility, is = that IPv6-only hosts would accept in IPv6 packets BOTH IPv6 ICMP = messages and ICMPv4 messages. >=20 > Yet, it remains to be analyzed whether it would be useful in real = world. >=20 > This depends on a detailed use case being identified, where double = RFC6145 translation would have a substantial advantage over the = header-mapping variant of 4rd-U-03 (4rd-H). (This advantage would have = to compensate for the loss of IPv4 transparency as good as that of = 4rd-E, and for the loss of the tunnel-specific traffic class which can = be used in 4rd-E.)=20 >=20 > This use case, key for this discussion, is subject of another e-mail = thread. >=20 > i (and others) have tested the single/double-compatibility in practice = and confirmed it is useful at least for some users. I don't deny. I just believe that, to have a chance to be convinced, I = need a description of at least a use case where it is useful (with = applicable mapping rules and indication of whether there is a DNS64). > another mail thread might fall into pure philosophical debate, which = is not preferred, Whatever the thread, I look for a technical discussion, not a = philosophical one. RD =20 > =20 >=20 > - maoke=20 > =20 >=20 > RD >=20 --Apple-Mail-105--82898252 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
dear = Remi,

sorry but your change of the title of = this thread is misleading. i mean: no change to RFC6145 needed for = practice of operation. my observation on the ICMP transparency of = RFC6145 in double translation is relatively independent, without much = relationship to 4rd-U.


well, the only connection is: 4rd-U REQUIRES IPv6 = carrying ICMPv4 messages without = translation. 

4rd-U is = indeed proposed with all IPv4 payloads transparently transmitted, = including ICMPv4.
This could be changed if ICMPv4 if there = would be a convincing need.
Honestly, what you have provided = so far hasn't been convincing. 


2012/2/2 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-02-01 =E0 = 03:04, Maoke a =E9crit :
...

i have investigated, = technically, what if we had updated RFC6145 with carrying ICMPv4 = messages in IPv6 directly instead of translating to ICMPv6, specially = for double translation,

Introducing ICMPv4 messages in = IPv6 packets "instead of" ICMPv6 messages in RFC6145 would be an = incompatible change. 
I don't think anyone proposed = that.
 
What might be envisaged without the same backward = incompatibility, is that IPv6-only hosts would accept in IPv6 = packets BOTH IPv6 ICMP messages and ICMPv4 = messages.

Yet, it remains to be analyzed = whether it would be useful in real world.

This depends on a detailed use case being = identified, where double RFC6145 translation would have a substantial = advantage over the header-mapping variant of 4rd-U-03 (4rd-H). (This = advantage would have to compensate for the loss of IPv4 transparency as = good as that of 4rd-E, and for the loss of the tunnel-specific traffic = class which can be used in 4rd-E.) 

This use case, key for this discussion, is subject = of another e-mail = thread.

i (and others) = have tested the single/double-compatibility in practice and confirmed it = is useful at least for some users. =

I don't deny. I just believe = that, to have a chance to be convinced, I need a description of at least = a use case where it is useful (with applicable mapping rules and = indication of whether there is a = DNS64).

another mail thread might fall into pure = philosophical debate, which is not preferred, =

Whatever the thread, I look = for a technical discussion, not a philosophical = one.

RD


=

 
 

- maoke 
 

RD


= --Apple-Mail-105--82898252-- From ichiroumakino@gmail.com Fri Feb 3 04:25:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2484E21F85D3 for ; Fri, 3 Feb 2012 04:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaVUQiKEzYHt for ; Fri, 3 Feb 2012 04:25:49 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0556A21F85CE for ; Fri, 3 Feb 2012 04:25:48 -0800 (PST) Received: by werm10 with SMTP id m10so3249303wer.31 for ; Fri, 03 Feb 2012 04:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=1m4Xa4gHjaZoSz67oZvN0CqEbhhLNwXgn+bLyEZwROU=; b=qeY2WNX9bYX2wqCkYRCTmoif04/RirIBLamAtdgn6ntii24NXRBvxoWZD0y3GjmDFh +cl2WdrMOo315Mdd4jveIUap1CvyUcdbayvGAZq/7PtjRXtCBhJbcHi4zJy8qHgxSinQ bYsQZwltj02rc9jjNVrvYZZKJHYB9zvHJE8xY= Received: by 10.216.139.79 with SMTP id b57mr6379634wej.22.1328271948054; Fri, 03 Feb 2012 04:25:48 -0800 (PST) Received: from [10.147.13.173] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l8sm16899371wiy.5.2012.02.03.04.25.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 04:25:47 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> Date: Fri, 3 Feb 2012 13:25:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 12:25:50 -0000 Remi, >> here is a comparison table of the feature differences between MAP and = 4rd-U. >> (try a fixed width font if it doesn't survive your particular MUA = mail mangling algorithm.) >>=20 >> Appendix A. Comparions of stateless A+P solutions >>=20 >> = +-------------------------------+----------------+------------------+ >> | Feature | MAP | 4rd-U = | >> = +-------------------------------+----------------+------------------+ >> | Encapsulation | Y | Y = | >> | Translation | Y | Y = | >> | Hub and Spoke mode | Y | Y = | >> | Nested CPE | N | Y = | >> | End-user prefixes > 64 | Y | N = | >=20 > (1)It is AFAIK also a "Y" for 4rd. > (Not sure to understand the point.) I might have misunderstood R-11 and R-24. it depends on the V octet. but I suppose for any solution it is more of a deployment choice than a = inherent limitation to the mechanism. >> | E-mode: Support for IPv4 | Y | N = | >> | options | | = | >=20 > (2) 4rd-U draft 03 has excluded IPv4 options for both 4rd-H and 4rd-E = but, for 4rd-E, they can easily be put back if found useful. (My vote is = NO, but a WG consensus on YES for 4rd-E would not be a problem at all). indeed, part of the smorgasbord of features the working group can choose = between. >> | T-mode: MF bit and TOS bits | N | Y = | >> | transparency | | = | >> | T-mode: Checksum | L4 rewrite | CNP = | >=20 > (3) The functional point is guaranteeing IPv4-payload preservation, = with compatibility with ALL protocols using TCP-like checksum, present = of future, with checksums anywhere in the payload.=20 the MDT recommends L4 rewrite: - this is what existing implementations do - works for any L4 protocol (MAP has to be L4 aware for port anyway) >> | H & S set bit 79 needed | N | Y = | >=20 > (4) The functional point is to permit use cases like that of 5.3 of = the last 4rd-U draft. > The added complexity for this is close to nil, and applies ONLY to H&S = scenarios. >=20 > If abandoned (which is easy), it should be with due WG consciousness = of which use cases are thus abandoned. indeed. >> | Interface-id | RFC6052 | V octet = | >> | MAP traffic identified by | Address/prefix | Interception of = | >> | | | V octet = | >=20 > (5) The main functional point of the V octet is to avoid interfering = with subnet assignments in customer sites. the MDT recommendation is to set aside a prefix or an IPv6 address to = terminate MAP traffic. > (6) Not sure to understand what you mean by "Interception of V octet". = IPv6 routing within CEs or BRs is sufficient to orient IPv6 packets to = the 4rd function. if classification of MAP packets versus native packets have to be done, = not using the best matching prefix algorithm, but a non contiguous mask. = e.g.: a match on: 2001:db8:1234:*:0V00:* >> | Port mapping algorithm | GMA. Prog. | GMA. Fixed = | >=20 > (7) Substantial complexity added for GMA isn't justified, in my = understanding, by real use cases that would need it.=20 > This could easily be added to 4rd-U if so decides the WG (a waste = IMHO). GMA and the 4rd-U algorithm is the same algorithm. with the same bit = representation on the wire. the MAP text goes in more detail in explaining how to calculate the port = ranges and so on. 4rd-U has fixed (a) the offset bits, while MAP has the same default, but = allows it to be configured. >> | Fragment forwarding on BR | N | Y = | >> | without reassembly | | = | >> | Shared fragmentation id space | N | Y = | >> | BR rewrite fragmentation | N | Y = | btw, in 4rd-U did you intend for the BR to rewrite the fragmentation id = on packets to the Internet from the CEs? instead of making the CE use the fragmented fragmentation (sic!) space = directly? I think the fragmentation ideas are well worth considering btw. >> | MSS update | Y | N = | >=20 > (8) I found no reference to MSS in MAP-E, and no reference to MSS = update in MAP-T. > Did I miss them? RFC6145 mentions it at least. I don't think MAP-E should do anything on = MSS, in that case it would be part of the NAT function prior to = encapsulation. >> | Complete IPv6 address / | Y | N = | >> | prefix | | = | >=20 > (9) Not sure what you mean by a complete IPv6 prefix. I see no = functional limitation of 4rd-U with prefix lengths. ah, misspelling. MAP describes how to provision a complete IPv4 address = or IPv4 prefix. (not IPv6 of course). >> | Provisioned with DHCP | Y | Y = | >> = +-------------------------------+----------------+------------------+ >>=20 >> Table 1: A+P comparison >=20 cheers, Ole From despres.remi@laposte.net Fri Feb 3 06:32:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E281721F851B for ; Fri, 3 Feb 2012 06:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPXpCsqo4pAZ for ; Fri, 3 Feb 2012 06:32:57 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id B3C6821F851A for ; Fri, 3 Feb 2012 06:32:54 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 83A41940120; Fri, 3 Feb 2012 15:32:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 3 Feb 2012 15:32:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:32:58 -0000 Le 2012-02-03 =E0 13:25, Ole Tr=F8an a =E9crit : > Remi, >=20 >>> here is a comparison table of the feature differences between MAP = and 4rd-U. >>> (try a fixed width font if it doesn't survive your particular MUA = mail mangling algorithm.) >>>=20 >>> Appendix A. Comparions of stateless A+P solutions >>>=20 >>> = +-------------------------------+----------------+------------------+ >>> | Feature | MAP | 4rd-U = | >>> = +-------------------------------+----------------+------------------+ >>> | Encapsulation | Y | Y = | >>> | Translation | Y | Y = | >>> | Hub and Spoke mode | Y | Y = | >>> | Nested CPE | N | Y = | >>> | End-user prefixes > 64 | Y | N = | >>=20 >> (1)It is AFAIK also a "Y" for 4rd. >> (Not sure to understand the point.) >=20 > I might have misunderstood R-11 and R-24. it depends on the V octet. > but I suppose for any solution it is more of a deployment choice than = a inherent limitation to the mechanism. Unless use cases showing a practical limitation of 4rd-U in this = respect, this line can then be left out. OK? >=20 >>> | E-mode: Support for IPv4 | Y | N = | >>> | options | | = | >>=20 >> (2) 4rd-U draft 03 has excluded IPv4 options for both 4rd-H and 4rd-E = but, for 4rd-E, they can easily be put back if found useful. (My vote is = NO, but a WG consensus on YES for 4rd-E would not be a problem at all). >=20 > indeed, part of the smorgasbord of features the working group can = choose between. The design team is mandated to assemble a particular proposal, and the = WG then decides what to do with it, globally or piece by piece.=20 >>> | T-mode: MF bit and TOS bits | N | Y = | >>> | transparency | | = | >>> | T-mode: Checksum | L4 rewrite | CNP = | >>=20 >> (3) The functional point is guaranteeing IPv4-payload preservation, = with compatibility with ALL protocols using TCP-like checksum, present = of future, with checksums anywhere in the payload.=20 >=20 > the MDT recommends L4 rewrite: > - this is what existing implementations do > - works for any L4 protocol Present or future without change? > (MAP has to be L4 aware for port anyway) >=20 >>> | H & S set bit 79 needed | N | Y = | >>=20 >> (4) The functional point is to permit use cases like that of 5.3 of = the last 4rd-U draft. >> The added complexity for this is close to nil, and applies ONLY to = H&S scenarios. >>=20 >> If abandoned (which is easy), it should be with due WG consciousness = of which use cases are thus abandoned. >=20 > indeed. >=20 >>> | Interface-id | RFC6052 | V octet = | >>> | MAP traffic identified by | Address/prefix | Interception of = | >>> | | | V octet = | >>=20 >> (5) The main functional point of the V octet is to avoid interfering = with subnet assignments in customer sites. >=20 > the MDT recommendation is to set aside a prefix or an IPv6 address to = terminate MAP traffic. Indeed, so that an IPv6 site to which MAP support is added may have to = change its intra-site subnet assignments for this. This is avoided with the V octet. >=20 >> (6) Not sure to understand what you mean by "Interception of V = octet". IPv6 routing within CEs or BRs is sufficient to orient IPv6 = packets to the 4rd function. >=20 > if classification of MAP packets versus native packets have to be = done, not using the best matching prefix algorithm, but a non contiguous = mask. e.g.: >=20 > a match on: > 2001:db8:1234:*:0V00:* (6.a) In BRs or CEs, the first * isn't needed because its value is = fixed so that best matching works. (6.b) In middle boxes, if this is what you discuss, testing the V octet = is sufficient.=20 (6.c) Note that use cases where middle boxes interpret tunnel packets = is the case where MAP-T and 4rd-H have their functional advantages over = MAP-E and 4rd-E.=20 >=20 >>> | Port mapping algorithm | GMA. Prog. | GMA. Fixed = | >>=20 >> (7) Substantial complexity added for GMA isn't justified, in my = understanding, by real use cases that would need it.=20 >> This could easily be added to 4rd-U if so decides the WG (a waste = IMHO). >=20 > GMA and the 4rd-U algorithm is the same algorithm. with the same bit = representation on the wire. - The 4rd-U algorithm is: "A port of the port set contains the PSID, = starting at bit 4. - The MAP algorithm is: "1. The port number (P) of a given PSID (K) is composed of: P =3D R * M = * j + M * K + i Where: * PSID: K =3D 0 to R - 1=20 * Port range index: j =3D (4096 / M) / R to ((65536 / M) / R) - 1, if = the port numbers (0 - 4095) are excluded. * Contiguous Port index: i =3D 0 to M - 1=20 2. The PSID (K) of a given port number (P) is determined by:=20 K =3D (floor(P/M)) % R Where: * % is the modulus operator * floor(arg) is a function that returns the largest integer not = greater than arg." - It has to be faced that this isn't the same algorithm. This difference = is significant because the simpler the algorithm, the simpler is = personnel training, and the simpler if network maintenance.=20 =20 > the MAP text goes in more detail in explaining how to calculate the = port ranges and so on. > 4rd-U has fixed (a) the offset bits, while MAP has the same default, = but allows it to be configured. >=20 >>> | Fragment forwarding on BR | N | Y = | >>> | without reassembly | | = | >>> | Shared fragmentation id space | N | Y = | >>> | BR rewrite fragmentation | N | Y = | >=20 > btw, in 4rd-U did you intend for the BR to rewrite the fragmentation = id on packets to the Internet from the CEs? (6-bis) As explained in the draft, not for packets from ALL CEs. But the 4rd-U draft does propose ID rewrite in BRs for packets from CEs = having shared addresses. Reason, explained in the draft, is that if original IDs are kept = unchanged for shared-address CEs, reassembly may be broken in = destination end points.=20 A discussion of this point, which so far had only been discussed = verbally, is of course welcome. > instead of making the CE use the fragmented fragmentation (sic!) space = directly? Not understood. >=20 > I think the fragmentation ideas are well worth considering btw. >=20 >>> | MSS update | Y | N = | >>=20 >> (8) I found no reference to MSS in MAP-E, and no reference to MSS = update in MAP-T. >> Did I miss them? >=20 > RFC6145 mentions it at least. I don't think MAP-E should do anything = on MSS, in that case it would be part of the NAT function prior to = encapsulation. >=20 >>> | Complete IPv6 address / | Y | N = | >>> | prefix | | = | >>=20 >> (9) Not sure what you mean by a complete IPv6 prefix. I see no = functional limitation of 4rd-U with prefix lengths. >=20 > ah, misspelling. MAP describes how to provision a complete IPv4 = address or IPv4 prefix. (not IPv6 of course). - Sec 5.1 says:=20 "As far as mapping rules are concerned, the simplest deployment model is = that in which the Domain has only one rule (the Default mapping rule). = To assign an IPv4 address to a CE in this model, an IPv6 /112 is = assigned to it comprising the BR /64 prefix, the V octet, a null octet, = and the IPv4 address." Also, the use case of 5.3 uses full IPv4 addresses. I agree however that the text could make it clearer. - A Mapping rule that has Rule IPv4 prefix =3D 0 and EA-bits length < = 32 assigns an IPv4 prefix. Cheers, RD BTW, could you use my e-mail address that works in Softwire, otherwise = my responses get lost. Thanks.=20 >=20 >>> | Provisioned with DHCP | Y | Y = | >>> = +-------------------------------+----------------+------------------+ >>>=20 >>> Table 1: A+P comparison >>=20 >=20 > cheers, > Ole >=20 From ichiroumakino@gmail.com Fri Feb 3 07:00:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A633A21F85F0 for ; Fri, 3 Feb 2012 07:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOFLlOFfjcgH for ; Fri, 3 Feb 2012 07:00:30 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDB221F85CE for ; Fri, 3 Feb 2012 07:00:30 -0800 (PST) Received: by pbdy7 with SMTP id y7so3506352pbd.31 for ; Fri, 03 Feb 2012 07:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=2jpqtUPmu6Ex2qP7IQ3Lh/C/PG2d5cG52QQDscI0N+8=; b=qsvRNIQACj0euUOCwmRxqCORsBxMCZl2kFrht+UZL9t6H0fNV7YmQMsJHc8ef4jOz1 ECOfa9b+OAfxTTshZCwYdBdpS3HJrG+lCmonMg6NXbXtuNIrcfi1FwfzZ+maJxxDtSnh y3t8oJPey1hkH2AiTnVPP8Er5XZeme9tDDp3M= Received: by 10.68.72.70 with SMTP id b6mr18194280pbv.58.1328281230057; Fri, 03 Feb 2012 07:00:30 -0800 (PST) Received: from sjc-vpn7-1336.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id p9sm13633667pbb.9.2012.02.03.07.00.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 07:00:28 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> Date: Fri, 3 Feb 2012 16:00:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: softwires WG Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 15:00:30 -0000 Remi, et al, > This kind of table you have below is IMHO the tool we need at this = stage :-). >=20 > It has however to be more detailed: so far, it covers 4rd-H (the = header-mapping variant of the last 4rd-U), but not 4rd-E (its = encapsulation variant). > A 4 columns table would be ideal. Also, It could have a sign = identifying points that are N in current drafts, but could easily = become Y if the final consensus is that they are worth the additional = complexity. > I can work on it if you are interested. the design team, chartered by the chairs, has delivered its work to the = working group for consideration. the MAP design team did its pick of features that it found useful and = valuable from the veritable smorgasbord of features that have been = suggested. those choices have to a large extent been discussed on the = list. we do not, in my view, have multiple competing solutions, we are rather = discussing different "feature profiles". the MAP design team has proposed one "feature profile" for the working = group. Remi has proposed another. since the design team has finished the work it set out to do, I'd rather = see the feature selection discussion on a working group document. idea: would it be possible to pull out the "feature sections" of 4rd-U = and publish that as a new draft. then with detailed descriptions of the = features, the working group can decide on what should be added or = replaced in the MAP documents? cheers, Ole From ichiroumakino@gmail.com Fri Feb 3 09:45:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245AD21F85A0 for ; Fri, 3 Feb 2012 09:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMtQJhHOxdhR for ; Fri, 3 Feb 2012 09:45:17 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3984A21F8599 for ; Fri, 3 Feb 2012 09:45:17 -0800 (PST) Received: by pbdy7 with SMTP id y7so3637575pbd.31 for ; Fri, 03 Feb 2012 09:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=C4PC+ppnL7WFA9k4tl+OXE3GOXTZ/Ud4CbLFRc3LDQI=; b=VTZEK6MTOBAE9x21Bk8chQkN8c5/kGRYAwF3Xk75cTsQRLrEjrA3B4WUhk8RZPDvK5 ge8XTQKhZ8zVRX3Gl834IGxJi+B7v2IC5S9SE4ODKZrjSlJXtEJh867n0CQ7ArBJ705j UqS0c5kaWwd+wUS7odMxT6lAzGrbvlVoxMrAo= Received: by 10.68.134.103 with SMTP id pj7mr3854192pbb.37.1328291117014; Fri, 03 Feb 2012 09:45:17 -0800 (PST) Received: from sjc-vpn7-1336.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id j5sm14521228pbe.1.2012.02.03.09.45.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 09:45:15 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> Date: Fri, 3 Feb 2012 18:45:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:45:18 -0000 Remi, >> I might have misunderstood R-11 and R-24. it depends on the V octet. >> but I suppose for any solution it is more of a deployment choice than = a inherent limitation to the mechanism. >=20 > Unless use cases showing a practical limitation of 4rd-U in this = respect, this line can then be left out. > OK? yes, to finish off this topic, what happens with 4rd-U if the End-user = IPv6 prefix is e.g a /96? and the V-bits are not adhered to? [...] >>>> | T-mode: Checksum | L4 rewrite | CNP = | >>>=20 >>> (3) The functional point is guaranteeing IPv4-payload preservation, = with compatibility with ALL protocols using TCP-like checksum, present = of future, with checksums anywhere in the payload.=20 >>=20 >> the MDT recommends L4 rewrite: >> - this is what existing implementations do >=20 >> - works for any L4 protocol >=20 > Present or future without change? "without change and MAP", isn't that an oxymoron? any A+P solution requires support for L4 protocols to extract ports. L4 checksum rewrite, as well as port extraction will have to be = supported for all new L4 protocols. the L4 checksum rewrite approach can work with any checksum algorithm. that said, do we really think NAT44s will be upgraded to support any new = L4? [...] >>>> | Interface-id | RFC6052 | V octet = | >>>> | MAP traffic identified by | Address/prefix | Interception of = | >>>> | | | V octet = | >>>=20 >>> (5) The main functional point of the V octet is to avoid interfering = with subnet assignments in customer sites. >>=20 >> the MDT recommendation is to set aside a prefix or an IPv6 address to = terminate MAP traffic. >=20 > Indeed, so that an IPv6 site to which MAP support is added may have to = change its intra-site subnet assignments for this. > This is avoided with the V octet. in the MAP case where there is a single address as tunnel endpoint. that = address can be taken out of a /64 used also by native. if that /64 = exists on a link that the MAP CE router is not connected, the prefixes = would have to be renumbered. >>> (6) Not sure to understand what you mean by "Interception of V = octet". IPv6 routing within CEs or BRs is sufficient to orient IPv6 = packets to the 4rd function. >>=20 >> if classification of MAP packets versus native packets have to be = done, not using the best matching prefix algorithm, but a non contiguous = mask. e.g.: >>=20 >> a match on: >> 2001:db8:1234:*:0V00:* >=20 > (6.a) In BRs or CEs, the first * isn't needed because its value is = fixed so that best matching works. > (6.b) In middle boxes, if this is what you discuss, testing the V = octet is sufficient.=20 > (6.c) Note that use cases where middle boxes interpret tunnel packets = is the case where MAP-T and 4rd-H have their functional advantages over = MAP-E and 4rd-E.=20 I know we've discussed the V octet a lot earlier. I can't remember all = the nuances we discussed. could you summarize, e.g. in the feature draft = I suggested earlier. my main concern, is if this would add a new check to the IPv6 forwarding = path, forever. >>>> | Port mapping algorithm | GMA. Prog. | GMA. Fixed = | >>>=20 >>> (7) Substantial complexity added for GMA isn't justified, in my = understanding, by real use cases that would need it.=20 >>> This could easily be added to 4rd-U if so decides the WG (a waste = IMHO). >>=20 >> GMA and the 4rd-U algorithm is the same algorithm. with the same bit = representation on the wire. >=20 > - The 4rd-U algorithm is: "A port of the port set contains the PSID, = starting at bit 4. >=20 > - The MAP algorithm is: > "1. The port number (P) of a given PSID (K) is composed of: P =3D R * = M * j + M * K + i > Where: > * PSID: K =3D 0 to R - 1=20 > * Port range index: j =3D (4096 / M) / R to ((65536 / M) / R) - 1, if = the port numbers (0 - 4095) are excluded. > * Contiguous Port index: i =3D 0 to M - 1=20 > 2. The PSID (K) of a given port number (P) is determined by:=20 > K =3D (floor(P/M)) % R > Where: > * % is the modulus operator > * floor(arg) is a function that returns the largest integer not = greater than arg." >=20 > - It has to be faced that this isn't the same algorithm. This = difference is significant because the simpler the algorithm, the simpler = is personnel training, and the simpler if network maintenance.=20 if you were to give the algorithm to calculate the port ranges and how = to extract the PSID from a port. I think you would see that you end up = with the same as above. 4rd-U only shows the bit format on the wire, = while MAP shows how the port ranges can be calculated. >> the MAP text goes in more detail in explaining how to calculate the = port ranges and so on. >> 4rd-U has fixed (a) the offset bits, while MAP has the same default, = but allows it to be configured. >=20 >>=20 >>>> | Fragment forwarding on BR | N | Y = | >>>> | without reassembly | | = | >>>> | Shared fragmentation id space | N | Y = | >>>> | BR rewrite fragmentation | N | Y = | >>=20 >> btw, in 4rd-U did you intend for the BR to rewrite the fragmentation = id on packets to the Internet from the CEs? >=20 > (6-bis) As explained in the draft, not for packets from ALL CEs. > But the 4rd-U draft does propose ID rewrite in BRs for packets from = CEs having shared addresses. > Reason, explained in the draft, is that if original IDs are kept = unchanged for shared-address CEs, reassembly may be broken in = destination end points.=20 > A discussion of this point, which so far had only been discussed = verbally, is of course welcome. I think this is a good idea. but why couldn't the fragmentation rewrite be done on the CEs? e.g. by = splitting fragmentation ID space, just like port space is split? >> instead of making the CE use the fragmented fragmentation (sic!) = space directly? >=20 > Not understood. >=20 >>>> | Complete IPv6 address / | Y | N = | >>>> | prefix | | = | >>>=20 >>> (9) Not sure what you mean by a complete IPv6 prefix. I see no = functional limitation of 4rd-U with prefix lengths. >>=20 >> ah, misspelling. MAP describes how to provision a complete IPv4 = address or IPv4 prefix. (not IPv6 of course). >=20 > - Sec 5.1 says:=20 > "As far as mapping rules are concerned, the simplest deployment model = is that in which the Domain has only one rule (the Default mapping = rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is = assigned to it comprising the BR /64 prefix, the V octet, a null octet, = and the IPv4 address." > Also, the use case of 5.3 uses full IPv4 addresses. > I agree however that the text could make it clearer. >=20 > - A Mapping rule that has Rule IPv4 prefix =3D 0 and EA-bits length < = 32 assigns an IPv4 prefix. right, so the function here is just like MAP, so we don't need to = discuss that further. > BTW, could you use my e-mail address that works in Softwire, otherwise = my responses get lost. if you set the right From: or Reply-To: fields, the replies go to the = address you like. cheers, Ole From cx.cernet@gmail.com Fri Feb 3 18:43:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E3911E8091 for ; Fri, 3 Feb 2012 18:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOJUbACPWVm0 for ; Fri, 3 Feb 2012 18:43:54 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6841F11E8097 for ; Fri, 3 Feb 2012 18:43:54 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so329719pbc.31 for ; Fri, 03 Feb 2012 18:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5MF/joO7IYcnVtHWbCcEmnCHPhM2Cmg+039fTpQ2ggY=; b=BgtoRxT7+JsyDTGd66pPaJdHDXMGvwarTgvw32WzEgrPMFf6rzpVglJOgYwcw25rie r4vKfEz29NsYCS/9eblAeFk+iPT1voaTqr/6aJ9IJy2d5PSzL8ONWIejkH3evFPwcR5Q FYILJpaE4CPopbplU2kX8LA9MNF3CZpHEMDWo= MIME-Version: 1.0 Received: by 10.68.232.202 with SMTP id tq10mr23023051pbc.68.1328323432343; Fri, 03 Feb 2012 18:43:52 -0800 (PST) Received: by 10.143.32.7 with HTTP; Fri, 3 Feb 2012 18:43:52 -0800 (PST) In-Reply-To: <4F2B42AA.30200@cernet.edu.cn> References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> <4F2B42AA.30200@cernet.edu.cn> Date: Sat, 4 Feb 2012 10:43:52 +0800 Message-ID: From: Congxiao Bao To: Xing Li Content-Type: multipart/alternative; boundary=047d7b33d6e854ea1904b81a6634 Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 02:43:55 -0000 --047d7b33d6e854ea1904b81a6634 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support to have this set of drafts adopted as WG documents. Congxiao 2012/2/3 Xing Li > =E4=BA=8E 2012/2/1 22:33, Ole Tr=C3=B8an =E5=86=99=E9=81=93: > > Mark, >> >> While I appreciate the functional modularity in understanding the >>> solution space, I do wish that DT had come up with a way to make this o= ne >>> document to present to the world rather than four. I fear organ rejecti= on >>> when tossing a list of RFCs for one function to the CPE industry. >>> >>> In current form, each document has more or less than 10 pages of >>> substantive text, with considerable overlap between them (how many >>> "framework" and "architecture" sections do we really need for what are >>> really just two variants of something 95% the same?). As further eviden= ce >>> of the problem, there are no less than 19 references to >>> mdt-softwire-mapping-address-**and-port from draft-mdt-softwire-map-**t= ranslation-00. >>> One page has 5 references alone. It's is like reading a single book wit= h >>> every other page in a different binding. >>> >>> Could we not eliminate the overlap, and just boil this down to one less >>> than 40 page document? In fact, I bet if you tried you could get it dow= n to >>> half that. Looks like Remi's new document is on the right track in this >>> regard. >>> >>> I'm in favor of the chairs stating that we will adopt a WG document >>> based on the text in these documents, but I would like to see a stipula= tion >>> that they be combined into one (perhaps two but with only the DHCP opti= on >>> separate) and the overlap eliminated among MAP, T and E eliminated. >>> >> with regards to document organization we've been over that a few times. >> my understanding of the Beijing interim meeting was to have the >> organization of documents we have now. largely because there were >> discussions on different document status for the different documents. e.= g. >> experimental versus standards track. >> >> yes, it is certainly possible to merge the 3 documents (MAP, T, E), with >> separate sections that only apply to encapsulation and some that apply t= o >> translation. what I feat is that you will pollute the text with lots of >> "does not apply in the translation case", "fragmentation issues are >> slightly different", and so on. >> >> this is obviously something the working group has to decide on, but I >> don't think that needs to be done before adopting this document set. >> > > I agree with Ole. > > Regards, > > xing > > > > cheers, >> Ole >> ______________________________**_________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/**listinfo/softwires >> >> > > ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > --047d7b33d6e854ea1904b81a6634 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support to have this set of drafts adopted as WG documents.
=C2=A0
Congxiao

2012/2/3 Xing Li <xing@cernet.edu.cn>
=E4=BA=8E 2012/2/1 22:33, Ole Tr=C3= =B8an =E5=86=99=E9=81=93:=20

Mark,

While I appreciate the functional mod= ularity in understanding the solution space, I do wish that DT had come up = with a way to make this one document to present to the world rather than fo= ur. I fear organ rejection when tossing a list of RFCs for one function to = the CPE industry.

In current form, each document has more or less than 10 pages of substa= ntive text, with considerable overlap between them (how many "framewor= k" and "architecture" sections do we really need for what ar= e really just two variants of something 95% the same?). As further evidence= of the problem, there are no less than 19 references to mdt-softwire-mappi= ng-address-and-port from draft-mdt-softwire-map-translation-0= 0. One page has 5 references alone. It's is like reading a single book = with every other page in a different binding.

Could we not eliminate the overlap, and just boil this down to one less= than 40 page document? In fact, I bet if you tried you could get it down t= o half that. Looks like Remi's new document is on the right track in th= is regard.

I'm in favor of the chairs stating that we will adopt a WG document= based on the text in these documents, but I would like to see a stipulatio= n that they be combined into one (perhaps two but with only the DHCP option= separate) and the overlap eliminated among MAP, T and E eliminated.
with regards to document organization we've been over that= a few times. my understanding of the Beijing interim meeting was to have t= he organization of documents we have now. largely because there were discus= sions on different document status for the different documents. e.g. experi= mental versus standards track.

yes, it is certainly possible to merge the 3 documents (MAP, T, E), wit= h separate sections that only apply to encapsulation and some that apply to= translation. what I feat is that you will pollute the text with lots of &q= uot;does not apply in the translation case", "fragmentation issue= s are slightly different", and so on.

this is obviously something the working group has to decide on, but I d= on't think that needs to be done before adopting this document set.
=

I agree with Ole.

Regards,

xing= =20



cheers,
Ole
___________________= ____________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



_______________________________________________
So= ftwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires
<= /div>

--047d7b33d6e854ea1904b81a6634-- From despres.remi@laposte.net Fri Feb 3 22:46:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D367221F853D for ; Fri, 3 Feb 2012 22:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmS1Ejse-pPg for ; Fri, 3 Feb 2012 22:46:35 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 845A121F8535 for ; Fri, 3 Feb 2012 22:46:32 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9B82994001B; Sat, 4 Feb 2012 07:46:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> Date: Sat, 4 Feb 2012 07:46:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 06:46:35 -0000 Le 2012-02-02 =E0 18:35, Alain Durand a =E9crit : > Please, Remi, do build such a table! That would be very useful. OK, will do it next week. RD >=20 > Alain. >=20 > Sent from my iPad >=20 > On Feb 2, 2012, at 10:56 AM, "R=E9mi Despr=E9s" = wrote: >=20 >> Hi Ole, >>=20 >> This kind of table you have below is IMHO the tool we need at this = stage :-). >>=20 >> It has however to be more detailed: so far, it covers 4rd-H (the = header-mapping variant of the last 4rd-U), but not 4rd-E (its = encapsulation variant). >> A 4 columns table would be ideal. Also, It could have a sign = identifying points that are N in current drafts, but could easily = become Y if the final consensus is that they are worth the additional = complexity. >> I can work on it if you are interested. >>=20 >> More specific points below. >> They can be discussed one by one. >>=20 >>=20 >> Le 2012-02-02 =E0 11:12, Ole Tr=F8an a =E9crit : >>=20 >>>> More over, 4rd-U claims to solves a number of issues that the MAP = suite of documents does not address. It would be beneficial to have >>>> a discussion on the mailing list to see if a) those issues are = important or not and b), if they are, are they properties of 4rd-U or = could they be solved as well >>>> in MAP, they just have not been addressed there yet. >>>=20 >>> here is a comparison table of the feature differences between MAP = and 4rd-U. >>> (try a fixed width font if it doesn't survive your particular MUA = mail mangling algorithm.) >>>=20 >>> Appendix A. Comparions of stateless A+P solutions >>>=20 >>> = +-------------------------------+----------------+------------------+ >>> | Feature | MAP | 4rd-U = | >>> = +-------------------------------+----------------+------------------+ >>> | Encapsulation | Y | Y = | >>> | Translation | Y | Y = | >>> | Hub and Spoke mode | Y | Y = | >>> | Nested CPE | N | Y = | >>> | End-user prefixes > 64 | Y | N = | >>=20 >> (1)It is AFAIK also a "Y" for 4rd. >> (Not sure to understand the point.) >>=20 >>> | E-mode: Support for IPv4 | Y | N = | >>> | options | | = | >>=20 >> (2) 4rd-U draft 03 has excluded IPv4 options for both 4rd-H and 4rd-E = but, for 4rd-E, they can easily be put back if found useful. (My vote is = NO, but a WG consensus on YES for 4rd-E would not be a problem at all). >>=20 >>=20 >>> | T-mode: MF bit and TOS bits | N | Y = | >>> | transparency | | = | >>> | T-mode: Checksum | L4 rewrite | CNP = | >>=20 >> (3) The functional point is guaranteeing IPv4-payload preservation, = with compatibility with ALL protocols using TCP-like checksum, present = of future, with checksums anywhere in the payload.=20 >>=20 >>> | H & S set bit 79 needed | N | Y = | >>=20 >> (4) The functional point is to permit use cases like that of 5.3 of = the last 4rd-U draft. >> The added complexity for this is close to nil, and applies ONLY to = H&S scenarios. >>=20 >> If abandoned (which is easy), it should be with due WG consciousness = of which use cases are thus abandoned. >>=20 >>=20 >>> | Interface-id | RFC6052 | V octet = | >>> | MAP traffic identified by | Address/prefix | Interception of = | >>> | | | V octet = | >>=20 >> (5) The main functional point of the V octet is to avoid interfering = with subnet assignments in customer sites. >> (6) Not sure to understand what you mean by "Interception of V = octet". IPv6 routing within CEs or BRs is sufficient to orient IPv6 = packets to the 4rd function. >>=20 >>> | Port mapping algorithm | GMA. Prog. | GMA. Fixed = | >>=20 >> (7) Substantial complexity added for GMA isn't justified, in my = understanding, by real use cases that would need it.=20 >> This could easily be added to 4rd-U if so decides the WG (a waste = IMHO). >>=20 >>> | Fragment forwarding on BR | N | Y = | >>> | without reassembly | | = | >>> | Shared fragmentation id space | N | Y = | >>> | BR rewrite fragmentation | N | Y = | >>=20 >>=20 >>> | MSS update | Y | N = | >>=20 >> (8) I found no reference to MSS in MAP-E, and no reference to MSS = update in MAP-T. >> Did I miss them? >>=20 >>> | Complete IPv6 address / | Y | N = | >>> | prefix | | = | >>=20 >> (9) Not sure what you mean by a complete IPv6 prefix. I see no = functional limitation of 4rd-U with prefix lengths. >>=20 >>> | Provisioned with DHCP | Y | Y = | >>> = +-------------------------------+----------------+------------------+ >>>=20 >>> Table 1: A+P comparison >>=20 >>=20 >> Cheers, >> RD >>=20 >>=20 >>>=20 >>> let us make it clear that these two solutions are solving exactly = the same problem, and they solve it in the same fundamental way (A+P). = the differences we're talking about here are what whistles, bells (and = dongs) we want to add on to the base specification. consider it a = buffet, any feature from one of them can be applied to the other. >>>=20 >>> cheers, >>> Ole >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Feb 3 23:39:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912B111E8071 for ; Fri, 3 Feb 2012 23:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxpAJC72-eLS for ; Fri, 3 Feb 2012 23:39:57 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 49ED321F8534 for ; Fri, 3 Feb 2012 23:39:55 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0FCE2940167; Sat, 4 Feb 2012 08:39:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 4 Feb 2012 08:39:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 07:39:58 -0000 Le 2012-02-03 =E0 18:45, Ole Tr=F8an a =E9crit : > Remi, >=20 >>> I might have misunderstood R-11 and R-24. it depends on the V octet. >>> but I suppose for any solution it is more of a deployment choice = than a inherent limitation to the mechanism. >>=20 >> Unless use cases showing a practical limitation of 4rd-U in this = respect, this line can then be left out. >> OK? >=20 > yes, to finish off this topic, what happens with 4rd-U if the End-user = IPv6 prefix is e.g a /96? > and the V-bits are not adhered to? If the End-user doesn't support 4rd-U, nothing to be said.=20 If 4rd-U is enabled, any prefix longer than /64 that matches a Mapping = rule MUST have the V octet. If any you have a case where this isn't sufficient, I will look at it. >=20 > [...] >=20 >>>>> | T-mode: Checksum | L4 rewrite | CNP = | >>>>=20 >>>> (3) The functional point is guaranteeing IPv4-payload preservation, = with compatibility with ALL protocols using TCP-like checksum, present = of future, with checksums anywhere in the payload.=20 >>>=20 >>> the MDT recommends L4 rewrite: >>> - this is what existing implementations do >>=20 >>> - works for any L4 protocol >>=20 >> Present or future without change? >=20 > "without change and MAP", isn't that an oxymoron? > any A+P solution requires support for L4 protocols to extract ports. > L4 checksum rewrite, as well as port extraction will have to be = supported for all new L4 protocols. > the L4 checksum rewrite approach can work with any checksum algorithm. > that said, do we really think NAT44s will be upgraded to support any = new L4? Imagine a variant of the SCTP of RFC4960 is introduced where the = TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis = (not a bad idea IMHO, but here just a hypothesis to answer your point).=20= =3D> 4rd-H would be compatible with it without any evolution; RFC6145 = would need an upgrade to support it. Upgrading NAT44s to support this SCTP-bis would be trivial (ports as the = same place as usual can be mapped as usual. >=20 > [...] >=20 >>>>> | Interface-id | RFC6052 | V octet = | >>>>> | MAP traffic identified by | Address/prefix | Interception = of | >>>>> | | | V octet = | >>>>=20 >>>> (5) The main functional point of the V octet is to avoid = interfering with subnet assignments in customer sites. >>>=20 >>> the MDT recommendation is to set aside a prefix or an IPv6 address = to terminate MAP traffic. >>=20 >> Indeed, so that an IPv6 site to which MAP support is added may have = to change its intra-site subnet assignments for this. >> This is avoided with the V octet. >=20 > in the MAP case where there is a single address as tunnel endpoint. = that address can be taken out of a /64 used also by native. if that /64 = exists on a link that the MAP CE router is not connected, the prefixes = would have to be renumbered. Right.=20 Renumbering avoidance being a positive feature, the V octet is useful in = this case. In the case of prefixes shorter than /64, all addresses based on the = subnet prefix that happens to be needed to introduce MAP would need to = be renumbered. This is avoided with the V octet of 4rd-U. Agreed? >=20 >>>> (6) Not sure to understand what you mean by "Interception of V = octet". IPv6 routing within CEs or BRs is sufficient to orient IPv6 = packets to the 4rd function. >>>=20 >>> if classification of MAP packets versus native packets have to be = done, not using the best matching prefix algorithm, but a non contiguous = mask. e.g.: >>>=20 >>> a match on: >>> 2001:db8:1234:*:0V00:* >>=20 >> (6.a) In BRs or CEs, the first * isn't needed because its value is = fixed so that best matching works. >> (6.b) In middle boxes, if this is what you discuss, testing the V = octet is sufficient.=20 >> (6.c) Note that use cases where middle boxes interpret tunnel packets = is the case where MAP-T and 4rd-H have their functional advantages over = MAP-E and 4rd-E.=20 >=20 > I know we've discussed the V octet a lot earlier. I can't remember all = the nuances we discussed. could you summarize, e.g. in the feature draft = I suggested earlier. Please see above. Also, the 4rd-U draft says: "The V octet is a 4rd-specific mark. Its function is to ensure that 4rd = does not interfere with the choice of subnet prefixes in CE sites. It = can also facilitate maintenance by facilitating distinction between 4rd = Tunnel packets and native-IPv6 packets. Within CEs, IPv6 packets can = safely be routed to the 4rd function based on a /80 prefix because no = internal route for native IPv6 can have a destination prefix that start = with this one."=20 > my main concern, is if this would add a new check to the IPv6 = forwarding path, forever. Not understood. >=20 >>>>> | Port mapping algorithm | GMA. Prog. | GMA. Fixed = | >>>>=20 >>>> (7) Substantial complexity added for GMA isn't justified, in my = understanding, by real use cases that would need it.=20 >>>> This could easily be added to 4rd-U if so decides the WG (a waste = IMHO). >>>=20 >>> GMA and the 4rd-U algorithm is the same algorithm. with the same bit = representation on the wire. >>=20 >> - The 4rd-U algorithm is: "A port of the port set contains the PSID, = starting at bit 4. >>=20 >> - The MAP algorithm is: >> "1. The port number (P) of a given PSID (K) is composed of: P =3D R * = M * j + M * K + i >> Where: >> * PSID: K =3D 0 to R - 1=20 >> * Port range index: j =3D (4096 / M) / R to ((65536 / M) / R) - 1, = if the port numbers (0 - 4095) are excluded. >> * Contiguous Port index: i =3D 0 to M - 1=20 >> 2. The PSID (K) of a given port number (P) is determined by:=20 >> K =3D (floor(P/M)) % R >> Where: >> * % is the modulus operator >> * floor(arg) is a function that returns the largest integer not = greater than arg." >>=20 >> - It has to be faced that this isn't the same algorithm. This = difference is significant because the simpler the algorithm, the simpler = is personnel training, and the simpler if network maintenance.=20 >=20 > if you were to give the algorithm to calculate the port ranges and how = to extract the PSID from a port. I think you would see that you end up = with the same as above. Are you sure you mean what you wrote?=20 (I can't find how this would make sense: in 4rd-U, extracting the PSID = knowing its length k is just extracting bits 4 to 3 + k). > 4rd-U only shows the bit format on the wire, while MAP shows how the = port ranges can be calculated. >=20 >>> the MAP text goes in more detail in explaining how to calculate the = port ranges and so on. >>> 4rd-U has fixed (a) the offset bits, while MAP has the same default, = but allows it to be configured. >>=20 >>>=20 >>>>> | Fragment forwarding on BR | N | Y = | >>>>> | without reassembly | | = | >>>>> | Shared fragmentation id space | N | Y = | >>>>> | BR rewrite fragmentation | N | Y = | >>>=20 >>> btw, in 4rd-U did you intend for the BR to rewrite the fragmentation = id on packets to the Internet from the CEs? >>=20 >> (6-bis) As explained in the draft, not for packets from ALL CEs. >> But the 4rd-U draft does propose ID rewrite in BRs for packets from = CEs having shared addresses. >> Reason, explained in the draft, is that if original IDs are kept = unchanged for shared-address CEs, reassembly may be broken in = destination end points.=20 >> A discussion of this point, which so far had only been discussed = verbally, is of course welcome. >=20 > I think this is a good idea. > but why couldn't the fragmentation rewrite be done on the CEs? e.g. by = splitting fragmentation ID space, just like port space is split? This is an alternative which has pros and cons. - it statically reduces the number of ID shared-addresss CEs can use, a = drawback. - it significantly simplifies BRs Personally, I think your proposal is overall better, at least as long as = very high sharing ratios are avoided. A warning against such sharing = ratios can be added. Unless there are objections, a next edition of the unified draft will = have it. >=20 >>> instead of making the CE use the fragmented fragmentation (sic!) = space directly? >>=20 >> Not understood. >>=20 >>>>> | Complete IPv6 address / | Y | N = | >>>>> | prefix | | = | >>>>=20 >>>> (9) Not sure what you mean by a complete IPv6 prefix. I see no = functional limitation of 4rd-U with prefix lengths. >>>=20 >>> ah, misspelling. MAP describes how to provision a complete IPv4 = address or IPv4 prefix. (not IPv6 of course). >>=20 >> - Sec 5.1 says:=20 >> "As far as mapping rules are concerned, the simplest deployment model = is that in which the Domain has only one rule (the Default mapping = rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is = assigned to it comprising the BR /64 prefix, the V octet, a null octet, = and the IPv4 address." >> Also, the use case of 5.3 uses full IPv4 addresses. >> I agree however that the text could make it clearer. >>=20 >> - A Mapping rule that has Rule IPv4 prefix =3D 0 and EA-bits length = < 32 assigns an IPv4 prefix. >=20 > right, so the function here is just like MAP, so we don't need to = discuss that further. >=20 >> BTW, could you use my e-mail address that works in Softwire, = otherwise my responses get lost. >=20 > if you set the right From: or Reply-To: fields, the replies go to the = address you like. I know, but when I fail to check that the right address was used, my = answers do reach cc addresses and fail to reach the WG list. I then have = to send a copy from the modified source. CCs addressees then receive the = same message twice. AFAIK, the Reply-to field is intended for cases where the provided = address differs from the source address. Anyway, thanks for having sent this e-mail to my mailing-list compatible = address. Cheers, RD =20 >=20 > cheers, > Ole >=20 From Tina.Tsou.Zouting@huawei.com Sat Feb 4 01:50:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78321F84FB for ; Sat, 4 Feb 2012 01:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00zhZivdYqSx for ; Sat, 4 Feb 2012 01:50:07 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id AB60621F84FA for ; Sat, 4 Feb 2012 01:50:06 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYV00FBS4NET6@szxga03-in.huawei.com> for softwires@ietf.org; Sat, 04 Feb 2012 17:50:03 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYV00BXJ4NEP4@szxga03-in.huawei.com> for softwires@ietf.org; Sat, 04 Feb 2012 17:50:02 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGV08115; Sat, 04 Feb 2012 17:49:31 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 04 Feb 2012 17:48:57 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Sat, 04 Feb 2012 17:48:54 +0800 Date: Sat, 04 Feb 2012 09:48:53 +0000 From: Tina TSOU In-reply-to: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Message-id: <258788AA-60F6-4736-82C0-CA02D45D0805@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U Thread-index: AQHM4m7z7v3+nerQQUWkiU5+ojD5A5YqtmUAgAA1xgCAAOkrAIAAqjU7 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 09:50:08 -0000 Sent from my iPad On Feb 3, 2012, at 11:40 PM, "R=E9mi Despr=E9s" = wrote: >=20 > Le 2012-02-03 =E0 18:45, Ole Tr=F8an a =E9crit : >=20 >> Remi, >>=20 >>>> I might have misunderstood R-11 and R-24. it depends on the V octet. >>>> but I suppose for any solution it is more of a deployment choice than = a inherent limitation to the mechanism. >>>=20 >>> Unless use cases showing a practical limitation of 4rd-U in this respec= t, this line can then be left out. >>> OK? >>=20 >> yes, to finish off this topic, what happens with 4rd-U if the End-user I= Pv6 prefix is e.g a /96? >> and the V-bits are not adhered to? >=20 > If the End-user doesn't support 4rd-U, nothing to be said.=20 > If 4rd-U is enabled, any prefix longer than /64 that matches a Mapping ru= le MUST have the V octet. >=20 > If any you have a case where this isn't sufficient, I will look at it. >=20 >>=20 >> [...] >>=20 >>>>>> | T-mode: Checksum | L4 rewrite | CNP = | >>>>>=20 >>>>> (3) The functional point is guaranteeing IPv4-payload preservation, w= ith compatibility with ALL protocols using TCP-like checksum, present of fu= ture, with checksums anywhere in the payload.=20 >>>>=20 >>>> the MDT recommends L4 rewrite: >>>> - this is what existing implementations do >>>=20 >>>> - works for any L4 protocol >>>=20 >>> Present or future without change? >>=20 >> "without change and MAP", isn't that an oxymoron? >> any A+P solution requires support for L4 protocols to extract ports. >> L4 checksum rewrite, as well as port extraction will have to be supporte= d for all new L4 protocols. >> the L4 checksum rewrite approach can work with any checksum algorithm. >> that said, do we really think NAT44s will be upgraded to support any new= L4? >=20 > Imagine a variant of the SCTP of RFC4960 is introduced where the TCP-like= checksum MAY be used to facilitate its deployment, say SCTP-bis (not a bad= idea IMHO, but here just a hypothesis to answer your point).=20 > =3D> 4rd-H would be compatible with it without any evolution; RFC6145 wou= ld need an upgrade to support it. >=20 > Upgrading NAT44s to support this SCTP-bis would be trivial (ports as the = same place as usual can be mapped as usual. >=20 >=20 >>=20 >> [...] >>=20 >>>>>> | Interface-id | RFC6052 | V octet = | >>>>>> | MAP traffic identified by | Address/prefix | Interception of = | >>>>>> | | | V octet = | >>>>>=20 >>>>> (5) The main functional point of the V octet is to avoid interfering = with subnet assignments in customer sites. >>>>=20 >>>> the MDT recommendation is to set aside a prefix or an IPv6 address to = terminate MAP traffic. >>>=20 >>> Indeed, so that an IPv6 site to which MAP support is added may have to = change its intra-site subnet assignments for this. >>> This is avoided with the V octet. >>=20 >> in the MAP case where there is a single address as tunnel endpoint. that= address can be taken out of a /64 used also by native. if that /64 exists = on a link that the MAP CE router is not connected, the prefixes would have = to be renumbered. >=20 > Right.=20 > Renumbering avoidance being a positive feature, the V octet is useful in = this case. >=20 > In the case of prefixes shorter than /64, all addresses based on the subn= et prefix that happens to be needed to introduce MAP would need to be renum= bered. This is avoided with the V octet of 4rd-U. >=20 > Agreed? >=20 >=20 >>=20 >>>>> (6) Not sure to understand what you mean by "Interception of V octet"= . IPv6 routing within CEs or BRs is sufficient to orient IPv6 packets to th= e 4rd function. >>>>=20 >>>> if classification of MAP packets versus native packets have to be done= , not using the best matching prefix algorithm, but a non contiguous mask. = e.g.: >>>>=20 >>>> a match on: >>>> 2001:db8:1234:*:0V00:* >>>=20 >>> (6.a) In BRs or CEs, the first * isn't needed because its value is fixe= d so that best matching works. >>> (6.b) In middle boxes, if this is what you discuss, testing the V octet= is sufficient.=20 >>> (6.c) Note that use cases where middle boxes interpret tunnel packets i= s the case where MAP-T and 4rd-H have their functional advantages over MAP-= E and 4rd-E.=20 >>=20 >> I know we've discussed the V octet a lot earlier. I can't remember all t= he nuances we discussed. could you summarize, e.g. in the feature draft I s= uggested earlier. >=20 > Please see above. > Also, the 4rd-U draft says: > "The V octet is a 4rd-specific mark. Its function is to ensure that 4rd d= oes not interfere with the choice of subnet prefixes in CE sites. It can a= lso facilitate maintenance by facilitating distinction between 4rd Tunnel p= ackets and native-IPv6 packets. Within CEs, IPv6 packets can safely be rou= ted to the 4rd function based on a /80 prefix because no internal route for= native IPv6 can have a destination prefix that start with this one."=20 Assume there is a CE Router with /32 IPv6 addresses in an enterprise networ= k. "based on a /80 prefix" for what? Would u elaborate or reword the last sent= ence for better understanding for readers like me? Merci. >=20 >=20 >> my main concern, is if this would add a new check to the IPv6 forwarding= path, forever. >=20 > Not understood. >=20 >>=20 >>>>>> | Port mapping algorithm | GMA. Prog. | GMA. Fixed = | >>>>>=20 >>>>> (7) Substantial complexity added for GMA isn't justified, in my unde= rstanding, by real use cases that would need it.=20 >>>>> This could easily be added to 4rd-U if so decides the WG (a waste IMH= O). >>>>=20 >>>> GMA and the 4rd-U algorithm is the same algorithm. with the same bit r= epresentation on the wire. >>>=20 >>> - The 4rd-U algorithm is: "A port of the port set contains the PSID, st= arting at bit 4. >>>=20 >>> - The MAP algorithm is: >>> "1. The port number (P) of a given PSID (K) is composed of: P =3D R * M= * j + M * K + i >>> Where: >>> * PSID: K =3D 0 to R - 1=20 >>> * Port range index: j =3D (4096 / M) / R to ((65536 / M) / R) - 1, if = the port numbers (0 - 4095) are excluded. >>> * Contiguous Port index: i =3D 0 to M - 1=20 >>> 2. The PSID (K) of a given port number (P) is determined by:=20 >>> K =3D (floor(P/M)) % R >>> Where: >>> * % is the modulus operator >>> * floor(arg) is a function that returns the largest integer not greate= r than arg." >>>=20 >>> - It has to be faced that this isn't the same algorithm. This differenc= e is significant because the simpler the algorithm, the simpler is personne= l training, and the simpler if network maintenance.=20 >>=20 >> if you were to give the algorithm to calculate the port ranges and how t= o extract the PSID from a port. I think you would see that you end up with = the same as above. >=20 > Are you sure you mean what you wrote?=20 > (I can't find how this would make sense: in 4rd-U, extracting the PSID kn= owing its length k is just extracting bits 4 to 3 + k). >=20 >> 4rd-U only shows the bit format on the wire, while MAP shows how the por= t ranges can be calculated. >>=20 >>>> the MAP text goes in more detail in explaining how to calculate the po= rt ranges and so on. >>>> 4rd-U has fixed (a) the offset bits, while MAP has the same default, b= ut allows it to be configured. >>>=20 >>>>=20 >>>>>> | Fragment forwarding on BR | N | Y = | >>>>>> | without reassembly | | = | >>>>>> | Shared fragmentation id space | N | Y = | >>>>>> | BR rewrite fragmentation | N | Y = | >>>>=20 >>>> btw, in 4rd-U did you intend for the BR to rewrite the fragmentation i= d on packets to the Internet from the CEs? >>>=20 >>> (6-bis) As explained in the draft, not for packets from ALL CEs. >>> But the 4rd-U draft does propose ID rewrite in BRs for packets from CEs= having shared addresses. >>> Reason, explained in the draft, is that if original IDs are kept unchan= ged for shared-address CEs, reassembly may be broken in destination end poi= nts.=20 >>> A discussion of this point, which so far had only been discussed verbal= ly, is of course welcome. >>=20 >> I think this is a good idea. >> but why couldn't the fragmentation rewrite be done on the CEs? e.g. by s= plitting fragmentation ID space, just like port space is split? >=20 > This is an alternative which has pros and cons. > - it statically reduces the number of ID shared-addresss CEs can use, a d= rawback. > - it significantly simplifies BRs >=20 > Personally, I think your proposal is overall better, at least as long as = very high sharing ratios are avoided. A warning against such sharing ratios= can be added. > Unless there are objections, a next edition of the unified draft will hav= e it. >=20 >>=20 >>>> instead of making the CE use the fragmented fragmentation (sic!) space= directly? >>>=20 >>> Not understood. >>>=20 >>>>>> | Complete IPv6 address / | Y | N = | >>>>>> | prefix | | = | >>>>>=20 >>>>> (9) Not sure what you mean by a complete IPv6 prefix. I see no functi= onal limitation of 4rd-U with prefix lengths. >>>>=20 >>>> ah, misspelling. MAP describes how to provision a complete IPv4 addres= s or IPv4 prefix. (not IPv6 of course). >>>=20 >>> - Sec 5.1 says:=20 >>> "As far as mapping rules are concerned, the simplest deployment model i= s that in which the Domain has only one rule (the Default mapping rule). To= assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to = it comprising the BR /64 prefix, the V octet, a null octet, and the IPv4 ad= dress." >>> Also, the use case of 5.3 uses full IPv4 addresses. >>> I agree however that the text could make it clearer. >>>=20 >>> - A Mapping rule that has Rule IPv4 prefix =3D 0 and EA-bits length < = 32 assigns an IPv4 prefix. >>=20 >> right, so the function here is just like MAP, so we don't need to discus= s that further. >>=20 >>> BTW, could you use my e-mail address that works in Softwire, otherwise = my responses get lost. >>=20 >> if you set the right From: or Reply-To: fields, the replies go to the ad= dress you like. >=20 > I know, but when I fail to check that the right address was used, my answ= ers do reach cc addresses and fail to reach the WG list. I then have to sen= d a copy from the modified source. CCs addressees then receive the same mes= sage twice. > AFAIK, the Reply-to field is intended for cases where the provided addres= s differs from the source address. > Anyway, thanks for having sent this e-mail to my mailing-list compatible = address. >=20 > Cheers, > RD >=20 >=20 >=20 >>=20 >> cheers, >> Ole >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Sat Feb 4 02:23:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0C521F8588 for ; Sat, 4 Feb 2012 02:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMnyDF3es2fZ for ; Sat, 4 Feb 2012 02:23:37 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2352021F857F for ; Sat, 4 Feb 2012 02:23:34 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9BBB29401CC; Sat, 4 Feb 2012 11:23:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <258788AA-60F6-4736-82C0-CA02D45D0805@huawei.com> Date: Sat, 4 Feb 2012 11:23:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <258788AA-60F6-4736-82C0-CA02D45D0805@huawei.com> To: Tina TSOU X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 10:23:38 -0000 Le 2012-02-04 =E0 10:48, Tina TSOU a =E9crit : > Sent from my iPad > On Feb 3, 2012, at 11:40 PM, "R=E9mi Despr=E9s" = wrote: >> Le 2012-02-03 =E0 18:45, Ole Tr=F8an a =E9crit : ... >>> I know we've discussed the V octet a lot earlier. I can't remember = all the nuances we discussed. could you summarize, e.g. in the feature = draft I suggested earlier. >> ... >> "The V octet is a 4rd-specific mark. Its function is to ensure that = 4rd does not interfere with the choice of subnet prefixes in CE sites. = It can also facilitate maintenance by facilitating distinction between = 4rd Tunnel packets and native-IPv6 packets. Within CEs, IPv6 packets = can safely be routed to the 4rd function based on a /80 prefix because = no internal route for native IPv6 can have a destination prefix that = start with this one."=20 > Assume there is a CE Router with /32 IPv6 addresses in an enterprise = network. > "based on a /80 prefix" for what? Would u elaborate or reword the last = sentence for better understanding for readers like me? Merci. If a CE has a /32 prefix, say p:p::/32, and some Mapping rule that = derives an IPv4 prefix or address from it, all 4rd Tunnel packets sent = to it have, according to the 4rd-U draft, an IPv6 destination starting = with p:p:0:0:3000::/80. Within the CE, all packets whose destination start with this prefix can = be routed, within the CE, to the 4rd function.=20 Native IPv6 packets are routed in the CE with prefixes that are either = longer than the CE 4rd prefix and non-overlapping, or shorter. In both = cases adding a route for the 4rd /80 doesn't impact how they are routed. Does this clarify? Regards, RD From ichiroumakino@gmail.com Sat Feb 4 06:01:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970BA21F853A for ; Sat, 4 Feb 2012 06:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khnEotqFCic7 for ; Sat, 4 Feb 2012 06:01:01 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5C7F21F852C for ; Sat, 4 Feb 2012 06:01:00 -0800 (PST) Received: by wibhm9 with SMTP id hm9so4163086wib.31 for ; Sat, 04 Feb 2012 06:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=SDg2/qem4HNHNiXyCddFROUa4o4J5CCsGbdVwvTQ7R0=; b=ho53GNIRx21fR5vRKwjHMRwsxnDbzt5vxJ0s5KHiym5NwoUjJczMXtAxcrikB8jGlA EuH0sO8y1BRBwY+4u2EuoOR8JGH5iAjhFDb/yIg6yUAA0AcpeEcVuPK43ts2RHMnFw03 cYLuWtyPBUrlLOGxhw8rb8f9tb3k+foyKzEqQ= Received: by 10.180.92.226 with SMTP id cp2mr17486952wib.10.1328364059995; Sat, 04 Feb 2012 06:00:59 -0800 (PST) Received: from dhcp-10-55-92-208.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id p10sm13362137wic.0.2012.02.04.06.00.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 06:00:58 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Sat, 4 Feb 2012 15:00:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D3E4FAC-954D-4AA6-825D-64776F945488@employees.org> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <258788AA-60F6-4736-82C0-CA02D45D0805@huawei.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Ralph Droms , Yong Cui Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 14:01:01 -0000 Remi, >>>> I know we've discussed the V octet a lot earlier. I can't remember = all the nuances we discussed. could you summarize, e.g. in the feature = draft I suggested earlier. >>> ... >>> "The V octet is a 4rd-specific mark. Its function is to ensure that = 4rd does not interfere with the choice of subnet prefixes in CE sites. = It can also facilitate maintenance by facilitating distinction between = 4rd Tunnel packets and native-IPv6 packets. Within CEs, IPv6 packets = can safely be routed to the 4rd function based on a /80 prefix because = no internal route for native IPv6 can have a destination prefix that = start with this one."=20 >=20 >> Assume there is a CE Router with /32 IPv6 addresses in an enterprise = network. >> "based on a /80 prefix" for what? Would u elaborate or reword the = last sentence for better understanding for readers like me? Merci. >=20 > If a CE has a /32 prefix, say p:p::/32, and some Mapping rule that = derives an IPv4 prefix or address from it, all 4rd Tunnel packets sent = to it have, according to the 4rd-U draft, an IPv6 destination starting = with p:p:0:0:3000::/80. > Within the CE, all packets whose destination start with this prefix = can be routed, within the CE, to the 4rd function.=20 > Native IPv6 packets are routed in the CE with prefixes that are either = longer than the CE 4rd prefix and non-overlapping, or shorter. In both = cases adding a route for the 4rd /80 doesn't impact how they are routed. > Does this clarify? so what you are saying is that for an End-User IPv6 prefix of /56. there = will be 256 /80 routes? cheers, Ole= From bingxuere@gmail.com Sat Feb 4 07:41:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC9A21F85B8 for ; Sat, 4 Feb 2012 07:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86VaYSnRrZpG for ; Sat, 4 Feb 2012 07:41:35 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD3421F85B6 for ; Sat, 4 Feb 2012 07:41:35 -0800 (PST) Received: by iagf6 with SMTP id f6so7517651iag.31 for ; Sat, 04 Feb 2012 07:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=C0wL455e00fPCdykQFt0yp5IBs1lkaYr0841Xrbxagk=; b=TVxNWaUI8jUf8zqrOw16i6N7jy4x+yWTgdjrL52fAjhhKRDku5pRNRwFEqyk1Ydaa1 n0y2zFNAd4xih8+FX0VUx3v/LVbevIRx8u/3yFR0d3a+epsVDC7f30nhT9VX8WWCauDt uTs4i9MR4E8aDU7Sgp1TljNmJICGRLEMFjTb0= Received: by 10.50.153.234 with SMTP id vj10mr13607147igb.16.1328370095254; Sat, 04 Feb 2012 07:41:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.226.134 with HTTP; Sat, 4 Feb 2012 07:40:55 -0800 (PST) From: Qiong Date: Sat, 4 Feb 2012 23:40:55 +0800 Message-ID: To: softwires@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3ba66da86d2f04b825437d Subject: [Softwires] [softwire] Merged version of lightweight 4over6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 15:41:36 -0000 --e89a8f3ba66da86d2f04b825437d Content-Type: text/plain; charset=UTF-8 Dear all, We have published a merged version of lightweight 4over6 in: http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt. This mechanism moves the translation function from the tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the mapping scale on the concentrator to per-subscriber level. It has got wilely support in the last Taipei IETF meeting, and the only action we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite and I-D.zhou-softwire-b4-nat into one draft. Now that the merge work has done, from the authors of this document's view, it is ready to be adopted as working group document. We would be appreciated to have your comments. Thanks in advance ! Best wishes Qiong --e89a8f3ba66da86d2f04b825437d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

We have published a merged version of lightweight 4over6 i= n:
http://www.ietf.org/internet-drafts/draft-cui-s= oftwire-b4-translated-ds-lite-05.txt.

This mechanism moves the translation function from the tunnel concentra= tor (AFTR) to initiators (B4s), and hence reduces the mapping scale on the = concentrator to per-subscriber level.

It has got wilely support in= the last Taipei IETF meeting, and the only action we need to do is to merg= e I-D.cui-softwire-b4-translated-ds-lite
and I-D.zhou-softwire-b4-nat into one draft.

Now that the merge work= has done, from the authors of this document's view, it is ready to be = adopted as working group document. We would be appreciated to have your com= ments.

Thanks in advance !

Best wishes

Qiong


=C2=A0

--e89a8f3ba66da86d2f04b825437d-- From wdec.ietf@gmail.com Sat Feb 4 09:23:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743D821F84DE for ; Sat, 4 Feb 2012 09:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD5umX7o4fep for ; Sat, 4 Feb 2012 09:23:40 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86B9821F84F9 for ; Sat, 4 Feb 2012 09:23:40 -0800 (PST) Received: by qafi29 with SMTP id i29so1282570qaf.10 for ; Sat, 04 Feb 2012 09:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DBiGXWURaoNFmZbiV6A5EPDgK4WDtkKyc1Dk4oH+GrQ=; b=f4L4vtAQozk1PUswNIY9KmHsax3rUPQ3rTpv4408x7+v8jStJP+6LgKKfVrb0eRxW9 uO8XvEptzFrNVcWppiaaOhLIYsImalKT1aXESIPmODzMfEfCW5GiU7r43MhmEcX8UYua 9hVZwEs2soxvnDH22ez/fl/S/P7T4b1DIlpv8= MIME-Version: 1.0 Received: by 10.224.181.143 with SMTP id by15mr14213606qab.29.1328376220001; Sat, 04 Feb 2012 09:23:40 -0800 (PST) Received: by 10.229.82.201 with HTTP; Sat, 4 Feb 2012 09:23:39 -0800 (PST) In-Reply-To: References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <97737FB3-6A47-4530-BE58-68209022D155@townsley.net> Date: Sat, 4 Feb 2012 18:23:39 +0100 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=20cf303b41adb8a64104b826b0f5 Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 17:23:41 -0000 --20cf303b41adb8a64104b826b0f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fully agree with Ole. We've been back and forth on the one-draft, many-drafts, too-many-drafts discussion so many times, and it's not productive. We have a broad group of individuals who are interested in pursuing the drafts. Given that this is a WG that is meant to operate for its participants, as opposed to against them (as has been the case), having progress in the form of document adoption would be a good step forward. -Woj. On 1 February 2012 15:33, Ole Tr=F8an wrote: > Mark, > > > While I appreciate the functional modularity in understanding the > solution space, I do wish that DT had come up with a way to make this one > document to present to the world rather than four. I fear organ rejection > when tossing a list of RFCs for one function to the CPE industry. > > > > In current form, each document has more or less than 10 pages of > substantive text, with considerable overlap between them (how many > "framework" and "architecture" sections do we really need for what are > really just two variants of something 95% the same?). As further evidence > of the problem, there are no less than 19 references to > mdt-softwire-mapping-address-and-port from > draft-mdt-softwire-map-translation-00. One page has 5 references alone. > It's is like reading a single book with every other page in a different > binding. > > > > Could we not eliminate the overlap, and just boil this down to one less > than 40 page document? In fact, I bet if you tried you could get it down = to > half that. Looks like Remi's new document is on the right track in this > regard. > > > > I'm in favor of the chairs stating that we will adopt a WG document > based on the text in these documents, but I would like to see a stipulati= on > that they be combined into one (perhaps two but with only the DHCP option > separate) and the overlap eliminated among MAP, T and E eliminated. > > with regards to document organization we've been over that a few times. m= y > understanding of the Beijing interim meeting was to have the organization > of documents we have now. largely because there were discussions on > different document status for the different documents. e.g. experimental > versus standards track. > > yes, it is certainly possible to merge the 3 documents (MAP, T, E), with > separate sections that only apply to encapsulation and some that apply to > translation. what I feat is that you will pollute the text with lots of > "does not apply in the translation case", "fragmentation issues are > slightly different", and so on. > > this is obviously something the working group has to decide on, but I > don't think that needs to be done before adopting this document set. > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf303b41adb8a64104b826b0f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fully agree with Ole.
We've been back and forth on the one-draft, m= any-drafts, too-many-drafts discussion so many times, and it's not prod= uctive. We have a broad group of individuals who are interested in pursuing= the drafts. Given that this is a WG that is meant to operate for its parti= cipants, as opposed to against them (as has been the case), having progress= in the form of document adoption would be a good step forward.

-Woj.

On 1 February 2012 15:33, Ole T= r=F8an <otroan= @employees.org> wrote:
Mark,

> While I appreciate the functional modularity in understanding the solu= tion space, I do wish that DT had come up with a way to make this one docum= ent to present to the world rather than four. I fear organ rejection when t= ossing a list of RFCs for one function to the CPE industry.
>
> In current form, each document has more or less than 10 pages of subst= antive text, with considerable overlap between them (how many "framewo= rk" and "architecture" sections do we really need for what a= re really just two variants of something 95% the same?). As further evidenc= e of the problem, there are no less than 19 references to mdt-softwire-mapp= ing-address-and-port from draft-mdt-softwire-map-translation-00. One page h= as 5 references alone. It's is like reading a single book with every ot= her page in a different binding.
>
> Could we not eliminate the overlap, and just boil this down to one les= s than 40 page document? In fact, I bet if you tried you could get it down = to half that. Looks like Remi's new document is on the right track in t= his regard.
>
> I'm in favor of the chairs stating that we will adopt a WG documen= t based on the text in these documents, but I would like to see a stipulati= on that they be combined into one (perhaps two but with only the DHCP optio= n separate) and the overlap eliminated among MAP, T and E eliminated.

with regards to document organization we've been over that a few = times. my understanding of the Beijing interim meeting was to have the orga= nization of documents we have now. largely because there were discussions o= n different document status for the different documents. e.g. experimental = versus standards track.

yes, it is certainly possible to merge the 3 documents (MAP, T, E), with se= parate sections that only apply to encapsulation and some that apply to tra= nslation. what I feat is that you will pollute the text with lots of "= does not apply in the translation case", "fragmentation issues ar= e slightly different", and so on.

this is obviously something the working group has to decide on, but I don&#= 39;t think that needs to be done before adopting this document set.

cheers,
Ole
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf303b41adb8a64104b826b0f5-- From ichiroumakino@gmail.com Sun Feb 5 01:05:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B90F21F84F3 for ; Sun, 5 Feb 2012 01:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTCRPN5W8jKR for ; Sun, 5 Feb 2012 01:05:18 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9043121F852B for ; Sun, 5 Feb 2012 01:05:18 -0800 (PST) Received: by dakl33 with SMTP id l33so4647466dak.31 for ; Sun, 05 Feb 2012 01:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=JOrLIRdcNS5mE3WFhTFVMZtGSr6nCiFfRwZp9/x7ZXk=; b=UvvdSFNhE3pCTnb6cGOquwAqw4wpzRaAq8jVvm0jesW2e92mPYYfMXAogVnuwhs6ra 0mZp2nnhrcZ24RlXLoRuNA5jfV42b+rzomjYDvRnmZoqPnOrTFzMGbUUFZ5D7n0epFFH MQKqePJrN1hB9WDrkFyFn/8czlonpvfg89EwI= Received: by 10.68.189.65 with SMTP id gg1mr35483015pbc.66.1328432718412; Sun, 05 Feb 2012 01:05:18 -0800 (PST) Received: from sjc-vpn5-138.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id p9sm29167792pbb.9.2012.02.05.01.05.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 01:05:16 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Sun, 5 Feb 2012 10:05:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 09:05:19 -0000 Remi, >>> Unless use cases showing a practical limitation of 4rd-U in this = respect, this line can then be left out. >>> OK? >>=20 >> yes, to finish off this topic, what happens with 4rd-U if the = End-user IPv6 prefix is e.g a /96? >> and the V-bits are not adhered to? >=20 > If the End-user doesn't support 4rd-U, nothing to be said.=20 > If 4rd-U is enabled, any prefix longer than /64 that matches a Mapping = rule MUST have the V octet. >=20 > If any you have a case where this isn't sufficient, I will look at it. MAP is more flexible with regards to not depending on the V octet. >>>>>> | T-mode: Checksum | L4 rewrite | CNP = | >>>>>=20 >>>>> (3) The functional point is guaranteeing IPv4-payload = preservation, with compatibility with ALL protocols using TCP-like = checksum, present of future, with checksums anywhere in the payload.=20 >>>>=20 >>>> the MDT recommends L4 rewrite: >>>> - this is what existing implementations do >>>=20 >>>> - works for any L4 protocol >>>=20 >>> Present or future without change? >>=20 >> "without change and MAP", isn't that an oxymoron? >> any A+P solution requires support for L4 protocols to extract ports. >> L4 checksum rewrite, as well as port extraction will have to be = supported for all new L4 protocols. >> the L4 checksum rewrite approach can work with any checksum = algorithm. >> that said, do we really think NAT44s will be upgraded to support any = new L4? >=20 > Imagine a variant of the SCTP of RFC4960 is introduced where the = TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis = (not a bad idea IMHO, but here just a hypothesis to answer your point).=20= > =3D> 4rd-H would be compatible with it without any evolution; RFC6145 = would need an upgrade to support it. >=20 > Upgrading NAT44s to support this SCTP-bis would be trivial (ports as = the same place as usual can be mapped as usual. my point is that MAP is L4 aware anyway, and has to be modified to = support any new transport protocol. since code modifications have to be = made, then having a checksum neutral function at the network layer = doesn't help much. you still need to change code. L4 rewrite is also = more flexible in that it will support _any_ checksum algorithm, and most = importantly is already implemented in every node. >> [...] >>=20 >>>>>> | Interface-id | RFC6052 | V octet = | >>>>>> | MAP traffic identified by | Address/prefix | Interception = of | >>>>>> | | | V octet = | >>>>>=20 >>>>> (5) The main functional point of the V octet is to avoid = interfering with subnet assignments in customer sites. >>>>=20 >>>> the MDT recommendation is to set aside a prefix or an IPv6 address = to terminate MAP traffic. >>>=20 >>> Indeed, so that an IPv6 site to which MAP support is added may have = to change its intra-site subnet assignments for this. >>> This is avoided with the V octet. >>=20 >> in the MAP case where there is a single address as tunnel endpoint. = that address can be taken out of a /64 used also by native. if that /64 = exists on a link that the MAP CE router is not connected, the prefixes = would have to be renumbered. >=20 > Right.=20 > Renumbering avoidance being a positive feature, the V octet is useful = in this case. >=20 > In the case of prefixes shorter than /64, all addresses based on the = subnet prefix that happens to be needed to introduce MAP would need to = be renumbered. This is avoided with the V octet of 4rd-U. >=20 > Agreed? no, I don't think so, but I can't guarantee that I understand your use = case. as I said previously, I would encourage you to write a draft with the = additional features including use cases you'd see made to MAP. [...] >>> - It has to be faced that this isn't the same algorithm. This = difference is significant because the simpler the algorithm, the simpler = is personnel training, and the simpler if network maintenance.=20 >>=20 >> if you were to give the algorithm to calculate the port ranges and = how to extract the PSID from a port. I think you would see that you end = up with the same as above. >=20 > Are you sure you mean what you wrote?=20 > (I can't find how this would make sense: in 4rd-U, extracting the PSID = knowing its length k is just extracting bits 4 to 3 + k). give me the algorithm to calculate the set of port ranges with 4rd-U. my claim is that it is going to look like the description in MAP. cheers, Ole From cuiyong@tsinghua.edu.cn Sun Feb 5 16:57:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFCB21F859B for ; Sun, 5 Feb 2012 16:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.524 X-Spam-Level: X-Spam-Status: No, score=0.524 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_20=-0.74, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nnlIGBSykxw for ; Sun, 5 Feb 2012 16:57:12 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id C7C9521F8581 for ; Sun, 5 Feb 2012 16:57:11 -0800 (PST) Received: from [219.143.133.79] (helo=[192.168.0.155]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1RuCtH-0002st-MS; Mon, 06 Feb 2012 08:57:07 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 06 Feb 2012 08:57:04 +0800 From: Yong Cui To: Softwires WG Message-ID: Thread-Topic: ask for adoption of draft-qin-softwire-multicast-prefix-option Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 00:57:12 -0000 Dear Softwires wg, As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix in Taipei meeting, the chairs would like to ask for WG adoption on the mailing list. Please review this document and send your comments (especially your opinion on the adoption with your reasons) to the mailing list by two weeks, i.e. Feb. 20. FYI: http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-option/ Yong & Alain From jacni@jacni.com Sun Feb 5 18:24:04 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B1021F852B for ; Sun, 5 Feb 2012 18:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.013 X-Spam-Level: *** X-Spam-Status: No, score=3.013 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-L8t00L+jhD for ; Sun, 5 Feb 2012 18:24:03 -0800 (PST) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 598D421F8514 for ; Sun, 5 Feb 2012 18:24:02 -0800 (PST) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 17F323801D2 for ; Sun, 5 Feb 2012 21:24:01 -0500 (EST) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 5C4173400BB for ; Mon, 6 Feb 2012 10:23:59 +0800 (CST) Received: from [114.81.86.160] (unknown [114.81.86.160]) by app (Coremail) with SMTP id +AWowJC7SQSkOS9P4jdpAA--.28659S2; Mon, 06 Feb 2012 10:23:47 +0800 (CST) Message-ID: <4F2F3A6C.5090002@jacni.com> Date: Mon, 06 Feb 2012 10:26:52 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Content-Type: multipart/alternative; boundary="------------030301070400000102010108" X-CM-TRANSID: +AWowJC7SQSkOS9P4jdpAA--.28659S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGFWDtrWxtr1kuF1rWF4fAFb_yoWrWFWDpa 9ayrsxWw4DJr18Gwn7Xw4fZwnYvrn3XF47AFy5Jw1Fkr98Z3W0yF40kw1Fvay8ZryrAF47 Xr4j9ry5AFs8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07j6wZcUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIQEko7lP+F8gAAss Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 02:24:04 -0000 This is a multi-part message in MIME format. --------------030301070400000102010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, On 1/30/2012 7:31 PM, Ole Trøan wrote: > hi, > > the MAP (Mapping of address and port) design team has now written and published the following sets of drafts. > > the base document (port mapping algorithm): > http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 > http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt > > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 > > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 > > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 > > there is a MAP deployment document coming soon. > > the solution described in this set of documents, are written to satisfy the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an RFC > - develop a protocol specification response to the solution > motivation document; this work item will not be taken through > > in the design team's view, this set of documents are ready to be adopted as working group documents. No objection to the adoption of the base document, with some comments (sorry if they've been discussed ever), please check below. BTW, another question, I can' t remember the conclusion when the DT was chartered, whether the -E and -T were the missions of the DT, or not? ---------------------------------------------------- 1. Section 4., ... The forwarding function uses the MRT to make forwarding decisions. The table consist of the mapping rules. An entry in the table consists of an IPv4 prefix and PSID. The normal best matching prefix algorithm is used. With a maximum key length of 48 (32 + 16). E.g. with a sharing ratio of 64 (6 bit PSID length) a host route for this CE would be a /38 (32 + 6). I'm confused here. The forwarding is based on routing tables (while IMHO the Section 5.3 & 5.4 state it clearer), the implementations may vary while the basic logic could be: Each FMR should install one corresponding route in the IPv4 RIB, like, Rule IPv4 prefix -> "connected", MAP Interface1 For outbound traffic from the private network, when the IPv4 RIB lookup is performed, it should hit one element with a MAP interface, which can be used as the pointer to the correct FMR in the MRT, to form the MAP IPv6 address of the destination. 2. Section 5.1.3., more text about what the "offset bits" is for, may need to be added, something like, "The length of offset bits determines the excluded ports ..." 3. Section 5.2., ... The offset of the EA bits field in the IPv6 address is equal to the BMR Rule IPv6 prefix length. The length of the EA bits field (o) is given by the BMR Rule EA-bits length. The sum of the Rule IPv6 Prefix length and the Rule EA-bits length MUST be less or equal than the End-user IPv6 prefix length. The prefix6-len + EA-bits len must be equal to the End-user IPv6 prefix length, why there is a "less than"? Any reasonable use case about it? 4. Section 6., ... In an encapsulation solution, an IPv4 address and port is mapped to an IPv6 address. This is the address of the tunnel end point of the receiving MAP CE. For traffic outside the MAP domain, the IPv6 tunnel end point address is the IPv6 address of the BR. The interface-id used for all MAP nodes in the domain MUST be deterministic. How to do that, to make the interface-id deterministic? By the interface-id formula specified? ... The encoding of the full IPv4 address into the interface identifier, both for the source and destination IPv6 addresses have been shown to be useful for troubleshooting. Does this statement apply to translation only, or to both? ---------------------------------------------------------- Cheers, Jacni > > comments? > > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --------------030301070400000102010108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

On 1/30/2012 7:31 PM, Ole Trøan wrote: 
hi,

the MAP (Mapping of address and port) design team has now written and published the following sets of drafts.

the base document (port mapping algorithm):
  http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03
  http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt

the encapsulation document (MAP-E):
  http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00

the translation document (MAP-T):
  http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00

the DHCP option (MAP-DHCP):
  http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02

there is a MAP deployment document coming soon.

the solution described in this set of documents, are written to satisfy the following from the softwires charter:
   4. Developments for stateless legacy IPv4 carried over IPv6 
      - develop a solution motivation document to be published as an RFC 
      - develop a protocol specification response to the solution 
        motivation document; this work item will not be taken through 

in the design team's view, this set of documents are ready to be adopted as working group documents.

No objection to the adoption of the base document, with some comments (sorry if they've been discussed ever), please check below.
BTW, another question, I can' t remember the conclusion when the DT was chartered, whether the -E and -T were the missions of the DT, or not?


----------------------------------------------------
1. Section 4., ...

   The forwarding function uses the MRT to make forwarding decisions.
   The table consist of the mapping rules.  An entry in the table
   consists of an IPv4 prefix and PSID.  The normal best matching prefix
   algorithm is used.  With a maximum key length of 48 (32 + 16).  E.g.
   with a sharing ratio of 64 (6 bit PSID length) a host route for this
   CE would be a /38 (32 + 6).

I'm confused here. The forwarding is based on routing tables (while IMHO the Section 5.3 & 5.4 state it clearer),
the implementations may vary while the basic logic could be:
Each FMR should install one corresponding route in the IPv4 RIB, like,

Rule IPv4 prefix -> "connected", MAP Interface1

For outbound traffic from the private network, when the IPv4 RIB lookup is
performed, it should hit one element with a MAP interface, which can be
used as the pointer to the correct FMR in the MRT, to form the MAP IPv6
address of the destination.


2. Section 5.1.3., more text about what the "offset bits" is for, may need to
be added, something like, "The length of offset bits determines the excluded
ports ..."


3. Section 5.2., ...

   The offset of the EA bits field in the IPv6 address is equal to the
   BMR Rule IPv6 prefix length.  The length of the EA bits field (o) is
   given by the BMR Rule EA-bits length.  The sum of the Rule IPv6
   Prefix length and the Rule EA-bits length MUST be less or equal than
   the End-user IPv6 prefix length.

The prefix6-len + EA-bits len must be equal to the End-user IPv6 prefix
length, why there is a "less than"? Any reasonable use case about it?


4. Section 6.,  ...

   In an encapsulation solution, an IPv4 address and port is mapped to
   an IPv6 address.  This is the address of the tunnel end point of the
   receiving MAP CE.  For traffic outside the MAP domain, the IPv6
   tunnel end point address is the IPv6 address of the BR.  The
   interface-id used for all MAP nodes in the domain MUST be
   deterministic.

How to do that, to make the interface-id deterministic? By the
interface-id formula specified?

   ...

   The encoding of the full IPv4 address into the interface identifier,
   both for the source and destination IPv6 addresses have been shown to
   be useful for troubleshooting.

Does this statement apply to translation only, or to both?
----------------------------------------------------------


Cheers,
Jacni


comments?

for the MAP design team,
Ole
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
--------------030301070400000102010108-- From yiu_lee@cable.comcast.com Sun Feb 5 18:32:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6090C21F8491 for ; Sun, 5 Feb 2012 18:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.847 X-Spam-Level: X-Spam-Status: No, score=-104.847 tagged_above=-999 required=5 tests=[AWL=3.616, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekOrC27B30ow for ; Sun, 5 Feb 2012 18:32:22 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id AA3FD21F846C for ; Sun, 5 Feb 2012 18:32:21 -0800 (PST) Received: from ([24.40.56.116]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.150783176; Sun, 05 Feb 2012 21:32:18 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Sun, 5 Feb 2012 21:32:18 -0500 From: "Lee, Yiu" To: Yong Cui , Softwires WG Thread-Topic: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option Thread-Index: AQHM5HeKNgAOiJ30XkeLmmZpWXKgvw== Date: Mon, 6 Feb 2012 02:32:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <9468AAA733ED9D42907D8A608E305172@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 02:32:22 -0000 I support to adopt this draft. On 2/5/12 7:57 PM, "Yong Cui" wrote: >Dear Softwires wg, > > >As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix in >Taipei meeting, the chairs would like to ask for WG adoption on the >mailing list. Please review this document and send your comments >(especially your opinion on the adoption with your reasons) to the mailing >list by two weeks, i.e. Feb. 20. > >FYI:=20 >http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-option >/ > > >Yong & Alain > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From dxhbupt@gmail.com Sun Feb 5 20:48:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1257921F84D6 for ; Sun, 5 Feb 2012 20:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0dwhfIj0u+c for ; Sun, 5 Feb 2012 20:48:11 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5781D21F8456 for ; Sun, 5 Feb 2012 20:48:11 -0800 (PST) Received: by wibhm9 with SMTP id hm9so4980432wib.31 for ; Sun, 05 Feb 2012 20:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NmfU5U8R7OW10q/EA9ub9504Od+jwORKIdl26x9OXrE=; b=sHN2vSZ9EQ2Bo5+miFLgvA17B0IzbLrbp2Pu0jJuBid47cqTzaRu17m32z7kvPACQ9 PYgZ9rcOTURtmQTc2W63fgMzBdyVfzZ8as/SP3mmLH7CHDZXJXpcEdhNDO1YPPzHes/u YHFs5S1HkUkoVwotBKBNoCvccYew4AsUKuh08= MIME-Version: 1.0 Received: by 10.180.103.132 with SMTP id fw4mr32208896wib.3.1328503690301; Sun, 05 Feb 2012 20:48:10 -0800 (PST) Received: by 10.180.98.103 with HTTP; Sun, 5 Feb 2012 20:48:10 -0800 (PST) Date: Mon, 6 Feb 2012 12:48:10 +0800 Message-ID: From: Xiaohong Deng To: softwires@ietf.org Content-Type: multipart/alternative; boundary=f46d04428e048b125904b8445e85 Subject: [Softwires] Open source code available for delivery IPv4 multicast over DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 04:48:12 -0000 --f46d04428e048b125904b8445e85 Content-Type: text/plain; charset=ISO-8859-1 FYI, mB4 implementation of draft-ietf-softwire-dslite-multicast is available via http://sourceforge.net/projects/mb4/ Cheers, Xiaohong --f46d04428e048b125904b8445e85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

FYI, mB4 implementation o= f draft-ietf-softwire-dslite-multicast is available via http://sourceforge.net= /projects/mb4/

=A0

Cheers,

Xiaohong


--f46d04428e048b125904b8445e85-- From despres.remi@laposte.net Mon Feb 6 00:24:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEC321F85D7 for ; Mon, 6 Feb 2012 00:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlb6kuMDphtz for ; Mon, 6 Feb 2012 00:24:33 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id A16AE21F85DF for ; Mon, 6 Feb 2012 00:24:30 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9DE90940120; Mon, 6 Feb 2012 09:24:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> Date: Mon, 6 Feb 2012 09:24:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: [Softwires] MAP & 4rd-U - Preserving freedom of subnet-prefixes (V octet) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 08:24:33 -0000 Le 2012-02-05 =E0 10:05, Ole Tr=F8an a =E9crit : ... >>> what happens with 4rd-U if the End-user IPv6 prefix is e.g a /96? >>> and the V-bits are not adhered to? >>=20 >> If the End-user doesn't support 4rd-U, nothing to be said.=20 >> If 4rd-U is enabled, any prefix longer than /64 that matches a = Mapping rule MUST have the V octet. >>=20 >> If any you have a case where this isn't sufficient, I will look at = it. >=20 > MAP is more flexible with regards to not depending on the V octet. (a) Which flexibility? To do what?=20 (b) Do you negate that: - with MAP as is, an IPv6 site may have to change its assignment of = subnet prefixes to support MAP - This is never needed with 4rd-U, thanks to the V octet. RD From ichiroumakino@gmail.com Mon Feb 6 00:33:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40D21F85D1 for ; Mon, 6 Feb 2012 00:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKdJ1xTPyMaq for ; Mon, 6 Feb 2012 00:33:15 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB12921F85C9 for ; Mon, 6 Feb 2012 00:33:14 -0800 (PST) Received: by werm10 with SMTP id m10so5015889wer.31 for ; Mon, 06 Feb 2012 00:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=BeOzZ0ejV3K5rLgm9QE1wO/TNkLGdvKcZOHvEVlO7Kg=; b=KbVp5aWOphHtLRXHXZUdnbRL9yii6MmqQggN5Wycmle4ZY1zmrbjnYHmLeAsNfFjRw fwrqFUV66tIpxby9kqRWE7pMYFQsSefNw+rzL4sJmQVT5I3cpYFMsRnWvvg7AsqaHI1l G7KQDBbNey213Za0INVbYDufOEYcu3pjpGYP4= Received: by 10.216.137.25 with SMTP id x25mr6434457wei.55.1328517193885; Mon, 06 Feb 2012 00:33:13 -0800 (PST) Received: from [10.147.13.62] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ep3sm26736633wib.10.2012.02.06.00.33.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 00:33:13 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> Date: Mon, 6 Feb 2012 09:33:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP & 4rd-U - Preserving freedom of subnet-prefixes (V octet) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 08:33:15 -0000 Remi, >>>> what happens with 4rd-U if the End-user IPv6 prefix is e.g a /96? >>>> and the V-bits are not adhered to? >>>=20 >>> If the End-user doesn't support 4rd-U, nothing to be said.=20 >>> If 4rd-U is enabled, any prefix longer than /64 that matches a = Mapping rule MUST have the V octet. >>>=20 >>> If any you have a case where this isn't sufficient, I will look at = it. >>=20 >> MAP is more flexible with regards to not depending on the V octet. >=20 > (a) Which flexibility? To do what?=20 supports arbitrary end-user IPv6 prefix length, without regard for = 'magic bits' in the interface-id. > (b) Do you negate that: > - with MAP as is, an IPv6 site may have to change its assignment of = subnet prefixes to support MAP only if the first subnet in the end-user IPv6 prefix is used by another = internal router, that isn't going to act as a MAP CE. > - This is never needed with 4rd-U, thanks to the V octet. renumbering is in any case going to happen in the home, and we have to = design our protocols to deal with it. can we just agree to disagree on the V-octet, and not spend any more = working group time on it? it would be good if you wrote up a more = detailed analysis in a separate draft, so the considerations are kept = somewhere. cheers, Ole From despres.remi@laposte.net Mon Feb 6 00:52:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CDE21F85EA for ; Mon, 6 Feb 2012 00:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtlBIpVANWTc for ; Mon, 6 Feb 2012 00:52:07 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E42F21F85DF for ; Mon, 6 Feb 2012 00:52:06 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 48C88700061E; Mon, 6 Feb 2012 09:52:05 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id C0CDD70002D8; Mon, 6 Feb 2012 09:52:04 +0100 (CET) X-SFR-UUID: 20120206085204789.C0CDD70002D8@msfrf2114.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> Date: Mon, 6 Feb 2012 09:52:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: [Softwires] Checksum neutrality and L4-protocol independence X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 08:52:08 -0000 Le 2012-02-05 =E0 10:05, Ole Tr=F8an a =E9crit : ... >>> any A+P solution requires support for L4 protocols to extract ports. >>> L4 checksum rewrite, as well as port extraction will have to be = supported for all new L4 protocols. >>> the L4 checksum rewrite approach can work with any checksum = algorithm. >>> that said, do we really think NAT44s will be upgraded to support any = new L4? >>=20 >> Imagine a variant of the SCTP of RFC4960 is introduced where the = TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis = (not a bad idea IMHO, but here just a hypothesis to answer your point).=20= >> =3D> 4rd-H would be compatible with it without any evolution; RFC6145 = would need an upgrade to support it. >>=20 >> Upgrading NAT44s to support this SCTP-bis would be trivial (ports as = the same place as usual can be mapped as usual. >=20 > my point is that MAP is L4 aware anyway, and has to be modified to = support any new transport protocol. since code modifications have to be = made, then having a checksum neutral function at the network layer = doesn't help much. you still need to change code. L4 rewrite is also = more flexible in that it will support _any_ checksum algorithm, and most = importantly is already implemented in every node. Thus, you continue to negate that 4rd-U would support without any change = a protocol such as, for example, a SCTP variant using TCP-like checksum = instead of its CRC32c checksum. This negation is AFAIK based on a lack of understanding: - UDP, TCP, DCCP, SCTP have the same places for port their fields, but = have their own places for their checksum fields.=20 - A solution based on L4 checksum adjustment MUST know _for each = protocol_ where checksum fields are placed. - A solution based on checksum neutrality of IPv6 addresses doesn't need = to know where checksum fields are placed.=20 - For address sharing, knowing places of port fields is sufficient. I added Dan as destination of this mail, hoping to have his comment. RD From despres.remi@laposte.net Mon Feb 6 01:18:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C754621F84D5 for ; Mon, 6 Feb 2012 01:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Vy+6xFtsovL for ; Mon, 6 Feb 2012 01:18:02 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 19A1E21F84AA for ; Mon, 6 Feb 2012 01:18:01 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 461327000613; Mon, 6 Feb 2012 10:18:01 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 881BF7000087; Mon, 6 Feb 2012 10:18:00 +0100 (CET) X-SFR-UUID: 20120206091800557.881BF7000087@msfrf2114.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> Date: Mon, 6 Feb 2012 10:18:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Yong Cui , Ralph Droms Subject: [Softwires] MAP & 4rd-U - Robust Renumbering avoidance (V octet) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 09:18:02 -0000 Le 2012-02-06 =E0 09:33, Ole Tr=F8an a =E9crit : ... >>> MAP is more flexible with regards to not depending on the V octet. >>=20 >> (a) Which flexibility? To do what?=20 >=20 > supports arbitrary end-user IPv6 prefix length, without regard for = 'magic bits' in the interface-id. If you have a use case where CEs need longer that /64 prefixes for = native IPv6, I will look at them and comment. If CE IPv6 prefixes longer than /64 are only used to convey CE IPv4 = addresses, I don't see the problem of having these addresses always = starting at bit 80. (It simplifies at least documentation and = maintenance. Standardization is sometimes making simplifying choices = when nothing functional is lost by making them.) >> (b) Do you negate that: >> - with MAP as is, an IPv6 site may have to change its assignment of = subnet prefixes to support MAP >=20 > only if the first subnet in the end-user IPv6 prefix is used by = another internal router, that isn't going to act as a MAP CE. "Only if", yes, but indeed in this case. Having never to renumber is better than having to renumber in some = cases, and better than having no residual IPv4 service on some subnets. >=20 >> - This is never needed with 4rd-U, thanks to the V octet. >=20 > renumbering is in any case going to happen in the home, Not understood. Renumbering should be avoided if it can (IMHO). > and we have to design our protocols to deal with it. > can we just agree to disagree on the V-octet, and not spend any more = working group time on it? Technical debate is finished if: - You accept that never having to renumber is a useful feature, compared = to having to do it in some cases. - You avoid statements like "renumbering is in any case going to happen = in the home" to negate value of renumbering avoidance. > it would be good if you wrote up a more detailed analysis in a = separate draft, so the considerations are kept somewhere. I will write a comparison table. RD >=20 > cheers, > Ole >=20 >=20 From christian.jacquenet@orange.com Mon Feb 6 01:33:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B19F21F85DF for ; Mon, 6 Feb 2012 01:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JmpfCmdlKUH for ; Mon, 6 Feb 2012 01:33:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C764C21F85E7 for ; Mon, 6 Feb 2012 01:33:49 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3BAEC18C2B7; Mon, 6 Feb 2012 10:33:49 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1C53E4C017; Mon, 6 Feb 2012 10:33:49 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 6 Feb 2012 10:33:48 +0100 From: To: Yong Cui , Softwires WG Date: Mon, 6 Feb 2012 10:33:48 +0100 Thread-Topic: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option Thread-Index: AczkakRFqB//p/FTRROJpgP+l0u0tgASCajw Message-ID: <31232_1328520829_4F2F9E7D_31232_1555_1_983A1D8DA0DA5F4EB747BF34CBEE5CD1502898183B@PUEXCB1C.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.30.163314 Subject: Re: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 09:33:50 -0000 Hi, I support the adoption of this draft as a softwire WG document. Cheers, Christian. =20 -----Message d'origine----- De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p= art de Yong Cui Envoy=E9 : lundi 6 f=E9vrier 2012 01:57 =C0 : Softwires WG Cc : Yong Cui Objet : [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix= -option Dear Softwires wg, As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix in = Taipei meeting, the chairs would like to ask for WG adoption on the mailing= list. Please review this document and send your comments (especially your = opinion on the adoption with your reasons) to the mailing list by two weeks= , i.e. Feb. 20. FYI:=20 http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-option/ Yong & Alain _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. From ichiroumakino@gmail.com Mon Feb 6 01:37:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1432221F8456 for ; Mon, 6 Feb 2012 01:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpOEx4a0irLt for ; Mon, 6 Feb 2012 01:37:25 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70A3D21F8447 for ; Mon, 6 Feb 2012 01:37:24 -0800 (PST) Received: by werm10 with SMTP id m10so5064531wer.31 for ; Mon, 06 Feb 2012 01:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=cJ+e98hs4wVsRffnjNYi6rlWRn9J9oEx7OXFpwyyRsA=; b=cpmr1ZAmkIvv0vuqlXZzlaY0pOMYbt4hzeDYr8y4GqEcRdAN+UY/5DPNsNFNLUtMP5 eJkRR4sL9TbDOIANky4BGrmbuy0K3ud5+IZm5h/gwfiAw3mESg9dGK46c5ZJovxob8uz r04jIizIYdpxYUsZrANygzIIzi4BfD0l6Y4yY= Received: by 10.180.83.70 with SMTP id o6mr657797wiy.19.1328521041044; Mon, 06 Feb 2012 01:37:21 -0800 (PST) Received: from [10.147.13.62] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q2sm24070644wiy.7.2012.02.06.01.37.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 01:37:20 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 6 Feb 2012 10:37:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP & 4rd-U - Robust Renumbering avoidance (V octet) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 09:37:26 -0000 Remi, the V-octet and the CNP, have already been discussed on the mailing = list, and the design team discussed it with you in person. the design team made the choice not to incorporate the V octet nor the = CNP mechanism in its proposal. I don't think it is good use of softwire's time to try to convince me = yet again that these features are worth adding. I've made the proposal that we adopts the design team documents as = working group documents, as the design team has done what it was = chartered to do. and that you write a draft with proposals of what = features you want to see added or changed. then the discussion can = continue on improving these working group documents. cheers, Ole= From shtsuchi@cisco.com Mon Feb 6 09:01:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6B721F869D; Mon, 6 Feb 2012 09:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HvDrxylBllH; Mon, 6 Feb 2012 09:01:41 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B25821F8643; Mon, 6 Feb 2012 09:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2029; q=dns/txt; s=iport; t=1328547700; x=1329757300; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pPqTRhm29sGtwai2xWMA5EN27nFu8AZsgjk54NS4fm8=; b=fmnAIob+yI3IliCCrvZjUShTGcH402uIvvwh65SqscerAorh+3JQmxcS emtfv2V9GmEhgCbOTXs2iJaxLd9FODEnDwAo9P6kILFHJShZXVemzOqSi 84ItZRjhoS7SxvEYGGrEvG/JsgftQdswVTuvwHIq9dLBZcMjkPlaUmdRC U=; X-IronPort-AV: E=Sophos;i="4.73,371,1325462400"; d="scan'208";a="4938292" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 06 Feb 2012 17:01:38 +0000 Received: from [10.70.230.103] (tky-vpn-client-230-103.cisco.com [10.70.230.103]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q16H1YNg018372; Mon, 6 Feb 2012 17:01:35 GMT Message-ID: <4F30076A.4040509@cisco.com> Date: Tue, 07 Feb 2012 02:01:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Softwires@ietf.org, ipv6@ietf.org, dthaler@microsoft.com References: <20120203091850.20674.88003.idtracker@ietfa.amsl.com> In-Reply-To: <20120203091850.20674.88003.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120203091850.20674.88003.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: draft-fu-softwire-4rd-mib@tools.ietf.org, draft-cai-softwire-6rd-mib@tools.ietf.org Subject: [Softwires] Fwd: I-D Action: draft-cai-softwire-6rd-mib-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:01:41 -0000 Dave Thaler,Softwire WG and 6man WG We have published 6rd mib draft. http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-01 6rd MIB is charter item of softwire wg. https://datatracker.ietf.org/wg/softwire/charter/ We felt lack of current IP TUNNEL MIB(RFC4087) to support 6rd and modern tunnel protocol. So the draft described two approaches to support 6rd mib. http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-01#section-5 1.New module approach like a L2TP MIB [RFC3371] 2.Extend IP TUNNEL MIB to support 6rd,4rd and so on. 4rd MIB draft was published on last week. http://tools.ietf.org/html/draft-fu-softwire-4rd-mib-00 Which approach is good for us? We need feedback and comments. I would appreciate any comments. Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-cai-softwire-6rd-mib-01.txt Date: Fri, 3 Feb 2012 17:18:50 +0800 From: Reply-To: To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for 6rd Author(s) : Lei Cai Jacni Qin Shishio Tsuchiya Filename : draft-cai-softwire-6rd-mib-01.txt Pages : 11 Date : 2012-02-03 This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing 6rd devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cai-softwire-6rd-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-cai-softwire-6rd-mib-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From despres.remi@laposte.net Mon Feb 6 09:17:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8880321F8483 for ; Mon, 6 Feb 2012 09:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NCOdlgqy4H8 for ; Mon, 6 Feb 2012 09:17:33 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3021F8484 for ; Mon, 6 Feb 2012 09:17:30 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id DDCB59404E4; Mon, 6 Feb 2012 18:16:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org> Date: Mon, 6 Feb 2012 18:16:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4F901DB4-3356-42BA-B3C9-E958FC8C8B67@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org> To: Alain Durand , Yong Cui , Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: [Softwires] MAP and 4rd-U - how to try to converge X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:17:33 -0000 Alain, Yong, Ralph, First, a little bit of history is IMHO useful to understand where we = are: 1. At the Beijing meeting, end of September, I started, with Professor = Xing Li, Wojciech Dec, and Congxiao Bao, a convergence effort based on = requirements expressed by double-translation and encapsulation = proponents respectively (ref = www.ietf.org/mail-archive/web/softwires/current/msg02994).=20 2. In early October, Alain then entrusted Ole with the task to lead a = team having "to formulate a unified format to be used either in an = encapsulation or double translation mode, for both hub & spokes and mesh = models" (www.ietf.org/mail-archive/web/softwires/current/msg03024) 3. Working on my own, looking for a stateless solution that would be = more completely unified than just the address mapping, I found an = approach for that, called 4rd-U. (Its reversible "header mapping" uses = systematic IPv6 fragment headers, and TCP-checksum neutrality of mapped = addresses. Ref draft-despres-softwire-4rd-u-00) 4. During the Softwire meeting in Taipei, in his report as MAP-team = leader, Ole had a slide stating that checksum neutrality would result = into "destination spray" (i.e. would break TCP!). Time lacking for a = technical challenge of such a claim, this prevented the WG from finding = interest in pursuing the 4rd-U approach. =20 5. In the MAP-team meeting that immediately followed that of the WG, = Ole obtained a rough consensus that features of the 4rd-U proposal = (checksum neutrality and the V octet) would no longer be considered by = the MAP team.=20 6. After that, Ole and I having discussed privately, Ole acknowledged = on the WG list that his statement against checksum neutrality was = technically invalid.=20 7. Some interest for looking more at the 4rd-U solution was then = reported to the chairs, and Alain encouraged me to work on a revised = 4rd-U draft for the next meeting (ref = www.ietf.org/mail-archive/web/softwires/current/msg03296). 8. On December 29, I then posted = tools.ietf.org/html/draft-despres-softwire-4rd-u-02. Following comments = I had received, and accepting that some needs weren't satisfied in = draft-02, I posted on January 28 draft-03 which has two tunnel variants = close to one another (4rd-E for encapsulation, 4rd-H for header = mapping). 9. On January 30, Ole announced to the WG that the 4 related MAP = documents were available (ref = www.ietf.org/mail-archive/web/softwires/current/msg03328). Thus, people involved in the two approaches have clearly done what they = were asked to. Trying to converge between the two approaches is worth attempting = because, as Ole recently wrote: "let us make it clear that these two = solutions are solving exactly the same problem, and they solve it in the = same fundamental way (A+P). the differences we're talking about here are = what whistles, bells (and dongs) we want to add on to the base = specification. consider it a buffet, any feature from one of them can be = applied to the other." Now, the 4rd-U draft is IMHO the best starting point for a = specification that suits implementors that didn't participate in the = work, because it is self-consistent and avoids redundancy. It is also = AFAIK much clearer than the current set of posted MAP document. An example of already achieved convergence is a proposal made by Ole. (It concerns the "BR rewrite fragmentation" item of his table of = www.ietf.org/mail-archive/web/softwires/current/msg03364, i.e. = disambiguation of datagram identifications in packets that go from = shared-address CEs to the Internet.) =20 - The need to do something has been identified for the first time in = the 4rd-U-03 draft. - Ole's proposed solution is simpler than that of the draft. (The need = is satisfied directly in CEs, rather than left for BRs to satisfy it.) Unless a problem would be identified in the mean time, I will adopt = Ole's solution in the next 4rd-U version.=20 Naturally, if Ole would agree to it, he would be most welcome as = co-author of the upgraded unified specification.=20 Best regards, RD From adurand@juniper.net Mon Feb 6 15:39:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F289A21F86B2 for ; Mon, 6 Feb 2012 15:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.192 X-Spam-Level: X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2x+J10vSIw3 for ; Mon, 6 Feb 2012 15:39:56 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 60E5821F86AB for ; Mon, 6 Feb 2012 15:39:53 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTzBkxEqBeVJu5PO6eV2IFXSAD2TqR9Ze@postini.com; Mon, 06 Feb 2012 15:39:56 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 6 Feb 2012 15:39:47 -0800 From: Alain Durand To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Mon, 6 Feb 2012 15:39:46 -0800 Thread-Topic: MAP and 4rd-U Thread-Index: AczlKJxz/paEVbgAQzWEXbmy/53iOw== Message-ID: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org> <4F901DB4-3356-42BA-B3C9-E958FC8C8B67@laposte.net> In-Reply-To: <4F901DB4-3356-42BA-B3C9-E958FC8C8B67@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: [Softwires] MAP and 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 23:39:57 -0000 R=E9mi, Ole: I'll be in Paris this week for v6 world congres, and I'm planning to spend = time with the two of you to make progress on this issue. Hopefully we will have good news for the wg by the end of the week. - Alain. From rdroms@cisco.com Mon Feb 6 16:09:27 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB521F85C3 for ; Mon, 6 Feb 2012 16:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSEJxG7jIbIr for ; Mon, 6 Feb 2012 16:09:26 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A90C21F85C0 for ; Mon, 6 Feb 2012 16:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=394; q=dns/txt; s=iport; t=1328573366; x=1329782966; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zK+QihNvhMy6bM6ry+xlMZMqq3/vnn7voiNihbPMFHM=; b=Rh2FYaiaFuf9/2b+6mcgeN96OPaflGwTRX//TH/mxR4IFOZciqHkLdeX U7E8bro3RhJ26qHQXf/xqAuUxkXTJb1G+O11ly0ZiVk/GqGX854ZC6C4C XTBeMJfZ0l+7ZltWixR2d5p6qNrWfzw0wvdtCCsKWLHryqCWbihad9XXZ U=; X-IronPort-AV: E=Sophos;i="4.73,373,1325462400"; d="scan'208";a="27340484" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 07 Feb 2012 00:09:26 +0000 Received: from [10.21.76.191] ([10.21.76.191]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1709OCR013060; Tue, 7 Feb 2012 00:09:25 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: Date: Mon, 6 Feb 2012 16:03:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org> <4F901DB4-3356-42BA-B3C9-E958FC8C8B67@laposte.net> To: Alain Durand X-Mailer: Apple Mail (2.1251.1) Cc: Ralph Droms , Yong Cui , Softwires WG Subject: Re: [Softwires] MAP and 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 00:09:27 -0000 I will be in Paris as well; hoping I can join the conversation... - Ralph On Feb 6, 2012, at 3:39 PM 2/6/12, Alain Durand wrote: > R=E9mi, Ole: >=20 > I'll be in Paris this week for v6 world congres, and I'm planning to = spend time with the two of you to make progress on this issue. > Hopefully we will have good news for the wg by the end of the week. >=20 > - Alain. >=20 From bingxuere@gmail.com Mon Feb 6 20:30:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEB711E80E2 for ; Mon, 6 Feb 2012 20:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaxGL1uuBnOA for ; Mon, 6 Feb 2012 20:30:44 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7F211E80E0 for ; Mon, 6 Feb 2012 20:30:44 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so5045407wgb.13 for ; Mon, 06 Feb 2012 20:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=h4H4jFAlm3qHwXZdW03GNSdkh+++K0+KQFfpRfKeOwU=; b=d1mCAQcnVZvIkL//dametAFgs2YXFvTV9cIPW8a1hFvCjwtvJ+SCMnf9TCD5EvxQHC 1Gf4CSnfQItgGSXvokPT3h5qW1q30YMO0fgX5jF5JPUt+9405ExOnoVx0cYoqWq5+Xur uLf158mtjS+Mm3sXBng9KLLbIpzncUl3YTUJM= Received: by 10.180.99.100 with SMTP id ep4mr31644904wib.7.1328589043383; Mon, 06 Feb 2012 20:30:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.113.133 with HTTP; Mon, 6 Feb 2012 20:30:03 -0800 (PST) In-Reply-To: <31232_1328520829_4F2F9E7D_31232_1555_1_983A1D8DA0DA5F4EB747BF34CBEE5CD1502898183B@PUEXCB1C.nanterre.francetelecom.fr> References: <31232_1328520829_4F2F9E7D_31232_1555_1_983A1D8DA0DA5F4EB747BF34CBEE5CD1502898183B@PUEXCB1C.nanterre.francetelecom.fr> From: Qiong Date: Tue, 7 Feb 2012 12:30:03 +0800 Message-ID: To: christian.jacquenet@orange.com Content-Type: multipart/alternative; boundary=f46d04428e5cfbbc2704b8583dc4 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 04:30:45 -0000 --f46d04428e5cfbbc2704b8583dc4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 support On Mon, Feb 6, 2012 at 5:33 PM, wrote: > Hi, > > I support the adoption of this draft as a softwire WG document. > > Cheers, > > Christian. > > > -----Message d'origine----- > De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la > part de Yong Cui > Envoy=C3=A9 : lundi 6 f=C3=A9vrier 2012 01:57 > =C3=80 : Softwires WG > Cc : Yong Cui > Objet : [Softwires] ask for adoption of > draft-qin-softwire-multicast-prefix-option > > Dear Softwires wg, > > > As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix i= n > Taipei meeting, the chairs would like to ask for WG adoption on the maili= ng > list. Please review this document and send your comments (especially your > opinion on the adoption with your reasons) to the mailing list by two > weeks, i.e. Feb. 20. > > FYI: > http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-optio= n/ > > > Yong & Alain > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorization. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange shall not be liable if > this message was modified, changed or falsified. > Thank you. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --f46d04428e5cfbbc2704b8583dc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 support

On Mon, Feb 6, 2012 at 5:33 PM= , <= christian.jacquenet@orange.com> wrote:
Hi,

I support the adoption of this draft as a softwire WG document.

Cheers,

Christian.


-----Message d'origine-----
De : softwires-bounces@ietf.o= rg [mailto:softwires-boun= ces@ietf.org] De la part de Yong Cui
Envoy=C3=A9 : lundi 6 f=C3=A9vrier 2012 01:57
=C3=80 : Softwires WG
Cc : Yong Cui
Objet : [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix= -option

Dear Softwires wg,


As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix in = Taipei meeting, the chairs would like to ask for WG adoption on the mailing= list. Please review this document and send your comments (especially your = opinion on the adoption with your reasons) to the mailing list by two weeks= , i.e. Feb. 20.

FYI:
http://datatracker.ietf.org/doc/draft-qin-so= ftwire-multicast-prefix-option/


Yong & Alain


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________________________= __________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified.
Thank you.

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--f46d04428e5cfbbc2704b8583dc4-- From despres.remi@laposte.net Tue Feb 7 02:13:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7914E21F86B3 for ; Tue, 7 Feb 2012 02:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWy+3jTnaVjG for ; Tue, 7 Feb 2012 02:13:14 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB721F869F for ; Tue, 7 Feb 2012 02:13:13 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id 28D0F7000144; Tue, 7 Feb 2012 11:13:12 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id B78EF7000133; Tue, 7 Feb 2012 11:13:11 +0100 (CET) X-SFR-UUID: 20120207101311751.B78EF7000133@msfrf2119.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2012 11:13:11 +0100 Message-Id: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> To: Ole Troan , Tetsuya Murakami , Wojciech Dec Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:13:14 -0000 Hello Ole, Tetsuya-san, Wojciech, In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces = its dual-stack routing by IPv6-only routing. For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. (By replacing each IPv4 route by an equivalent IPv6 route, it ensures = that all customers keep their IPv4 addresses.) For this to work, the 4rd-U draft has a bit that, in the hub&spoke case, = differs between CE-to-BR and BR-to-CE directions. Thus, packets sent to = a CE take different routes depending on whether sent by a CE or a BR. I don't see how the equivalent could work with the MAP documents you = edited. Is it that such a use case is out of scope for MAP? Or did I miss something? Cheers, RD From satoru.matsushima@gmail.com Tue Feb 7 04:07:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBAE21F848C for ; Tue, 7 Feb 2012 04:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp-bvph-P7DZ for ; Tue, 7 Feb 2012 04:07:45 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3DCA21F859A for ; Tue, 7 Feb 2012 04:07:44 -0800 (PST) Received: by werm10 with SMTP id m10so6129456wer.31 for ; Tue, 07 Feb 2012 04:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Di41KP7oErWw6GF9XnUYtOTETkJ3VfEovlb8UeqUKtk=; b=waVWaf5SwJ46YtJFpzFSLPQ1SfgVkvBmXaGU/USb2D6ytZw2YzWyfSPmIPgp0Llqq4 BLk9fY3hVhbfzZvV3mcB8g2B3VqQe7QZS8m/ejHqd7nIoqXkvhYZIA8bQlVN9OTLWPcs RJi1LmKOpozqMnTYvWR8T9eJoT86OZd/2nbao= Received: by 10.216.139.9 with SMTP id b9mr8634995wej.23.1328616463600; Tue, 07 Feb 2012 04:07:43 -0800 (PST) Received: from [10.115.194.117] (62-50-193-163.client.stsn.net. [62.50.193.163]) by mx.google.com with ESMTPS id hb10sm3256322wib.10.2012.02.07.04.07.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 04:07:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> Date: Tue, 7 Feb 2012 13:07:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:07:48 -0000 Hi Remi-san, On 2012/02/07, at 11:13, R=C3=A9mi Despr=C3=A9s wrote: > Hello Ole, Tetsuya-san, Wojciech, >=20 > In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces = its dual-stack routing by IPv6-only routing. > For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. > (By replacing each IPv4 route by an equivalent IPv6 route, it ensures = that all customers keep their IPv4 addresses.) >=20 I don't think that it could work as you explained in that section. For = example, the BR would need to check a received packet from a CE whether = it has correct source address in mapping rule or not. It means that the = BR must know all address mappings for CE between IPv4 addresses and IPv6 = prefixes. Is it correct understanding?=20 I think that operators who already deploy such dual-stack network is = supposed that they have address mapping table, they can provision each = CE individually, and also they are capable to distribute the default = mapping rule since they should install it into the CEs. In that = situation, what's the motivation of why the operator want to provision = with only default mapping rule? cheers, --satoru > For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >=20 > I don't see how the equivalent could work with the MAP documents you = edited. > Is it that such a use case is out of scope for MAP? > Or did I miss something? >=20 > Cheers, > RD >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Tue Feb 7 04:11:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154B321F8702 for ; Tue, 7 Feb 2012 04:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY2CMjWk2mNV for ; Tue, 7 Feb 2012 04:11:18 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4A721F859A for ; Tue, 7 Feb 2012 04:11:18 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so5271871wgb.13 for ; Tue, 07 Feb 2012 04:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=mnfo3Y3clQQeK/PeKAOgB2oILwL6n0A8ZQD6S3IvK74=; b=EDp3iFmSncJUd4zzuybtay638sSbIYlWj2SJ7Vfa5MKmyMbJfNzO0EhECAeP960qKO MnTulIp0SMNs/cm6vYjfL7JdNnrb/aKPPjwW2Sn2aM5HaHg2lQn4ieZz6iB6Y+cYf9O9 OioLZm+4zGuHfW0kt9nKH4vNLCl7oGMbU+1tc= Received: by 10.180.87.8 with SMTP id t8mr19327937wiz.15.1328616677507; Tue, 07 Feb 2012 04:11:17 -0800 (PST) Received: from dhcp-10-61-103-54.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n5sm56055032wiw.7.2012.02.07.04.11.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 04:11:16 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 7 Feb 2012 13:11:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB6D918-EC14-4E72-A7D6-7C93969C77D6@employees.org> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org> <4F901DB4-3356-42BA-B3C9-E958FC8C8B67@laposte.net> To: Alain Durand X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:11:19 -0000 Alain, > I'll be in Paris this week for v6 world congres, and I'm planning to = spend time with the two of you to make progress on this issue. > Hopefully we will have good news for the wg by the end of the week. excellent; this is high priority for me, so please let me know a time = suitable for yourselves. cheers, Ole From ichiroumakino@gmail.com Tue Feb 7 04:16:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7414621F86B3 for ; Tue, 7 Feb 2012 04:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMGe2rIWj5Xt for ; Tue, 7 Feb 2012 04:16:38 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B63F121F86B2 for ; Tue, 7 Feb 2012 04:16:37 -0800 (PST) Received: by wibhm9 with SMTP id hm9so6239704wib.31 for ; Tue, 07 Feb 2012 04:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=SJkWjQTHu1sU1/pSfxcWTQH4GZ/7qHJgf6jTKz0g/Go=; b=UGcomEISLv9YPc6/avuh5NKqlmtcLbOE++5sLKT/N/f/j7RcwGXT1y3fu71FISv/eU R3sfPLqR8oYQG8B9jOHfT/I97b8jes5IDSyU9QFf/g+rMMILbGj8xnnzo7DF4eb5sESe EPc10grxk/iAqsuwBA/7/XLgWtm3M6FnvJQi8= Received: by 10.180.83.97 with SMTP id p1mr22832375wiy.19.1328616996924; Tue, 07 Feb 2012 04:16:36 -0800 (PST) Received: from dhcp-10-61-103-54.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n5sm56095943wiw.7.2012.02.07.04.16.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 04:16:36 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> Date: Tue, 7 Feb 2012 13:16:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48E1E89C-0CB2-4FE8-B3CB-13D556F46AE1@employees.org> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:16:38 -0000 Remi, > In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces = its dual-stack routing by IPv6-only routing. > For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. > (By replacing each IPv4 route by an equivalent IPv6 route, it ensures = that all customers keep their IPv4 addresses.) >=20 > For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >=20 > I don't see how the equivalent could work with the MAP documents you = edited. > Is it that such a use case is out of scope for MAP? > Or did I miss something? injecting IPv4 routing into the IPv6 routing table is considered a bad = idea. that was what caused Automatic tunnelling and IPv4 compatible = address in RFC1933 to be deprecated. cheers, Ole= From despres.remi@laposte.net Tue Feb 7 04:56:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C187F21F8751 for ; Tue, 7 Feb 2012 04:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPz5U4yIPYA4 for ; Tue, 7 Feb 2012 04:56:18 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA7321F8745 for ; Tue, 7 Feb 2012 04:56:17 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id BDF4A7000076; Tue, 7 Feb 2012 13:56:16 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 1970370000BE; Tue, 7 Feb 2012 13:56:15 +0100 (CET) X-SFR-UUID: 20120207125616104.1970370000BE@msfrf2206.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <48E1E89C-0CB2-4FE8-B3CB-13D556F46AE1@employees.org> Date: Tue, 7 Feb 2012 13:49:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <179E0E92-1E0F-414C-87CD-D782B9AF4577@laposte.net> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <48E1E89C-0CB2-4FE8-B3CB-13D556F46AE1@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:56:18 -0000 Le 2012-02-07 =E0 13:16, Ole Tr=F8an a =E9crit : > Remi, >=20 >> In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces = its dual-stack routing by IPv6-only routing. >> For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. >> (By replacing each IPv4 route by an equivalent IPv6 route, it ensures = that all customers keep their IPv4 addresses.) >>=20 >> For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >>=20 >> I don't see how the equivalent could work with the MAP documents you = edited. >> Is it that such a use case is out of scope for MAP? >> Or did I miss something? >=20 > injecting IPv4 routing into the IPv6 routing table is considered a bad = idea. that was what caused Automatic tunnelling and IPv4 compatible = address in RFC1933 to be deprecated. - Reference? - Should we take it, then, that you reject moving from DS routing to = IPV6-only routing without address/prefix changes as a use case you are = interested in? RD >=20 > cheers, > Ole From despres.remi@laposte.net Tue Feb 7 05:03:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414B221F8747 for ; Tue, 7 Feb 2012 05:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKpn4UFBFsKh for ; Tue, 7 Feb 2012 05:03:33 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 64BDF21F8642 for ; Tue, 7 Feb 2012 05:03:31 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id EBC7F9401A8; Tue, 7 Feb 2012 14:03:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> Date: Tue, 7 Feb 2012 14:03:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:03:34 -0000 Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit : > Hi Remi-san, >=20 > On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote: >=20 >> Hello Ole, Tetsuya-san, Wojciech, >>=20 >> In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces = its dual-stack routing by IPv6-only routing. >> For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. >> (By replacing each IPv4 route by an equivalent IPv6 route, it ensures = that all customers keep their IPv4 addresses.) >>=20 >=20 > I don't think that it could work as you explained in that section. For = example, the BR would need to check a received packet from a CE whether = it has correct source address in mapping rule or not. It means that the = BR must know all address mappings for CE between IPv4 addresses and IPv6 = prefixes. Is it correct understanding? Ingress filtering of the domain has checked that the IPv6 source starts = with the delegated IPv6 prefix, a /112 which includes the IPv4 address. = In the 4rd-E case, the BR checks that the source address in the IPv4 = header matches that of the IPv6 address. There is therefore no need for = the BR to know all IPv4 prefixes. At its IPv4 interface, all received = packets start with one of them. At its IPv6 interface, all packets it = receives have an embedded address that starts with one of these = prefixes.=20 > I think that operators who already deploy such dual-stack network is = supposed that they have address mapping table, I would rather suppose that ISPs that have added IPv6-prefix delegation, = say /56s, to an existing IPv4 network did it without mixing their IPv6 = plan with their IPv4 prefixes. I am ready, however, to look seriously at individual cases where choices = were different. Regards, RD > they can provision each CE individually, and also they are capable to = distribute the default mapping rule since they should install it into = the CEs. In that situation, what's the motivation of why the operator = want to provision with only default mapping rule? >=20 > cheers, > --satoru >=20 >> For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >>=20 >> I don't see how the equivalent could work with the MAP documents you = edited. >> Is it that such a use case is out of scope for MAP? >> Or did I miss something? >>=20 >> Cheers, >> RD >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From rajiva@cisco.com Tue Feb 7 05:18:16 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D6221F86D0 for ; Tue, 7 Feb 2012 05:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuSYUbYSxVa0 for ; Tue, 7 Feb 2012 05:18:10 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2C86621F86C9 for ; Tue, 7 Feb 2012 05:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=13260; q=dns/txt; s=iport; t=1328620690; x=1329830290; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=zUNj7PvxUe3I5DoyhRs9YzQ/6AfKkLhdOhj11UIUICI=; b=fNUA3yWYVM6L8JKBdCiJ2X9PnGwTGL78/+cst7NV0l43VrHph+QIKUkS 7x8s8z6qBdVg+SbzVRvfU9pGYg7v2jO9/Dlr4x1eRPVQidnVcHS8hBVUd nm0HnF8h+8KluU8Gf3sd+UkglDn+l+EvgJo0nF0cUqOYQyGmaRPS2Kes/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYGALUjMU+rRDoG/2dsb2JhbABDhQupUm4CgQWBcgEBAQMBAQEBDwEQSwsFCwIBCBgCAiYCAgIlMAEBBBMih1oJm0kBjGWSIwSBL4oGASk3AQcHAoMEBRgCCwIFHAgLIyaCQzNjBIhGjGaOPIQ/ X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208,217";a="29097737" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 07 Feb 2012 13:18:10 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17DI9kN018043; Tue, 7 Feb 2012 13:18:09 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 07:18:09 -0600 Received: from 144.254.231.93 ([144.254.231.93]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Feb 2012 13:18:09 +0000 References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> Content-Transfer-Encoding: 7bit From: "Rajiv Asati (rajiva)" Thread-Topic: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin hub&spoke topology Thread-Index: Aczlmu8+Qyjycgt8RdakpxbHm5D5zw== Content-Type: multipart/alternative; boundary="Apple-Mail-201C0DEA-2789-4114-AE9D-15E2C13D541A"; charset="UTF-8" In-Reply-To: <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> Message-ID: <8EDD7EC1-55FC-4474-8688-7F473DEDE36E@cisco.com> Date: Tue, 7 Feb 2012 08:18:06 -0500 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 07 Feb 2012 13:18:09.0328 (UTC) FILETIME=[EF87CB00:01CCE59A] Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:18:16 -0000 --Apple-Mail-201C0DEA-2789-4114-AE9D-15E2C13D541A Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 PiB0aGUgNHJkLUUgY2FzZSwgdGhlIEJSIGNoZWNrcyB0aGF0IHRoZSBzb3VyY2UgYWRkcmVzcyBp biB0aGUgSVB2NCBoZWFkZXIgbWF0Y2hlcyB0aGF0IG9mIHRoZSBJUHY2IGFkZHJlc3MuIA0KDQpD b3VsZCB0aGlzIGNoZWNrIChhbmQgZmlsdGVyaW5nKSBiZSBkb25lIHdpdGhvdXQgaW5jdXJyaW5n IGEgcGVyZm9ybWFuY2UgcGVuYWx0eT8gDQoNCkNoZWVycywNClJhaml2DQoNClNlbnQgZnJvbSBt eSBQaG9uZQ0KDQpPbiBGZWIgNywgMjAxMiwgYXQgODowMyBBTSwgUsOpbWkgRGVzcHLDqXMgPGRl c3ByZXMucmVtaUBsYXBvc3RlLm5ldD4gd3JvdGU6DQoNCj4gDQo+IExlIDIwMTItMDItMDcgw6Ag MTM6MDcsIFNhdG9ydSBNYXRzdXNoaW1hIGEgw6ljcml0IDoNCj4gDQo+PiBIaSBSZW1pLXNhbiwN Cj4+IA0KPj4gT24gMjAxMi8wMi8wNywgYXQgMTE6MTMsIFLDqW1pIERlc3Byw6lzIHdyb3RlOg0K Pj4gDQo+Pj4gSGVsbG8gT2xlLCBUZXRzdXlhLXNhbiwgV29qY2llY2gsDQo+Pj4gDQo+Pj4gSW4g YSB1c2UgY2FzZSBkZXNjcmliZWQgaW4gdGhlIDRyZC1VIGRyYWZ0IChzZWMgNS4zKSwgYW4gSVNQ IHJlcGxhY2VzIGl0cyBkdWFsLXN0YWNrIHJvdXRpbmcgYnkgSVB2Ni1vbmx5IHJvdXRpbmcuDQo+ Pj4gRm9yIHRoaXMsIGluZGVwZW5kZW50bHkgZnJvbSB0aGUgbnVtYmVyIG9mIElQdjQgcHJlZml4 ZXMgaXQgaGFzIHRvIHN1cHBvcnQsIGl0IHVzZXMgb25seSBvbmUgbWFwcGluZyBydWxlLg0KPj4+ IChCeSByZXBsYWNpbmcgZWFjaCBJUHY0IHJvdXRlIGJ5IGFuIGVxdWl2YWxlbnQgSVB2NiByb3V0 ZSwgaXQgZW5zdXJlcyB0aGF0IGFsbCBjdXN0b21lcnMga2VlcCB0aGVpciBJUHY0IGFkZHJlc3Nl cy4pDQo+Pj4gDQo+PiANCj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBjb3VsZCB3b3JrIGFzIHlv dSBleHBsYWluZWQgaW4gdGhhdCBzZWN0aW9uLiBGb3IgZXhhbXBsZSwgdGhlIEJSIHdvdWxkIG5l ZWQgdG8gY2hlY2sgYSByZWNlaXZlZCBwYWNrZXQgZnJvbSBhIENFIHdoZXRoZXIgaXQgaGFzIGNv cnJlY3Qgc291cmNlIGFkZHJlc3MgaW4gbWFwcGluZyBydWxlIG9yIG5vdC4gSXQgbWVhbnMgdGhh dCB0aGUgQlIgbXVzdCBrbm93IGFsbCBhZGRyZXNzIG1hcHBpbmdzIGZvciBDRSBiZXR3ZWVuIElQ djQgYWRkcmVzc2VzIGFuZCBJUHY2IHByZWZpeGVzLiBJcyBpdCBjb3JyZWN0IHVuZGVyc3RhbmRp bmc/DQo+IA0KPiBJbmdyZXNzIGZpbHRlcmluZyBvZiB0aGUgZG9tYWluIGhhcyBjaGVja2VkIHRo YXQgdGhlIElQdjYgc291cmNlIHN0YXJ0cyB3aXRoIHRoZSBkZWxlZ2F0ZWQgSVB2NiBwcmVmaXgs IGEgLzExMiB3aGljaCBpbmNsdWRlcyB0aGUgSVB2NCBhZGRyZXNzLiBJbiB0aGUgNHJkLUUgY2Fz ZSwgdGhlIEJSIGNoZWNrcyB0aGF0IHRoZSBzb3VyY2UgYWRkcmVzcyBpbiB0aGUgSVB2NCBoZWFk ZXIgbWF0Y2hlcyB0aGF0IG9mIHRoZSBJUHY2IGFkZHJlc3MuIFRoZXJlIGlzIHRoZXJlZm9yZSBu byBuZWVkIGZvciB0aGUgQlIgdG8ga25vdyBhbGwgSVB2NCBwcmVmaXhlcy4gQXQgaXRzIElQdjQg aW50ZXJmYWNlLCBhbGwgcmVjZWl2ZWQgcGFja2V0cyBzdGFydCB3aXRoIG9uZSBvZiB0aGVtLiBB dCBpdHMgSVB2NiBpbnRlcmZhY2UsIGFsbCBwYWNrZXRzIGl0IHJlY2VpdmVzIGhhdmUgYW4gZW1i ZWRkZWQgYWRkcmVzcyB0aGF0IHN0YXJ0cyB3aXRoIG9uZSBvZiB0aGVzZSBwcmVmaXhlcy4gDQo+ IA0KPj4gSSB0aGluayB0aGF0IG9wZXJhdG9ycyB3aG8gYWxyZWFkeSBkZXBsb3kgc3VjaCBkdWFs LXN0YWNrIG5ldHdvcmsgaXMgc3VwcG9zZWQgdGhhdCB0aGV5IGhhdmUgYWRkcmVzcyBtYXBwaW5n IHRhYmxlLA0KPiANCj4gSSB3b3VsZCByYXRoZXIgc3VwcG9zZSB0aGF0IElTUHMgdGhhdCBoYXZl IGFkZGVkIElQdjYtcHJlZml4IGRlbGVnYXRpb24sIHNheSAvNTZzLCB0byBhbiBleGlzdGluZyBJ UHY0IG5ldHdvcmsgZGlkIGl0IHdpdGhvdXQgbWl4aW5nIHRoZWlyIElQdjYgcGxhbiB3aXRoIHRo ZWlyIElQdjQgcHJlZml4ZXMuDQo+IEkgYW0gcmVhZHksIGhvd2V2ZXIsIHRvIGxvb2sgc2VyaW91 c2x5IGF0IGluZGl2aWR1YWwgY2FzZXMgd2hlcmUgY2hvaWNlcyB3ZXJlIGRpZmZlcmVudC4NCj4g DQo+IFJlZ2FyZHMsDQo+IFJEDQo+IA0KPiANCj4gDQo+PiB0aGV5IGNhbiBwcm92aXNpb24gZWFj aCBDRSBpbmRpdmlkdWFsbHksIGFuZCBhbHNvIHRoZXkgYXJlIGNhcGFibGUgdG8gZGlzdHJpYnV0 ZSB0aGUgZGVmYXVsdCBtYXBwaW5nIHJ1bGUgc2luY2UgdGhleSBzaG91bGQgaW5zdGFsbCBpdCBp bnRvIHRoZSBDRXMuIEluIHRoYXQgc2l0dWF0aW9uLCB3aGF0J3MgdGhlIG1vdGl2YXRpb24gb2Yg d2h5IHRoZSBvcGVyYXRvciB3YW50IHRvIHByb3Zpc2lvbiB3aXRoIG9ubHkgZGVmYXVsdCBtYXBw aW5nIHJ1bGU/DQo+PiANCj4+IGNoZWVycywNCj4+IC0tc2F0b3J1DQo+PiANCj4+PiBGb3IgdGhp cyB0byB3b3JrLCB0aGUgNHJkLVUgZHJhZnQgaGFzIGEgYml0IHRoYXQsIGluIHRoZSBodWImc3Bv a2UgY2FzZSwgZGlmZmVycyBiZXR3ZWVuIENFLXRvLUJSIGFuZCBCUi10by1DRSBkaXJlY3Rpb25z LiBUaHVzLCBwYWNrZXRzIHNlbnQgdG8gYSBDRSB0YWtlIGRpZmZlcmVudCByb3V0ZXMgZGVwZW5k aW5nIG9uIHdoZXRoZXIgc2VudCBieSBhIENFIG9yIGEgQlIuDQo+Pj4gDQo+Pj4gSSBkb24ndCBz ZWUgaG93IHRoZSBlcXVpdmFsZW50IGNvdWxkIHdvcmsgd2l0aCB0aGUgTUFQIGRvY3VtZW50cyB5 b3UgZWRpdGVkLg0KPj4+IElzIGl0IHRoYXQgc3VjaCBhIHVzZSBjYXNlIGlzIG91dCBvZiBzY29w ZSBmb3IgTUFQPw0KPj4+IE9yIGRpZCBJIG1pc3Mgc29tZXRoaW5nPw0KPj4+IA0KPj4+IENoZWVy cywNCj4+PiBSRA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPj4+IFNvZnR3aXJlc0Bp ZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdp cmVzDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4gU29mdHdpcmVzQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo= --Apple-Mail-201C0DEA-2789-4114-AE9D-15E2C13D541A Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgY29sb3I9 IiMwMDAwMDAiPnRoZSA0cmQtRSBjYXNlLCB0aGUgQlIgY2hlY2tzIHRoYXQgdGhlIHNvdXJjZSBh ZGRyZXNzIGluIHRoZSBJUHY0IGhlYWRlciBtYXRjaGVzIHRoYXQgb2YgdGhlIElQdjYgYWRkcmVz cy4mbmJzcDs8L2ZvbnQ+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PkNvdWxkIHRo aXMgY2hlY2sgKGFuZCBmaWx0ZXJpbmcpIGJlIGRvbmUgd2l0aG91dCBpbmN1cnJpbmcgYSBwZXJm b3JtYW5jZSBwZW5hbHR5PyZuYnNwOzxicj48YnI+Q2hlZXJzLDxkaXY+UmFqaXY8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBQaG9uZTwvZGl2PjwvZGl2PjxkaXY+PGJyPk9u IEZlYiA3LCAyMDEyLCBhdCA4OjAzIEFNLCBSw6ltaSBEZXNwcsOpcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmRlc3ByZXMucmVtaUBsYXBvc3RlLm5ldCI+ZGVzcHJlcy5yZW1pQGxhcG9zdGUubmV0PC9h PiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+TGUgMjAxMi0wMi0w NyDDoCAxMzowNywgU2F0b3J1IE1hdHN1c2hpbWEgYSDDqWNyaXQgOjwvc3Bhbj48YnI+PHNwYW4+ PC9zcGFuPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5IaSBSZW1pLXNhbiw8L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+ PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5PbiAyMDEyLzAy LzA3LCBhdCAxMToxMywgUsOpbWkgRGVzcHLDqXMgd3JvdGU6PC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SGVs bG8gT2xlLCBUZXRzdXlhLXNhbiwgV29qY2llY2gsPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5JbiBhIHVzZSBjYXNlIGRl c2NyaWJlZCBpbiB0aGUgNHJkLVUgZHJhZnQgKHNlYyA1LjMpLCBhbiBJU1AgcmVwbGFjZXMgaXRz IGR1YWwtc3RhY2sgcm91dGluZyBieSBJUHY2LW9ubHkgcm91dGluZy48L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+Rm9yIHRoaXMsIGluZGVwZW5kZW50bHkgZnJvbSB0aGUgbnVtYmVy IG9mIElQdjQgcHJlZml4ZXMgaXQgaGFzIHRvIHN1cHBvcnQsIGl0IHVzZXMgb25seSBvbmUgbWFw cGluZyBydWxlLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4oQnkgcmVwbGFjaW5n IGVhY2ggSVB2NCByb3V0ZSBieSBhbiBlcXVpdmFsZW50IElQdjYgcm91dGUsIGl0IGVuc3VyZXMg dGhhdCBhbGwgY3VzdG9tZXJzIGtlZXAgdGhlaXIgSVB2NCBhZGRyZXNzZXMuKTwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SSBkb24ndCB0aGluayB0aGF0IGl0IGNvdWxk IHdvcmsgYXMgeW91IGV4cGxhaW5lZCBpbiB0aGF0IHNlY3Rpb24uIEZvciBleGFtcGxlLCB0aGUg QlIgd291bGQgbmVlZCB0byBjaGVjayBhIHJlY2VpdmVkIHBhY2tldCBmcm9tIGEgQ0Ugd2hldGhl ciBpdCBoYXMgY29ycmVjdCBzb3VyY2UgYWRkcmVzcyBpbiBtYXBwaW5nIHJ1bGUgb3Igbm90LiBJ dCBtZWFucyB0aGF0IHRoZSBCUiBtdXN0IGtub3cgYWxsIGFkZHJlc3MgbWFwcGluZ3MgZm9yIENF IGJldHdlZW4gSVB2NCBhZGRyZXNzZXMgYW5kIElQdjYgcHJlZml4ZXMuIElzIGl0IGNvcnJlY3Qg dW5kZXJzdGFuZGluZz88L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48c3Bhbj48L3NwYW4+PGJyPjxz cGFuPkluZ3Jlc3MgZmlsdGVyaW5nIG9mIHRoZSBkb21haW4gaGFzIGNoZWNrZWQgdGhhdCB0aGUg SVB2NiBzb3VyY2Ugc3RhcnRzIHdpdGggdGhlIGRlbGVnYXRlZCBJUHY2IHByZWZpeCwgYSAvMTEy IHdoaWNoIGluY2x1ZGVzIHRoZSBJUHY0IGFkZHJlc3MuIEluIHRoZSA0cmQtRSBjYXNlLCB0aGUg QlIgY2hlY2tzIHRoYXQgdGhlIHNvdXJjZSBhZGRyZXNzIGluIHRoZSBJUHY0IGhlYWRlciBtYXRj aGVzIHRoYXQgb2YgdGhlIElQdjYgYWRkcmVzcy4gVGhlcmUgaXMgdGhlcmVmb3JlIG5vIG5lZWQg Zm9yIHRoZSBCUiB0byBrbm93IGFsbCBJUHY0IHByZWZpeGVzLiBBdCBpdHMgSVB2NCBpbnRlcmZh Y2UsIGFsbCByZWNlaXZlZCBwYWNrZXRzIHN0YXJ0IHdpdGggb25lIG9mIHRoZW0uIEF0IGl0cyBJ UHY2IGludGVyZmFjZSwgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMgaGF2ZSBhbiBlbWJlZGRlZCBh ZGRyZXNzIHRoYXQgc3RhcnRzIHdpdGggb25lIG9mIHRoZXNlIHByZWZpeGVzLiA8L3NwYW4+PGJy PjxzcGFuPjwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SSB0aGluayB0 aGF0IG9wZXJhdG9ycyB3aG8gYWxyZWFkeSBkZXBsb3kgc3VjaCBkdWFsLXN0YWNrIG5ldHdvcmsg aXMgc3VwcG9zZWQgdGhhdCB0aGV5IGhhdmUgYWRkcmVzcyBtYXBwaW5nIHRhYmxlLDwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+SSB3b3VsZCByYXRoZXIgc3Vw cG9zZSB0aGF0IElTUHMgdGhhdCBoYXZlIGFkZGVkIElQdjYtcHJlZml4IGRlbGVnYXRpb24sIHNh eSAvNTZzLCB0byBhbiBleGlzdGluZyBJUHY0IG5ldHdvcmsgZGlkIGl0IHdpdGhvdXQgbWl4aW5n IHRoZWlyIElQdjYgcGxhbiB3aXRoIHRoZWlyIElQdjQgcHJlZml4ZXMuPC9zcGFuPjxicj48c3Bh bj5JIGFtIHJlYWR5LCBob3dldmVyLCB0byBsb29rIHNlcmlvdXNseSBhdCBpbmRpdmlkdWFsIGNh c2VzIHdoZXJlIGNob2ljZXMgd2VyZSBkaWZmZXJlbnQuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+ PGJyPjxzcGFuPlJlZ2FyZHMsPC9zcGFuPjxicj48c3Bhbj5SRDwvc3Bhbj48YnI+PHNwYW4+PC9z cGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+dGhleSBjYW4gcHJvdmlzaW9uIGVhY2ggQ0UgaW5kaXZpZHVhbGx5LCBh bmQgYWxzbyB0aGV5IGFyZSBjYXBhYmxlIHRvIGRpc3RyaWJ1dGUgdGhlIGRlZmF1bHQgbWFwcGlu ZyBydWxlIHNpbmNlIHRoZXkgc2hvdWxkIGluc3RhbGwgaXQgaW50byB0aGUgQ0VzLiBJbiB0aGF0 IHNpdHVhdGlvbiwgd2hhdCdzIHRoZSBtb3RpdmF0aW9uIG9mIHdoeSB0aGUgb3BlcmF0b3Igd2Fu dCB0byBwcm92aXNpb24gd2l0aCBvbmx5IGRlZmF1bHQgbWFwcGluZyBydWxlPzwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmNoZWVycyw8L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4tLXNhdG9ydTwvc3Bh bj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPkZvciB0aGlzIHRvIHdvcmssIHRoZSA0cmQtVSBkcmFmdCBoYXMgYSBiaXQg dGhhdCwgaW4gdGhlIGh1YiZhbXA7c3Bva2UgY2FzZSwgZGlmZmVycyBiZXR3ZWVuIENFLXRvLUJS IGFuZCBCUi10by1DRSBkaXJlY3Rpb25zLiBUaHVzLCBwYWNrZXRzIHNlbnQgdG8gYSBDRSB0YWtl IGRpZmZlcmVudCByb3V0ZXMgZGVwZW5kaW5nIG9uIHdoZXRoZXIgc2VudCBieSBhIENFIG9yIGEg QlIuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj5JIGRvbid0IHNlZSBob3cgdGhlIGVxdWl2YWxlbnQgY291bGQgd29yayB3 aXRoIHRoZSBNQVAgZG9jdW1lbnRzIHlvdSBlZGl0ZWQuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxzcGFuPklzIGl0IHRoYXQgc3VjaCBhIHVzZSBjYXNlIGlzIG91dCBvZiBzY29wZSBmb3Ig TUFQPzwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5PciBkaWQgSSBtaXNzIHNvbWV0 aGluZz88L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPkNoZWVycyw8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ UkQ8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlNvZnR3aXJlcyBtYWlsaW5nIGxp c3Q8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOlNvZnR3 aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0 d2lyZXM8L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxzcGFuPjwvc3Bhbj48 YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PGJyPjxzcGFuPlNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxh IGhyZWY9Im1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmciPlNvZnR3aXJlc0BpZXRmLm9yZzwvYT48 L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29mdHdpcmVzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nv ZnR3aXJlczwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-201C0DEA-2789-4114-AE9D-15E2C13D541A-- From despres.remi@laposte.net Tue Feb 7 05:28:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C95621F870E for ; Tue, 7 Feb 2012 05:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdBXTI-UzD8f for ; Tue, 7 Feb 2012 05:28:13 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3321F870A for ; Tue, 7 Feb 2012 05:28:12 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id BA11370000FE; Tue, 7 Feb 2012 14:28:11 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 4EEEC70000F7; Tue, 7 Feb 2012 14:28:11 +0100 (CET) X-SFR-UUID: 20120207132811323.4EEEC70000F7@msfrf2206.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-121-274256405 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8EDD7EC1-55FC-4474-8688-7F473DEDE36E@cisco.com> Date: Tue, 7 Feb 2012 14:28:10 +0100 Message-Id: References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <8EDD7EC1-55FC-4474-8688-7F473DEDE36E@cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:28:14 -0000 --Apple-Mail-121-274256405 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-07 =E0 14:18, Rajiv Asati (rajiva) a =E9crit : >> the 4rd-E case, the BR checks that the source address in the IPv4 = header matches that of the IPv6 address.=20 >=20 > Could this check (and filtering) be done without incurring a = performance penalty?=20 Yes indeed.. Consistency check between source IPv4 address and source IPv6 address is = always part of encapsulation solutions (translation or header-mapping = solutions are not concerned). They are needed to avoid introducing vulnerability to spoofing attacks. Cheers, RD=20 =20 >=20 > Cheers, > Rajiv >=20 > Sent from my Phone >=20 > On Feb 7, 2012, at 8:03 AM, R=E9mi Despr=E9s = wrote: >=20 >>=20 >> Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit : >>=20 >>> Hi Remi-san, >>>=20 >>> On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote: >>>=20 >>>> Hello Ole, Tetsuya-san, Wojciech, >>>>=20 >>>> In a use case described in the 4rd-U draft (sec 5.3), an ISP = replaces its dual-stack routing by IPv6-only routing. >>>> For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. >>>> (By replacing each IPv4 route by an equivalent IPv6 route, it = ensures that all customers keep their IPv4 addresses.) >>>>=20 >>>=20 >>> I don't think that it could work as you explained in that section. = For example, the BR would need to check a received packet from a CE = whether it has correct source address in mapping rule or not. It means = that the BR must know all address mappings for CE between IPv4 addresses = and IPv6 prefixes. Is it correct understanding? >>=20 >> Ingress filtering of the domain has checked that the IPv6 source = starts with the delegated IPv6 prefix, a /112 which includes the IPv4 = address. In the 4rd-E case, the BR checks that the source address in the = IPv4 header matches that of the IPv6 address. There is therefore no need = for the BR to know all IPv4 prefixes. At its IPv4 interface, all = received packets start with one of them. At its IPv6 interface, all = packets it receives have an embedded address that starts with one of = these prefixes.=20 >>=20 >>> I think that operators who already deploy such dual-stack network is = supposed that they have address mapping table, >>=20 >> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >> I am ready, however, to look seriously at individual cases where = choices were different. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>> they can provision each CE individually, and also they are capable = to distribute the default mapping rule since they should install it into = the CEs. In that situation, what's the motivation of why the operator = want to provision with only default mapping rule? >>>=20 >>> cheers, >>> --satoru >>>=20 >>>> For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >>>>=20 >>>> I don't see how the equivalent could work with the MAP documents = you edited. >>>> Is it that such a use case is out of scope for MAP? >>>> Or did I miss something? >>>>=20 >>>> Cheers, >>>> RD >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-121-274256405 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
the 4rd-E case, the = BR checks that the source address in the IPv4 header matches that of the = IPv6 address. 

Could this = check (and filtering) be done without incurring a performance = penalty? 

Yes = indeed..
Consistency check between source IPv4 address and = source IPv6 address is always part of encapsulation solutions = (translation or header-mapping solutions are not = concerned).
They are needed to avoid introducing vulnerability = to spoofing = attacks.

Cheers,
RD 

 

Cheers,
Rajiv

Se= nt from my Phone

On Feb 7, 2012, at 8:03 AM, R=E9mi = Despr=E9s <despres.remi@laposte.net> = wrote:


Le 2012-02-07 =E0 13:07, = Satoru Matsushima a =E9crit :

Hi Remi-san,

On 2012/02/07, at 11:13, R=E9mi Despr=E9s = wrote:

Hello Ole, Tetsuya-san, = Wojciech,

In a use case described in = the 4rd-U draft (sec 5.3), an ISP replaces its dual-stack routing by = IPv6-only routing.
For this, independently = from the number of IPv4 prefixes it has to support, it uses only one = mapping rule.
(By replacing each IPv4 = route by an equivalent IPv6 route, it ensures that all customers keep = their IPv4 addresses.)


I don't think that it could work as you explained in = that section. For example, the BR would need to check a received packet = from a CE whether it has correct source address in mapping rule or not. = It means that the BR must know all address mappings for CE between IPv4 = addresses and IPv6 prefixes. Is it correct = understanding?

Ingress = filtering of the domain has checked that the IPv6 source starts with the = delegated IPv6 prefix, a /112 which includes the IPv4 address. In the = 4rd-E case, the BR checks that the source address in the IPv4 header = matches that of the IPv6 address. There is therefore no need for the BR = to know all IPv4 prefixes. At its IPv4 interface, all received packets = start with one of them. At its IPv6 interface, all packets it receives = have an embedded address that starts with one of these prefixes. =

I think that = operators who already deploy such dual-stack network is supposed that = they have address mapping = table,

I would rather = suppose that ISPs that have added IPv6-prefix delegation, say /56s, to = an existing IPv4 network did it without mixing their IPv6 plan with = their IPv4 prefixes.
I am ready, however, to look = seriously at individual cases where choices were = different.

Regards,
RD



they can provision each CE individually, and also = they are capable to distribute the default mapping rule since they = should install it into the CEs. In that situation, what's the motivation = of why the operator want to provision with only default mapping = rule?

cheers,
--satoru

For this to work, the = 4rd-U draft has a bit that, in the hub&spoke case, differs between = CE-to-BR and BR-to-CE directions. Thus, packets sent to a CE take = different routes depending on whether sent by a CE or a = BR.

I don't see how the = equivalent could work with the MAP documents you = edited.
Is it that such a use case = is out of scope for MAP?
Or did I miss = something?

Cheers,
RD

_______________________________________________=
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires


_______= ________________________________________
Softwires = mailing list
Softwires@ietf.org
= https://www.ietf.= org/mailman/listinfo/softwires

= --Apple-Mail-121-274256405-- From ichiroumakino@gmail.com Tue Feb 7 05:40:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B4521F8762 for ; Tue, 7 Feb 2012 05:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0KJSR3LybfB for ; Tue, 7 Feb 2012 05:40:09 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6400E21F8751 for ; Tue, 7 Feb 2012 05:40:09 -0800 (PST) Received: by werm10 with SMTP id m10so6208304wer.31 for ; Tue, 07 Feb 2012 05:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=x6lj5SHcIIhN0g43nA7zurp6Yr3k3CtdX4vi8H4OQ04=; b=BbTq1UWqUZfG81Lc7p4AW6z+6JWgmrzmY1EByzBFkViLoeHI107E6CiSRuwdLh1eXv 9V73/ceE5DtNsOye4ZGhJ/GnucIUvVBYoJpnQO1fVu9sEgBnTZ0IYK5Hwpp6oaD7389r P08WCosCdTvby+SHelQvIJK4+VubSty/DqiT4= Received: by 10.216.133.18 with SMTP id p18mr5057465wei.1.1328622008008; Tue, 07 Feb 2012 05:40:08 -0800 (PST) Received: from ams3-vpn-dhcp4282.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id eq5sm56784529wib.2.2012.02.07.05.40.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:40:07 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <179E0E92-1E0F-414C-87CD-D782B9AF4577@laposte.net> Date: Tue, 7 Feb 2012 14:40:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38DA8E40-3A43-42DD-B08B-771EFF483DD6@employees.org> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <48E1E89C-0CB2-4FE8-B3CB-13D556F46AE1@employees.org> <179E0E92-1E0F-414C-87CD-D782B9AF4577@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:40:11 -0000 Remi, >> injecting IPv4 routing into the IPv6 routing table is considered a = bad idea. that was what caused Automatic tunnelling and IPv4 compatible = address in RFC1933 to be deprecated. >=20 > - Reference? good question. anyone aware of an IETF document, giving a detailed = description of why we deprecated automatic tunnels? the best I can come up with, regarding IPv4 routes in IPv6 is: = http://www.windows-ipv6.org/index.php?page=3Dimplementation&selectlanguage= =3Deng > - Should we take it, then, that you reject moving from DS routing to = IPV6-only routing without address/prefix changes as a use case you are = interested in? *talking about the general case here* IPv4 addresses are used to number the outside of a CPE NAT, and can have = relatively short address leases today. the resulting renumbering event = only affects ongoing TCP sessions. given that, it doesn't sound like the main use case for MAP. it can be implemented in MAP, with a single rule as well; e.g. by = assigning a separate IPv6 prefix /128 prefix to each CE. what are we arguing over? if 4rd-U is better than MAP? in the MAP effort = we chose to drop quite a number of suggested features, because we didn't = think the added complexity/confusion was worth it. the working group are = free to add any feature from the feature buffet. cheers, Ole From satoru.matsushima@gmail.com Tue Feb 7 06:26:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C760321F87C7 for ; Tue, 7 Feb 2012 06:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00lgELM4ipxi for ; Tue, 7 Feb 2012 06:26:52 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67AB821F87B4 for ; Tue, 7 Feb 2012 06:26:49 -0800 (PST) Received: by werm10 with SMTP id m10so6253327wer.31 for ; Tue, 07 Feb 2012 06:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=AKg8l9vq36kos6quOWUTV33dtHsT99XoyRusWog4ePQ=; b=I/86NqduN+3TpDmRCfBAgivofbvYQiI0M99V4H629MN5FD6mZ9/b/THGz4R3bTJY8H Kd5AZaDzcr6mZrE7iu0cxQzrfPO6ODANY3117j2dOpWR8RdSfF5PbdSm/EEkobZubcmG wkOJ56cpqOWXj/mGsrux8Z3jqtPONm5xzS8OY= Received: by 10.216.134.87 with SMTP id r65mr7219241wei.46.1328624807388; Tue, 07 Feb 2012 06:26:47 -0800 (PST) Received: from [10.115.194.117] (62-50-193-163.client.stsn.net. [62.50.193.163]) by mx.google.com with ESMTPS id q7sm32485889wix.5.2012.02.07.06.26.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 06:26:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> Date: Tue, 7 Feb 2012 15:26:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:26:52 -0000 On 2012/02/07, at 14:03, R=E9mi Despr=E9s wrote: >=20 > Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit : >=20 >> Hi Remi-san, >>=20 >> On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote: >>=20 >>> Hello Ole, Tetsuya-san, Wojciech, >>>=20 >>> In a use case described in the 4rd-U draft (sec 5.3), an ISP = replaces its dual-stack routing by IPv6-only routing. >>> For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. >>> (By replacing each IPv4 route by an equivalent IPv6 route, it = ensures that all customers keep their IPv4 addresses.) >>>=20 >>=20 >> I don't think that it could work as you explained in that section. = For example, the BR would need to check a received packet from a CE = whether it has correct source address in mapping rule or not. It means = that the BR must know all address mappings for CE between IPv4 addresses = and IPv6 prefixes. Is it correct understanding? >=20 > Ingress filtering of the domain has checked that the IPv6 source = starts with the delegated IPv6 prefix, a /112 which includes the IPv4 = address. In the 4rd-E case, the BR checks that the source address in the = IPv4 header matches that of the IPv6 address. There is therefore no need = for the BR to know all IPv4 prefixes. At its IPv4 interface, all = received packets start with one of them. At its IPv6 interface, all = packets it receives have an embedded address that starts with one of = these prefixes.=20 >=20 It looks like that you treat default mapping rule as a basic mapping = rule to check source address consistency on the BR. It should work, and = the MAP too. >> I think that operators who already deploy such dual-stack network is = supposed that they have address mapping table, >=20 > I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. > I am ready, however, to look seriously at individual cases where = choices were different. Basically provision MAP CE is based on its delegated IPv6 prefix in = concept. It is opposed to your case but technically possible. Now I = concern that it requires much complicated CE implementation.=20 cheers, --satoru >=20 > Regards, > RD >=20 >=20 >=20 >> they can provision each CE individually, and also they are capable to = distribute the default mapping rule since they should install it into = the CEs. In that situation, what's the motivation of why the operator = want to provision with only default mapping rule? >>=20 >> cheers, >> --satoru >>=20 >>> For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >>>=20 >>> I don't see how the equivalent could work with the MAP documents you = edited. >>> Is it that such a use case is out of scope for MAP? >>> Or did I miss something? >>>=20 >>> Cheers, >>> RD >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 From cb.list6@gmail.com Tue Feb 7 07:05:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF98921F87F7 for ; Tue, 7 Feb 2012 07:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnLAdNAve+pB for ; Tue, 7 Feb 2012 07:05:45 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCBB21F87EC for ; Tue, 7 Feb 2012 07:05:43 -0800 (PST) Received: by dakl33 with SMTP id l33so6691643dak.31 for ; Tue, 07 Feb 2012 07:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EOxDzS8c3X3+TWR+yE6CqPAE9/liSshaQd/TCKnR3LI=; b=aGBqyVU4CkEuWINRqGFWozSJ2D7mVDAQTW/NqCvLC94Ipt9G2k7HVlZF3s8HDanl7w 5bvQ0ky5c4YQxvGJqoTtyNotyduHuclzbFaGhFuHqfiIG9sXBNsX01bM6sTTVpP4W17D Hgan7tEJ0TyYJW177V5+c6wLd+p4tdssI3p5c= MIME-Version: 1.0 Received: by 10.68.225.39 with SMTP id rh7mr15701701pbc.104.1328627142875; Tue, 07 Feb 2012 07:05:42 -0800 (PST) Received: by 10.143.164.16 with HTTP; Tue, 7 Feb 2012 07:05:42 -0800 (PST) Received: by 10.143.164.16 with HTTP; Tue, 7 Feb 2012 07:05:42 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Feb 2012 07:05:42 -0800 Message-ID: From: Cameron Byrne To: softwires@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff2538ce3d9d704b8611cd3 Subject: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:05:46 -0000 --e89a8ff2538ce3d9d704b8611cd3 Content-Type: text/plain; charset=ISO-8859-1 Are the map and 4rd solutions deployable for existing networks that do not have reserves of ipv4 ? My assumption is that these solutions target existing networks that have meaningful growth and they need a v6 solution. If yes, how? Any pointers within the reams of drafts I should look for? In my brief and simple skimming, it appears to me that setting up one of these solutions would require me to collapse my existing network to harvest back the addresses so that they may be redeployed in map. What would the deployment process be for an address exhausted network of 10 million subs with 10% annual growth be? Cb --e89a8ff2538ce3d9d704b8611cd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Are the map and 4rd solutions deployable for existing networks that do n= ot have reserves=A0 of ipv4 ?=A0 My assumption is that these solutions targ= et existing networks that have meaningful growth and they need a v6 solutio= n.

If yes, how? Any pointers within the reams of drafts I should look for? =

In my brief and simple skimming, it appears to me that setting up one of= these solutions would require me to collapse my existing network to harves= t back the addresses so that they may be redeployed in map.=A0

What would the deployment process be for an address exhausted network of= 10 million subs with 10% annual growth be?

Cb

--e89a8ff2538ce3d9d704b8611cd3-- From despres.remi@laposte.net Tue Feb 7 07:10:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE6521F8811 for ; Tue, 7 Feb 2012 07:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC9JOsi6733T for ; Tue, 7 Feb 2012 07:10:49 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id CB82121F84FB for ; Tue, 7 Feb 2012 07:10:47 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id CED0C70000E1; Tue, 7 Feb 2012 16:10:41 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 9E4B6700009D; Tue, 7 Feb 2012 16:10:40 +0100 (CET) X-SFR-UUID: 20120207151040648.9E4B6700009D@msfrf2216.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> Date: Tue, 7 Feb 2012 16:10:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:10:51 -0000 Le 2012-02-07 =E0 15:26, Satoru Matsushima a =E9crit : > On 2012/02/07, at 14:03, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit : >>=20 >>> Hi Remi-san, >>>=20 >>> On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote: >>>=20 >>>> Hello Ole, Tetsuya-san, Wojciech, >>>>=20 >>>> In a use case described in the 4rd-U draft (sec 5.3), an ISP = replaces its dual-stack routing by IPv6-only routing. >>>> For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. >>>> (By replacing each IPv4 route by an equivalent IPv6 route, it = ensures that all customers keep their IPv4 addresses.) >>>>=20 >>>=20 >>> I don't think that it could work as you explained in that section. = For example, the BR would need to check a received packet from a CE = whether it has correct source address in mapping rule or not. It means = that the BR must know all address mappings for CE between IPv4 addresses = and IPv6 prefixes. Is it correct understanding? >>=20 >> Ingress filtering of the domain has checked that the IPv6 source = starts with the delegated IPv6 prefix, a /112 which includes the IPv4 = address. In the 4rd-E case, the BR checks that the source address in the = IPv4 header matches that of the IPv6 address. There is therefore no need = for the BR to know all IPv4 prefixes. At its IPv4 interface, all = received packets start with one of them. At its IPv6 interface, all = packets it receives have an embedded address that starts with one of = these prefixes.=20 >>=20 >=20 > It looks like that you treat default mapping rule as a basic mapping = rule to check source address consistency on the BR. It should work, Yes, thanks. > and the MAP too. I don't see that. The bit that, in 4rd-U hub&spoke, is changed for the CE-to-BR direction = has been included precisely to support this case.=20 Otherwise, packets sent by a CE to another CE would be routed directly = to its destination, without a detour via a BR.=20 >>> I think that operators who already deploy such dual-stack network is = supposed that they have address mapping table, >>=20 >> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >> I am ready, however, to look seriously at individual cases where = choices were different. >=20 > Basically provision MAP CE is based on its delegated IPv6 prefix in = concept. It is opposed to your case but technically possible. > Now I concern that it requires much complicated CE implementation. All what is required is that CEs set an address bit if hub&spoke = topology is required. Cheers, RD >=20 >=20 > cheers, > --satoru >=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>> they can provision each CE individually, and also they are capable = to distribute the default mapping rule since they should install it into = the CEs. In that situation, what's the motivation of why the operator = want to provision with only default mapping rule? >>>=20 >>> cheers, >>> --satoru >>>=20 >>>> For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >>>>=20 >>>> I don't see how the equivalent could work with the MAP documents = you edited. >>>> Is it that such a use case is out of scope for MAP? >>>> Or did I miss something? >>>>=20 >>>> Cheers, >>>> RD >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >=20 From fibrib@gmail.com Tue Feb 7 07:15:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9395921F85EE for ; Tue, 7 Feb 2012 07:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQsLQOA5nOal for ; Tue, 7 Feb 2012 07:15:51 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E363421F841D for ; Tue, 7 Feb 2012 07:15:50 -0800 (PST) Received: by qafi29 with SMTP id i29so2746373qaf.10 for ; Tue, 07 Feb 2012 07:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OsbzaCS7GihO8ObnHDvd9kXppNojFkmbhBhySpYOhh0=; b=qhOlO+tv9MWZ5s+cosTkW1At9AugB3lKoP66MJAyJLIWm60E1UBM6oVVV8WuH4wZXT iVMIgN9mnlHt2c3+LbU3uUqBrUTW8Kqx2xdObpgykhfvqes4TyxlGC2fvQqNJ0XGZZQk cq/XRal0Bieaq6/HbYMkDmCI3kXQHskc2chbY= MIME-Version: 1.0 Received: by 10.224.183.201 with SMTP id ch9mr19632854qab.22.1328627750470; Tue, 07 Feb 2012 07:15:50 -0800 (PST) Received: by 10.229.11.144 with HTTP; Tue, 7 Feb 2012 07:15:50 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Feb 2012 00:15:50 +0900 Message-ID: From: Maoke To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf303b402d1b050304b861418c Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:15:51 -0000 --20cf303b402d1b050304b861418c Content-Type: text/plain; charset=ISO-8859-1 just my personal humble understanding: basically MAP or 4rd, as it is named, is designed for residual deployment, i.e., using not-yet-allocated or already-recalled ipv4 addresses for the ipv4 access of ipv6-enabled networks. its address mapping logic implies doing the ipv6 address planning as the first step, independent of ipv4. for the transition of existing ipv4 network without renumbering (or only renumbering to ipv4-translatable ipv6 addresses), MAP is also applicable but the operator should pay much attention to the addressing issue. in such a case, RFC6052/RFC6145 suite is a little better recommended. - maoke 2012/2/8 Cameron Byrne > Are the map and 4rd solutions deployable for existing networks that do not > have reserves of ipv4 ? My assumption is that these solutions target > existing networks that have meaningful growth and they need a v6 solution. > > If yes, how? Any pointers within the reams of drafts I should look for? > > In my brief and simple skimming, it appears to me that setting up one of > these solutions would require me to collapse my existing network to harvest > back the addresses so that they may be redeployed in map. > > What would the deployment process be for an address exhausted network of > 10 million subs with 10% annual growth be? > > Cb > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf303b402d1b050304b861418c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
just my personal humble understanding:
=A0
basical= ly MAP or 4rd, as it is named, is designed for residual deployment, i.e., u= sing not-yet-allocated or already-recalled ipv4 addresses for the ipv4 acce= ss of ipv6-enabled networks. its address mapping logic implies doing the ip= v6 address planning as the first step, independent of ipv4.
=A0
for the transition of existing ipv4 network without renu= mbering (or only renumbering to ipv4-translatable ipv6 addresses), MAP is a= lso applicable but the operator should pay much attention=A0to the addressi= ng issue. in such a case, RFC6052/RFC6145 suite is a little better recommen= ded.
- maoke
2012/2/8 Cameron Byr= ne <cb.list6@gma= il.com>

Are the map and 4rd solutions deployable for existing networks that do n= ot have reserves=A0 of ipv4 ?=A0 My assumption is that these solutions targ= et existing networks that have meaningful growth and they need a v6 solutio= n.

If yes, how? Any pointers within the reams of drafts I should look for? =

In my brief and simple skimming, it appears to me that setting up one of= these solutions would require me to collapse my existing network to harves= t back the addresses so that they may be redeployed in map.=A0

What would the deployment process be for an address exhausted network of= 10 million subs with 10% annual growth be?

Cb


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--20cf303b402d1b050304b861418c-- From satoru.matsushima@gmail.com Tue Feb 7 07:24:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BC421F87C4 for ; Tue, 7 Feb 2012 07:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfVA7awZAyLO for ; Tue, 7 Feb 2012 07:24:16 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAB521F8771 for ; Tue, 7 Feb 2012 07:24:15 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so5409254wgb.13 for ; Tue, 07 Feb 2012 07:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=admP0pLNt6cDkPxvUTHj9mga7ClsKtezOSqmSbPO8oY=; b=WEVqGMINZQFs0Yq6hE83gp0gS50S3wCRosM0vFKDX9Pk/TqYdPQlyPoZJsa6Fah1c9 uU7mWjL3vju1W7SJTBzYJ2WC+VkEFtGzGQlAL1WijeFasxsxo8FO8YPD+0/YS3JuSo4r drzRmY/0lw3fLNQiVwSxhiv5eVEckU260gpdY= Received: by 10.180.93.132 with SMTP id cu4mr20339953wib.9.1328628254980; Tue, 07 Feb 2012 07:24:14 -0800 (PST) Received: from [10.115.194.117] (62-50-193-163.client.stsn.net. [62.50.193.163]) by mx.google.com with ESMTPS id s8sm24024165wiz.8.2012.02.07.07.24.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 07:24:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> Date: Tue, 7 Feb 2012 16:24:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:24:17 -0000 On 2012/02/07, at 16:10, R=E9mi Despr=E9s wrote: >=20 > Le 2012-02-07 =E0 15:26, Satoru Matsushima a =E9crit : >=20 >> On 2012/02/07, at 14:03, R=E9mi Despr=E9s wrote: >>=20 >>>=20 >>> Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit : >>>=20 >>>> Hi Remi-san, >>>>=20 >>>> On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote: >>>>=20 >>>>> Hello Ole, Tetsuya-san, Wojciech, >>>>>=20 >>>>> In a use case described in the 4rd-U draft (sec 5.3), an ISP = replaces its dual-stack routing by IPv6-only routing. >>>>> For this, independently from the number of IPv4 prefixes it has to = support, it uses only one mapping rule. >>>>> (By replacing each IPv4 route by an equivalent IPv6 route, it = ensures that all customers keep their IPv4 addresses.) >>>>>=20 >>>>=20 >>>> I don't think that it could work as you explained in that section. = For example, the BR would need to check a received packet from a CE = whether it has correct source address in mapping rule or not. It means = that the BR must know all address mappings for CE between IPv4 addresses = and IPv6 prefixes. Is it correct understanding? >>>=20 >>> Ingress filtering of the domain has checked that the IPv6 source = starts with the delegated IPv6 prefix, a /112 which includes the IPv4 = address. In the 4rd-E case, the BR checks that the source address in the = IPv4 header matches that of the IPv6 address. There is therefore no need = for the BR to know all IPv4 prefixes. At its IPv4 interface, all = received packets start with one of them. At its IPv6 interface, all = packets it receives have an embedded address that starts with one of = these prefixes.=20 >>>=20 >>=20 >> It looks like that you treat default mapping rule as a basic mapping = rule to check source address consistency on the BR. It should work, >=20 > Yes, thanks. >=20 >> and the MAP too. >=20 > I don't see that. > The bit that, in 4rd-U hub&spoke, is changed for the CE-to-BR = direction has been included precisely to support this case.=20 > Otherwise, packets sent by a CE to another CE would be routed directly = to its destination, without a detour via a BR.=20 >=20 I don't think so. I just mention BR behavior here. You mention CE behavior for whether the bit is set or not. >=20 >>>> I think that operators who already deploy such dual-stack network = is supposed that they have address mapping table, >>>=20 >>> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >>> I am ready, however, to look seriously at individual cases where = choices were different. >>=20 >> Basically provision MAP CE is based on its delegated IPv6 prefix in = concept. It is opposed to your case but technically possible. >=20 >=20 >> Now I concern that it requires much complicated CE implementation. >=20 > All what is required is that CEs set an address bit if hub&spoke = topology is required. >=20 So how CE decide to set the bit, and when the CE figure it out? --satoru >=20 > Cheers, > RD >=20 >=20 >=20 >>=20 >>=20 >> cheers, >> --satoru >>=20 >>>=20 >>> Regards, >>> RD >>>=20 >>>=20 >>>=20 >>>> they can provision each CE individually, and also they are capable = to distribute the default mapping rule since they should install it into = the CEs. In that situation, what's the motivation of why the operator = want to provision with only default mapping rule? >>>>=20 >>>> cheers, >>>> --satoru >>>>=20 >>>>> For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, differs between CE-to-BR and BR-to-CE directions. Thus, packets = sent to a CE take different routes depending on whether sent by a CE or = a BR. >>>>>=20 >>>>> I don't see how the equivalent could work with the MAP documents = you edited. >>>>> Is it that such a use case is out of scope for MAP? >>>>> Or did I miss something? >>>>>=20 >>>>> Cheers, >>>>> RD >>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>=20 >>=20 From despres.remi@laposte.net Tue Feb 7 07:28:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1821F8636 for ; Tue, 7 Feb 2012 07:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8FPTuxPKypJ for ; Tue, 7 Feb 2012 07:28:35 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id AB90621F87CD for ; Tue, 7 Feb 2012 07:28:33 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 2BB6370000ED; Tue, 7 Feb 2012 16:28:32 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id E6A5370000B9; Tue, 7 Feb 2012 16:28:31 +0100 (CET) X-SFR-UUID: 20120207152831944.E6A5370000B9@msfrf2216.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-123-281477228 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 7 Feb 2012 16:28:31 +0100 Message-Id: <36A95A1F-CA1B-43E4-BABB-E703E9A37B84@laposte.net> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:28:35 -0000 --Apple-Mail-123-281477228 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-07 =E0 16:05, Cameron Byrne a =E9crit : > Are the map and 4rd solutions deployable for existing networks that do = not have reserves of ipv4 ? My assumption is that these solutions = target existing networks that have meaningful growth and they need a v6 = solution. >=20 NAT64 does needs some IPv4 space to work. MAP/4rd is in the same position, with static sharing instead of dynamic. > If yes, how? Any pointers within the reams of drafts I should look = for? >=20 IMHO, the easiest entry in the stateless work of Softwire is the unified = draft (tools.ietf.org/html/draft-despres-softwire-4rd-u-03). > In my brief and simple skimming, it appears to me that setting up one = of these solutions would require me to collapse my existing network to = harvest back the addresses so that they may be redeployed in map.=20 >=20 > What would the deployment process be for an address exhausted network = of 10 million subs with 10% annual growth be?=20 >=20 This has to be looked at compared with NAT64 requirements, with the = understanding that a mobile device that supports IPv6 would have most of = its traffic in IPv6, and therefore needs only a few IPv4 ports. (If troubled by not enough IPv4 ports, its ASPs should better become = IPv6-enabled.) RD >=20 > Cb >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-123-281477228 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Are the map and 4rd solutions = deployable for existing networks that do not have reserves  of ipv4 = ?  My assumption is that these solutions target existing networks = that have meaningful growth and they need a v6 solution. =


NAT64 does needs some IPv4 space to = work.
MAP/4rd is in the same position, with static sharing = instead of dynamic.

If yes, how? Any = pointers within the reams of drafts I should look for? =

IMHO, the easiest entry in the stateless work of = Softwire is the unified draft (tools.= ietf.org/html/draft-despres-softwire-4rd-u-03).

In my brief and simple skimming, it appears to me that = setting up one of these solutions would require me to collapse my = existing network to harvest back the addresses so that they may be = redeployed in map. 

What would the deployment process be for = an address exhausted network of 10 million subs with 10% annual growth = be?

This has to be looked at compared with = NAT64 requirements, with the understanding that a mobile device that = supports IPv6 would have most of its traffic in IPv6, and therefore = needs only a few IPv4 ports.
(If troubled by not enough IPv4 = ports, its ASPs should better become = IPv6-enabled.)

RD


Cb

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

= --Apple-Mail-123-281477228-- From despres.remi@laposte.net Tue Feb 7 07:46:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58321F8807 for ; Tue, 7 Feb 2012 07:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 642hrERgWTxw for ; Tue, 7 Feb 2012 07:46:53 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id EB93621F87FC for ; Tue, 7 Feb 2012 07:46:39 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 1854170000E7; Tue, 7 Feb 2012 16:46:39 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 946087000088; Tue, 7 Feb 2012 16:46:38 +0100 (CET) X-SFR-UUID: 20120207154638607.946087000088@msfrf2216.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> Date: Tue, 7 Feb 2012 16:46:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 15:46:54 -0000 Le 2012-02-07 =E0 16:24, Satoru Matsushima a =E9crit : > On 2012/02/07, at 16:10, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 2012-02-07 =E0 15:26, Satoru Matsushima a =E9crit : >>=20 >>> On 2012/02/07, at 14:03, R=E9mi Despr=E9s wrote: >>>=20 >>>>=20 >>>> Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit : >>>>=20 >>>>> Hi Remi-san, >>>>>=20 >>>>> On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote: >>>>>=20 >>>>>> Hello Ole, Tetsuya-san, Wojciech, >>>>>>=20 >>>>>> In a use case described in the 4rd-U draft (sec 5.3), an ISP = replaces its dual-stack routing by IPv6-only routing. >>>>>> For this, independently from the number of IPv4 prefixes it has = to support, it uses only one mapping rule. >>>>>> (By replacing each IPv4 route by an equivalent IPv6 route, it = ensures that all customers keep their IPv4 addresses.) >>>>>>=20 >>>>>=20 >>>>> I don't think that it could work as you explained in that section. = For example, the BR would need to check a received packet from a CE = whether it has correct source address in mapping rule or not. It means = that the BR must know all address mappings for CE between IPv4 addresses = and IPv6 prefixes. Is it correct understanding? >>>>=20 >>>> Ingress filtering of the domain has checked that the IPv6 source = starts with the delegated IPv6 prefix, a /112 which includes the IPv4 = address. In the 4rd-E case, the BR checks that the source address in the = IPv4 header matches that of the IPv6 address. There is therefore no need = for the BR to know all IPv4 prefixes. At its IPv4 interface, all = received packets start with one of them. At its IPv6 interface, all = packets it receives have an embedded address that starts with one of = these prefixes.=20 >>>>=20 >>>=20 >>> It looks like that you treat default mapping rule as a basic mapping = rule to check source address consistency on the BR. It should work, >>=20 >> Yes, thanks. >>=20 >>> and the MAP too. >>=20 >> I don't see that. >> The bit that, in 4rd-U hub&spoke, is changed for the CE-to-BR = direction has been included precisely to support this case.=20 >> Otherwise, packets sent by a CE to another CE would be routed = directly to its destination, without a detour via a BR.=20 >>=20 >=20 > I don't think so. I just mention BR behavior here. Yes, but AFAIK the solution needs to involve CEs > You mention CE behavior for whether the bit is set or not. Yes, please see below. >=20 >>=20 >>>>> I think that operators who already deploy such dual-stack network = is supposed that they have address mapping table, >>>>=20 >>>> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >>>> I am ready, however, to look seriously at individual cases where = choices were different. >>>=20 >>> Basically provision MAP CE is based on its delegated IPv6 prefix in = concept. It is opposed to your case but technically possible. >>=20 >>=20 >>> Now I concern that it requires much complicated CE implementation. >>=20 >> All what is required is that CEs set an address bit if hub&spoke = topology is required. >>=20 >=20 > So how CE decide to set the bit, and when the CE figure it out? The CE knows it must set this bit if, and only if, it received at = initialization a Topology-variant parameter set to Hub&spoke (sec 4.1). In this case, the CE sets bit 79 to 1 in IPv6 destination addresses of = all packets it sends. BTW, this bit should better, for clarity, be given a name, e.g. bit B = meaning To-BR bit (or whatever better idea one could propose). I plan to = do it in the next version. =20 RD > --satoru >=20 >=20 From ichiroumakino@gmail.com Tue Feb 7 08:02:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C542621F85F6 for ; Tue, 7 Feb 2012 08:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2-X1hp2pvZC for ; Tue, 7 Feb 2012 08:02:33 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFE3A21F85FC for ; Tue, 7 Feb 2012 08:02:32 -0800 (PST) Received: by werm10 with SMTP id m10so6341330wer.31 for ; Tue, 07 Feb 2012 08:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=GrC9bJ35FXnOY2V7l1+maU4T4TKfuXyhJ29QT/gdvtQ=; b=fEDG0wZYcE/+AZqFQzvPcJkd+6zjeyIwc05IS+HLQDpHt1ekMaPZHfvGABF8nQo4xi JIe7+vTcRsidP+X4Lu9cjzl+Pg5xbWml6YC+z5XL94MuG7K6ZUkofQdb1EQcoYWk+de/ fquT5c2humx4IHQkxSpSFNfyYtl2ljn1i47TM= Received: by 10.216.136.202 with SMTP id w52mr5162657wei.57.1328630551979; Tue, 07 Feb 2012 08:02:31 -0800 (PST) Received: from ams3-vpn-dhcp4282.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id t15sm32997974wiv.6.2012.02.07.08.02.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 08:02:31 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 7 Feb 2012 17:02:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99A53A07-CCD6-4F23-9409-B80FEB8DCF03@employees.org> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:02:33 -0000 Cameron, > Are the map and 4rd solutions deployable for existing networks that do = not have reserves of ipv4 ? My assumption is that these solutions = target existing networks that have meaningful growth and they need a v6 = solution. >=20 > If yes, how? Any pointers within the reams of drafts I should look = for? there is a new draft on MAP deployment in the works. should be out any = day now. > In my brief and simple skimming, it appears to me that setting up one = of these solutions would require me to collapse my existing network to = harvest back the addresses so that they may be redeployed in map.=20 it is certainly simpler if you have some available IPv4 address space to = start with. e.g. with a /14 of IPv4 space, you'll get 16 million subs for a sharing = ratio of 64. or a /16 with a sharing ratio of 256 . > What would the deployment process be for an address exhausted network = of 10 million subs with 10% annual growth be?=20 if you have zero IPv4 addresses left to play with. you can convert a = subscriber at a time. then for every subscriber converted, you'd get = sharing-ratio-1 IPv4 addresses reclaimed, that you can do the same with. cheers, Ole= From satoru.matsushima@gmail.com Tue Feb 7 08:35:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3121F885D for ; Tue, 7 Feb 2012 08:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cV8MoheDFNq for ; Tue, 7 Feb 2012 08:35:29 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6421F8848 for ; Tue, 7 Feb 2012 08:35:29 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so5463881wgb.13 for ; Tue, 07 Feb 2012 08:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YPlGmf9f4gmKhpG6mXlm4MhHAz1iImznI4uKIOu/VfA=; b=WcqvGao6sfdqKYf5Z/sBIs3M/D0wD0MOrYqfP/b1RmNsPkmdOl95kHuKprC1qmdut1 /cZYVsUawK4OeJlvqTDfkULhJft3OPgE7g2kp2FEUdcn7jHtHLc9HZlsKAtNBLabYrxU FmiQO2QtvXa4/wfxS2DcQxksjZJQDSegB0Xbs= Received: by 10.180.90.194 with SMTP id by2mr35376005wib.5.1328632528709; Tue, 07 Feb 2012 08:35:28 -0800 (PST) Received: from [10.115.194.117] (62-50-193-163.client.stsn.net. [62.50.193.163]) by mx.google.com with ESMTPS id cb8sm33210789wib.0.2012.02.07.08.35.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 08:35:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Tue, 7 Feb 2012 17:35:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:35:30 -0000 On 2012/02/07, at 16:46, R=E9mi Despr=E9s wrote: --snip-- >>>=20 >>>>>> I think that operators who already deploy such dual-stack network = is supposed that they have address mapping table, >>>>>=20 >>>>> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >>>>> I am ready, however, to look seriously at individual cases where = choices were different. >>>>=20 >>>> Basically provision MAP CE is based on its delegated IPv6 prefix in = concept. It is opposed to your case but technically possible. >>>=20 >>>=20 >>>> Now I concern that it requires much complicated CE implementation. >>>=20 >>> All what is required is that CEs set an address bit if hub&spoke = topology is required. >>>=20 >>=20 >> So how CE decide to set the bit, and when the CE figure it out? >=20 > The CE knows it must set this bit if, and only if, it received at = initialization a Topology-variant parameter set to Hub&spoke (sec 4.1). > In this case, the CE sets bit 79 to 1 in IPv6 destination addresses of = all packets it sends. >=20 > BTW, this bit should better, for clarity, be given a name, e.g. bit B = meaning To-BR bit (or whatever better idea one could propose). I plan to = do it in the next version. >=20 So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 = prefix as 4rd end point from IPv4 address which is already assigned. = Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. = right? cheers, --satoru= From despres.remi@laposte.net Tue Feb 7 08:53:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267B021F883D for ; Tue, 7 Feb 2012 08:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwe1Nk6NVRJ2 for ; Tue, 7 Feb 2012 08:53:34 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A3221F8832 for ; Tue, 7 Feb 2012 08:53:33 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id DA3A57000176; Tue, 7 Feb 2012 17:53:32 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id 280A77000189; Tue, 7 Feb 2012 17:53:32 +0100 (CET) X-SFR-UUID: 20120207165332164.280A77000189@msfrf2119.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com> Date: Tue, 7 Feb 2012 17:53:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:53:35 -0000 Le 2012-02-07 =E0 17:35, Satoru Matsushima a =E9crit : > On 2012/02/07, at 16:46, R=E9mi Despr=E9s wrote: >=20 > --snip-- >=20 >>>>=20 >>>>>>> I think that operators who already deploy such dual-stack = network is supposed that they have address mapping table, >>>>>>=20 >>>>>> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >>>>>> I am ready, however, to look seriously at individual cases where = choices were different. >>>>>=20 >>>>> Basically provision MAP CE is based on its delegated IPv6 prefix = in concept. It is opposed to your case but technically possible. >>>>=20 >>>>=20 >>>>> Now I concern that it requires much complicated CE implementation. >>>>=20 >>>> All what is required is that CEs set an address bit if hub&spoke = topology is required. >>>>=20 >>>=20 >>> So how CE decide to set the bit, and when the CE figure it out? >>=20 >> The CE knows it must set this bit if, and only if, it received at = initialization a Topology-variant parameter set to Hub&spoke (sec 4.1). >> In this case, the CE sets bit 79 to 1 in IPv6 destination addresses = of all packets it sends. >>=20 >> BTW, this bit should better, for clarity, be given a name, e.g. bit B = meaning To-BR bit (or whatever better idea one could propose). I plan to = do it in the next version. >>=20 >=20 > So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 = prefix as 4rd end point from IPv4 address which is already assigned. If the CE is delegated a prefix shorter than /64, it isn't concerned = with the To-BR bit. If it is delegated a /112, it finds its IPv4 address inom it.=20 It then must set the To-BR bit, in its outgoing IpV6 destinations, iff = the Topology variant is Hub&spoke. =20 > Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. = right? The CE always derives its 4rd prefix from its delegated IPv6 prefix, = based on the Mapping rule that has the longest match. RD >=20 > cheers, > --satoru From rpenno@juniper.net Tue Feb 7 08:54:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B6421F884F for ; Tue, 7 Feb 2012 08:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xipNgA-Hm5XE for ; Tue, 7 Feb 2012 08:54:35 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id AC43E21F8844 for ; Tue, 7 Feb 2012 08:54:32 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTzFXSMi4Mp3m3Wmv1uwGAB7iP4VqLu2E@postini.com; Tue, 07 Feb 2012 08:54:35 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Feb 2012 08:53:48 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 7 Feb 2012 11:53:47 -0500 From: Reinaldo Penno To: Ralph Droms , Alain Durand Date: Tue, 7 Feb 2012 11:53:45 -0500 Thread-Topic: [Softwires] MAP and 4rd-U Thread-Index: AczlLMPTF3z7cIfkS02wO45SZupFJAAjEn00 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] MAP and 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:54:36 -0000 Hello Chairs/AD, I've been following this discussion and believe both 4rd-U and MAP should b= e given a fair and impartial evaluation. IMO we should also avoid 'designing by committee' and mashing everything together just in an effort to please everybody. Thanks, Reinaldo On 2/6/12 4:03 PM, "Ralph Droms" wrote: > I will be in Paris as well; hoping I can join the conversation... >=20 > - Ralph >=20 > On Feb 6, 2012, at 3:39 PM 2/6/12, Alain Durand wrote: >=20 >> R=E9mi, Ole: >>=20 >> I'll be in Paris this week for v6 world congres, and I'm planning to spe= nd >> time with the two of you to make progress on this issue. >> Hopefully we will have good news for the wg by the end of the week. >>=20 >> - Alain. >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Tue Feb 7 09:23:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AB921F87FB for ; Tue, 7 Feb 2012 09:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.732 X-Spam-Level: X-Spam-Status: No, score=-8.732 tagged_above=-999 required=5 tests=[AWL=1.867, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCGYIKfypl94 for ; Tue, 7 Feb 2012 09:23:40 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F1FE421F87F7 for ; Tue, 7 Feb 2012 09:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1940; q=dns/txt; s=iport; t=1328635420; x=1329845020; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zSP4KIF+GCcXTVriMLhyPOv2J5kvt78m6w7mTUTo108=; b=O1m2Po0yt6+Eqo4bUryMPjVSy6xiW45OLemJhTb/sukF7eVJ+zho5hiA 3/qzEXWnJBMPP4CaLRkATWMln8x0POgG1kmT07bbIqzUXs61rbtiUfoos GcVHQIFwnZwzehoj/LOskURf6iMmUFQNEBfFIed3BqjYcL1r0cYh3Q6lh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJBdMU+tJXG8/2dsb2JhbABCr1qBBYFyAQEBBBIBHQpLBAIBCA4DBAEBCwYXAQYBRQkIAQEEARIIEweiUQGXHYs1KzUMAgyEJoJ2YwSIRp9i X-IronPort-AV: E=Sophos;i="4.73,378,1325462400"; d="scan'208";a="57037764" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 07 Feb 2012 17:23:39 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17HNcQf032237; Tue, 7 Feb 2012 17:23:38 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 11:23:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2012 11:23:37 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07508C4E@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Stateless implementation plan Thread-Index: AczlqfsEjHNMWyqaSWeT02NZZZdXWAACuHHg References: From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" , X-OriginalArrivalTime: 07 Feb 2012 17:23:38.0744 (UTC) FILETIME=[3AF24F80:01CCE5BD] Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:23:47 -0000 Hi Cameron, Good question. Yes, MAP is deployable even in that case (though the mileage may vary). One deployment approach suggested below. What's really interesting is that MAP-T CE function (with sharing ratio=3D1, thereby disabling NAT44 on CE) could get us quite comparable = to the CLAT function, and still allowing to use the PLAT device for stateful NAT64. This flexibility got be highlighted, IMO. Cheers, Rajiv PS: One of many deployment approaches could be to=20 - take one public IPv4 address (or prefix) out of the pool=20 assigned to CGN, and use it in MAP as the starting point - exclude that IPv4 address (or prefix) from CGN - share that IPv4 address (or prefix) among 2^n subscribers using MAP Needless to say that this would be done on a per PDN GW basis. The above approach takes quite a simplistic view, suffice to say, and we could come up with more approaches. I bet that you already thought through most of this already. > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Cameron Byrne > Sent: Tuesday, February 07, 2012 10:06 AM > To: softwires@ietf.org > Subject: [Softwires] Stateless implementation plan >=20 > Are the map and 4rd solutions deployable for existing networks that do not > have reserves of ipv4 ? My assumption is that these solutions target existing > networks that have meaningful growth and they need a v6 solution. >=20 > If yes, how? Any pointers within the reams of drafts I should look for? >=20 > In my brief and simple skimming, it appears to me that setting up one of these > solutions would require me to collapse my existing network to harvest back the > addresses so that they may be redeployed in map. >=20 > What would the deployment process be for an address exhausted network of 10 > million subs with 10% annual growth be? >=20 >=20 >=20 > Cb From rajiva@cisco.com Tue Feb 7 09:43:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3015921F88BF for ; Tue, 7 Feb 2012 09:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwQ5tpsHl+qx for ; Tue, 7 Feb 2012 09:43:08 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 18DAC21F888A for ; Tue, 7 Feb 2012 09:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4772; q=dns/txt; s=iport; t=1328636586; x=1329846186; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oKRkup7p2jKMSddSO+iLGzpMnHyOxYpyMyLFccr3mVA=; b=WkxPvbOJ7lWfY74ncb3RBmnHYkbkG7vVel3RyjchyAeiUFIjC4pZR53W JhsGwnW9hPe0TWx4Kl6qqWuAlCUQ/eEbhWcnpKxN/wtgDcYXUuhdf2QRL as/q3gUzoY40GbvG7f1dMgGjz4GR/ifFRV3W1foYxyTmsRawprdNlPRke s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF5hMU+tJXG8/2dsb2JhbABDr1eBBYFyAQEBBAEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQTCBMHh2ObHwGefgSLNSs1DAKEMoJ2YwSIEzOfYg X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="54418438" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 07 Feb 2012 17:43:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17Hh5gT010399; Tue, 7 Feb 2012 17:43:05 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 11:43:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2012 11:43:04 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07508C68@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin hub&spoke topology Thread-Index: AczlnFgFM5LbhtK2R0emdsFQuh5JVwAI4DOA References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <8EDD7EC1-55FC-4474-8688-7F473DEDE36E@cisco.com> From: "Rajiv Asati (rajiva)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 07 Feb 2012 17:43:05.0394 (UTC) FILETIME=[F252F920:01CCE5BF] Cc: Softwires WG , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:43:09 -0000 I would shy away from drawing that conclusion, given the implementation = specifics. Cheers, Rajiv > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] > Sent: Tuesday, February 07, 2012 8:28 AM > To: Rajiv Asati (rajiva) > Cc: Satoru Matsushima; Softwires WG; Wojciech Dec (wdec) > Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only = routingin > hub&spoke topology >=20 >=20 > Le 2012-02-07 =E0 14:18, Rajiv Asati (rajiva) a =E9crit : >=20 >=20 > the 4rd-E case, the BR checks that the source address in the > IPv4 header matches that of the IPv6 address. >=20 >=20 > Could this check (and filtering) be done without incurring a > performance penalty? >=20 >=20 >=20 > Yes indeed.. > Consistency check between source IPv4 address and source IPv6 address = is > always part of encapsulation solutions (translation or header-mapping = solutions > are not concerned). > They are needed to avoid introducing vulnerability to spoofing = attacks. >=20 > Cheers, > RD >=20 >=20 >=20 >=20 >=20 >=20 > Cheers, > Rajiv >=20 > Sent from my Phone >=20 > On Feb 7, 2012, at 8:03 AM, R=E9mi Despr=E9s > wrote: >=20 >=20 >=20 >=20 >=20 > Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit : >=20 >=20 >=20 > Hi Remi-san, >=20 >=20 >=20 >=20 >=20 > On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote: >=20 >=20 >=20 >=20 >=20 > Hello Ole, Tetsuya-san, Wojciech, >=20 >=20 >=20 >=20 >=20 > In a use case described in the 4rd-U draft (sec > 5.3), an ISP replaces its dual-stack routing by IPv6-only routing. >=20 >=20 > For this, independently from the number of > IPv4 prefixes it has to support, it uses only one mapping rule. >=20 >=20 > (By replacing each IPv4 route by an equivalent > IPv6 route, it ensures that all customers keep their IPv4 addresses.) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > I don't think that it could work as you explained in that > section. For example, the BR would need to check a received packet = from a CE > whether it has correct source address in mapping rule or not. It means = that the > BR must know all address mappings for CE between IPv4 addresses and = IPv6 > prefixes. Is it correct understanding? >=20 >=20 >=20 > Ingress filtering of the domain has checked that the IPv6 source > starts with the delegated IPv6 prefix, a /112 which includes the IPv4 = address. In > the 4rd-E case, the BR checks that the source address in the IPv4 = header > matches that of the IPv6 address. There is therefore no need for the = BR to know > all IPv4 prefixes. At its IPv4 interface, all received packets start = with one of > them. At its IPv6 interface, all packets it receives have an embedded = address > that starts with one of these prefixes. >=20 >=20 >=20 > I think that operators who already deploy such dual- > stack network is supposed that they have address mapping table, >=20 >=20 >=20 > I would rather suppose that ISPs that have added IPv6-prefix > delegation, say /56s, to an existing IPv4 network did it without = mixing their IPv6 > plan with their IPv4 prefixes. > I am ready, however, to look seriously at individual cases > where choices were different. >=20 > Regards, > RD >=20 >=20 >=20 >=20 >=20 > they can provision each CE individually, and also they > are capable to distribute the default mapping rule since they should = install it > into the CEs. In that situation, what's the motivation of why the = operator want > to provision with only default mapping rule? >=20 >=20 >=20 >=20 >=20 > cheers, >=20 >=20 > --satoru >=20 >=20 >=20 >=20 >=20 > For this to work, the 4rd-U draft has a bit that, > in the hub&spoke case, differs between CE-to-BR and BR-to-CE = directions. Thus, > packets sent to a CE take different routes depending on whether sent = by a CE or > a BR. >=20 >=20 >=20 >=20 >=20 > I don't see how the equivalent could work with > the MAP documents you edited. >=20 >=20 > Is it that such a use case is out of scope for > MAP? >=20 >=20 > Or did I miss something? >=20 >=20 >=20 >=20 >=20 > Cheers, >=20 >=20 > RD >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ >=20 >=20 > Softwires mailing list >=20 >=20 > Softwires@ietf.org >=20 >=20 >=20 > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 From Tina.Tsou.Zouting@huawei.com Tue Feb 7 10:27:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAE721F886C for ; Tue, 7 Feb 2012 10:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBhGKveJit6l for ; Tue, 7 Feb 2012 10:27:48 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 310B421F8862 for ; Tue, 7 Feb 2012 10:27:48 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ100GOBCLZRD@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 08 Feb 2012 02:27:35 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ1006PICLZX6@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 08 Feb 2012 02:27:35 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX57596; Wed, 08 Feb 2012 02:27:34 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 08 Feb 2012 02:26:55 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 08 Feb 2012 02:27:56 +0800 Date: Tue, 07 Feb 2012 18:27:14 +0000 From: Tina TSOU In-reply-to: <067E6CE33034954AAC05C9EC85E2577C07508C4E@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Softwires] Stateless implementation plan Thread-index: AQHM5aofFcNYKqiCf0eXBbmiR7jrZ5YxKQOAgACX49w= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <067E6CE33034954AAC05C9EC85E2577C07508C4E@XMB-RCD-111.cisco.com> Cc: "softwires@ietf.org" Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:27:49 -0000 Some implementer wrote to me as below. I would like to get some feedback from the WG list before my reply. Thank u. Hi Tina, Please clear this doubt of mine: In the initial stage of IPv6 Migration, there will be vast IPv4 lands connected by IPv6 n/w's, where diff operators must have chosen different transition technology for 6over4 like 6to4,6rd etc. etc. Now if they have to deploy MAP over this for 4over6 traversal, is MAP always independent of whether 6to4 was used or 6rd used.....because the prefix delegation is different in each. Sent from my iPad On Feb 7, 2012, at 9:24 AM, "Rajiv Asati (rajiva)" wrote: > Hi Cameron, > > Good question. Yes, MAP is deployable even in that case (though the > mileage may vary). One deployment approach suggested below. > > What's really interesting is that MAP-T CE function (with sharing > ratio=1, thereby disabling NAT44 on CE) could get us quite comparable to > the CLAT function, and still allowing to use the PLAT device for > stateful NAT64. This flexibility got be highlighted, IMO. > > Cheers, > Rajiv > > PS: One of many deployment approaches could be to > - take one public IPv4 address (or prefix) out of the pool > assigned to CGN, and use it in MAP as the starting point > - exclude that IPv4 address (or prefix) from CGN > - share that IPv4 address (or prefix) among 2^n subscribers > using MAP > > Needless to say that this would be done on a per PDN GW basis. The above > approach takes quite a simplistic view, suffice to say, and we could > come up with more approaches. I bet that you already thought through > most of this already. > > > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > On >> Behalf Of Cameron Byrne >> Sent: Tuesday, February 07, 2012 10:06 AM >> To: softwires@ietf.org >> Subject: [Softwires] Stateless implementation plan >> >> Are the map and 4rd solutions deployable for existing networks that do > not >> have reserves of ipv4 ? My assumption is that these solutions target > existing >> networks that have meaningful growth and they need a v6 solution. >> >> If yes, how? Any pointers within the reams of drafts I should look > for? >> >> In my brief and simple skimming, it appears to me that setting up one > of these >> solutions would require me to collapse my existing network to harvest > back the >> addresses so that they may be redeployed in map. >> >> What would the deployment process be for an address exhausted network > of 10 >> million subs with 10% annual growth be? >> >> >> >> Cb > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jacni@jacni.com Tue Feb 7 16:57:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3A111E8088 for ; Tue, 7 Feb 2012 16:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[AWL=2.650, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeoJ6faH35nq for ; Tue, 7 Feb 2012 16:57:04 -0800 (PST) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9DC11E8080 for ; Tue, 7 Feb 2012 16:57:03 -0800 (PST) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 61E643802BC for ; Tue, 7 Feb 2012 19:57:02 -0500 (EST) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id B1EE13400D7 for ; Wed, 8 Feb 2012 08:56:59 +0800 (CST) Received: from [114.81.81.29] (unknown [114.81.81.29]) by app (Coremail) with SMTP id +AWowJBrAQNOyDFP5mprAA--.942S2; Wed, 08 Feb 2012 08:56:57 +0800 (CST) Message-ID: <4F31C916.9010901@jacni.com> Date: Wed, 08 Feb 2012 09:00:06 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030106010309090603000407" X-CM-TRANSID: +AWowJBrAQNOyDFP5mprAA--.942S2 X-Coremail-Antispam: 1UD129KBjvdXoWrZFW5CFW5KrW8Cw4fXF4rGrg_yoWDtrX_Gr 4ktw18Ar1UAa1jyrWxArnrKrsrCFWrWryUtryDZw17Zryjyws8Jws7WryxGw15GFyUCr45 Wr1kJryjka47WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ-t7k0a2IF6w1UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_ Wr0E3s1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcV AKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI 7VAKI48JMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43 ZEXa7IU8NyCJUUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEQEko7lP+cMwArsc Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd-U X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 00:57:05 -0000 This is a multi-part message in MIME format. --------------030106010309090603000407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Re-, +1 Cheers, Jacni On 2/8/2012 12:53 AM, Reinaldo Penno wrote: > Hello Chairs/AD, > > I've been following this discussion and believe both 4rd-U and MAP should be > given a fair and impartial evaluation. IMO we should also avoid 'designing > by committee' and mashing everything together just in an effort to please > everybody. > > Thanks, > > Reinaldo > > > On 2/6/12 4:03 PM, "Ralph Droms" wrote: > >> I will be in Paris as well; hoping I can join the conversation... >> >> - Ralph >> >> On Feb 6, 2012, at 3:39 PM 2/6/12, Alain Durand wrote: >> >>> Rémi, Ole: >>> >>> I'll be in Paris this week for v6 world congres, and I'm planning to spend >>> time with the two of you to make progress on this issue. >>> Hopefully we will have good news for the wg by the end of the week. >>> >>> - Alain. >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --------------030106010309090603000407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

+1

Cheers,
Jacni


On 2/8/2012 12:53 AM, Reinaldo Penno wrote: 
Hello Chairs/AD,

I've been following this discussion and believe both 4rd-U and MAP should be
given a fair and impartial evaluation. IMO we should also avoid 'designing
by committee' and mashing everything together just in an effort to please
everybody.

Thanks,

Reinaldo


On 2/6/12 4:03 PM, "Ralph Droms" <rdroms@cisco.com> wrote:


I will be in Paris as well; hoping I can join the conversation...

- Ralph

On Feb 6, 2012, at 3:39 PM 2/6/12, Alain Durand wrote:


Rémi, Ole:

I'll be in Paris this week for v6 world congres, and I'm planning to spend
time with the two of you to make progress on this issue.
Hopefully we will have good news for the wg by the end of the week.

 - Alain.


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
--------------030106010309090603000407-- From eleven.fuyu@huawei.com Tue Feb 7 18:32:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5776821F8475 for ; Tue, 7 Feb 2012 18:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJKt35+IkS54 for ; Tue, 7 Feb 2012 18:32:43 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6148821F8472 for ; Tue, 7 Feb 2012 18:32:42 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ1004HMZ1MTL@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 08 Feb 2012 10:32:10 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ1006GHZ1FWA@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 08 Feb 2012 10:32:10 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX75692; Wed, 08 Feb 2012 10:32:10 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 08 Feb 2012 10:31:31 +0800 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.21]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Wed, 08 Feb 2012 10:32:00 +0800 Date: Wed, 08 Feb 2012 02:31:59 +0000 From: "Eleven Fu(Yu)" In-reply-to: X-Originating-IP: [10.108.4.119] To: Qiong , "softwires@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CMOpBHDFQ5CZxG9OIC8OhQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [Softwires] [softwire] Merged version of lightweight 4over6 Thread-index: AQHM41OEcUVJWcwlH0yWZPjPSFfgj5YyQvSg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:32:44 -0000 --Boundary_(ID_CMOpBHDFQ5CZxG9OIC8OhQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi Qiong, I think the merged version of this draft is mature to be adopted as WG document. So I support WG adoption for this draft. Cheers Yu From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Qiong Sent: Saturday, February 04, 2012 11:41 PM To: softwires@ietf.org Subject: [Softwires] [softwire] Merged version of lightweight 4over6 Dear all, We have published a merged version of lightweight 4over6 in: http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt. This mechanism moves the translation function from the tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the mapping scale on the concentrator to per-subscriber level. It has got wilely support in the last Taipei IETF meeting, and the only action we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite and I-D.zhou-softwire-b4-nat into one draft. Now that the merge work has done, from the authors of this document's view, it is ready to be adopted as working group document. We would be appreciated to have your comments. Thanks in advance ! Best wishes Qiong --Boundary_(ID_CMOpBHDFQ5CZxG9OIC8OhQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTsNCglwYW5vc2UtMToyIDEgNiAwIDQgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5Y2O5paH57uG6buRIjsNCglwYW5vc2Ut MToyIDEgNiAwIDQgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2T O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpICZuYnNwO1Fpb25nLA0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIHRo aW5rIHRoZSBtZXJnZWQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGlzIG1hdHVyZSB0byBiZSBhZG9w dGVkIGFzIFdHIGRvY3VtZW50LiAmbmJzcDtTbyBJIHN1cHBvcnQgV0cgYWRvcHRpb24gZm9yIHRo aXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjkuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZdTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFs aWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlFpb25nPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBGZWJydWFyeSAw NCwgMjAxMiAxMTo0MSBQTTxicj4NCjxiPlRvOjwvYj4gc29mdHdpcmVzQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFtTb2Z0d2lyZXNdIFtzb2Z0d2lyZV0gTWVyZ2VkIHZlcnNpb24gb2Yg bGlnaHR3ZWlnaHQgNG92ZXI2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBhbGwsPGJyPg0KPGJyPg0KV2UgaGF2ZSBwdWJsaXNoZWQg YSBtZXJnZWQgdmVyc2lvbiBvZiBsaWdodHdlaWdodCA0b3ZlcjYgaW46IDxicj4NCjxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWN1aS1zb2Z0d2lyZS1i NC10cmFuc2xhdGVkLWRzLWxpdGUtMDUudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1jdWktc29mdHdpcmUtYjQtdHJhbnNsYXRlZC1kcy1saXRlLTA1LnR4dDwv YT4uDQo8YnI+DQo8YnI+DQpUaGlzIG1lY2hhbmlzbSBtb3ZlcyB0aGUgdHJhbnNsYXRpb24gZnVu Y3Rpb24gZnJvbSB0aGUgdHVubmVsIGNvbmNlbnRyYXRvciAoQUZUUikgdG8gaW5pdGlhdG9ycyAo QjRzKSwgYW5kIGhlbmNlIHJlZHVjZXMgdGhlIG1hcHBpbmcgc2NhbGUgb24gdGhlIGNvbmNlbnRy YXRvciB0byBwZXItc3Vic2NyaWJlciBsZXZlbC4NCjxicj4NCjxicj4NCkl0IGhhcyBnb3Qgd2ls ZWx5IHN1cHBvcnQgaW4gdGhlIGxhc3QgVGFpcGVpIElFVEYgbWVldGluZywgYW5kIHRoZSBvbmx5 IGFjdGlvbiB3ZSBuZWVkIHRvIGRvIGlzIHRvIG1lcmdlIEktRC5jdWktc29mdHdpcmUtYjQtdHJh bnNsYXRlZC1kcy1saXRlPGJyPg0KYW5kIEktRC56aG91LXNvZnR3aXJlLWI0LW5hdCBpbnRvIG9u ZSBkcmFmdC48YnI+DQo8YnI+DQpOb3cgdGhhdCB0aGUgbWVyZ2Ugd29yayBoYXMgZG9uZSwgZnJv bSB0aGUgYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50J3MgdmlldywgaXQgaXMgcmVhZHkgdG8gYmUg YWRvcHRlZCBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBXZSB3b3VsZCBiZSBhcHByZWNpYXRl ZCB0byBoYXZlIHlvdXIgY29tbWVudHMuDQo8YnI+DQo8YnI+DQpUaGFua3MgaW4gYWR2YW5jZSAh PGJyPg0KPGJyPg0KQmVzdCB3aXNoZXM8YnI+DQo8YnI+DQpRaW9uZzxicj4NCjxicj4NCjxicj4N CiZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --Boundary_(ID_CMOpBHDFQ5CZxG9OIC8OhQ)-- From yiu_lee@cable.comcast.com Tue Feb 7 18:37:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E411E80A1 for ; Tue, 7 Feb 2012 18:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHBAvG2jtW8Y for ; Tue, 7 Feb 2012 18:37:09 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 957C011E809B for ; Tue, 7 Feb 2012 18:36:58 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.5449884; Tue, 07 Feb 2012 19:27:07 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Tue, 7 Feb 2012 21:36:43 -0500 From: "Lee, Yiu" Thread-Topic: [Softwires] Stateless implementation plan Thread-Index: AQHM5gp9TNZJnwdqZkSM5EuJMyYGlw== Date: Wed, 8 Feb 2012 02:36:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <14FBDF51490F854D8E444173204C2048@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Tina TSOU , "Rajiv Asati (rajiva)" Cc: "softwires@ietf.org" Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:37:09 -0000 May I ask a question. Why will people deploy MAP over another tunnel schema such as 6rd? On 2/7/12 1:27 PM, "Tina TSOU" wrote: >Now if they have to deploy MAP over this for 4over6 traversal, is MAP >always independent of whether 6to4 was used or 6rd used.....because the >prefix delegation is different in each. > From songlinjian@gmail.com Tue Feb 7 20:11:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B819D21F854E for ; Tue, 7 Feb 2012 20:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.035 X-Spam-Level: **** X-Spam-Status: No, score=4.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBOpQEKWUAn9 for ; Tue, 7 Feb 2012 20:11:36 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46CEB21F8541 for ; Tue, 7 Feb 2012 20:11:36 -0800 (PST) Received: by dakl33 with SMTP id l33so140667dak.31 for ; Tue, 07 Feb 2012 20:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=6LG9NKenR6JBJV0qeL+sbOSU++/oRqqVaIhDUs8XA6E=; b=ek4OImiW1BRx9D5GNz8NG3yuWpaOrACRj4Z7LjQbAdfPW1+G/JTXsppKexHLP+DNSn aLJLH3xpEw84KibW5tyy6YX9oH1d0OZx6YNgaOeuaijJzRm6ojb4dugHKAi80VDLcWe6 KDtN2MqryF0ekvoI8KLZiVBDP8dx68qaEkZvc= Received: by 10.68.212.161 with SMTP id nl1mr64110717pbc.38.1328674294910; Tue, 07 Feb 2012 20:11:34 -0800 (PST) Received: from lenovoPC ([218.247.205.130]) by mx.google.com with ESMTPS id d1sm271848pbg.13.2012.02.07.20.11.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 20:11:33 -0800 (PST) From: "Linjian Song" To: "'Lee, Yiu'" , "'Tina TSOU'" , "'Rajiv Asati \(rajiva\)'" References: In-Reply-To: Date: Wed, 8 Feb 2012 12:11:19 +0800 Message-ID: <001501cce617$bc50f400$34f2dc00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: zh-cn Thread-index: AQHM5gp9TNZJnwdqZkSM5EuJMyYGl5YyYkZQ Cc: softwires@ietf.org Subject: [Softwires] =?gb2312?b?tPC4tDogIFN0YXRlbGVzcyBpbXBsZW1lbnRhdGlv?= =?gb2312?b?biBwbGFu?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 04:11:36 -0000 I guess several scenarios may overlap in one network topology. MAP and = 6rd functions can be built on a certain edge router=A3=BF=20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] =B4=FA=B1=ED Lee, Yiu =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA2=D4=C28=C8=D5 10:37 =CA=D5=BC=FE=C8=CB: Tina TSOU; Rajiv Asati (rajiva) =B3=AD=CB=CD: softwires@ietf.org =D6=F7=CC=E2: Re: [Softwires] Stateless implementation plan May I ask a question. Why will people deploy MAP over another tunnel schema such as 6rd? On 2/7/12 1:27 PM, "Tina TSOU" wrote: >Now if they have to deploy MAP over this for 4over6 traversal, is MAP >always independent of whether 6to4 was used or 6rd used.....because the >prefix delegation is different in each. > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Tue Feb 7 20:37:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0D921F8693 for ; Tue, 7 Feb 2012 20:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.016 X-Spam-Level: X-Spam-Status: No, score=-101.016 tagged_above=-999 required=5 tests=[AWL=-1.940, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS5do+7eQLCX for ; Tue, 7 Feb 2012 20:37:51 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id B6A0321F8601 for ; Tue, 7 Feb 2012 20:37:50 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.150961379; Tue, 07 Feb 2012 23:37:24 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Tue, 7 Feb 2012 23:37:24 -0500 From: "Lee, Yiu" To: Linjian Song Thread-Topic: =?gb2312?B?tPC4tDogW1NvZnR3aXJlc10gU3RhdGVsZXNzIGltcGxlbWVudGF0aW9uIHBs?= =?gb2312?Q?an?= Thread-Index: AczmG1n1cbmJP2NARJS5yMNtquYIoQ== Date: Wed, 8 Feb 2012 04:37:23 +0000 Message-ID: <2981E430-DD96-438D-BAE7-6F0F531FE32B@Cable.Comcast.com> References: <001501cce617$bc50f400$34f2dc00$@com> In-Reply-To: <001501cce617$bc50f400$34f2dc00$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] =?gb2312?b?tPC4tDogIFN0YXRlbGVzcyBpbXBsZW1lbnRhdGlv?= =?gb2312?b?biBwbGFu?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 04:37:51 -0000 SSBhbSBvayB3aXRoIHRoYXQuIEkgZ3Vlc3MgSSB3YXMgY29uZnVzZWQgYnkgdGhlIHBoYXNlICJ0 aGV5IGhhdmUgdG8gZGVwbG95IE1BUCBvdmVyIHRoaXMgZm9yIDRvdmVyNiB0cmF2ZXJzYWwiLiBJ IGFzc3VtZSAidGhpcyIgcmVmZXJzIHRvIDZvNCB0dW5uZWxpbmcgdGVjaG5pcXVlLiBJZiBzb21l Ym9keSB3YW50cyB0byBpbXBsZW1lbnQgTUFQIGFuZCA2cmQgb24gdGhlIHNhbWUgZWRnZSByb3V0 ZXIsIGkgZG9uJ3Qgc2VlIGFueSBwcm9ibGVtLiBUaGlzIGlzIHNpbWlsYXIgdG8gaW1wbGVtZW50 IE5BVDQ0IGFuZCBOQVQ2NCBvbiB0aGUgc2FtZSBuZXR3b3JrIGVsZW1lbnQuDQoNCkNoZWVycywN CllpdQ0KDQpPbiBGZWIgNywgMjAxMiwgYXQgMjM6MTEsICJMaW5qaWFuIFNvbmciIDxzb25nbGlu amlhbkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+IEkgZ3Vlc3Mgc2V2ZXJhbCBzY2VuYXJpb3MgbWF5 IG92ZXJsYXAgaW4gb25lIG5ldHdvcmsgdG9wb2xvZ3kuICBNQVAgYW5kIDZyZA0KPiBmdW5jdGlv bnMgY2FuIGJlIGJ1aWx0IG9uIGEgY2VydGFpbiBlZGdlIHJvdXRlcqO/IA0KPiANCj4gLS0tLS3T yrz+1K28/i0tLS0tDQo+ILeivP7Iyzogc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBMZWUsIFlpdQ0KPiC3osvNyrG8 5DogMjAxMsTqMtTCOMjVIDEwOjM3DQo+IMrVvP7IyzogVGluYSBUU09VOyBSYWppdiBBc2F0aSAo cmFqaXZhKQ0KPiCzrcvNOiBzb2Z0d2lyZXNAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtTb2Z0d2ly ZXNdIFN0YXRlbGVzcyBpbXBsZW1lbnRhdGlvbiBwbGFuDQo+IA0KPiBNYXkgSSBhc2sgYSBxdWVz dGlvbi4gV2h5IHdpbGwgcGVvcGxlIGRlcGxveSBNQVAgb3ZlciBhbm90aGVyIHR1bm5lbA0KPiBz Y2hlbWEgc3VjaCBhcyA2cmQ/DQo+IA0KPiBPbiAyLzcvMTIgMToyNyBQTSwgIlRpbmEgVFNPVSIg PFRpbmEuVHNvdS5ab3V0aW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4+IE5vdyBpZiB0aGV5 IGhhdmUgdG8gZGVwbG95IE1BUCBvdmVyIHRoaXMgZm9yIDRvdmVyNiB0cmF2ZXJzYWwsIGlzIE1B UA0KPj4gYWx3YXlzIGluZGVwZW5kZW50IG9mIHdoZXRoZXIgNnRvNCB3YXMgdXNlZCBvciA2cmQg dXNlZC4uLi4uYmVjYXVzZSB0aGUNCj4+IHByZWZpeCBkZWxlZ2F0aW9uIGlzIGRpZmZlcmVudCBp biBlYWNoLg0KPj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJlc0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPiAN Cg== From shtsuchi@cisco.com Tue Feb 7 21:17:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ED611E8088; Tue, 7 Feb 2012 21:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+f2K4F1kBXv; Tue, 7 Feb 2012 21:17:00 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7D11E8094; Tue, 7 Feb 2012 21:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1797; q=dns/txt; s=iport; t=1328678219; x=1329887819; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=abd6fC2wBSptmpobZToYYQA1bZx5fKVb+ZOmTdWu/S0=; b=JPRKz51u4ABVO/US323MfbHX6Hvme/vAIQkb5nV+ddF0BDR6pVgv3Luc 4YKOEQ/Ra32d53KluzihFh2bsFBnFESZKzJzh8VJNYJAZf8RTHueVkOA7 L1v6NpVtM8fYwwxsgO3I5cQkP62SFYyAVUQYbZx1RtRje3LlNa0o22UA3 I=; X-IronPort-AV: E=Sophos;i="4.73,382,1325462400"; d="scan'208";a="29241710" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Feb 2012 05:16:59 +0000 Received: from [64.104.9.218] (dhcp-shinjuku-64-104-9-218.cisco.com [64.104.9.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q185Gwn1010353; Wed, 8 Feb 2012 05:16:58 GMT Message-ID: <4F320549.20100@cisco.com> Date: Wed, 08 Feb 2012 14:16:57 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: armd@ietf.org, v6ops@ietf.org References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> In-Reply-To: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org Subject: [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 05:17:01 -0000 v6ops and ARMD Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. We thought this is interesting idea,so published the draft. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 I think both of mailing list participants are also interesting in this technique. If you have any comment and question of the draft,please let me know. Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt Date: Mon, 14 Nov 2011 17:21:26 +0800 From: Reply-To: To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Rapid Deployment (6rd) in a Large Data Center Author(s) : Shishio Tsuchiya Mark Townsley Shuichi Ohkubo Filename : draft-sakura-6rd-datacenter-03.txt Pages : 15 Date : 2011-11-14 IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid deployment of IPv6 by an access service provider which has difficulty deploying native IPv6. This document describes how 6rd can be used to deliver IPv6 within a Large Data Center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From yiu_lee@cable.comcast.com Tue Feb 7 21:23:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2838611E80A5; Tue, 7 Feb 2012 21:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.648 X-Spam-Level: X-Spam-Status: No, score=-100.648 tagged_above=-999 required=5 tests=[AWL=-1.532, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R-DV5h4qQ7Q; Tue, 7 Feb 2012 21:23:44 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1816111E8088; Tue, 7 Feb 2012 21:23:44 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.5455620; Tue, 07 Feb 2012 22:14:04 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 00:23:41 -0500 From: "Lee, Yiu" To: Shishio Tsuchiya Thread-Topic: [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt Thread-Index: AQHM5iDpvq1pF/9+ckGtbaXvkonN/5Yyd2BV Date: Wed, 8 Feb 2012 05:23:40 +0000 Message-ID: <40137D15-A014-4C28-B531-9D949173C222@Cable.Comcast.com> References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com>, <4F320549.20100@cisco.com> In-Reply-To: <4F320549.20100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "v6ops@ietf.org" , "draft-sakura-6rd-datacenter@tools.ietf.org" , "armd@ietf.org" Subject: Re: [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 05:23:45 -0000 Hi Shishio, Thanks for sharing this. I am glad but not surprised to see the result beca= use free.fr has shown to scale 6rd to millions of their users since few yea= rs ago. Yiu On Feb 8, 2012, at 0:17, "Shishio Tsuchiya" wrote: > v6ops and ARMD > Sakura internet are providing IPv6 service without scalability impact to = core network equipment to customer using 6rd. > We thought this is interesting idea,so published the draft. >=20 > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 >=20 > I think both of mailing list participants are also interesting in this te= chnique. > If you have any comment and question of the draft,please let me know. >=20 > Regards, > -Shishio > -------- Original Message -------- > Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt > Date: Mon, 14 Nov 2011 17:21:26 +0800 > From: > Reply-To: > To: >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : IPv6 Rapid Deployment (6rd) in a Large Data Center > Author(s) : Shishio Tsuchiya > Mark Townsley > Shuichi Ohkubo > Filename : draft-sakura-6rd-datacenter-03.txt > Pages : 15 > Date : 2011-11-14 >=20 > IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid > deployment of IPv6 by an access service provider which has difficulty > deploying native IPv6. This document describes how 6rd can be used > to deliver IPv6 within a Large Data Center. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From shtsuchi@cisco.com Tue Feb 7 21:39:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1311E8089; Tue, 7 Feb 2012 21:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.408 X-Spam-Level: X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=-2.124, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyVeyHlPo6av; Tue, 7 Feb 2012 21:39:50 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 545B621F8507; Tue, 7 Feb 2012 21:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2893; q=dns/txt; s=iport; t=1328679590; x=1329889190; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+pxfYkUbPwPJDB3arVToosXMP7EeF5y37/lSTDMZAdQ=; b=Sd9zfxHDABI2lBslDD7a6Q4TtIk1V+2I+01+9DtHcJ1es8Mpo/oyogep lepDS1iQOOwPF3ckW6KRElBrWvrrjBhU8Y6/zPUwLnltIl7W1qTCfEXb2 0m2QV4jexRFsaGJx43b5r9SeJu/FV6oi2rL1+iZkR1Fl7sCqoATK+03Tq w=; X-IronPort-AV: E=Sophos;i="4.73,382,1325462400"; d="scan'208";a="29107881" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 08 Feb 2012 05:39:49 +0000 Received: from [64.104.9.218] (dhcp-shinjuku-64-104-9-218.cisco.com [64.104.9.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q185dlZw003253; Wed, 8 Feb 2012 05:39:48 GMT Message-ID: <4F320AA3.1020803@cisco.com> Date: Wed, 08 Feb 2012 14:39:47 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Yiu_Lee@Cable.Comcast.com References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com>, <4F320549.20100@cisco.com> <40137D15-A014-4C28-B531-9D949173C222@Cable.Comcast.com> In-Reply-To: <40137D15-A014-4C28-B531-9D949173C222@Cable.Comcast.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, v6ops@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org Subject: Re: [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 05:39:51 -0000 Yiu Thanks for comments. Yes,Free,Swisscom,Softbank and so on already deployed 6rd to the access network. But Sakura deployed IPv6 to the datacenter network by server based 6rd with variable OSs and 6rd BR. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03#section-3 This is my interesting point,and this would be useful information. Regards, -Shishio (2012/02/08 14:23), Lee, Yiu wrote: > Hi Shishio, > > Thanks for sharing this. I am glad but not surprised to see the result because free.fr has shown to scale 6rd to millions of their users since few years ago. > > Yiu > > On Feb 8, 2012, at 0:17, "Shishio Tsuchiya" wrote: > > > v6ops and ARMD > > Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. > > We thought this is interesting idea,so published the draft. > > > > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 > > > > I think both of mailing list participants are also interesting in this technique. > > If you have any comment and question of the draft,please let me know. > > > > Regards, > > -Shishio > > -------- Original Message -------- > > Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt > > Date: Mon, 14 Nov 2011 17:21:26 +0800 > > From: > > Reply-To: > > To: > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : IPv6 Rapid Deployment (6rd) in a Large Data Center > > Author(s) : Shishio Tsuchiya > > Mark Townsley > > Shuichi Ohkubo > > Filename : draft-sakura-6rd-datacenter-03.txt > > Pages : 15 > > Date : 2011-11-14 > > > > IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid > > deployment of IPv6 by an access service provider which has difficulty > > deploying native IPv6. This document describes how 6rd can be used > > to deliver IPv6 within a Large Data Center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Tue Feb 7 22:56:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A80D21F8725 for ; Tue, 7 Feb 2012 22:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqw9mcXsF68O for ; Tue, 7 Feb 2012 22:56:40 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFD221F8721 for ; Tue, 7 Feb 2012 22:56:39 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 43BB7700012B; Wed, 8 Feb 2012 07:56:38 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id ADE2F7000108; Wed, 8 Feb 2012 07:56:37 +0100 (CET) X-SFR-UUID: 20120208065637712.ADE2F7000108@msfrf2216.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 07:56:37 +0100 Message-Id: To: Tetsuya Murakami Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: [Softwires] Hub&spoke supported or not in MAP-E ? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 06:56:41 -0000 In the MAP-E draft, I noted that: - The Introduction says: "CE to CE traffic is direct, while BRs are = traversed only for IPv4 packets that are destined to or are arriving = from outside a given MAP-E domain." - Section 5.2 on BR behavior has no provision for hairpinning CE-to-CE = packets. - Section 8.2 is titled "Hub & Spoke model", and says that some CEs may = know subsets of Mapping rules, and then send some CE-to-CE packets to "a = given BR". Could you clarify the intent? Thanks RD=20= From despres.remi@laposte.net Tue Feb 7 23:16:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BC521F85F9 for ; Tue, 7 Feb 2012 23:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+3tVO2UwsVG for ; Tue, 7 Feb 2012 23:16:11 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91421F8594 for ; Tue, 7 Feb 2012 23:16:09 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 9645470000C1; Wed, 8 Feb 2012 08:16:08 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 6AE6A700006E; Wed, 8 Feb 2012 08:16:08 +0100 (CET) X-SFR-UUID: 20120208071608437.6AE6A700006E@msfrf2412.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 8 Feb 2012 08:16:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yiu Lee , Tina Tsou X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:16:11 -0000 Le 2012-02-08 =E0 03:36, Lee, Yiu a =E9crit : > May I ask a question. Why will people deploy MAP over another tunnel > schema such as 6rd? 6rd can be deployed over Net-10 networks (RFC1918) to deployIPv6. Shared public IPv4 addresses can then be offered to customers via this = IPv6. Such a use case, based on the header-mappiong variant of 4rd-U rather = than on a double MAP encapsulation, is described in = tools.ietf.org/html/draft-despres-softwire-4rd-u-03#section-5.4. RD >=20 > On 2/7/12 1:27 PM, "Tina TSOU" wrote: >=20 >> Now if they have to deploy MAP over this for 4over6 traversal, is MAP >> always independent of whether 6to4 was used or 6rd used.....because = the >> prefix delegation is different in each. >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sarikaya2012@gmail.com Wed Feb 8 00:46:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D95E21F8757 for ; Wed, 8 Feb 2012 00:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlIKOysSREPG for ; Wed, 8 Feb 2012 00:46:07 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF0A21F865B for ; Wed, 8 Feb 2012 00:46:06 -0800 (PST) Received: by yenm3 with SMTP id m3so105337yen.31 for ; Wed, 08 Feb 2012 00:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=iitJJqxV403WtzQQL5OBPpgSS2youa/qieMKeeWyyKo=; b=biwcEOrCrGAGJCKqU2Di7DtYCG5+dSRqumlrtH3s92XL6HyBJC179+ZbzB8EGL3NmW vGjftnPTXmnaTPlwGQPiA6jlr6sxISAuJJmijPUxPfSvG9pIzuNeO6EiyiRt6AiOGdfB awVTU8c5onoWKO/TqxEtHETU8owufE4PU4RMA= MIME-Version: 1.0 Received: by 10.101.141.9 with SMTP id t9mr10934114ann.42.1328690764235; Wed, 08 Feb 2012 00:46:04 -0800 (PST) Received: by 10.236.170.163 with HTTP; Wed, 8 Feb 2012 00:46:04 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Feb 2012 02:46:04 -0600 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 08:46:08 -0000 Hi Cameron, 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd is not appropriate to be hosted in a UE. I think your solution 464XLAT's mobile part is way better for your purposes. There you can put all your IPv4 resources on the PLAT box so that CLAT box is kept simpler. In 4rd, CPEs have A+P and BR is kept "stateless" these are not so useful for your purposes, I think. Regards, Behcet On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne wrote: > Are the map and 4rd solutions deployable for existing networks that do no= t > have reserves=A0 of ipv4 ?=A0 My assumption is that these solutions targe= t > existing networks that have meaningful growth and they need a v6 solution= . > > If yes, how? Any pointers within the reams of drafts I should look for? > > In my brief and simple skimming, it appears to me that setting up one of > these solutions would require me to collapse my existing network to harve= st > back the addresses so that they may be redeployed in map. > > What would the deployment process be for an address exhausted network of = 10 > million subs with 10% annual growth be? > > Cb > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Wed Feb 8 01:23:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B65821F8591 for ; Wed, 8 Feb 2012 01:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MufWmi834sxQ for ; Wed, 8 Feb 2012 01:23:29 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A66321F857F for ; Wed, 8 Feb 2012 01:23:29 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 4B32170001B9; Wed, 8 Feb 2012 10:23:28 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id DBCA470001B5; Wed, 8 Feb 2012 10:23:27 +0100 (CET) X-SFR-UUID: 20120208092327900.DBCA470001B5@msfrf2419.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 8 Feb 2012 10:23:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 09:23:30 -0000 Hi Behcet, Le 2012-02-08 =E0 09:46, Behcet Sarikaya a =E9crit : > Hi Cameron, > 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd is > not appropriate to be hosted in a UE. >=20 > I think your solution 464XLAT's mobile part is way better for your > purposes. There you can put all your IPv4 resources on the PLAT box so > that CLAT box is kept simpler. >=20 > In 4rd, CPEs have A+P and BR is kept "stateless" these are not so > useful for your purposes, I think. Note however that: - 464XLAT doesn't support shared IPv4 addresses (while 4rd does) - 4rd over 6rd can work, and therefore offer both IPv6 and = shared-address IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP = (while 464XLAT cannot AFAIK). Regards, RD >=20 > Regards, >=20 > Behcet >=20 >=20 > On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne = wrote: >> Are the map and 4rd solutions deployable for existing networks that = do not >> have reserves of ipv4 ? My assumption is that these solutions = target >> existing networks that have meaningful growth and they need a v6 = solution. >>=20 >> If yes, how? Any pointers within the reams of drafts I should look = for? >>=20 >> In my brief and simple skimming, it appears to me that setting up one = of >> these solutions would require me to collapse my existing network to = harvest >> back the addresses so that they may be redeployed in map. >>=20 >> What would the deployment process be for an address exhausted network = of 10 >> million subs with 10% annual growth be? >>=20 >> Cb >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Feb 8 02:10:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AAA21F852B for ; Wed, 8 Feb 2012 02:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmWxzJ81T8WH for ; Wed, 8 Feb 2012 02:10:29 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id A306021F855B for ; Wed, 8 Feb 2012 02:10:27 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id 25D3A700005E; Wed, 8 Feb 2012 11:10:26 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id 13D2170000A4; Wed, 8 Feb 2012 11:10:24 +0100 (CET) X-SFR-UUID: 20120208101025813.13D2170000A4@msfrf2106.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> Date: Wed, 8 Feb 2012 11:10:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Yong Cui , Ralph Droms Subject: [Softwires] MAP and 4rd - Feature comparison table X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:10:30 -0000 Le 2012-02-02 =E0 18:35, Alain Durand a =E9crit : > Please, Remi, do build such a table! That would be very useful. Here is what I got: +----+--------------------------------------+-----+-----+-----+-----+ | | Feature | MAP | 4rd | MAP | 4rd | | | | -T | -H | -E | -E | +----+--------------------------------------+-----+-----+-----+-----+ | 1 | Full Transparency to IPv4 DF bit | N | Y | Y | Y | | | | | | | | | 2 | ISP can impose a Tunnel traffic | N | Y | Y | Y | | | class | | | | | | | | | | | | | 3 | IPv6 port-based ACLs work for IPv4 | Y | Y | N | N | | | packets | | | | | | | | | | | | | 4 | IPv6 web caches work for IPv4 | Y | Y | N | N | | | packets | | | | | | | | | | | | | 5 | No constraint on subnet prefixes in | N | Y | N | Y | | | CE sites (V-octet format) | | | | | | | | | | | | | 6 | Number of excluded ports is flexible | Y | N | Y | N | | | (GMA algorithm, 2 parameters) | | | | | | | | | | | | | 7 | Migration from DS routing to | N | Y | N | Y | | | IPv6-only is possible without | | | | | | | changing CE addresses and/or | | | | | | | prefixes (DMR may apply to CEs) | | | | | | | | | | | | | 8 | Automatic support of all protocols | N | Y | N | Y | | | having ports at their usual place | | | | | | | and a TCP-like checksum anywhere | | | | | | | (checksum neutrality) | | | | | | | | | | | | | 9 | IPv4-options supported | N | N | Y | Y | | | | | | | (1) | | | | | | | | | 10 | Datagram reassembly avoided in BRs | N | Y | N | Y | | | | (2) | | (2) | | | | | | | | | | 11 | Packet IDs from shared-address CEs | N | Y | Y | Y | | | cannot be confused in destinations | (2) | | | | +----+--------------------------------------+-----+-----+-----+-----+ (1) Not in draft yet, but decided to be added (trivial to do) (2) Not in draft, but could be added if decided > On Feb 2, 2012, at 10:56 AM, "R=E9mi Despr=E9s" = wrote: > ... >> A 4 columns table would be ideal. Also, It could have a sign = identifying points that are N in current drafts, but could easily = become Y if the final consensus is that they are worth the additional = complexity. >> I can work on it if you are interested. From sarikaya2012@gmail.com Wed Feb 8 03:04:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A1721F86A4 for ; Wed, 8 Feb 2012 03:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKgNfj2xM4Im for ; Wed, 8 Feb 2012 03:04:11 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7021F86A2 for ; Wed, 8 Feb 2012 03:04:10 -0800 (PST) Received: by ghbg16 with SMTP id g16so147614ghb.31 for ; Wed, 08 Feb 2012 03:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=DZ7P09JwJ5Oq+OqSHvL358KaSYVwR6u0iANxMPiYo10=; b=h5cWLw5cRZBWyUgqp7edBgUbfJdzAwEGln0gtiz1eS0HKqXYwjsg+E95FTevgw5nxu 7c/D3rhqyCRyVFgYF9TDx8VG1KbWGLrIlUJwCtzqC126sqZzA2Jkq3G9bGOwbgNHQPXw 76R4Iw0XlXXBj5NokHYj21Dc/5FdGgIGFIQXQ= MIME-Version: 1.0 Received: by 10.236.197.1 with SMTP id s1mr11988466yhn.89.1328699050486; Wed, 08 Feb 2012 03:04:10 -0800 (PST) Received: by 10.236.170.163 with HTTP; Wed, 8 Feb 2012 03:04:10 -0800 (PST) In-Reply-To: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net> References: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net> Date: Wed, 8 Feb 2012 05:04:10 -0600 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:04:11 -0000 Hi Remi, 4rd would be quite applicable for some UEs, e.g. mobile routers which are in charge of a 3G/4G uplink and manage several devices connected to them such as in vehicles. Regards, Behcet On Wed, Feb 8, 2012 at 3:23 AM, R=E9mi Despr=E9s = wrote: > Hi Behcet, > > Le 2012-02-08 =E0 09:46, Behcet Sarikaya a =E9crit : > >> Hi Cameron, >> 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd is >> not appropriate to be hosted in a UE. >> >> I think your solution 464XLAT's mobile part is way better for your >> purposes. There you can put all your IPv4 resources on the PLAT box so >> that CLAT box is kept simpler. >> >> In 4rd, CPEs have A+P and BR is kept "stateless" these are not so >> useful for your purposes, I think. > > Note however that: > - 464XLAT doesn't support shared IPv4 addresses (while 4rd does) > - 4rd over 6rd can work, and therefore offer both IPv6 and shared-address= IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP (while 464XLAT cannot = AFAIK). > > Regards, > RD > >> >> Regards, >> >> Behcet >> >> >> On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne wrote= : >>> Are the map and 4rd solutions deployable for existing networks that do = not >>> have reserves =A0of ipv4 ? =A0My assumption is that these solutions tar= get >>> existing networks that have meaningful growth and they need a v6 soluti= on. >>> >>> If yes, how? Any pointers within the reams of drafts I should look for? >>> >>> In my brief and simple skimming, it appears to me that setting up one o= f >>> these solutions would require me to collapse my existing network to har= vest >>> back the addresses so that they may be redeployed in map. >>> >>> What would the deployment process be for an address exhausted network o= f 10 >>> million subs with 10% annual growth be? >>> >>> Cb >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Feb 8 03:12:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633EE21F8633 for ; Wed, 8 Feb 2012 03:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uK50JhvhxrL for ; Wed, 8 Feb 2012 03:12:19 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9543721F8630 for ; Wed, 8 Feb 2012 03:12:19 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 69EE670004D9; Wed, 8 Feb 2012 12:12:18 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 1571C7000440; Wed, 8 Feb 2012 12:12:18 +0100 (CET) X-SFR-UUID: 20120208111218879.1571C7000440@msfrf2403.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 8 Feb 2012 12:12:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <112FA3FC-EA76-4F38-BBF5-BE6141689842@laposte.net> References: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:12:20 -0000 Le 2012-02-08 =E0 12:04, Behcet Sarikaya a =E9crit : > Hi Remi, >=20 > 4rd would be quite applicable for some UEs, e.g. mobile routers which > are in charge of a 3G/4G uplink and manage several devices connected > to them such as in vehicles. Yes, I think so. It remains to: - finalize 4rd - find mobile operators that understand the potential - find mobile-OS vendors that support it Not necessarily a long path IMHO (but not necessarily a fitness trail = either). Regards=20 RD =20 >=20 > Regards, >=20 > Behcet >=20 > On Wed, Feb 8, 2012 at 3:23 AM, R=E9mi Despr=E9s = wrote: >> Hi Behcet, >>=20 >> Le 2012-02-08 =E0 09:46, Behcet Sarikaya a =E9crit : >>=20 >>> Hi Cameron, >>> 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd = is >>> not appropriate to be hosted in a UE. >>>=20 >>> I think your solution 464XLAT's mobile part is way better for your >>> purposes. There you can put all your IPv4 resources on the PLAT box = so >>> that CLAT box is kept simpler. >>>=20 >>> In 4rd, CPEs have A+P and BR is kept "stateless" these are not so >>> useful for your purposes, I think. >>=20 >> Note however that: >> - 464XLAT doesn't support shared IPv4 addresses (while 4rd does) >> - 4rd over 6rd can work, and therefore offer both IPv6 and = shared-address IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP = (while 464XLAT cannot AFAIK). >>=20 >> Regards, >> RD >>=20 >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>=20 >>> On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne = wrote: >>>> Are the map and 4rd solutions deployable for existing networks that = do not >>>> have reserves of ipv4 ? My assumption is that these solutions = target >>>> existing networks that have meaningful growth and they need a v6 = solution. >>>>=20 >>>> If yes, how? Any pointers within the reams of drafts I should look = for? >>>>=20 >>>> In my brief and simple skimming, it appears to me that setting up = one of >>>> these solutions would require me to collapse my existing network to = harvest >>>> back the addresses so that they may be redeployed in map. >>>>=20 >>>> What would the deployment process be for an address exhausted = network of 10 >>>> million subs with 10% annual growth be? >>>>=20 >>>> Cb >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires From wdec@cisco.com Wed Feb 8 03:53:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED24F21F8573 for ; Wed, 8 Feb 2012 03:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.451 X-Spam-Level: X-Spam-Status: No, score=-109.451 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VpEt13ARLGQ for ; Wed, 8 Feb 2012 03:53:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A847521F8566 for ; Wed, 8 Feb 2012 03:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1496; q=dns/txt; s=iport; t=1328701989; x=1329911589; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=a1VNCsAGTkZD06R4c4z9skdRkDO72TtXzS4XmUiWXQk=; b=gBJJ31En+jgn9Lx9j014TC4khKXb1RBSaH1thc5yf2/diIYn7XDgM7Z3 QoiFE7KVLh32hbvZT7cB9emhVqsmdS581zCS0LupdmfQskKpASr1kPaxq /CIMGrr5u4sNFwjCABDDLql1mlqDydM6iDcE0Ml59S26RFiKJnSV2f34t M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABZhMk+Q/khN/2dsb2JhbABDr2qBB4FyAQEBAwESASkBPAUNAQiBHQEBBAENBSKHWppGAZ5xi0osBgELAQgFAwMJBwEHBwIHhCaDWQSIE40akl4 X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="128837377" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Feb 2012 11:53:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q18Br7a5026959; Wed, 8 Feb 2012 11:53:08 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 12:52:53 +0100 Received: from 10.55.92.10 ([10.55.92.10]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Feb 2012 11:52:52 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 08 Feb 2012 12:52:50 +0100 From: Wojciech Dec To: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Ole Troan , Tetsuya Murakami Message-ID: Thread-Topic: MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology Thread-Index: AczmWC6Wno1QB0TnaEWAwsO+C1I7CQ== In-Reply-To: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 08 Feb 2012 11:52:53.0123 (UTC) FILETIME=[30729D30:01CCE658] Cc: Softwires WG Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:53:11 -0000 Hello Remi, On 07/02/2012 11:13, "R=E9mi Despr=E9s" wrote: > Hello Ole, Tetsuya-san, Wojciech, >=20 > In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces its > dual-stack routing by IPv6-only routing. > For this, independently from the number of IPv4 prefixes it has to suppor= t, it > uses only one mapping rule. > (By replacing each IPv4 route by an equivalent IPv6 route, it ensures tha= t all > customers keep their IPv4 addresses.) >=20 > For this to work, the 4rd-U draft has a bit that, in the hub&spoke case, > differs between CE-to-BR and BR-to-CE directions. Thus, packets sent to a= CE > take different routes depending on whether sent by a CE or a BR. Would this be the "bit set in the V byte"? With MAP-T, the BR prefix(es) and the CE prefix(es) can be different. Matching on the source and destination prefix combination allows CE-CE traffic in a MAP domain, if one cares to detect such traffic. As you may recall classification of "MAP" and "non-MAP" traffic, is a topic we discussed in Beijing and in the design team, and there appeared to be little practical need for it from operators. Nothing in MAP precludes from adding that, if the need would actually be more substantial. Regards, Woj >=20 > I don't see how the equivalent could work with the MAP documents you edit= ed. > Is it that such a use case is out of scope for MAP? > Or did I miss something? >=20 > Cheers, > RD >=20 From rajiva@cisco.com Wed Feb 8 04:20:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697B221F8569 for ; Wed, 8 Feb 2012 04:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRDJEC5tocnf for ; Wed, 8 Feb 2012 04:20:08 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C3E3621F8542 for ; Wed, 8 Feb 2012 04:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=731; q=dns/txt; s=iport; t=1328703608; x=1329913208; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=12Wdqz8PMP+6VAyxQaUiSL5irorElI3m7DceHqt6ydo=; b=VVnPqppgMZT0UPSzb0zhZE8BBful5nImVnOHiIPuc39ASloXE8nLXqKg yeKeJ+wwGIjpv73CHp0ZzbDKZ1cpgkSHyTJJyZi6qeF4tXEn9PfHnggdT KSWDTca93hYLyUdPe2V57rT24J3fvSfsdckNI9CDP83vb0e4Wxqw6TnK5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkIAAtoMk+tJV2d/2dsb2JhbABDiVmmEwKBB4FyAQEBAwESASc/BQsCAQgYLlcBAQQTIodam1YBlwmLSis3AQcHAgQDAYJ8BRgCCwIFeIJ2YwSIRoxnjjyEPw X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="57260288" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 08 Feb 2012 12:20:08 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q18CK87G026656; Wed, 8 Feb 2012 12:20:08 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 06:20:08 -0600 Received: from 144.254.231.93 ([144.254.231.93]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Feb 2012 12:20:07 +0000 References: Content-Transfer-Encoding: quoted-printable From: "Rajiv Asati (rajiva)" Thread-Topic: [Softwires] Stateless implementation plan Thread-Index: AczmW/7B8Xq8IwrrTX26i3q+Ro6Shg== Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: <1E2A9D37-5787-46E2-A0D4-B2E116FA0A80@cisco.com> Date: Wed, 8 Feb 2012 07:20:06 -0500 To: "Lee, Yiu" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 08 Feb 2012 12:20:08.0028 (UTC) FILETIME=[FEED51C0:01CCE65B] Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 12:20:09 -0000 Indeed. Such a scenario makes little sense to me, given that MAP requires na= tive IPv6 connectivity anyway. IOW, if CE is able to get native IPv6 anyway for MAP, then anything non-nati= ve IPv6 would have no usage. =20 Cheers, Rajiv Sent from my Phone On Feb 7, 2012, at 9:36 PM, "Lee, Yiu" wrote: > May I ask a question. Why will people deploy MAP over another tunnel > schema such as 6rd? >=20 > On 2/7/12 1:27 PM, "Tina TSOU" wrote: >=20 >> Now if they have to deploy MAP over this for 4over6 traversal, is MAP >> always independent of whether 6to4 was used or 6rd used.....because the >> prefix delegation is different in each. >>=20 >=20 From satoru.matsushima@gmail.com Wed Feb 8 04:43:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B8021F8606 for ; Wed, 8 Feb 2012 04:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79ECaVHtIqHw for ; Wed, 8 Feb 2012 04:43:35 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1B7121F84BF for ; Wed, 8 Feb 2012 04:43:34 -0800 (PST) Received: by werm10 with SMTP id m10so438458wer.31 for ; Wed, 08 Feb 2012 04:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=g7QlqZc0U6rC+6Hi2uhBf/fBhsgmAUvktyGW2ZLGfSY=; b=iwMaTrmMTsCnl1khyYaNLpNCft5vly5F20wVAYFh0iQsvtyz79VbrUwTO2sSwtfl+X X/97DIHsX/gAg5gMn05UCD77RnSuZuV20sbsofi8joyxqjt/kI5V6PXTeJpWfPYuJB8A 01DEkA7a03taS6tXxCwpjuLzyAmWBn/Kz7bg8= Received: by 10.180.97.166 with SMTP id eb6mr40955575wib.5.1328705014075; Wed, 08 Feb 2012 04:43:34 -0800 (PST) Received: from [10.115.196.129] ([46.245.241.99]) by mx.google.com with ESMTPS id s8sm30728938wiz.8.2012.02.08.04.43.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 04:43:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 8 Feb 2012 13:43:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8032174F-2879-45D0-9E20-62899126EAC6@gmail.com> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com> To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 12:43:35 -0000 On 2012/02/07, at 17:53, R=E9mi Despr=E9s wrote: >=20 > Le 2012-02-07 =E0 17:35, Satoru Matsushima a =E9crit : >=20 >> On 2012/02/07, at 16:46, R=E9mi Despr=E9s wrote: >>=20 >> --snip-- >>=20 >>>>>=20 >>>>>>>> I think that operators who already deploy such dual-stack = network is supposed that they have address mapping table, >>>>>>>=20 >>>>>>> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >>>>>>> I am ready, however, to look seriously at individual cases where = choices were different. >>>>>>=20 >>>>>> Basically provision MAP CE is based on its delegated IPv6 prefix = in concept. It is opposed to your case but technically possible. >>>>>=20 >>>>>=20 >>>>>> Now I concern that it requires much complicated CE = implementation. >>>>>=20 >>>>> All what is required is that CEs set an address bit if hub&spoke = topology is required. >>>>>=20 >>>>=20 >>>> So how CE decide to set the bit, and when the CE figure it out? >>>=20 >>> The CE knows it must set this bit if, and only if, it received at = initialization a Topology-variant parameter set to Hub&spoke (sec 4.1). >>> In this case, the CE sets bit 79 to 1 in IPv6 destination addresses = of all packets it sends. >>>=20 >>> BTW, this bit should better, for clarity, be given a name, e.g. bit = B meaning To-BR bit (or whatever better idea one could propose). I plan = to do it in the next version. >>>=20 >>=20 >> So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 = prefix as 4rd end point from IPv4 address which is already assigned. >=20 >=20 > If the CE is delegated a prefix shorter than /64, it isn't concerned = with the To-BR bit. > If it is delegated a /112, it finds its IPv4 address inom it.=20 > It then must set the To-BR bit, in its outgoing IpV6 destinations, iff = the Topology variant is Hub&spoke. =20 >=20 As you described in your draft, if a CE is delegated /112 IPv6 prefix, = the CE automatically form itself for H&S mode and extract a non-sharing = IPv4 address from the /112 prefix. >=20 >> Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. = right? >=20 > The CE always derives its 4rd prefix from its delegated IPv6 prefix, = based on the Mapping rule that has the longest match. >=20 So you mean that it is only specific case of which if the extracted IPv4 = address is same with an address assigned to a dual-stack interface on = the CE, the default route on the CE is forced to the BR, and keep that = address on the dual-stack interface as NAPT source address. Is that what = you request to 4rd-U CE implementation? It also requires operator to manage specific /112 route for each CE that = means IPv4 host routes are injected to the operator's IPv6 routing table = that's what Ole already pointed out. I agree with Ole that I'm doubt it = could be widely acceptable technique for operators. cheers, --satoru From despres.remi@laposte.net Wed Feb 8 10:20:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3A821E8015 for ; Wed, 8 Feb 2012 10:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKdsn-7I68Rr for ; Wed, 8 Feb 2012 10:20:49 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4772121E8010 for ; Wed, 8 Feb 2012 10:20:47 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5E19B940F42; Wed, 8 Feb 2012 19:20:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 8 Feb 2012 19:20:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:20:50 -0000 Le 2012-02-08 =E0 12:52, Wojciech Dec a =E9crit : > Hello Remi, >=20 >=20 > On 07/02/2012 11:13, "R=E9mi Despr=E9s" = wrote: >=20 >> Hello Ole, Tetsuya-san, Wojciech, >>=20 >> In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces = its >> dual-stack routing by IPv6-only routing. >> For this, independently from the number of IPv4 prefixes it has to = support, it >> uses only one mapping rule. >> (By replacing each IPv4 route by an equivalent IPv6 route, it ensures = that all >> customers keep their IPv4 addresses.) >>=20 >> For this to work, the 4rd-U draft has a bit that, in the hub&spoke = case, >> differs between CE-to-BR and BR-to-CE directions. Thus, packets sent = to a CE >> take different routes depending on whether sent by a CE or a BR. >=20 > Would this be the "bit set in the V byte"? No. As you know, the V octet is the first one in Interface IDs. The ToBR bit is in the lower bit of the next octet, bit 79 as shown on = figures. Where it is said to be 71, it is is a typo. Sorry for that. =20 > With MAP-T, the BR prefix(es) and the CE prefix(es) can be different. > Matching on the source and destination prefix combination allows CE-CE > traffic in a MAP domain, if one cares to detect such traffic. > As you may recall classification of "MAP" and "non-MAP" traffic, is a = topic > we discussed in Beijing and in the design team, and there appeared to = be > little practical need for it from operators. Full freedom of subnet prefixes in CE sites in all cases wasn't really = understood yet, AFAIK. > Nothing in MAP precludes from > adding that, Agreed > if the need would actually be more substantial. The need is hub&spoke combined with full IPv4 addresses embedded in IPv6 = addresses. If forbidden, it should be documented. RD >=20 > Regards, > Woj >=20 >>=20 >> I don't see how the equivalent could work with the MAP documents you = edited. >> Is it that such a use case is out of scope for MAP? >> Or did I miss something? >>=20 >> Cheers, >> RD >>=20 >=20 From despres.remi@laposte.net Wed Feb 8 10:33:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4921F8592 for ; Wed, 8 Feb 2012 10:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aL9Zzh-wWg0 for ; Wed, 8 Feb 2012 10:33:41 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id D57E821F855B for ; Wed, 8 Feb 2012 10:33:40 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 566AF7000435; Wed, 8 Feb 2012 19:33:39 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 629AB700042F; Wed, 8 Feb 2012 19:33:38 +0100 (CET) X-SFR-UUID: 20120208183338405.629AB700042F@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8032174F-2879-45D0-9E20-62899126EAC6@gmail.com> Date: Wed, 8 Feb 2012 19:33:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <30435679-4CFA-4B9C-A68B-E55722987E6D@laposte.net> References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com> <8032174F-2879-45D0-9E20-62899126EAC6@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Wojciech Dec Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:33:41 -0000 Le 2012-02-08 =E0 13:43, Satoru Matsushima a =E9crit : > On 2012/02/07, at 17:53, R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 2012-02-07 =E0 17:35, Satoru Matsushima a =E9crit : >>=20 >>> On 2012/02/07, at 16:46, R=E9mi Despr=E9s wrote: >>>=20 >>> --snip-- >>>=20 >>>>>>=20 >>>>>>>>> I think that operators who already deploy such dual-stack = network is supposed that they have address mapping table, >>>>>>>>=20 >>>>>>>> I would rather suppose that ISPs that have added IPv6-prefix = delegation, say /56s, to an existing IPv4 network did it without mixing = their IPv6 plan with their IPv4 prefixes. >>>>>>>> I am ready, however, to look seriously at individual cases = where choices were different. >>>>>>>=20 >>>>>>> Basically provision MAP CE is based on its delegated IPv6 prefix = in concept. It is opposed to your case but technically possible. >>>>>>=20 >>>>>>=20 >>>>>>> Now I concern that it requires much complicated CE = implementation. >>>>>>=20 >>>>>> All what is required is that CEs set an address bit if hub&spoke = topology is required. >>>>>>=20 >>>>>=20 >>>>> So how CE decide to set the bit, and when the CE figure it out? >>>>=20 >>>> The CE knows it must set this bit if, and only if, it received at = initialization a Topology-variant parameter set to Hub&spoke (sec 4.1). >>>> In this case, the CE sets bit 79 to 1 in IPv6 destination addresses = of all packets it sends. >>>>=20 >>>> BTW, this bit should better, for clarity, be given a name, e.g. bit = B meaning To-BR bit (or whatever better idea one could propose). I plan = to do it in the next version. >>>>=20 >>>=20 >>> So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 = prefix as 4rd end point from IPv4 address which is already assigned. >>=20 >>=20 >> If the CE is delegated a prefix shorter than /64, it isn't concerned = with the To-BR bit. >> If it is delegated a /112, it finds its IPv4 address inom it.=20 >> It then must set the To-BR bit, in its outgoing IpV6 destinations, = iff the Topology variant is Hub&spoke. =20 >>=20 >=20 > As you described in your draft, if a CE is delegated /112 IPv6 prefix, = the CE automatically form itself for H&S mode and extract a non-sharing = IPv4 address from the /112 prefix. Hub&spoke vs Mesh is independent from /112. Otherwise, yes, a CE always derives its IPv4 address when it receives a = /112 matching the default mapping rule. >=20 >>=20 >>> Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. = right? >>=20 >> The CE always derives its 4rd prefix from its delegated IPv6 prefix, = based on the Mapping rule that has the longest match. >>=20 >=20 > So you mean that it is only specific case of which if the extracted = IPv4 address is same with an address assigned to a dual-stack interface = on the CE, the default route on the CE is forced to the BR, Yes, by setting the ToBR bit. > and keep that address on the dual-stack interface as NAPT source = address. Is that what you request to 4rd-U CE implementation? I think so. > It also requires operator to manage specific /112 route for each CE = that means IPv4 host routes are injected to the operator's IPv6 routing = table that's what Ole already pointed out. Well, an ISP has assigned that has assigned fixed IPv4 addresses, and = wants to keep them while moving to IPv6-only routing needs, one way or = another, to reflect IPv4 routes in IPv6.=20 > I agree with Ole that I'm doubt it could be widely acceptable = technique for operators. It is useful for ISPs that have this use case, even if there aren't = many, and in any case creates no harm for others. It is a way to encourage IPv6 routing for ISPs that don't want to = maintain DS routing. RD >=20 > cheers, > --satoru >=20 From yiu_lee@cable.comcast.com Wed Feb 8 10:37:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D2921F85EF for ; Wed, 8 Feb 2012 10:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk11C5s38iJA for ; Wed, 8 Feb 2012 10:37:01 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7934D21F85B4 for ; Wed, 8 Feb 2012 10:37:01 -0800 (PST) Received: from ([24.40.55.42]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.5547827; Wed, 08 Feb 2012 11:27:06 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 13:36:45 -0500 From: "Lee, Yiu" To: "Rajiv Asati (rajiva)" Thread-Topic: [Softwires] Stateless implementation plan Thread-Index: AQHM5pCbQi4to1RdukWr9pyZpPZWAw== Date: Wed, 8 Feb 2012 18:36:44 +0000 Message-ID: In-Reply-To: <1E2A9D37-5787-46E2-A0D4-B2E116FA0A80@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <89B26B077493CF4FBB2F6590D9196D6F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:37:02 -0000 +1 On 2/8/12 7:20 AM, "Rajiv Asati (rajiva)" wrote: >IOW, if CE is able to get native IPv6 anyway for MAP, then anything >non-native IPv6 would have no usage.=20 From yiu_lee@cable.comcast.com Wed Feb 8 10:39:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16E921F85D2 for ; Wed, 8 Feb 2012 10:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.269 X-Spam-Level: X-Spam-Status: No, score=-101.269 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9MYgcO2VYvP for ; Wed, 8 Feb 2012 10:39:53 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id ECBAB21F85C4 for ; Wed, 8 Feb 2012 10:39:52 -0800 (PST) Received: from ([24.40.55.42]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.5548619; Wed, 08 Feb 2012 11:30:07 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 13:39:47 -0500 From: "Lee, Yiu" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Tina Tsou Thread-Topic: [Softwires] Stateless implementation plan Thread-Index: AQHM5pEHxLw5CtuzHkqSHRKm7413Mw== Date: Wed, 8 Feb 2012 18:39:46 +0000 Message-ID: In-Reply-To: <0EE6D5C4-5C1D-484E-9BEA-45E072F7418F@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <53A61CF81691BB4E9E820CC29FE48157@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:39:53 -0000 Hi Remi, I know this is possible to do, in theory. However my question is more toward manageability of the network. IMHO, layering one tunnel (or translation) protocol on another tunnel protocol is asking for trouble. Cheers, /Yiu On 2/8/12 2:13 AM, "R=E9mi Despr=E9s" wrote: >6rd can be deployed over Net-10 networks (RFC1918) to deployIPv6. >Shared public IPv4 addresses can then be offered to customers via this >IPv6. >Such a use case, based on the header-mappiong variant of 4rd-U rather >than on a double MAP encapsulation, is described in >tools.ietf.org/html/draft-despres-softwire-4rd-u-03#section-5.4. > >RD > From cb.list6@gmail.com Wed Feb 8 11:49:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0834C11E809B for ; Wed, 8 Feb 2012 11:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEwdmQY40JVR for ; Wed, 8 Feb 2012 11:49:36 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02C11E8080 for ; Wed, 8 Feb 2012 11:49:36 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so911269pbc.31 for ; Wed, 08 Feb 2012 11:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LAWNukw6FPhA3ugHkPJbJZDS5FpiFvlk8vjDqxxAboY=; b=g8MzQMdR6skky1JEHRqGZ8oOlikqATmYhMP6mAeR3pA0VlPHMhcn7s72OV4+ZjYEKA MRHHeju347+fv37SFCISU/fs9atbhuIxPR6W9GvPUS0+XKgL7icdE/l+GzPPu+lxbLZI jGtn2MzvZEv/hz0bVnftmrGWmasjibyeqlWgE= MIME-Version: 1.0 Received: by 10.68.209.6 with SMTP id mi6mr71075810pbc.87.1328730575982; Wed, 08 Feb 2012 11:49:35 -0800 (PST) Received: by 10.143.164.16 with HTTP; Wed, 8 Feb 2012 11:49:35 -0800 (PST) In-Reply-To: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net> References: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net> Date: Wed, 8 Feb 2012 11:49:35 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:49:37 -0000 On Wed, Feb 8, 2012 at 1:23 AM, R=E9mi Despr=E9s = wrote: > Hi Behcet, > > Le 2012-02-08 =E0 09:46, Behcet Sarikaya a =E9crit : > >> Hi Cameron, >> 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd is >> not appropriate to be hosted in a UE. >> >> I think your solution 464XLAT's mobile part is way better for your >> purposes. There you can put all your IPv4 resources on the PLAT box so >> that CLAT box is kept simpler. >> >> In 4rd, CPEs have A+P and BR is kept "stateless" these are not so >> useful for your purposes, I think. > > Note however that: > - 464XLAT doesn't support shared IPv4 addresses (while 4rd does) Hmm... we may be getting off topic. 464XLAT definitely shares IPv4 addresses on the PLAT -- That is RFC 6146 -- statefule NAT64. Perhaps what you mean to say is that 464XLAT uses stateful sharing of IPv4 addresses as defined in RFC6146. The public IPv4 address resources are decoupled from the IPv4 service deployment at the edge. This is more flexible, IPv4 efficient, and allows for geographic redundancy of the translation exit points. So, to summarize. Both 4RD and 464XLAT support address sharing. One is stateless and the other is stateful. > - 4rd over 6rd can work, and therefore offer both IPv6 and shared-address= IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP (while 464XLAT cannot = AFAIK). > 4RD over 6RD? That is a lot of RD :) I believe the implementation report here shows that 464XLAT provides a good users experience on 3G networks http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html CB > Regards, > RD > >> >> Regards, >> >> Behcet >> >> >> On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne wrote= : >>> Are the map and 4rd solutions deployable for existing networks that do = not >>> have reserves =A0of ipv4 ? =A0My assumption is that these solutions tar= get >>> existing networks that have meaningful growth and they need a v6 soluti= on. >>> >>> If yes, how? Any pointers within the reams of drafts I should look for? >>> >>> In my brief and simple skimming, it appears to me that setting up one o= f >>> these solutions would require me to collapse my existing network to har= vest >>> back the addresses so that they may be redeployed in map. >>> >>> What would the deployment process be for an address exhausted network o= f 10 >>> million subs with 10% annual growth be? >>> >>> Cb >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From jacni@jacni.com Thu Feb 9 00:02:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974F321F8518 for ; Thu, 9 Feb 2012 00:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zprXcxnWu3yt for ; Thu, 9 Feb 2012 00:02:40 -0800 (PST) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id C103721F8508 for ; Thu, 9 Feb 2012 00:02:40 -0800 (PST) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id AB12A3800BE for ; Thu, 9 Feb 2012 03:02:38 -0500 (EST) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 047643400D7 for ; Thu, 9 Feb 2012 16:02:36 +0800 (CST) Received: from [114.87.135.99] (unknown [114.87.135.99]) by app (Coremail) with SMTP id +AWowJAbqgR+fTNPkTBtAA--.1649S2; Thu, 09 Feb 2012 16:02:22 +0800 (CST) Message-ID: <4F337E48.3050705@jacni.com> Date: Thu, 09 Feb 2012 16:05:28 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090204000706080208010603" X-CM-TRANSID: +AWowJAbqgR+fTNPkTBtAA--.1649S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKw45tF45GFWDCF15KF4UArb_yoWfZrg_uF 4DWa48Xw4qyrZ3Ka1xtF98ArsxC3yYg34UJa4kGw1jvFy0yFsFyrsrXrWkCr45GFy7Cr9x Gr1fXr1DCw4aqjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ-t7k0a2IF6F4UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_ Wr0E3s1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcV AKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI 7VAKI48JMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43 ZEXa7IU8ijjDUUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEQEko7lP+cMwBMs7 Cc: Softwires WG , =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:02:41 -0000 This is a multi-part message in MIME format. --------------090204000706080208010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Re-, +1, IMHO it's unacceptable in practice. Cheers, Jacni On 2/9/2012 2:39 AM, Lee, Yiu wrote: > Hi Remi, > > I know this is possible to do, in theory. However my question is more > toward manageability of the network. IMHO, layering one tunnel (or > translation) protocol on another tunnel protocol is asking for trouble. > > Cheers, > /Yiu > > On 2/8/12 2:13 AM, "Rémi Després" wrote: > >> 6rd can be deployed over Net-10 networks (RFC1918) to deployIPv6. >> Shared public IPv4 addresses can then be offered to customers via this >> IPv6. >> Such a use case, based on the header-mappiong variant of 4rd-U rather >> than on a double MAP encapsulation, is described in >> tools.ietf.org/html/draft-despres-softwire-4rd-u-03#section-5.4. >> >> RD >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --------------090204000706080208010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

+1,
IMHO it's unacceptable in practice.


Cheers,
Jacni

On 2/9/2012 2:39 AM, Lee, Yiu wrote: 
Hi Remi,

I know this is possible to do, in theory. However my question is more
toward manageability of the network. IMHO, layering one tunnel (or
translation) protocol on another tunnel protocol is asking for trouble.

Cheers,
/Yiu

On 2/8/12 2:13 AM, "Rémi Després" <remi.despres@free.fr> wrote:


6rd can be deployed over Net-10 networks (RFC1918) to deployIPv6.
Shared public IPv4 addresses can then be offered to customers via this
IPv6.
Such a use case, based on the header-mappiong variant of 4rd-U rather
than on a double MAP encapsulation, is described in
tools.ietf.org/html/draft-despres-softwire-4rd-u-03#section-5.4.

RD


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
--------------090204000706080208010603-- From despres.remi@laposte.net Thu Feb 9 00:40:04 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2237021F8613 for ; Thu, 9 Feb 2012 00:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqDVFFQ34iC3 for ; Thu, 9 Feb 2012 00:40:03 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC7721F854D for ; Thu, 9 Feb 2012 00:40:02 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id D59CF700013E; Thu, 9 Feb 2012 09:40:01 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 97CFA70000BF; Thu, 9 Feb 2012 09:40:01 +0100 (CET) X-SFR-UUID: 20120209084001621.97CFA70000BF@msfrf2116.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 9 Feb 2012 09:40:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DA169B8-57BC-4CCC-B8E1-25FBB9F9BD2A@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: softwires@ietf.org Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:40:04 -0000 Le 2012-02-08 =E0 20:49, Cameron Byrne a =E9crit : > On Wed, Feb 8, 2012 at 1:23 AM, R=E9mi Despr=E9s = wrote: >> Hi Behcet, >>=20 >> Le 2012-02-08 =E0 09:46, Behcet Sarikaya a =E9crit : >>=20 >>> Hi Cameron, >>> 4rd solution IMHO is more suitable for a fixed network. CPE in 4rd = is >>> not appropriate to be hosted in a UE. >>>=20 >>> I think your solution 464XLAT's mobile part is way better for your >>> purposes. There you can put all your IPv4 resources on the PLAT box = so >>> that CLAT box is kept simpler. >>>=20 >>> In 4rd, CPEs have A+P and BR is kept "stateless" these are not so >>> useful for your purposes, I think. >>=20 >> Note however that: >> - 464XLAT doesn't support shared IPv4 addresses (while 4rd does) >=20 > Hmm... we may be getting off topic. >=20 > 464XLAT definitely shares IPv4 addresses on the PLAT -- That is RFC > 6146 -- statefule NAT64. Well, if a customer _uses_ 464XLAT, it does get a full IPv4 address (sec = 6.1).=20 I don't see why a customer that has both an IPv6 prefix (used for more = and more of its traffic) and a full public IPv4 address would need needs = to use a NAT64. 464XLAT has a DNS proxy in CLATs, which I find a GOOD feature. Besides that, it ressembles to a subset of some solutions worked on in = Softwire, restricted to full IPv4 addresses and to hub and spoke. Relationship with these other solutions belongs AFAIK to Softwire.=20 > Perhaps what you mean to say is that 464XLAT uses stateful sharing of > IPv4 addresses as defined in RFC6146. The public IPv4 address > resources are decoupled from the IPv4 service deployment at the edge. > This is more flexible, IPv4 efficient, and allows for geographic > redundancy of the translation exit points. >=20 > So, to summarize. Both 4RD and 464XLAT support address sharing. One > is stateless and the other is stateful. >=20 >> - 4rd over 6rd can work, and therefore offer both IPv6 and = shared-address IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP = (while 464XLAT cannot AFAIK). >>=20 >=20 > 4RD over 6RD? >=20 > That is a lot of RD :) IPv4 Residual Deployment over IPv6 Rapid Deployment, why not? It is AFAIK a stateless alternative to PCP in DS-lite. Regards, RD >=20 > I believe the implementation report here shows that 464XLAT provides a > good users experience on 3G networks >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html >=20 > CB >=20 >> Regards, >> RD >>=20 >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>=20 >>> On Tue, Feb 7, 2012 at 9:05 AM, Cameron Byrne = wrote: >>>> Are the map and 4rd solutions deployable for existing networks that = do not >>>> have reserves of ipv4 ? My assumption is that these solutions = target >>>> existing networks that have meaningful growth and they need a v6 = solution. >>>>=20 >>>> If yes, how? Any pointers within the reams of drafts I should look = for? >>>>=20 >>>> In my brief and simple skimming, it appears to me that setting up = one of >>>> these solutions would require me to collapse my existing network to = harvest >>>> back the addresses so that they may be redeployed in map. >>>>=20 >>>> What would the deployment process be for an address exhausted = network of 10 >>>> million subs with 10% annual growth be? >>>>=20 >>>> Cb >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Thu Feb 9 00:40:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659B721F861E for ; Thu, 9 Feb 2012 00:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JG6xVaY5lXc for ; Thu, 9 Feb 2012 00:40:30 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id E14E821F8619 for ; Thu, 9 Feb 2012 00:40:29 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 40F637000642; Thu, 9 Feb 2012 09:40:29 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 0C6B27000140; Thu, 9 Feb 2012 09:40:28 +0100 (CET) X-SFR-UUID: 20120209084029509.0C6B27000140@msfrf2116.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 9 Feb 2012 09:40:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <700BA18F-16F0-4DD3-ABD9-E6BFB81B00C5@laposte.net> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: Re: [Softwires] Stateless implementation plan X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:40:30 -0000 Le 2012-02-08 =E0 19:39, Lee, Yiu a =E9crit : > Hi Remi, >=20 > I know this is possible to do, in theory. However my question is more > toward manageability of the network. IMHO, layering one tunnel (or > translation) protocol on another tunnel protocol is asking for = trouble. No obligation to do it, of course. Noting that it is possible doesn't hurt though. Personally, I find it legitimate to be careful before pretending to = offer more service than before, but I don't see which trouble would = result from IPv6 (with IPv4 embedded addresses) encapsulated in IPv4 = (with RFC1918 addresses).=20 Cheers, RD >=20 > Cheers, > /Yiu >=20 > On 2/8/12 2:13 AM, "R=E9mi Despr=E9s" wrote: >=20 >> 6rd can be deployed over Net-10 networks (RFC1918) to deployIPv6. >> Shared public IPv4 addresses can then be offered to customers via = this >> IPv6. >> Such a use case, based on the header-mappiong variant of 4rd-U rather >> than on a double MAP encapsulation, is described in >> tools.ietf.org/html/draft-despres-softwire-4rd-u-03#section-5.4. >>=20 >> RD >>=20 >=20 From despres.remi@laposte.net Thu Feb 9 01:39:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC9621F86C6 for ; Thu, 9 Feb 2012 01:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsJ2wZ2OygBV for ; Thu, 9 Feb 2012 01:39:57 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED521F86C3 for ; Thu, 9 Feb 2012 01:39:56 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id 4A2AF7000192; Thu, 9 Feb 2012 10:39:55 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id 3221B700017F; Thu, 9 Feb 2012 10:39:54 +0100 (CET) X-SFR-UUID: 20120209093954205.3221B700017F@msfrf2408.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> Date: Thu, 9 Feb 2012 10:39:53 +0100 Content-Transfer-Encoding: 7bit Message-Id: <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Feature comparison table X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 09:39:57 -0000 New version, after a discussion with Ole: +----+--------------------------------------+-----+-----+-----+-----+ | | Feature (based on CURRENT drafts) | MAP | MAP | 4rd | 4rd | | | | -T | -E | -H | -E | +----+--------------------------------------+-----+-----+-----+-----+ | 1 | Full Transparency to IPv4 DF bit | N | Y | Y | Y | | | | | | | | | 2 | ISP can impose a Tunnel traffic | N | Y | Y | Y | | | class | | | | | | | | | | | | | 3 | Possible support of CEs behind | N | N | Y | Y | | | third-party CPEs | | | | | | | | | | | | | 4 | IPv6 port-based ACLs work for IPv4 | Y | N | Y | N | | | packets | | | | | | | | | | | | | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N | | | packets | | | | | | | | | | | | | 6 | No constraint on host addresses or | N | N | Y | Y | | | subnet prefixes in CE sites (V-octet | | | | | | | format) | | | | | | | | | | | | | 7 | Number of excluded ports is flexible | Y | Y | N | N | | | (GMA algorithm, 2 parameters) | | | | | | | | | | | | | 8 | Possible migration from DS routing | N | N | Y | Y | | | to IPv6-only routing without | | | | | | | changing CE addresses and/or | | | | | | | prefixes (DMR may apply to CEs) | | | | | | | | | | | | | 9 | BRs need no change for any new | N | N | Y | Y | | | protocol having ports at their usual | | | | | | | place and TCP-like checksum | | | | | | | (checksum neutrality) | | | | | | | | | | | | | 10 | IPv4-options supported | N | Y | N | N | | | | | | | | | 11 | Datagram reassembly avoided in BRs | N | N | Y | Y | | | | | | | | | 12 | Packet IDs from shared-address CEs | N | Y | Y | Y | | | cannot be confused in destinations | | | | | | | | | | | | | 13 | The number of rules CEs must be able | N | N | Y | Y | | | to support is defined | | | | | | | | | | | | | 14 | Minimum IP header length | 40 | 60 | 48 | 60 | +----+--------------------------------------+-----+-----+-----+-----+ From despres.remi@laposte.net Thu Feb 9 02:07:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3718521F8663 for ; Thu, 9 Feb 2012 02:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwkKamS-qp7P for ; Thu, 9 Feb 2012 02:07:16 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id 74E6821F8622 for ; Thu, 9 Feb 2012 02:07:16 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id CAD7C7000108; Thu, 9 Feb 2012 11:07:15 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id E0038700008E; Thu, 9 Feb 2012 11:07:14 +0100 (CET) X-SFR-UUID: 20120209100714917.E0038700008E@msfrf2507.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Feb 2012 11:07:11 +0100 Message-Id: <25D87EBB-9201-4E56-93C2-5ED834C8D99A@laposte.net> To: Alain Durand , Yong Cui , Ralph Droms Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: [Softwires] MAP and 4rd - Feature comparison table -02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 10:07:17 -0000 New version, after a discussion with Ole: +----+--------------------------------------+-----+-----+-----+-----+ | | Feature (based on CURRENT drafts) | MAP | MAP | 4rd | 4rd | | | | -T | -E | -H | -E | +----+--------------------------------------+-----+-----+-----+-----+ | 1 | Full Transparency to IPv4 DF bit | N | Y | Y | Y | | | | | | | | | 2 | ISP can impose a Tunnel traffic | N | Y | Y | Y | | | class | | | | | | | | | | | | | 3 | Possible support of CEs behind | N | N | Y | Y | | | third-party CPEs | | | | | | | | | | | | | 4 | IPv6 port-based ACLs work for IPv4 | Y | N | Y | N | | | packets | | | | | | | | | | | | | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N | | | packets | | | | | | | | | | | | | 6 | No constraint on host addresses or | N | N | Y | Y | | | subnet prefixes in CE sites (V-octet | | | | | | | format) | | | | | | | | | | | | | 7 | Number of excluded ports is flexible | Y | Y | N | N | | | (GMA algorithm, 2 parameters) | | | | | | | | | | | | | 8 | Possible migration from DS routing | N | N | Y | Y | | | to IPv6-only routing without | | | | | | | changing CE addresses and/or | | | | | | | prefixes (DMR may apply to CEs) | | | | | | | | | | | | | 9 | BRs need no change for any new | N | N | Y | Y | | | protocol having ports at their usual | | | | | | | place and TCP-like checksum | | | | | | | (checksum neutrality) | | | | | | | | | | | | | 10 | IPv4-options supported | N | Y | N | N | | | | | | | | | 11 | Datagram reassembly avoided in BRs | N | N | Y | Y | | | | | | | | | 12 | Packet IDs from shared-address CEs | N | Y | Y | Y | | | cannot be confused in destinations | | | | | | | | | | | | | 13 | The number of rules CEs must be able | N | N | Y | Y | | | to support is defined | | | | | | | | | | | | | 14 | Minimum IP header length | 40 | 60 | 48 | 60 | +----+--------------------------------------+-----+-----+-----+-----+ From ichiroumakino@gmail.com Thu Feb 9 09:23:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2921921F85F9 for ; Thu, 9 Feb 2012 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwC1IyrjlDNl for ; Thu, 9 Feb 2012 09:23:21 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A76BC21F85F4 for ; Thu, 9 Feb 2012 09:23:20 -0800 (PST) Received: by werm10 with SMTP id m10so1915067wer.31 for ; Thu, 09 Feb 2012 09:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=MwcfOqixVXXEMKvbFRJfJe3VhSPP0gYuFqQVQ1wAe8k=; b=cOXRrKVlF3d3cuewaa8Nr5DlH2g/5nm3viFqfgDlh1TJjFfF/ZWRuwQBSjamRwAKOW zqCbYJKkUFdksxDYXI6FDmeaEXTKniSkAs5PWenzK6qyh4g8ZKuUYDLrSKjmWQ694Tv4 wIU4ibfkhLv4OefTbOzdCKaYGlNNmxh5mALH8= Received: by 10.216.139.97 with SMTP id b75mr8623633wej.0.1328808197160; Thu, 09 Feb 2012 09:23:17 -0800 (PST) Received: from ams3-vpn-dhcp4248.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y6sm7989162wix.10.2012.02.09.09.23.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 09:23:16 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> Date: Thu, 9 Feb 2012 18:23:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96214733-7D45-436E-81C2-6E6701542C79@employees.org> References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Feature comparison table X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:23:22 -0000 >=20 > New version, after a discussion with Ole: >=20 > = +----+--------------------------------------+-----+-----+-----+-----+ > | | Feature (based on CURRENT drafts) | MAP | MAP | 4rd | 4rd = | > | | | -T | -E | -H | -E = | > = +----+--------------------------------------+-----+-----+-----+-----+ > | 1 | Full Transparency to IPv4 DF bit | N | Y | Y | Y = | > | | | | | | = | > | 2 | ISP can impose a Tunnel traffic | N | Y | Y | Y = | > | | class | | | | = | > | | | | | | = | > | 3 | Possible support of CEs behind | N | N | Y | Y = | > | | third-party CPEs | | | | = | possible with MAP-{E,T} too, but may require coordination of subnet = numbering. in all solutions will require a different provisioning model. > | | | | | | = | > | 4 | IPv6 port-based ACLs work for IPv4 | Y | N | Y | N = | > | | packets | | | | = | suggest we rename this to "IPv6 features can be applied to the payload = packet"? (we're talking about applying features in between the translators/tunnel = endpoints here). you could also add a new feature: "possible to apply IPv4 features on the payload" which is possible if = IPv4 features are enhanced to support offset the tunnel encap header. so: | 4.1 | IPv6 features can be applied to the payload packet" | Y | N | Y = | N| | 4.2 | IPv4 features can be applied to the payload with | N | Y | N = | Y| | | "tunnel vision =20 > | | | | | | = | > | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N = | > | | packets | | | | = | suggest you rename to "IPv4 to IPv6 communication (single translation) = supported" > | | | | | | = | > | 6 | No constraint on host addresses or | N | N | Y | Y = | > | | subnet prefixes in CE sites (V-octet | | | | = | > | | format) | | | | = | I don't agree with this wording. actually the MAP interface-id has less = constraints, in that it doesn't depend on the V-octet. what about = emphasizing the problem V solves? "Native IPv6 hosts can co-exist with MAP node on the same subnet" or "Reserved subnet needed for MAP function" I also think you need to add: | N | "New format of interface-id needs to be standardized | N | N | Y | = Y | > | | | | | | = | > | 7 | Number of excluded ports is flexible | Y | Y | N | N = | > | | (GMA algorithm, 2 parameters) | | | | = | > | | | | | | = | > | 8 | Possible migration from DS routing | N | N | Y | Y = | > | | to IPv6-only routing without | | | | = | > | | changing CE addresses and/or | | | | = | > | | prefixes (DMR may apply to CEs) | | | | = | all mechanisms do support this. this is purely a deployment option in my = mind, more than it separates the mechanisms. I would suggest you drop = it. it requires a separate IPv6 prefix purely for the MAP function, and it = requires importing IPv4 routing into IPv6. > | | | | | | = | > | 9 | BRs need no change for any new | N | N | Y | Y = | > | | protocol having ports at their usual | | | | = | > | | place and TCP-like checksum | | | | = | > | | (checksum neutrality) | | | | = | I don't think that is correct. an implementation would have to verify = that the ports is actually in the place the algorithm expects. and it = needs to check that the transport protocol uses a TCP-like checksum. any MAP node MUST be L4 aware. you could add: |9.1|New transport protocols can be supported regardless of L4 header = format and checksum algorithm| Y | Y | N | N | > | | | | | | = | > | 10 | IPv4-options supported | N | Y | N | N = | > | | | | | | = | > | 11 | Datagram reassembly avoided in BRs | N | N | Y | Y = | right, I would expect this would be added to MAP too. > | | | | | | = | > | 12 | Packet IDs from shared-address CEs | N | Y | Y | Y = | > | | cannot be confused in destinations | | | | = | likewise for this one. so it would be Y all around. > | | | | | | = | > | 13 | The number of rules CEs must be able | N | N | Y | Y = | > | | to support is defined | | | | = | do we typically state the lower limit of the size of tables (e.g. BGP = table) in IETF specifications? > | | | | | | = | > | 14 | Minimum IP header length | 40 | 60 | 48 | 60 = | > = +----+--------------------------------------+-----+-----+-----+-----+ I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | = 40 | I also suggest you add the features: | 15 | Handle IPv4 UDP checksum =3D 0 | Y | Y | N | Y | | 16 | Running code | Y | N | N | N | cheers, Ole From Tina.Tsou.Zouting@huawei.com Thu Feb 9 18:13:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BF711E8075; Thu, 9 Feb 2012 18:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj-Kl-OykHk2; Thu, 9 Feb 2012 18:13:35 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E335311E8076; Thu, 9 Feb 2012 18:13:33 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ5004XFNEIU7@szxga03-in.huawei.com>; Fri, 10 Feb 2012 10:11:06 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500L5CNEFPJ@szxga03-in.huawei.com>; Fri, 10 Feb 2012 10:11:06 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ93690; Fri, 10 Feb 2012 10:11:05 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 10:10:22 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 10 Feb 2012 10:11:15 +0800 Date: Fri, 10 Feb 2012 02:10:47 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.244.142] To: Linda Dunbar , Shishio Tsuchiya Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt Thread-index: AQHM55OqKuMa1bvJ8kCzdvdIpYIP2ZY1Yw1A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> <4F320549.20100@cisco.com> Cc: "softwires@ietf.org" , "v6ops@ietf.org" , "armd@ietf.org" , "draft-sakura-6rd-datacenter@tools.ietf.org" Subject: Re: [Softwires] [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 02:13:36 -0000 --Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Tina From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 09, 2012 3:26 PM To: Shishio Tsuchiya Cc: softwires@ietf.org; v6ops@ietf.org; draft-sakura-6rd-datacenter@tools.ietf.org; armd@ietf.org Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt Shishio, Thank you very much for sharing the v6 deployment in data center. I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation? Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks? [Tina] In my case, yes. Thanks, Linda Dunbar On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya > wrote: v6ops and ARMD Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. We thought this is interesting idea,so published the draft. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 I think both of mailing list participants are also interesting in this technique. If you have any comment and question of the draft,please let me know. Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt Date: Mon, 14 Nov 2011 17:21:26 +0800 From: > Reply-To: > To: > A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Rapid Deployment (6rd) in a Large Data Center Author(s) : Shishio Tsuchiya Mark Townsley Shuichi Ohkubo Filename : draft-sakura-6rd-datacenter-03.txt Pages : 15 Date : 2011-11-14 IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid deployment of IPv6 by an access service provider which has difficulty deploying native IPv6. This document describes how 6rd can be used to deliver IPv6 within a Large Data Center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd --Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

 

Tina

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, February 09, 2012 3:26 PM
To: Shishio Tsuchiya
Cc: softwires@ietf.org; v6ops@ietf.org; draft-sakura-6rd-datacenter@tools.ietf.org; armd@ietf.org
Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt

 

Shishio,

Thank you very much for sharing the v6 deployment in data center.

I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation?


Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks?

[Tina] In my case, yes.



Thanks, Linda Dunbar




On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya <shtsuchi@cisco.com> wrote:

v6ops and ARMD
Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd.
We thought this is interesting idea,so published the draft.

http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03

I think both of mailing list participants are also interesting in this technique.
If you have any comment and question of the draft,please let me know.

Regards,
-Shishio
-------- Original Message --------
Subject:        I-D Action: draft-sakura-6rd-datacenter-03.txt
Date:   Mon, 14 Nov 2011 17:21:26 +0800
From:   <internet-drafts@ietf.org>
Reply-To:       <internet-drafts@ietf.org>
To:     <i-d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : IPv6 Rapid Deployment (6rd) in a Large Data Center
Author(s) : Shishio Tsuchiya
Mark Townsley
Shuichi Ohkubo
Filename : draft-sakura-6rd-datacenter-03.txt
Pages : 15
Date : 2011-11-14

IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid
deployment of IPv6 by an access service provider which has difficulty
deploying native IPv6. This document describes how 6rd can be used
to deliver IPv6 within a Large Data Center.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

 

--Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ)-- From xing@cernet.edu.cn Thu Feb 9 19:29:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4123011E809C for ; Thu, 9 Feb 2012 19:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.646 X-Spam-Level: X-Spam-Status: No, score=-99.646 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wfWdLQh8AWM for ; Thu, 9 Feb 2012 19:29:04 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id DD7A111E8086 for ; Thu, 9 Feb 2012 19:28:55 -0800 (PST) Received: from [127.0.0.1] (unknown [223.198.196.80]) by centos (Coremail) with SMTP id AQAAf3AbxAVbjjRPLDcJAA--.27896S2; Fri, 10 Feb 2012 11:26:21 +0800 (CST) Message-ID: <4F348EEB.4050908@cernet.edu.cn> Date: Fri, 10 Feb 2012 11:28:43 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> In-Reply-To: <96214733-7D45-436E-81C2-6E6701542C79@employees.org> Content-Type: multipart/alternative; boundary="------------050709070303040708070009" X-CM-TRANSID: AQAAf3AbxAVbjjRPLDcJAA--.27896S2 X-Coremail-Antispam: 1UD129KBjvJXoWxtryUXr1fur4Utry7uFWrGrg_yoWxXF1UpF 1fGr13Ga1DtF15Aw4kJF48W3W5Ar4rJa15Jr15trykA398CF1kKw4YyF9Y93yUJryrXw1U XrWjkrn5AF4kZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU6F14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjc xK6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28E F7xvwVC2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I 8CrVAqjxCE14ACF2xKxwAqx4xG6I8vx48I62xC7I0kMcIj6I8E87Iv67AKxVWUJVW8JwAm 72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7Mx 8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI7VAKI48J MI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67 AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAI cVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa 73UjIFyTuYvjfUzzuWDUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] MAP and 4rd - Feature comparison table X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 03:29:08 -0000 This is a multi-part message in MIME format. --------------050709070303040708070009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit ? 2012/2/10 1:23, Ole Trøan ??: >> New version, after a discussion with Ole: >> >> +----+--------------------------------------+-----+-----+-----+-----+ >> | | Feature (based on CURRENT drafts) | MAP | MAP | 4rd | 4rd | >> | | | -T | -E | -H | -E | >> +----+--------------------------------------+-----+-----+-----+-----+ >> | 1 | Full Transparency to IPv4 DF bit | N | Y | Y | Y | (1) More clarification should be added for the IPv4 DF bit transparency issue, i.e. the advantages versus cost. (a) MAP-T is almost DF bit transparent, expect a special case which 4rd-H addresses (the case with DF=1 and MF=1). However, based on the experimental data, this kind of packets is about 0.1% of the total packets (mainly TCP) and is not representing the production traffic. (b) The cost to achieve the full transparency to IPv4 DF bit is that the IPv6 packets which 4rd-H generates will always contain fragmentation headers. In addition, the middle bits of the IPv6 ID fields in the IPv6 fragmentation header will contain the IPv4 TOS information. By my understanding, these are changes to the standard of the IPv6 architecture and careful study for the impact to the current network devices (firewall)/end systems should be taken. We should not run into a situation that there are packets containing headers look like IPv6 headers, but not really IPv6 headers according the current standard of the IPv6 architecture. If people do need the full transparency to IPv4 DF bit, use encapsulation. >> | | | | | | | >> | 2 | ISP can impose a Tunnel traffic | N | Y | Y | Y | >> | | class | | | | | >> | | | | | | | >> | 3 | Possible support of CEs behind | N | N | Y | Y | >> | | third-party CPEs | | | | | > possible with MAP-{E,T} too, but may require coordination of subnet numbering. > in all solutions will require a different provisioning model. > >> | | | | | | | >> | 4 | IPv6 port-based ACLs work for IPv4 | Y | N | Y | N | >> | | packets | | | | | > suggest we rename this to "IPv6 features can be applied to the payload packet"? > (we're talking about applying features in between the translators/tunnel endpoints here). > you could also add a new feature: > "possible to apply IPv4 features on the payload" which is possible if IPv4 features are enhanced to support offset the tunnel encap header. > so: > | 4.1 | IPv6 features can be applied to the payload packet" | Y | N | Y | N| > | 4.2 | IPv4 features can be applied to the payload with | N | Y | N | Y| > | | "tunnel vision > >> | | | | | | | >> | 5 | IPv6 web caches work for IPv4 | Y | N | Y | N | >> | | packets | | | | | > suggest you rename to "IPv4 to IPv6 communication (single translation) supported" > (2) More clarification should be added here. I am not sure 4rd-H can support single translation. (a) According to (1), 4rd-H does not perform header translation defined by RFC6145. (b) In the softwire mailing list, it seems that 4rd-H cannot support single translation. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. (c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets. >> | | | | | | | >> | 6 | No constraint on host addresses or | N | N | Y | Y | >> | | subnet prefixes in CE sites (V-octet | | | | | >> | | format) | | | | | > I don't agree with this wording. actually the MAP interface-id has less constraints, in that it doesn't depend on the V-octet. what about emphasizing the problem V solves? > > "Native IPv6 hosts can co-exist with MAP node on the same subnet" > or "Reserved subnet needed for MAP function" > > I also think you need to add: > | N | "New format of interface-id needs to be standardized | N | N | Y | Y | > > (3) The introduction of the V-octet is another change to the standard of the IPv6 architecture. We should be very careful and study the impacts to the existing network. >> | | | | | | | >> | 7 | Number of excluded ports is flexible | Y | Y | N | N | >> | | (GMA algorithm, 2 parameters) | | | | | >> | | | | | | | >> | 8 | Possible migration from DS routing | N | N | Y | Y | >> | | to IPv6-only routing without | | | | | >> | | changing CE addresses and/or | | | | | >> | | prefixes (DMR may apply to CEs) | | | | | > all mechanisms do support this. this is purely a deployment option in my mind, more than it separates the mechanisms. I would suggest you drop it. > it requires a separate IPv6 prefix purely for the MAP function, and it requires importing IPv4 routing into IPv6. > >> | | | | | | | >> | 9 | BRs need no change for any new | N | N | Y | Y | >> | | protocol having ports at their usual | | | | | >> | | place and TCP-like checksum | | | | | >> | | (checksum neutrality) | | | | | > I don't think that is correct. an implementation would have to verify that the ports is actually in the place the algorithm expects. and it needs to check that the transport protocol uses a TCP-like checksum. > any MAP node MUST be L4 aware. > you could add: > > |9.1|New transport protocols can be supported regardless of L4 header format and checksum algorithm| Y | Y | N | N | > >> | | | | | | | >> | 10 | IPv4-options supported | N | Y | N | N | >> | | | | | | | >> | 11 | Datagram reassembly avoided in BRs | N | N | Y | Y | > right, I would expect this would be added to MAP too. > >> | | | | | | | >> | 12 | Packet IDs from shared-address CEs | N | Y | Y | Y | >> | | cannot be confused in destinations | | | | | > likewise for this one. so it would be Y all around. > >> | | | | | | | >> | 13 | The number of rules CEs must be able | N | N | Y | Y | >> | | to support is defined | | | | | > do we typically state the lower limit of the size of tables (e.g. BGP table) in IETF specifications? > >> | | | | | | | >> | 14 | Minimum IP header length | 40 | 60 | 48 | 60 | >> +----+--------------------------------------+-----+-----+-----+-----+ > I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | 40 | > > I also suggest you add the features: > > | 15 | Handle IPv4 UDP checksum = 0 | Y | Y | N | Y | > | 16 | Running code | Y | N | N | N | (4) This is a very important point. We need running code and experiments to prove a new design. (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.Please add | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | I also agree with other comments Ole presented in the mail. Regards, xing > cheers, > Ole > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --------------050709070303040708070009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 于 2012/2/10 1:23, Ole Trøan 写道: 

      

        
New version, after a discussion with Ole:

  +----+--------------------------------------+-----+-----+-----+-----+
  |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
  |    |                                      |  -T |  -E |  -H |  -E |
  +----+--------------------------------------+-----+-----+-----+-----+
  |  1 | Full Transparency to IPv4 DF bit     |  N  |  Y  |  Y  |  Y  |


      

    

    

    (1)
      More clarification should be added for the IPv4 DF
      bit transparency issue, i.e. the advantages versus cost.

      

      (a) MAP-T is almost DF bit transparent, expect a special case
      which 4rd-H
      addresses (the case with DF=1 and MF=1). However, based on the
      experimental
      data, this kind of packets is about 0.1% of the total packets
      (mainly TCP) and
      is not representing the production traffic. 

      

      (b) The cost to achieve the full transparency to IPv4 DF bit is
      that the IPv6
      packets which 4rd-H generates will always contain fragmentation
      headers. 
      In addition, the middle bits of the IPv6 ID fields in the IPv6
      fragmentation
      header will contain the IPv4 TOS information.  By my
      understanding, these
      are changes to the standard of the IPv6 architecture and careful
      study for the impact to the
      current network devices (firewall)/end systems should be taken. We
      should not run into a situation that there are
      packets containing headers look like IPv6 headers, but not really
      IPv6 headers
      according the current standard of the IPv6 architecture. If people
      do need the full
      transparency to IPv4 DF bit, use encapsulation.

      

    

    

      

        
  |    |                                      |     |     |     |     |
  |  2 | ISP can impose a Tunnel traffic      |  N  |  Y  |  Y  |  Y  |
  |    | class                                |     |     |     |     |
  |    |                                      |     |     |     |     |
  |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
  |    | third-party CPEs                     |     |     |     |     |


      

      
possible with MAP-{E,T} too, but may require coordination of subnet numbering.
in all solutions will require a different provisioning model.



    

    

    

      

      

        
  |    |                                      |     |     |     |     |
  |  4 | IPv6 port-based ACLs work for IPv4   |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |


      

      
suggest we rename this to "IPv6 features can be applied to the payload packet"?
(we're talking about applying features in between the translators/tunnel endpoints here).
you could also add a new feature:
 "possible to apply IPv4 features on the payload" which is possible if IPv4 features are enhanced to support offset the tunnel encap header.
so:


    

    

    

      
| 4.1 | IPv6 features can be applied to the payload packet"  | Y | N | Y | N|
| 4.2 | IPv4 features can be applied to the payload with     | N | Y | N | Y|
|     | "tunnel vision                                  



      

        
  |    |                                      |     |     |     |     |
  |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |


      

      
suggest you rename to "IPv4 to IPv6 communication (single translation) supported"



    

    

      (2) More clarification should be added here. I am not
      sure 4rd-H can support single translation.

      

      (a) According to (1), 4rd-H does not perform header translation
      defined by
      RFC6145. 

      

      (b) In the softwire mailing list, it seems that 4rd-H cannot
      support single
      translation. 
      See the thread containing
      http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html
      and other posts.

      

      (c) If 4rd-H cannot support single translation, then "IPv6 web
      caches work for IPv4 packets" requires special configurations, it
      cannot do IPv6 web
      caches for non 4rd-H packets.

    

    

      

      

        
  |    |                                      |     |     |     |     |
  |  6 | No constraint on host addresses or   |  N  |  N  |  Y  |  Y  |
  |    | subnet prefixes in CE sites (V-octet |     |     |     |     |
  |    | format)                              |     |     |     |     |


      

      
I don't agree with this wording. actually the MAP interface-id has less constraints, in that it doesn't depend on the V-octet. what about emphasizing the problem V solves?

"Native IPv6 hosts can co-exist with MAP node on the same subnet"
or  "Reserved subnet needed for MAP function"

I also think you need to add:
| N | "New format of interface-id needs to be standardized | N | N | Y | Y |




    

    

      (3) The introduction of the V-octet is another change to the
      standard of the IPv6 architecture. We should be very careful and
      study the impacts to the
      existing network. 

    

    

      

      

        
  |    |                                      |     |     |     |     |
  |  7 | Number of excluded ports is flexible |  Y  |  Y  |  N  |  N  |
  |    | (GMA algorithm, 2 parameters)        |     |     |     |     |
  |    |                                      |     |     |     |     |
  |  8 | Possible migration from DS routing   |  N  |  N  |  Y  |  Y  |
  |    | to IPv6-only routing without         |     |     |     |     |
  |    | changing CE addresses and/or         |     |     |     |     |
  |    | prefixes (DMR may apply to CEs)      |     |     |     |     |


      

      
all mechanisms do support this. this is purely a deployment option in my mind, more than it separates the mechanisms. I would suggest you drop it.
it requires a separate IPv6 prefix purely for the MAP function, and it requires importing IPv4 routing into IPv6.



      

        
  |    |                                      |     |     |     |     |
  |  9 | BRs need no change for any new       |  N  |  N  |  Y  |  Y  |
  |    | protocol having ports at their usual |     |     |     |     |
  |    | place and TCP-like checksum          |     |     |     |     |
  |    | (checksum neutrality)                |     |     |     |     |


      

      
I don't think that is correct. an implementation would have to verify that the ports is actually in the place the algorithm expects. and it needs to check that the transport protocol uses a TCP-like checksum.
any MAP node MUST be L4 aware.
you could add:

|9.1|New transport protocols can be supported regardless of L4 header format and checksum algorithm| Y | Y | N | N |



      

        
  |    |                                      |     |     |     |     |
  | 10 | IPv4-options supported               |  N  |  Y  |  N  |  N  |
  |    |                                      |     |     |     |     |
  | 11 | Datagram reassembly avoided in BRs   |  N  |  N  |  Y  |  Y  |


      

      
right, I would expect this would be added to MAP too.



      

        
  |    |                                      |     |     |     |     |
  | 12 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  |
  |    | cannot be confused in destinations   |     |     |     |     |


      

      
likewise for this one. so it would be Y all around.



      

        
  |    |                                      |     |     |     |     |
  | 13 | The number of rules CEs must be able |  N  |  N  |  Y  |  Y  |
  |    | to support is defined                |     |     |     |     |


      

      
do we typically state the lower limit of the size of tables (e.g. BGP table) in IETF specifications?



      

        
  |    |                                      |     |     |     |     |
  | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 |
  +----+--------------------------------------+-----+-----+-----+-----+


      

      
I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | 40 |

I also suggest you add the features:

| 15 | Handle IPv4 UDP checksum = 0 | Y | Y | N | Y |
| 16 | Running code                 | Y | N | N | N |


    

    

    (4)
      This is a very important point. We need running code and
      experiments to prove a new design.

      

      (5) I would like to see the details of how 4rd-H handles ICMP and
      ICMP error messages. In the softwire mailing list there were some
      discussions. See the thread containing
      http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html
      and other posts. Please add

      

    
    
| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? |

    
      

      I also agree with other comments Ole presented in the mail.

      

      Regards,

      

      xing

      

    

    

    

      
cheers,
Ole

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



    

    

  


--------------050709070303040708070009--


From shtsuchi@cisco.com  Thu Feb  9 20:44:37 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFEF21F85DB; Thu,  9 Feb 2012 20:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level: 
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-4.336, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_84=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TECnOlY6X4y; Thu,  9 Feb 2012 20:44:36 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 51BDD21F85D8; Thu,  9 Feb 2012 20:44:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=4214; q=dns/txt; s=iport; t=1328849073; x=1330058673; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9Q7NnMHNjXBGTghYArNDL/ysh93IonMuhYwPRjMb2CI=; b=gyLg8esOZNjj4eszpun97L2pwrJUFO8iz4eBNMFa7dJOg/b1fItWyY9L JolTPmX3cKxLbBnGa09/fzawzjy4HYYIw65/rJ7HJ79XpEQ2LKRQWUh85 +QHeBsCDjmPdFynvCxf4PbJcQcanyjwSSwYxyfSQ/jBmnRcdAPnRTx/CH g=;
X-IronPort-AV: E=Sophos;i="4.73,394,1325462400";  d="scan'208";a="5237742"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 10 Feb 2012 04:44:30 +0000
Received: from [64.104.53.150] (dhcp-tmt-wirelessdata-64-104-53-150.cisco.com [64.104.53.150]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1A4iT3b019125; Fri, 10 Feb 2012 04:44:29 GMT
Message-ID: <4F34A0AD.4040300@cisco.com>
Date: Fri, 10 Feb 2012 13:44:29 +0900
From: Shishio Tsuchiya 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: dunbar.ll@gmail.com
References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com><4F320549.20100@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: softwires@ietf.org, v6ops@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org
Subject: Re: [Softwires] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2012 04:44:37 -0000

Linda
Thanks for comments.

(2012/02/10 8:26), Linda Dunbar wrote:
> Shishio,
> 
> Thank you very much for sharing the v6 deployment in data center.
> 
> I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation?

Yes.
6rd is IPv6 over IPv4 tunnel technology.
So backbone operator does not need to care to IPv6 on the core.
Additionally 6rd has stateless feature.
Once the operator has placed/configured 6rd BR on the exit point to the IPv6 internet,does not need additional operation to add 6rd CE(server based 6rd).
And if the server would like to go  to the IPv6 internet,then IPv4 packets will through 6rd BR and de-capsulate.
If the server would like to communicate other 6rd server within the data center,then IPv4 packets will reach 6rd server directly and de-capsulate.

> 
> 
> Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks?

In Sakura internet 6rd cases,each of 6rd server has one 6rd delegate prefix(/64).
http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03#section-4.1

The 6rd delegate prefix calculates from Sakura's IPv6 prefix(/32) and IPv4 address.
Sakura has the scalability problem which is same as ARMD draft.
http://tools.ietf.org/html/draft-ietf-armd-problem-statement-00

They also had to update switches to resolve security issue(Rogue RA).
http://tools.ietf.org/html/rfc6104

They selected "server-based 6rd" as the solution to avoid scalability and security problem.

Regards,
-Shishio


> 
> Thanks, Linda Dunbar
> 
> 
> 
> 
> 
> On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya > wrote:
> 
>     v6ops and ARMD
>     Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd.
>     We thought this is interesting idea,so published the draft.
> 
>     http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03
> 
>     I think both of mailing list participants are also interesting in this technique.
>     If you have any comment and question of the draft,please let me know.
> 
>     Regards,
>     -Shishio
>     -------- Original Message --------
>     Subject:        I-D Action: draft-sakura-6rd-datacenter-03.txt
>     Date:   Mon, 14 Nov 2011 17:21:26 +0800
>     From: >
>     Reply-To: >
>     To: >
> 
> 
> 
>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>     Title : IPv6 Rapid Deployment (6rd) in a Large Data Center
>     Author(s) : Shishio Tsuchiya
>     Mark Townsley
>     Shuichi Ohkubo
>     Filename : draft-sakura-6rd-datacenter-03.txt
>     Pages : 15
>     Date : 2011-11-14
> 
>     IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid
>     deployment of IPv6 by an access service provider which has difficulty
>     deploying native IPv6. This document describes how 6rd can be used
>     to deliver IPv6 within a Large Data Center.
> 
> 
>     A URL for this Internet-Draft is:
>     http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt
> 
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
> 
>     This Internet-Draft can be retrieved at:
>     ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt
>     _______________________________________________
>     I-D-Announce mailing list
>     I-D-Announce@ietf.org 
>     https://www.ietf.org/mailman/listinfo/i-d-announce
>     Internet-Draft  directories: http://www.ietf.org/shadow.html
>     or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
>     _______________________________________________
>     armd mailing list
>     armd@ietf.org 
>     https://www.ietf.org/mailman/listinfo/armd
> 
> 



From internet-drafts@ietf.org  Fri Feb 10 02:03:50 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AD021F8619; Fri, 10 Feb 2012 02:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Level: 
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-0wb9FfwRkg; Fri, 10 Feb 2012 02:03:49 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88CF21F86A8; Fri, 10 Feb 2012 02:03:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20120210100349.14509.19188.idtracker@ietfa.amsl.com>
Date: Fri, 10 Feb 2012 02:03:49 -0800
Cc: softwires@ietf.org
Subject: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-01.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2012 10:03:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Softwires Working Group of the IETF.

	Title           : Motivations for Stateless IPv4 over IPv6 Migration Solut=
ions
	Author(s)       : Mohamed Boucadair
                          Satoru Matsushima
                          Yiu Lee
                          Olaf Bonness
                          Isabel Borges
                          Gang Chen
	Filename        : draft-ietf-softwire-stateless-4v6-motivation-01.txt
	Pages           : 16
	Date            : 2012-02-10

   IPv4 service continuity is one of the most pressing problems that
   must be resolved by Service Providers during the IPv6 transition
   period - especially after the exhaustion of the public IPv4 address
   space.  Current standardization effort that addresses IPv4 service
   continuity focuses on stateful mechanisms.  This document elaborates
   on the motivations for the need to undertake a companion effort to
   specify stateless IPv4 over IPv6 approaches.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-stateless-4v6-motiv=
ation-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-stateless-4v6-motiva=
tion-01.txt


From despres.remi@laposte.net  Fri Feb 10 02:11:22 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91B121F84D7 for ; Fri, 10 Feb 2012 02:11:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.965
X-Spam-Level: 
X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv88xfJEBAYC for ; Fri, 10 Feb 2012 02:11:21 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id C67E021F8535 for ; Fri, 10 Feb 2012 02:11:17 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 21A589401D5; Fri, 10 Feb 2012 11:10:41 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <96214733-7D45-436E-81C2-6E6701542C79@employees.org>
Date: Fri, 10 Feb 2012 11:10:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <972877C3-EFA3-4B65-BD98-547F643D94D1@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org>
To: =?iso-8859-1?Q?Ole_Tr=F8an?= 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG , Yong Cui , Ralph Droms 
Subject: Re: [Softwires] MAP and 4rd - Feature comparison table
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2012 10:11:22 -0000

Le 2012-02-09 =E0 18:23, Ole Tr=F8an a =E9crit :

>=20
>>=20
>> New version, after a discussion with Ole:
>>=20
>>  =
+----+--------------------------------------+-----+-----+-----+-----+
>>  |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd =
|
>>  |    |                                      |  -T |  -E |  -H |  -E =
|
>>  =
+----+--------------------------------------+-----+-----+-----+-----+
>>  |  1 | Full Transparency to IPv4 DF bit     |  N  |  Y  |  Y  |  Y  =
|
>>  |    |                                      |     |     |     |     =
|
>>  |  2 | ISP can impose a Tunnel traffic      |  N  |  Y  |  Y  |  Y  =
|
>>  |    | class                                |     |     |     |     =
|
>>  |    |                                      |     |     |     |     =
|
>>  |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  =
|
>>  |    | third-party CPEs                     |     |     |     |     =
|
>=20
> possible with MAP-{E,T} too, but may require coordination of subnet =
numbering.

Your describing what you have in mind would be useful.
So far I see the 4rd-U approach as the only specified one that is =
viable.
=20
> in all solutions will require a different provisioning model.

Not sure what you mean.
Anything missing in 4rd-U in this respect?

>>  |    |                                      |     |     |     |     =
|
>>  |  4 | IPv6 port-based ACLs work for IPv4   |  Y  |  N  |  Y  |  N  =
|
>>  |    | packets                              |     |     |     |     =
|
>=20
> suggest we rename this to "IPv6 features can be applied to the payload =
packet"?
> (we're talking about applying features in between the =
translators/tunnel endpoints here).

The point being true, I don't see a need to change it.
What you propose is less precise, and IMHO consequently less useful.

> you could also add a new feature:
> "possible to apply IPv4 features on the payload"

Don't understand what it means in practice.

> which is possible if IPv4 features are enhanced to support offset the =
tunnel encap header.
> so:
>=20
> | 4.1 | IPv6 features can be applied to the payload packet"  | Y | N | =
Y | N|
> | 4.2 | IPv4 features can be applied to the payload with     | N | Y | =
N | Y|
> |     | "tunnel vision                                 =20
>=20
>>  |    |                                      |     |     |     |     =
|
>>  |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  =
|
>>  |    | packets                              |     |     |     |     =
|
>=20
> suggest you rename to "IPv4 to IPv6 communication (single translation) =
supported"

With any interpretation I can imagine of of what you write, I see this =
as a different point.
OTOH, I acknowledge that there is a point worth analysing about the =
relationship with single translation.
More about this in my forthcoming answer to Xing.


>=20
>>  |    |                                      |     |     |     |     =
|
>>  |  6 | No constraint on host addresses or   |  N  |  N  |  Y  |  Y  =
|
>>  |    | subnet prefixes in CE sites (V-octet |     |     |     |     =
|
>>  |    | format)                              |     |     |     |     =
|
>=20
> I don't agree with this wording. actually the MAP interface-id has =
less constraints, in that it doesn't depend on the V-octet. what about =
emphasizing the problem V solves?

I added "addresses" following the technical discussion we had on =
Wednesday, understanding that it was sufficient for the statement to be =
true.
Are you negating that current MAP drafts MAY imply a change of subnet =
prefix or host address in CE sites that assigned them before adding MAP =
support?
If yes, please explain.


> "Native IPv6 hosts can co-exist with MAP node on the same subnet"

??

> or  "Reserved subnet needed for MAP function"

The table is written so that Y is always positive.


> I also think you need to add:
> | N | "New format of interface-id needs to be standardized | N | N | Y =
| Y |

True, but not an operational feature.

Clarifying that the unused combination of "u" and "g" bits can be used =
as an escape mechanism is useful for any new Interface ID formats that =
may prove useful in the future. 4rd-U is only the first instance of =
that. =20

>>  |    |                                      |     |     |     |     =
|
>>  |  7 | Number of excluded ports is flexible |  Y  |  Y  |  N  |  N  =
|
>>  |    | (GMA algorithm, 2 parameters)        |     |     |     |     =
|
>>  |    |                                      |     |     |     |     =
|
>>  |  8 | Possible migration from DS routing   |  N  |  N  |  Y  |  Y  =
|
>>  |    | to IPv6-only routing without         |     |     |     |     =
|
>>  |    | changing CE addresses and/or         |     |     |     |     =
|
>>  |    | prefixes (DMR may apply to CEs)      |     |     |     |     =
|
>=20
> all mechanisms do support this.

Well, the current MAP draft says:
- "There are three types of mapping rules"
- In a CE, "A MAP IPv6 address (or prefix) is formed from the BMR Rule =
IPv6 prefix"
I found this confusing, but I am ready to acknowledge that, by making it =
very clear that a mapping rule can have simultaneously several types, =
there can be Y in the 4 columns.

A problem will still remain in the hub&spoke case because MAP has "In =
hub and spoke mode, all traffic MUST be forwarded using the Default =
Mapping Rule." Then, if some CEs have their MAP IPv6 address (or prefix) =
derived with this rule, packets sent to them from other CEs will be =
routed directly to them, the contrary of hub&spoke.=20

I suppose that MAP can add the "toBR" bit (bit 79 in 4rd-U) to solve =
this problem. (I didn't check however, whether this would remain safe =
without the V octet).


> this is purely a deployment option in my mind, more than it separates =
the mechanisms.


> I would suggest you drop it.

Once you make clear that a Mapping rule can be both Default and Basic, I =
would rather restrict its scope to hub&spoke (see above).=20

> it requires a separate IPv6 prefix purely for the MAP function, and it =
requires importing IPv4 routing into IPv6.
>=20
>>  |    |                                      |     |     |     |     =
|
>>  |  9 | BRs need no change for any new       |  N  |  N  |  Y  |  Y  =
|
>>  |    | protocol having ports at their usual |     |     |     |     =
|
>>  |    | place and TCP-like checksum          |     |     |     |     =
|
>>  |    | (checksum neutrality)                |     |     |     |     =
|
>=20
> I don't think that is correct.

Please read the sentence once more, and say exactly which words make it =
untrue.


> an implementation would have to verify that the ports is actually in =
the place the algorithm expects. and it needs to check that the =
transport protocol uses a TCP-like checksum.
> any MAP node MUST be L4 aware.
> you could add:
>=20
> |9.1|New transport protocols can be supported regardless of L4 header =
format and checksum algorithm| Y | Y | N | N |

The point is "without change".=20
(With a change, any solution can be said to have new features.)=20
>=20
>>  |    |                                      |     |     |     |     =
|
>>  | 10 | IPv4-options supported               |  N  |  Y  |  N  |  N  =
|
>>  |    |                                      |     |     |     |     =
|
>>  | 11 | Datagram reassembly avoided in BRs   |  N  |  N  |  Y  |  Y  =
|
>=20
> right, I would expect this would be added to MAP too.

Good.

>>  |    |                                      |     |     |     |     =
|
>>  | 12 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  =
|
>>  |    | cannot be confused in destinations   |     |     |     |     =
|
>=20
> likewise for this one. so it would be Y all around.

Good.
As indicated, this table is about current drafts.

>>  |    |                                      |     |     |     |     =
|
>>  | 13 | The number of rules CEs must be able |  N  |  N  |  Y  |  Y  =
|
>>  |    | to support is defined                |     |     |     |     =
|
>=20
> do we typically state the lower limit of the size of tables (e.g. BGP =
table) in IETF specifications?

Completely different.
ISPs that have many IPv4 prefixes MUST know how many rules to specify in =
each Domain to make sure all independently acquired CEs can work in mesh =
topology.
Do you deny that this number is useful?

(BTW, sorry we didn't discuss this point on Wednesday, I had it on a =
list but skipped it.)

>=20
>>  |    |                                      |     |     |     |     =
|
>>  | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 =
|
>>  =
+----+--------------------------------------+-----+-----+-----+-----+
>=20
> I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 =
| 40 |

Fortunately you have more substantial points ;-).
(This line is just informational.)

> I also suggest you add the features:
>=20
> | 15 | Handle IPv4 UDP checksum =3D 0 | Y | Y | N | Y |

Could you be more specific about what MAP does for this, separating =
MAP-T and MAP-E?
=20

> | 16 | Running code                 | Y | N | N | N |

Running code is definitely good, but not sufficient to say that a =
feature is good to have?
OTOH, we agree that lines 12 an 13 are good to have without running =
code.


RD



>=20
> cheers,
> Ole
>=20


From mohamed.boucadair@orange.com  Fri Feb 10 02:20:40 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F3D21F8635 for ; Fri, 10 Feb 2012 02:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.159
X-Spam-Level: 
X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFbZvkywOSqQ for ; Fri, 10 Feb 2012 02:20:39 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 36A8B21F8627 for ; Fri, 10 Feb 2012 02:20:37 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 57F8422C214 for ; Fri, 10 Feb 2012 11:20:36 +0100 (CET)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3A7534C024 for ; Fri, 10 Feb 2012 11:20:36 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 10 Feb 2012 11:20:36 +0100
From: 
To: "softwires@ietf.org" 
Date: Fri, 10 Feb 2012 11:20:35 +0100
Thread-Topic: Closing draft-ietf-softwire-stateless-4v6-motivation
Thread-Index: Aczn21W/hfX703LqT+Se3UHnpEkFmwAAIHyw
Message-ID: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com>
In-Reply-To: <20120210100349.14509.19188.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.10.70319
Subject: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2012 10:20:40 -0000

Dear WG members,=20

I would like to close this document so that we can meet the following item =
from the WG Charter:

"
4. Developments for stateless legacy IPv4 carried over IPv6
- develop a solution motivation document to be published as an
RFC
- develop a protocol specification response to the solution
motivation document; this work item will not be taken through
Working Group last call until the solution motivation document
has been published or approved for publication=20
"

Except the a comment asking to include a new section to compare stateful vs=
. stateless, no further comments have been received.

I didn't considered adding the proposed new section because IMO it is out o=
f scope of this document. That section can justify in its own a dedicated d=
raft.

As for the next step, I see two options:

(1) Either issue a WG LC, or
(2) Withdraw the document and update the WG charter.

WG members, please advise.

Cheers,
Med

From despres.remi@laposte.net  Fri Feb 10 02:23:27 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D927321F858D for ; Fri, 10 Feb 2012 02:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level: 
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSe0VLpoQoGd for ; Fri, 10 Feb 2012 02:23:27 -0800 (PST)
Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id D301121F861B for ; Fri, 10 Feb 2012 02:23:26 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id YAPM1i00437Y3f403APMHW; Fri, 10 Feb 2012 11:23:25 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-2-522366737
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4F348EEB.4050908@cernet.edu.cn>
Date: Fri, 10 Feb 2012 11:23:21 +0100
Message-Id: <86ABDF99-789A-47D3-AD70-476F998E31AE@laposte.net>
References: 	<3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org>	<171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net>	<8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net>	<29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net>	<63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <4F348EEB.4050908@cernet.edu.cn>
To: Xing Li 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG , Yong Cui , Ralph Droms 
Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2012 10:23:28 -0000

--Apple-Mail-2-522366737
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Xing,
Good to have you coming in the (unfinished) technical analysis.

I answered to Ole on his remarks, which you support, but not on the =
following:

You propose to have a line on "IPv4 to IPv6 communication (single =
translation) supported", wit=20

Let me therefore reiterate the wish to see an ISP use case, with its =
Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem =
you see.

Regards,
RD
=20




Le 2012-02-10 =E0 04:28, Xing Li a =E9crit :
...                                      |     |     |     |     |
>>>   |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N =
 |
>>>   |    | packets                              |     |     |     |    =
 |
>> suggest you rename to "IPv4 to IPv6 communication (single =
translation) supported"
>>=20
>=20
> (2) More clarification should be added here. I am not sure 4rd-H can =
support single translation.
>=20
> (a) According to (1), 4rd-H does not perform header translation =
defined by RFC6145.=20
>=20
> (b) In the softwire mailing list, it seems that 4rd-H cannot support =
single translation.  See the thread containing =
http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and =
other posts.
>=20
> (c) If 4rd-H cannot support single translation, then "IPv6 web caches =
work for IPv4 packets" requires special configurations, it cannot do =
IPv6 web caches for non 4rd-H packets.

...

> (5) I would like to see the details of how 4rd-H handles ICMP and ICMP =
error messages. In the softwire mailing list there were some =
discussions. See the thread containing =
http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and =
other posts. Please add
>=20
>  | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? |
...


--Apple-Mail-2-522366737
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Xing,
Good to have you coming in the (unfinished) technical =
analysis.

I answered to Ole on his remarks, =
which you support, but not on =
the following:

You propose to have a line =
on "IPv4 to IPv6 communication (single translation) supported", =
wit 

Let me therefore reiterate the wish =
to see an ISP use case, with its Mapping rules, and with IPv6 prefixes =
of CEs that illustrate the problem you =
see.

Regards,
RD
 
=





Le 2012-02-10 =C3=A0 04:28, Xing Li a =C3=A9crit :
...                                      |     |     |     |    =
 |
  |  5 | IPv6 web =
caches work for IPv4        |  Y  |  N  |  Y  |  N  |
  |    | packets                              |     |     |     |     |


      

      
suggest you rename to "IPv4 to IPv6 communication =
(single translation) supported"



    

    

      (2) More clarification should be added here. I am not
      sure 4rd-H can support single translation.

      

      (a) According to (1), 4rd-H does not perform header translation
      defined by
      RFC6145. 

      

      (b) In the softwire mailing list, it seems that 4rd-H cannot
      support single
      translation. 
      See the thread containing
      http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html
      and other posts.

      

      (c) If 4rd-H cannot support single translation, then "IPv6 web
      caches work for IPv4 packets" requires special configurations, it
      cannot do IPv6 web
      caches for non 4rd-H =
packets.

...

=

--Apple-Mail-2-522366737--

From ichiroumakino@gmail.com  Fri Feb 10 06:25:14 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD321F8757 for ; Fri, 10 Feb 2012 06:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0H9rsytAtFN for ; Fri, 10 Feb 2012 06:25:12 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF5921F8747 for ; Fri, 10 Feb 2012 06:25:12 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so2626928wib.31 for ; Fri, 10 Feb 2012 06:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=WvAbDL5kMGikE3XRk3QhItih82rSO5+o7ApuKKewXDs=; b=nI+szDdc4+aFHsIZg736tluN6enqFi/qzT0Chd77miXxzb5efK6h2Pr0ZFqO2odzM+ 0I4JRwcD3CKEkp1hzeTCkYqi6W5ysEnxFY2q5uUJ0OVFZ7WzKu6gmIW7DEhcvb9Mti7/ W01psLH5Uu+6R0B8dsuvzWUQX9k8h+H5LlSmA=
Received: by 10.180.85.105 with SMTP id g9mr3519063wiz.12.1328883911201; Fri, 10 Feb 2012 06:25:11 -0800 (PST)
Received: from [192.168.4.69] (a50.fluent.fr. [195.68.67.50]) by mx.google.com with ESMTPS id ho4sm3594492wib.3.2012.02.10.06.25.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 06:25:09 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: <972877C3-EFA3-4B65-BD98-547F643D94D1@laposte.net>
Date: Fri, 10 Feb 2012 15:25:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <972877C3-EFA3-4B65-BD98-547F643D94D1@laposte.net>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG , Yong Cui , Ralph Droms 
Subject: Re: [Softwires] MAP and 4rd - Feature comparison table
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2012 14:25:14 -0000

Remi,

>>> New version, after a discussion with Ole:
>>>=20
>>> =
+----+--------------------------------------+-----+-----+-----+-----+
>>> |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd =
|
>>> |    |                                      |  -T |  -E |  -H |  -E =
|
>>> =
+----+--------------------------------------+-----+-----+-----+-----+
>>> |  1 | Full Transparency to IPv4 DF bit     |  N  |  Y  |  Y  |  Y  =
|
>>> |    |                                      |     |     |     |     =
|
>>> |  2 | ISP can impose a Tunnel traffic      |  N  |  Y  |  Y  |  Y  =
|
>>> |    | class                                |     |     |     |     =
|
>>> |    |                                      |     |     |     |     =
|
>>> |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  =
|
>>> |    | third-party CPEs                     |     |     |     |     =
|
>>=20
>> possible with MAP-{E,T} too, but may require coordination of subnet =
numbering.
>=20
> Your describing what you have in mind would be useful.
> So far I see the 4rd-U approach as the only specified one that is =
viable.

MAP uses the first subnet of a End-user IPv6 prefix. to deploy a MAP CE =
behind another IPv6 CE, the only thing required is to route the prefix =
(/64) used for MAP to this CE.=20

both 4rd-u and MAP assume that prefix assignment with multiple routers =
is solved, and that some other  mechanism exists for provisioning.

I don't see the point of having text in the specification for this use =
case. it is a deployment option.

>> in all solutions will require a different provisioning model.
>=20
> Not sure what you mean.
> Anything missing in 4rd-U in this respect?
>=20
>>> |    |                                      |     |     |     |     =
|
>>> |  4 | IPv6 port-based ACLs work for IPv4   |  Y  |  N  |  Y  |  N  =
|
>>> |    | packets                              |     |     |     |     =
|
>>=20
>> suggest we rename this to "IPv6 features can be applied to the =
payload packet"?
>> (we're talking about applying features in between the =
translators/tunnel endpoints here).
>=20
> The point being true, I don't see a need to change it.
> What you propose is less precise, and IMHO consequently less useful.

there are many more features than just ACLs.
you are misleading when stating that the IPv6 ACLs work on IPv4 packets. =
they don't.

>> you could also add a new feature:
>> "possible to apply IPv4 features on the payload"
>=20
> Don't understand what it means in practice.

a reason for T is to be able to apply "native IPv6 features" in the =
network. given that there is a feature gap between IPv4 and IPv6 support =
in existing gear, where IPv4 features are better supported. then an E =
solution could allow IPv4 features to be applied to tunnel packets. in =
practice:
    pak->network_start +=3D 40.
    apply IPv4 features to inner packet
    pak->network_start -=3D 40

>> which is possible if IPv4 features are enhanced to support offset the =
tunnel encap header.
>> so:
>>=20
>> | 4.1 | IPv6 features can be applied to the payload packet"  | Y | N =
| Y | N|
>> | 4.2 | IPv4 features can be applied to the payload with     | N | Y =
| N | Y|
>> |     | "tunnel vision                                 =20
>>=20
>>> |    |                                      |     |     |     |     =
|
>>> |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  =
|
>>> |    | packets                              |     |     |     |     =
|
>>=20
>> suggest you rename to "IPv4 to IPv6 communication (single =
translation) supported"
>=20
> With any interpretation I can imagine of of what you write, I see this =
as a different point.
> OTOH, I acknowledge that there is a point worth analysing about the =
relationship with single translation.
> More about this in my forthcoming answer to Xing.

can a T session terminate in a native unchanged IPv6 host? as long as =
this host has an IPv6 MAP address?
that is single translation. and implies that T packets "leak" into the =
native network. examples of use cases for this is web caching, captive =
portals, or just providing IPv4 access to IPv6 only servers.
given the wider scope, your feature name is not sufficient.

>>> |    |                                      |     |     |     |     =
|
>>> |  6 | No constraint on host addresses or   |  N  |  N  |  Y  |  Y  =
|
>>> |    | subnet prefixes in CE sites (V-octet |     |     |     |     =
|
>>> |    | format)                              |     |     |     |     =
|
>>=20
>> I don't agree with this wording. actually the MAP interface-id has =
less constraints, in that it doesn't depend on the V-octet. what about =
emphasizing the problem V solves?
>=20
> I added "addresses" following the technical discussion we had on =
Wednesday, understanding that it was sufficient for the statement to be =
true.
> Are you negating that current MAP drafts MAY imply a change of subnet =
prefix or host address in CE sites that assigned them before adding MAP =
support?
> If yes, please explain.

as I said with a mapping resulting in a 128 bit tunnel end point =
address, that can be taken out of the first /64 even if this is used by =
native hosts. the probability of collision is minimal.


>> "Native IPv6 hosts can co-exist with MAP node on the same subnet"
>=20
> ??
>=20
>> or  "Reserved subnet needed for MAP function"
>=20
> The table is written so that Y is always positive.

yes, I think that a separate /64 prefix or separate /128 address is used =
for the MAP function is a positive.

>> I also think you need to add:
>> | N | "New format of interface-id needs to be standardized | N | N | =
Y | Y |
>=20
> True, but not an operational feature.

your table has non-operational features. the usefulness of the table in =
my mind, is to identify the differences between MAP and 4rd-u and =
evaluate features that potentially can be added to MAP.
the purpose of the MAP team, was to do a first pass on that, and in the =
existing proposals we dropped many proposed features. you re-propose =
some of them in 4rd-U and all add some news ones. it is fair that those =
get a fair hearing. I don't think this table is restricted to =
"operational features"

> Clarifying that the unused combination of "u" and "g" bits can be used =
as an escape mechanism is useful for any new Interface ID formats that =
may prove useful in the future. 4rd-U is only the first instance of =
that.

if you did that, then the new mechanism would conflict with 4rd-U.

>>> |  7 | Number of excluded ports is flexible |  Y  |  Y  |  N  |  N  =
|
>>> |    | (GMA algorithm, 2 parameters)        |     |     |     |     =
|
>>> |    |                                      |     |     |     |     =
|
>>> |  8 | Possible migration from DS routing   |  N  |  N  |  Y  |  Y  =
|
>>> |    | to IPv6-only routing without         |     |     |     |     =
|
>>> |    | changing CE addresses and/or         |     |     |     |     =
|
>>> |    | prefixes (DMR may apply to CEs)      |     |     |     |     =
|
>>=20
>> all mechanisms do support this.
>=20
> Well, the current MAP draft says:
> - "There are three types of mapping rules"
> - In a CE, "A MAP IPv6 address (or prefix) is formed from the BMR Rule =
IPv6 prefix"
> I found this confusing, but I am ready to acknowledge that, by making =
it very clear that a mapping rule can have simultaneously several types, =
there can be Y in the 4 columns.
>=20
> A problem will still remain in the hub&spoke case because MAP has "In =
hub and spoke mode, all traffic MUST be forwarded using the Default =
Mapping Rule." Then, if some CEs have their MAP IPv6 address (or prefix) =
derived with this rule, packets sent to them from other CEs will be =
routed directly to them, the contrary of hub&spoke.=20
>=20
> I suppose that MAP can add the "toBR" bit (bit 79 in 4rd-U) to solve =
this problem. (I didn't check however, whether this would remain safe =
without the V octet).

no, I don't see why the bit 79 would be needed in MAP.
the CE will configure itself with an IPv4 address and port set from the =
BMR. given that it is in hub and spoke mode it will not install any =
FMRs, but only a DMR. all traffic not being for itself, will be =
forwarded using the DMR.

>> this is purely a deployment option in my mind, more than it separates =
the mechanisms.
>=20
>=20
>> I would suggest you drop it.
>=20
> Once you make clear that a Mapping rule can be both Default and Basic, =
I would rather restrict its scope to hub&spoke (see above).=20

no, two rules are used for this.

>> it requires a separate IPv6 prefix purely for the MAP function, and =
it requires importing IPv4 routing into IPv6.
>>=20
>>> |    |                                      |     |     |     |     =
|
>>> |  9 | BRs need no change for any new       |  N  |  N  |  Y  |  Y  =
|
>>> |    | protocol having ports at their usual |     |     |     |     =
|
>>> |    | place and TCP-like checksum          |     |     |     |     =
|
>>> |    | (checksum neutrality)                |     |     |     |     =
|
>>=20
>> I don't think that is correct.
>=20
> Please read the sentence once more, and say exactly which words make =
it untrue.

the "no change"

>> an implementation would have to verify that the ports is actually in =
the place the algorithm expects. and it needs to check that the =
transport protocol uses a TCP-like checksum.
>> any MAP node MUST be L4 aware.
>> you could add:
>>=20
>> |9.1|New transport protocols can be supported regardless of L4 header =
format and checksum algorithm| Y | Y | N | N |
>=20
> The point is "without change".=20
> (With a change, any solution can be said to have new features.)=20

you can't do that "without change". that would result using random bits =
for ports in L4 protocols that has a different layout. given that, you =
need to check the L4 protocol, and only accept the ones you support. CNP =
does not make supporting new L4s simpler.

>>> |    |                                      |     |     |     |     =
|
>>> | 10 | IPv4-options supported               |  N  |  Y  |  N  |  N  =
|
>>> |    |                                      |     |     |     |     =
|
>>> | 11 | Datagram reassembly avoided in BRs   |  N  |  N  |  Y  |  Y  =
|
>>=20
>> right, I would expect this would be added to MAP too.
>=20
> Good.
>=20
>>> |    |                                      |     |     |     |     =
|
>>> | 12 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  =
|
>>> |    | cannot be confused in destinations   |     |     |     |     =
|
>>=20
>> likewise for this one. so it would be Y all around.
>=20
> Good.
> As indicated, this table is about current drafts.
>=20
>>> |    |                                      |     |     |     |     =
|
>>> | 13 | The number of rules CEs must be able |  N  |  N  |  Y  |  Y  =
|
>>> |    | to support is defined                |     |     |     |     =
|
>>=20
>> do we typically state the lower limit of the size of tables (e.g. BGP =
table) in IETF specifications?
>=20
> Completely different.
> ISPs that have many IPv4 prefixes MUST know how many rules to specify =
in each Domain to make sure all independently acquired CEs can work in =
mesh topology.
> Do you deny that this number is useful?

yes. the number is a guess. we risk ending up with implementations =
_only_ supporting the smallest number. as we have little deployment =
experience that's a bad idea.

> (BTW, sorry we didn't discuss this point on Wednesday, I had it on a =
list but skipped it.)
>=20
>>=20
>>> |    |                                      |     |     |     |     =
|
>>> | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 =
|
>>> =
+----+--------------------------------------+-----+-----+-----+-----+
>>=20
>> I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 =
| 40 |
>=20
> Fortunately you have more substantial points ;-).
> (This line is just informational.)
>=20
>> I also suggest you add the features:
>>=20
>> | 15 | Handle IPv4 UDP checksum =3D 0 | Y | Y | N | Y |
>=20
> Could you be more specific about what MAP does for this, separating =
MAP-T and MAP-E?

MAP-E carries the IPv4 packet unchanged and doesn't touch the UDP =
checksum.
MAP-T rewrites the UDP checksum to a valid IPv6 packet and re-translates =
it to an IPv4 UDP packet with a checksum.
not transparent, but keeps a valid IPv6 packet inside the domain.

>> | 16 | Running code                 | Y | N | N | N |
>=20
> Running code is definitely good, but not sufficient to say that a =
feature is good to have?
> OTOH, we agree that lines 12 an 13 are good to have without running =
code.

I'm saying that the best technology, even if it was perfect doesn't =
"win". running code does.

cheers,
Ole


From despres.remi@laposte.net  Fri Feb 10 09:53:43 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA53021F85F7 for ; Fri, 10 Feb 2012 09:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level: 
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtEg2HMQCHXg for ; Fri, 10 Feb 2012 09:53:42 -0800 (PST)
Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id C88F421F85F8 for ; Fri, 10 Feb 2012 09:53:39 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id YHta1i00A37Y3f403Htbw6; Fri, 10 Feb 2012 18:53:38 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Fri, 10 Feb 2012 18:53:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <171F46DF-2C26-48A8-BE2D-D859C9DE43E9@laposte.net> <8A238676-62B7-4A8B-8986-B24A964CFD9B@juniper.net> <29D1D1C9-CC1E-4F92-81BC-81ECC3402C47@laposte.net> <63E186D0-B49E-4AB4-93C1-C6C7412519E8@laposte.net> <96214733-7D45-436E-81C2-6E6701542C79@employees.org> <972877C3-EFA3-4B65-BD98-547F643D94D1@laposte.net> 
To: =?iso-8859-1?Q?Ole_Tr=F8an?= 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG , Yong Cui , Ralph Droms 
Subject: Re: [Softwires] MAP and 4rd - Feature comparison table
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Feb 2012 17:53:43 -0000

Le 2012-02-10 =E0 15:25, Ole Tr=F8an a =E9crit :

> Remi,
>=20
>>>> New version, after a discussion with Ole:
>>>>=20
>>>> =
+----+--------------------------------------+-----+-----+-----+-----+
>>>> |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd =
|
>>>> |    |                                      |  -T |  -E |  -H |  -E =
|
>>>> =
+----+--------------------------------------+-----+-----+-----+-----+
>>>> |  1 | Full Transparency to IPv4 DF bit     |  N  |  Y  |  Y  |  Y  =
|
>>>> |    |                                      |     |     |     |     =
|
>>>> |  2 | ISP can impose a Tunnel traffic      |  N  |  Y  |  Y  |  Y  =
|
>>>> |    | class                                |     |     |     |     =
|
>>>> |    |                                      |     |     |     |     =
|
>>>> |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  =
|
>>>> |    | third-party CPEs                     |     |     |     |     =
|
>>>=20
>>> possible with MAP-{E,T} too, but may require coordination of subnet =
numbering.
>>=20
>> Your describing what you have in mind would be useful.
>> So far I see the 4rd-U approach as the only specified one that is =
viable.
>=20
> MAP uses the first subnet of a End-user IPv6 prefix. to deploy a MAP =
CE behind another IPv6 CE, the only thing required is to route the =
prefix (/64) used for MAP to this CE.=20
>=20
> both 4rd-u and MAP assume that prefix assignment with multiple routers =
is solved, and that some other  mechanism exists for provisioning.
>=20
> I don't see the point of having text in the specification for this use =
case. it is a deployment option.

I plan to have sometime a separate thread on this one, not technically =
trivial AFAIK.


>=20
>>> in all solutions will require a different provisioning model.
>>=20
>> Not sure what you mean.
>> Anything missing in 4rd-U in this respect?
>>=20
>>>> |    |                                      |     |     |     |     =
|
>>>> |  4 | IPv6 port-based ACLs work for IPv4   |  Y  |  N  |  Y  |  N  =
|
>>>> |    | packets                              |     |     |     |     =
|
>>>=20
>>> suggest we rename this to "IPv6 features can be applied to the =
payload packet"?
>>> (we're talking about applying features in between the =
translators/tunnel endpoints here).
>>=20
>> The point being true, I don't see a need to change it.
>> What you propose is less precise, and IMHO consequently less useful.
>=20
> there are many more features than just ACLs.

The point being only both true and operationally differentiating, its =
presence here is AFAIK justified.

> you are misleading when stating that the IPv6 ACLs work on IPv4 =
packets. they don't.

I wrote "port-based ACLs", never claimed it for all "IPv6 ACLs".

>=20
>>> you could also add a new feature:
>>> "possible to apply IPv4 features on the payload"
>>=20
>> Don't understand what it means in practice.
>=20
> a reason for T is to be able to apply "native IPv6 features" in the =
network. given that there is a feature gap between IPv4 and IPv6 support =
in existing gear, where IPv4 features are better supported. then an E =
solution could allow IPv4 features to be applied to tunnel packets. in =
practice:
>    pak->network_start +=3D 40.
>    apply IPv4 features to inner packet
>    pak->network_start -=3D 40

You may find that the point is minor, but it remains: some deployed =
products aren't ready yet to do what you suggest yet, and no announced =
availability date and/or price.=20
The point was made at the Beijing meeting, and has not been denied since =
then, AFAIK.


>>> which is possible if IPv4 features are enhanced to support offset =
the tunnel encap header.
>>> so:
>>>=20
>>> | 4.1 | IPv6 features can be applied to the payload packet"  | Y | N =
| Y | N|
>>> | 4.2 | IPv4 features can be applied to the payload with     | N | Y =
| N | Y|
>>> |     | "tunnel vision                                 =20
>>>=20
>>>> |    |                                      |     |     |     |     =
|
>>>> |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  =
|
>>>> |    | packets                              |     |     |     |     =
|
>>>=20


>>> suggest you rename to "IPv4 to IPv6 communication (single =
translation) supported"
>>=20
>> With any interpretation I can imagine of of what you write, I see =
this as a different point.
>> OTOH, I acknowledge that there is a point worth analysing about the =
relationship with single translation.
>> More about this in my forthcoming answer to Xing.
>=20
> can a T session terminate in a native unchanged IPv6 host? as long as =
this host has an IPv6 MAP address?
> that is single translation. and implies that T packets "leak" into the =
native network. examples of use cases for this is web caching, captive =
portals, or just providing IPv4 access to IPv6 only servers.
> given the wider scope, your feature name is not sufficient.

As answered to Xing Li, this point of relationship with single =
translation deserves IMHO its own thread (not technically trivial AFAIK.


>>>> |    |                                      |     |     |     |     =
|
>>>> |  6 | No constraint on host addresses or   |  N  |  N  |  Y  |  Y  =
|
>>>> |    | subnet prefixes in CE sites (V-octet |     |     |     |     =
|
>>>> |    | format)                              |     |     |     |     =
|
>>>=20
>>> I don't agree with this wording. actually the MAP interface-id has =
less constraints, in that it doesn't depend on the V-octet. what about =
emphasizing the problem V solves?
>>=20
>> I added "addresses" following the technical discussion we had on =
Wednesday, understanding that it was sufficient for the statement to be =
true.
>> Are you negating that current MAP drafts MAY imply a change of subnet =
prefix or host address in CE sites that assigned them before adding MAP =
support?
>> If yes, please explain.
>=20
> as I said with a mapping resulting in a 128 bit tunnel end point =
address,

Not clear what you mean (I find your draft quite unclear as to how =
Interface IDs of CE destinations are built) =20

> that can be taken out of the first /64 even if this is used by native =
hosts. the probability of collision is minimal.

In any case, a design without collisions is better than one with low =
probability collisions.



>>> "Native IPv6 hosts can co-exist with MAP node on the same subnet"
>>=20
>> ??
>>=20
>>> or  "Reserved subnet needed for MAP function"
>>=20
>> The table is written so that Y is always positive.
>=20
> yes, I think that a separate /64 prefix or separate /128 address is =
used for the MAP function is a positive.

I see no operational gain compared to what is achieved with the V octet.



>>> I also think you need to add:
>>> | N | "New format of interface-id needs to be standardized | N | N | =
Y | Y |
>>=20
>> True, but not an operational feature.
>=20
> your table has non-operational features.

Which ones?
Maybe header length, which has I would say negligible impact on =
bandwidth to be offered to customers, but it is only informational, =
without Y (positive) or N (negative).


> the usefulness of the table in my mind, is to identify the differences =
between MAP and 4rd-u and evaluate features that potentially can be =
added to MAP.

That's of course a restricted view on the purpose of this table.=20
I made it to help the chairs, and WG participants in general, to analyze =
operational differences between solutions.


> the purpose of the MAP team, was to do a first pass on that, and in =
the existing proposals we dropped many proposed features. you re-propose =
some of them in 4rd-U and all add some news ones. it is fair that those =
get a fair hearing. I don't think this table is restricted to =
"operational features"
>=20
>> Clarifying that the unused combination of "u" and "g" bits can be =
used as an escape mechanism is useful for any new Interface ID formats =
that may prove useful in the future. 4rd-U is only the first instance of =
that.
>=20
> if you did that, then the new mechanism would conflict with 4rd-U.

4rd-U only uses 0x03 as first Interface-ID octet.
All other values of this octet that have binary 11 in their lower bits =
can be used for other purposes.=20
=20

>>>> |  7 | Number of excluded ports is flexible |  Y  |  Y  |  N  |  N  =
|
>>>> |    | (GMA algorithm, 2 parameters)        |     |     |     |     =
|
>>>> |    |                                      |     |     |     |     =
|
>>>> |  8 | Possible migration from DS routing   |  N  |  N  |  Y  |  Y  =
|
>>>> |    | to IPv6-only routing without         |     |     |     |     =
|
>>>> |    | changing CE addresses and/or         |     |     |     |     =
|
>>>> |    | prefixes (DMR may apply to CEs)      |     |     |     |     =
|
>>>=20
>>> all mechanisms do support this.
>>=20
>> Well, the current MAP draft says:
>> - "There are three types of mapping rules"
>> - In a CE, "A MAP IPv6 address (or prefix) is formed from the BMR =
Rule IPv6 prefix"
>> I found this confusing, but I am ready to acknowledge that, by making =
it very clear that a mapping rule can have simultaneously several types, =
there can be Y in the 4 columns.
>>=20
>> A problem will still remain in the hub&spoke case because MAP has "In =
hub and spoke mode, all traffic MUST be forwarded using the Default =
Mapping Rule." Then, if some CEs have their MAP IPv6 address (or prefix) =
derived with this rule, packets sent to them from other CEs will be =
routed directly to them, the contrary of hub&spoke.=20
>>=20
>> I suppose that MAP can add the "toBR" bit (bit 79 in 4rd-U) to solve =
this problem. (I didn't check however, whether this would remain safe =
without the V octet).
>=20
> no, I don't see why the bit 79 would be needed in MAP.

The explanation is AFAIK in the second paragraph above ("A problem will =
... hub&spoke")
Whether it is bit 79 or another is secondary.


> the CE will configure itself with an IPv4 address and port set from =
the BMR. given that it is in hub and spoke mode it will not install any =
FMRs, but only a DMR. all traffic not being for itself, will be =
forwarded using the DMR.
>=20
>>> this is purely a deployment option in my mind, more than it =
separates the mechanisms.
>>=20
>>=20
>>> I would suggest you drop it.
>>=20
>> Once you make clear that a Mapping rule can be both Default and =
Basic, I would rather restrict its scope to hub&spoke (see above).=20
>=20
> no, two rules are used for this.

The DHCPv6 option doesn't distinguish rule types.
So, if both the BMR and the FMR have a null length IOPv4 prefix, I don't =
see how the longest match works.


>>> it requires a separate IPv6 prefix purely for the MAP function, and =
it requires importing IPv4 routing into IPv6.
>>>=20
>>>> |    |                                      |     |     |     |     =
|
>>>> |  9 | BRs need no change for any new       |  N  |  N  |  Y  |  Y  =
|
>>>> |    | protocol having ports at their usual |     |     |     |     =
|
>>>> |    | place and TCP-like checksum          |     |     |     |     =
|
>>>> |    | (checksum neutrality)                |     |     |     |     =
|
>>>=20
>>> I don't think that is correct.
>>=20
>> Please read the sentence once more, and say exactly which words make =
it untrue.
>=20
> the "no change"

??


>>> an implementation would have to verify that the ports is actually in =
the place the algorithm expects. and it needs to check that the =
transport protocol uses a TCP-like checksum.
>>> any MAP node MUST be L4 aware.
>>> you could add:
>>>=20
>>> |9.1|New transport protocols can be supported regardless of L4 =
header format and checksum algorithm| Y | Y | N | N |
>>=20
>> The point is "without change".=20
>> (With a change, any solution can be said to have new features.)=20
>=20
> you can't do that "without change". that would result using random =
bits for ports in L4 protocols that has a different layout. given that, =
you need to check the L4 protocol, and only accept the ones you support. =
CNP does not make supporting new L4s simpler.

If, by mistake of a source, a datagram from the Internet having a =
port-less L4 is addressed to a shared IPv4 address with a port-less =
transport layer, it will reach a NAT44 that will discard it. Not a =
problem AFAIK.
=20

>>>> |    |                                      |     |     |     |     =
|
>>>> | 10 | IPv4-options supported               |  N  |  Y  |  N  |  N  =
|
>>>> |    |                                      |     |     |     |     =
|
>>>> | 11 | Datagram reassembly avoided in BRs   |  N  |  N  |  Y  |  Y  =
|
>>>=20
>>> right, I would expect this would be added to MAP too.
>>=20
>> Good.
>>=20
>>>> |    |                                      |     |     |     |     =
|
>>>> | 12 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  =
|
>>>> |    | cannot be confused in destinations   |     |     |     |     =
|
>>>=20
>>> likewise for this one. so it would be Y all around.
>>=20
>> Good.
>> As indicated, this table is about current drafts.
>>=20
>>>> |    |                                      |     |     |     |     =
|
>>>> | 13 | The number of rules CEs must be able |  N  |  N  |  Y  |  Y  =
|
>>>> |    | to support is defined                |     |     |     |     =
|
>>>=20
>>> do we typically state the lower limit of the size of tables (e.g. =
BGP table) in IETF specifications?
>>=20
>> Completely different.
>> ISPs that have many IPv4 prefixes MUST know how many rules to specify =
in each Domain to make sure all independently acquired CEs can work in =
mesh topology.
>> Do you deny that this number is useful?
>=20
> yes. the number is a guess. we risk ending up with implementations =
_only_ supporting the smallest number. as we have little deployment =
experience that's a bad idea.

If CEs are implemented with only 32 rules, I don't see the practical =
problem.
But, as said in the draft, the WG could easily agree on a larger number, =
512 if you wish.
The point is that ISPs MUST know which number does guarantee mesh =
operation.

=20
>> (BTW, sorry we didn't discuss this point on Wednesday, I had it on a =
list but skipped it.)
>>=20
>>>=20
>>>> |    |                                      |     |     |     |     =
|
>>>> | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 =
|
>>>> =
+----+--------------------------------------+-----+-----+-----+-----+
>>>=20
>>> I suggest you change this to "Minimum packet overhead" | 20 | 40 | =
28 | 40 |
>>=20
>> Fortunately you have more substantial points ;-).
>> (This line is just informational.)
>>=20
>>> I also suggest you add the features:
>>>=20
>>> | 15 | Handle IPv4 UDP checksum =3D 0 | Y | Y | N | Y |
>>=20
>> Could you be more specific about what MAP does for this, separating =
MAP-T and MAP-E?
>=20
> MAP-E carries the IPv4 packet unchanged and doesn't touch the UDP =
checksum.
> MAP-T rewrites the UDP checksum to a valid IPv6 packet and =
re-translates it to an IPv4 UDP packet with a checksum.
> not transparent, but keeps a valid IPv6 packet inside the domain.

Yes, this is a lack of transparency that is avoided in MAP-E and in both =
4rd-H and 4rd-E.
A line could be added.

Note also that RFC6145 has:
"Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., =
the UDP checksum field is zero) are not of significant use in the =
Internet, and in general will not be translated by the IP/ICMP =
translator.  However, when the translator is configured to forward the =
packet without a UDP checksum, the fragmented IPv4 UDP packets will be =
translated."

In other words, with double translation, one isn't sure what happens to =
null-checksum IPv4 packets when=20

RD



>=20
>>> | 16 | Running code                 | Y | N | N | N |
>>=20
>> Running code is definitely good, but not sufficient to say that a =
feature is good to have?
>> OTOH, we agree that lines 12 an 13 are good to have without running =
code.
>=20
> I'm saying that the best technology, even if it was perfect doesn't =
"win". running code does.
>=20
> cheers,
> Ole
>=20


From Francis.Dupont@fdupont.fr  Sat Feb 11 00:30:15 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7318321F85D3 for ; Sat, 11 Feb 2012 00:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0a7wXDP5wwF for ; Sat, 11 Feb 2012 00:30:15 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 87EE021F85C0 for ; Sat, 11 Feb 2012 00:30:14 -0800 (PST)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q1B8UDvM008903; Sat, 11 Feb 2012 09:30:13 +0100 (CET) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201202110830.q1B8UDvM008903@givry.fdupont.fr>
From: Francis Dupont 
To: mohamed.boucadair@orange.com
In-reply-to: Your message of Fri, 10 Feb 2012 11:20:35 +0100. <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>
Date: Sat, 11 Feb 2012 09:30:13 +0100
Sender: Francis.Dupont@fdupont.fr
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2012 08:30:15 -0000

 In your previous mail you wrote:

>  (1) Either issue a WG LC, or

+1

Francis.Dupont@fdupont.fr

From rajiva@cisco.com  Sat Feb 11 03:43:14 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD0321F84A2 for ; Sat, 11 Feb 2012 03:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.204
X-Spam-Level: 
X-Spam-Status: No, score=-7.204 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x8jyGKW3mZ9 for ; Sat, 11 Feb 2012 03:43:13 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2121F84A0 for ; Sat, 11 Feb 2012 03:43:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=411; q=dns/txt; s=iport; t=1328960593; x=1330170193; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=VnHP/XzGCox+VZcLmMQpCSALOELXrTefo4QNCAoiGH8=; b=SHOIdPtpoC2X+8t2Vby7BDKKp9lfhenzuhu6n31zlYX3uEepWSeIFVcA RRqdAo/ir8z34/CLwq1dZ+v/127kmASPEH5Yu3XjgGZfV4Z28y5wyHj5F A6xv16WgNVicG6XOEEe+oz4oAOGmYdy5oUMG/gJJir/OYZAhG2BPjCtwu 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As4KAG5TNk+tJXG//2dsb2JhbABEr28CgQeBcgEBAQMBAQEBDwEnNAsQAgEIEAguJzABAQQTIodaCZwuAZYnBIwJNx8LAQIBgxcFBoEWgmBjBIhKjGiTAg
X-IronPort-AV: E=Sophos;i="4.73,401,1325462400"; d="scan'208";a="58146487"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 11 Feb 2012 11:43:13 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1BBhC6M010229;  Sat, 11 Feb 2012 11:43:12 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 11 Feb 2012 05:43:12 -0600
Received: from 72.163.43.37 ([72.163.43.37]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ;  Sat, 11 Feb 2012 11:43:12 +0000
References: <201202110830.q1B8UDvM008903@givry.fdupont.fr>
Content-Transfer-Encoding: quoted-printable
From: "Rajiv Asati (rajiva)" 
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <201202110830.q1B8UDvM008903@givry.fdupont.fr>
thread-topic: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
thread-index: AczoslU7EluFqIFjTP67hYvoQwDcMA==
Message-ID: <0080FD0A-97FF-4C30-BD49-05AAB5E60BDA@cisco.com>
Date: Sat, 11 Feb 2012 06:43:10 -0500
To: "Francis Dupont" 
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 11 Feb 2012 11:43:12.0753 (UTC) FILETIME=[55C26E10:01CCE8B2]
Cc: softwires@ietf.org
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2012 11:43:14 -0000

+1

Cheers,
Rajiv

Sent from my Phone

On Feb 11, 2012, at 3:30 AM, "Francis Dupont"  wr=
ote:

>=20
> In your previous mail you wrote:
>=20
>> (1) Either issue a WG LC, or
>=20
> +1
>=20
> Francis.Dupont@fdupont.fr
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From despres.remi@laposte.net  Sat Feb 11 05:53:04 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1AF21F8543 for ; Sat, 11 Feb 2012 05:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.309,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP66RwVezAuM for ; Sat, 11 Feb 2012 05:53:04 -0800 (PST)
Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id C02D721F853C for ; Sat, 11 Feb 2012 05:53:02 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id Ydsy1i00337Y3f403dt0C7; Sat, 11 Feb 2012 14:53:01 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <0080FD0A-97FF-4C30-BD49-05AAB5E60BDA@cisco.com>
Date: Sat, 11 Feb 2012 14:52:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <922196F8-A6BE-492E-979F-6F95955C62F9@laposte.net>
References: <201202110830.q1B8UDvM008903@givry.fdupont.fr> <0080FD0A-97FF-4C30-BD49-05AAB5E60BDA@cisco.com>
To: Rajiv Asati (rajiva) 
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2012 13:53:04 -0000

Le 2012-02-11 =E0 12:43, Rajiv Asati (rajiva) a =E9crit :

> +1

+1
RD

>=20
> Cheers,
> Rajiv
>=20
> Sent from my Phone
>=20
> On Feb 11, 2012, at 3:30 AM, "Francis Dupont" =
 wrote:
>=20
>>=20
>> In your previous mail you wrote:
>>=20
>>> (1) Either issue a WG LC, or
>>=20
>> +1
>>=20
>> Francis.Dupont@fdupont.fr
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From cb.list6@gmail.com  Sat Feb 11 06:31:00 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09DB21F8551 for ; Sat, 11 Feb 2012 06:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level: 
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.156,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fALVvSOtFk0u for ; Sat, 11 Feb 2012 06:30:59 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7C21F8549 for ; Sat, 11 Feb 2012 06:30:59 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so3397243pbc.31 for ; Sat, 11 Feb 2012 06:30:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bI5BVjLeEMUlMC8PJnoqAtYet32bwvJgyScHlz8DE18=; b=kUSQapjzrV5tXGwyaQBuWZfgOxIRE7xFpmxB0XdbBiVgo211n5u2S/x+bqB5qeGMJ9 ZQUy7tn2t2js7psyrC9M2hkZiOfNscKriiGUzTcnLQXWpyJ7W/119NEkM86aMnYbZMV8 5MsIhz2QamkcuCjp6lmeb5tiKQNK4UeESLKLA=
MIME-Version: 1.0
Received: by 10.68.210.12 with SMTP id mq12mr27005398pbc.2.1328970659164; Sat, 11 Feb 2012 06:30:59 -0800 (PST)
Received: by 10.143.164.16 with HTTP; Sat, 11 Feb 2012 06:30:58 -0800 (PST)
Received: by 10.143.164.16 with HTTP; Sat, 11 Feb 2012 06:30:58 -0800 (PST)
In-Reply-To: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>
Date: Sat, 11 Feb 2012 06:30:58 -0800
Message-ID: 
From: Cameron Byrne 
To: mohamed.boucadair@orange.com
Content-Type: multipart/alternative; boundary=047d7b15b2630e726804b8b1182c
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2012 14:31:00 -0000

--047d7b15b2630e726804b8b1182c
Content-Type: text/plain; charset=ISO-8859-1

On Feb 10, 2012 2:20 AM,  wrote:
>
> Dear WG members,
>
> I would like to close this document so that we can meet the following
item from the WG Charter:
>
> "
> 4. Developments for stateless legacy IPv4 carried over IPv6
> - develop a solution motivation document to be published as an
> RFC
> - develop a protocol specification response to the solution
> motivation document; this work item will not be taken through
> Working Group last call until the solution motivation document
> has been published or approved for publication
> "
>
> Except the a comment asking to include a new section to compare stateful
vs. stateless, no further comments have been received.
>
> I didn't considered adding the proposed new section because IMO it is out
of scope of this document. That section can justify in its own a dedicated
draft.
>

I find this omission disappointing. There is a common assumption that
stateless is superior to stateful, but it is not quantified anywhere.

It seems all this stateless work hinges on this assumption without any
quantification.

Honestly, the omission makes me believe the case of stateless being
superior is dubious.

Cb

> As for the next step, I see two options:
>
> (1) Either issue a WG LC, or
> (2) Withdraw the document and update the WG charter.
>
> WG members, please advise.
>
> Cheers,
> Med
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--047d7b15b2630e726804b8b1182c
Content-Type: text/html; charset=ISO-8859-1




On Feb 10, 2012 2:20 AM, <mohamed.boucadair@orange.com> wrote:

>

> Dear WG members,

>

> I would like to close this document so that we can meet the following item from the WG Charter:

>

> "

> 4. Developments for stateless legacy IPv4 carried over IPv6

> - develop a solution motivation document to be published as an

> RFC

> - develop a protocol specification response to the solution

> motivation document; this work item will not be taken through

> Working Group last call until the solution motivation document

> has been published or approved for publication

> "

>

> Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received.

>

> I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft.

>


I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere.


It seems all this stateless work hinges on this assumption without any quantification. 


Honestly, the omission makes me believe the case of stateless being superior is dubious. 


Cb


> As for the next step, I see two options:

>

> (1) Either issue a WG LC, or

> (2) Withdraw the document and update the WG charter.

>

> WG members, please advise.

>

> Cheers,

> Med

> _______________________________________________

> Softwires mailing list

> Softwires@ietf.org

> https://www.ietf.org/mailman/listinfo/softwires




--047d7b15b2630e726804b8b1182c--

From despres.remi@laposte.net  Sat Feb 11 08:36:27 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691C621F8523 for ; Sat, 11 Feb 2012 08:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.299,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8JNekHTv0MM for ; Sat, 11 Feb 2012 08:36:26 -0800 (PST)
Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21321F84B6 for ; Sat, 11 Feb 2012 08:36:25 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id YgcN1i00937Y3f403gcNNT; Sat, 11 Feb 2012 17:36:23 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-4-631147932
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Sat, 11 Feb 2012 17:36:22 +0100
Message-Id: 
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> 
To: Cameron Byrne 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Feb 2012 16:36:27 -0000

--Apple-Mail-4-631147932
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 2012-02-11 =E0 15:30, Cameron Byrne a =E9crit :

>=20
> On Feb 10, 2012 2:20 AM,  wrote:
> >
> > Dear WG members,
> >
> > I would like to close this document so that we can meet the =
following item from the WG Charter:
> >
> > "
> > 4. Developments for stateless legacy IPv4 carried over IPv6
> > - develop a solution motivation document to be published as an
> > RFC
> > - develop a protocol specification response to the solution
> > motivation document; this work item will not be taken through
> > Working Group last call until the solution motivation document
> > has been published or approved for publication
> > "
> >
> > Except the a comment asking to include a new section to compare =
stateful vs. stateless, no further comments have been received.
> >
> > I didn't considered adding the proposed new section because IMO it =
is out of scope of this document. That section can justify in its own a =
dedicated draft.
> >
>=20
> I find this omission disappointing. There is a common assumption that =
stateless is superior to stateful, but it is not quantified anywhere.
>=20
> It seems all this stateless work hinges on this assumption without any =
quantification.
>=20
> Honestly, the omission makes me believe the case of stateless being =
superior is dubious.
>=20

Both stateful AND stateless have their use cases.
This motivation draft shouldn't be taken as advocating that Stateful =
should be abandoned!=20
(Both NAT64 and DS-lite are here to stay. There also have their use =
cases where they are superior).

Delaying this document would only be IMHO a waste of energy.=20

Regards,
RD

> Cb
>=20
> > As for the next step, I see two options:
> >
> > (1) Either issue a WG LC, or
> > (2) Withdraw the document and update the WG charter.
> >
> > WG members, please advise.
> >
> > Cheers,
> > Med
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


--Apple-Mail-4-631147932
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1




On Feb 10, 2012 2:20 AM, <mohamed.boucadair@orange.com<=
/a>> wrote:

>

> Dear WG members,

>

> I would like to close this document so that we can meet the =
following item from the WG Charter:

>

> "

> 4. Developments for stateless legacy IPv4 carried over IPv6

> - develop a solution motivation document to be published as an

> RFC

> - develop a protocol specification response to the solution

> motivation document; this work item will not be taken through

> Working Group last call until the solution motivation document

> has been published or approved for publication

> "

>

> Except the a comment asking to include a new section to compare =
stateful vs. stateless, no further comments have been received.

>

> I didn't considered adding the proposed new section because IMO it =
is out of scope of this document. That section can justify in its own a =
dedicated draft.

>
I find this omission disappointing. There is a common =
assumption that stateless is superior to stateful, but it is not =
quantified anywhere.
It seems all this stateless work hinges on =
this assumption without any quantification. 
Honestly, the =
omission makes me believe the case of stateless being superior is =
dubious. 

Both stateful AND stateless =
have their use cases.
This motivation draft shouldn't be taken =
as advocating that Stateful should be abandoned! 
(Both =
NAT64 and DS-lite are here to stay. There also have their use cases =
where they are superior).

Delaying this =
document would only be IMHO a waste of =
energy. 

Regards,
RD

=

--Apple-Mail-4-631147932--

From satoru.matsushima@gmail.com  Sun Feb 12 19:14:37 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B33021F8742 for ; Sun, 12 Feb 2012 19:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlDU3S4ZJnvI for ; Sun, 12 Feb 2012 19:14:36 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3F21F85EF for ; Sun, 12 Feb 2012 19:14:35 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so4381614pbc.31 for ; Sun, 12 Feb 2012 19:14:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=P3CAHbCq//8bANIb4vI6csPI/uhEyJTlUvZvl1XC9oY=; b=Td8QA+5X1NmNZr3lXIsur9LJDyy8UJH76A8CRF51hNAX1ZE29ImhFOnO8+f6Kpsb9g rAR0c2msgXSRPZ5Lf0vsvRZXHkbSyCETgslexo4OvS/KGvo8naETiDKH20U/V+WAw/TD +C/lshU7ma933KGE5PvINv+nbBFwIQSe6v2qw=
Received: by 10.68.222.103 with SMTP id ql7mr42946684pbc.53.1329102875872; Sun, 12 Feb 2012 19:14:35 -0800 (PST)
Received: from [10.201.81.209] ([202.45.12.141]) by mx.google.com with ESMTPS id 4sm319130pbo.4.2012.02.12.19.14.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 19:14:33 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Satoru Matsushima 
In-Reply-To: 
Date: Mon, 13 Feb 2012 04:14:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EB9B69C-726A-4080-B021-30EE734518CD@gmail.com>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> 
To: Cameron Byrne 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2012 03:14:37 -0000

On 2012/02/11, at 15:30, Cameron Byrne wrote:

--snip--
>=20
> I find this omission disappointing. There is a common assumption that =
stateless is superior to stateful, but it is not quantified anywhere.
>=20
> It seems all this stateless work hinges on this assumption without any =
quantification.
>=20
> Honestly, the omission makes me believe the case of stateless being =
superior is dubious.
>=20
> Cb

Do you think that it is productive productive analysis that comparison =
of stateless between stateful? Current motivation draft stands not to =
beat other solutions, it stands for justifying to start stateless =
solution work on the WG so some proponents of stateless solution took a =
pen. My question is that if the comparison is productive for something, =
who should work for it, and who should read it.

cheers,
--satoru=

From maxpassion@gmail.com  Sun Feb 12 19:45:41 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBA421F8700 for ; Sun, 12 Feb 2012 19:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKSFQu4Srh27 for ; Sun, 12 Feb 2012 19:45:40 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCCCF21F8688 for ; Sun, 12 Feb 2012 19:45:40 -0800 (PST)
Received: by iagf6 with SMTP id f6so4236785iag.31 for ; Sun, 12 Feb 2012 19:45:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tgKI8PT+9rzOToxA6YMqcQL8iwIEKS3BO/hLmUus8eU=; b=DV44ywoBj9wGoLVbLMPG+1wXRVsv18WFbpqHw+uJdXYeB4YTN8V1vfUfIW9IbITSOP ldLemoduo3jEKuFIZCHlwWjUDMyEesR/nWBMc/HrYKJWCdh39HKR6qbzxq0Z9AKLzanl exRokMvRXCt9QKPC+Xsxm5bGuKMUvjJf0gmoQ=
MIME-Version: 1.0
Received: by 10.50.178.73 with SMTP id cw9mr24390444igc.23.1329104740498; Sun, 12 Feb 2012 19:45:40 -0800 (PST)
Received: by 10.42.29.70 with HTTP; Sun, 12 Feb 2012 19:45:40 -0800 (PST)
In-Reply-To: 
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> 
Date: Mon, 13 Feb 2012 11:45:40 +0800
Message-ID: 
From: liu dapeng 
To: Cameron Byrne 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2012 03:45:41 -0000

2012/2/11, Cameron Byrne :
> On Feb 10, 2012 2:20 AM,  wrote:
>>
>> Dear WG members,
>>
>> I would like to close this document so that we can meet the following
> item from the WG Charter:
>>
>> "
>> 4. Developments for stateless legacy IPv4 carried over IPv6
>> - develop a solution motivation document to be published as an
>> RFC
>> - develop a protocol specification response to the solution
>> motivation document; this work item will not be taken through
>> Working Group last call until the solution motivation document
>> has been published or approved for publication
>> "
>>
>> Except the a comment asking to include a new section to compare stateful
> vs. stateless, no further comments have been received.
>>
>> I didn't considered adding the proposed new section because IMO it is out
> of scope of this document. That section can justify in its own a dedicated
> draft.
>>
>
> I find this omission disappointing. There is a common assumption that
> stateless is superior to stateful, but it is not quantified anywhere.
>
> It seems all this stateless work hinges on this assumption without any
> quantification.
>
> Honestly, the omission makes me believe the case of stateless being
> superior is dubious.

Agree. Stateless and stateful may both have their own use cases.Saying
that stateless is superior than stateful may not be appropriate
considering that there is no comprehensive and quantitative
comparation between them.

BR,
Dapeng


> Cb
>
>> As for the next step, I see two options:
>>
>> (1) Either issue a WG LC, or
>> (2) Withdraw the document and update the WG charter.
>>
>> WG members, please advise.
>>
>> Cheers,
>> Med
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>


-- 

------
Best Regards,
Dapeng Liu

From cb.list6@gmail.com  Sun Feb 12 20:02:37 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8150C21F867C for ; Sun, 12 Feb 2012 20:02:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Toru-UdB6HwZ for ; Sun, 12 Feb 2012 20:02:36 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF28A21F8595 for ; Sun, 12 Feb 2012 20:02:36 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so4406979pbc.31 for ; Sun, 12 Feb 2012 20:02:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kvc/aGAVS/BafNN7kCwFedVHtoHUqjYq+Mr4qGLYceE=; b=RzWof47p6xx0kZ1slh7c/2ic2g4ywbkGYfhBSKqY01zi7colrzBzSvqcJ3AA/3SH0s fuLVd0h1SQ1ocPpeOoX3p3T/h7eFzecGu7rSzUHiCSpfrHraqwwoBXEv6vI8bmjBeKtM F/0/lP3q1YZcTwettYjMgMbOgbKq/xUMIunXc=
MIME-Version: 1.0
Received: by 10.68.225.73 with SMTP id ri9mr42858168pbc.70.1329105756550; Sun, 12 Feb 2012 20:02:36 -0800 (PST)
Received: by 10.143.164.16 with HTTP; Sun, 12 Feb 2012 20:02:36 -0800 (PST)
Received: by 10.143.164.16 with HTTP; Sun, 12 Feb 2012 20:02:36 -0800 (PST)
In-Reply-To: <8EB9B69C-726A-4080-B021-30EE734518CD@gmail.com>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>  <8EB9B69C-726A-4080-B021-30EE734518CD@gmail.com>
Date: Sun, 12 Feb 2012 20:02:36 -0800
Message-ID: 
From: Cameron Byrne 
To: Satoru Matsushima 
Content-Type: multipart/alternative; boundary=e89a8ff2437d7cf83004b8d08c88
Cc: Softwires WG 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2012 04:02:37 -0000

--e89a8ff2437d7cf83004b8d08c88
Content-Type: text/plain; charset=ISO-8859-1

On Feb 12, 2012 7:14 PM, "Satoru Matsushima" 
wrote:
>
> On 2012/02/11, at 15:30, Cameron Byrne wrote:
>
> --snip--
> >
> > I find this omission disappointing. There is a common assumption that
stateless is superior to stateful, but it is not quantified anywhere.
> >
> > It seems all this stateless work hinges on this assumption without any
quantification.
> >
> > Honestly, the omission makes me believe the case of stateless being
superior is dubious.
> >
> > Cb
>
> Do you think that it is productive productive analysis that comparison of
stateless between stateful? Current motivation draft stands not to beat
other solutions, it stands for justifying to start stateless solution work
on the WG so some proponents of stateless solution took a pen. My question
is that if the comparison is productive for something, who should work for
it, and who should read it.
>

I assumed this explanation and comparison would be easy for the stateless
experts.  I looked to this as a learning opportunity for me.

I agree with you and RD, there are many good solutions that fit this
problem space and I do not intend to slow progress.

If it is difficult  and the differences in merit cannot be easily
quantified between stateful and stateless , I accept that as an answer.

I suggested they be compared since opposites frequently help define each
other. Black helps define white just as cold helps define hot.  I had
assumed this was true for this case as well. Perhaps I was wrong.

Thanks again for your contribution.

Cb

> cheers,
> --satoru

--e89a8ff2437d7cf83004b8d08c88
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Feb 12, 2012 7:14 PM, "Satoru Matsushima" <satoru.matsushima@gmail.com> wrote:
>

> On 2012/02/11, at 15:30, Cameron Byrne wrote:

>

> --snip--

> >

> > I find this omission disappointing. There is a common assumption =
that stateless is superior to stateful, but it is not quantified anywhere.<=
br>
> >

> > It seems all this stateless work hinges on this assumption withou=
t any quantification.

> >

> > Honestly, the omission makes me believe the case of stateless bei=
ng superior is dubious.

> >

> > Cb

>

> Do you think that it is productive productive analysis that comparison=
 of stateless between stateful? Current motivation draft stands not to beat=
 other solutions, it stands for justifying to start stateless solution work=
 on the WG so some proponents of stateless solution took a pen. My question=
 is that if the comparison is productive for something, who should work for=
 it, and who should read it.


>


I assumed this explanation and comparison would be easy for the stateles=
s experts.=A0 I looked to this as a learning opportunity for me. 


I agree with you and RD, there are many good solutions that fit this pro=
blem space and I do not intend to slow progress. 


If it is difficult=A0 and the differences in merit cannot be easily=A0 q=
uantified between stateful and stateless , I accept that as an answer. 


 I suggested they be compared since opposites frequently help define eac=
h other. Black helps define white just as cold helps define hot.=A0 I had a=
ssumed this was true for this case as well. Perhaps I was wrong. 


Thanks again for your contribution.=A0 


Cb 


> cheers,

> --satoru


--e89a8ff2437d7cf83004b8d08c88--

From satoru.matsushima@gmail.com  Sun Feb 12 21:19:31 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE3121F85ED for ; Sun, 12 Feb 2012 21:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISHBclz0rJue for ; Sun, 12 Feb 2012 21:19:30 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7821221F85D6 for ; Sun, 12 Feb 2012 21:19:30 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so4449549pbc.31 for ; Sun, 12 Feb 2012 21:19:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=n6apBCETiDpPaf3Wc7YzDECk5C+UmjvdEqYSmh17ofc=; b=x5WOjbtxFG+938io4LtJaicIirxWwQNBiGcI9teFjJ52SljJPFcWDSf87kX4TsMAri YnYSBWj1Ztx2bXtK4psCfy+3GhDVMZ6iIoM+P81j1SBDXpfCPEhip/amPxjgm7y+h4UB hb366pk1hPc+VAJAC1z+2EBTkK5nxgcSvchsY=
Received: by 10.68.223.68 with SMTP id qs4mr43318013pbc.112.1329110370167; Sun, 12 Feb 2012 21:19:30 -0800 (PST)
Received: from [10.201.81.209] ([202.45.12.141]) by mx.google.com with ESMTPS id p2sm37383895pbb.14.2012.02.12.21.19.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 21:19:28 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Satoru Matsushima 
In-Reply-To: 
Date: Mon, 13 Feb 2012 06:19:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BB72E68-29B3-42E1-805A-FD195B3A5172@gmail.com>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>  <8EB9B69C-726A-4080-B021-30EE734518CD@gmail.com> 
To: Cameron Byrne 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2012 05:19:31 -0000

On 2012/02/13, at 5:02, Cameron Byrne wrote:

>=20
> On Feb 12, 2012 7:14 PM, "Satoru Matsushima" =
 wrote:
> >
> > On 2012/02/11, at 15:30, Cameron Byrne wrote:
> >
> > --snip--
> > >
> > > I find this omission disappointing. There is a common assumption =
that stateless is superior to stateful, but it is not quantified =
anywhere.
> > >
> > > It seems all this stateless work hinges on this assumption without =
any quantification.
> > >
> > > Honestly, the omission makes me believe the case of stateless =
being superior is dubious.
> > >
> > > Cb
> >
> > Do you think that it is productive productive analysis that =
comparison of stateless between stateful? Current motivation draft =
stands not to beat other solutions, it stands for justifying to start =
stateless solution work on the WG so some proponents of stateless =
solution took a pen. My question is that if the comparison is productive =
for something, who should work for it, and who should read it.
> >
>=20
> I assumed this explanation and comparison would be easy for the =
stateless experts.  I looked to this as a learning opportunity for me.
>=20
> I agree with you and RD, there are many good solutions that fit this =
problem space and I do not intend to slow progress.
>=20
> If it is difficult  and the differences in merit cannot be easily  =
quantified between stateful and stateless , I accept that as an answer.
>=20

I agree that the proponents of statless can work for the comparison, but =
also stateful proponents too.
Does who can work means equal to who should work, which sides is better =
to explain it for the fairness? Maybe both?


> I suggested they be compared since opposites frequently help define =
each other. Black helps define white just as cold helps define hot.  I =
had assumed this was true for this case as well. Perhaps I was wrong.
>=20

Agree. but when do we need it? 6rd vs L2TP, OSPF vs ISIS, LDP vs RSVP, =
etc, etc.,

> Thanks again for your contribution.=20

you too, thanks.
--satoru

>=20
> Cb=20
>=20
> > cheers,
> > --satoru
>=20


From ichiroumakino@gmail.com  Mon Feb 13 01:28:11 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D9321F8717 for ; Mon, 13 Feb 2012 01:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLEajLhjiswM for ; Mon, 13 Feb 2012 01:28:10 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25A3B21F8687 for ; Mon, 13 Feb 2012 01:28:09 -0800 (PST)
Received: by werm10 with SMTP id m10so4365807wer.31 for ; Mon, 13 Feb 2012 01:28:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=fFmi7NQ+EIxQIR99mfWrtNP2JsXCbB5uS85iXqmdSXY=; b=ZvqdBZ/au5mjY/6j9ojimQ537obwAYPqVe0LECshWvphQdBiEkaPG6JUAx3X2TmoIj jrVTjY6SD6n2op1pHDNn6hPnWM1X5xzIbEb4RaJa5HgdBG5Y9xT2MHOEvsl8VY7NciF3 Xqrcy4feLZ60eh3hGf/SuT6meRF4p9V8QYup4=
Received: by 10.180.94.68 with SMTP id da4mr22969836wib.22.1329125289187; Mon, 13 Feb 2012 01:28:09 -0800 (PST)
Received: from dhcp-10-61-97-19.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm35175133wib.4.2012.02.13.01.28.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 01:28:08 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Mon, 13 Feb 2012 10:27:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1758F412-9B21-4E3A-9CFD-3BBFE5439162@employees.org>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>  <8EB9B69C-726A-4080-B021-30EE734518CD@gmail.com> 
To: Cameron Byrne 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2012 09:28:11 -0000

Cameron,

RFC1958 gives the fundamental principles. search for "state".

cheers,
Ole


On Feb 13, 2012, at 5:02 , Cameron Byrne wrote:

>=20
> On Feb 12, 2012 7:14 PM, "Satoru Matsushima" =
 wrote:
> >
> > On 2012/02/11, at 15:30, Cameron Byrne wrote:
> >
> > --snip--
> > >
> > > I find this omission disappointing. There is a common assumption =
that stateless is superior to stateful, but it is not quantified =
anywhere.
> > >
> > > It seems all this stateless work hinges on this assumption without =
any quantification.
> > >
> > > Honestly, the omission makes me believe the case of stateless =
being superior is dubious.
> > >
> > > Cb
> >
> > Do you think that it is productive productive analysis that =
comparison of stateless between stateful? Current motivation draft =
stands not to beat other solutions, it stands for justifying to start =
stateless solution work on the WG so some proponents of stateless =
solution took a pen. My question is that if the comparison is productive =
for something, who should work for it, and who should read it.
> >
>=20
> I assumed this explanation and comparison would be easy for the =
stateless experts.  I looked to this as a learning opportunity for me.
>=20
> I agree with you and RD, there are many good solutions that fit this =
problem space and I do not intend to slow progress.
>=20
> If it is difficult  and the differences in merit cannot be easily  =
quantified between stateful and stateless , I accept that as an answer.
>=20
> I suggested they be compared since opposites frequently help define =
each other. Black helps define white just as cold helps define hot.  I =
had assumed this was true for this case as well. Perhaps I was wrong.
>=20
> Thanks again for your contribution.=20
>=20
> Cb=20
>=20
> > cheers,
> > --satoru
>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From mohamed.boucadair@orange.com  Mon Feb 13 01:28:48 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AB121F8687 for ; Mon, 13 Feb 2012 01:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Level: 
X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdWNjdnEarGs for ; Mon, 13 Feb 2012 01:28:48 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 84C3C21F8717 for ; Mon, 13 Feb 2012 01:28:47 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 67C8B22C5CD; Mon, 13 Feb 2012 10:28:46 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3F2AC27C069; Mon, 13 Feb 2012 10:28:46 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 13 Feb 2012 10:28:46 +0100
From: 
To: Cameron Byrne 
Date: Mon, 13 Feb 2012 10:28:44 +0100
Thread-Topic: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Thread-Index: AczoyciRFkD12/qQR/6ceNSU3+XtfgBWPe8Q
Message-ID: <94C682931C08B048B7A8645303FDC9F35D86965DC1@PUEXCB1B.nanterre.francetelecom.fr>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F35D86965DC1PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.13.70315
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2012 09:28:48 -0000

--_000_94C682931C08B048B7A8645303FDC9F35D86965DC1PUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Cameron,

Yes, I know it is tempting to have such section but it won't help in making=
 a decision and, furthermore, it may maintain a tension between stateless a=
nd stateful camps. We tried in the document to be neutral as much as possib=
le and avoid claiming "stateless is superior to stateful" or "stateful is s=
uperior to stateless".

I personally think both stateful and stateless solutions are needed. It is =
up to each service provider, taking into account its own environment and co=
nstraint, to select the flavour of solutions which fit its needs. The selec=
tion may even be complex given the diversity of networks and services manag=
ed by (large) service providers.

Cheers,
Med


________________________________
De : Cameron Byrne [mailto:cb.list6@gmail.com]
Envoy=E9 : samedi 11 f=E9vrier 2012 15:31
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwires@ietf.org
Objet : Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivatio=
n


On Feb 10, 2012 2:20 AM, > wrote:
>
> Dear WG members,
>
> I would like to close this document so that we can meet the following ite=
m from the WG Charter:
>
> "
> 4. Developments for stateless legacy IPv4 carried over IPv6
> - develop a solution motivation document to be published as an
> RFC
> - develop a protocol specification response to the solution
> motivation document; this work item will not be taken through
> Working Group last call until the solution motivation document
> has been published or approved for publication
> "
>
> Except the a comment asking to include a new section to compare stateful =
vs. stateless, no further comments have been received.
>
> I didn't considered adding the proposed new section because IMO it is out=
 of scope of this document. That section can justify in its own a dedicated=
 draft.
>

I find this omission disappointing. There is a common assumption that state=
less is superior to stateful, but it is not quantified anywhere.

It seems all this stateless work hinges on this assumption without any quan=
tification.

Honestly, the omission makes me believe the case of stateless being superio=
r is dubious.

Cb

> As for the next step, I see two options:
>
> (1) Either issue a WG LC, or
> (2) Withdraw the document and update the WG charter.
>
> WG members, please advise.
>
> Cheers,
> Med
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--_000_94C682931C08B048B7A8645303FDC9F35D86965DC1PUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Dear Cameron,


 


Yes, I know it is tempting to have such secti=
on but it=20
won't help in making a decision and, furthermore, it may maintain a tension=
=20
between stateless and stateful camps. We tried in the document to be neutra=
l as=20
much as possible and avoid claiming "stateless is superior to stateful"&nbs=
p;or=20
"stateful is superior to stateless".


 


I personally think both stateful and stateles=
s=20
solutions are needed. It is up to each service provider, taking into accoun=
t its=20
own environment and constraint, to select the flavour of solutions which fi=
t its=20
needs. The selection may even be complex given the diversity of networks an=
d=20
services managed by (large) service providers.


 


Cheers,


Med


 



  

  

  De : Cameron Byrne=20
  [mailto:cb.list6@gmail.com] 
Envoy=E9 : samedi 11 f=E9vrie=
r 2012=20
  15:31
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc :=
=20
  softwires@ietf.org
Objet : Re: [Softwires] Closing=20
  draft-ietf-softwire-stateless-4v6-motivation


  

  

On Feb 10, 2012 2:20 AM, <mohamed.boucadair@orange.com=
>=20
  wrote:
>
> Dear WG members,
>
> I would like to c=
lose=20
  this document so that we can meet the following item from the WG=20
  Charter:
>
> "
> 4. Developments for stateless legacy I=
Pv4=20
  carried over IPv6
> - develop a solution motivation document to be=
=20
  published as an
> RFC
> - develop a protocol specification=20
  response to the solution
> motivation document; this work item will=
 not=20
  be taken through
> Working Group last call until the solution motiv=
ation=20
  document
> has been published or approved for publication
>=20
  "
>
> Except the a comment asking to include a new section to=
=20
  compare stateful vs. stateless, no further comments have been=20
  received.
>
> I didn't considered adding the proposed new sec=
tion=20
  because IMO it is out of scope of this document. That section can justify=
 in=20
  its own a dedicated draft.
>

  
I find this omission disappointing. There is a common assumption that=
=20
  stateless is superior to stateful, but it is not quantified anywhere.

  
It seems all this stateless work hinges on this assumption without any=
=20
  quantification. 

  
Honestly, the omission makes me believe the case of stateless being=20
  superior is dubious. 

  
Cb

  
> As for the next step, I see two options:
>
> (1) Eith=
er=20
  issue a WG LC, or
> (2) Withdraw the document and update the WG=20
  charter.
>
> WG members, please advise.
>
>=20
  Cheers,
> Med
>=20
  _______________________________________________
> Softwires mailing=
=20
  list
> Softwires@ietf.org
> https://www.ietf=
.org/mailman/listinfo/softwires


--_000_94C682931C08B048B7A8645303FDC9F35D86965DC1PUEXCB1Bnante_--

From maxpassion@gmail.com  Mon Feb 13 04:11:05 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF321F8620 for ; Mon, 13 Feb 2012 04:11:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXjNCBPqhuho for ; Mon, 13 Feb 2012 04:11:04 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD91D21F8617 for ; Mon, 13 Feb 2012 04:11:03 -0800 (PST)
Received: by iagf6 with SMTP id f6so4965503iag.31 for ; Mon, 13 Feb 2012 04:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nL8+As7UT/fJfOd58gKSQ055S6Ri/OoSIsfs+x9wISs=; b=VRGBkodEb4Q0nOVRSoTWzsLQ6Lv9SMnhnwsCN5Zvgq7LtOTfR3gKHuDaoxptbib4BP 4kgxHb60IeWuifrNV8Fx8QrjFwdCpoB6G/wLz9DdR5fbNvxWwr7aZT4wMFvjsXZtLxhi fvcJFDTyUpN5HI/9N+vQ3KPzNq/7vN7C1Tb0M=
MIME-Version: 1.0
Received: by 10.42.157.196 with SMTP id e4mr7426497icx.3.1329135050919; Mon, 13 Feb 2012 04:10:50 -0800 (PST)
Received: by 10.42.29.70 with HTTP; Mon, 13 Feb 2012 04:10:50 -0800 (PST)
In-Reply-To: <1758F412-9B21-4E3A-9CFD-3BBFE5439162@employees.org>
References: <20120210100349.14509.19188.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr>  <8EB9B69C-726A-4080-B021-30EE734518CD@gmail.com>  <1758F412-9B21-4E3A-9CFD-3BBFE5439162@employees.org>
Date: Mon, 13 Feb 2012 20:10:50 +0800
Message-ID: 
From: liu dapeng 
To: =?ISO-8859-1?Q?Ole_Tr=F8an?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires WG 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2012 12:11:05 -0000

2012/2/13, Ole Tr=F8an :
> Cameron,
>
> RFC1958 gives the fundamental principles. search for "state".

Yes. But do you think it is achievable for "pure stateless"?

BR,
Dapeng

> cheers,
> Ole
>
>
> On Feb 13, 2012, at 5:02 , Cameron Byrne wrote:
>
>>
>> On Feb 12, 2012 7:14 PM, "Satoru Matsushima" 
>> wrote:
>> >
>> > On 2012/02/11, at 15:30, Cameron Byrne wrote:
>> >
>> > --snip--
>> > >
>> > > I find this omission disappointing. There is a common assumption tha=
t
>> > > stateless is superior to stateful, but it is not quantified anywhere=
.
>> > >
>> > > It seems all this stateless work hinges on this assumption without a=
ny
>> > > quantification.
>> > >
>> > > Honestly, the omission makes me believe the case of stateless being
>> > > superior is dubious.
>> > >
>> > > Cb
>> >
>> > Do you think that it is productive productive analysis that comparison
>> > of stateless between stateful? Current motivation draft stands not to
>> > beat other solutions, it stands for justifying to start stateless
>> > solution work on the WG so some proponents of stateless solution took =
a
>> > pen. My question is that if the comparison is productive for something=
,
>> > who should work for it, and who should read it.
>> >
>>
>> I assumed this explanation and comparison would be easy for the stateles=
s
>> experts.  I looked to this as a learning opportunity for me.
>>
>> I agree with you and RD, there are many good solutions that fit this
>> problem space and I do not intend to slow progress.
>>
>> If it is difficult  and the differences in merit cannot be easily
>> quantified between stateful and stateless , I accept that as an answer.
>>
>> I suggested they be compared since opposites frequently help define each
>> other. Black helps define white just as cold helps define hot.  I had
>> assumed this was true for this case as well. Perhaps I was wrong.
>>
>> Thanks again for your contribution.
>>
>> Cb
>>
>> > cheers,
>> > --satoru
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>


--=20

------
Best Regards,
Dapeng Liu

From wwwrun@rfc-editor.org  Mon Feb 13 22:25:06 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B830221E8085; Mon, 13 Feb 2012 22:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.111
X-Spam-Level: 
X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD5ovDkRV+78; Mon, 13 Feb 2012 22:25:06 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5144921E8079; Mon, 13 Feb 2012 22:25:06 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 2138D72F1F1; Mon, 13 Feb 2012 22:20:26 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120214062026.2138D72F1F1@rfc-editor.org>
Date: Mon, 13 Feb 2012 22:20:26 -0800 (PST)
Cc: softwires@ietf.org, rfc-editor@rfc-editor.org
Subject: [Softwires] RFC 6519 on RADIUS Extensions for Dual-Stack Lite
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2012 06:25:06 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6519

        Title:      RADIUS Extensions for Dual-Stack Lite 
        Author:     R. Maglione, A. Durand
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2012
        Mailbox:    roberta.maglione@telecomitalia.it, 
                    adurand@juniper.net
        Pages:      11
        Characters: 22574
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-softwire-dslite-radius-ext-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6519.txt

Dual-Stack Lite is a solution to offer both IPv4 and IPv6
connectivity to customers that are addressed only with an IPv6
prefix.  Dual-Stack Lite requires pre-configuration of the Dual-Stack
Lite Address Family Transition Router (AFTR) tunnel information on
the Basic Bridging BroadBand (B4) element.  In many networks, the
customer profile information may be stored in Authentication,
Authorization, and Accounting (AAA) servers, while client
configurations are mainly provided through the Dynamic Host
Configuration Protocol (DHCP).  This document specifies a new Remote
Authentication Dial-In User Service (RADIUS) attribute to carry the
Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined
based on the equivalent DHCPv6 OPTION_AFTR_NAME option.  This RADIUS
attribute is meant to be used between the RADIUS server and the
Network Access Server (NAS); it is not intended to be used directly
between the B4 element and the RADIUS server.  [STANDARDS-TRACK]

This document is a product of the Softwires Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From fibrib@gmail.com  Tue Feb 14 03:09:16 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FA621F87AB for ; Tue, 14 Feb 2012 03:09:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.315
X-Spam-Level: 
X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N2Y907PgHRf for ; Tue, 14 Feb 2012 03:09:15 -0800 (PST)
Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66921F8729 for ; Tue, 14 Feb 2012 03:09:15 -0800 (PST)
Received: by qan41 with SMTP id 41so184181qan.10 for ; Tue, 14 Feb 2012 03:09:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E1hMRS0ppIzGEEWzTNz2y+j7k+ch9wqmeX1O7aVw4w0=; b=frLNKDHIulHQlpo4k5pTP+WEzbowrXIr/R7mDDmHMrndVI6bmTyxh+mYcB+T/0EUuP rnJbiR9iGzYcLpczZdmrJpQv9NKwfJf9PKcoN7dQ/PwZmYuIyGjexdOm7MZfiazhk2S9 T6SQnfZ8Dabbir/2u2Hx4K64mWCoFOJIIyrZI=
MIME-Version: 1.0
Received: by 10.229.137.76 with SMTP id v12mr12156344qct.61.1329217754694; Tue, 14 Feb 2012 03:09:14 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Tue, 14 Feb 2012 03:09:14 -0800 (PST)
In-Reply-To: 
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> 
Date: Tue, 14 Feb 2012 20:09:14 +0900
Message-ID: 
From: Maoke 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=00235452ea7019038804b8eaa0ef
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2012 11:09:17 -0000

--00235452ea7019038804b8eaa0ef
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Remi, Ole, and others,

sorry but i follow this quite late due to recent busy work. i would like to
share some of my understandings to this issue.

2012/2/6 R=E9mi Despr=E9s 

>
> Le 2012-02-05 =E0 10:05, Ole Tr=F8an a =E9crit :
> ...
> >>> any A+P solution requires support for L4 protocols to extract ports.
> >>> L4 checksum rewrite, as well as port extraction will have to be
> supported for all new L4 protocols.
> >>> the L4 checksum rewrite approach can work with any checksum algorithm=
.
> >>> that said, do we really think NAT44s will be upgraded to support any
> new L4?
> >>
> >> Imagine a variant of the SCTP of RFC4960 is introduced where the
> TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis
> (not a bad idea IMHO, but here just a hypothesis to answer your point).
> >> =3D> 4rd-H would be compatible with it without any evolution; RFC6145
> would need an upgrade to support it.
>

i understand that Remi's concern is, RFC6145 left an "OPTIONAL" for the
support of the DCCP checksum. this "OPTIONAL" may impact as 1) for the
single translation, DCCP checksum check might fail in the alien protocol
family; 2) for the double translation, there is a risk that the
sender-translator has done the L4 checksum rewrite while the receiver side
doesn't, and thus the DCCP checksum transparency is voilated. the same
concern is applicable for the SCTP, if someday TCP-fashion checksum is
applied too.

if the both sides consistently do not do L4 checksum-rewriting for DCCP,
there is no problem for the end-to-end communication but only the boxes in
IPv6 domains, if they check the L4 checksum to approve the packet
integrity, might drop packets with wrong checksum. it could be a
recommendation if RFC6145 would make the L4 checksum rewriting fixed for
any protocols or make an emphasis on the consistency in configuration,
(i.e., OPTIONAL in the term of domain operation rather than in the term of
equipment making/configuration).


> >>
> >> Upgrading NAT44s to support this SCTP-bis would be trivial (ports as
> the same place as usual can be mapped as usual.
> >
> > my point is that MAP is L4 aware anyway, and has to be modified to
> support any new transport protocol. since code modifications have to be
> made, then having a checksum neutral function at the network layer doesn'=
t
> help much. you still need to change code. L4 rewrite is also more flexibl=
e
> in that it will support _any_ checksum algorithm, and most importantly is
> already implemented in every node.
>
> Thus, you continue to negate that 4rd-U would support without any change =
a
> protocol such as, for example, a SCTP variant using TCP-like checksum
> instead of its CRC32c checksum.
>
> This negation is AFAIK based on a lack of understanding:
> - UDP, TCP, DCCP, SCTP have the same places for port their fields, but
> have their own places for their checksum fields.
> - A solution based on L4 checksum adjustment MUST know _for each protocol=
_
> where checksum fields are placed.
> - A solution based on checksum neutrality of IPv6 addresses doesn't need
> to know where checksum fields are placed.
> - For address sharing, knowing places of port fields is sufficient.
>

however, dear Remi, the problem is, even we have the checksum neutrality in
address scheme, there are still some problems need to concern:
1) ICMPv6 checksum contains pseudo-header like TCP while ICMPv4 doesn't and
therefore the checksum rewrite is anyway needed for ICMP; we cannot ensure
that future L4 procotols may definitely have the same checksum as in TCP.
2) in the environment where single translation is also envolved (either
stateless or stateful), L4 checksum rewriting is a MUST because sometimes
there is only one address of the (src, dst)-pair following the
checksum-neutral address scheme. (this is mentioned in RFC6052, giving up
to enforce the checksum-neutrality in the address format, to my knowledge).


therefore, even it is possible that the address scheme could support
checksum neutrallity, the equipment designer must anyway make the module
for L4 rewrite for any well-known L4 protocol (and fortunately it is not a
big coding at all). i understand Ole has the same opinion: as we anyway
have it, we don't need it in the address scheme standard (but it could be a
recommendation for the operators to enable the address-level checksum
neutrality, put in either prefix or interface id, through the address
assignment, in order to help any L4 protocol when its TCP-flavor checksum
rewrite happens not to be considered/implemented).

cheers,
maoke


>
> I added Dan as destination of this mail, hoping to have his comment.
>
> RD
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--00235452ea7019038804b8eaa0ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Remi, Ole, and others,

sorry but i follow=
 this quite late due to recent busy work. i would like to share some of my =
understandings to this issue.=A0

2012/2=
/6 R=E9mi Despr=E9s <despres.remi@laposte.net>




Le 2012-02-05 =E0 10:05, Ole Tr=F8an a =E9crit :

...

>>> any A+P solution requires support for L4 protocols to extract =
ports.

>>> L4 checksum rewrite, as well as port extraction will have to b=
e supported for all new L4 protocols.

>>> the L4 checksum rewrite approach can work with any checksum al=
gorithm.

>>> that said, do we really think NAT44s will be upgraded to suppo=
rt any new L4?

>>

>> Imagine a variant of the SCTP of RFC4960 is introduced where the T=
CP-like checksum MAY be used to facilitate its deployment, say SCTP-bis (no=
t a bad idea IMHO, but here just a hypothesis to answer your point).


>> =3D> 4rd-H would be compatible with it without any evolution; R=
FC6145 would need an upgrade to support it.

=

i understand that Remi's concern is, RFC6145 left an "OP=
TIONAL" for the support of the DCCP checksum. this "OPTIONAL"=
; may impact as 1) for the single translation, DCCP checksum check might fa=
il in the alien protocol family; 2) for the double translation, there is a =
risk that the sender-translator has done the L4 checksum rewrite while the =
receiver side doesn't, and thus the DCCP checksum transparency is voila=
ted. the same concern is applicable for the SCTP, if someday TCP-fashion ch=
ecksum is applied too.=A0



if the both sides consistently do not do L4 checksum-re=
writing for DCCP, there is no problem for the end-to-end communication but =
only the boxes in IPv6 domains, if they check the L4 checksum to approve th=
e packet integrity, might drop packets with wrong checksum. it could be a r=
ecommendation if RFC6145 would make the L4 checksum rewriting fixed for any=
 protocols or make an emphasis on the consistency in configuration, (i.e., =
OPTIONAL in the term of domain operation rather than in the term of equipme=
nt making/configuration).=A0


=A0

>>

>> Upgrading NAT44s to support this SCTP-bis would be trivial (ports =
as the same place as usual can be mapped as usual.

>

> my point is that MAP is L4 aware anyway, and has to be modified to sup=
port any new transport protocol. since code modifications have to be made, =
then having a checksum neutral function at the network layer doesn't he=
lp much. you still need to change code. L4 rewrite is also more flexible in=
 that it will support _any_ checksum algorithm, and most importantly is alr=
eady implemented in every node.




Thus, you continue to negate that 4rd-U would support without any change a =
protocol such as, for example, a SCTP variant using TCP-like checksum inste=
ad of its CRC32c checksum.



This negation is AFAIK based on a lack of understanding:

- UDP, TCP, DCCP, SCTP have the same places for port their fields, but have=
 their own places for their checksum fields.

- A solution based on L4 checksum adjustment MUST know _for each protocol_ =
where checksum fields are placed.

- A solution based on checksum neutrality of IPv6 addresses doesn't nee=
d to know where checksum fields are placed.

- For address sharing, knowing places of port fields is sufficient.

however, dear Remi, the problem is, even we ha=
ve the checksum neutrality in address scheme, there are still some problems=
 need to concern:


1) ICMPv6 checksum contains pseudo-header like TCP while ICMPv4 doesn&=
#39;t and therefore the checksum rewrite is anyway needed for ICMP; we cann=
ot ensure that future L4 procotols may definitely have the same checksum as=
 in TCP.=A0


2) in the environment where single translation is also envolved (eithe=
r stateless or stateful), L4 checksum rewriting is a MUST because sometimes=
 there is only one address of the (src, dst)-pair following the checksum-ne=
utral address scheme. (this is mentioned in RFC6052, giving up to enforce t=
he checksum-neutrality in the address format, to my knowledge). =A0



therefore, even it is possible that the address scheme =
could support checksum neutrallity, the equipment designer must anyway make=
 the module for L4 rewrite for any well-known L4 protocol (and fortunately =
it is not a big coding at all). i understand Ole has the same opinion: as w=
e anyway have it, we don't need it in the address scheme standard (but =
it could be a recommendation for the operators to enable the address-level =
checksum neutrality, put in either prefix or interface id, through the addr=
ess assignment, in order to help any L4 protocol when its TCP-flavor checks=
um rewrite happens not to be considered/implemented).=A0



cheers,
maoke
=A0



I added Dan as destination of this mail, hoping to have his comment.



RD





_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--00235452ea7019038804b8eaa0ef--

From despres.remi@laposte.net  Tue Feb 14 06:34:39 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C4B21F8745 for ; Tue, 14 Feb 2012 06:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.709
X-Spam-Level: 
X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYAdkRfKLliF for ; Tue, 14 Feb 2012 06:34:37 -0800 (PST)
Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 311F321F8715 for ; Tue, 14 Feb 2012 06:34:36 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id ZqaZ1i00637Y3f403qaZzJ; Tue, 14 Feb 2012 15:34:34 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-12-883038579
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Tue, 14 Feb 2012 15:34:33 +0100
Message-Id: <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>  
To: Maoke 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2012 14:34:39 -0000

--Apple-Mail-12-883038579
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 2012-02-14 =E0 12:09, Maoke a =E9crit :

> Remi, Ole, and others,
>=20
> sorry but i follow this quite late due to recent busy work. i would =
like to share some of my understandings to this issue.=20
>=20
> 2012/2/6 R=E9mi Despr=E9s 
>=20
> Le 2012-02-05 =E0 10:05, Ole Tr=F8an a =E9crit :
> ...
> >>> any A+P solution requires support for L4 protocols to extract =
ports.
> >>> L4 checksum rewrite, as well as port extraction will have to be =
supported for all new L4 protocols.
> >>> the L4 checksum rewrite approach can work with any checksum =
algorithm.
> >>> that said, do we really think NAT44s will be upgraded to support =
any new L4?
> >>
> >> Imagine a variant of the SCTP of RFC4960 is introduced where the =
TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis =
(not a bad idea IMHO, but here just a hypothesis to answer your point).
> >> =3D> 4rd-H would be compatible with it without any evolution; =
RFC6145 would need an upgrade to support it.
>=20
> i understand that Remi's concern is, RFC6145 left an "OPTIONAL" for =
the support of the DCCP checksum. this "OPTIONAL" may impact as 1) for =
the single translation, DCCP checksum check might fail in the alien =
protocol family; 2) for the double translation, there is a risk that the =
sender-translator has done the L4 checksum rewrite while the receiver =
side doesn't, and thus the DCCP checksum transparency is voilated. the =
same concern is applicable for the SCTP, if someday TCP-fashion checksum =
is applied too.

This is indeed one point.

> if the both sides consistently do not do L4 checksum-rewriting for =
DCCP, there is no problem for the end-to-end communication but only the =
boxes in IPv6 domains, if they check the L4 checksum to approve the =
packet integrity, might drop packets with wrong checksum. it could be a =
recommendation if RFC6145 would make the L4 checksum rewriting fixed for =
any protocols or make an emphasis on the consistency in configuration, =
(i.e., OPTIONAL in the term of domain operation rather than in the term =
of equipment making/configuration).=20
> =20
> >>
> >> Upgrading NAT44s to support this SCTP-bis would be trivial (ports =
as the same place as usual can be mapped as usual.
> >
> > my point is that MAP is L4 aware anyway, and has to be modified to =
support any new transport protocol. since code modifications have to be =
made, then having a checksum neutral function at the network layer =
doesn't help much. you still need to change code. L4 rewrite is also =
more flexible in that it will support _any_ checksum algorithm, and most =
importantly is already implemented in every node.
>=20
> Thus, you continue to negate that 4rd-U would support without any =
change a protocol such as, for example, a SCTP variant using TCP-like =
checksum instead of its CRC32c checksum.
>=20
> This negation is AFAIK based on a lack of understanding:
> - UDP, TCP, DCCP, SCTP have the same places for port their fields, but =
have their own places for their checksum fields.
> - A solution based on L4 checksum adjustment MUST know _for each =
protocol_ where checksum fields are placed.
> - A solution based on checksum neutrality of IPv6 addresses doesn't =
need to know where checksum fields are placed.
> - For address sharing, knowing places of port fields is sufficient.
>=20
> however, dear Remi, the problem is,


ANOTHER problem.=20
The point just above remains true, right?
=20
> even we have the checksum neutrality in address scheme, there are =
still some problems need to concern:
> 1) ICMPv6 checksum contains pseudo-header like TCP while ICMPv4 =
doesn't and therefore the checksum rewrite is anyway needed for ICMP; we =
cannot ensure that future L4 procotols may definitely have the same =
checksum as in TCP.

ICMP is as subject per se, and dealt with as such.
(ICMP isn't a transport protocol having _port fields at their usual =
place_)
> =20
> 2) in the environment where single translation is also envolved =
(either stateless or stateful), L4 checksum rewriting is a MUST because =
sometimes there is only one address of the (src, dst)-pair following the =
checksum-neutral address scheme. (this is mentioned in RFC6052, giving =
up to enforce the checksum-neutrality in the address format, to my =
knowledge).

I have aways acknowledged that L4 update is necessary for single =
translation, no disagreement.
But here the problem is stateless IPv4 service across IPv6, a different =
problem where there is no such necessity.

> therefore, even it is possible that the address scheme could support =
checksum neutrallity, the equipment designer must anyway make the module =
for L4 rewrite for any well-known L4 protocol (and fortunately it is not =
a big coding at all).

Coding complexity is not the point (trivial in both cases).
The point is that, where it can be used, checksum neutrality is MORE =
GENERAL than L4 update.
Besides, but less important, it is simpler as far as the number of =
specifications it depends on is concerned (no need to know where =
checksum fields are for different protocols).


> i understand Ole has the same opinion: as we anyway have it,

There can be implementations of BRs that are independent of single =
translation.
They don't need to know where checksums are placed in various protocols.
=20

> we don't need it in the address scheme standard

One can live with a standard less good than it could be but, since we =
are working for the future, let's make them as good as we can now.
In any case, this is no excuse to claim that, with checksum neutrality =
the following is not correct "BRs need no change for any new protocol =
having ports at their usual place and TCP-like checksum" (DCCP, SCTP if =
it would acce^t TCP-like checksum, any other.)
=20

> (but it could be a recommendation for the operators to enable the =
address-level checksum neutrality,

What remains to be seen is what is gained by not having it a MUST while =
we are specifying a new standard for a new problem.

Cheers,
RD

> put in either prefix or interface id, through the address assignment, =
in order to help any L4 protocol when its TCP-flavor checksum rewrite =
happens not to be considered/implemented).=20
>=20
> cheers,
> maoke


--Apple-Mail-12-883038579
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


Remi, =
Ole, and others,

sorry but i follow this =
quite late due to recent busy work. i would like to share some of my =
understandings to this issue. 

2012/2/6 R=E9mi Despr=E9s <despres.remi@laposte.net><=
/span>




Le 2012-02-05 =E0 10:05, Ole Tr=F8an a =E9crit :

...

>>> any A+P solution requires support for L4 protocols to =
extract ports.

>>> L4 checksum rewrite, as well as port extraction will have =
to be supported for all new L4 protocols.

>>> the L4 checksum rewrite approach can work with any checksum =
algorithm.

>>> that said, do we really think NAT44s will be upgraded to =
support any new L4?

>>

>> Imagine a variant of the SCTP of RFC4960 is introduced where =
the TCP-like checksum MAY be used to facilitate its deployment, say =
SCTP-bis (not a bad idea IMHO, but here just a hypothesis to answer your =
point).


>> =3D> 4rd-H would be compatible with it without any =
evolution; RFC6145 would need an upgrade to support =
it.

i understand that Remi's =
concern is, RFC6145 left an "OPTIONAL" for the support of the DCCP =
checksum. this "OPTIONAL" may impact as 1) for the single translation, =
DCCP checksum check might fail in the alien protocol family; 2) for the =
double translation, there is a risk that the sender-translator has done =
the L4 checksum rewrite while the receiver side doesn't, and thus the =
DCCP checksum transparency is voilated. the same concern is applicable =
for the SCTP, if someday TCP-fashion checksum is applied =
too.

This is indeed one =
point.

if the both sides consistently do not do =
L4 checksum-rewriting for DCCP, there is no problem for the end-to-end =
communication but only the boxes in IPv6 domains, if they check the L4 =
checksum to approve the packet integrity, might drop packets with wrong =
checksum. it could be a recommendation if RFC6145 would make the L4 =
checksum rewriting fixed for any protocols or make an emphasis on the =
consistency in configuration, (i.e., OPTIONAL in the term of domain =
operation rather than in the term of equipment =
making/configuration). 


 

>>

>> Upgrading NAT44s to support this SCTP-bis would be trivial =
(ports as the same place as usual can be mapped as usual.

>

> my point is that MAP is L4 aware anyway, and has to be modified to =
support any new transport protocol. since code modifications have to be =
made, then having a checksum neutral function at the network layer =
doesn't help much. you still need to change code. L4 rewrite is also =
more flexible in that it will support _any_ checksum algorithm, and most =
importantly is already implemented in every node.




Thus, you continue to negate that 4rd-U would support without any change =
a protocol such as, for example, a SCTP variant using TCP-like checksum =
instead of its CRC32c checksum.



This negation is AFAIK based on a lack of understanding:

- UDP, TCP, DCCP, SCTP have the same places for port their fields, but =
have their own places for their checksum fields.

- A solution based on L4 checksum adjustment MUST know _for each =
protocol_ where checksum fields are placed.

- A solution based on checksum neutrality of IPv6 addresses doesn't need =
to know where checksum fields are placed.

- For address sharing, knowing places of port fields is =
sufficient.

however, dear Remi, the =
problem is, =



ANOTHER =
problem. 
The point just above remains true, =
right?
 
even we have the checksum neutrality in =
address scheme, there are still some problems need to concern:


1) ICMPv6 checksum contains pseudo-header like TCP while ICMPv4 =
doesn't and therefore the checksum rewrite is anyway needed for ICMP; we =
cannot ensure that future L4 procotols may definitely have the same =
checksum as in TCP.

ICMP is as =
subject per se, and dealt with as such.
(ICMP isn't a =
transport protocol having _port fields at their usual =
place_)
 


2) in the environment where single translation is also envolved =
(either stateless or stateful), L4 checksum rewriting is a MUST because =
sometimes there is only one address of the (src, dst)-pair following the =
checksum-neutral address scheme. (this is mentioned in RFC6052, giving =
up to enforce the checksum-neutrality in the address format, to my =
knowledge).

I have aways =
acknowledged that L4 update is necessary for single translation, no =
disagreement.
But here the problem is stateless IPv4 service =
across IPv6, a different problem where there is no such =
necessity.

therefore, even it is possible that the =
address scheme could support checksum neutrallity, the equipment =
designer must anyway make the module for L4 rewrite for any well-known =
L4 protocol (and fortunately it is not a big coding at =
all).

Coding complexity is not =
the point (trivial in both cases).
The point is that, where it =
can be used, checksum neutrality is MORE GENERAL than L4 =
update.
Besides, but less important, it is simpler as far as =
the number of specifications it depends on is concerned (no need to know =
where checksum fields are for different =
protocols).


i understand Ole has the =
same opinion: as we anyway have it, =


There can be =
implementations of BRs that are independent of single =
translation.
They don't need to know where checksums are =
placed in various protocols.
 

we don't need it in the =
address scheme standard

One can =
live with a standard less good than it could be but, since we are =
working for the future, let's make them as good as we can =
now.
In any case, this is no excuse to claim that, with =
checksum neutrality the following is not correct "BRs need no change for any new protocol having ports at their usual place and TCP-like checksum" (DCCP, SCTP if it would acce^t =
TCP-like checksum, any other.)
 

 (but it could be a recommendation for the =
operators to enable the address-level checksum neutrality, =


What remains to be seen is what =
is gained by not having it a MUST while we are specifying a new standard =
for a new =
problem.

Cheers,
RD

put in either =
prefix or interface id, through the address assignment, in order to help =
any L4 protocol when its TCP-flavor checksum rewrite happens not to be =
considered/implemented). 

=


cheers,
maoke
=

=

--Apple-Mail-12-883038579--

From fibrib@gmail.com  Tue Feb 14 07:21:59 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7B621F8778 for ; Tue, 14 Feb 2012 07:21:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.013
X-Spam-Level: 
X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl-LlVgH+M9H for ; Tue, 14 Feb 2012 07:21:58 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8856E21F846E for ; Tue, 14 Feb 2012 07:21:55 -0800 (PST)
Received: by qafi29 with SMTP id i29so2300750qaf.10 for ; Tue, 14 Feb 2012 07:21:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YFHQtefhY5KRcSJqi3x2cQ+FUd2BctWh+qyOPFBQPJs=; b=h1ejZrpkiPrYa3MQY5rS5zEqQLv9mxHjiLBaOrL3f3uQMkPkWlpX3rqf+uOD+pwmW0 3Qn+abBKpu98C0VaEEOcQjj/OAN7I0ky/wTpd3niZGS1ciE1W02x+9iP5XW1kzhV3hzG qEHZofCeGUorw7zX8QHJMvtvM3AWURdA8ZcC4=
MIME-Version: 1.0
Received: by 10.229.77.12 with SMTP id e12mr12723309qck.41.1329232915084; Tue, 14 Feb 2012 07:21:55 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Tue, 14 Feb 2012 07:21:55 -0800 (PST)
In-Reply-To: <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>
Date: Wed, 15 Feb 2012 00:21:55 +0900
Message-ID: 
From: Maoke 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=00235429e11cba36c104b8ee2749
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2012 15:21:59 -0000

--00235429e11cba36c104b8ee2749
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net

>
>
2) in the environment where single translation is also envolved (either
> stateless or stateful), L4 checksum rewriting is a MUST because sometimes
> there is only one address of the (src, dst)-pair following the
> checksum-neutral address scheme. (this is mentioned in RFC6052, giving up
> to enforce the checksum-neutrality in the address format, to my knowledge=
).
>
>
> I have aways acknowledged that L4 update is necessary for single
> translation, no disagreement.
> But here the problem is stateless IPv4 service across IPv6, a different
> problem where there is no such necessity.
>
>

RFC6052 includes also the double-translation case. i guess operators
wouldn't like to deploy different translators here for single translation
while there for double.


>
> The point is that, where it can be used, checksum neutrality is MORE
> GENERAL than L4 update.
>
>

how do you define the "generality"? doing L4 update is a safe choice no
matter if the addresses are checksum-neutral or not.


>
> Besides, but less important, it is simpler as far as the number of
> specifications it depends on is concerned (no need to know where checksum
> fields are for different protocols).
>
>

>
> i understand Ole has the same opinion: as we anyway have it,
>
>
> There can be implementations of BRs that are independent of single
> translation.
> They don't need to know where checksums are placed in various protocols.
>
>
> we don't need it in the address scheme standard
>
>
> One can live with a standard less good than it could be but, since we are
> working for the future, let's make them as good as we can now.
> In any case, this is no excuse to claim that, with checksum neutrality th=
e
> following is not correct "BRs need no change for any new protocol having
> ports at their usual place and TCP-like checksum" (DCCP, SCTP if it would
> acce^t TCP-like checksum, any other.)
>
>
i think making L4 checksum update is a safe choice for standard. once we
have a new L4 protocol, the BR surely need a change to check if this new
protocol is a TCP-checksumed one. at least the BR's code should include the
new protocol number in to the list of checksum-neutrality-compatible.
A better BR needs also to check the packet integrity with ensuring that the
checksum is correct and there a L4 activity is not avoidable. therefore i
do agree with Ole's argument. if i make anything incorrect, please point
out.

best,
maoke

> (but it could be a recommendation for the operators to enable the
> address-level checksum neutrality,
>
>
> What remains to be seen is what is gained by not having it a MUST while w=
e
> are specifying a new standard for a new problem.
>
> Cheers,
> RD
>
> put in either prefix or interface id, through the address assignment, in
> order to help any L4 protocol when its TCP-flavor checksum rewrite happen=
s
> not to be considered/implemented).
>
> cheers,
> maoke
>
>
>

--00235429e11cba36c104b8ee2749
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net


=A0
=





2) in the environment where single translation is also envolved (eithe=
r stateless or stateful), L4 checksum rewriting is a MUST because sometimes=
 there is only one address of the (src, dst)-pair following the checksum-ne=
utral address scheme. (this is mentioned in RFC6052, giving up to enforce t=
he checksum-neutrality in the address format, to my knowledge).



I have aways acknowledged that L4 u=
pdate is necessary for single translation, no disagreement.
But h=
ere the problem is stateless IPv4 service across IPv6, a different problem =
where there is no such necessity.


=A0
=A0
RFC6052 includes also t=
he double-translation case. i guess operators wouldn't like to deploy d=
ifferent translators here for single translation while there for double. 

=A0
=A0=



The point is that, where it can be used, checksum neutrality is MORE G=
ENERAL than L4 update.
=A0
=A0
=

how do you define the "generality"? doing L4 update is=A0a s=
afe choice=A0no matter if the addresses are checksum-neutral or not. 


=A0
=A0=



Besides, but less important, it is simpler as far as the number of spe=
cifications it depends on is concerned (no need to know where checksum fiel=
ds are for different protocols).
=A0


=A0
i understand Ole ha=
s the same opinion: as we anyway have it, 


There can be implementations of BRs that are independent of sing=
le translation.
They don't need to know where checksums are p=
laced in various protocols.
=A0



we don't need it in the address scheme =
standard

One can live with a s=
tandard less good than it could be but, since we are working for the future=
, let's make them as good as we can now.


In any case, this is no excuse to claim that, with checksum neutrality=
 the following is not correct "BRs need no change for any new protocol having ports at their us=
ual place=
 and TCP-like checksum" (DCCP, SCTP if it would acce^t TCP-like checks=
um, any other.)


 

=A0
=

i think making L4 checksum update is a safe choice for standard. once =
we have a new L4=A0protocol, the BR surely need a change to=A0check if this=
 new protocol is a TCP-checksumed one. at least the BR's code should=A0=
include=A0the new=A0protocol number in to the list of checksum-neutrality-c=
ompatible. A=A0better BR needs also to check the packet=A0integrity=A0with =
ensuring that the checksum=A0is correct=A0and=A0there a L4 activity is not =
avoidable.=A0therefore i do agree with Ole's argument. if i make anythi=
ng incorrect, please point out. 


=A0
best,
maoke


 (but it could be a recommendation for the operators to enable the ad=
dress-level checksum neutrality, 


What remains to be seen is what is gained by not having it a MUST while we =
are specifying a new standard for a new problem.

C=
heers,
RD



put in either prefix or interface id, throu=
gh the address assignment, in order to help any L4 protocol when its TCP-fl=
avor checksum rewrite happens not to be considered/implemented).=A0



cheers,
maoke
<=
br>



--00235429e11cba36c104b8ee2749--

From despres.remi@laposte.net  Tue Feb 14 07:53:31 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767E921F8780 for ; Tue, 14 Feb 2012 07:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.708
X-Spam-Level: 
X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7ys+gXUx9Sw for ; Tue, 14 Feb 2012 07:53:30 -0800 (PST)
Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 0154221F85E7 for ; Tue, 14 Feb 2012 07:53:29 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id ZrtS1i00737Y3f403rtSRQ; Tue, 14 Feb 2012 16:53:27 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-13-887771346
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Tue, 14 Feb 2012 16:53:25 +0100
Message-Id: <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net> 
To: Maoke 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2012 15:53:31 -0000

--Apple-Mail-13-887771346
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 2012-02-14 =E0 16:21, Maoke a =E9crit :

>=20
>=20
> 2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net
> =20
>> 2) in the environment where single translation is also envolved =
(either stateless or stateful), L4 checksum rewriting is a MUST because =
sometimes there is only one address of the (src, dst)-pair following the =
checksum-neutral address scheme. (this is mentioned in RFC6052, giving =
up to enforce the checksum-neutrality in the address format, to my =
knowledge).
>=20
> I have aways acknowledged that L4 update is necessary for single =
translation, no disagreement.
> But here the problem is stateless IPv4 service across IPv6, a =
different problem where there is no such necessity.
> =20
> =20
> RFC6052 includes also the double-translation case. i guess operators =
wouldn't like to deploy different translators here for single =
translation while there for double.
> =20
> =20
> The point is that, where it can be used, checksum neutrality is MORE =
GENERAL than L4 update.
> =20
> =20
> how do you define the "generality"? doing L4 update is a safe choice =
no matter if the addresses are checksum-neutral or not.
> =20
> =20
> Besides, but less important, it is simpler as far as the number of =
specifications it depends on is concerned (no need to know where =
checksum fields are for different protocols).
> =20
> =20
>> i understand Ole has the same opinion: as we anyway have it,
>=20
> There can be implementations of BRs that are independent of single =
translation.
> They don't need to know where checksums are placed in various =
protocols.
> =20
>=20
>> we don't need it in the address scheme standard
>=20
> One can live with a standard less good than it could be but, since we =
are working for the future, let's make them as good as we can now.
> In any case, this is no excuse to claim that, with checksum neutrality =
the following is not correct "BRs need no change for any new protocol =
having ports at their usual place and TCP-like checksum" (DCCP, SCTP if =
it would acce^t TCP-like checksum, any other.)
> =20
>=20
> =20
> i think making L4 checksum update is a safe choice for standard. once =
we have a new L4 protocol,
> the BR surely need a change to check if this new protocol is a =
TCP-checksumed one.

1. A key, that probably hasn't been clarified enough so far (thanks for =
in fact raising it), is the following:
- With checksum neutrality, the BR DOESN'T NEED to know about UDP, TCP =
etc. (see R-22 (3) of the 4rd-U draft).

If, by mistake a remote host sends to a shared IPv4 address a packet =
whose L4 payload has no ports at their usual places, the packet, if it =
reaches a CE, will ALWAYS be  discarded there (protocol unknown by the =
NAT44) =3D> no operational problem.=20

This is one more instance where it isn't useful to try and guess what =
mistakes people might make, and to add specific software for them while =
tools already exist to detect and signal them. (Keep it simple)

OK?


> at least the BR's code should include the new protocol number in to =
the list of checksum-neutrality-compatible.

See above.

> A better BR needs also to check the packet integrity with ensuring =
that the checksum is correct and there a L4 activity is not avoidable.

2. A less good BR in my understanding: more processing for no =
appreciable gain.

>  therefore i do agree with Ole's argument.

> if i make anything incorrect, please point out.

See above.

Cheers,
RD


> =20
> best,
> maoke
>> (but it could be a recommendation for the operators to enable the =
address-level checksum neutrality,
>=20
> What remains to be seen is what is gained by not having it a MUST =
while we are specifying a new standard for a new problem.
>=20
> Cheers,
> RD
>=20
>> put in either prefix or interface id, through the address assignment, =
in order to help any L4 protocol when its TCP-flavor checksum rewrite =
happens not to be considered/implemented).=20
>>=20
>> cheers,
>> maoke
>=20
>=20


--Apple-Mail-13-887771346
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1




2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net


 




2) in the environment where single translation is also envolved =
(either stateless or stateful), L4 checksum rewriting is a MUST because =
sometimes there is only one address of the (src, dst)-pair following the =
checksum-neutral address scheme. (this is mentioned in RFC6052, giving =
up to enforce the checksum-neutrality in the address format, to my =
knowledge).



I have aways acknowledged that =
L4 update is necessary for single translation, no =
disagreement.
But here the problem is stateless IPv4 service =
across IPv6, a different problem where there is no such necessity.


 
 
RFC6052 =
includes also the double-translation case. i guess operators wouldn't =
like to deploy different translators here for single translation while =
there for double. 


 
 


The point is that, where it can be used, checksum neutrality is =
MORE GENERAL than L4 =
update.
 
 
how=
 do you define the "generality"? doing L4 update is a safe =
choice no matter if the addresses are checksum-neutral or not. =



 
 


Besides, but less important, it is simpler as far as the number of =
specifications it depends on is concerned (no need to know where =
checksum fields are for different =
protocols).
 


 
i =
understand Ole has the same opinion: as we anyway have it, =




There can be implementations of BRs that are independent of =
single translation.
They don't need to know where checksums =
are placed in various protocols.
 



we don't need it in the address scheme =
standard

One can live with =
a standard less good than it could be but, since we are working for the =
future, let's make them as good as we can now.


In any case, this is no excuse to claim that, with checksum =
neutrality the following is not correct "BRs need no change =
for any new protocol having =
ports at their usual place and TCP-like =
checksum" (DCCP, SCTP if it would acce^t TCP-like checksum, any =
other.)


 =


 
i =
think making L4 checksum update is a safe choice for standard. once we =
have a new L4 protocol,
the BR surely need a =
change to check if this new protocol is a TCP-checksumed =
one.

1. A key, that probably =
hasn't been clarified enough so far (thanks for in fact raising =
it), is the following:
- With checksum neutrality, the BR =
DOESN'T NEED to know about UDP, TCP etc. (see R-22 (3) of the 4rd-U =
draft).

If, by mistake a remote host =
sends to a shared IPv4 address a packet whose L4 payload has =
no ports at their usual places, the packet, if it reaches a CE, will =
ALWAYS be  discarded there (protocol unknown by the =
NAT44) =3D> no operational =
problem. 

This is one more instance where =
it isn't useful to try and guess what mistakes people might make, and to =
add specific software for them while tools already exist to detect and =
signal them. (Keep it =
simple)

OK?


 at least the =
BR's code should include the new protocol number in to =
the list of checksum-neutrality-compatible. =


See above.

A better BR needs =
also to check the packet integrity with ensuring that the =
checksum is correct and there a L4 activity is not =
avoidable.

2. A less good BR =
in my understanding: more processing for no appreciable =
gain.

 therefore i do agree with Ole's =
argument.

if i make anything incorrect, please point =
out. 

See =
above.

Cheers,
RD

<=
div>


 
best,
maoke


 (but it could be a recommendation for the =
operators to enable the address-level checksum neutrality, =



What remains to be seen is what is gained by not having it a MUST while =
we are specifying a new standard for a new =
problem.

Cheers,
RD



put in either prefix or interface id, =
through the address assignment, in order to help any L4 protocol when =
its TCP-flavor checksum rewrite happens not to be =
considered/implemented). 

=


cheers,
maoke
=





=

--Apple-Mail-13-887771346--

From fibrib@gmail.com  Tue Feb 14 18:15:25 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CE721F8574 for ; Tue, 14 Feb 2012 18:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.984
X-Spam-Level: 
X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox0ilaklS-ho for ; Tue, 14 Feb 2012 18:15:24 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 458E321F8573 for ; Tue, 14 Feb 2012 18:15:24 -0800 (PST)
Received: by qafi29 with SMTP id i29so2652144qaf.10 for ; Tue, 14 Feb 2012 18:15:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zfwUd34d1R6Ou5vjxmUWQJl/MIy+awV8Ekq0MD3B64o=; b=QCuGXBGRgJg4mYBxtwVhS6/8jJHC7UP+xDnVwIECXL5MTocWh8aGaw7d+c2dEEMZe+ QrEjjeSZdEQ9DHNpRXJhnK8AFGQSNgX4gjRHICPcjiV8Xj3aHB/yKG4dcy3ZjtWN0wzc zDHUhQwEfTqpT3MGo+TTQo30TpD8rB42pMndE=
MIME-Version: 1.0
Received: by 10.229.137.76 with SMTP id v12mr14082800qct.61.1329272122788; Tue, 14 Feb 2012 18:15:22 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Tue, 14 Feb 2012 18:15:22 -0800 (PST)
In-Reply-To: <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>
Date: Wed, 15 Feb 2012 11:15:22 +0900
Message-ID: 
From: Maoke 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=00235452ea70b04b9304b8f748a1
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 02:15:26 -0000

--00235452ea70b04b9304b8f748a1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/2/15 R=E9mi Despr=E9s 

>
> Le 2012-02-14 =E0 16:21, Maoke a =E9crit :
>
>
>
> 2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net
>
>>
>>
>  2) in the environment where single translation is also envolved (either
>> stateless or stateful), L4 checksum rewriting is a MUST because sometime=
s
>> there is only one address of the (src, dst)-pair following the
>> checksum-neutral address scheme. (this is mentioned in RFC6052, giving u=
p
>> to enforce the checksum-neutrality in the address format, to my knowledg=
e).
>>
>>
>> I have aways acknowledged that L4 update is necessary for single
>> translation, no disagreement.
>> But here the problem is stateless IPv4 service across IPv6, a different
>> problem where there is no such necessity.
>>
>>
>
> RFC6052 includes also the double-translation case. i guess operators
> wouldn't like to deploy different translators here for single translation
> while there for double.
>
>
>>
>> The point is that, where it can be used, checksum neutrality is MORE
>> GENERAL than L4 update.
>>
>>
>
> how do you define the "generality"? doing L4 update is a safe choice no
> matter if the addresses are checksum-neutral or not.
>
>
>>
>> Besides, but less important, it is simpler as far as the number of
>> specifications it depends on is concerned (no need to know where checksu=
m
>> fields are for different protocols).
>>
>>
>
>>
>> i understand Ole has the same opinion: as we anyway have it,
>>
>>
>> There can be implementations of BRs that are independent of single
>> translation.
>> They don't need to know where checksums are placed in various protocols.
>>
>>
>> we don't need it in the address scheme standard
>>
>>
>> One can live with a standard less good than it could be but, since we ar=
e
>> working for the future, let's make them as good as we can now.
>> In any case, this is no excuse to claim that, with checksum neutrality
>> the following is not correct "BRs need no change for any new protocol
>> having ports at their usual place and TCP-like checksum" (DCCP, SCTP if
>> it would acce^t TCP-like checksum, any other.)
>>
>>
> i think making L4 checksum update is a safe choice for standard. once we
> have a new L4 protocol,
>
> the BR surely need a change to check if this new protocol is a
> TCP-checksumed one.
>
>
> 1. A key, that probably hasn't been clarified enough so far (thanks for i=
n
> fact raising it), is the following:
> - With checksum neutrality, the BR DOESN'T NEED to know about UDP, TCP
> etc. (see R-22 (3) of the 4rd-U draft).
>
> If, by mistake a remote host sends to a shared IPv4 address a packet whos=
e
> L4 payload has no ports at their usual places, the packet, if it reaches =
a
> CE, will ALWAYS be  discarded there (protocol unknown by the NAT44) =3D> =
no
> operational problem.
>

MAP should also works for the case where IPv4 addresses are not shared and
there is no NAT44. "protocol unknown" should be detected and discarded at
both CE and BR in their major module instead of the NAT44 part.


>
> This is one more instance where it isn't useful to try and guess what
> mistakes people might make, and to add specific software for them while
> tools already exist to detect and signal them. (Keep it simple)
>

1. as the above, MAP should not depend upon NAT44.

2. on the other hand, even the NAT44 works in front of CE, there is no
NAT44 works between BR and a remote host (not belonging to the MAP domain).
the assumption of "NAT44 discards unknown protocol" only available in the
case where communication is initialized by a client in the CE-delegated
network. be more clarified:

    host.A --- NAT44 --- CE ---- IPv6 domain ---- BR --- IPv4 Internet ---
host.B

(a) A initiates connection to B =3D> ok, that the NAT44 checks protocol
unknown.
(b) B initiates connection to A =3D> BR has to check if L4 protocol is
supported or not.
(c) A initiates communication to B through a UDP or TCP signaling channel
while B reply a connection request on another channel over a new L4
protocol =3D> BR has to check if the new L4 protocol is supported or not.

and in the case of (c), R-22 (3)'s processing looks dangerous -- blindly
deciding where the port is located without looking at the L4 protocol
layout narrows the applicability of the proposal.

however, surely it is not a problem if you state the scope of applicability
of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS BEEN KNOWN
(known by the BR/CE rather than human) as having the same header layout as
well as the same checksum algorithm (without variation).

i don't think MAP standard have nor should have such a limitation. A
MAP-compliant device supports UDP, TCP, DCCP, SCTP today, with the same
logic, and will support any emerging L4 protocol in the future, again with
the same logic. requiring L4 checksum update for any supported protocol
makes it a stable standard, and the checksum update logic is stable for any
protocol. in 4rd-U, however, with the R-22 (3), today it can support UDP,
TCP, DCCP and SCTP-variant(? not sure due to lack of personal knowledge),
while if tomorrow we have a new protocol XXXP:
   a) XXXP has the same layout and same checksum logic, then the 4rd-U
compliant BR should be changed in order it knows that XXXP is also
supported and the logic R-22 (3) is still available;
   b) XXXP is different, then 4rd-U compliant BR should be changed in order
it knows that XXXP is now supported but different logic should be applied.

in either a) and b), the BR should be changed otherwise the XXXP will be
not supported. therefore i still think Ole's argument is not unfair here.

btw, regarding the below "new standard for a new problem", i'd like to
emphasize it is not a new problem as RFC6052 has discussed it. it is an
incorrect understanding to think RFC6052/RFC6145 is designed only for
single translation. since the very beginning of the stateless address
mapping/translation design, the single and double translations have being
considered.

- maoke


>
> OK?
>
>
> at least the BR's code should include the new protocol number in to the
> list of checksum-neutrality-compatible.
>
>
> See above.
>
>
> A better BR needs also to check the packet integrity with ensuring that
> the checksum is correct and there a L4 activity is not avoidable.
>
>
> 2. A less good BR in my understanding: more processing for no appreciable
> gain.
>
>  therefore i do agree with Ole's argument.
>
>
> if i make anything incorrect, please point out.
>
>
> See above.
>
> Cheers,
> RD
>
>
>
> best,
> maoke
>
>>  (but it could be a recommendation for the operators to enable the
>> address-level checksum neutrality,
>>
>>
>> What remains to be seen is what is gained by not having it a MUST while
>> we are specifying a new standard for a new problem.
>>
>> Cheers,
>> RD
>>
>> put in either prefix or interface id, through the address assignment, in
>> order to help any L4 protocol when its TCP-flavor checksum rewrite happe=
ns
>> not to be considered/implemented).
>>
>> cheers,
>> maoke
>>
>>
>>
>
>

--00235452ea70b04b9304b8f748a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



2012/2/15 R=E9mi Despr=E9s <despres.remi@laposte.n=
et>



Le 2012-02-14 =E0 16:21, =
Maoke a =E9crit :


=

2012/2/14 R=E9mi Despr=E9s despres.remi=
@laposte.net




=A0
=






2) in the environment where single translation is also envolved (eithe=
r stateless or stateful), L4 checksum rewriting is a MUST because sometimes=
 there is only one address of the (src, dst)-pair following the checksum-ne=
utral address scheme. (this is mentioned in RFC6052, giving up to enforce t=
he checksum-neutrality in the address format, to my knowledge).




I have aways acknowledged that L4 u=
pdate is necessary for single translation, no disagreement.
But h=
ere the problem is stateless IPv4 service across IPv6, a different problem =
where there is no such necessity.



=A0
=A0
RFC6052 includes also t=
he double-translation case. i guess operators wouldn't like to deploy d=
ifferent translators here for single translation while there for double. 


=A0
=A0=




The point is that, where it can be used, checksum neutrality is MORE G=
ENERAL than L4 update.
=A0
=A0
=

how do you define the "generality"? doing L4 update is=A0a s=
afe choice=A0no matter if the addresses are checksum-neutral or not. 



=A0
=A0=




Besides, but less important, it is simpler as far as the number of spe=
cifications it depends on is concerned (no need to know where checksum fiel=
ds are for different protocols).
=A0



=A0
i understand Ole has the same op=
inion: as we anyway have it, 



There can be implementations of BRs that are independent of sing=
le translation.
They don't need to know where checksums are p=
laced in various protocols.
=A0




we don't need it in the address scheme =
standard

One can live with a s=
tandard less good than it could be but, since we are working for the future=
, let's make them as good as we can now.



In any case, this is no excuse to claim that, with checksum neutrality=
 the following is not correct "BRs need no change for any new protocol having ports at their us=
ual place=
 and TCP-like checksum" (DCCP, SCTP if it would acce^t TCP-like checks=
um, any other.)



 

=A0
i think =
making L4 checksum update is a safe choice for standard. once we have a new=
 L4=A0protocol,


the BR surely need a change to=A0check if this new protocol is a TCP-chec=
ksumed one.

1. A key, tha=
t probably hasn't been clarified enough so far=A0(thanks for in fact ra=
ising it), is the following:


- With checksum neutrality, the BR DOESN'T NEED to know about UDP,=
 TCP etc. (see R-22 (3) of the 4rd-U draft).

If, b=
y mistake a remote host sends=A0to a shared IPv4 address=A0a packet whose L=
4 payload has no ports at their usual places, the packet, if it reaches a C=
E, will ALWAYS be =A0discarded there (protocol unknown by the NAT44)=A0=3D&=
gt; no operational problem.=A0



MAP should also works for the =
case where IPv4 addresses are not shared and there is no NAT44. "proto=
col unknown" should be detected and discarded at both CE and BR in the=
ir major module instead of the NAT44 part. 


=A0

This is one more instance where it isn't=
 useful to try and guess what mistakes people might make, and to add specif=
ic software for them while tools already exist to detect and signal them. (=
Keep it simple)



1. as the above, MAP should no=
t depend upon NAT44. 

2. on the other hand, even t=
he NAT44 works in front of CE, there is no NAT44 works between BR and a rem=
ote host (not belonging to the MAP domain). the assumption of "NAT44 d=
iscards unknown protocol" only available in the case where communicati=
on is initialized by a client in the CE-delegated network. be more clarifie=
d:=A0



=A0 =A0 host.A --- NAT44 --- CE ---- IPv6 domain ---- B=
R --- IPv4 Internet --- host.B=A0

(a) A initiates =
connection to B =3D> ok, that the NAT44 checks protocol unknown.=A0

(b) B initiates connection to A =3D> BR has to check if L4 protocol is s=
upported or not.=A0
(c) A initiates communication to B through a =
UDP or TCP signaling channel while B reply a connection request on another =
channel over a new L4 protocol =3D> BR has to check if the new L4 protoc=
ol is supported or not.=A0



and in the case of (c), R-22 (3)'s processing looks=
 dangerous -- blindly deciding where the port is located without looking at=
 the L4 protocol layout narrows the applicability of the proposal.



however, surely it is not a problem if you state t=
he scope of applicability of 4rd-U is LIMITED to UDP, TCP and L4 protocols =
which HAS BEEN KNOWN (known by the BR/CE rather than human) as having the s=
ame header layout as well as the same checksum algorithm (without variation=
).=A0



i don't think MAP standard have nor should have suc=
h a limitation. A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,=
 with the same logic, and will support any emerging L4 protocol in the futu=
re, again with the same logic. requiring L4 checksum update for any support=
ed protocol makes it a stable standard, and the checksum update logic is st=
able for any protocol. in 4rd-U, however, with the R-22 (3), today it can s=
upport UDP, TCP, DCCP and SCTP-variant(? not sure due to lack of personal k=
nowledge), while if tomorrow we have a new protocol XXXP:


=A0 =A0a) XXXP has the same layout and same checksum logic, then the 4=
rd-U compliant BR should be changed in order it knows that XXXP is also sup=
ported and the logic R-22 (3) is still available;=A0
=A0 =A0b) XX=
XP is different, then 4rd-U compliant BR should be changed in order it know=
s that XXXP is now supported but different logic should be applied.=A0


in either a) and b), the BR should be changed otherwise=
 the XXXP will be not supported. therefore i still think Ole's argument=
 is not unfair here.=A0

btw, regarding the below &=
quot;new standard for a new problem", i'd like to emphasize it is =
not a new problem as RFC6052 has discussed it. it is an incorrect understan=
ding to think RFC6052/RFC6145 is designed only for single translation. sinc=
e the very beginning of the stateless address mapping/translation design, t=
he single and double translations have being considered.=A0



- maoke
=A0

OK?



<=
div class=3D"gmail_quote">
 at least the BR's code should=A0include=
=A0the new=A0protocol number in to the list of checksum-neutrality-compatib=
le. 



See above.

A=A0better BR ne=
eds also to check the packet=A0integrity=A0with ensuring that the checksum=
=A0is correct=A0and=A0there a L4 activity is not avoidable.



2. A less good BR in my unders=
tanding: more processing for no appreciable gain.
=A0therefore i =
do agree with Ole's argument.



if i make anything incorrect, please point out. 

See above.

Cheers,
<=
div>
RD




=A0
best,
maoke



 (but i=
t could be a recommendation for the operators to enable the address-level c=
hecksum neutrality, 


What remains to be seen is what is gained by not having it a MUST while we =
are specifying a new standard for a new problem.

C=
heers,
RD



put in either prefix or interface id, throu=
gh the address assignment, in order to help any L4 protocol when its TCP-fl=
avor checksum rewrite happens not to be considered/implemented).=A0



cheers,
maoke
<=
br>







--00235452ea70b04b9304b8f748a1--

From fibrib@gmail.com  Tue Feb 14 23:38:37 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A0E21E8052 for ; Tue, 14 Feb 2012 23:38:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.411
X-Spam-Level: 
X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.187,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx5z8+t8xVcz for ; Tue, 14 Feb 2012 23:38:37 -0800 (PST)
Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D608021E8039 for ; Tue, 14 Feb 2012 23:38:36 -0800 (PST)
Received: by qan41 with SMTP id 41so768150qan.10 for ; Tue, 14 Feb 2012 23:38:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XTGW63DxamhoXyNmhrgope4bilzDEkSo0dHol7ylnRg=; b=YH5YQ7+1QvZbRbCwES47QN+PdvsWc+sizvzvhXQEXyl7XzsjOGdyHfyBOH9RV8QNfP 2z5biDbnbQDOlUEZdGFqq6GUAmq/FpleXDmoYiR/n9PvghWckIkPJdwc5SaBsQSBnAiF WEBQBMpVjZ43pfGA1Y/bxfNPFEXBsELgchfMA=
MIME-Version: 1.0
Received: by 10.229.77.12 with SMTP id e12mr14776020qck.41.1329291516259; Tue, 14 Feb 2012 23:38:36 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Tue, 14 Feb 2012 23:38:36 -0800 (PST)
In-Reply-To: 
References: 
Date: Wed, 15 Feb 2012 16:38:36 +0900
Message-ID: 
From: Maoke 
To: Qiong 
Content-Type: multipart/alternative; boundary=00235429e11ca12faa04b8fbcc48
Cc: softwires@ietf.org
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 07:38:37 -0000

--00235429e11ca12faa04b8fbcc48
Content-Type: text/plain; charset=ISO-8859-1

sp. the merged document meets the requirements where flexible dynamic IPv4
address sharing in IPv6 domain and meanwhile 1) considerably reduces the
states that the AFTR needs to handle; 2) reduces the overload of AFTR
through distributing the NAT functionality over Initiators.

i think the document is ready for WG adoption.

a further discussion is: DS-Lite (RFC6333) states some limitations related
to the potentially high burden of AFTR. as i understand, there are at least
two:
1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is
required to reassembly before the decapsulation. DS-Lite states because of
the high buffer requirements, AFTR doesn't do the reassembly but only B4 do
that. it is reasonable in the case of client/server communications where
large datagrams happen often in the inbound. however, it implies that
DS-Lite is not very suitable for the p2p communications where outbound
datagram might be large as well.
2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite AFTR
doesn't do ALG for any applications. thus some applications might be
impacted.

my question is: can lightweight 4over6 improve 1) and 2) because the AFTR
load has been enlighted? if so, i suggest the author to state the
improvement of releasing the limitations.

regards,
maoke

2012/2/5 Qiong 

> Dear all,
>
> We have published a merged version of lightweight 4over6 in:
>
> http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt.
>
>
> This mechanism moves the translation function from the tunnel concentrator
> (AFTR) to initiators (B4s), and hence reduces the mapping scale on the
> concentrator to per-subscriber level.
>
> It has got wilely support in the last Taipei IETF meeting, and the only
> action we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
> and I-D.zhou-softwire-b4-nat into one draft.
>
> Now that the merge work has done, from the authors of this document's
> view, it is ready to be adopted as working group document. We would be
> appreciated to have your comments.
>
> Thanks in advance !
>
> Best wishes
>
> Qiong
>
>
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>

--00235429e11ca12faa04b8fbcc48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


sp. the merged document meets the requirements where flexible dynamic =
IPv4 address sharing in IPv6 domain and meanwhile 1) considerably reduces t=
he states that the AFTR needs to handle; 2) reduces the overload of AFTR th=
rough distributing the NAT functionality over Initiators.=A0



i think the document is ready for WG adoption.=A0
=


a further discussion is: DS-Lite (RFC6333) states some =
limitations related to the potentially high burden of AFTR. as i understand=
, there are at least two:


1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is=
 required to reassembly before the decapsulation. DS-Lite states because of=
 the high buffer requirements, AFTR doesn't do the reassembly but only =
B4 do that. it is reasonable in the case of client/server communications wh=
ere large datagrams happen often in the inbound. however, it implies that D=
S-Lite is not very suitable for the p2p communications where outbound datag=
ram might be large as well.=A0


2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite A=
FTR doesn't do ALG for any applications. thus some applications might b=
e impacted.=A0

my question is: can lightweight 4ov=
er6 improve 1) and 2) because the AFTR load has been enlighted? if so, i su=
ggest the author to state the improvement of releasing the limitations.=A0<=
/div>


regards,
maoke

2012/2/5 Qiong <bingxuere@gmail.com>

Dear all,

We have published a merged version of lightweight 4over6 i=
n: 
http://www.ietf.org/internet-=
drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt. 




This mechanism moves the translation function from the tunnel concentra=
tor (AFTR) to initiators (B4s), and hence reduces the mapping scale on the =
concentrator to per-subscriber level.  

It has got wilely support in=
 the last Taipei IETF meeting, and the only action we need to do is to merg=
e I-D.cui-softwire-b4-translated-ds-lite



and I-D.zhou-softwire-b4-nat into one draft.

Now that the merge work=
 has done, from the authors of this document's view, it is ready to be =
adopted as working group document. We would be appreciated to have your com=
ments. 




Thanks in advance !

Best wishes

Q=
iong


=A0




_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires





--00235429e11ca12faa04b8fbcc48--

From despres.remi@laposte.net  Wed Feb 15 00:21:55 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9B21E803F for ; Wed, 15 Feb 2012 00:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.290,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvUPns11hJ2d for ; Wed, 15 Feb 2012 00:21:55 -0800 (PST)
Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCA221E801C for ; Wed, 15 Feb 2012 00:21:51 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id a8Mp1i00137Y3f4038MpSS; Wed, 15 Feb 2012 09:21:50 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Wed, 15 Feb 2012 09:21:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7439AE2C-97DF-4B09-99F7-B90EFDEC99E6@laposte.net>
References:  
To: Qiong Sun 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 08:21:55 -0000

2012-02-15 =E0 08:38, Maoke :

> sp. the merged document meets the requirements where flexible dynamic =
IPv4 address sharing in IPv6 domain and meanwhile 1) considerably =
reduces the states that the AFTR needs to handle; 2) reduces the =
overload of AFTR through distributing the NAT functionality over =
Initiators.=20
>=20
> i think the document is ready for WG adoption.=20

Because Lightweight 4over6 permits AFTRs to be stateful per customer but =
stateless per flow, it fills a gap between DS-lite (whose AFTRs are =
stateful per flow) and currently discussed solutions that are stateless =
per customer (MAP-T, MAP-E, 4rd-U ).=20

=3D> +1

RD



From washam.fan@gmail.com  Wed Feb 15 05:34:18 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE521F8674 for ; Wed, 15 Feb 2012 05:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7INywusNncd for ; Wed, 15 Feb 2012 05:34:17 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7ADA21F8650 for ; Wed, 15 Feb 2012 05:34:11 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so652426wib.31 for ; Wed, 15 Feb 2012 05:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2SlaPNz/w0nb4PTjPXIgTtpGyRZpHuBmDPEEiJH5LyA=; b=Dd7Y0kJQzqMxdS1o4Rq9jCy7/zKdYz4VK+PIAMkCBFQNHup+Lb986kO0SPqP3U0bua 3q03He/CJTOGF+y11t0PQTIb3RMYxm5sZmm0+eNxNzaz6R8Z4Jz/aK84YPWvg88RzNtN tdUbyaPH9VHHC+RJJKjingjsQnUiMlAekHyVk=
MIME-Version: 1.0
Received: by 10.216.133.204 with SMTP id q54mr2665024wei.2.1329312850693; Wed, 15 Feb 2012 05:34:10 -0800 (PST)
Received: by 10.216.1.6 with HTTP; Wed, 15 Feb 2012 05:34:10 -0800 (PST)
In-Reply-To: 
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net> 
Date: Wed, 15 Feb 2012 21:34:10 +0800
Message-ID: 
From: Washam Fan 
To: Maoke 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 13:34:18 -0000

Hi Maoke,

Just one point. Please see inline.

> i don't think MAP standard have nor should have such a limitation. A
> MAP-compliant device supports UDP, TCP, DCCP, SCTP today, with the same
> logic, and will support any emerging L4 protocol in the future, again with
> the same logic. requiring L4 checksum update for any supported protocol
> makes it a stable standard, and the checksum update logic is stable for any
> protocol. in 4rd-U, however, with the R-22 (3), today it can support UDP,
> TCP, DCCP and SCTP-variant(? not sure due to lack of personal knowledge),
> while if tomorrow we have a new protocol XXXP:

Please keep in mind both MAP and 4rd-U are transition techniques, from
a long-term perspective, they might disappear before any new L4
protocol invented;)

washam

From despres.remi@laposte.net  Wed Feb 15 06:45:29 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B7121E803A for ; Wed, 15 Feb 2012 06:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.716
X-Spam-Level: 
X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUz2njlT2mfn for ; Wed, 15 Feb 2012 06:45:27 -0800 (PST)
Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id EE9FE21E8025 for ; Wed, 15 Feb 2012 06:45:25 -0800 (PST)
Received: from [192.168.0.31] ([88.166.221.144]) by mwinf8507-out with ME id aElN1i00437Y3f403ElNtq; Wed, 15 Feb 2012 15:45:24 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-15-970087264
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Wed, 15 Feb 2012 15:45:21 +0100
Message-Id: <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net> 
To: Maoke 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 14:45:29 -0000

--Apple-Mail-15-970087264
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


2012-02-15 =E0 03:15, Maoke a =E9crit :

>=20
>=20
> 2012/2/15 R=E9mi Despr=E9s 
>=20
> Le 2012-02-14 =E0 16:21, Maoke a =E9crit :
>=20
>>=20
>>=20
>> 2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net
>> =20
>>> 2) in the environment where single translation is also envolved =
(either stateless or stateful), L4 checksum rewriting is a MUST because =
sometimes there is only one address of the (src, dst)-pair following the =
checksum-neutral address scheme. (this is mentioned in RFC6052, giving =
up to enforce the checksum-neutrality in the address format, to my =
knowledge).
>>=20
>> I have aways acknowledged that L4 update is necessary for single =
translation, no disagreement.
>> But here the problem is stateless IPv4 service across IPv6, a =
different problem where there is no such necessity.
>> =20
>> =20
>> RFC6052 includes also the double-translation case. i guess operators =
wouldn't like to deploy different translators here for single =
translation while there for double.
>> =20
>> =20
>> The point is that, where it can be used, checksum neutrality is MORE =
GENERAL than L4 update.
>> =20
>> =20
>> how do you define the "generality"? doing L4 update is a safe choice =
no matter if the addresses are checksum-neutral or not.
>> =20
>> =20
>> Besides, but less important, it is simpler as far as the number of =
specifications it depends on is concerned (no need to know where =
checksum fields are for different protocols).
>> =20
>> =20
>>> i understand Ole has the same opinion: as we anyway have it,
>>=20
>> There can be implementations of BRs that are independent of single =
translation.
>> They don't need to know where checksums are placed in various =
protocols.
>> =20
>>=20
>>> we don't need it in the address scheme standard
>>=20
>> One can live with a standard less good than it could be but, since we =
are working for the future, let's make them as good as we can now.
>> In any case, this is no excuse to claim that, with checksum =
neutrality the following is not correct "BRs need no change for any new =
protocol having ports at their usual place and TCP-like checksum" (DCCP, =
SCTP if it would acce^t TCP-like checksum, any other.)
>> =20
>>=20
>> =20
>> i think making L4 checksum update is a safe choice for standard. once =
we have a new L4 protocol,
>> the BR surely need a change to check if this new protocol is a =
TCP-checksumed one.
>=20
> 1. A key, that probably hasn't been clarified enough so far (thanks =
for in fact raising it), is the following:
> - With checksum neutrality, the BR DOESN'T NEED to know about UDP, TCP =
etc. (see R-22 (3) of the 4rd-U draft).
>=20
> If, by mistake a remote host sends to a shared IPv4 address a packet =
whose L4 payload has no ports at their usual places, the packet, if it =
reaches a CE, will ALWAYS be  discarded there (protocol unknown by the =
NAT44) =3D> no operational problem.=20
>=20
> MAP should also works for the case where IPv4 addresses are not shared =
and there is no NAT44.

Indeed, in particular for CEs that are assigned IPv4 prefixes.
So does 4rd-H, without identified problem.
=20
> "protocol unknown" should be detected and discarded at both CE and BR =
in their major module instead of the NAT44 part.

I don't think so:
- If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't =
exclude any protocol in packets sent to this CE.
- If a CE has a shared address, it needs a NAT that the CE informs it =
the restricted port set. This NAT already has all what is needed to =
refuse protocols it doesn't understand.=20

=20
> This is one more instance where it isn't useful to try and guess what =
mistakes people might make, and to add specific software for them while =
tools already exist to detect and signal them. (Keep it simple)
>=20
> 1. as the above, MAP should not depend upon NAT44.
>=20
> 2. on the other hand, even the NAT44 works in front of CE, there is no =
NAT44 works between BR and a remote host (not belonging to the MAP =
domain). the assumption of "NAT44 discards unknown protocol" only =
available in the case where communication is initialized by a client in =
the CE-delegated network. be more clarified:=20
>=20
>     host.A --- NAT44 --- CE ---- IPv6 domain ---- BR --- IPv4 Internet =
--- host.B=20
>=20
> (a) A initiates connection to B =3D> ok, that the NAT44 checks =
protocol unknown.=20
> (b) B initiates connection to A =3D> BR has to check if L4 protocol is =
supported or not.=20
> (c) A initiates communication to B through a UDP or TCP signaling =
channel while B reply a connection request on another channel over a new =
L4 protocol =3D> BR has to check if the new L4 protocol is supported or =
not.=20
>=20
> and in the case of (c), R-22 (3)'s processing looks dangerous -- =
blindly deciding where the port is located without looking at the L4 =
protocol layout narrows the applicability of the proposal.

Which danger?
On the contrary, avoiding that BRs depend on a list of L4 protocols =
enlarges their applicability.

> however, surely it is not a problem if you state the scope of =
applicability of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS =
BEEN KNOWN (known by the BR/CE rather than human) as having the same =
header layout as well as the same checksum algorithm (without =
variation).

I just say (and repeat) that, for shared-address CEs, 4rd-U BRs support =
WITHOUT MODIFICATION any L4 protocol that has ports at their usual place =
and a TCP-like checksum.=20

> i don't think MAP standard have nor should have such a limitation.

Which limitation?
On the contrary, checksum neutrality eliminates the need for a BR =
upgrade if a new protocol using conventional ports and TCP-like checksum =
is introduced.


> A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,

Not SCTP today, for sure.
Also, as I think you know, there is uncertainty concerning DCCP because =
RFC6145 sec 4.5 says:
"Other transport protocols (e.g., DCCP) are OPTIONAL to support".


> with the same logic, and will support any emerging L4 protocol in the =
future, again with the same logic. requiring L4 checksum update for any =
supported protocol makes it a stable standard, and the checksum update =
logic is stable for any protocol. in 4rd-U, however, with the R-22 (3), =
today it can support UDP, TCP, DCCP and SCTP-variant(? not sure due to =
lack of personal knowledge), while if tomorrow we have a new protocol =
XXXP:
>    a) XXXP has the same layout and same checksum logic, then the 4rd-U =
compliant BR should be changed in order it knows that XXXP is also =
supported and the logic R-22 (3) is still available;=20

Not AFAIK.
You can check that R-22 (3) does not depend on any L4 protocol (the only =
protocol that needs to be recognized is ICMP (a layer-3 protocol).

>    b) XXXP is different, then 4rd-U compliant BR should be changed in =
order it knows that XXXP is now supported but different logic should be =
applied.=20
>=20
> in either a) and b), the BR should be changed otherwise the XXXP will =
be not supported. therefore i still think Ole's argument is not unfair =
here.=20

Let me repeat once more:
If XXXP has (1) the same checksum algorithm, (2) the same port layout =
(like UDP, TCP, DCCP and SCTP do have), (3) a different layout for the =
checksum field (as is the case for UDP, TCP, DCCP, SCTP), THEN no new =
logic is needed in 4rd-H (because of its checksum neutrality).=20

I do hope this point will eventually be understood in the WG, rather =
repeatedly negated.

> btw, regarding the below "new standard for a new problem", i'd like to =
emphasize it is not a new problem as RFC6052 has discussed it. it is an =
incorrect understanding to think RFC6052/RFC6145 is designed only for =
single translation. since the very beginning of the stateless address =
mapping/translation design, the single and double translations have =
being considered.=20

I have no intention to negate anything about what designers of =
RFC6052/6145 considered (I wasn't there ;-)).

The problem which IS NEW is how to design a stateless v4/v6 solution =
that:
- is AS TRANSPARENT to IPv4 as encapsulation, without any restriction or =
doubt
- yet works with IPv6-only port-based ACLs and IPv6 Web caches.
In my understanding, 4rd-H is indeed such a solution (and is the only =
one on the table).
=20

Regards,
RD

PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a =
different subject which deserves a discussion thread with another title.

> ...

--Apple-Mail-15-970087264
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1




2012/2/15 R=E9mi Despr=E9s <despres.remi@laposte.net><=
/span>



Le 2012-02-14 =E0 =
16:21, Maoke a =E9crit :



2012/2/14 R=E9mi =
Despr=E9s despres.remi@laposte.net




 





2) in the environment where single translation is also envolved =
(either stateless or stateful), L4 checksum rewriting is a MUST because =
sometimes there is only one address of the (src, dst)-pair following the =
checksum-neutral address scheme. (this is mentioned in RFC6052, giving =
up to enforce the checksum-neutrality in the address format, to my =
knowledge).




I have aways acknowledged that =
L4 update is necessary for single translation, no =
disagreement.
But here the problem is stateless IPv4 service =
across IPv6, a different problem where there is no such necessity.



 
 
RFC6052 =
includes also the double-translation case. i guess operators wouldn't =
like to deploy different translators here for single translation while =
there for double. 



 
 



The point is that, where it can be used, checksum neutrality is =
MORE GENERAL than L4 =
update.
 
 
how=
 do you define the "generality"? doing L4 update is a safe =
choice no matter if the addresses are checksum-neutral or not. =




 
 



Besides, but less important, it is simpler as far as the number of =
specifications it depends on is concerned (no need to know where =
checksum fields are for different =
protocols).
 



 
i understand Ole has the =
same opinion: as we anyway have it, =




There can be implementations of BRs that are independent of =
single translation.
They don't need to know where checksums =
are placed in various =
protocols.
 




we don't need it in the address scheme =
standard

One can live with =
a standard less good than it could be but, since we are working for the =
future, let's make them as good as we can now.



In any case, this is no excuse to claim that, with checksum =
neutrality the following is not correct "BRs need no change =
for any new protocol having =
ports at their usual place and TCP-like =
checksum" (DCCP, SCTP if it would acce^t TCP-like checksum, any =
other.)



 =


 
i think making L4 checksum update is a safe choice for standard. =
once we have a new L4 protocol,


the BR surely need a change to check if =
this new protocol is a TCP-checksumed =
one.

1. A key, that =
probably hasn't been clarified enough so far (thanks for in fact =
raising it), is the following:


- With checksum neutrality, the BR DOESN'T NEED to know about UDP, =
TCP etc. (see R-22 (3) of the 4rd-U draft).

If, =
by mistake a remote host sends to a shared IPv4 address a =
packet whose L4 payload has no ports at their usual places, the packet, =
if it reaches a CE, will ALWAYS be  discarded there (protocol =
unknown by the NAT44) =3D> no operational problem. 



MAP should also works for =
the case where IPv4 addresses are not shared and there is no NAT44. =


Indeed, in particular for CEs =
that are assigned IPv4 prefixes.
So does 4rd-H, without =
identified problem.
 
"protocol unknown" should be detected and =
discarded at both CE and BR in their major module instead of the NAT44 =
part. 

I don't think =
so:
- If a CE has a non-shared address, or an IPv4 prefix, BRs =
shouldn't exclude any protocol in packets sent to this CE.
- =
If a CE has a shared address, it needs a NAT that the CE informs it the =
restricted port set. This NAT already has all what is needed to refuse =
protocols it doesn't =
understand. 

 


This is one more =
instance where it isn't useful to try and guess what mistakes people =
might make, and to add specific software for them while tools already =
exist to detect and signal them. (Keep it simple)



1. as the above, MAP should =
not depend upon NAT44. 

2. on the other hand, =
even the NAT44 works in front of CE, there is no NAT44 works between BR =
and a remote host (not belonging to the MAP domain). the assumption of =
"NAT44 discards unknown protocol" only available in the case where =
communication is initialized by a client in the CE-delegated network. be =
more clarified: 



    host.A --- NAT44 --- CE ---- IPv6 =
domain ---- BR --- IPv4 Internet --- =
host.B 

(a) A initiates connection to B =
=3D> ok, that the NAT44 checks protocol unknown. 

(b) B initiates connection to A =3D> BR has to check if L4 protocol =
is supported or not. 
(c) A initiates communication to B =
through a UDP or TCP signaling channel while B reply a connection =
request on another channel over a new L4 protocol =3D> BR has to =
check if the new L4 protocol is supported or not. 



and in the case of (c), R-22 (3)'s processing looks =
dangerous -- blindly deciding where the port is located without looking =
at the L4 protocol layout narrows the applicability of the =
proposal.

Which =
danger?
On the contrary, avoiding that BRs depend on a list of =
L4 protocols enlarges their =
applicability.

however, surely it is not a problem if =
you state the scope of applicability of 4rd-U is LIMITED to UDP, TCP and =
L4 protocols which HAS BEEN KNOWN (known by the BR/CE rather than human) =
as having the same header layout as well as the same checksum algorithm =
(without variation).

I just =
say (and repeat) that, for shared-address CEs, 4rd-U BRs =
support WITHOUT MODIFICATION any L4 protocol that has ports at =
their usual place and a TCP-like =
checksum. 

i don't think MAP standard have nor =
should have such a =
limitation.

Which =
limitation?
On the contrary, checksum neutrality eliminates =
the need for a BR upgrade if a new protocol using conventional ports and =
TCP-like checksum is introduced.


 A MAP-compliant =
device supports UDP, TCP, DCCP, SCTP =
today,

Not SCTP today, for =
sure.
Also, as I think you know, there is uncertainty =
concerning DCCP because RFC6145 sec 4.5 says:
"Other transport protocols (e.g., DCCP) are OPTIONAL to =
support".


 with the same logic, =
and will support any emerging L4 protocol in the future, again with the =
same logic. requiring L4 checksum update for any supported protocol =
makes it a stable standard, and the checksum update logic is stable for =
any protocol. in 4rd-U, however, with the R-22 (3), today it can support =
UDP, TCP, DCCP and SCTP-variant(? not sure due to lack of personal =
knowledge), while if tomorrow we have a new protocol XXXP:


   a) XXXP has the same layout and same checksum logic, =
then the 4rd-U compliant BR should be changed in order it knows that =
XXXP is also supported and the logic R-22 (3) is still =
available; 

Not =
AFAIK.
You can check that R-22 (3) does not depend on any L4 =
protocol (the only protocol that needs to be recognized is ICMP (a =
layer-3 protocol).

   b) XXXP is different, then =
4rd-U compliant BR should be changed in order it knows that XXXP is now =
supported but different logic should be applied. 



in either a) and b), the BR should be changed =
otherwise the XXXP will be not supported. therefore i still think Ole's =
argument is not unfair =
here. 

Let me =
repeat once more:
If XXXP has (1) the same checksum algorithm, =
(2) the same port layout (like UDP, TCP, DCCP and SCTP do have), (3) a =
different layout for the checksum field (as is the case for UDP, TCP, =
DCCP, SCTP), THEN no new logic is needed in 4rd-H (because of its =
checksum neutrality). 

I do hope this =
point will eventually be understood in the WG, rather repeatedly =
negated.

btw, regarding the below "new standard =
for a new problem", i'd like to emphasize it is not a new problem as =
RFC6052 has discussed it. it is an incorrect understanding to think =
RFC6052/RFC6145 is designed only for single translation. since the very =
beginning of the stateless address mapping/translation design, the =
single and double translations have being =
considered. 

I have no =
intention to negate anything about what designers of =
RFC6052/6145 considered (I wasn't there =
;-)).

The problem which IS NEW is how to design =
a stateless v4/v6 solution that:
- is AS TRANSPARENT to =
IPv4 as encapsulation, without any restriction or doubt
- yet =
works with IPv6-only port-based ACLs and IPv6 Web caches.
In =
my understanding, 4rd-H is indeed such a solution (and is the only one =
on the =
table).
 

Regards,
RD

PS: Relationship of 4rd-U with single =
translation XLATs of RFC6145 is a different subject which deserves a =
discussion thread with another =
title.



...
=

--Apple-Mail-15-970087264--

From buptnoc@gmail.com  Wed Feb 15 08:02:57 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A2E21F854C for ; Wed, 15 Feb 2012 08:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.257
X-Spam-Level: 
X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtxlC7fc6LKK for ; Wed, 15 Feb 2012 08:02:56 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C895521F8715 for ; Wed, 15 Feb 2012 08:02:55 -0800 (PST)
Received: by iagf6 with SMTP id f6so1924074iag.31 for ; Wed, 15 Feb 2012 08:02:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UZApnf0l2skLs7nWKQcVrpbJTTO54LtPAl1kD3lD5/w=; b=X0GVimvGbP/lG3CNYyUyvAprmN1nwGI5g/2/vm88zi3J+V+6NoPuWLoFis+Gc+QDFM x0f0tB2pm1J4m4B3Ni7ooKbuJG7wP4EULhUndF/SuJfwMFm9zxN4os+e87/9reSCdkQB Gx+8g1+vd/g/ylmNXAodWzDTRzBaZxbIfyVCk=
Received: by 10.42.156.7 with SMTP id x7mr34735946icw.56.1329321775493; Wed, 15 Feb 2012 08:02:55 -0800 (PST)
Received: from [210.25.132.132] ([210.25.132.132]) by mx.google.com with ESMTPS id va6sm25584551igc.4.2012.02.15.08.02.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 08:02:54 -0800 (PST)
Message-ID: <4F3BD72A.4000609@gmail.com>
Date: Thu, 16 Feb 2012 00:02:50 +0800
From: buptnoc 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: softwires@ietf.org
References: 
In-Reply-To: 
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 16:02:57 -0000


  
    
  
  
    sp.

      The merged version of lightweight 4over6 is ready for WG adoption.
      

    

    zhaoqin

    BUPT

    

    于 2012-2-4 23:40, Qiong 写é“:
    
Dear all,

      

      We have published a merged version of lightweight 4over6 in: 

      http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt.
      

      

      This mechanism moves the translation function from the tunnel
      concentrator (AFTR) to initiators (B4s), and hence reduces the
      mapping scale on the concentrator to per-subscriber level. 

      

      It has got wilely support in the last Taipei IETF meeting, and the
      only action we need to do is to merge
      I-D.cui-softwire-b4-translated-ds-lite

      and I-D.zhou-softwire-b4-nat into one draft.

      

      Now that the merge work has done, from the authors of this
      document's view, it is ready to be adopted as working group
      document. We would be appreciated to have your comments. 

      

      Thanks in advance !

      

      Best wishes

      

      Qiong

      

      

       

      

      

      

      

      

      
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


    

  


From despres.remi@laposte.net  Wed Feb 15 09:07:33 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7596E21F851A for ; Wed, 15 Feb 2012 09:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level: 
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeOicBa7zNS6 for ; Wed, 15 Feb 2012 09:07:33 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 9D25621F8518 for ; Wed, 15 Feb 2012 09:07:30 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6A9AC94024D; Wed, 15 Feb 2012 18:07:22 +0100 (CET)
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Feb 2012 18:07:20 +0100
Message-Id: 
To: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 17:07:33 -0000

Hi Ole,

1.
Your comments about the following feature-comparison item have been:
- "possible with MAP-{E,T} too, but may require coordination of subnet =
numbering."
- "I don't see the point of having text in the specification for this =
use case. it is a deployment option."

  +----+--------------------------------------+-----+-----+-----+-----+
  |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
  |    |                                      |  -T |  -E |  -H |  -E |
  +----+--------------------------------------+-----+-----+-----+-----+
...
  |    |                                      |     |     |     |     |
  |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
  |    | third-party CPEs                     |     |     |     |     |

But, AFAIK, it is not possible to configure a MAP domain for CEs =
attached to third-party CPEs (ref. use case 5.2.2 of the 4rd-U draft).

2.
To deal with some similar use cases, we had an optional Suffix parameter =
of Mapping rules in draft draft-despres-intarea-4rd-01 (of which =
co-authors were R. Despr=E9s, S. Matsushima, T. Murakami, ... and =
yourself).

Having not seen in the WG that the need had disappeared, nor that =
another way to satisfy the need had been discussed, I did include the =
Suffix parameter in 4rd-U.

3.
A somewhat detailed explanation about this need, received in the past =
and IMHO clarifying, was something like this:

"For the instance, in Japan, NTT provides the access line to the =
end-users and ISPs provides the internet service over this access line. =
Sometimes, NTT CPE is located in front of the ISP's 4rd CE. Sometimes, =
only the ISP's 4rd CE is located at home as shown below.

---- NTT CPE ---- ISP CE ----

---- ISP CE --

It depends on the end-users' contract. If the end-user is getting some =
services from NTT, the NTT CPE is located at home and the ISP CE is =
located behind the NTT CE. If the end-user is not getting such a =
service, only ISP CE is located at home.

In both cases, the IPv6 network infrastructure assigns an IPv6 prefix to =
the customer site. If present, the NTT CPE receives an IPv6 prefix and =
then delegates a longer IPv6 prefix to the ISP CE. For example, a /48 =
IPv6 prefix is assigned to the NTT CPE, and the NTT CPE delegates a /52 =
after adding a 4bit suffix to the ISP CE. But in other cases, if the ISP =
CE is directly connected to the IPv6 network infrastructure, the ISP CE =
can get an IPv6 prefix without any suffix.

So, in one 4rd domain, some ISP CEs get shorter IPv6 prefixes directly =
from the IPv6 network (say /48) and some other ISP CEs get longer IPv6 =
prefixes from NTT CPEs (say /52). This means that the delegated IPv6 =
prefix consists of the Domain IPv6 prefix followed by EA bits, if the =
ISP CE is directly connected to the IPv6 network, and that the delegated =
prefix consists of the Domain IPv6 prefix, followed by EA bits, and =
followed by the added suffix if the ISP CE is connected to another CE."


4.
Without a suffix parameter in mapping rules that applies to CEs behind a =
third-party CPEs, CPE added suffixes would be included in EA bits. They =
would therefore be present as lower parts of PSIDs of CE that have =
shared IPv4 addresses.=20
I don't see how this could work.=20

5.
Of course, the suffix parameter can be added to MAP if decided (no =
problem with that), but the feature comparison table remains based on =
existing drafts.


Hoping this clarifies this issue, I welcome questions and comments from =
anyone in the WG, in particular from the MAP design team.
Regards,
RD




From despres.remi@laposte.net  Wed Feb 15 09:12:59 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0D321F86F6 for ; Wed, 15 Feb 2012 09:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.841
X-Spam-Level: 
X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqZ370fdgG0n for ; Wed, 15 Feb 2012 09:12:59 -0800 (PST)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id A281221F8468 for ; Wed, 15 Feb 2012 09:12:58 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 4EA897000094; Wed, 15 Feb 2012 18:12:57 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id D96B47000083; Wed, 15 Feb 2012 18:12:56 +0100 (CET)
X-SFR-UUID: 20120215171256890.D96B47000083@msfrf2319.sfr.fr
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Feb 2012 18:12:55 +0100
Message-Id: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>
To: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
Cc: Softwires WG 
Subject: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 17:12:59 -0000

Hi Ole,

1.
Your comments about the following feature-comparison item have been:
- "possible with MAP-{E,T} too, but may require coordination of subnet =
numbering."
- "I don't see the point of having text in the specification for this =
use case. it is a deployment option."

 +----+--------------------------------------+-----+-----+-----+-----+
 |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
 |    |                                      |  -T |  -E |  -H |  -E |
 +----+--------------------------------------+-----+-----+-----+-----+
...
 |    |                                      |     |     |     |     |
 |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
 |    | third-party CPEs                     |     |     |     |     |

But, AFAIK, it is not possible to configure a MAP domain for CEs =
attached to third-party CPEs (ref. use case 5.2.2 of the 4rd-U draft).

2.
To deal with some similar use cases, we had an optional Suffix parameter =
of Mapping rules in draft draft-despres-intarea-4rd-01 (of which =
co-authors were R. Despr=E9s, S. Matsushima, T. Murakami, ... and =
yourself).

Having not seen in the WG that the need had disappeared, nor that =
another way to satisfy the need had been discussed, I did include the =
Suffix parameter in 4rd-U.

3.
A somewhat detailed explanation about this need, received in the past =
and IMHO clarifying, was something like this:

"For the instance, in Japan, NTT provides the access line to the =
end-users and ISPs provides the internet service over this access line. =
Sometimes, NTT CPE is located in front of the ISP's 4rd CE. Sometimes, =
only the ISP's 4rd CE is located at home as shown below.

---- NTT CPE ---- ISP CE ----

---- ISP CE --

It depends on the end-users' contract. If the end-user is getting some =
services from NTT, the NTT CPE is located at home and the ISP CE is =
located behind the NTT CE. If the end-user is not getting such a =
service, only ISP CE is located at home.

In both cases, the IPv6 network infrastructure assigns an IPv6 prefix to =
the customer site. If present, the NTT CPE receives an IPv6 prefix and =
then delegates a longer IPv6 prefix to the ISP CE. For example, a /48 =
IPv6 prefix is assigned to the NTT CPE, and the NTT CPE delegates a /52 =
after adding a 4bit suffix to the ISP CE. But in other cases, if the ISP =
CE is directly connected to the IPv6 network infrastructure, the ISP CE =
can get an IPv6 prefix without any suffix.

So, in one 4rd domain, some ISP CEs get shorter IPv6 prefixes directly =
from the IPv6 network (say /48) and some other ISP CEs get longer IPv6 =
prefixes from NTT CPEs (say /52). This means that the delegated IPv6 =
prefix consists of the Domain IPv6 prefix followed by EA bits, if the =
ISP CE is directly connected to the IPv6 network, and that the delegated =
prefix consists of the Domain IPv6 prefix, followed by EA bits, and =
followed by the added suffix if the ISP CE is connected to another CE."


4.
Without a suffix parameter in mapping rules that applies to CEs behind a =
third-party CPEs, CPE added suffixes would be included in EA bits. They =
would therefore be present as lower parts of PSIDs of CE that have =
shared IPv4 addresses.=20
I don't see how this could work.=20

5.
Of course, the suffix parameter can be added to MAP if decided (no =
problem with that), but the feature comparison table remains based on =
existing drafts.


Hoping this clarifies this issue, I welcome questions and comments from =
anyone in the WG, in particular from the MAP design team.
Regards,
RD



From yiu_lee@cable.comcast.com  Wed Feb 15 11:55:36 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C7621E804E for ; Wed, 15 Feb 2012 11:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.678
X-Spam-Level: 
X-Spam-Status: No, score=-100.678 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FfinksmpvTm for ; Wed, 15 Feb 2012 11:55:29 -0800 (PST)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C94AD21F8501 for ; Wed, 15 Feb 2012 11:55:28 -0800 (PST)
Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.6303209; Wed, 15 Feb 2012 12:45:21 -0700
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Wed, 15 Feb 2012 14:55:23 -0500
From: "Lee, Yiu" 
To: Maoke , Qiong 
Thread-Topic: [Softwires] [softwire] Merged version of lightweight 4over6
Thread-Index: AQHM7BvAIcvCW84xWEmWOqa5XFnJXA==
Date: Wed, 15 Feb 2012 19:55:22 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [24.40.55.72]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3412162522_1222782"
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 19:55:36 -0000

--B_3412162522_1222782
Content-type: multipart/alternative;
	boundary="B_3412162521_1181782"


--B_3412162521_1181782
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Maoke,

For 1, it is not a ds-lite problem but a general problem for any tunneling
protocol. Once option is the 4o6 TC passes the fragmented packets and hope
the destination would reassemble them. This option would break the
end-to-end model if the destination rejects fragmented packets. The current
model in RFC6333 will not in exchange with extra CPU and buffer overhead.

For 2, we can mention ALG could be implemented in the 4o6 TI. We still want
to keep the 4o6 TC simple.

Thanks,
Yiu

From:  Maoke 
Date:  Wed, 15 Feb 2012 16:38:36 +0900
To:  Qiong 
Cc:  
Subject:  Re: [Softwires] [softwire] Merged version of lightweight 4over6

sp. the merged document meets the requirements where flexible dynamic IPv4
address sharing in IPv6 domain and meanwhile 1) considerably reduces the
states that the AFTR needs to handle; 2) reduces the overload of AFTR
through distributing the NAT functionality over Initiators.

i think the document is ready for WG adoption.

a further discussion is: DS-Lite (RFC6333) states some limitations related
to the potentially high burden of AFTR. as i understand, there are at least
two:
1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is
required to reassembly before the decapsulation. DS-Lite states because of
the high buffer requirements, AFTR doesn't do the reassembly but only B4 do
that. it is reasonable in the case of client/server communications where
large datagrams happen often in the inbound. however, it implies that
DS-Lite is not very suitable for the p2p communications where outbound
datagram might be large as well.
2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite AFTR
doesn't do ALG for any applications. thus some applications might be
impacted. 

my question is: can lightweight 4over6 improve 1) and 2) because the AFTR
load has been enlighted? if so, i suggest the author to state the
improvement of releasing the limitations.

regards,
maoke

2012/2/5 Qiong 
> Dear all,
> 
> We have published a merged version of lightweight 4over6 in:
> http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-0
> 5.txt. 
> 
> This mechanism moves the translation function from the tunnel concentrator
> (AFTR) to initiators (B4s), and hence reduces the mapping scale on the
> concentrator to per-subscriber level.
> 
> It has got wilely support in the last Taipei IETF meeting, and the only action
> we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
> and I-D.zhou-softwire-b4-nat into one draft.
> 
> Now that the merge work has done, from the authors of this document's view, it
> is ready to be adopted as working group document. We would be appreciated to
> have your comments.
> 
> Thanks in advance !
> 
> Best wishes
> 
> Qiong
> 
> 
>  
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
> 

_______________________________________________ Softwires mailing list
Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires


--B_3412162521_1181782
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


Hi Maoke,

For 1, it is not a ds-lite problem but a general problem for any tunn=
eling protocol. Once option is the 4o6 TC passes the fragmented packets and =
hope the destination would reassemble them. This option would break the end-=
to-end model if the destination rejects fragmented packets. The current mode=
l in RFC6333 will not in exchange with extra CPU and buffer overhead.
<=
div>
For 2, we can mention ALG could be implemented in the 4o6=
 TI. We still want to keep the 4o6 TC simple.

Thank=
s,
Yiu

From:  Maoke <fibrib@gmail.com>
<=
span style=3D"font-weight:bold">Date:  Wed, 15 Feb 2012 16:38:36 +0900<=
br>To:  Qiong <bingxuere@gmail.com>
Cc:  <softwires@ietf.org>
Subject:  Re: [Softwires] [so=
ftwire] Merged version of lightweight 4over6



a further discussion is: DS-Lite (RFC6333) states some limitations related =
to the potentially high burden of AFTR. as i understand, there are at least =
two:


<=
div>maoke
2012/2/5 Qiong &=
lt;bingxuere@gmail.com>

Dear all,

We have published a merged version of lightweight 4over6 i=
n: 
http://www.ietf.org/internet-drafts=
/draft-cui-softwire-b4-translated-ds-lite-05.txt. 

This mechanism=
 moves the translation function from the tunnel concentrator (AFTR) to initi=
ators (B4s), and hence reduces the mapping scale on the concentrator to per-=
subscriber level.  

It has got wilely support in the last Taipei IETF=
 meeting, and the only action we need to do is to merge I-D.cui-softwire-b4-=
translated-ds-lite



and I-D.zhou-softwire-b4-nat into one draft.

Now that the merge work=
 has done, from the authors of this document's view, it is ready to be adopt=
ed as working group document. We would be appreciated to have your comments.=
 

Thanks in advance !

Best wishes
Qiong


 



_____________________________=
__________________

Softwires mailing list
Softwires@iet=
f.org
https://www.ietf.org/mailman/listinfo/softwires



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.=
org/mailman/listinfo/softwires


--B_3412162521_1181782--

--B_3412162522_1222782
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX
DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa
djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA
Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8
dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf
WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn
c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0
W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED
BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI
KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u
YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0
cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1
cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG
A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB
AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq
ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV
/F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss
oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7
mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC
AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS
VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE
AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx
MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY
1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp
ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU
gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/
FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ
Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME
GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5
xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV
HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF
UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw
ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp
ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq
hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5
yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z
X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG
1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u
5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl
cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe
Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt
VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq
mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM
yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN
oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR
Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/
MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa
MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF
BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW
uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR
zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd
lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg
7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC
BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT
C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi
MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y
MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0
IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz
5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6
2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO
rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B
X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq
WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O
BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/
MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT
RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU
UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG
SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD
UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69
FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh
jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE
MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw
NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQ2r24Y
4B5H/H2WkeZUKq8bnObWNzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMjAyMTUxOTU1MjFaMA0GCSqGSIb3DQEBAQUABIIBAGVa7flLxuozd5qMPcDiUEpc
b434fjBW0IVnw4dJOuE5ARrH38CFP2ZJd7yaaBbppa7pht0Y+LL+ibdOJ2o4HZROjB0Oe9Vz
8R2KgaNaLTNIm2brk+NXoRF9JKZsIecQZOsqNDZ68ryYjMiiYlmV9dDgB3GtJAxpBvPQNN1f
4KmSfszkzBJrXWNBV/x1wMWGFr+KkaaMC0lN7yq6I8kGDQ3BSYx4MbSB9jye4LfdV1kShH4s
FedE9jO+PjsN+KDaKFZoRcXyVV7Hp3Nw/PTQceDOJk8gWbxBdatNd2aQgV3e7SEuW/A5/6qx
lkVqnR68xZJWT5kJBFcE/SoL/3Oiog4=

--B_3412162522_1222782--

From ichiroumakino@gmail.com  Wed Feb 15 12:03:39 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36B021E80A0 for ; Wed, 15 Feb 2012 12:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXdKLHMzLSzJ for ; Wed, 15 Feb 2012 12:03:39 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC92E21E8027 for ; Wed, 15 Feb 2012 12:03:38 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so968110wib.31 for ; Wed, 15 Feb 2012 12:03:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=70+6QG6RT/o7OI41pqAJH20GDQ+kgWgNWqNpQdO5l0E=; b=hF7AbEgzyVYMzDt2LX3Xb/XaBxfKrFmGUtbdPA37lHg5b9MTZrh/20h+lPNJOilTfV HOUGqjRxNCx5UOQH17zMu27vCshE3AvFGjRXJ2kEnoJAx80cugiqFIzqGW2zzB+ny89i ccviAuSPgax6mXLMQLvnfWuwcxDKMSslnJnG8=
Received: by 10.180.86.134 with SMTP id p6mr37371990wiz.0.1329336217808; Wed, 15 Feb 2012 12:03:37 -0800 (PST)
Received: from dhcp-10-61-97-249.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y1sm15139527wiw.6.2012.02.15.12.03.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 12:03:36 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>
Date: Wed, 15 Feb 2012 21:03:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG 
Subject: Re: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2012 20:03:40 -0000

Remi,

> Your comments about the following feature-comparison item have been:
> - "possible with MAP-{E,T} too, but may require coordination of subnet =
numbering."
> - "I don't see the point of having text in the specification for this =
use case. it is a deployment option."
>=20
> +----+--------------------------------------+-----+-----+-----+-----+
> |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
> |    |                                      |  -T |  -E |  -H |  -E |
> +----+--------------------------------------+-----+-----+-----+-----+
> ...
> |    |                                      |     |     |     |     |
> |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
> |    | third-party CPEs                     |     |     |     |     |
>=20
> But, AFAIK, it is not possible to configure a MAP domain for CEs =
attached to third-party CPEs (ref. use case 5.2.2 of the 4rd-U draft).
>=20
> 2.
> To deal with some similar use cases, we had an optional Suffix =
parameter of Mapping rules in draft draft-despres-intarea-4rd-01 (of =
which co-authors were R. Despr=E9s, S. Matsushima, T. Murakami, ... and =
yourself).
>=20
> Having not seen in the WG that the need had disappeared, nor that =
another way to satisfy the need had been discussed, I did include the =
Suffix parameter in 4rd-U.
>=20
> 3.
> A somewhat detailed explanation about this need, received in the past =
and IMHO clarifying, was something like this:
>=20
> "For the instance, in Japan, NTT provides the access line to the =
end-users and ISPs provides the internet service over this access line. =
Sometimes, NTT CPE is located in front of the ISP's 4rd CE. Sometimes, =
only the ISP's 4rd CE is located at home as shown below.
>=20
> ---- NTT CPE ---- ISP CE ----
>=20
> ---- ISP CE --

I would not expect those two cases would be in the same MAP domain. even =
though they could.

> It depends on the end-users' contract. If the end-user is getting some =
services from NTT, the NTT CPE is located at home and the ISP CE is =
located behind the NTT CE. If the end-user is not getting such a =
service, only ISP CE is located at home.

not quite. see Satoru-san's presentation from the Paris last week for =
details.

> In both cases, the IPv6 network infrastructure assigns an IPv6 prefix =
to the customer site. If present, the NTT CPE receives an IPv6 prefix =
and then delegates a longer IPv6 prefix to the ISP CE. For example, a =
/48 IPv6 prefix is assigned to the NTT CPE, and the NTT CPE delegates a =
/52 after adding a 4bit suffix to the ISP CE. But in other cases, if the =
ISP CE is directly connected to the IPv6 network infrastructure, the ISP =
CE can get an IPv6 prefix without any suffix.
>=20
> So, in one 4rd domain, some ISP CEs get shorter IPv6 prefixes directly =
from the IPv6 network (say /48) and some other ISP CEs get longer IPv6 =
prefixes from NTT CPEs (say /52). This means that the delegated IPv6 =
prefix consists of the Domain IPv6 prefix followed by EA bits, if the =
ISP CE is directly connected to the IPv6 network, and that the delegated =
prefix consists of the Domain IPv6 prefix, followed by EA bits, and =
followed by the added suffix if the ISP CE is connected to another CE."

the End-user IPv6 prefix must be of the same length for all CEs using =
the same mapping rule.

> 4.
> Without a suffix parameter in mapping rules that applies to CEs behind =
a third-party CPEs, CPE added suffixes would be included in EA bits. =
They would therefore be present as lower parts of PSIDs of CE that have =
shared IPv4 addresses.=20
> I don't see how this could work.=20

incorrect, MAP includes an EA-bits length parameter. the EA-bits are =
included in the topmost End-user IPv6 prefix (in your example above).

> 5.
> Of course, the suffix parameter can be added to MAP if decided (no =
problem with that), but the feature comparison table remains based on =
existing drafts.

not, needed. the MAP subnet-id is defined to be 0.

> Hoping this clarifies this issue, I welcome questions and comments =
from anyone in the WG, in particular from the MAP design team.

MAP supports "3rd party CPEs". (assuming all the other problems =
associated with provisioning are resolved.)
it also solves the case of directly connected and 3rd party CPEs within =
the same MAP domain. albeit I've never ever heard that as a real use =
case.

cheers,
Ole


From fibrib@gmail.com  Wed Feb 15 17:16:51 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531921E800E for ; Wed, 15 Feb 2012 17:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level: 
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNnztka-BtOf for ; Wed, 15 Feb 2012 17:16:51 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4974C21E803E for ; Wed, 15 Feb 2012 17:16:51 -0800 (PST)
Received: by qafi29 with SMTP id i29so3759783qaf.10 for ; Wed, 15 Feb 2012 17:16:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XFG64PbutQ6yOI7wbDPxO7q+1IspTYTkNTPhdLJhsww=; b=s08c7XysS87ra4n5Dz91yyUNM7eMqQ+vCoVArDAHdtmk+4J4Dc/twY6RYb9Ss3FDr1 Zk78I/5MeWNwZWvZM2VhxkaGiJ/B95vGcJTLjOGryPzEZGqVyo0nrEHQVC0o7piJnJTu E/kuOfA7/ztsS/ASQ/QmYoeP9RtqZ7xxJ91lA=
MIME-Version: 1.0
Received: by 10.229.77.12 with SMTP id e12mr394320qck.41.1329355010852; Wed, 15 Feb 2012 17:16:50 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Wed, 15 Feb 2012 17:16:50 -0800 (PST)
In-Reply-To: 
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>  
Date: Thu, 16 Feb 2012 10:16:50 +0900
Message-ID: 
From: Maoke 
To: Washam Fan 
Content-Type: multipart/alternative; boundary=00235429e11c33c66b04b90a9526
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 01:16:52 -0000

--00235429e11c33c66b04b90a9526
Content-Type: text/plain; charset=ISO-8859-1

2012/2/15 Washam Fan 

> Hi Maoke,
>
> Just one point. Please see inline.
>
> > i don't think MAP standard have nor should have such a limitation. A
> > MAP-compliant device supports UDP, TCP, DCCP, SCTP today, with the same
> > logic, and will support any emerging L4 protocol in the future, again
> with
> > the same logic. requiring L4 checksum update for any supported protocol
> > makes it a stable standard, and the checksum update logic is stable for
> any
> > protocol. in 4rd-U, however, with the R-22 (3), today it can support UDP,
> > TCP, DCCP and SCTP-variant(? not sure due to lack of personal knowledge),
> > while if tomorrow we have a new protocol XXXP:
>
> Please keep in mind both MAP and 4rd-U are transition techniques, from
> a long-term perspective, they might disappear before any new L4
> protocol invented;)
>

good point! but, ... if they are really transition-able ;) i am not so
optimistic.

on the other hand, the thread is talking on whether BR needs to be changed
or not for new L4 protocol. ;-)

best,
maoke


>
> washam
>

--00235429e11c33c66b04b90a9526
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



2012/2/15 Washam Fan &=
lt;washam.fan@gmail.com>

Hi Maoke,



Just one point. Please see inline.




> i don't think MAP standard have nor should have such a limitation.=
 A

> MAP-compliant device supports UDP, TCP, DCCP, SCTP today, with the sam=
e

> logic, and will support any emerging L4 protocol in the future, again =
with

> the same logic. requiring L4 checksum update for any supported protoco=
l

> makes it a stable standard, and the checksum update logic is stable fo=
r any

> protocol. in 4rd-U, however, with the R-22 (3), today it can support U=
DP,

> TCP, DCCP and SCTP-variant(? not sure due to lack of personal knowledg=
e),

> while if tomorrow we have a new protocol XXXP:




Please keep in mind both MAP and 4rd-U are transition techniques, fro=
m

a long-term perspective, they might disappear before any new L4

protocol invented;)

good point! but, ..=
. if they are really transition-able ;) i am not so optimistic.=A0

on the other hand, the thread is talking on whether BR nee=
ds to be changed or not for new L4 protocol. ;-)



best,
maoke
=A0



washam





--00235429e11c33c66b04b90a9526--

From fibrib@gmail.com  Wed Feb 15 18:34:30 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9A21F84DA for ; Wed, 15 Feb 2012 18:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-1.439, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, MANGLED_SHOP=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhqLUcqQxqQD for ; Wed, 15 Feb 2012 18:34:28 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3898A21E800E for ; Wed, 15 Feb 2012 18:34:27 -0800 (PST)
Received: by qafi29 with SMTP id i29so3817104qaf.10 for ; Wed, 15 Feb 2012 18:34:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2d/mpA1FQvTb+K2KxPapArVIXTpUuOsWRI01RrXkQlg=; b=HYyebPbYL4pz4w4bQZr41hFBE7rSg+pX1RF6fANvbrHl8z1/uudTyBgQLajDlvx/UJ 6O8rbI/coArlgvBVfi8hULeTigXV4TOvqkzFk74dgDenRjKHCbNg1/twnYRFR81jOLPg gUsxvS8WX0InRkXB6gZCs5tKh/MN5kzBpcrVc=
MIME-Version: 1.0
Received: by 10.229.77.12 with SMTP id e12mr557694qck.41.1329359667208; Wed, 15 Feb 2012 18:34:27 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Wed, 15 Feb 2012 18:34:27 -0800 (PST)
In-Reply-To: <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>  <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net>
Date: Thu, 16 Feb 2012 11:34:27 +0900
Message-ID: 
From: Maoke 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=00235429e11cbe244f04b90baac1
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 02:34:30 -0000

--00235429e11cbe244f04b90baac1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/2/15 R=E9mi Despr=E9s 

>
> 2012-02-15 =E0 03:15, Maoke a =E9crit :
>
>
>
> 2012/2/15 R=E9mi Despr=E9s 
>
>>
>> Le 2012-02-14 =E0 16:21, Maoke a =E9crit :
>>
>>
>>
>> 2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net
>>
>>>
>>>
>>  2) in the environment where single translation is also envolved (either
>>> stateless or stateful), L4 checksum rewriting is a MUST because sometim=
es
>>> there is only one address of the (src, dst)-pair following the
>>> checksum-neutral address scheme. (this is mentioned in RFC6052, giving =
up
>>> to enforce the checksum-neutrality in the address format, to my knowled=
ge).
>>>
>>>
>>> I have aways acknowledged that L4 update is necessary for single
>>> translation, no disagreement.
>>> But here the problem is stateless IPv4 service across IPv6, a different
>>> problem where there is no such necessity.
>>>
>>>
>>
>> RFC6052 includes also the double-translation case. i guess operators
>> wouldn't like to deploy different translators here for single translatio=
n
>> while there for double.
>>
>>
>>>
>>> The point is that, where it can be used, checksum neutrality is MORE
>>> GENERAL than L4 update.
>>>
>>>
>>
>> how do you define the "generality"? doing L4 update is a safe choice no
>> matter if the addresses are checksum-neutral or not.
>>
>>
>>>
>>> Besides, but less important, it is simpler as far as the number of
>>> specifications it depends on is concerned (no need to know where checks=
um
>>> fields are for different protocols).
>>>
>>>
>>
>>>
>>> i understand Ole has the same opinion: as we anyway have it,
>>>
>>>
>>> There can be implementations of BRs that are independent of single
>>> translation.
>>> They don't need to know where checksums are placed in various protocols=
.
>>>
>>>
>>> we don't need it in the address scheme standard
>>>
>>>
>>> One can live with a standard less good than it could be but, since we
>>> are working for the future, let's make them as good as we can now.
>>> In any case, this is no excuse to claim that, with checksum neutrality
>>> the following is not correct "BRs need no change for any new protocol
>>> having ports at their usual place and TCP-like checksum" (DCCP, SCTP if
>>> it would acce^t TCP-like checksum, any other.)
>>>
>>>
>> i think making L4 checksum update is a safe choice for standard. once we
>> have a new L4 protocol,
>>
>> the BR surely need a change to check if this new protocol is a
>> TCP-checksumed one.
>>
>>
>> 1. A key, that probably hasn't been clarified enough so far (thanks for
>> in fact raising it), is the following:
>> - With checksum neutrality, the BR DOESN'T NEED to know about UDP, TCP
>> etc. (see R-22 (3) of the 4rd-U draft).
>>
>> If, by mistake a remote host sends to a shared IPv4 address a packet
>> whose L4 payload has no ports at their usual places, the packet, if it
>> reaches a CE, will ALWAYS be  discarded there (protocol unknown by the
>> NAT44) =3D> no operational problem.
>>
>
> MAP should also works for the case where IPv4 addresses are not shared an=
d
> there is no NAT44.
>
>
> Indeed, in particular for CEs that are assigned IPv4 prefixes.
> So does 4rd-H, without identified problem.
>
>
> "protocol unknown" should be detected and discarded at both CE and BR in
> their major module instead of the NAT44 part.
>
>
> I don't think so:
> - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't
> exclude any protocol in packets sent to this CE.
> - If a CE has a shared address, it needs a NAT that the CE informs it the
> restricted port set. This NAT already has all what is needed to refuse
> protocols it doesn't understand.
>

what if my NAT has understood XXXP but your CE hasn't? to my understanding,
CE only informs the restricted port set regardless of the protocol.


>
>
>
> This is one more instance where it isn't useful to try and guess what
>> mistakes people might make, and to add specific software for them while
>> tools already exist to detect and signal them. (Keep it simple)
>>
>
> 1. as the above, MAP should not depend upon NAT44.
>
> 2. on the other hand, even the NAT44 works in front of CE, there is no
> NAT44 works between BR and a remote host (not belonging to the MAP domain=
).
> the assumption of "NAT44 discards unknown protocol" only available in the
> case where communication is initialized by a client in the CE-delegated
> network. be more clarified:
>
>     host.A --- NAT44 --- CE ---- IPv6 domain ---- BR --- IPv4 Internet --=
-
> host.B
>
> (a) A initiates connection to B =3D> ok, that the NAT44 checks protocol
> unknown.
> (b) B initiates connection to A =3D> BR has to check if L4 protocol is
> supported or not.
> (c) A initiates communication to B through a UDP or TCP signaling channel
> while B reply a connection request on another channel over a new L4
> protocol =3D> BR has to check if the new L4 protocol is supported or not.
>
> and in the case of (c), R-22 (3)'s processing looks dangerous -- blindly
> deciding where the port is located without looking at the L4 protocol
> layout narrows the applicability of the proposal.
>
>
> Which danger?
>
On the contrary, avoiding that BRs depend on a list of L4 protocols
> enlarges their applicability.
>

> however, surely it is not a problem if you state the scope of
> applicability of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS
> BEEN KNOWN (known by the BR/CE rather than human) as having the same head=
er
> layout as well as the same checksum algorithm (without variation).
>
>
> I just say (and repeat) that, for shared-address CEs, 4rd-U BRs
> support WITHOUT MODIFICATION any L4 protocol that has ports at their usua=
l
> place and a TCP-like checksum.
>
> i don't think MAP standard have nor should have such a limitation.
>
>
> Which limitation?
> On the contrary, checksum neutrality eliminates the need for a BR upgrade
> if a new protocol using conventional ports and TCP-like checksum is
> introduced.
>
>
> A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,
>
>
> Not SCTP today, for sure.
> Also, as I think you know, there is uncertainty concerning DCCP because
> RFC6145 sec 4.5 says:
> "Other transport protocols (e.g., DCCP) are OPTIONAL to support".
>

it depends on the understanding of the "OPTIONAL". if it is OPTIONAL for
the operation domain, it is not a problem for double translation. if it is
OPTIONAL per device, the uncertainty is a problem where src-translator
makes DCCP checksum rewrite but dst-translator doesn't. (inverse case,
where src translator doesn't make but dst do, is not a problem though.)


>
>
> with the same logic, and will support any emerging L4 protocol in the
> future, again with the same logic. requiring L4 checksum update for any
> supported protocol makes it a stable standard, and the checksum update
> logic is stable for any protocol. in 4rd-U, however, with the R-22 (3),
> today it can support UDP, TCP, DCCP and SCTP-variant(? not sure due to la=
ck
> of personal knowledge), while if tomorrow we have a new protocol XXXP:
>    a) XXXP has the same layout and same checksum logic, then the 4rd-U
> compliant BR should be changed in order it knows that XXXP is also
> supported and the logic R-22 (3) is still available;
>
>
> Not AFAIK.
> You can check that R-22 (3) does not depend on any L4 protocol (the only
> protocol that needs to be recognized is ICMP (a layer-3 protocol).
>
>    b) XXXP is different, then 4rd-U compliant BR should be changed in
> order it knows that XXXP is now supported but different logic should be
> applied.
>
> in either a) and b), the BR should be changed otherwise the XXXP will be
> not supported. therefore i still think Ole's argument is not unfair here.
>
>
> Let me repeat once more:
> If XXXP has (1) the same checksum algorithm, (2) the same port layout
> (like UDP, TCP, DCCP and SCTP do have), (3) a different layout for the
> checksum field (as is the case for UDP, TCP, DCCP, SCTP), THEN no new log=
ic
> is needed in 4rd-H (because of its checksum neutrality).
>
> I do hope this point will eventually be understood in the WG, rather
> repeatedly negated.
>

ok, i think we do understand your point but please check. you mean: if
addresses are checksum-neutral, we don't need to have a list of supported
protocol in BR and just let it pass any protocol with the assumption that
it is TCP-layouted/checksumed. if the "any protocol" happens to really have
TCP-layout and TCP-checksum, then things are happy and the addresses have
ensured the checksum validity even without L4 rewrite. if the "any
protocol", unfortunately, happens to have another layout and/or another
checksum, then BR also treat it as it were TCP-layouted/checksumed but let
it fail at the end host or CE. right?

here it is what i said R-22 (3) in 4rd-U is dangerous. it says:

   + If the packet Protocol is not ICMP, bits 0-15 for an
   IPv4 source address, and bits 16-31 for a destination
   address.

well doesn't it mean: even if the protocol has another layout, R-22 (3)'s
BR prefer to ignore the fact, making messy mapped addresses with blindly
assuming the protocol follows the TCP-layout!? (there is no NAT44 before BR
to ensure the "unknown" protocol has been dropped.) i would further point
out that, the messy mapped destination address may navigate your packet in
a wrong direction towards a wrong CE where even the "fail at end" may fail.

therefore i do agree Ole's argument. because we think any protocol should
be certainly supported, or certainly reported as not-supported, rather than
blindly trying a seemingly "universal" logic.


>
> btw, regarding the below "new standard for a new problem", i'd like to
> emphasize it is not a new problem as RFC6052 has discussed it. it is an
> incorrect understanding to think RFC6052/RFC6145 is designed only for
> single translation. since the very beginning of the stateless address
> mapping/translation design, the single and double translations have being
> considered.
>
>
> I have no intention to negate anything about what designers of
> RFC6052/6145 considered (I wasn't there ;-)).
>
> The problem which IS NEW is how to design a stateless v4/v6 solution that=
:
> - is AS TRANSPARENT to IPv4 as encapsulation, without any restriction or
> doubt
>

NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2 points:

1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. this
is not a behavior of encapsulation but a behavior of translation.

2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 message
will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. please note
that RFC6145 Sec 5.2 is a typical behavior of translation rather than
encapsulation. for the encapsulation, the semantics of ICMPv6 message
processing should be quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U
draft 03 contains the RFC2473 in the reference list but never cites it in
the main text).

if we say some fields are transparent, that's ok. but if we are talking
about the IP as a whole, TRANSPARENCY implies not only the consistency of
packet header fields but also the behavior of hiding details of the
carrying underlay infrastructure.

best,
maoke


> - yet works with IPv6-only port-based ACLs and IPv6 Web caches.
> In my understanding, 4rd-H is indeed such a solution (and is the only one
> on the table).
>
>
> Regards,
> RD
>
> PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a
> different subject which deserves a discussion thread with another title.
>
> ...
>
>

--00235429e11cbe244f04b90baac1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



2012/2/15 R=E9mi Despr=E9s <despres.remi@laposte.n=
et>



2012-02-15 =E0 03:15, Mao=
ke a =E9crit :


2012/2/15 R=E9mi Despr=E9s &l=
t;despres.rem=
i@laposte.net>





Le 2012-02-14 =E0 16:21, =
Maoke a =E9crit :



2012/2/14 R=E9mi Despr=E9s despres.remi@laposte.net<=
/a>





=A0
=







2) in the environment where single translation is also envolved (eithe=
r stateless or stateful), L4 checksum rewriting is a MUST because sometimes=
 there is only one address of the (src, dst)-pair following the checksum-ne=
utral address scheme. (this is mentioned in RFC6052, giving up to enforce t=
he checksum-neutrality in the address format, to my knowledge).





I have aways acknowledged that L4 u=
pdate is necessary for single translation, no disagreement.
But h=
ere the problem is stateless IPv4 service across IPv6, a different problem =
where there is no such necessity.




=A0
=A0
RFC6052 includes also t=
he double-translation case. i guess operators wouldn't like to deploy d=
ifferent translators here for single translation while there for double. 



=A0
=A0=





The point is that, where it can be used, checksum neutrality is MORE G=
ENERAL than L4 update.
=A0
=A0
=

how do you define the "generality"? doing L4 update is=A0a s=
afe choice=A0no matter if the addresses are checksum-neutral or not. 




=A0
=A0=





Besides, but less important, it is simpler as far as the number of spe=
cifications it depends on is concerned (no need to know where checksum fiel=
ds are for different protocols).
=A0




=A0
i understand Ole has the same op=
inion: as we anyway have it, 



There can be implementations of BRs that are independent of sing=
le translation.
They don't need to know where checksums are p=
laced in various protocols.
=A0





we don't need it in the address scheme =
standard

One can live with a s=
tandard less good than it could be but, since we are working for the future=
, let's make them as good as we can now.




In any case, this is no excuse to claim that, with checksum neutrality=
 the following is not correct "BRs need no change for any new protocol having ports at their us=
ual place=
 and TCP-like checksum" (DCCP, SCTP if it would acce^t TCP-like checks=
um, any other.)




 




the BR surely need a change to=A0check if this new protocol is a TCP-chec=
ksumed one.




- With checksum neutrality, the BR DOESN'T NEED to know about UDP,=
 TCP etc. (see R-22 (3) of the 4rd-U draft).

If, b=
y mistake a remote host sends=A0to a shared IPv4 address=A0a packet whose L=
4 payload has no ports at their usual places, the packet, if it reaches a C=
E, will ALWAYS be =A0discarded there (protocol unknown by the NAT44)=A0=3D&=
gt; no operational problem.=A0





Indeed, in particular for CEs that are a=
ssigned IPv4 prefixes.

So does 4rd-H, without identified problem.
=A0
"pro=
tocol unknown" should be detected and discarded at both CE and BR in t=
heir major module instead of the NAT44 part. 



I don't think so:
- I=
f a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't exclu=
de any protocol in packets sent to this CE.
- If a CE has a share=
d address, it needs a NAT that the CE informs it the restricted port set. T=
his NAT already has all what is needed to refuse protocols it doesn't u=
nderstand.=A0



what if my NAT has understood XXXP b=
ut your CE hasn't? to my understanding, CE only informs the restricted =
port set regardless of the protocol.=A0
=A0



=
=A0




This is one more instance where it isn't useful to try and gu=
ess what mistakes people might make, and to add specific software for them =
while tools already exist to detect and signal them. (Keep it simple)




1. as the above, MAP should no=
t depend upon NAT44. 

2. on the other hand, even t=
he NAT44 works in front of CE, there is no NAT44 works between BR and a rem=
ote host (not belonging to the MAP domain). the assumption of "NAT44 d=
iscards unknown protocol" only available in the case where communicati=
on is initialized by a client in the CE-delegated network. be more clarifie=
d:=A0




=A0 =A0 host.A --- NAT44 --- CE ---- IPv6 domain ---- B=
R --- IPv4 Internet --- host.B=A0

(a) A initiates =
connection to B =3D> ok, that the NAT44 checks protocol unknown.=A0


(b) B initiates connection to A =3D> BR has to check if L4 protocol is s=
upported or not.=A0
(c) A initiates communication to B through a =
UDP or TCP signaling channel while B reply a connection request on another =
channel over a new L4 protocol =3D> BR has to check if the new L4 protoc=
ol is supported or not.=A0




and in the case of (c), R-22 (3)'s processing looks=
 dangerous -- blindly deciding where the port is located without looking at=
 the L4 protocol layout narrows the applicability of the proposal.



Which danger?=A0
On the contrary, avoiding that BRs depend on a list of L4 protocols enla=
rges their applicability.



=



however, surely it is not a problem if you state the scope of app=
licability of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS BEEN =
KNOWN (known by the BR/CE rather than human) as having the same header layo=
ut as well as the same checksum algorithm (without variation).



I just say (and repeat) that,=
 for shared-address CEs, 4rd-U BRs support=A0WITHOUT MODIFICATION any L4 pr=
otocol that has ports at their usual place and a TCP-like checksum.=A0


i don't think MAP standard have nor should h=
ave such a limitation.

<=
div>
Which limitation?
On the contrary, checksum neutrality eliminates=
 the need for a BR upgrade if a new protocol using conventional ports and T=
CP-like checksum is introduced.




 A MAP-compl=
iant device supports UDP, TCP, DCCP, SCTP today,

Not SCTP today, for sure.
Also, as I thi=
nk you know, there is uncertainty concerning DCCP because RFC6145 sec 4.5 s=
ays:


"Other=
 transport protocols (e.g., DCCP) are OPTIONAL to support".

it depends on the understanding of=
 the "OPTIONAL". if it is OPTIONAL for the operation domain, it i=
s not a problem for double translation. if it is OPTIONAL per device, the u=
ncertainty is a problem where src-translator makes DCCP checksum rewrite bu=
t dst-translator doesn't. (inverse case, where src translator doesn'=
;t make but dst do, is not a problem though.)=A0


=A0


<=
div class=3D"gmail_quote">

 with the same logic, and will support any emerging L4 protocol i=
n the future, again with the same logic. requiring L4 checksum update for a=
ny supported protocol makes it a stable standard, and the checksum update l=
ogic is stable for any protocol. in 4rd-U, however, with the R-22 (3), toda=
y it can support UDP, TCP, DCCP and SCTP-variant(? not sure due to lack of =
personal knowledge), while if tomorrow we have a new protocol XXXP:



=A0 =A0a) XXXP has the same layout and same checksum logic, then the 4=
rd-U compliant BR should be changed in order it knows that XXXP is also sup=
ported and the logic R-22 (3) is still available;=A0



Not AFAIK.
You can check that R-22 (3) does =
not depend on any L4 protocol (the only protocol that needs to be recognize=
d is ICMP (a layer-3 protocol).



=A0 =A0b) XXXP is different, then 4rd-=
U compliant BR should be changed in order it knows that XXXP is now support=
ed but different logic should be applied.=A0



in either a) and b), the BR should be changed otherwise=
 the XXXP will be not supported. therefore i still think Ole's argument=
 is not unfair here.=A0



Let me repeat once more:
If XXXP has (1) the same checksum a=
lgorithm, (2) the same port layout (like UDP, TCP, DCCP and SCTP do have), =
(3) a different layout for the checksum field (as is the case for UDP, TCP,=
 DCCP, SCTP), THEN no new logic is needed in 4rd-H (because of its checksum=
 neutrality).=A0



I do hope this point will eventually be understood in t=
he WG, rather repeatedly negated.

ok, i think we do understand your point but please check. you mean=
: if addresses are checksum-neutral, we don't need to have a list of su=
pported protocol in BR and just let it pass any protocol with the assumptio=
n that it is TCP-layouted/checksumed. if the "any protocol" happe=
ns to really have TCP-layout and TCP-checksum, then things are happy and th=
e addresses have ensured the checksum validity even without L4 rewrite. if =
the "any protocol", unfortunately, happens to have another layout=
 and/or another checksum, then BR also treat it as it were TCP-layouted/che=
cksumed but let it fail at the end host or CE. right?



here it is what i said R-22 (3) in 4rd-U is dangerous. =
it says:=A0

=A0 =A0+  If the packet Protocol is no=
t ICMP, bits 0-15 for an
=A0                =A0IPv4 source address, and =
bits 16-31 for a destination

=A0                =A0address.

well doesn't it=
 mean: even if the protocol has another layout, R-22 (3)'s BR prefer to=
 ignore the fact, making messy mapped addresses with blindly assuming the p=
rotocol follows the TCP-layout!? (there is no NAT44 before BR to ensure the=
 "unknown" protocol has been dropped.) i would further point out =
that, the messy mapped destination address may navigate your packet in a wr=
ong direction towards a wrong CE where even the "fail at end" may=
 fail.=A0



therefore i do agree Ole's argument. because we thi=
nk any protocol should be certainly supported, or certainly reported as not=
-supported, rather than blindly trying a seemingly "universal" lo=
gic.=A0


=A0



btw, regarding the below "new standard for a new problem&quo=
t;, i'd like to emphasize it is not a new problem as RFC6052 has discus=
sed it. it is an incorrect understanding to think RFC6052/RFC6145 is design=
ed only for single translation. since the very beginning of the stateless a=
ddress mapping/translation design, the single and double translations have =
being considered.=A0



I have no intention to negate=
 anything about what=A0designers of RFC6052/6145=A0considered (I wasn't=
 there ;-)).

The problem which IS NEW is how to de=
sign a stateless v4/v6 solution that:


- is=A0AS TRANSPARENT to IPv4 as encapsulation, without any restrictio=
n or doubt

NOT AS TRANSPARENT t=
o IPv4 as encapsulation at least in following 2 points:=A0



1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domai=
n. this is not a behavior of encapsulation but a behavior of translation.=
=A0

2) 4rd-U draft, at R-33, states its IPv6-domai=
n-generated ICMPv6 message will be translated to ICMPv4 with the logic of R=
FC6145 Sec 5.2. please note that RFC6145 Sec 5.2 is a typical behavior of t=
ranslation rather than encapsulation. for the encapsulation, the semantics =
of ICMPv6 message processing should be quite different (cf. RFC2473, Sec 8.=
) (btw, 4rd-U draft 03 contains the RFC2473 in the reference list but never=
 cites it in the main text).=A0



if we say some fields are transparent, that's =
ok. but if we are talking about the IP as a whole, TRANSPARENCY implies not=
 only the consistency of packet header fields but also the behavior of hidi=
ng details of the carrying underlay infrastructure.=A0



best,
maoke
=A0
- yet works=
 with IPv6-only port-based ACLs and IPv6 Web caches.


In my understanding, 4rd-H is indeed such a solution (and is the only =
one on the table).
=A0

Regards,
RD

PS:=A0Relationship of 4rd-U with single trans=
lation XLATs of RFC6145 is a different subject which deserves a discussion =
thread with another title.





...



--00235429e11cbe244f04b90baac1--

From fibrib@gmail.com  Wed Feb 15 18:51:01 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CAD21E800F for ; Wed, 15 Feb 2012 18:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.341
X-Spam-Level: 
X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKk5HvgHAKkC for ; Wed, 15 Feb 2012 18:50:57 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 402BA21E800E for ; Wed, 15 Feb 2012 18:50:57 -0800 (PST)
Received: by qafi29 with SMTP id i29so3828732qaf.10 for ; Wed, 15 Feb 2012 18:50:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0d9tMf5tUYzh9X/fjjK7mYsuNEDRRS5GMAnq7PF5ewQ=; b=FnaB/U+KmNk3Ls+6d8b18yyGqYAGquEw3js5GGtg3q9NZTC+RWmipiv8seo83Z5d8y KkpSUox1LS99LV1fCWArp30+4MDR7YDjAo6Qu8HxAF2y4iwg+A9CJHeJ0eEwDxb7cRtF shsXEXRiTSVIA2+Bo/QqX6SmUx7ZvrYEV8Tyc=
MIME-Version: 1.0
Received: by 10.229.76.76 with SMTP id b12mr554148qck.81.1329360653124; Wed, 15 Feb 2012 18:50:53 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Wed, 15 Feb 2012 18:50:33 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 16 Feb 2012 11:50:33 +0900
Message-ID: 
From: Maoke 
To: "Lee, Yiu" 
Content-Type: multipart/alternative; boundary=00235429cbc482054804b90be5eb
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 02:51:01 -0000

--00235429cbc482054804b90be5eb
Content-Type: text/plain; charset=ISO-8859-1

hi Yiu,

thanks for the explanation.

2012/2/16 Lee, Yiu 

> Hi Maoke,
>
> For 1, it is not a ds-lite problem but a general problem for any tunneling
> protocol. Once option is the 4o6 TC passes the fragmented packets and hope
> the destination would reassemble them. This option would break the
> end-to-end model if the destination rejects fragmented packets. The current
> model in RFC6333 will not in exchange with extra CPU and buffer overhead.
>
>
got it. this point is fine. and i also mean that DS-Lite states (Sec 6.3):

   This reassembly process will significantly
   impact the AFTR's performance. However, this impact only happens
   when many clients simultaneously source large IPv4 packets. Since we
   believe that the majority of the clients will receive large IPv4
   packets (such as watching video streams) instead of sourcing large
   IPv4 packets (such as sourcing video streams), reassembly is only a
   fraction of the overall AFTR's workload.

the "since we believe" is true in the term that client/server model is
dominating the Internet usage. but the situation is changing, AFTR might
suffer a heavy burden with reassembly in the environment where p2p is
dominating. can we (actually you authors) surely state lightweight 4over6
improves this? if we can, it is a happy point. ;-)

best,
maoke


> For 2, we can mention ALG could be implemented in the 4o6 TI. We still
> want to keep the 4o6 TC simple.
>
> Thanks,
> Yiu
>
> From: Maoke 
> Date: Wed, 15 Feb 2012 16:38:36 +0900
> To: Qiong 
> Cc: 
> Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
>
> sp. the merged document meets the requirements where flexible dynamic IPv4
> address sharing in IPv6 domain and meanwhile 1) considerably reduces the
> states that the AFTR needs to handle; 2) reduces the overload of AFTR
> through distributing the NAT functionality over Initiators.
>
> i think the document is ready for WG adoption.
>
> a further discussion is: DS-Lite (RFC6333) states some limitations related
> to the potentially high burden of AFTR. as i understand, there are at least
> two:
> 1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is
> required to reassembly before the decapsulation. DS-Lite states because of
> the high buffer requirements, AFTR doesn't do the reassembly but only B4 do
> that. it is reasonable in the case of client/server communications where
> large datagrams happen often in the inbound. however, it implies that
> DS-Lite is not very suitable for the p2p communications where outbound
> datagram might be large as well.
> 2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite AFTR
> doesn't do ALG for any applications. thus some applications might be
> impacted.
>
> my question is: can lightweight 4over6 improve 1) and 2) because the AFTR
> load has been enlighted? if so, i suggest the author to state the
> improvement of releasing the limitations.
>
> regards,
> maoke
>
> 2012/2/5 Qiong 
>
>> Dear all,
>>
>> We have published a merged version of lightweight 4over6 in:
>>
>> http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt.
>>
>>
>> This mechanism moves the translation function from the tunnel
>> concentrator (AFTR) to initiators (B4s), and hence reduces the mapping
>> scale on the concentrator to per-subscriber level.
>>
>> It has got wilely support in the last Taipei IETF meeting, and the only
>> action we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
>> and I-D.zhou-softwire-b4-nat into one draft.
>>
>> Now that the merge work has done, from the authors of this document's
>> view, it is ready to be adopted as working group document. We would be
>> appreciated to have your comments.
>>
>> Thanks in advance !
>>
>> Best wishes
>>
>> Qiong
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
> _______________________________________________ Softwires mailing list
> Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
>

--00235429cbc482054804b90be5eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


hi Yiu,

thanks for the explanation.=A0
2012/2/16 Lee, Yiu <=
Yiu_Lee@cable.comcast.com&=
gt;


Hi Maoke,
=



For 1, it is not a ds-lite problem but a general problem for=
 any tunneling protocol. Once option is the 4o6 TC passes the fragmented pa=
ckets and hope the destination would reassemble them. This option would bre=
ak the end-to-end model if the destination rejects fragmented packets. The =
current model in RFC6333 will not in exchange with extra CPU and buffer ove=
rhead.




got it. this point is=
 fine. and i also mean that DS-Lite states (Sec 6.3):=A0 

=A0 =A0This reassembly process will significantly
=A0  =A0impact=
 the AFTR's performance.  However, this impact only happens

=A0  =A0when many clients simultaneously source large IPv4 packets.  Since =
we
=A0  =A0believe that the majority of the clients will receive large I=
Pv4
=A0  =A0packets (such as watching video streams) instead of sourcing=
 large

=A0  =A0IPv4 packets (such as sourcing video streams), reassembly is only a=

=A0  =A0fraction of the overall AFTR's workload.

the "since we believe" is true in the term that client/ser=
ver model is dominating the Internet usage. but the situation is changing, =
AFTR might suffer a heavy burden with reassembly in the environment where p=
2p is dominating. can we (actually you authors) surely state lightweight 4o=
ver6 improves this? if we can, it is a happy point. ;-)=A0



best,
maoke
=A0


For 2, we can mention ALG could be implemented in the 4o6 TI. We still=
 want to keep the 4o6 TC simple.

Thanks,
Yiu


From:  Maoke <fibrib@gmail.com>
Date:  Wed, 15 Feb 2012 16:38:36 +0900
To:  Qiong <bingxuere@gmail.com>

Cc:  <softwires@ietf.org>
Subject:  Re: [Softwires] [softwire] Merged versio=
n of lightweight 4over6



sp. the merged document me=
ets the requirements where flexible dynamic IPv4 address sharing in IPv6 do=
main and meanwhile 1) considerably reduces the states that the AFTR needs t=
o handle; 2) reduces the overload of AFTR through distributing the NAT func=
tionality over Initiators.=A0



i think the document is ready for WG adoption.=A0
=


a further discussion is: DS-Lite (RFC6333) states some =
limitations related to the potentially high burden of AFTR. as i understand=
, there are at least two:


1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is=
 required to reassembly before the decapsulation. DS-Lite states because of=
 the high buffer requirements, AFTR doesn't do the reassembly but only =
B4 do that. it is reasonable in the case of client/server communications wh=
ere large datagrams happen often in the inbound. however, it implies that D=
S-Lite is not very suitable for the p2p communications where outbound datag=
ram might be large as well.=A0


2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite A=
FTR doesn't do ALG for any applications. thus some applications might b=
e impacted.=A0

my question is: can lightweight 4ov=
er6 improve 1) and 2) because the AFTR load has been enlighted? if so, i su=
ggest the author to state the improvement of releasing the limitations.=A0<=
/div>


regards,
maoke

2012/2/5 Qiong <bingxuere@gmail.com>


Dear all,

We have published a merged version of lightweight 4over6 i=
n: 
http://www.ietf.org/internet-=
drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt. 


This mechanism moves the translation function from the tunnel concentra=
tor (AFTR) to initiators (B4s), and hence reduces the mapping scale on the =
concentrator to per-subscriber level.  

It has got wilely support in=
 the last Taipei IETF meeting, and the only action we need to do is to merg=
e I-D.cui-softwire-b4-translated-ds-lite




and I-D.zhou-softwire-b4-nat into one draft.

Now that the merge work=
 has done, from the authors of this document's view, it is ready to be =
adopted as working group document. We would be appreciated to have your com=
ments. 


Thanks in advance !

Best wishes

Q=
iong


=A0



_________________________________=
______________

Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s=
oftwires




_______________________________________________
Softwires mailing list
Softwires@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/softwires






--00235429cbc482054804b90be5eb--

From yiu_lee@cable.comcast.com  Wed Feb 15 19:57:08 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC1E21E8021 for ; Wed, 15 Feb 2012 19:57:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.584
X-Spam-Level: 
X-Spam-Status: No, score=-100.584 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIP6pUQfsyBh for ; Wed, 15 Feb 2012 19:57:07 -0800 (PST)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4367221E800E for ; Wed, 15 Feb 2012 19:57:03 -0800 (PST)
Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.6347303; Wed, 15 Feb 2012 20:46:55 -0700
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Wed, 15 Feb 2012 22:56:58 -0500
From: "Lee, Yiu" 
To: Maoke 
Thread-Topic: [Softwires] [softwire] Merged version of lightweight 4over6
Thread-Index: AQHM7F8HXLvfeMOpWU6APi1d8wpLmA==
Date: Thu, 16 Feb 2012 03:56:57 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [24.40.55.72]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3412191414_1269373"
MIME-Version: 1.0
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 03:57:08 -0000

--B_3412191414_1269373
Content-type: multipart/alternative;
	boundary="B_3412191413_1259687"


--B_3412191413_1259687
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Hi Maoke,

There are always trade-offs. We can suggest few options and ask the WG to
choose one.=20

1) Let the host to reassemble the fragmented packets
2) Let the 4o6 TC to assemble the fragmented packets
3) Don=B9t suggest anything and leave this open for implementation

/Yiu


From:  Maoke 
Date:  Thu, 16 Feb 2012 11:50:33 +0900
To:  "Yiu L. LEE" 
Cc:  Qiong , "softwires@ietf.org" 
Subject:  Re: [Softwires] [softwire] Merged version of lightweight 4over6

the "since we believe" is true in the term that client/server model is
dominating the Internet usage. but the situation is changing, AFTR might
suffer a heavy burden with reassembly in the environment where p2p is
dominating. can we (actually you authors) surely state lightweight 4over6
improves this? if we can, it is a happy point. ;-)




--B_3412191413_1259687
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Hi Maoke,

There are always trade-offs. We can suggest few options and ask the W=
G to choose one. 

1) Let the host to reassembl=
e the fragmented packets
2) Let the 4o6 TC to assemble the fragmen=
ted packets
3) Don’t suggest anything and leave this open fo=
r implementation

/Yiu


=

From:  Maoke <fibrib@gmail.com>
D=
ate:  Thu, 16 Feb 2012 11:50:33 +0900
To:  "Yiu L. LEE" <y=
iu_lee@cable.comcast.com>
Cc:  Qiong <bingxuere@gmail.com>=
;, "softwires@ietf.org" <softwires@ietf.org>
Subject:  Re: [Softwires] [softwire] Merged version of l=
ightweight 4over6

the "since =
we believe" is true in the term that client/server model is dominating the I=
nternet usage. but the situation is changing, AFTR might suffer a heavy burd=
en with reassembly in the environment where p2p is dominating. can we (actua=
lly you authors) surely state lightweight 4over6 improves this? if we can, i=
t is a happy point. ;-) 



--B_3412191413_1259687--

--B_3412191414_1269373
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX
DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa
djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA
Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8
dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf
WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn
c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0
W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED
BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI
KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u
YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0
cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1
cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG
A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB
AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq
ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV
/F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss
oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7
mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC
AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS
VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE
AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx
MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY
1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp
ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU
gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/
FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ
Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME
GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5
xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV
HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF
UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw
ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp
ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq
hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5
yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z
X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG
1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u
5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl
cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe
Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt
VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq
mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM
yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN
oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR
Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/
MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa
MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF
BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW
uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR
zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd
lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg
7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC
BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT
C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi
MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y
MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0
IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz
5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6
2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO
rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B
X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq
WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O
BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/
MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT
RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU
UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG
SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD
UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69
FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh
jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE
MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw
NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT/Q6ae
Z31dS4vBTaQdlODEedwBXzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMjAyMTYwMzU2NTNaMA0GCSqGSIb3DQEBAQUABIIBAJEVbaNXIBGG+BVW/FYa2hVq
F19Z8OmXT2F6WMcvNLAdyiuj9705kjTMubNQdcrt7LKqvRN5uOXSsS7GKn4sGUbSL8lu4fke
qmK0KRN3uBtsHyMxrtD8HOcDJ4p5dZkbm4+OB9zBvlO6wKjvMfoHVWtJO3RrDdHRbOrp0aOE
2+vSxI1BgVk60bJ6J1ELL9+mZcIMbbjG9LWTTgs0j2WKe8T9TkJuwvPy1qBZUWx4FElmG0XZ
p89PkhgtFN6CFL7zalhm3ourXDMw9OVSbvi/smEIEHDaxnOLbdTyTV8sw+IcSFV454+UFP8r
zgxNAncV2zwuCjbXWdlDD41UB/wdCSM=

--B_3412191414_1269373--

From fibrib@gmail.com  Wed Feb 15 20:20:50 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6421F8574 for ; Wed, 15 Feb 2012 20:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.357
X-Spam-Level: 
X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlgSepE7YBQt for ; Wed, 15 Feb 2012 20:20:49 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 309DE21F852B for ; Wed, 15 Feb 2012 20:20:46 -0800 (PST)
Received: by qafi29 with SMTP id i29so3890053qaf.10 for ; Wed, 15 Feb 2012 20:20:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D/NqVOA2OXxLK2crod6Gv2kYMGO/8kbMYVCdwbjizUQ=; b=Kkp4/umZFhBT2TCpUueW3bhd4n2WfAbo2SM95kjKiY9pf2bgHfLnnhq/t7xVBfSDVU iLLxEPmWbnmkTbvYvhfWTTDd+4GCkIRdVgTAiXwDqGTE+Ka/lcZDtZ7DrVmnVOYqqn2U wUw8/4RONDsE7hGfhIQBXS/0vTPdvFbDqex2E=
MIME-Version: 1.0
Received: by 10.229.78.145 with SMTP id l17mr689997qck.141.1329366045724; Wed, 15 Feb 2012 20:20:45 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Wed, 15 Feb 2012 20:20:45 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 16 Feb 2012 13:20:45 +0900
Message-ID: 
From: Maoke 
To: "Lee, Yiu" 
Content-Type: multipart/alternative; boundary=002354470b84ee937e04b90d266c
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 04:20:50 -0000

--002354470b84ee937e04b90d266c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

2012/2/16 Lee, Yiu 

> Hi Maoke,
>
> There are always trade-offs. We can suggest few options and ask the WG to
> choose one.
>

good point. acceptable. :) - maoke


>
> 1) Let the host to reassemble the fragmented packets
> 2) Let the 4o6 TC to assemble the fragmented packets
> 3) Don=92t suggest anything and leave this open for implementation
>
> /Yiu
>
>
> From: Maoke 
> Date: Thu, 16 Feb 2012 11:50:33 +0900
> To: "Yiu L. LEE" 
> Cc: Qiong , "softwires@ietf.org" 
>
> Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
>
> the "since we believe" is true in the term that client/server model is
> dominating the Internet usage. but the situation is changing, AFTR might
> suffer a heavy burden with reassembly in the environment where p2p is
> dominating. can we (actually you authors) surely state lightweight 4over6
> improves this? if we can, it is a happy point. ;-)
>
>

--002354470b84ee937e04b90d266c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



2012/2/16 Lee, Yiu <Yiu_Lee@cable.comcast.=
com>


Hi Maoke,

There are a=
lways trade-offs. We can suggest few options and ask the WG to choose one.=
=A0



good point. acceptable. :) - maoke
=A0



1) Let the host to reassemble the fragmented packets
2) Let the 4o6 TC to assemble the fragmented packets
3) D=
on=92t suggest anything and leave this open for implementation


/Yiu



From:  Maoke <fibrib@gmail.com>
Date:  Thu, 16 Feb 2012 11:50:33 +0900
To:  "Yiu L. LEE" <yiu_lee@cable.comca=
st.com>

Cc:  Qiong <bingxuere@gmail.com>, "softwires@ietf.org=
" <softwire=
s@ietf.org>


Subject:  Re: [Softwires] [soft=
wire] Merged version of lightweight 4over6


the "since we believe" is true in the term that client/server mod=
el is dominating the Internet usage. but the situation is changing, AFTR mi=
ght suffer a heavy burden with reassembly in the environment where p2p is d=
ominating. can we (actually you authors) surely state lightweight 4over6 im=
proves this? if we can, it is a happy point. ;-)=A0







--002354470b84ee937e04b90d266c--

From despres.remi@laposte.net  Thu Feb 16 01:54:51 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458F121F85BD for ; Thu, 16 Feb 2012 01:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level: 
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHeyv6Kl4nrE for ; Thu, 16 Feb 2012 01:54:50 -0800 (PST)
Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A221F85C5 for ; Thu, 16 Feb 2012 01:54:48 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id aZul1i00537Y3f403ZulzM; Thu, 16 Feb 2012 10:54:47 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-17-1039050800
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 16 Feb 2012 10:54:45 +0100
Message-Id: 
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>  <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net> 
To: Maoke 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 09:54:51 -0000

--Apple-Mail-17-1039050800
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 2012-02-16 =E0 03:34, Maoke a =E9crit=20
> 2012/2/15 R=E9mi Despr=E9s 
> 2012-02-15 =E0 03:15, Maoke a =E9crit :
> =20
>> "protocol unknown" should be detected and discarded at both CE and BR =
in their major module instead of the NAT44 part.
>=20
> I don't think so:
> - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't =
exclude any protocol in packets sent to this CE.
> - If a CE has a shared address, it needs a NAT that the CE informs it =
the restricted port set. This NAT already has all what is needed to =
refuse protocols it doesn't understand.=20
>=20
> what if my NAT has understood XXXP but your CE hasn't? to my =
understanding, CE only informs the restricted port set regardless of the =
protocol.=20

2 cases:
- If the new protocol has ports at their usual place, and has TCP-like =
checksum, no problem. "Your CE", as you call it, does forward packets of =
the new protocol.=20
- In other cases, any CE or BR would need needs an update to work, and =
incompatibilities cold result.=20
=20

...
>=20
>> A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,
>=20
> Not SCTP today, for sure.
> Also, as I think you know, there is uncertainty concerning DCCP =
because RFC6145 sec 4.5 says:
> "Other transport protocols (e.g., DCCP) are OPTIONAL to support".
>=20
> it depends on the understanding of the "OPTIONAL". if it is OPTIONAL =
for the operation domain, it is not a problem for double translation. if =
it is OPTIONAL per device, the uncertainty is a problem where =
src-translator makes DCCP checksum rewrite but dst-translator doesn't. =
(inverse case, where src translator doesn't make but dst do, is not a =
problem though.)=20

Optional "for the operation domain" would work only if there would be =
means to inform CEs of the choice made for the domain.
Such means don't exist, right?


> ok, i think we do understand your point but please check. you mean: if =
addresses are checksum-neutral, we don't need to have a list of =
supported protocol in BR and just let it pass any protocol with the =
assumption that it is TCP-layouted/checksumed. if the "any protocol" =
happens to really have TCP-layout and TCP-checksum, then things are =
happy and the addresses have ensured the checksum validity even without =
L4 rewrite. if the "any protocol", unfortunately, happens to have =
another layout and/or another checksum, then BR also treat it as it were =
TCP-layouted/checksumed but let it fail at the end host or CE. right?

Yes.
We are in sync on this point.

>=20
> here it is what i said R-22 (3) in 4rd-U is dangerous. it says:=20
>=20
>    + If the packet Protocol is not ICMP, bits 0-15 for an
>    IPv4 source address, and bits 16-31 for a destination
>    address.
>=20
> well doesn't it mean: even if the protocol has another layout, R-22 =
(3)'s BR prefer to ignore the fact, making messy mapped addresses with =
blindly assuming the protocol follows the TCP-layout!? (there is no =
NAT44 before BR to ensure the "unknown" protocol has been dropped.) i =
would further point out that, the messy mapped destination address may =
navigate your packet in a wrong direction towards a wrong CE where even =
the "fail at end" may fail.

Still a misunderstanding here.
No new protocol will work for shared IPv4 addresses, be it with MAP or =
4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their =
usual place, and a TCP-like checksum somewhere).
A NAT44 that is coupled with a CE MUST remain operational ONLY for =
"traditional" protocols.

(Future protocols, if not "traditional", will need IPv6 to work safely, =
including with shared-IPv4-address CEs.



> therefore i do agree Ole's argument. because we think any protocol =
should be certainly supported, or certainly reported as not-supported, =
rather than blindly trying a seemingly "universal" logic.=20

1.
I don't know which "Ole's argument" you agree to (making your own points =
directly would be clearer).=20
- In particular, Ole wrote "any A+P solution requires support for L4 =
protocols to extract ports. L4 checksum rewrite, as well as port =
extraction will have to be supported for all new L4 protocols."
- The fact is that 4rd-U, because of checksum neutrality, doesn't have =
to support L4 checksum rewrite. Yet, it is an A+P solution that has no =
identified operational problem.

2.
4rd-U "certainly" supports All "traditional" protocols, an Echo requests =
in identified conditions,  and nothing else.
MAP-T is AFAIK uncertain for DCCP.


>> btw, regarding the below "new standard for a new problem", i'd like =
to emphasize it is not a new problem as RFC6052 has discussed it. it is =
an incorrect understanding to think RFC6052/RFC6145 is designed only for =
single translation. since the very beginning of the stateless address =
mapping/translation design, the single and double translations have =
being considered.=20
>=20
> I have no intention to negate anything about what designers of =
RFC6052/6145 considered (I wasn't there ;-)).
>=20
> The problem which IS NEW is how to design a stateless v4/v6 solution =
that:
> - is AS TRANSPARENT to IPv4 as encapsulation, without any restriction =
or doubt
>=20
> NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2 =
points:=20
>=20
> 1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. =
this is not a behavior of encapsulation but a behavior of translation.=20=


1.
Well, there remains an inconsistency that I didn't see in the 4rd-U =
draft(!):=20
- "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class =
that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel =
traversal is treated in IPv4 as a single-link traversal. Without it, =
Explicit Congestion Notification of [RFC3168] MAY be propagated from =
intermediate IPv6 nodes to IPv4 destinations, and IPv4 Time to live =
values progress with the number of traversed IPv6 links."
- Table 2 has:
+---------------------+-----------------------------------+
| IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT         |
+---------------------+-----------------------------------+
                    ...
| Time to live        | Hop limit                         |
                    ...
+---------------------+-----------------------------------+

 Correction should be:
"R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class =
that BRs and CEs MUST set in Tunnel packets.  Without it, Explicit =
Congestion Notification of [RFC3168] MAY be propagated from intermediate =
IPv6 nodes to IPv4 destinations."
Thanks for the opportunity to notice this inconsistency.

2.
IPv4 time-to-live of an IPv4 may thus progress by more than one during =
domain traversal, right, but this isn't a breach to IPv4 end-to-end =
transparency (the TTL is THE field that always evolve during network =
traversal).=20


> 2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 =
message will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. =
please note that RFC6145 Sec 5.2 is a typical behavior of translation =
rather than encapsulation. for the encapsulation, the semantics of =
ICMPv6 message processing should be quite different (cf. RFC2473, Sec =
8.) (btw, 4rd-U draft 03 contains the RFC2473 in the reference list but =
never cites it in the main text).=20

1. How an IPv6-generated ICMP message is translated into an IPMPv4 =
message, doesn't belong to "IPv4 transparency".
2. MAP-E has the same need. Otherwise unreachable CEs couldn't be =
signaled to IPv4 sources, right?

The point remains that 4rd-U is "as transparent to IPv4 as MAP-E".=20
This is AFAIK a simple and important fact (it was designed for that).=20


> if we say some fields are transparent, that's ok.

> but if we are talking about the IP as a whole, TRANSPARENCY implies =
not only the consistency of packet header fields but also the behavior =
of hiding details of the carrying underlay infrastructure.

Agreed.
(But with due understanding of the exception of time-to-live: it always =
decreases end to end, and more or less depending on peculiarities of =
traversed infrastructures).=20


Regards,
RD



> =20
>=20
> best,
> maoke
> =20
> - yet works with IPv6-only port-based ACLs and IPv6 Web caches.
> In my understanding, 4rd-H is indeed such a solution (and is the only =
one on the table).
> =20
>=20
> Regards,
> RD
>=20
> PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is =
a different subject which deserves a discussion thread with another =
title.
>=20
>> ...
>=20


--Apple-Mail-17-1039050800
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


2012/2/15 R=E9mi Despr=E9s <despres.remi@laposte.net><=
/span>
2012-02-15 =E0 =
03:15, Maoke a =E9crit :
 
"protocol unknown" should be detected and =
discarded at both CE and BR in their major module instead of the NAT44 =
part. 



I don't think so:
- If =
a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't exclude =
any protocol in packets sent to this CE.
- If a CE has a =
shared address, it needs a NAT that the CE informs it the restricted =
port set. This NAT already has all what is needed to refuse protocols it =
doesn't understand. 



what if my NAT has understood =
XXXP but your CE hasn't? to my understanding, CE only informs the =
restricted port set regardless of the =
protocol. 

2 =
cases:
- If the new protocol has ports at their usual place, =
and has TCP-like checksum, no problem. "Your CE", as you call it, does =
forward packets of the new protocol. 
- In other cases, =
any CE or BR would need needs an update to work, and incompatibilities =
cold =
result. 
 

...



 A =
MAP-compliant device supports UDP, TCP, DCCP, SCTP =
today,

Not SCTP =
today, for sure.
Also, as I think you know, there is =
uncertainty concerning DCCP because RFC6145 sec 4.5 says:


"Other =
transport protocols (e.g., DCCP) are OPTIONAL to =
support".

it depends =
on the understanding of the "OPTIONAL". if it is OPTIONAL for the =
operation domain, it is not a problem for double translation. if it is =
OPTIONAL per device, the uncertainty is a problem where src-translator =
makes DCCP checksum rewrite but dst-translator doesn't. (inverse case, =
where src translator doesn't make but dst do, is not a problem =
though.) 

Optional "for =
the operation domain" would work only if there would be means to inform =
CEs of the choice made for the domain.
Such means don't exist, =
right?




ok, i think we do understand your point but please check. you mean: =
if addresses are checksum-neutral, we don't need to have a list of =
supported protocol in BR and just let it pass any protocol with the =
assumption that it is TCP-layouted/checksumed. if the "any protocol" =
happens to really have TCP-layout and TCP-checksum, then things are =
happy and the addresses have ensured the checksum validity even without =
L4 rewrite. if the "any protocol", unfortunately, happens to have =
another layout and/or another checksum, then BR also treat it as it were =
TCP-layouted/checksumed but let it fail at the end host or CE. =
right?

Yes.
We are =
in sync on this point.




here it is what i said R-22 (3) in 4rd-U is =
dangerous. it says: 

   +  If =
the packet Protocol is not ICMP, bits 0-15 for an
               =
   IPv4 source address, and bits 16-31 for a destination

                  address.

well =
doesn't it mean: even if the protocol has another layout, R-22 (3)'s BR =
prefer to ignore the fact, making messy mapped addresses with blindly =
assuming the protocol follows the TCP-layout!? (there is no NAT44 before =
BR to ensure the "unknown" protocol has been dropped.) i would further =
point out that, the messy mapped destination address may navigate your =
packet in a wrong direction towards a wrong CE where even the "fail at =
end" may fail.

Still a =
misunderstanding here.
No new protocol will work for shared =
IPv4 addresses, be it with MAP or 4rd-U BRs, if it isn't a "traditional" =
protocol (i.e. ports at their usual place, and a TCP-like checksum =
somewhere).
A NAT44 that is coupled with a CE MUST remain =
operational ONLY for "traditional" =
protocols.

(Future protocols, if not =
"traditional", will need IPv6 to work safely, including with =
shared-IPv4-address =
CEs.





therefore i do agree Ole's argument. because we think any protocol =
should be certainly supported, or certainly reported as not-supported, =
rather than blindly trying a seemingly "universal" =
logic. 

1.
I =
don't know which "Ole's argument" you agree to (making your own points =
directly would be clearer). 
- In particular, Ole =
wrote "any A+P solution requires support for L4 protocols to extract =
ports. L4 checksum rewrite, as well as port extraction will have to be =
supported for all new L4 protocols."
- The fact is that 4rd-U, =
because of checksum neutrality, doesn't have to support L4 checksum =
rewrite. Yet, it is an A+P solution that has no identified operational =
problem.

2.
4rd-U "certainly" =
supports All "traditional" protocols, an Echo requests in =
identified conditions,  and nothing else.
MAP-T is AFAIK =
uncertain for DCCP.




btw, regarding the below "new standard for a new problem", i'd =
like to emphasize it is not a new problem as RFC6052 has discussed it. =
it is an incorrect understanding to think RFC6052/RFC6145 is designed =
only for single translation. since the very beginning of the stateless =
address mapping/translation design, the single and double translations =
have being considered. 



I have no intention to =
negate anything about what designers of =
RFC6052/6145 considered (I wasn't there =
;-)).

The problem which IS NEW is how to design =
a stateless v4/v6 solution that:


- is AS TRANSPARENT to IPv4 as encapsulation, without any =
restriction or doubt

NOT AS =
TRANSPARENT to IPv4 as encapsulation at least in following 2 =
points: 



1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 =
domain. this is not a behavior of encapsulation but a behavior of =
translation. 

1.
Well, there remains an inconsistency that I didn't see in the 4rd-U =
draft(!): 
- "R-4   "Tunnel traffic class", if =
provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel =
packets.  In this case, tunnel traversal is treated in IPv4 as a =
single-link traversal. Without it, Explicit Congestion Notification of =
[RFC3168] MAY be propagated from intermediate IPv6 nodes to IPv4 =
destinations, and IPv4 Time to live values progress with the number of =
traversed IPv6 links."
- Table 2 =
has:
+---------------------+-------------------------------=
----+
| IPv4 FIELDS         | VALUES SET =
AT DOMAIN EXIT         =
|
+---------------------+-----------------------------------+
                  =
  ...
| Time to live        | Hop =
limit                   =
      |
          =
          =
...
+---------------------+-----------------------------------+<=
/div>

 Correction should =
be:
"R-4   "Tunnel traffic class", if provided, is the =
IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. =
 Without it, Explicit Congestion Notification of [RFC3168] MAY be =
propagated from intermediate IPv6 nodes to IPv4 =
destinations."
Thanks for the opportunity to notice this =
inconsistency.

2.
IPv4 time-to-live =
of an IPv4 may thus progress by more than one during domain traversal, =
right, but this isn't a breach to IPv4 end-to-end transparency (the TTL =
is THE field that always evolve during network =
traversal). 


2) 4rd-U draft, at R-33, =
states its IPv6-domain-generated ICMPv6 message will be translated to =
ICMPv4 with the logic of RFC6145 Sec 5.2. please note that RFC6145 Sec =
5.2 is a typical behavior of translation rather than encapsulation. for =
the encapsulation, the semantics of ICMPv6 message processing should be =
quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U draft 03 contains the =
RFC2473 in the reference list but never cites it in the main =
text). 

1. How an =
IPv6-generated ICMP message is translated into an IPMPv4 message, =
doesn't belong to "IPv4 transparency".
2. MAP-E has the =
same need. Otherwise unreachable CEs couldn't be signaled to IPv4 =
sources, right?

The point remains that 4rd-U is =
"as transparent to IPv4 as MAP-E". 
This is AFAIK a =
simple and important fact (it was designed for =
that). 


if we say some fields =
are transparent, that's =
ok.

 but if we are talking about the IP as a =
whole, TRANSPARENCY implies not only the consistency of packet header =
fields but also the behavior of hiding details of the carrying underlay =
infrastructure.

Agreed.<=
/div>
(But with due understanding of the exception of time-to-live: =
it always decreases end to end, and more or less depending on =
peculiarities of traversed =
infrastructures). 


Regards,
RD



 

=


best,
maoke
 
- =
yet works with IPv6-only port-based ACLs and IPv6 Web caches.


In my understanding, 4rd-H is indeed such a solution (and is the =
only one on the =
table).
 

Regards,
RD

PS: Relationship of 4rd-U with single =
translation XLATs of RFC6145 is a different subject which deserves a =
discussion thread with another title.




=

...

=



=

--Apple-Mail-17-1039050800--

From fibrib@gmail.com  Thu Feb 16 03:19:25 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C3221F87D0 for ; Thu, 16 Feb 2012 03:19:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aosVrzNpDTs for ; Thu, 16 Feb 2012 03:19:23 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDDE21F87C8 for ; Thu, 16 Feb 2012 03:19:22 -0800 (PST)
Received: by wgbdt10 with SMTP id dt10so1287452wgb.13 for ; Thu, 16 Feb 2012 03:19:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kk+413SbzeFVtTYpBMqvVYvsslD3OXRBC/mc8xUKRgQ=; b=RNH+jvjaKXEh61rPlbX+UwJdbhQ21PhGlrOIm/9+9Enm6aEkL8rewju4A8Z/strTWJ ISTv0y//o0VxgezVW7KY1YjNgt6boyhTNbqRKbqDBbvtMMxHkHLlAhnFzn8glq9BOzZ/ DKP1+MGIl37JuBtMDIKcwfBuPBh/nLXlNEe/k=
MIME-Version: 1.0
Received: by 10.180.100.228 with SMTP id fb4mr3737347wib.1.1329391161686; Thu, 16 Feb 2012 03:19:21 -0800 (PST)
Received: by 10.216.122.81 with HTTP; Thu, 16 Feb 2012 03:19:21 -0800 (PST)
In-Reply-To: 
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>  <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net>  
Date: Thu, 16 Feb 2012 20:19:21 +0900
Message-ID: 
From: Maoke 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=f46d0418256ef5bad804b912ffe0
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 11:19:25 -0000

--f46d0418256ef5bad804b912ffe0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/2/16 R=E9mi Despr=E9s 

>
> Le 2012-02-16 =E0 03:34, Maoke a =E9crit
>
> 2012/2/15 R=E9mi Despr=E9s 
>>
>> 2012-02-15 =E0 03:15, Maoke a =E9crit :
>>
>>
>> "protocol unknown" should be detected and discarded at both CE and BR in
>> their major module instead of the NAT44 part.
>>
>>
>> I don't think so:
>> - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't
>> exclude any protocol in packets sent to this CE.
>> - If a CE has a shared address, it needs a NAT that the CE informs it th=
e
>> restricted port set. This NAT already has all what is needed to refuse
>> protocols it doesn't understand.
>>
>
> what if my NAT has understood XXXP but your CE hasn't? to my
> understanding, CE only informs the restricted port set regardless of the
> protocol.
>
>
> 2 cases:
> - If the new protocol has ports at their usual place, and has TCP-like
> checksum, no problem. "Your CE", as you call it, does forward packets of
> the new protocol.
> - In other cases, any CE or BR would need needs an update to work, and
> incompatibilities cold result.
>
>
> ...
>
>
>>  A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,
>>
>>
>> Not SCTP today, for sure.
>> Also, as I think you know, there is uncertainty concerning DCCP because
>> RFC6145 sec 4.5 says:
>> "Other transport protocols (e.g., DCCP) are OPTIONAL to support".
>>
>
> it depends on the understanding of the "OPTIONAL". if it is OPTIONAL for
> the operation domain, it is not a problem for double translation. if it i=
s
> OPTIONAL per device, the uncertainty is a problem where src-translator
> makes DCCP checksum rewrite but dst-translator doesn't. (inverse case,
> where src translator doesn't make but dst do, is not a problem though.)
>
>
> Optional "for the operation domain" would work only if there would be
> means to inform CEs of the choice made for the domain.
> Such means don't exist, right?
>

agree. for this point, we'd prefer to propose an update to RFC6145 in order
to clear the uncertainty, if the authors have not other concern we haven't
noticed.


>
>
> ok, i think we do understand your point but please check. you mean: if
> addresses are checksum-neutral, we don't need to have a list of supported
> protocol in BR and just let it pass any protocol with the assumption that
> it is TCP-layouted/checksumed. if the "any protocol" happens to really ha=
ve
> TCP-layout and TCP-checksum, then things are happy and the addresses have
> ensured the checksum validity even without L4 rewrite. if the "any
> protocol", unfortunately, happens to have another layout and/or another
> checksum, then BR also treat it as it were TCP-layouted/checksumed but le=
t
> it fail at the end host or CE. right?
>
>
> Yes.
> We are in sync on this point.
>

good. thanks!


>
>
> here it is what i said R-22 (3) in 4rd-U is dangerous. it says:
>
>    + If the packet Protocol is not ICMP, bits 0-15 for an
>    IPv4 source address, and bits 16-31 for a destination
>    address.
>
> well doesn't it mean: even if the protocol has another layout, R-22 (3)'s
> BR prefer to ignore the fact, making messy mapped addresses with blindly
> assuming the protocol follows the TCP-layout!? (there is no NAT44 before =
BR
> to ensure the "unknown" protocol has been dropped.) i would further point
> out that, the messy mapped destination address may navigate your packet i=
n
> a wrong direction towards a wrong CE where even the "fail at end" may fai=
l.
>
>
> Still a misunderstanding here.
> No new protocol will work for shared IPv4 addresses, be it with MAP or
> 4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their usua=
l
> place, and a TCP-like checksum somewhere).
> A NAT44 that is coupled with a CE MUST remain operational ONLY for
> "traditional" protocols.
>
> (Future protocols, if not "traditional", will need IPv6 to work safely,
> including with shared-IPv4-address CEs.
>

it confuses me. if there is no new protocol, where we have the talking
topic on the *change* of BR? neither MAP nor 4rd-U needs change if there is
no new protocol. if there is new protocol in consideration, how do you
assert such a new protocol surely not work for shared IPv4 addresses unless
it is a "traditional" one? do you mean non-traditional protocol is nonsense
and we have no obligation to consider? or do you mean, new protocol working
with shared IPv4 addresses must be traditional?


>
>
>
> therefore i do agree Ole's argument. because we think any protocol should
> be certainly supported, or certainly reported as not-supported, rather th=
an
> blindly trying a seemingly "universal" logic.
>
>
> 1.
> I don't know which "Ole's argument" you agree to (making your own points
> directly would be clearer).
>

i think i focuses on the point that the "BR needs no change ...".


>
> - In particular, Ole wrote "any A+P solution requires support for L4
> protocols to extract ports. L4 checksum rewrite, as well as port extracti=
on
> will have to be supported for all new L4 protocols."
> - The fact is that 4rd-U, because of checksum neutrality, doesn't have to
> support L4 checksum rewrite. Yet, it is an A+P solution that has no
> identified operational problem.
>
> 2.
> 4rd-U "certainly" supports All "traditional" protocols, an Echo requests
> in identified conditions,  and nothing else.
> MAP-T is AFAIK uncertain for DCCP.
>

MAP-T has been in running code and it is not complicated to remove the
uncertainty with changing the OPTIONAL to a definite word, unless there is
something we haven't noticed.


>
>
> btw, regarding the below "new standard for a new problem", i'd like to
>> emphasize it is not a new problem as RFC6052 has discussed it. it is an
>> incorrect understanding to think RFC6052/RFC6145 is designed only for
>> single translation. since the very beginning of the stateless address
>> mapping/translation design, the single and double translations have bein=
g
>> considered.
>>
>>
>> I have no intention to negate anything about what designers of
>> RFC6052/6145 considered (I wasn't there ;-)).
>>
>> The problem which IS NEW is how to design a stateless v4/v6 solution tha=
t:
>> - is AS TRANSPARENT to IPv4 as encapsulation, without any restriction or
>> doubt
>>
>
> NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2
> points:
>
> 1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. this
> is not a behavior of encapsulation but a behavior of translation.
>
>
> 1.
> Well, there remains an inconsistency that I didn't see in the 4rd-U
> draft(!):
> - "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class
> that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel
> traversal is treated in IPv4 as a single-link traversal.
>

right, here the "single-link traversal" causes TTL decreases more than 1.
well, you removed this self-contradictory.


> Without it, Explicit Congestion Notification of [RFC3168] MAY be
> propagated from intermediate IPv6 nodes to IPv4 destinations, and IPv4 Ti=
me
> to live values progress with the number of traversed IPv6 links."
>

misunderstanding! please note that ECN being propagated from intermediate
IPv6 to IPv4 is correct even for the mode of encapsulation! because
congestion is a link-wise behavior. RFC3168 Sec 9 discussed this and its
succeeding updates RFC6040 takes a huge effort in order to achieve
compatibility among different processing proposals regarding the potential
inconsistency between the outer header's ECN and inner header's ECN. the
basic operation is: tunnel entry point should copy ECN from inner to outer
header while tunnel exit should copy ECN from outer to inner.


> - Table 2 has:
> +---------------------+-----------------------------------+
> | IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT         |
> +---------------------+-----------------------------------+
>                     ...
> | Time to live        | Hop limit                         |
>                     ...
> +---------------------+-----------------------------------+
>
>  Correction should be:
> "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class tha=
t
> BRs and CEs MUST set in Tunnel packets.  Without it, Explicit Congestion
> Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes =
to
> IPv4 destinations."
> Thanks for the opportunity to notice this inconsistency.
>
> 2.
> IPv4 time-to-live of an IPv4 may thus progress by more than one during
> domain traversal, right, but this isn't a breach to IPv4 end-to-end
> transparency (the TTL is THE field that always evolve during network
> traversal).
>

>
> 2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 message
> will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. please no=
te
> that RFC6145 Sec 5.2 is a typical behavior of translation rather than
> encapsulation. for the encapsulation, the semantics of ICMPv6 message
> processing should be quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U
> draft 03 contains the RFC2473 in the reference list but never cites it in
> the main text).
>
>
> 1. How an IPv6-generated ICMP message is translated into an IPMPv4
> message, doesn't belong to "IPv4 transparency".
>

"belongs to" or not is only a text gaming. i focus on the behavior: you
stated it is "as encapsulation" and therefore i argue its behavior is not
encapsulation behavior at all.


> 2. MAP-E has the same need. Otherwise unreachable CEs couldn't be signale=
d
> to IPv4 sources, right?
>

MAP-E applying any existing encapsulation standard such as RFC2473 or GRE
as the packet processing method surely has been ready for that. the same
need has been satisfied without need to define again. it could be emphasize
the RFC2473's ICMPv6-to-ICMPv4 processing is consistent with the semantics
of "virtual link" which the encapsulation contributes to the Internet
architecture.


>
> The point remains that 4rd-U is "as transparent to IPv4 as MAP-E".
>

narrow sense transparency, no problem in wording. but i suppose people are
concerning the behavior rather than the wording itself.


> This is AFAIK a simple and important fact (it was designed for that).
>
>
> if we say some fields are transparent, that's ok.
>
>
> but if we are talking about the IP as a whole, TRANSPARENCY implies not
> only the consistency of packet header fields but also the behavior of
> hiding details of the carrying underlay infrastructure.
>
>
> Agreed.
> (But with due understanding of the exception of time-to-live: it always
> decreases end to end, and more or less depending on peculiarities of
> traversed infrastructures).
>

encapsulation makes underlay as a link-layer, and certainly the TTL only
decreases by 1 if no trouble. decreasing as the same in the underlay
network is the behavior of translation. it exposes the details of the
underlay and therefore not transparent as encapsulation.

best,
maoke


>
>
> Regards,
> RD
>
>
>
>
>
> best,
> maoke
>
>
>> - yet works with IPv6-only port-based ACLs and IPv6 Web caches.
>> In my understanding, 4rd-H is indeed such a solution (and is the only on=
e
>> on the table).
>>
>>
>> Regards,
>> RD
>>
>> PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a
>> different subject which deserves a discussion thread with another title.
>>
>> ...
>>
>>
>
>

--f46d0418256ef5bad804b912ffe0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



2012/2/16 R=E9mi Despr=E9s <despres.remi@laposte.n=
et>



Le 2012-02-16 =E0 03:34, =
Maoke a =E9crit=A0
2012/2/15 R=E9mi Despr=E9s <despres.remi@laposte.net>


2012-02-15 =
=E0 03:15, Maoke a =E9crit :
=A0
"protocol unknown" =
should be detected and discarded at both CE and BR in their major module in=
stead of the NAT44 part. 




I don't think=
 so:
- If a CE has a non-shared address, =
or an IPv4 prefix, BRs shouldn't exclude any protocol in packets sent t=
o this CE.


- If a CE has a shared address, it needs a NAT that the CE informs it =
the restricted port set. This NAT already has all what is needed to refuse =
protocols it doesn't understand.=A0



what if my N=
AT has understood XXXP but your CE hasn't? to my understanding, CE only=
 informs the restricted port set regardless of the protocol.=A0



2 cases:
- If the new prot=
ocol has ports at their usual place, and has TCP-like checksum, no problem.=
 "Your CE", as you call it, does forward packets of the new proto=
col.=A0


- In other cases, any CE or BR would need needs an update to work, and=
 incompatibilities cold result.=A0
=A0

...





 A MAP-compl=
iant device supports UDP, TCP, DCCP, SCTP today,

Not SCTP today, for sure.
Also, as I thi=
nk you know, there is uncertainty concerning DCCP because RFC6145 sec 4.5 s=
ays:



"Other=
 transport protocols (e.g., DCCP) are OPTIONAL to support".

it depends on the understanding of=
 the "OPTIONAL". if it is OPTIONAL for the operation domain, it i=
s not a problem for double translation. if it is OPTIONAL per device, the u=
ncertainty is a problem where src-translator makes DCCP checksum rewrite bu=
t dst-translator doesn't. (inverse case, where src translator doesn'=
;t make but dst do, is not a problem though.)=A0



Optional "for the operati=
on domain" would work only if there would be means to inform CEs of th=
e choice made for the domain.
Such means don't exist, right?<=
/div>


agree. for this point, we'=
d prefer to propose an update to RFC6145 in order to clear the uncertainty,=
 if the authors have not other concern we haven't noticed.=A0

=A0





ok, i think we do understand your point but please check. you mean: if=
 addresses are checksum-neutral, we don't need to have a list of suppor=
ted protocol in BR and just let it pass any protocol with the assumption th=
at it is TCP-layouted/checksumed. if the "any protocol" happens t=
o really have TCP-layout and TCP-checksum, then things are happy and the ad=
dresses have ensured the checksum validity even without L4 rewrite. if the =
"any protocol", unfortunately, happens to have another layout and=
/or another checksum, then BR also treat it as it were TCP-layouted/checksu=
med but let it fail at the end host or CE. right?



Yes.
We are in sync =
on this point.

good. than=
ks!
=A0






here it is what i said R-22 (3) in 4rd-U is dangerous. =
it says:=A0

=A0 =A0+  If the packet Protocol is no=
t ICMP, bits 0-15 for an
=A0                =A0IPv4 source address, and =
bits 16-31 for a destination


=A0                =A0address.

well doesn't it=
 mean: even if the protocol has another layout, R-22 (3)'s BR prefer to=
 ignore the fact, making messy mapped addresses with blindly assuming the p=
rotocol follows the TCP-layout!? (there is no NAT44 before BR to ensure the=
 "unknown" protocol has been dropped.) i would further point out =
that, the messy mapped destination address may navigate your packet in a wr=
ong direction towards a wrong CE where even the "fail at end" may=
 fail.



Still a misunderstanding here.=

No new protocol will work for shared IPv4 addresses, be it with =
MAP or 4rd-U BRs, if it isn't a "traditional" protocol (i.e. =
ports at their usual place, and a TCP-like checksum somewhere).


A NAT44 that is coupled with a CE MUST remain operational ONLY for &qu=
ot;traditional" protocols.

(Future protocols,=
 if not "traditional", will need IPv6 to work safely, including w=
ith shared-IPv4-address CEs.



it confuses me. if there is no=
 new protocol, where we have the talking topic on the *change* of BR? neith=
er MAP nor 4rd-U needs change if there is no new protocol. if there is new =
protocol in consideration, how do you assert such a new protocol surely not=
 work for shared IPv4 addresses unless it is a "traditional" one?=
 do you mean non-traditional protocol is nonsense and we have no obligation=
 to consider? or do you mean, new protocol working with shared IPv4 address=
es must be traditional?=A0


=A0







therefore i do agree Ole's argument. because we think any protocol=
 should be certainly supported, or certainly reported as not-supported, rat=
her than blindly trying a seemingly "universal" logic.=A0



1.
I don't know =
which "Ole's argument" you agree to (making your own points d=
irectly would be clearer).



i think i focuses on the point that the "BR needs no change ...&q=
uot;.=A0
=A0


=A0
- In particular,=A0Ole wrote "any A+P solution=
 requires support for L4 protocols to extract ports. L4 checksum rewrite, a=
s well as port extraction will have to be supported for all new L4 protocol=
s."


- The fact is that 4rd-U, because of checksum neutrality, doesn't =
have to support L4 checksum rewrite. Yet, it is an A+P solution that has no=
 identified operational problem.

2.

4rd-U "certainly" supports=A0All "traditional" protocol=
s, an Echo requests in identified conditions, =A0and nothing else.
MAP-T is AFAIK uncertain for DCCP.


MAP-T has been in running code and it is not complicated to remo=
ve the uncertainty with changing the OPTIONAL to a definite word, unless th=
ere is something we haven't noticed.=A0
=A0



<=
div>




btw, regarding the below "new standard for a new problem&quo=
t;, i'd like to emphasize it is not a new problem as RFC6052 has discus=
sed it. it is an incorrect understanding to think RFC6052/RFC6145 is design=
ed only for single translation. since the very beginning of the stateless a=
ddress mapping/translation design, the single and double translations have =
being considered.=A0




I have no intention to negate=
 anything about what=A0designers of RFC6052/6145=A0considered (I wasn't=
 there ;-)).

The problem which IS NEW is how to de=
sign a stateless v4/v6 solution that:



- is=A0AS TRANSPARENT to IPv4 as encapsulation, without any restrictio=
n or doubt

NOT AS TRANSPARENT t=
o IPv4 as encapsulation at least in following 2 points:=A0




1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domai=
n. this is not a behavior of encapsulation but a behavior of translation.=
=A0

1.
Well, th=
ere remains an inconsistency that I didn't see in the 4rd-U draft(!):=
=A0


- "R-4 =A0 "Tunnel traffic class", if provided, is the =
IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. =A0In this =
case, tunnel traversal is treated in IPv4 as a single-link traversal.



right, here the "single-l=
ink traversal" causes TTL decreases more than 1. well, you removed thi=
s self-contradictory.=A0
=A0


 Without it, Explicit Congest=
ion Notification of [RFC3168] MAY be propagated from intermediate IPv6 node=
s to IPv4 destinations, and IPv4 Time to live values progress with the numb=
er of traversed IPv6 links."



misunderstanding! please note =
that ECN being propagated from intermediate IPv6 to IPv4 is correct even fo=
r the mode of encapsulation! because congestion is a link-wise behavior. RF=
C3168 Sec 9 discussed this and its succeeding updates RFC6040 takes a huge =
effort in order to achieve compatibility among different processing proposa=
ls regarding the potential inconsistency between the outer header's ECN=
 and inner header's ECN. the basic operation is: tunnel entry point sho=
uld copy ECN from inner to outer header while tunnel exit should copy ECN f=
rom outer to inner.=A0


=A0
- Table 2 has:
+---------------------+------=
-----------------------------+


| IPv4 FIELDS =A0 =A0 =A0 =A0 | VALUES SET AT DOMAIN EXIT =A0 =A0 =A0 =
=A0 |
+---------------------+-----------------------------------+=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
| Time to =
live =A0 =A0 =A0 =A0| Hop limit =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 |


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
+---------------=
------+-----------------------------------+

=
=A0Correction should be:
"R-4 =A0 "Tunnel traffic class=
", if provided, is the IPv6 traffic class that BRs and CEs MUST set in=
 Tunnel packets. =A0Without it, Explicit Congestion Notification of [RFC316=
8] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations.&quo=
t;


Thanks for the opportunity to notice this inconsistency.
2.
IPv4 time-to-live of an IPv4 may thus progress by =
more than one during domain traversal, right, but this isn't a breach t=
o IPv4 end-to-end transparency (the TTL is THE field that always evolve dur=
ing network traversal). =A0






2) 4rd-U draft, at R-33, states its IPv6-do=
main-generated ICMPv6 message will be translated to ICMPv4 with the logic o=
f RFC6145 Sec 5.2. please note that RFC6145 Sec 5.2 is a typical behavior o=
f translation rather than encapsulation. for the encapsulation, the semanti=
cs of ICMPv6 message processing should be quite different (cf. RFC2473, Sec=
 8.) (btw, 4rd-U draft 03 contains the RFC2473 in the reference list but ne=
ver cites it in the main text).=A0



1.=A0How an IPv6-generated ICMP mes=
sage is translated into an IPMPv4 message, doesn't belong to "IPv4=
 transparency".

"belo=
ngs to" or not is only a text gaming. i focus on the behavior: you sta=
ted it is "as encapsulation" and therefore i argue its behavior i=
s not encapsulation behavior at all.=A0


=A0
2.=A0MAP-E has the same need. Otherwise unreachable CEs couldn&#=
39;t be signaled to IPv4 sources, right?



MAP-E applying any existing encapsul=
ation standard such as RFC2473 or GRE as the packet processing method surel=
y has been ready for that. the same need has been satisfied without need to=
 define again. it could be emphasize the RFC2473's ICMPv6-to-ICMPv4 pro=
cessing is consistent with the semantics of "virtual link" which =
the encapsulation contributes to the Internet architecture.=A0


=A0

The point remains that 4rd-U is "as transpar=
ent to IPv4 as MAP-E".=A0



narrow sense transparency, no proble=
m in wording. but i suppose people are concerning the behavior rather than =
the wording itself.=A0
=A0


This is AFAIK a simple and importa=
nt fact (it was designed for that).=A0


<=
div>
=


if we say some fields are transparent, that's ok.

 but if we are talking about the IP as a whole, TRANSPARENCY implies not o=
nly the consistency of packet header fields but also the behavior of hiding=
 details of the carrying underlay infrastructure.



Agreed.
(But w=
ith due understanding of the exception of time-to-live: it always decreases=
 end to end, and more or less depending on peculiarities of traversed infra=
structures).=A0



encapsulation makes underlay a=
s a link-layer, and certainly the TTL only decreases by 1 if no trouble. de=
creasing as the same in the underlay network is the behavior of translation=
. it exposes the details of the underlay and therefore not transparent as e=
ncapsulation.=A0



best,
maoke
=A0




Regards,
RD



=A0



best,
maoke
=A0
- yet works=
 with IPv6-only port-based ACLs and IPv6 Web caches.



In my understanding, 4rd-H is indeed such a solution (and is the only =
one on the table).
=A0

Regards,
RD

PS:=A0Relationship of 4rd-U with single trans=
lation XLATs of RFC6145 is a different subject which deserves a discussion =
thread with another title.






...






--f46d0418256ef5bad804b912ffe0--

From despres.remi@laposte.net  Thu Feb 16 03:28:18 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DCA21F8768 for ; Thu, 16 Feb 2012 03:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.303,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytBiF8Ynle5O for ; Thu, 16 Feb 2012 03:28:17 -0800 (PST)
Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id F011B21F8764 for ; Thu, 16 Feb 2012 03:28:16 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id abUD1i00837Y3f403bUDiN; Thu, 16 Feb 2012 12:28:15 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 16 Feb 2012 12:28:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net> 
To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Satoru Matsushima 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 11:28:18 -0000

Ole, Satoru-san,

Le 2012-02-15 =E0 21:03, Ole Tr=F8an a =E9crit :

> Remi,
>=20
>> Your comments about the following feature-comparison item have been:
>> - "possible with MAP-{E,T} too, but may require coordination of =
subnet numbering."
>> - "I don't see the point of having text in the specification for this =
use case. it is a deployment option."
>>=20
>> +----+--------------------------------------+-----+-----+-----+-----+
>> |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
>> |    |                                      |  -T |  -E |  -H |  -E |
>> +----+--------------------------------------+-----+-----+-----+-----+
>> ...
>> |    |                                      |     |     |     |     |
>> |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
>> |    | third-party CPEs                     |     |     |     |     |
>>=20
>> But, AFAIK, it is not possible to configure a MAP domain for CEs =
attached to third-party CPEs (ref. use case 5.2.2 of the 4rd-U draft).
>>=20
>> 2.
>> To deal with some similar use cases, we had an optional Suffix =
parameter of Mapping rules in draft draft-despres-intarea-4rd-01 (of =
which co-authors were R. Despr=E9s, S. Matsushima, T. Murakami, ... and =
yourself).
>>=20
>> Having not seen in the WG that the need had disappeared, nor that =
another way to satisfy the need had been discussed, I did include the =
Suffix parameter in 4rd-U.
>>=20
>> 3.
>> A somewhat detailed explanation about this need, received in the past =
and IMHO clarifying, was something like this:
>>=20
>> "For the instance, in Japan, NTT provides the access line to the =
end-users and ISPs provides the internet service over this access line. =
Sometimes, NTT CPE is located in front of the ISP's 4rd CE. Sometimes, =
only the ISP's 4rd CE is located at home as shown below.
>>=20
>> ---- NTT CPE ---- ISP CE ----
>>=20
>> ---- ISP CE --
>=20
> I would not expect those two cases would be in the same MAP domain. =
even though they could.
>=20
>> It depends on the end-users' contract. If the end-user is getting =
some services from NTT, the NTT CPE is located at home and the ISP CE is =
located behind the NTT CE. If the end-user is not getting such a =
service, only ISP CE is located at home.
>=20
> not quite. see Satoru-san's presentation from the Paris last week for =
details.

Where can I get it, or at least the relevant part?
(If the problem has changed, I will of course acknowledge and adapt.)

>=20
>> In both cases, the IPv6 network infrastructure assigns an IPv6 prefix =
to the customer site. If present, the NTT CPE receives an IPv6 prefix =
and then delegates a longer IPv6 prefix to the ISP CE. For example, a =
/48 IPv6 prefix is assigned to the NTT CPE, and the NTT CPE delegates a =
/52 after adding a 4bit suffix to the ISP CE. But in other cases, if the =
ISP CE is directly connected to the IPv6 network infrastructure, the ISP =
CE can get an IPv6 prefix without any suffix.
>>=20
>> So, in one 4rd domain, some ISP CEs get shorter IPv6 prefixes =
directly from the IPv6 network (say /48) and some other ISP CEs get =
longer IPv6 prefixes from NTT CPEs (say /52). This means that the =
delegated IPv6 prefix consists of the Domain IPv6 prefix followed by EA =
bits, if the ISP CE is directly connected to the IPv6 network, and that =
the delegated prefix consists of the Domain IPv6 prefix, followed by EA =
bits, and followed by the added suffix if the ISP CE is connected to =
another CE."
>=20
> the End-user IPv6 prefix must be of the same length for all CEs using =
the same mapping rule.

Indeed.
However, if needed, there can be several mapping rules.

>> 4.
>> Without a suffix parameter in mapping rules that applies to CEs =
behind a third-party CPEs, CPE added suffixes would be included in EA =
bits. They would therefore be present as lower parts of PSIDs of CE that =
have shared IPv4 addresses.=20
>> I don't see how this could work.=20
>=20
> incorrect, MAP includes an EA-bits length parameter. the EA-bits are =
included in the topmost End-user IPv6 prefix (in your example above).

Not sure, Ole, what you find "incorrect".=20
Are you making some assumptions that you don't express (see below)?


>> 5.
>> Of course, the suffix parameter can be added to MAP if decided (no =
problem with that), but the feature comparison table remains based on =
existing drafts.
>=20
> not, needed. the MAP subnet-id is defined to be 0.

AFAIK, this statement makes sense only if you assume that the 4-bit NTT =
suffix is set to 0 in all customer sites.
If this is assumed, it is a great simplification of the problem.
It deserves to be clearly stated.
=20
With this assumption, the suffix parameter is indeed no longer needed =
(not more for 4rd-U than for MAP).


>> Hoping this clarifies this issue, I welcome questions and comments =
from anyone in the WG, in particular from the MAP design team.
>=20
> MAP supports "3rd party CPEs".

> (assuming all the other problems associated with provisioning are =
resolved.)

Which problem?
Being explicit would help.

> it also solves the case of directly connected and 3rd party CPEs =
within the same MAP domain.

Based on the assumption of CPE prefixes routed to CEs are always 0?

> albeit I've never ever heard that as a real use case.

Conclusion:=20
Unless the need to support arbitrary-value suffixes in third-party CPEs, =
which was expressed as a firm requirement in the past, is confirmed in =
the WG, I will delete the suffix parameter in the next 4rd-U draft (a =
nice simplification :-)).


I added you, Satoru-san, as destination of this mail, in order to have =
your direct view what remains useful and what has ceased to be needed.

Thanks,
RD =20




>=20
> cheers,
> Ole
>=20


From ichiroumakino@gmail.com  Thu Feb 16 04:52:53 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5453821F85C5 for ; Thu, 16 Feb 2012 04:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXEeh-9dEmI6 for ; Thu, 16 Feb 2012 04:52:51 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0A321F85B9 for ; Thu, 16 Feb 2012 04:52:49 -0800 (PST)
Received: by wgbdt10 with SMTP id dt10so1342369wgb.13 for ; Thu, 16 Feb 2012 04:52:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=RYH5Pgu756bVcDDFOo0ghPzEIivoO38dMDgmI70Ia00=; b=ejCb6Z23VjDbBlLpbR+qvSUZTKImrZe2tQd2nMBBgzpxXGvg/4W3oEMulfYZY/btF/ rFfX2Lpq2YwRiSdVJl0z8DqaNG6sAas2e30CegWvM+GnZvUU7JtwDuMhPHSdxt8UIffF 7o27YNEVVWe1MJN3VAkqYF7kQyrCwv7LAh4wQ=
Received: by 10.180.103.97 with SMTP id fv1mr4284964wib.17.1329396768488; Thu, 16 Feb 2012 04:52:48 -0800 (PST)
Received: from [10.147.11.77] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gd8sm3580316wib.2.2012.02.16.04.52.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 04:52:47 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Thu, 16 Feb 2012 13:52:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <62997F18-759C-4213-BB8D-92B3909D9EEE@employees.org>
References: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>  
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG 
Subject: Re: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 12:52:53 -0000

Remi,

[...]

>>> 5.
>>> Of course, the suffix parameter can be added to MAP if decided (no =
problem with that), but the feature comparison table remains based on =
existing drafts.
>>=20
>> not, needed. the MAP subnet-id is defined to be 0.
>=20
> AFAIK, this statement makes sense only if you assume that the 4-bit =
NTT suffix is set to 0 in all customer sites.
> If this is assumed, it is a great simplification of the problem.
> It deserves to be clearly stated.

MAP specifies a subnet-id of 0. those are the bits between the End-user =
IPv6 prefix length and the interface-id.
e.g. if a /56 is delegated there will be 8 bits of 0. we have discussed =
if this needs to be configurable.

> With this assumption, the suffix parameter is indeed no longer needed =
(not more for 4rd-U than for MAP).

regardless of what the suffix parameter is. 0xF or 0x0. it has to be the =
same across the domain.
in the 3rd party CPE use case, which prefixes are available to the 3rd =
party CPE may be outside of your control.

the 3rd party model has the following issues:
 - how to get routing for the MAP prefix
 - how does prefix assignment work at all (general IPv6 problem)
 - how is the mechanism provisioned? there is no DHCPv6 path, unless the =
3rd party CPE has a tunnel
   "home"

cheers,
Ole



From despres.remi@laposte.net  Thu Feb 16 05:16:12 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7236621F8710 for ; Thu, 16 Feb 2012 05:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level: 
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.295,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlvbUhC5zJRl for ; Thu, 16 Feb 2012 05:16:12 -0800 (PST)
Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 83AEE21F86DE for ; Thu, 16 Feb 2012 05:16:11 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id adG81i00237Y3f403dG8GP; Thu, 16 Feb 2012 14:16:09 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <62997F18-759C-4213-BB8D-92B3909D9EEE@employees.org>
Date: Thu, 16 Feb 2012 14:16:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>   <62997F18-759C-4213-BB8D-92B3909D9EEE@employees.org>
To: =?iso-8859-1?Q?Ole_Tr=F8an?= 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 13:16:12 -0000

Le 2012-02-16 =E0 13:52, Ole Tr=F8an a =E9crit :

> Remi,
>=20
> [...]
>=20
>>>> 5.
>>>> Of course, the suffix parameter can be added to MAP if decided (no =
problem with that), but the feature comparison table remains based on =
existing drafts.
>>>=20
>>> not, needed. the MAP subnet-id is defined to be 0.
>>=20
>> AFAIK, this statement makes sense only if you assume that the 4-bit =
NTT suffix is set to 0 in all customer sites.
>> If this is assumed, it is a great simplification of the problem.
>> It deserves to be clearly stated.
>=20
> MAP specifies a subnet-id of 0. those are the bits between the =
End-user IPv6 prefix length and the interface-id.
> e.g. if a /56 is delegated there will be 8 bits of 0. we have =
discussed if this needs to be configurable.

Discussed, OK, but concluded what?
BTW, if the MAP team debates would be on a list having ITEF archives, =
contributions by members of the WG would be easier, IMHO.
Could you ask the WG chair to open such a mailing list?


>> With this assumption, the suffix parameter is indeed no longer needed =
(not more for 4rd-U than for MAP).
>=20
> regardless of what the suffix parameter is. 0xF or 0x0. it has to be =
the same across the domain.

Having it the same for CEs whose IPv6 prefixes match the same mapping =
rule could be more flexible, but agreed, imposing that it is the same =
for each domain should be sufficient (this is the choice made for =
4rd-U).=20

=20
> in the 3rd party CPE use case, which prefixes are available to the 3rd =
party CPE may be outside of your control.

In this case, a Domain IPv6 suffix is needed.
The question therefore  remains: is there a need or not to support this =
use case.

Without a response from Satoru-san, it might be assumed, by default, =
that the NTT CPE example is no longer of interest.
But, if the need is confirmed, a Domain IPv6 suffix is AFAIK needed.=20
=20
>=20
> the 3rd party model has the following issues:
> - how to get routing for the MAP prefix
> - how does prefix assignment work at all (general IPv6 problem)

Not understood.

> - how is the mechanism provisioned? there is no DHCPv6 path, unless =
the 3rd party CPE has a tunnel
>   "home"

The use case description includes that the NTT CPE of a /48 site =
delegates a /52 prefix to the CE.
Isn't this sufficient?

RD

BTW, you asked me, to understand one of your points to "see Satoru-san's =
presentation from the Paris last week for details" .
Can you provide what I should see (or replace it in some way)?



>=20
> cheers,
> Ole
>=20
>=20


From Tina.Tsou.Zouting@huawei.com  Thu Feb 16 06:07:03 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A4A21F877B for ; Thu, 16 Feb 2012 06:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level: 
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYD+PjpRQF47 for ; Thu, 16 Feb 2012 06:07:03 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8621F8773 for ; Thu, 16 Feb 2012 06:07:02 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00JWNOJK3X@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 16 Feb 2012 22:06:56 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZH00GYKOIVM2@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 16 Feb 2012 22:06:56 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGW86804; Thu, 16 Feb 2012 22:06:55 +0800
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Feb 2012 22:06:45 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.64]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 16 Feb 2012 22:07:19 +0800
Date: Thu, 16 Feb 2012 14:06:46 +0000
From: Tina TSOU 
In-reply-to: 
To: Maoke 
Message-id: <1DD7B5A7-BFBA-43CA-A55A-8E77D39E1FE6@huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_CCNKfyoDVA8RuOonm2PrYw)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [Softwires] [softwire] Merged version of lightweight 4over6
Thread-index: AQHM67TbW0deHUyxL0GeDRlK7kAql5Y92foAgAB0AICAABKNgIAABqeAgAEp10Y=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 14:07:03 -0000

--Boundary_(ID_CCNKfyoDVA8RuOonm2PrYw)
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: quoted-printable



Sent from my iPad

On Feb 16, 2012, at 5:21 AM, "Maoke" > wrote:


2012/2/16 Lee, Yiu >
Hi Maoke,

There are always trade-offs. We can suggest few options and ask the WG to c=
hoose one.

good point. acceptable. :) - maoke


1) Let the host to reassemble the fragmented packets
2) Let the 4o6 TC to assemble the fragmented packets
2) may be easier.
3) Don=92t suggest anything and leave this open for implementation

/Yiu


From: Maoke >
Date: Thu, 16 Feb 2012 11:50:33 +0900
To: "Yiu L. LEE" >
Cc: Qiong >, "softwires@iet=
f.org" >

Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6

the "since we believe" is true in the term that client/server model is domi=
nating the Internet usage. but the situation is changing, AFTR might suffer=
 a heavy burden with reassembly in the environment where p2p is dominating.=
 can we (actually you authors) surely state lightweight 4over6 improves thi=
s? if we can, it is a happy point. ;-)



--Boundary_(ID_CCNKfyoDVA8RuOonm2PrYw)
Content-type: text/html; charset=Windows-1252
Content-transfer-encoding: quoted-printable











Sent from my iPad




On Feb 16, 2012, at 5:21 AM, "Maoke" <fibrib@gmail.com> wrote:

















2012/2/16 Lee, Yiu <Yiu_Lee@cable.comcast.com>






Hi Maoke,







There are always trade-offs. We can suggest few options and ask the WG=
 to choose one. 











good point. acceptable. :) - maoke


 











1) Let the host to reassemble the fragmented packets


2) Let the 4o6 TC to assemble the fragmented packets











2) may be easier.












3) Don=92t suggest anything and leave this open for implementation






/Yiu














From: Maoke <fibrib@gmail.com>

Date: Thu, 16 Feb 2012 11:50:33 =
3;0900

To: "Yiu L. LEE" <yiu_lee@cable.co=
mcast.com>

Cc: Qiong <bingxuere@gmail.com>, "softwires@ietf.org&=
quot; <softwires=
@ietf.org>



Subject: Re: [Softwires] [softwire]=
 Merged version of lightweight 4over6














the "since we believe" is true in the term that client/serve=
r model is dominating the Internet usage. but the situation is changing, AF=
TR might suffer a heavy burden with reassembly in the environment where p2p=
 is dominating. can we (actually you authors)
 surely state lightweight 4over6 improves this? if we can, it is a happy po=
int. ;-) 


























--Boundary_(ID_CCNKfyoDVA8RuOonm2PrYw)--

From satoru.matsushima@gmail.com  Thu Feb 16 06:29:54 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E2221F87AE for ; Thu, 16 Feb 2012 06:29:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+0hi9ngXOQY for ; Thu, 16 Feb 2012 06:29:53 -0800 (PST)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94D0D21F871D for ; Thu, 16 Feb 2012 06:29:53 -0800 (PST)
Received: by dakl33 with SMTP id l33so2221874dak.31 for ; Thu, 16 Feb 2012 06:29:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DYIGAwRv+IAVL2fng9lF5SF3Yzfw9wVUycoEFiWt7iA=; b=mKHiAMrc2OPx5ArZsk9Ps41vRvOQBDyQfUIjaorlOuclelTZc+j947iJZoEaWtbn91 lqbnpmvwFCRlFc2Ao76RAViC9fqEZvqw16QKbAoady1tCWZOeQ4qBWX6OGqN+m7pTf98 3BDlnbGkUgjrodRFKHsu/7AxYP7R0WZtjRYng=
Received: by 10.68.135.137 with SMTP id ps9mr14403277pbb.40.1329402593449; Thu, 16 Feb 2012 06:29:53 -0800 (PST)
Received: from [192.168.3.4] (softbank221038134212.bbtec.net. [221.38.134.212]) by mx.google.com with ESMTPS id q1sm2456457pbv.49.2012.02.16.06.29.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 06:29:52 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Satoru Matsushima 
In-Reply-To: 
Date: Thu, 16 Feb 2012 23:29:48 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <515ED64B-8F66-4352-8D52-202D11CDF4B2@gmail.com>
References: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>   <62997F18-759C-4213-BB8D-92B3909D9EEE@employees.org> 
To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= 
X-Mailer: Apple Mail (2.1251.1)
Cc: Softwires WG 
Subject: Re: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 14:29:54 -0000

Hi Remi-san, Ole-san,

I still think that configurable suffix would help a case where a MAP CE =
cascaded another IPv6 CPE. On the other hand, it is true that second =
issue, which Ole-san pointed out that there's difficulty to predict =
stable prefix for MAP in that case, which mean MAP wouldn't work because =
the suffix would be varied through the MAP domain. IMO it isn't an issue =
to be solved by MAP specification, the issue is in IPv6 home networking. =
When the issue is solved, to be able to configurable suffix in MAP =
specification will be discussed. Until then it might be possible that I =
can assume that MAP CE always get stable suffix value for MAP in a =
specific case even in Japan.=20

> The use case description includes that the NTT CPE of a /48 site =
delegates a /52 prefix to the CE.
> Isn't this sufficient?

It is one of variation. There's another case where you get just a /64 =
through RA. Which prefix length you get isn't related to Internet =
service.=20

> BTW, you asked me, to understand one of your points to "see =
Satoru-san's presentation from the Paris last week for details" .
> Can you provide what I should see (or replace it in some way)?

I'll send it you later.

cheers,
--satoru

On 2012/02/16, at 22:16, R=E9mi Despr=E9s wrote:

>=20
> Le 2012-02-16 =E0 13:52, Ole Tr=F8an a =E9crit :
>=20
>> Remi,
>>=20
>> [...]
>>=20
>>>>> 5.
>>>>> Of course, the suffix parameter can be added to MAP if decided (no =
problem with that), but the feature comparison table remains based on =
existing drafts.
>>>>=20
>>>> not, needed. the MAP subnet-id is defined to be 0.
>>>=20
>>> AFAIK, this statement makes sense only if you assume that the 4-bit =
NTT suffix is set to 0 in all customer sites.
>>> If this is assumed, it is a great simplification of the problem.
>>> It deserves to be clearly stated.
>>=20
>> MAP specifies a subnet-id of 0. those are the bits between the =
End-user IPv6 prefix length and the interface-id.
>> e.g. if a /56 is delegated there will be 8 bits of 0. we have =
discussed if this needs to be configurable.
>=20
> Discussed, OK, but concluded what?
> BTW, if the MAP team debates would be on a list having ITEF archives, =
contributions by members of the WG would be easier, IMHO.
> Could you ask the WG chair to open such a mailing list?
>=20
>=20
>>> With this assumption, the suffix parameter is indeed no longer =
needed (not more for 4rd-U than for MAP).
>>=20
>> regardless of what the suffix parameter is. 0xF or 0x0. it has to be =
the same across the domain.
>=20
> Having it the same for CEs whose IPv6 prefixes match the same mapping =
rule could be more flexible, but agreed, imposing that it is the same =
for each domain should be sufficient (this is the choice made for =
4rd-U).=20
>=20
>=20
>> in the 3rd party CPE use case, which prefixes are available to the =
3rd party CPE may be outside of your control.
>=20
> In this case, a Domain IPv6 suffix is needed.
> The question therefore  remains: is there a need or not to support =
this use case.
>=20
> Without a response from Satoru-san, it might be assumed, by default, =
that the NTT CPE example is no longer of interest.
> But, if the need is confirmed, a Domain IPv6 suffix is AFAIK needed.=20=

>=20
>>=20
>> the 3rd party model has the following issues:
>> - how to get routing for the MAP prefix
>> - how does prefix assignment work at all (general IPv6 problem)
>=20
> Not understood.
>=20
>> - how is the mechanism provisioned? there is no DHCPv6 path, unless =
the 3rd party CPE has a tunnel
>>  "home"
>=20
> The use case description includes that the NTT CPE of a /48 site =
delegates a /52 prefix to the CE.
> Isn't this sufficient?
>=20
> RD
>=20
> BTW, you asked me, to understand one of your points to "see =
Satoru-san's presentation from the Paris last week for details" .
> Can you provide what I should see (or replace it in some way)?
>=20
>=20
>=20
>>=20
>> cheers,
>> Ole
>>=20
>>=20
>=20


From despres.remi@laposte.net  Thu Feb 16 07:43:53 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2014B21F85AE for ; Thu, 16 Feb 2012 07:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level: 
X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JR54EDHI+NB for ; Thu, 16 Feb 2012 07:43:52 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 27AE521F87E9 for ; Thu, 16 Feb 2012 07:43:50 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 90003940204; Thu, 16 Feb 2012 16:43:40 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <515ED64B-8F66-4352-8D52-202D11CDF4B2@gmail.com>
Date: Thu, 16 Feb 2012 16:43:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <18CC9DB3-64ED-4259-8FCA-9975611BDD64@laposte.net>   <62997F18-759C-4213-BB8D-92B3909D9EEE@employees.org>  <515ED64B-8F66-4352-8D52-202D11CDF4B2@gmail.com>
To: Satoru Matsushima 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 15:43:53 -0000

Thank you, Satoru-san, for the bringing more information on this issue.
More comments in line.

Le 2012-02-16 =E0 15:29, Satoru Matsushima a =E9crit :

> Hi Remi-san, Ole-san,
>=20
> I still think that configurable suffix would help a case where a MAP =
CE cascaded another IPv6 CPE.

OK.
What there is today in 4rd-U may not be sufficient, but we can work to =
complete it if possible.
Actually, I now doubt that it is the right choice to have the suffix as =
Domain parameter instead of a per-rule parameter. (We had it as a =
per-rule parameter in the intarea-4rd draft.)

If there can be a Suffix per mapping rule, it seems to me we can =
configure mapping rules for all practical situations you have in mind.
In order to validate or invalidate this belief, would it be possible to =
have more details about some reference configurations that need to be =
supported?=20

> On the other hand, it is true that second issue, which Ole-san pointed =
out that there's difficulty to predict stable prefix for MAP in that =
case, which mean MAP wouldn't work because the suffix would be varied =
through the MAP domain.

Configuring several mapping rules, each one with its own IPv6 prefix, =
IPv4 prefix, and Rule IPv6 suffix, looks like a viable approach.

> IMO it isn't an issue to be solved by MAP specification, the issue is =
in IPv6 home networking. When the issue is solved, to be able to =
configurable suffix in MAP specification will be discussed. Until then =
it might be possible that I can assume that MAP CE always get stable =
suffix value for MAP in a specific case even in Japan.=20

If in addition this stable suffix can always be 0, that could indeed a =
short term solution.
But I don't understand why it would be needed to wait for IPv6 home =
networking to evolve before providing a satisfactory solution.

>=20
>> The use case description includes that the NTT CPE of a /48 site =
delegates a /52 prefix to the CE.
>> Isn't this sufficient?
>=20
> It is one of variation. There's another case where you get just a /64 =
through RA. Which prefix length you get isn't related to Internet =
service.=20

Understood.
Remarks above still apply.


>> BTW, you asked me, to understand one of your points to "see =
Satoru-san's presentation from the Paris last week for details" .
>> Can you provide what I should see (or replace it in some way)?
>=20
> I'll send it you later.

Excellent, thank you.

Cheers,
RD






>=20
> cheers,
> --satoru
>=20
> On 2012/02/16, at 22:16, R=E9mi Despr=E9s wrote:
>=20
>>=20
>> Le 2012-02-16 =E0 13:52, Ole Tr=F8an a =E9crit :
>>=20
>>> Remi,
>>>=20
>>> [...]
>>>=20
>>>>>> 5.
>>>>>> Of course, the suffix parameter can be added to MAP if decided =
(no problem with that), but the feature comparison table remains based =
on existing drafts.
>>>>>=20
>>>>> not, needed. the MAP subnet-id is defined to be 0.
>>>>=20
>>>> AFAIK, this statement makes sense only if you assume that the 4-bit =
NTT suffix is set to 0 in all customer sites.
>>>> If this is assumed, it is a great simplification of the problem.
>>>> It deserves to be clearly stated.
>>>=20
>>> MAP specifies a subnet-id of 0. those are the bits between the =
End-user IPv6 prefix length and the interface-id.
>>> e.g. if a /56 is delegated there will be 8 bits of 0. we have =
discussed if this needs to be configurable.
>>=20
>> Discussed, OK, but concluded what?
>> BTW, if the MAP team debates would be on a list having ITEF archives, =
contributions by members of the WG would be easier, IMHO.
>> Could you ask the WG chair to open such a mailing list?
>>=20
>>=20
>>>> With this assumption, the suffix parameter is indeed no longer =
needed (not more for 4rd-U than for MAP).
>>>=20
>>> regardless of what the suffix parameter is. 0xF or 0x0. it has to be =
the same across the domain.
>>=20
>> Having it the same for CEs whose IPv6 prefixes match the same mapping =
rule could be more flexible, but agreed, imposing that it is the same =
for each domain should be sufficient (this is the choice made for =
4rd-U).=20
>>=20
>>=20
>>> in the 3rd party CPE use case, which prefixes are available to the =
3rd party CPE may be outside of your control.
>>=20
>> In this case, a Domain IPv6 suffix is needed.
>> The question therefore  remains: is there a need or not to support =
this use case.
>>=20
>> Without a response from Satoru-san, it might be assumed, by default, =
that the NTT CPE example is no longer of interest.
>> But, if the need is confirmed, a Domain IPv6 suffix is AFAIK needed.=20=

>>=20
>>>=20
>>> the 3rd party model has the following issues:
>>> - how to get routing for the MAP prefix
>>> - how does prefix assignment work at all (general IPv6 problem)
>>=20
>> Not understood.
>>=20
>>> - how is the mechanism provisioned? there is no DHCPv6 path, unless =
the 3rd party CPE has a tunnel
>>> "home"
>>=20
>> The use case description includes that the NTT CPE of a /48 site =
delegates a /52 prefix to the CE.
>> Isn't this sufficient?
>>=20
>> RD
>>=20
>> BTW, you asked me, to understand one of your points to "see =
Satoru-san's presentation from the Paris last week for details" .
>> Can you provide what I should see (or replace it in some way)?
>>=20
>>=20
>>=20
>>>=20
>>> cheers,
>>> Ole
>>>=20
>>>=20
>>=20
>=20


From despres.remi@laposte.net  Thu Feb 16 10:01:47 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A0021F8888 for ; Thu, 16 Feb 2012 10:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.861
X-Spam-Level: 
X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PCN41dUb0i6 for ; Thu, 16 Feb 2012 10:01:45 -0800 (PST)
Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id A79B621F883A for ; Thu, 16 Feb 2012 10:01:43 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id ai1f1i00537Y3f403i1fkD; Thu, 16 Feb 2012 19:01:41 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-20-1068264892
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 16 Feb 2012 19:01:39 +0100
Message-Id: <822AE298-64F0-4D82-8074-ECB408D14D1C@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>  <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net>   
To: Maoke 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2012 18:01:47 -0000

--Apple-Mail-20-1068264892
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Le 2012-02-16 =E0 12:19, Maoke a =E9crit :

> 2012/2/16 R=E9mi Despr=E9s 
>=20
> Le 2012-02-16 =E0 03:34, Maoke a =E9crit=20
>> 2012/2/15 R=E9mi Despr=E9s 
>> 2012-02-15 =E0 03:15, Maoke a =E9crit :
>> =20
>>> "protocol unknown" should be detected and discarded at both CE and =
BR in their major module instead of the NAT44 part.
>>=20
>> I don't think so:
>> - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't =
exclude any protocol in packets sent to this CE.
>> - If a CE has a shared address, it needs a NAT that the CE informs it =
the restricted port set. This NAT already has all what is needed to =
refuse protocols it doesn't understand.=20
>>=20
>> what if my NAT has understood XXXP but your CE hasn't? to my =
understanding, CE only informs the restricted port set regardless of the =
protocol.=20
>=20
> 2 cases:
> - If the new protocol has ports at their usual place, and has TCP-like =
checksum, no problem. "Your CE", as you call it, does forward packets of =
the new protocol.=20
> - In other cases, any CE or BR would need needs an update to work, and =
incompatibilities cold result.=20
> =20
>=20
> ...
>=20
>>=20
>>> A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,
>>=20
>> Not SCTP today, for sure.
>> Also, as I think you know, there is uncertainty concerning DCCP =
because RFC6145 sec 4.5 says:
>> "Other transport protocols (e.g., DCCP) are OPTIONAL to support".
>>=20
>> it depends on the understanding of the "OPTIONAL". if it is OPTIONAL =
for the operation domain, it is not a problem for double translation. if =
it is OPTIONAL per device, the uncertainty is a problem where =
src-translator makes DCCP checksum rewrite but dst-translator doesn't. =
(inverse case, where src translator doesn't make but dst do, is not a =
problem though.)=20
>=20
> Optional "for the operation domain" would work only if there would be =
means to inform CEs of the choice made for the domain.
> Such means don't exist, right?
>=20
> agree. for this point, we'd prefer to propose an update to RFC6145 in =
order to clear the uncertainty, if the authors have not other concern we =
haven't noticed.=20

Seems good to me.
However, a specification change doesn't ensure that all devices support =
the change.=20
A problem therefore remains.

> =20
>=20
>=20
>> ok, i think we do understand your point but please check. you mean: =
if addresses are checksum-neutral, we don't need to have a list of =
supported protocol in BR and just let it pass any protocol with the =
assumption that it is TCP-layouted/checksumed. if the "any protocol" =
happens to really have TCP-layout and TCP-checksum, then things are =
happy and the addresses have ensured the checksum validity even without =
L4 rewrite. if the "any protocol", unfortunately, happens to have =
another layout and/or another checksum, then BR also treat it as it were =
TCP-layouted/checksumed but let it fail at the end host or CE. right?
>=20
> Yes.
> We are in sync on this point.
>=20
> good. thanks!
> =20
>=20
>>=20
>> here it is what i said R-22 (3) in 4rd-U is dangerous. it says:=20
>>=20
>>    + If the packet Protocol is not ICMP, bits 0-15 for an
>>    IPv4 source address, and bits 16-31 for a destination
>>    address.
>>=20
>> well doesn't it mean: even if the protocol has another layout, R-22 =
(3)'s BR prefer to ignore the fact, making messy mapped addresses with =
blindly assuming the protocol follows the TCP-layout!? (there is no =
NAT44 before BR to ensure the "unknown" protocol has been dropped.) i =
would further point out that, the messy mapped destination address may =
navigate your packet in a wrong direction towards a wrong CE where even =
the "fail at end" may fail.
>=20
> Still a misunderstanding here.
> No new protocol will work for shared IPv4 addresses, be it with MAP or =
4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their =
usual place, and a TCP-like checksum somewhere).
> A NAT44 that is coupled with a CE MUST remain operational ONLY for =
"traditional" protocols.
>=20
> (Future protocols, if not "traditional", will need IPv6 to work =
safely, including with shared-IPv4-address CEs.
>=20
> it confuses me.

> if there is no new protocol, where we have the talking topic on the =
*change* of BR? neither MAP nor 4rd-U needs change if there is no new =
protocol.

Clear.

> if there is new protocol in consideration, how do you assert such a =
new protocol surely not work for shared IPv4 addresses unless it is a =
"traditional" one?

Yes, I do suggest that a transition tool such as MAP/4rd shouldn't be =
modified to support a new protocol that would have been be specified =
with consciousness that it is difficult to support in NAT44s.

> do you mean non-traditional protocol is nonsense and we have no =
obligation to consider?

A nonsense, by no means!
Defining new protocols, even with non-TCP checksum, can make a lot of =
sense, but only in the context of IPv6.


> or do you mean, new protocol working with shared IPv4 addresses must =
be traditional?=20

My point is that any new protocol that should work for hosts having IPv4 =
shared addresses SHOULD use the TCP-like checksum, yes.
(I use SHOULD instead of MUST because we talk about the future, which is =
uncertain by nature.)


>> therefore i do agree Ole's argument. because we think any protocol =
should be certainly supported, or certainly reported as not-supported, =
rather than blindly trying a seemingly "universal" logic.=20
>=20
> 1.
> I don't know which "Ole's argument" you agree to (making your own =
points directly would be clearer).
>=20
> i think i focuses on the point that the "BR needs no change ...".=20
> =20
> =20
> - In particular, Ole wrote "any A+P solution requires support for L4 =
protocols to extract ports. L4 checksum rewrite, as well as port =
extraction will have to be supported for all new L4 protocols."
> - The fact is that 4rd-U, because of checksum neutrality, doesn't have =
to support L4 checksum rewrite. Yet, it is an A+P solution that has no =
identified operational problem.
>=20
> 2.
> 4rd-U "certainly" supports All "traditional" protocols, an Echo =
requests in identified conditions,  and nothing else.
> MAP-T is AFAIK uncertain for DCCP.
>=20
> MAP-T has been in running code and it is not complicated to remove the =
uncertainty with changing the OPTIONAL to a definite word, unless there =
is something we haven't noticed.=20

This point has no relationship with the fact that checksum neutrality =
provides BR support of all L4 protocols using TCP-like checksum.


>>> btw, regarding the below "new standard for a new problem", i'd like =
to emphasize it is not a new problem as RFC6052 has discussed it. it is =
an incorrect understanding to think RFC6052/RFC6145 is designed only for =
single translation. since the very beginning of the stateless address =
mapping/translation design, the single and double translations have =
being considered.=20
>>=20
>> I have no intention to negate anything about what designers of =
RFC6052/6145 considered (I wasn't there ;-)).
>>=20
>> The problem which IS NEW is how to design a stateless v4/v6 solution =
that:
>> - is AS TRANSPARENT to IPv4 as encapsulation, without any restriction =
or doubt
>>=20
>> NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2 =
points:=20
>>=20
>> 1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. =
this is not a behavior of encapsulation but a behavior of translation.=20=

>=20
> 1.
> Well, there remains an inconsistency that I didn't see in the 4rd-U =
draft(!):=20
> - "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic =
class that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel =
traversal is treated in IPv4 as a single-link traversal.
>=20
> right, here the "single-link traversal" causes TTL decreases more than =
1. well, you removed this self-contradictory.=20
> =20
> Without it, Explicit Congestion Notification of [RFC3168] MAY be =
propagated from intermediate IPv6 nodes to IPv4 destinations,


> and IPv4 Time to live values progress with the number of traversed =
IPv6 links."

Note that this part of the sentence no longer appears in the revised R-4=20=


>=20
> misunderstanding!=20

> please note that ECN being propagated from intermediate IPv6 to IPv4 =
is correct even for the mode of encapsulation!

Exactly, where it it applies in 4rd-U (no Tunnel traffic class =
parameter) it does it for both -H AND -E.=20


> because congestion is a link-wise behavior. RFC3168 Sec 9 discussed =
this and its succeeding updates RFC6040 takes a huge effort in order to =
achieve compatibility among different processing proposals regarding the =
potential inconsistency between the outer header's ECN and inner =
header's ECN. the basic operation is: tunnel entry point should copy ECN =
from inner to outer header while tunnel exit should copy ECN from outer =
to inner.=20

Right=20

>=20
> - Table 2 has:
> +---------------------+-----------------------------------+
> | IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT         |
> +---------------------+-----------------------------------+
>                     ...
> | Time to live        | Hop limit                         |
>                     ...
> +---------------------+-----------------------------------+
>=20
>  Correction should be:
> "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class =
that BRs and CEs MUST set in Tunnel packets.  Without it, Explicit =
Congestion Notification of [RFC3168] MAY be propagated from intermediate =
IPv6 nodes to IPv4 destinations."
> Thanks for the opportunity to notice this inconsistency.
>=20
> 2.
> IPv4 time-to-live of an IPv4 may thus progress by more than one during =
domain traversal, right, but this isn't a breach to IPv4 end-to-end =
transparency (the TTL is THE field that always evolve during network =
traversal). =20
>=20
>=20
>> 2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 =
message will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. =
please note that RFC6145 Sec 5.2 is a typical behavior of translation =
rather than encapsulation. for the encapsulation, the semantics of =
ICMPv6 message processing should be quite different (cf. RFC2473, Sec =
8.) (btw, 4rd-U draft 03 contains the RFC2473 in the reference list but =
never cites it in the main text).=20
>=20
> 1. How an IPv6-generated ICMP message is translated into an IPMPv4 =
message, doesn't belong to "IPv4 transparency".
>=20
> "belongs to" or not is only a text gaming. i focus on the behavior:

> you stated it is "as encapsulation" and therefore i argue its behavior =
is not encapsulation behavior at all.=20

4rd-H IS NOT "encapsulation" (not more than it is "double translation").
The only claim is that it is, end-to end, as transparent to IPv4 packets =
as encapsulation.


> =20
> 2. MAP-E has the same need. Otherwise unreachable CEs couldn't be =
signaled to IPv4 sources, right?
>=20
> MAP-E applying any existing encapsulation standard such as RFC2473 or =
GRE as the packet processing method surely has been ready for that. the =
same need has been satisfied without need to define again. it could be =
emphasize the RFC2473's ICMPv6-to-ICMPv4 processing is consistent with =
the semantics of "virtual link" which the encapsulation contributes to =
the Internet architecture.

I didn't see this ICMP translation in the BR behavior of the MAP-E draft =
sec. 5.2, but it certainly can be added.
In any case, this doesn't make 4rd-U less end-to-end transparent to IPv4 =
than encapsulation.


> The point remains that 4rd-U is "as transparent to IPv4 as MAP-E".=20
>=20
> narrow sense transparency, no problem in wording. but i suppose people =
are concerning the behavior rather than the wording itself.=20
> =20
> This is AFAIK a simple and important fact (it was designed for that).=20=

>=20
>=20
>> if we say some fields are transparent, that's ok.
>=20
>> but if we are talking about the IP as a whole, TRANSPARENCY implies =
not only the consistency of packet header fields but also the behavior =
of hiding details of the carrying underlay infrastructure.
>=20
> Agreed.
> (But with due understanding of the exception of time-to-live: it =
always decreases end to end, and more or less depending on peculiarities =
of traversed infrastructures).=20
>=20
> encapsulation makes underlay as a link-layer, and certainly the TTL =
only decreases by 1 if no trouble. decreasing as the same in the =
underlay network is the behavior of translation.

> it exposes the details of the underlay and therefore not transparent =
as encapsulation.=20

Different view (IMHO, this statement is just playing with words)

Regards,
RD



>=20
> best,
> maoke
> =20
>=20
>=20
> Regards,
> RD
>=20
>=20
>=20
>> =20
>>=20
>> best,
>> maoke
>> =20
>> - yet works with IPv6-only port-based ACLs and IPv6 Web caches.
>> In my understanding, 4rd-H is indeed such a solution (and is the only =
one on the table).
>> =20
>>=20
>> Regards,
>> RD
>>=20
>> PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is =
a different subject which deserves a discussion thread with another =
title.
>>=20
>>> ...
>>=20
>=20
>=20


--Apple-Mail-20-1068264892
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


2012/2/16 =
R=E9mi Despr=E9s <despres.remi@laposte.net><=
/span>



Le 2012-02-16 =E0 =
03:34, Maoke a =E9crit 
2012/2/15 R=E9mi Despr=E9s <despres.remi@laposte.net>


2012-02-15=
 =E0 03:15, Maoke a =E9crit =
:
 
"protocol unknown" should be detected and =
discarded at both CE and BR in their major module instead of the NAT44 =
part. 




I don't think =
so:
- If a CE has a non-shared =
address, or an IPv4 prefix, BRs shouldn't exclude any protocol in =
packets sent to this CE.


- If a CE has a shared address, it needs a NAT that the CE informs =
it the restricted port set. This NAT already has all what is needed to =
refuse protocols it doesn't understand. 



what if =
my NAT has understood XXXP but your CE hasn't? to my understanding, CE =
only informs the restricted port set regardless of the =
protocol. 



2 cases:
- If the new =
protocol has ports at their usual place, and has TCP-like checksum, no =
problem. "Your CE", as you call it, does forward packets of the new =
protocol. 


- In other cases, any CE or BR would need needs an update to work, =
and incompatibilities cold =
result. 
 

...






 A =
MAP-compliant device supports UDP, TCP, DCCP, SCTP =
today,

Not SCTP =
today, for sure.
Also, as I think you know, there is =
uncertainty concerning DCCP because RFC6145 sec 4.5 says:



"Other =
transport protocols (e.g., DCCP) are OPTIONAL to =
support".

it depends =
on the understanding of the "OPTIONAL". if it is OPTIONAL for the =
operation domain, it is not a problem for double translation. if it is =
OPTIONAL per device, the uncertainty is a problem where src-translator =
makes DCCP checksum rewrite but dst-translator doesn't. (inverse case, =
where src translator doesn't make but dst do, is not a problem =
though.) 



Optional "for the operation =
domain" would work only if there would be means to inform CEs of the =
choice made for the domain.
Such means don't exist, =
right?



agree. for this point, we'd =
prefer to propose an update to RFC6145 in order to clear the =
uncertainty, if the authors have not other concern we haven't =
noticed. 

Seems good to =
me.
However, a specification change doesn't ensure that all =
devices support the change. 
A problem therefore =
remains.


 





ok, i think we do understand your point but please check. you mean: =
if addresses are checksum-neutral, we don't need to have a list of =
supported protocol in BR and just let it pass any protocol with the =
assumption that it is TCP-layouted/checksumed. if the "any protocol" =
happens to really have TCP-layout and TCP-checksum, then things are =
happy and the addresses have ensured the checksum validity even without =
L4 rewrite. if the "any protocol", unfortunately, happens to have =
another layout and/or another checksum, then BR also treat it as it were =
TCP-layouted/checksumed but let it fail at the end host or CE. =
right?



Yes.
We are in =
sync on this =
point.

good. =
thanks!
 






here it is what i said R-22 (3) in 4rd-U is =
dangerous. it says: 

   +  If =
the packet Protocol is not ICMP, bits 0-15 for an
               =
   IPv4 source address, and bits 16-31 for a destination


                  address.

well =
doesn't it mean: even if the protocol has another layout, R-22 (3)'s BR =
prefer to ignore the fact, making messy mapped addresses with blindly =
assuming the protocol follows the TCP-layout!? (there is no NAT44 before =
BR to ensure the "unknown" protocol has been dropped.) i would further =
point out that, the messy mapped destination address may navigate your =
packet in a wrong direction towards a wrong CE where even the "fail at =
end" may fail.



Still a misunderstanding =
here.
No new protocol will work for shared IPv4 addresses, be =
it with MAP or 4rd-U BRs, if it isn't a "traditional" protocol (i.e. =
ports at their usual place, and a TCP-like checksum somewhere).


A NAT44 that is coupled with a CE MUST remain operational ONLY for =
"traditional" protocols.

(Future protocols, if =
not "traditional", will need IPv6 to work safely, including with =
shared-IPv4-address CEs.



it confuses me. =


if there is no new protocol, where we have =
the talking topic on the *change* of BR? neither MAP nor 4rd-U needs =
change if there is no new protocol. =


Clear.

if there is new protocol =
in consideration, how do you assert such a new protocol surely not work =
for shared IPv4 addresses unless it is a "traditional" one? =


Yes, I do suggest that a =
transition tool such as MAP/4rd shouldn't be modified to support a new =
protocol that would have been be specified with consciousness that it is =
difficult to support in NAT44s.

do you mean =
non-traditional protocol is nonsense and we have no obligation to =
consider? 

A nonsense, by no =
means!
Defining new protocols, even with non-TCP =
checksum, can make a lot of sense, but only in the context of =
IPv6.


or do you mean, new protocol working with =
shared IPv4 addresses must be =
traditional? 

My point =
is that any new protocol that should work for hosts having IPv4 shared =
addresses SHOULD use the TCP-like checksum, yes.
(I use SHOULD =
instead of MUST because we talk about the future, which is uncertain by =
nature.)








therefore i do agree Ole's argument. because we think any protocol =
should be certainly supported, or certainly reported as not-supported, =
rather than blindly trying a seemingly "universal" logic. 



1.
I don't know =
which "Ole's argument" you agree to (making your own points directly =
would be clearer).



i think i focuses on the point that the "BR needs no change =
...". 
 


 
- In particular, Ole wrote "any A+P =
solution requires support for L4 protocols to extract ports. L4 checksum =
rewrite, as well as port extraction will have to be supported for all =
new L4 protocols."


- The fact is that 4rd-U, because of checksum neutrality, doesn't =
have to support L4 checksum rewrite. Yet, it is an A+P solution that has =
no identified operational =
problem.

2.

4rd-U "certainly" supports All "traditional" protocols, an Echo =
requests in identified conditions,  and nothing =
else.
MAP-T is AFAIK uncertain for =
DCCP.



MAP-T has been in running code and it is not complicated to =
remove the uncertainty with changing the OPTIONAL to a definite word, =
unless there is something we haven't =
noticed. 

This point =
has no relationship with the fact that checksum neutrality provides BR =
support of all L4 protocols using TCP-like =
checksum.






btw, regarding the below "new standard for a new problem", i'd =
like to emphasize it is not a new problem as RFC6052 has discussed it. =
it is an incorrect understanding to think RFC6052/RFC6145 is designed =
only for single translation. since the very beginning of the stateless =
address mapping/translation design, the single and double translations =
have being considered. 




I have no intention to =
negate anything about what designers of =
RFC6052/6145 considered (I wasn't there =
;-)).

The problem which IS NEW is how to design =
a stateless v4/v6 solution that:



- is AS TRANSPARENT to IPv4 as encapsulation, without any =
restriction or doubt

NOT AS =
TRANSPARENT to IPv4 as encapsulation at least in following 2 =
points: 




1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 =
domain. this is not a behavior of encapsulation but a behavior of =
translation. 

1.
Well, there remains an inconsistency that I didn't see in the =
4rd-U draft(!): 


- "R-4   "Tunnel traffic class", if provided, is the IPv6 =
traffic class that BRs and CEs MUST set in Tunnel packets.  In this =
case, tunnel traversal is treated in IPv4 as a single-link =
traversal.



right, here the =
"single-link traversal" causes TTL decreases more than 1. well, you =
removed this self-contradictory. 
 


 Without it, Explicit =
Congestion Notification of [RFC3168] MAY be propagated from intermediate =
IPv6 nodes to IPv4 destinations, =



and IPv4 Time to live values =
progress with the number of traversed IPv6 =
links."

No=
te that this part of the sentence no longer appears in the revised =
R-4 


=


misunderstanding! 
=


please note that ECN being propagated from =
intermediate IPv6 to IPv4 is correct even for the mode of =
encapsulation!

Exactly, =
where it it applies in 4rd-U (no Tunnel traffic class =
parameter) it does it for both -H AND =
-E. 


 because congestion is a =
link-wise behavior. RFC3168 Sec 9 discussed this and its succeeding =
updates RFC6040 takes a huge effort in order to achieve compatibility =
among different processing proposals regarding the potential =
inconsistency between the outer header's ECN and inner header's ECN. the =
basic operation is: tunnel entry point should copy ECN from inner to =
outer header while tunnel exit should copy ECN from outer to =
inner. 

Right 




- Table 2 =
has:
+---------------------+-------------------------------=
----+


| IPv4 FIELDS         | VALUES SET AT DOMAIN =
EXIT         =
|
+---------------------+-----------------------------------+
                  =
  ...
| Time to live        | Hop =
limit                   =
      |


                  =
  =
...
+---------------------+-----------------------------------+<=
/div>

 Correction should =
be:
"R-4   "Tunnel traffic class", if provided, is the =
IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. =
 Without it, Explicit Congestion Notification of [RFC3168] MAY be =
propagated from intermediate IPv6 nodes to IPv4 destinations."


Thanks for the opportunity to notice this =
inconsistency.

2.
IPv4 time-to-live =
of an IPv4 may thus progress by more than one during domain traversal, =
right, but this isn't a breach to IPv4 end-to-end transparency (the TTL =
is THE field that always evolve during network traversal).  






2) 4rd-U draft, at R-33, states its =
IPv6-domain-generated ICMPv6 message will be translated to ICMPv4 with =
the logic of RFC6145 Sec 5.2. please note that RFC6145 Sec 5.2 is a =
typical behavior of translation rather than encapsulation. for the =
encapsulation, the semantics of ICMPv6 message processing should be =
quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U draft 03 contains the =
RFC2473 in the reference list but never cites it in the main =
text). 



1. How an IPv6-generated =
ICMP message is translated into an IPMPv4 message, doesn't belong to =
"IPv4 =
transparency".

"belongs to" =
or not is only a text gaming. i focus on the behavior: =


you stated it is "as encapsulation" and =
therefore i argue its behavior is not encapsulation behavior at =
all. 

4rd-H IS NOT =
"encapsulation" (not more than it is "double =
translation").
The only claim is that it is, end-to =
end, as transparent to IPv4 packets as =
encapsulation.




 
2. MAP-E has the same need. =
Otherwise unreachable CEs couldn't be signaled to IPv4 sources, =
right?



MAP-E applying any existing =
encapsulation standard such as RFC2473 or GRE as the packet processing =
method surely has been ready for that. the same need has been satisfied =
without need to define again. it could be emphasize the RFC2473's =
ICMPv6-to-ICMPv4 processing is consistent with the semantics of "virtual =
link" which the encapsulation contributes to the Internet =
architecture.

I didn't see this =
ICMP translation in the BR behavior of the MAP-E draft sec. 5.2, but it =
certainly can be added.
In any case, this doesn't make 4rd-U =
less end-to-end transparent to IPv4 than =
encapsulation.


The =
point remains that 4rd-U is "as transparent to IPv4 as =
MAP-E". 



narrow sense transparency, no =
problem in wording. but i suppose people are concerning the behavior =
rather than the wording itself. 
 


This is AFAIK a simple and =
important fact (it was designed for =
that). 



if we say some fields are transparent, that's =
ok.

 but if we are talking about the IP as a =
whole, TRANSPARENCY implies not only the consistency of packet header =
fields but also the behavior of hiding details of the carrying underlay =
infrastructure.

=


Agreed.
(But =
with due understanding of the exception of time-to-live: it always =
decreases end to end, and more or less depending on peculiarities of =
traversed infrastructures). 



encapsulation makes =
underlay as a link-layer, and certainly the TTL only decreases by 1 if =
no trouble. decreasing as the same in the underlay network is the =
behavior of translation. 

it exposes the details of =
the underlay and therefore not transparent as =
encapsulation. 

Different=
 view (IMHO, this statement is just playing with =
words)

Regards,
RD

=




=


best,
maoke
 




Regards,
RD



 

=


best,
maoke
 
- =
yet works with IPv6-only port-based ACLs and IPv6 Web caches.



In my understanding, 4rd-H is indeed such a solution (and is the =
only one on the =
table).
 

Regards,
RD

PS: Relationship of 4rd-U with single =
translation XLATs of RFC6145 is a different subject which deserves a =
discussion thread with another title.





=

...

=






=

--Apple-Mail-20-1068264892--

From fibrib@gmail.com  Thu Feb 16 19:41:28 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A4721E806C for ; Thu, 16 Feb 2012 19:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.072
X-Spam-Level: 
X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzLrVRdzbm5I for ; Thu, 16 Feb 2012 19:41:26 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2558921E8056 for ; Thu, 16 Feb 2012 19:41:26 -0800 (PST)
Received: by qafi29 with SMTP id i29so385857qaf.10 for ; Thu, 16 Feb 2012 19:41:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wWf7DWAG0sS+wTppprSe+5Yt7j4chFrHt7u8PQf17RU=; b=rpJM/dSIPA3uVmSlpFwoNT/NEoqQiy/3SvjqxGbHkIYpfvKvZ3qXgOPd6BOj4Lm87m IcXk8I2pQ8XwWJsxxUVNE6wSKjZinvc11/k6tnSgVvJqccPsiJJRQ6YHqT/B6JEk4CEB dCRg4V65NgSYtSSWPKsMGXnlj2ErhJVT97C3I=
MIME-Version: 1.0
Received: by 10.229.77.12 with SMTP id e12mr3727778qck.41.1329450085628; Thu, 16 Feb 2012 19:41:25 -0800 (PST)
Received: by 10.229.11.144 with HTTP; Thu, 16 Feb 2012 19:41:25 -0800 (PST)
In-Reply-To: <822AE298-64F0-4D82-8074-ECB408D14D1C@laposte.net>
References:  <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr>  <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net>   <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org>   <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net>  <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net>  <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net>    <822AE298-64F0-4D82-8074-ECB408D14D1C@laposte.net>
Date: Fri, 17 Feb 2012 12:41:25 +0900
Message-ID: 
From: Maoke 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=00235429e11c19ba8c04b920b851
Cc: Softwires WG 
Subject: Re: [Softwires] Checksum neutrality and L4-protocol independence
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2012 03:41:28 -0000

--00235429e11c19ba8c04b920b851
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Remi,

up to this message, i think we both have stated our points and have
clarified where we agree to each other where we don't. for some part, even
with the different terminology, we have known what each other are talking
about. it looks i have no further comments for this thread any more. :)

thanks and regards,
maoke

2012/2/17 R=E9mi Despr=E9s 

>
> Le 2012-02-16 =E0 12:19, Maoke a =E9crit :
>
> 2012/2/16 R=E9mi Despr=E9s 
>
>>
>> Le 2012-02-16 =E0 03:34, Maoke a =E9crit
>>
>> 2012/2/15 R=E9mi Despr=E9s 
>>>
>>> 2012-02-15 =E0 03:15, Maoke a =E9crit :
>>>
>>>
>>> "protocol unknown" should be detected and discarded at both CE and BR i=
n
>>> their major module instead of the NAT44 part.
>>>
>>>
>>> I don't think so:
>>> - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't
>>> exclude any protocol in packets sent to this CE.
>>> - If a CE has a shared address, it needs a NAT that the CE informs it
>>> the restricted port set. This NAT already has all what is needed to ref=
use
>>> protocols it doesn't understand.
>>>
>>
>> what if my NAT has understood XXXP but your CE hasn't? to my
>> understanding, CE only informs the restricted port set regardless of the
>> protocol.
>>
>>
>> 2 cases:
>> - If the new protocol has ports at their usual place, and has TCP-like
>> checksum, no problem. "Your CE", as you call it, does forward packets of
>> the new protocol.
>> - In other cases, any CE or BR would need needs an update to work, and
>> incompatibilities cold result.
>>
>>
>> ...
>>
>>
>>>  A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,
>>>
>>>
>>> Not SCTP today, for sure.
>>> Also, as I think you know, there is uncertainty concerning DCCP because
>>> RFC6145 sec 4.5 says:
>>> "Other transport protocols (e.g., DCCP) are OPTIONAL to support".
>>>
>>
>> it depends on the understanding of the "OPTIONAL". if it is OPTIONAL for
>> the operation domain, it is not a problem for double translation. if it =
is
>> OPTIONAL per device, the uncertainty is a problem where src-translator
>> makes DCCP checksum rewrite but dst-translator doesn't. (inverse case,
>> where src translator doesn't make but dst do, is not a problem though.)
>>
>>
>> Optional "for the operation domain" would work only if there would be
>> means to inform CEs of the choice made for the domain.
>> Such means don't exist, right?
>>
>
> agree. for this point, we'd prefer to propose an update to RFC6145 in
> order to clear the uncertainty, if the authors have not other concern we
> haven't noticed.
>
>
> Seems good to me.
> However, a specification change doesn't ensure that all devices support
> the change.
> A problem therefore remains.
>
>
>
>>
>>
>> ok, i think we do understand your point but please check. you mean: if
>> addresses are checksum-neutral, we don't need to have a list of supporte=
d
>> protocol in BR and just let it pass any protocol with the assumption tha=
t
>> it is TCP-layouted/checksumed. if the "any protocol" happens to really h=
ave
>> TCP-layout and TCP-checksum, then things are happy and the addresses hav=
e
>> ensured the checksum validity even without L4 rewrite. if the "any
>> protocol", unfortunately, happens to have another layout and/or another
>> checksum, then BR also treat it as it were TCP-layouted/checksumed but l=
et
>> it fail at the end host or CE. right?
>>
>>
>> Yes.
>> We are in sync on this point.
>>
>
> good. thanks!
>
>
>>
>>
>> here it is what i said R-22 (3) in 4rd-U is dangerous. it says:
>>
>>    + If the packet Protocol is not ICMP, bits 0-15 for an
>>    IPv4 source address, and bits 16-31 for a destination
>>    address.
>>
>> well doesn't it mean: even if the protocol has another layout, R-22 (3)'=
s
>> BR prefer to ignore the fact, making messy mapped addresses with blindly
>> assuming the protocol follows the TCP-layout!? (there is no NAT44 before=
 BR
>> to ensure the "unknown" protocol has been dropped.) i would further poin=
t
>> out that, the messy mapped destination address may navigate your packet =
in
>> a wrong direction towards a wrong CE where even the "fail at end" may fa=
il.
>>
>>
>> Still a misunderstanding here.
>> No new protocol will work for shared IPv4 addresses, be it with MAP or
>> 4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their usu=
al
>> place, and a TCP-like checksum somewhere).
>> A NAT44 that is coupled with a CE MUST remain operational ONLY for
>> "traditional" protocols.
>>
>> (Future protocols, if not "traditional", will need IPv6 to work safely,
>> including with shared-IPv4-address CEs.
>>
>
> it confuses me.
>
>
> if there is no new protocol, where we have the talking topic on the
> *change* of BR? neither MAP nor 4rd-U needs change if there is no new
> protocol.
>
>
> Clear.
>
> if there is new protocol in consideration, how do you assert such a new
> protocol surely not work for shared IPv4 addresses unless it is a
> "traditional" one?
>
>
> Yes, I do suggest that a transition tool such as MAP/4rd shouldn't be
> modified to support a new protocol that would have been be specified with
> consciousness that it is difficult to support in NAT44s.
>
> do you mean non-traditional protocol is nonsense and we have no obligatio=
n
> to consider?
>
>
> A nonsense, by no means!
> Defining new protocols, even with non-TCP checksum, can make a lot of
> sense, but only in the context of IPv6.
>
>
> or do you mean, new protocol working with shared IPv4 addresses must be
> traditional?
>
>
> My point is that any new protocol that should work for hosts having IPv4
> shared addresses SHOULD use the TCP-like checksum, yes.
> (I use SHOULD instead of MUST because we talk about the future, which is
> uncertain by nature.)
>
>
>  therefore i do agree Ole's argument. because we think any protocol
>> should be certainly supported, or certainly reported as not-supported,
>> rather than blindly trying a seemingly "universal" logic.
>>
>>
>> 1.
>> I don't know which "Ole's argument" you agree to (making your own points
>> directly would be clearer).
>>
>
> i think i focuses on the point that the "BR needs no change ...".
>
>
>>
>> - In particular, Ole wrote "any A+P solution requires support for L4
>> protocols to extract ports. L4 checksum rewrite, as well as port extract=
ion
>> will have to be supported for all new L4 protocols."
>> - The fact is that 4rd-U, because of checksum neutrality, doesn't have t=
o
>> support L4 checksum rewrite. Yet, it is an A+P solution that has no
>> identified operational problem.
>>
>> 2.
>> 4rd-U "certainly" supports All "traditional" protocols, an Echo requests
>> in identified conditions,  and nothing else.
>> MAP-T is AFAIK uncertain for DCCP.
>>
>
> MAP-T has been in running code and it is not complicated to remove the
> uncertainty with changing the OPTIONAL to a definite word, unless there i=
s
> something we haven't noticed.
>
>
> This point has no relationship with the fact that checksum neutrality
> provides BR support of all L4 protocols using TCP-like checksum.
>
>
>  btw, regarding the below "new standard for a new problem", i'd like to
>>> emphasize it is not a new problem as RFC6052 has discussed it. it is an
>>> incorrect understanding to think RFC6052/RFC6145 is designed only for
>>> single translation. since the very beginning of the stateless address
>>> mapping/translation design, the single and double translations have bei=
ng
>>> considered.
>>>
>>>
>>> I have no intention to negate anything about what designers of
>>> RFC6052/6145 considered (I wasn't there ;-)).
>>>
>>> The problem which IS NEW is how to design a stateless v4/v6 solution
>>> that:
>>> - is AS TRANSPARENT to IPv4 as encapsulation, without any restriction o=
r
>>> doubt
>>>
>>
>> NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2
>> points:
>>
>> 1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. thi=
s
>> is not a behavior of encapsulation but a behavior of translation.
>>
>>
>> 1.
>> Well, there remains an inconsistency that I didn't see in the 4rd-U
>> draft(!):
>> - "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class
>> that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel
>> traversal is treated in IPv4 as a single-link traversal.
>>
>
> right, here the "single-link traversal" causes TTL decreases more than 1.
> well, you removed this self-contradictory.
>
>
>>  Without it, Explicit Congestion Notification of [RFC3168] MAY be
>> propagated from intermediate IPv6 nodes to IPv4 destinations,
>>
>
>
> and IPv4 Time to live values progress with the number of traversed IPv6
>> links."
>>
>
> Note that this part of the sentence no longer appears in the revised R-4
>
>
> misunderstanding!
>
>
> please note that ECN being propagated from intermediate IPv6 to IPv4 is
> correct even for the mode of encapsulation!
>
>
> Exactly, where it it applies in 4rd-U (no Tunnel traffic class
> parameter) it does it for both -H AND -E.
>
>
> because congestion is a link-wise behavior. RFC3168 Sec 9 discussed this
> and its succeeding updates RFC6040 takes a huge effort in order to achiev=
e
> compatibility among different processing proposals regarding the potentia=
l
> inconsistency between the outer header's ECN and inner header's ECN. the
> basic operation is: tunnel entry point should copy ECN from inner to oute=
r
> header while tunnel exit should copy ECN from outer to inner.
>
>
> Right
>
>
>
> - Table 2 has:
>> +---------------------+-----------------------------------+
>> | IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT         |
>> +---------------------+-----------------------------------+
>>                     ...
>> | Time to live        | Hop limit                         |
>>                     ...
>> +---------------------+-----------------------------------+
>>
>>  Correction should be:
>> "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class
>> that BRs and CEs MUST set in Tunnel packets.  Without it, Explicit
>> Congestion Notification of [RFC3168] MAY be propagated from intermediate
>> IPv6 nodes to IPv4 destinations."
>> Thanks for the opportunity to notice this inconsistency.
>>
>> 2.
>> IPv4 time-to-live of an IPv4 may thus progress by more than one during
>> domain traversal, right, but this isn't a breach to IPv4 end-to-end
>> transparency (the TTL is THE field that always evolve during network
>> traversal).
>>
>
>>
>> 2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 message
>> will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. please n=
ote
>> that RFC6145 Sec 5.2 is a typical behavior of translation rather than
>> encapsulation. for the encapsulation, the semantics of ICMPv6 message
>> processing should be quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U
>> draft 03 contains the RFC2473 in the reference list but never cites it i=
n
>> the main text).
>>
>>
>> 1. How an IPv6-generated ICMP message is translated into an IPMPv4
>> message, doesn't belong to "IPv4 transparency".
>>
>
> "belongs to" or not is only a text gaming. i focus on the behavior:
>
>
> you stated it is "as encapsulation" and therefore i argue its behavior is
> not encapsulation behavior at all.
>
>
> 4rd-H IS NOT "encapsulation" (not more than it is "double translation").
> The only claim is that it is, end-to end, as transparent to IPv4 packets
> as encapsulation.
>
>
>
>
>> 2. MAP-E has the same need. Otherwise unreachable CEs couldn't be
>> signaled to IPv4 sources, right?
>>
>
> MAP-E applying any existing encapsulation standard such as RFC2473 or GRE
> as the packet processing method surely has been ready for that. the same
> need has been satisfied without need to define again. it could be emphasi=
ze
> the RFC2473's ICMPv6-to-ICMPv4 processing is consistent with the semantic=
s
> of "virtual link" which the encapsulation contributes to the Internet
> architecture.
>
>
> I didn't see this ICMP translation in the BR behavior of the MAP-E draft
> sec. 5.2, but it certainly can be added.
> In any case, this doesn't make 4rd-U less end-to-end transparent to IPv4
> than encapsulation.
>
>
> The point remains that 4rd-U is "as transparent to IPv4 as MAP-E".
>>
>
> narrow sense transparency, no problem in wording. but i suppose people ar=
e
> concerning the behavior rather than the wording itself.
>
>
>> This is AFAIK a simple and important fact (it was designed for that).
>>
>>
>> if we say some fields are transparent, that's ok.
>>
>>
>> but if we are talking about the IP as a whole, TRANSPARENCY implies not
>> only the consistency of packet header fields but also the behavior of
>> hiding details of the carrying underlay infrastructure.
>>
>>
>> Agreed.
>> (But with due understanding of the exception of time-to-live: it always
>> decreases end to end, and more or less depending on peculiarities of
>> traversed infrastructures).
>>
>
> encapsulation makes underlay as a link-layer, and certainly the TTL only
> decreases by 1 if no trouble. decreasing as the same in the underlay
> network is the behavior of translation.
>
>
> it exposes the details of the underlay and therefore not transparent as
> encapsulation.
>
>
> Different view (IMHO, this statement is just playing with words)
>
> Regards,
> RD
>
>
>
>
> best,
> maoke
>
>
>>
>>
>> Regards,
>> RD
>>
>>
>>
>>
>>
>> best,
>> maoke
>>
>>
>>> - yet works with IPv6-only port-based ACLs and IPv6 Web caches.
>>> In my understanding, 4rd-H is indeed such a solution (and is the only
>>> one on the table).
>>>
>>>
>>> Regards,
>>> RD
>>>
>>> PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a
>>> different subject which deserves a discussion thread with another title=
.
>>>
>>> ...
>>>
>>>
>>
>>
>
>

--00235429e11c19ba8c04b920b851
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Remi,=A0

up to this message, i think we both =
have stated our points and have clarified where we agree to each other wher=
e we don't. for some part, even with the different terminology, we have=
 known what each other are talking about. it looks i have no further commen=
ts for this thread any more. :)



thanks and regards,
maoke

2012/2/17 R=E9mi Despr=E9s <despres.remi@laposte.net>



Le 2012-02-16 =E0 12:19, =
Maoke a =E9crit :

2012/2/16 R=E9mi Despr=E9s <despres.remi@lap=
oste.net>





Le 2012-02-16 =E0 03:34, =
Maoke a =E9crit=A0
2012/2/15 R=E9mi Despr=E9s <despres.remi@laposte.net>



2012-02-15 =E0 03:15, Ma=
oke a =E9crit :
=A0
"protocol unknown" should be det=
ected and discarded at both CE and BR in their major module instead of the =
NAT44 part. 





I don't think so:
- If a CE has a non-shared address, or an IPv4 prefix, BRs sho=
uldn't exclude any protocol in packets sent to this CE.


- If a CE has a shared address, it needs a NAT that the CE informs it =
the restricted port set. This NAT already has all what is needed to refuse =
protocols it doesn't understand.=A0



what if my NAT has unders=
tood XXXP but your CE hasn't? to my understanding, CE only informs the =
restricted port set regardless of the protocol.=A0



2 cases:
- If the new prot=
ocol has ports at their usual place, and has TCP-like checksum, no problem.=
 "Your CE", as you call it, does forward packets of the new proto=
col.=A0



- In other cases, any CE or BR would need needs an update to work, and=
 incompatibilities cold result.=A0
=A0

...






 A MAP-compl=
iant device supports UDP, TCP, DCCP, SCTP today,

Not SCTP today, for sure.
Also, as I thi=
nk you know, there is uncertainty concerning DCCP because RFC6145 sec 4.5 s=
ays:




"Other=
 transport protocols (e.g., DCCP) are OPTIONAL to support".

it depends on the understanding of=
 the "OPTIONAL". if it is OPTIONAL for the operation domain, it i=
s not a problem for double translation. if it is OPTIONAL per device, the u=
ncertainty is a problem where src-translator makes DCCP checksum rewrite bu=
t dst-translator doesn't. (inverse case, where src translator doesn'=
;t make but dst do, is not a problem though.)=A0




Optional "for the operati=
on domain" would work only if there would be means to inform CEs of th=
e choice made for the domain.
Such means don't exist, right?<=
/div>



agree. for this point, we'=
d prefer to propose an update to RFC6145 in order to clear the uncertainty,=
 if the authors have not other concern we haven't noticed.=A0



Seems good to me.
However, a sp=
ecification change doesn't ensure that all devices support the change.=
=A0
A problem therefore remains.

=




=A0






ok, i think we do understand your point but please check. you mean: if=
 addresses are checksum-neutral, we don't need to have a list of suppor=
ted protocol in BR and just let it pass any protocol with the assumption th=
at it is TCP-layouted/checksumed. if the "any protocol" happens t=
o really have TCP-layout and TCP-checksum, then things are happy and the ad=
dresses have ensured the checksum validity even without L4 rewrite. if the =
"any protocol", unfortunately, happens to have another layout and=
/or another checksum, then BR also treat it as it were TCP-layouted/checksu=
med but let it fail at the end host or CE. right?




Yes.
We are in sync =
on this point.

good. than=
ks!
=A0







here it is what i said R-22 (3) in 4rd-U is dangerous. =
it says:=A0

=A0 =A0+  If the packet Protocol is no=
t ICMP, bits 0-15 for an
=A0                =A0IPv4 source address, and =
bits 16-31 for a destination



=A0                =A0address.

well doesn't it=
 mean: even if the protocol has another layout, R-22 (3)'s BR prefer to=
 ignore the fact, making messy mapped addresses with blindly assuming the p=
rotocol follows the TCP-layout!? (there is no NAT44 before BR to ensure the=
 "unknown" protocol has been dropped.) i would further point out =
that, the messy mapped destination address may navigate your packet in a wr=
ong direction towards a wrong CE where even the "fail at end" may=
 fail.




Still a misunderstanding here.=

No new protocol will work for shared IPv4 addresses, be it with =
MAP or 4rd-U BRs, if it isn't a "traditional" protocol (i.e. =
ports at their usual place, and a TCP-like checksum somewhere).



A NAT44 that is coupled with a CE MUST remain operational ONLY for &qu=
ot;traditional" protocols.

(Future protocols,=
 if not "traditional", will need IPv6 to work safely, including w=
ith shared-IPv4-address CEs.




it confuses me. 

if=
 there is no new protocol, where we have the talking topic on the *change* =
of BR? neither MAP nor 4rd-U needs change if there is no new protocol. 


Clear.
=

if there is n=
ew protocol in consideration, how do you assert such a new protocol surely =
not work for shared IPv4 addresses unless it is a "traditional" o=
ne? 



Yes, I do suggest that a transition=
 tool such as MAP/4rd shouldn't be modified to support a new protocol t=
hat would have been be specified with consciousness that it is difficult to=
 support in NAT44s.



do you mean non-traditional protocol is nonsense and we have no o=
bligation to consider? 

A nons=
ense, by no means!


Defining new protocols, even with non-TCP checksum,=A0can make a lot o=
f sense, but only=A0in the context of IPv6.


o=
r do you mean, new protocol working with shared IPv4 addresses must be trad=
itional?=A0



My point is that any new proto=
col that should work for hosts having IPv4 shared addresses SHOULD use the =
TCP-like checksum, yes.
(I use SHOULD instead of MUST because we =
talk about the future, which is uncertain by nature.)




<=
div class=3D"gmail_quote">







therefore i do agree Ole's argument. because we think any protocol=
 should be certainly supported, or certainly reported as not-supported, rat=
her than blindly trying a seemingly "universal" logic.=A0




1.
I don't know =
which "Ole's argument" you agree to (making your own points d=
irectly would be clearer).




i think i focuses on the point that the "BR needs no change ...&q=
uot;.=A0
=A0



=A0
- In particular,=A0Ole wrote "any A+P solution=
 requires support for L4 protocols to extract ports. L4 checksum rewrite, a=
s well as port extraction will have to be supported for all new L4 protocol=
s."



- The fact is that 4rd-U, because of checksum neutrality, doesn't =
have to support L4 checksum rewrite. Yet, it is an A+P solution that has no=
 identified operational problem.

2.


4rd-U "certainly" supports=A0All "traditional" protocol=
s, an Echo requests in identified conditions, =A0and nothing else.
MAP-T is AFAIK uncertain for DCCP.



MAP-T has been in running code and it is not complicated to remo=
ve the uncertainty with changing the OPTIONAL to a definite word, unless th=
ere is something we haven't noticed.=A0


This point has no relationship with the fact that chec=
ksum neutrality provides BR support of all L4 protocols using TCP-like chec=
ksum.


<=
div class=3D"gmail_quote">








btw, regarding the below "new standard for a new problem&quo=
t;, i'd like to emphasize it is not a new problem as RFC6052 has discus=
sed it. it is an incorrect understanding to think RFC6052/RFC6145 is design=
ed only for single translation. since the very beginning of the stateless a=
ddress mapping/translation design, the single and double translations have =
being considered.=A0





I have no intention to negate=
 anything about what=A0designers of RFC6052/6145=A0considered (I wasn't=
 there ;-)).

The problem which IS NEW is how to de=
sign a stateless v4/v6 solution that:




- is=A0AS TRANSPARENT to IPv4 as encapsulation, without any restrictio=
n or doubt

NOT AS TRANSPARENT t=
o IPv4 as encapsulation at least in following 2 points:=A0





1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domai=
n. this is not a behavior of encapsulation but a behavior of translation.=
=A0

1.
Well, th=
ere remains an inconsistency that I didn't see in the 4rd-U draft(!):=
=A0



- "R-4 =A0 "Tunnel traffic class", if provided, is the =
IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. =A0In this =
case, tunnel traversal is treated in IPv4 as a single-link traversal.




right, here the "single-l=
ink traversal" causes TTL decreases more than 1. well, you removed thi=
s self-contradictory.=A0
=A0



 Without it, Explicit Congest=
ion Notification of [RFC3168] MAY be propagated from intermediate IPv6 node=
s to IPv4 destinations, 






and IPv4 Time to live values =
progress with the number of traversed IPv6 links."

Note that this part of t=
he sentence no longer appears in the revised R-4=A0







misunderstanding!=A0

please note that ECN being propagated from intermediate IPv6 to IPv4 is c=
orrect even for the mode of encapsulation!



Exactly, where it it applies=
=A0in 4rd-U (no Tunnel traffic class parameter)=A0it does it for both -H AN=
D -E.=A0




 because congestion is a link-wise behavior=
. RFC3168 Sec 9 discussed this and its succeeding updates RFC6040 takes a h=
uge effort in order to achieve compatibility among different processing pro=
posals regarding the potential inconsistency between the outer header's=
 ECN and inner header's ECN. the basic operation is: tunnel entry point=
 should copy ECN from inner to outer header while tunnel exit should copy E=
CN from outer to inner.=A0



Right=A0


<=
blockquote type=3D"cite">



- Table 2 has:
+---------------------+-----=
------------------------------+



| IPv4 FIELDS =A0 =A0 =A0 =A0 | VALUES SET AT DOMAIN EXIT =A0 =A0 =A0 =
=A0 |
+---------------------+-----------------------------------+=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
| Time to =
live =A0 =A0 =A0 =A0| Hop limit =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 |



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
+---------------=
------+-----------------------------------+

=
=A0Correction should be:
"R-4 =A0 "Tunnel traffic class=
", if provided, is the IPv6 traffic class that BRs and CEs MUST set in=
 Tunnel packets. =A0Without it, Explicit Congestion Notification of [RFC316=
8] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations.&quo=
t;



Thanks for the opportunity to notice this inconsistency.
2.
IPv4 time-to-live of an IPv4 may thus progress by =
more than one during domain traversal, right, but this isn't a breach t=
o IPv4 end-to-end transparency (the TTL is THE field that always evolve dur=
ing network traversal). =A0








2) 4rd-U draft, at R-33, states its IPv6-do=
main-generated ICMPv6 message will be translated to ICMPv4 with the logic o=
f RFC6145 Sec 5.2. please note that RFC6145 Sec 5.2 is a typical behavior o=
f translation rather than encapsulation. for the encapsulation, the semanti=
cs of ICMPv6 message processing should be quite different (cf. RFC2473, Sec=
 8.) (btw, 4rd-U draft 03 contains the RFC2473 in the reference list but ne=
ver cites it in the main text).=A0




1.=A0How an IPv6-generated ICMP mes=
sage is translated into an IPMPv4 message, doesn't belong to "IPv4=
 transparency".

"belo=
ngs to" or not is only a text gaming. i focus on the behavior: 



you stated it is "as encapsulation" and therefore i argue i=
ts behavior is not encapsulation behavior at all.=A0



4rd-H IS NOT "encapsulation" (not more =
than it is "double translation").
The only claim is tha=
t it is, end-to end,=A0as transparent to IPv4 packets as encapsulation.





=A0
2.=A0MAP-E has the same need. Otherwise unreachable CEs couldn&#=
39;t be signaled to IPv4 sources, right?




MAP-E applying any existing encapsul=
ation standard such as RFC2473 or GRE as the packet processing method surel=
y has been ready for that. the same need has been satisfied without need to=
 define again. it could be emphasize the RFC2473's ICMPv6-to-ICMPv4 pro=
cessing is consistent with the semantics of "virtual link" which =
the encapsulation contributes to the Internet architecture.



I didn't see this ICMP translat=
ion in the BR behavior of the MAP-E draft sec. 5.2, but it certainly can be=
 added.
In any case, this doesn't make 4rd-U less end-to-end =
transparent to IPv4 than encapsulation.






The point remains that 4rd-U is &q=
uot;as transparent to IPv4 as MAP-E".=A0



narrow sense transparency, no proble=
m in wording. but i suppose people are concerning the behavior rather than =
the wording itself.=A0
=A0



This is AFAIK a simple and importa=
nt fact (it was designed for that).=A0


<=
div>

if we say some fields are transparent, that's ok.

 but if we are talking about the IP as a whole, TRANSPARENCY implies not o=
nly the consistency of packet header fields but also the behavior of hiding=
 details of the carrying underlay infrastructure.




Agreed.
(But w=
ith due understanding of the exception of time-to-live: it always decreases=
 end to end, and more or less depending on peculiarities of traversed infra=
structures).=A0




encapsulation makes underlay a=
s a link-layer, and certainly the TTL only decreases by 1 if no trouble. de=
creasing as the same in the underlay network is the behavior of translation=
. 



it exposes the details of the underlay and therefore not transparent =
as encapsulation.=A0

Diff=
erent view (IMHO, this statement is just playing with words)



Regards,
RD

<=
/div>





best,
maoke
=A0





Regards,
RD


=A0



best,
maoke
=A0
- yet works=
 with IPv6-only port-based ACLs and IPv6 Web caches.




In my understanding, 4rd-H is indeed such a solution (and is the only =
one on the table).
=A0

Regards,
RD

PS:=A0Relationship of 4rd-U with single trans=
lation XLATs of RFC6145 is a different subject which deserves a discussion =
thread with another title.







...










--00235429e11c19ba8c04b920b851--

From mohamed.boucadair@orange.com  Mon Feb 20 06:24:30 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE7821F8697 for ; Mon, 20 Feb 2012 06:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level: 
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_20=-0.74, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKSq8jhAN4jF for ; Mon, 20 Feb 2012 06:24:29 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B4B5D21F8685 for ; Mon, 20 Feb 2012 06:24:29 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3022C264419; Mon, 20 Feb 2012 15:24:29 +0100 (CET)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8798635C05B; Mon, 20 Feb 2012 15:24:28 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 20 Feb 2012 15:24:28 +0100
From: 
To: Softwire Chairs , "softwires@ietf.org" 
Date: Mon, 20 Feb 2012 15:24:27 +0100
Thread-Topic: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation 
Thread-Index: Aczol2GJqs3p5hsuQsGBvokg5DY2mgHQrF2A
Message-ID: <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>
References: Your message of Fri, 10 Feb 2012 11:20:35 +0100. <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr>
In-Reply-To: <201202110830.q1B8UDvM008903@givry.fdupont.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.20.132415
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2012 14:24:30 -0000

Dear chairs, WG members,

The answers received so far are in favour of initiating a WG LC on this doc=
ument.

As an editor of the document, I would like to progress this document for th=
e next IETF meeting. Chairs, could you please issue the WG LC? Thanks.

Cheers,
Med=20

> -----Message d'origine-----
> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20
> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : softwires@ietf.org
> Objet : Re: [Softwires] Closing=20
> draft-ietf-softwire-stateless-4v6-motivation=20
>=20
>  In your previous mail you wrote:
>=20
> >  (1) Either issue a WG LC, or
>=20
> +1
>=20
> Francis.Dupont@fdupont.fr
> =

From despres.remi@laposte.net  Mon Feb 20 07:10:07 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9773021F8680 for ; Mon, 20 Feb 2012 07:10:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.991
X-Spam-Level: 
X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.308,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x4ZZPcm4DTD for ; Mon, 20 Feb 2012 07:10:03 -0800 (PST)
Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id C75B221F8746 for ; Mon, 20 Feb 2012 07:09:57 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id cF9m1i00537Y3f403F9mqd; Mon, 20 Feb 2012 16:09:56 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>
Date: Mon, 20 Feb 2012 16:09:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FE56C88-B061-4388-A42B-313914055900@laposte.net>
References: Your message of Fri, 10 Feb 2012 11:20:35 +0100. <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>
To: Mohamed Boucadair 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2012 15:10:07 -0000

Le 2012-02-20 =E0 15:24,  =
 a =E9crit :

> Dear chairs, WG members,
>=20
> The answers received so far are in favour of initiating a WG LC on =
this document.
>=20
> As an editor of the document, I would like to progress this document =
for the next IETF meeting.

+1
RD


> Chairs, could you please issue the WG LC? Thanks.
>=20
> Cheers,
> Med=20
>=20
>> -----Message d'origine-----
>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20
>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>> Cc : softwires@ietf.org
>> Objet : Re: [Softwires] Closing=20
>> draft-ietf-softwire-stateless-4v6-motivation=20
>>=20
>> In your previous mail you wrote:
>>=20
>>> (1) Either issue a WG LC, or
>>=20
>> +1
>>=20
>> Francis.Dupont@fdupont.fr
>>=20
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From sarikaya2012@gmail.com  Mon Feb 20 07:18:01 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32C821F879A for ; Mon, 20 Feb 2012 07:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.343
X-Spam-Level: 
X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU4M3YQ87+i7 for ; Mon, 20 Feb 2012 07:17:59 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B04BF21F8623 for ; Mon, 20 Feb 2012 07:17:59 -0800 (PST)
Received: by yhkk25 with SMTP id k25so2952800yhk.31 for ; Mon, 20 Feb 2012 07:17:59 -0800 (PST)
Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.197.1 as permitted sender) client-ip=10.236.197.1; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.197.1 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com
Received: from mr.google.com ([10.236.197.1]) by 10.236.197.1 with SMTP id s1mr28687181yhn.89.1329751079287 (num_hops = 1); Mon, 20 Feb 2012 07:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=KqHTRf7M5mvCAt5PXVXLD0S5Sv84Jcujdnhe4o0CCis=; b=uua8VwFxCYGLwF62rFUx0PLkRsqmEztfA/Gc8qGZNcUDhY2UOO7onIQQrAe3PD/oPF W4pKoipdc6tVCDxSJglBDa+in8BSjk6PDlIckZfpduCk4eG0CVs7uW++VBZxAQKlAAwK 5rAiiRuvodg+pBCZlCa2QaBp/K1K97LwsJzew=
MIME-Version: 1.0
Received: by 10.236.197.1 with SMTP id s1mr22094081yhn.89.1329751079204; Mon, 20 Feb 2012 07:17:59 -0800 (PST)
Received: by 10.236.9.73 with HTTP; Mon, 20 Feb 2012 07:17:58 -0800 (PST)
In-Reply-To: <2FE56C88-B061-4388-A42B-313914055900@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr> <2FE56C88-B061-4388-A42B-313914055900@laposte.net>
Date: Mon, 20 Feb 2012 09:17:58 -0600
Message-ID: 
From: Behcet Sarikaya 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2012 15:18:02 -0000

+1

Behcet

On Mon, Feb 20, 2012 at 9:09 AM, R=E9mi Despr=E9s  wrote:
>
> Le 2012-02-20 =E0 15:24,   a =E9crit :
>
>> Dear chairs, WG members,
>>
>> The answers received so far are in favour of initiating a WG LC on this =
document.
>>
>> As an editor of the document, I would like to progress this document for=
 the next IETF meeting.
>
> +1
> RD
>
>
>> Chairs, could you please issue the WG LC? Thanks.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>> Cc : softwires@ietf.org
>>> Objet : Re: [Softwires] Closing
>>> draft-ietf-softwire-stateless-4v6-motivation
>>>
>>> In your previous mail you wrote:
>>>
>>>> (1) Either issue a WG LC, or
>>>
>>> +1
>>>
>>> Francis.Dupont@fdupont.fr
>>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From despres.remi@laposte.net  Tue Feb 21 08:06:27 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F099821F8834 for ; Tue, 21 Feb 2012 08:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.017
X-Spam-Level: 
X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.282,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAQzdQyg9nj4 for ; Tue, 21 Feb 2012 08:06:27 -0800 (PST)
Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id CCA9821F883A for ; Tue, 21 Feb 2012 08:06:26 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id cg6N1i00N37Y3f403g6P3n; Tue, 21 Feb 2012 17:06:25 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <20120221115526.0320.8FE1F57E@jpix.ad.jp>
Date: Tue, 21 Feb 2012 17:06:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> <4F42ADCC.9070806@bogus.com> <20120221115526.0320.8FE1F57E@jpix.ad.jp>
To: MAWATARI Masataka 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG , v6ops WG 
Subject: Re: [Softwires] [v6ops] new draft: draft-ietf-v6ops-464xlat
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2012 16:06:28 -0000

Masataka-san,

Please see in line.

Le 2012-02-21 =E0 03:55, MAWATARI Masataka a =E9crit :
...

> As all really know, 464XLAT remove 4rd and MAP, and vice versa, I
> also really think.

I don't understand this sentence because what 464XLAT introduces is (in =
4rd/MAP) vocabulary, a variant of stateless CE (one that only works wit =
stateful BRs whereas those of 4rd/MAP permit BRs to also be stateless).=20=


Isn't it natural to quickly look whether IETF-specified stateless CEs =
can work indifferently with stateful and stateless BRs?=20

AFAIK, there is little to add to 4rd-U so that its CEs can work =
according to the generic 464XLAT scenario.
- I plan to work on it in Softwire.
- Would be available to share views on the proposed solution?

> What I really want to realize is faster deploying IPv6 network and
> IPv6 service on the internet.

Same objective (that was that of 6rd, and is also that of 4rd)


Kind regards,
RD



From maxpassion@gmail.com  Thu Feb 23 03:03:45 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96BC21F8698 for ; Thu, 23 Feb 2012 03:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.373
X-Spam-Level: 
X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.226,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRMBEoL65nKh for ; Thu, 23 Feb 2012 03:03:45 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B42C21F8692 for ; Thu, 23 Feb 2012 03:03:45 -0800 (PST)
Received: by iagf6 with SMTP id f6so1699309iag.31 for ; Thu, 23 Feb 2012 03:03:44 -0800 (PST)
Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.154.200 as permitted sender) client-ip=10.50.154.200; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.154.200 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com
Received: from mr.google.com ([10.50.154.200]) by 10.50.154.200 with SMTP id vq8mr771748igb.14.1329995024931 (num_hops = 1); Thu, 23 Feb 2012 03:03:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KxICDwjMFUtC33g0eimCT6mauv7/i5zZ2oQNaVnk5n4=; b=D/mJS4isQEuEQZCZVXvZ6xAPBaJ+rsZCZZ3Km0CEE03xI8ElhwzMvz1HEhQPSsCJww WQLdnKcFOB79ICUDGH0xGyNhRFSVUEVIBZZ4vQbpWf9yE/46qgX+M6Y+CepLLfu3Od87 m+BY7G8ue1xCbyzWCWSkrGa4V0ZHb4mgVPwH0=
MIME-Version: 1.0
Received: by 10.50.154.200 with SMTP id vq8mr671547igb.14.1329995024877; Thu, 23 Feb 2012 03:03:44 -0800 (PST)
Received: by 10.42.161.74 with HTTP; Thu, 23 Feb 2012 03:03:44 -0800 (PST)
In-Reply-To: <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>
Date: Thu, 23 Feb 2012 19:03:44 +0800
Message-ID: 
From: liu dapeng 
To: mohamed.boucadair@orange.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2012 11:03:46 -0000

Hi Med,

I think it is still not clear about the definition of "stateless", in
current draft, it says:

stateless denotes a solution which does not require any per-user state
(see Section
 2.3 of [RFC1958]) to be maintained by any IP address sharing
function in the Service Provider's network.

But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
state in CPE. It is obviously contradictory with this definition. We
need more discussion regarding the definition of "stateless".

regards,
Dapeng Liu

2012/2/20, mohamed.boucadair@orange.com :
> Dear chairs, WG members,
>
> The answers received so far are in favour of initiating a WG LC on this
> document.
>
> As an editor of the document, I would like to progress this document for =
the
> next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>> Cc : softwires@ietf.org
>> Objet : Re: [Softwires] Closing
>> draft-ietf-softwire-stateless-4v6-motivation
>>
>>  In your previous mail you wrote:
>>
>> >  (1) Either issue a WG LC, or
>>
>> +1
>>
>> Francis.Dupont@fdupont.fr
>>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>


--=20

------
Best Regards,
Dapeng Liu

From leaf.y.yeh@huawei.com  Thu Feb 23 03:24:02 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2377221F86C9 for ; Thu, 23 Feb 2012 03:24:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.699
X-Spam-Level: 
X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BycdBuPtgPrZ for ; Thu, 23 Feb 2012 03:24:01 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 33AC521F86C7 for ; Thu, 23 Feb 2012 03:24:01 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZU00K85FMEKK@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 23 Feb 2012 19:23:02 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZU000EWFME2H@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 23 Feb 2012 19:23:02 +0800 (CST)
Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHI89467; Thu, 23 Feb 2012 19:23:01 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 23 Feb 2012 19:22:37 +0800
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Thu, 23 Feb 2012 19:22:58 +0800
Date: Thu, 23 Feb 2012 11:22:56 +0000
From: Leaf yeh 
In-reply-to: 
X-Originating-IP: [10.70.39.113]
To: liu dapeng , "mohamed.boucadair@orange.com" 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Thread-index: AQHM6Jdwz2ybbLr/8EC+mQeFduFL3ZZFX2iAgAR+6gCAAIakEA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr> 
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2012 11:24:02 -0000

VGhlIHN0YXRlbGVzcyBzb3VuZHMgb25seSByZWdhcmQgdG8gQlIsIHRoZSBib3JkZXIgcm91dGVy
LCBpbiB0aGUgY2FzZSBvZiBNQVAtVC9NQVAtRS80cmQtVSwNCm9yIGV2ZW4gQ0dOICggb3IgQUZU
UikgaW4gdGhlIGNhc2Ugb2YgSnVuaXBlciBTRC1OQVQuDQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVh
Zg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzb2Z0d2lyZXMtYm91bmNl
c0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgbGl1IGRhcGVuZw0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAyMDEyIDc6MDQgUE0N
ClRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQpDYzogc29mdHdpcmVzQGlldGYub3Jn
OyBTb2Z0d2lyZSBDaGFpcnMNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBDbG9zaW5nIGRyYWZ0
LWlldGYtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uDQoNCkhpIE1lZCwNCg0KSSB0
aGluayBpdCBpcyBzdGlsbCBub3QgY2xlYXIgYWJvdXQgdGhlIGRlZmluaXRpb24gb2YgInN0YXRl
bGVzcyIsIGluDQpjdXJyZW50IGRyYWZ0LCBpdCBzYXlzOg0KDQpzdGF0ZWxlc3MgZGVub3RlcyBh
IHNvbHV0aW9uIHdoaWNoIGRvZXMgbm90IHJlcXVpcmUgYW55IHBlci11c2VyIHN0YXRlDQooc2Vl
IFNlY3Rpb24NCiAyLjMgb2YgW1JGQzE5NThdKSB0byBiZSBtYWludGFpbmVkIGJ5IGFueSBJUCBh
ZGRyZXNzIHNoYXJpbmcNCmZ1bmN0aW9uIGluIHRoZSBTZXJ2aWNlIFByb3ZpZGVyJ3MgbmV0d29y
ay4NCg0KQnV0IGFsbCB0aGUgY2FuZGlkYXRlIHNvbHV0aW9uczogTUFQLVQvTUFQLUUvNHJkLVUg
YWxsIG5lZWQgdG8gbWFpdGFpbg0Kc3RhdGUgaW4gQ1BFLiBJdCBpcyBvYnZpb3VzbHkgY29udHJh
ZGljdG9yeSB3aXRoIHRoaXMgZGVmaW5pdGlvbi4gV2UNCm5lZWQgbW9yZSBkaXNjdXNzaW9uIHJl
Z2FyZGluZyB0aGUgZGVmaW5pdGlvbiBvZiAic3RhdGVsZXNzIi4NCg0KcmVnYXJkcywNCkRhcGVu
ZyBMaXUNCg0KMjAxMi8yLzIwLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtb2hhbWVk
LmJvdWNhZGFpckBvcmFuZ2UuY29tPjoNCj4gRGVhciBjaGFpcnMsIFdHIG1lbWJlcnMsDQo+DQo+
IFRoZSBhbnN3ZXJzIHJlY2VpdmVkIHNvIGZhciBhcmUgaW4gZmF2b3VyIG9mIGluaXRpYXRpbmcg
YSBXRyBMQyBvbiB0aGlzDQo+IGRvY3VtZW50Lg0KPg0KPiBBcyBhbiBlZGl0b3Igb2YgdGhlIGRv
Y3VtZW50LCBJIHdvdWxkIGxpa2UgdG8gcHJvZ3Jlc3MgdGhpcyBkb2N1bWVudCBmb3IgdGhlDQo+
IG5leHQgSUVURiBtZWV0aW5nLiBDaGFpcnMsIGNvdWxkIHlvdSBwbGVhc2UgaXNzdWUgdGhlIFdH
IExDPyBUaGFua3MuDQo+DQo+IENoZWVycywNCj4gTWVkDQo+DQo+PiAtLS0tLU1lc3NhZ2UgZCdv
cmlnaW5lLS0tLS0NCj4+IERlIDogRnJhbmNpcy5EdXBvbnRAZmR1cG9udC5mciBbbWFpbHRvOkZy
YW5jaXMuRHVwb250QGZkdXBvbnQuZnJdDQo+PiBFbnZvecOpIDogc2FtZWRpIDExIGbDqXZyaWVy
IDIwMTIgMDk6MzANCj4+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9OQUQvVElQDQo+PiBD
YyA6IHNvZnR3aXJlc0BpZXRmLm9yZw0KPj4gT2JqZXQgOiBSZTogW1NvZnR3aXJlc10gQ2xvc2lu
Zw0KPj4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb24NCj4+DQo+
PiAgSW4geW91ciBwcmV2aW91cyBtYWlsIHlvdSB3cm90ZToNCj4+DQo+PiA+ICAoMSkgRWl0aGVy
IGlzc3VlIGEgV0cgTEMsIG9yDQo+Pg0KPj4gKzENCj4+DQo+PiBGcmFuY2lzLkR1cG9udEBmZHVw
b250LmZyDQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPg0KDQoNCi0t
IA0KDQotLS0tLS0NCkJlc3QgUmVnYXJkcywNCkRhcGVuZyBMaXUNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpT
b2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
c29mdHdpcmVzDQo=

From mohamed.boucadair@orange.com  Thu Feb 23 04:37:28 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FFA21F8721 for ; Thu, 23 Feb 2012 04:37:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.14
X-Spam-Level: 
X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj1uMWshSIPz for ; Thu, 23 Feb 2012 04:37:28 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0978621F8720 for ; Thu, 23 Feb 2012 04:37:26 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 79361324869; Thu, 23 Feb 2012 13:37:25 +0100 (CET)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5D3874C075; Thu, 23 Feb 2012 13:37:25 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 23 Feb 2012 13:37:25 +0100
From: 
To: liu dapeng 
Date: Thu, 23 Feb 2012 13:37:24 +0100
Thread-Topic: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Thread-Index: AczyGtAmLYQ3u0wdRcuLnkeW/azYbwAC8Hsg
Message-ID: <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr> 
In-Reply-To: 
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.23.115128
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2012 12:37:28 -0000

Dear Dapeng,

Are you considering the endpoint (host or CPE) as part of the service provi=
der's network?

If not, please read the definition again with the answer in mind.

Cheers,
Med=20

> -----Message d'origine-----
> De : liu dapeng [mailto:maxpassion@gmail.com]=20
> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04
> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : Softwire Chairs; softwires@ietf.org
> Objet : Re: [Softwires] Closing=20
> draft-ietf-softwire-stateless-4v6-motivation
>=20
> Hi Med,
>=20
> I think it is still not clear about the definition of "stateless", in
> current draft, it says:
>=20
> stateless denotes a solution which does not require any per-user state
> (see Section
>  2.3 of [RFC1958]) to be maintained by any IP address sharing
> function in the Service Provider's network.
>=20
> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
> state in CPE. It is obviously contradictory with this definition. We
> need more discussion regarding the definition of "stateless".
>=20
> regards,
> Dapeng Liu
>=20
> 2012/2/20, mohamed.boucadair@orange.com=20
> :
> > Dear chairs, WG members,
> >
> > The answers received so far are in favour of initiating a=20
> WG LC on this
> > document.
> >
> > As an editor of the document, I would like to progress this=20
> document for the
> > next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
> >> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
> >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> >> Cc : softwires@ietf.org
> >> Objet : Re: [Softwires] Closing
> >> draft-ietf-softwire-stateless-4v6-motivation
> >>
> >>  In your previous mail you wrote:
> >>
> >> >  (1) Either issue a WG LC, or
> >>
> >> +1
> >>
> >> Francis.Dupont@fdupont.fr
> >>
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> >
>=20
>=20
> --=20
>=20
> ------
> Best Regards,
> Dapeng Liu
> =

From despres.remi@laposte.net  Thu Feb 23 05:05:37 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A825A21F879F for ; Thu, 23 Feb 2012 05:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level: 
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhN2bKLsNgo0 for ; Thu, 23 Feb 2012 05:05:36 -0800 (PST)
Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1A58221F87BE for ; Thu, 23 Feb 2012 05:05:32 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id dR5R1i00537Y3f403R5RWQ; Thu, 23 Feb 2012 14:05:31 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 23 Feb 2012 14:05:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr> 
To: liu dapeng 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2012 13:05:37 -0000

Le 2012-02-23 =E0 12:03, liu dapeng a =E9crit :

> Hi Med,
>=20
> I think it is still not clear about the definition of "stateless", in
> current draft, it says:
>=20
> stateless denotes a solution which does not require any per-user state
> (see Section
> 2.3 of [RFC1958]) to be maintained by any IP address sharing
> function in the Service Provider's network.
>=20
> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
> state in CPE.

Hi Liu,

Even in mesh topologies, these solutions don't require CPEs to maintain =
states about other CPEs to communicate directly with them.
In this sense, they are stateless, including with the given definition.
OK?=20

regards,
RD




> It is obviously contradictory with this definition. We
> need more discussion regarding the definition of "stateless".
>=20
> regards,
> Dapeng Liu
>=20
> 2012/2/20, mohamed.boucadair@orange.com =
:
>> Dear chairs, WG members,
>>=20
>> The answers received so far are in favour of initiating a WG LC on =
this
>> document.
>>=20
>> As an editor of the document, I would like to progress this document =
for the
>> next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
>>=20
>> Cheers,
>> Med
>>=20
>>> -----Message d'origine-----
>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>> Cc : softwires@ietf.org
>>> Objet : Re: [Softwires] Closing
>>> draft-ietf-softwire-stateless-4v6-motivation
>>>=20
>>> In your previous mail you wrote:
>>>=20
>>>> (1) Either issue a WG LC, or
>>>=20
>>> +1
>>>=20
>>> Francis.Dupont@fdupont.fr
>>>=20
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>=20
>=20
>=20
> --=20
>=20
> ------
> Best Regards,
> Dapeng Liu
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From cb.list6@gmail.com  Thu Feb 23 08:11:05 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB57421F87A4 for ; Thu, 23 Feb 2012 08:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.26
X-Spam-Level: 
X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8VATsuKXlL9 for ; Thu, 23 Feb 2012 08:10:50 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 55DAF21F85A0 for ; Thu, 23 Feb 2012 08:10:43 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so1618166pbc.31 for ; Thu, 23 Feb 2012 08:10:43 -0800 (PST)
Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.220.199 as permitted sender) client-ip=10.68.220.199; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.220.199 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com
Received: from mr.google.com ([10.68.220.199]) by 10.68.220.199 with SMTP id py7mr6086333pbc.8.1330013443230 (num_hops = 1); Thu, 23 Feb 2012 08:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F53pv9DpyIP6TU+rvNx2AfA2euGXlD1W2kCMioPzSV8=; b=GpUfqHwKEyre3m0ZMRM9M3ESIHj31CdfNsRYzq103LQFryUj+Bxb+gbSd1k/MvY79x 3eQITf6hMfap2wq9qvVJ7zU3xXlMZsyg81h3insJ/D5m5JAEA6uWqdK8mhSwTiqrwLlC VeM45u7ohDE0zlqDVjcX1bG4ookGDcmxgAkKg=
MIME-Version: 1.0
Received: by 10.68.220.199 with SMTP id py7mr5096122pbc.8.1330013443138; Thu, 23 Feb 2012 08:10:43 -0800 (PST)
Received: by 10.142.99.12 with HTTP; Thu, 23 Feb 2012 08:10:43 -0800 (PST)
Received: by 10.142.99.12 with HTTP; Thu, 23 Feb 2012 08:10:43 -0800 (PST)
In-Reply-To: <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net>
Date: Thu, 23 Feb 2012 08:10:43 -0800
Message-ID: 
From: Cameron Byrne 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=e89a8f13ec9ed3250904b9a3e20e
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2012 16:11:07 -0000

--e89a8f13ec9ed3250904b9a3e20e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Feb 23, 2012 5:05 AM, "R=E9mi Despr=E9s"  wrot=
e:
>
>
> Le 2012-02-23 =E0 12:03, liu dapeng a =E9crit :
>
> > Hi Med,
> >
> > I think it is still not clear about the definition of "stateless", in
> > current draft, it says:
> >
> > stateless denotes a solution which does not require any per-user state
> > (see Section
> > 2.3 of [RFC1958]) to be maintained by any IP address sharing
> > function in the Service Provider's network.
> >
> > But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
> > state in CPE.
>
> Hi Liu,
>
> Even in mesh topologies, these solutions don't require CPEs to maintain
states about other CPEs to communicate directly with them.
> In this sense, they are stateless, including with the given definition.
> OK?
>

Correct me if I am wrong, but at leas map-t requires stateful nat44 at the
cpe

Cb
> regards,
> RD
>
>
>
>
> > It is obviously contradictory with this definition. We
> > need more discussion regarding the definition of "stateless".
> >
> > regards,
> > Dapeng Liu
> >
> > 2012/2/20, mohamed.boucadair@orange.com :
> >> Dear chairs, WG members,
> >>
> >> The answers received so far are in favour of initiating a WG LC on thi=
s
> >> document.
> >>
> >> As an editor of the document, I would like to progress this document
for the
> >> next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
> >>
> >> Cheers,
> >> Med
> >>
> >>> -----Message d'origine-----
> >>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
> >>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
> >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> >>> Cc : softwires@ietf.org
> >>> Objet : Re: [Softwires] Closing
> >>> draft-ietf-softwire-stateless-4v6-motivation
> >>>
> >>> In your previous mail you wrote:
> >>>
> >>>> (1) Either issue a WG LC, or
> >>>
> >>> +1
> >>>
> >>> Francis.Dupont@fdupont.fr
> >>>
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
> >>
> >
> >
> > --
> >
> > ------
> > Best Regards,
> > Dapeng Liu
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--e89a8f13ec9ed3250904b9a3e20e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Feb 23, 2012 5:05 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:

>

>

> Le 2012-02-23 =E0 12:03, liu dapeng a =E9crit :

>

> > Hi Med,

> >

> > I think it is still not clear about the definition of "state=
less", in

> > current draft, it says:

> >

> > stateless denotes a solution which does not require any per-user =
state

> > (see Section

> > 2.3 of [RFC1958]) to be maintained by any IP address sharing

> > function in the Service Provider's network.

> >

> > But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to ma=
itain

> > state in CPE.

>

> Hi Liu,

>

> Even in mesh topologies, these solutions don't require CPEs to mai=
ntain states about other CPEs to communicate directly with them.

> In this sense, they are stateless, including with the given definition=
.

> OK?

>


Correct me if I am wrong, but at leas map-t requires stateful nat44 at t=
he cpe=A0=A0=A0 


Cb

> regards,

> RD

>

>

>

>

> > It is obviously contradictory with this definition. We

> > need more discussion regarding the definition of "stateless&=
quot;.

> >

> > regards,

> > Dapeng Liu

> >

> > 2012/2/20, mohame=
d.boucadair@orange.com <mohamed.boucadair@orange.com>:

> >> Dear chairs, WG members,

> >>

> >> The answers received so far are in favour of initiating a WG =
LC on this

> >> document.

> >>

> >> As an editor of the document, I would like to progress this d=
ocument for the

> >> next IETF meeting. Chairs, could you please issue the WG LC? =
Thanks.

> >>

> >> Cheers,

> >> Med

> >>

> >>> -----Message d'origine-----

> >>> De : Francis=
.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]

> >>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30

> >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP

> >>> Cc : softwires@ietf=
.org

> >>> Objet : Re: [Softwires] Closing

> >>> draft-ietf-softwire-stateless-4v6-motivation

> >>>

> >>> In your previous mail you wrote:

> >>>

> >>>> (1) Either issue a WG LC, or

> >>>

> >>> +1

> >>>

> >>> Francis.Dupo=
nt@fdupont.fr

> >>>

> >> _______________________________________________

> >> Softwires mailing list

> >> Softwires@ietf.org<=
br>
> >> h=
ttps://www.ietf.org/mailman/listinfo/softwires

> >>

> >

> >

> > --

> >

> > ------

> > Best Regards,

> > Dapeng Liu

> > _______________________________________________

> > Softwires mailing list

> > Softwires@ietf.org

> > https=
://www.ietf.org/mailman/listinfo/softwires

>

> _______________________________________________

> Softwires mailing list

> Softwires@ietf.org

> https://ww=
w.ietf.org/mailman/listinfo/softwires




--e89a8f13ec9ed3250904b9a3e20e--

From cb.list6@gmail.com  Thu Feb 23 08:13:20 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C0D21F8812 for ; Thu, 23 Feb 2012 08:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.261
X-Spam-Level: 
X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO7VBpqIxX3c for ; Thu, 23 Feb 2012 08:13:20 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1458421F87F8 for ; Thu, 23 Feb 2012 08:13:20 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so1620689pbc.31 for ; Thu, 23 Feb 2012 08:13:19 -0800 (PST)
Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.234.132 as permitted sender) client-ip=10.68.234.132; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.234.132 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com
Received: from mr.google.com ([10.68.234.132]) by 10.68.234.132 with SMTP id ue4mr6036028pbc.29.1330013599982 (num_hops = 1); Thu, 23 Feb 2012 08:13:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QxsuR3or9A0WK6WtfrZ+gG4ApQRpaQitsp2sjORYHyQ=; b=lj1FEMC9RW4JLIAOBRV4reXqpMbOyJzTFZg+iw/TLGxQGcXtJ9yv/t5J6fjeFzJW62 urAI2rkjCZjxX/U8Zj13gVSk2JyT1WEiUUI0LqIomOTZGQ5T2rMrsj1/4eNAbGQWao+I 4+czY1tmRNjNli/dz6YMG/qSv4j7Xr5Vlr6GE=
MIME-Version: 1.0
Received: by 10.68.234.132 with SMTP id ue4mr5046035pbc.29.1330013599824; Thu, 23 Feb 2012 08:13:19 -0800 (PST)
Received: by 10.142.99.12 with HTTP; Thu, 23 Feb 2012 08:13:19 -0800 (PST)
Received: by 10.142.99.12 with HTTP; Thu, 23 Feb 2012 08:13:19 -0800 (PST)
In-Reply-To: 
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net> 
Date: Thu, 23 Feb 2012 08:13:19 -0800
Message-ID: 
From: Cameron Byrne 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=047d7b33901929fb7404b9a3ec6a
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2012 16:13:21 -0000

--047d7b33901929fb7404b9a3ec6a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Feb 23, 2012 8:10 AM, "Cameron Byrne"  wrote:
>
>
> On Feb 23, 2012 5:05 AM, "R=E9mi Despr=E9s"  wr=
ote:
> >
> >
> > Le 2012-02-23 =E0 12:03, liu dapeng a =E9crit :
> >
> > > Hi Med,
> > >
> > > I think it is still not clear about the definition of "stateless", in
> > > current draft, it says:
> > >
> > > stateless denotes a solution which does not require any per-user stat=
e
> > > (see Section
> > > 2.3 of [RFC1958]) to be maintained by any IP address sharing
> > > function in the Service Provider's network.
> > >
> > > But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitai=
n
> > > state in CPE.
> >
> > Hi Liu,
> >
> > Even in mesh topologies, these solutions don't require CPEs to maintain
states about other CPEs to communicate directly with them.
> > In this sense, they are stateless, including with the given definition.
> > OK?
> >
>
> Correct me if I am wrong, but at leas map-t requires stateful nat44 at
the cpe
>

Never mind. Please excuse me not reading enough about the definition
before sending.

Cb
> Cb
>
> > regards,
> > RD
> >
> >
> >
> >
> > > It is obviously contradictory with this definition. We
> > > need more discussion regarding the definition of "stateless".
> > >
> > > regards,
> > > Dapeng Liu
> > >
> > > 2012/2/20, mohamed.boucadair@orange.com :
> > >> Dear chairs, WG members,
> > >>
> > >> The answers received so far are in favour of initiating a WG LC on
this
> > >> document.
> > >>
> > >> As an editor of the document, I would like to progress this document
for the
> > >> next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
> > >>
> > >> Cheers,
> > >> Med
> > >>
> > >>> -----Message d'origine-----
> > >>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
> > >>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
> > >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> > >>> Cc : softwires@ietf.org
> > >>> Objet : Re: [Softwires] Closing
> > >>> draft-ietf-softwire-stateless-4v6-motivation
> > >>>
> > >>> In your previous mail you wrote:
> > >>>
> > >>>> (1) Either issue a WG LC, or
> > >>>
> > >>> +1
> > >>>
> > >>> Francis.Dupont@fdupont.fr
> > >>>
> > >> _______________________________________________
> > >> Softwires mailing list
> > >> Softwires@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/softwires
> > >>
> > >
> > >
> > > --
> > >
> > > ------
> > > Best Regards,
> > > Dapeng Liu
> > > _______________________________________________
> > > Softwires mailing list
> > > Softwires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> >
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires

--047d7b33901929fb7404b9a3ec6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Feb 23, 2012 8:10 AM, "Cameron Byrne" <cb.list6@gmail.com> wrote:

>

>

> On Feb 23, 2012 5:05 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:

> >

> >

> > Le 2012-02-23 =E0 12:03, liu dapeng a =E9crit :

> >

> > > Hi Med,

> > >

> > > I think it is still not clear about the definition of "=
stateless", in

> > > current draft, it says:

> > >

> > > stateless denotes a solution which does not require any per-=
user state

> > > (see Section

> > > 2.3 of [RFC1958]) to be maintained by any IP address sharing=


> > > function in the Service Provider's network.

> > >

> > > But all the candidate solutions: MAP-T/MAP-E/4rd-U all need =
to maitain

> > > state in CPE.

> >

> > Hi Liu,

> >

> > Even in mesh topologies, these solutions don't require CPEs t=
o maintain states about other CPEs to communicate directly with them.

> > In this sense, they are stateless, including with the given defin=
ition.

> > OK?

> >

>

> Correct me if I am wrong, but at leas map-t requires stateful nat44 at=
 the cpe=A0=A0=A0

>


Never mind. Please excuse me not reading enough about the definition=A0 =
before sending. 


Cb

> Cb

>

> > regards,

> > RD

> >

> >

> >

> >

> > > It is obviously contradictory with this definition. We

> > > need more discussion regarding the definition of "state=
less".

> > >

> > > regards,

> > > Dapeng Liu

> > >

> > > 2012/2/20, m=
ohamed.boucadair@orange.com <mohamed.boucadair@orange.com>:

> > >> Dear chairs, WG members,

> > >>

> > >> The answers received so far are in favour of initiating =
a WG LC on this

> > >> document.

> > >>

> > >> As an editor of the document, I would like to progress t=
his document for the

> > >> next IETF meeting. Chairs, could you please issue the WG=
 LC? Thanks.

> > >>

> > >> Cheers,

> > >> Med

> > >>

> > >>> -----Message d'origine-----

> > >>> De : Fr=
ancis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]

> > >>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30

> > >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP

> > >>> Cc : softwires=
@ietf.org

> > >>> Objet : Re: [Softwires] Closing

> > >>> draft-ietf-softwire-stateless-4v6-motivation

> > >>>

> > >>> In your previous mail you wrote:

> > >>>

> > >>>> (1) Either issue a WG LC, or

> > >>>

> > >>> +1

> > >>>

> > >>> Francis=
.Dupont@fdupont.fr

> > >>>

> > >> _______________________________________________

> > >> Softwires mailing list

> > >> Softwires@ietf.org=


> > >> https://www.ietf.org/mailman/listinfo/softwires

> > >>

> > >

> > >

> > > --

> > >

> > > ------

> > > Best Regards,

> > > Dapeng Liu

> > > _______________________________________________

> > > Softwires mailing list

> > > Softwires@ietf.org=


> > > =
https://www.ietf.org/mailman/listinfo/softwires

> >

> > _______________________________________________

> > Softwires mailing list

> > Softwires@ietf.org

> > https=
://www.ietf.org/mailman/listinfo/softwires




--047d7b33901929fb7404b9a3ec6a--

From maxpassion@gmail.com  Fri Feb 24 04:10:29 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B098621F88CE for ; Fri, 24 Feb 2012 04:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.261
X-Spam-Level: 
X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Oi266U8j97Y for ; Fri, 24 Feb 2012 04:10:23 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 451AA21F87A3 for ; Fri, 24 Feb 2012 04:10:14 -0800 (PST)
Received: by iagf6 with SMTP id f6so3642546iag.31 for ; Fri, 24 Feb 2012 04:10:13 -0800 (PST)
Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.34.164 as permitted sender) client-ip=10.50.34.164; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.34.164 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com
Received: from mr.google.com ([10.50.34.164]) by 10.50.34.164 with SMTP id a4mr2389369igj.14.1330085413648 (num_hops = 1); Fri, 24 Feb 2012 04:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=l4UXVtVt5wjcAT3woO76nV0RcCWEAVRE/9owemAk6ug=; b=jwUawqs813VT4xzfHbId+DKAztqlec7qMD33W3KwRM/9Aam5w8cy5D/dHbO/5asTCW fv/4JxLFrDdlgiaEXVvDuGb3M8uujtNXoo1KYRFMwePowlJHBT+W+gSAUvS5jV2nZtlO hclJnA1d6ShafY2V/ptOY1WfV3e2eUdT44qdE=
MIME-Version: 1.0
Received: by 10.50.34.164 with SMTP id a4mr1970325igj.14.1330085413591; Fri, 24 Feb 2012 04:10:13 -0800 (PST)
Received: by 10.42.161.74 with HTTP; Fri, 24 Feb 2012 04:10:13 -0800 (PST)
In-Reply-To: <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net>
Date: Fri, 24 Feb 2012 20:10:13 +0800
Message-ID: 
From: liu dapeng 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 12:10:29 -0000

2012/2/23, R=E9mi Despr=E9s :
>
> Le 2012-02-23 =E0 12:03, liu dapeng a =E9crit :
>
>> Hi Med,
>>
>> I think it is still not clear about the definition of "stateless", in
>> current draft, it says:
>>
>> stateless denotes a solution which does not require any per-user state
>> (see Section
>> 2.3 of [RFC1958]) to be maintained by any IP address sharing
>> function in the Service Provider's network.
>>
>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
>> state in CPE.
>
> Hi Liu,
>
> Even in mesh topologies, these solutions don't require CPEs to maintain
> states about other CPEs to communicate directly with them.
> In this sense, they are stateless, including with the given definition.
> OK?

CPE have to maintain NAT44 state in all the cases. Is that a state or not?

regards,
Liu
> regards,
> RD
>
>
>
>
>> It is obviously contradictory with this definition. We
>> need more discussion regarding the definition of "stateless".
>>
>> regards,
>> Dapeng Liu
>>
>> 2012/2/20, mohamed.boucadair@orange.com :
>>> Dear chairs, WG members,
>>>
>>> The answers received so far are in favour of initiating a WG LC on this
>>> document.
>>>
>>> As an editor of the document, I would like to progress this document fo=
r
>>> the
>>> next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>> Cc : softwires@ietf.org
>>>> Objet : Re: [Softwires] Closing
>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>
>>>> In your previous mail you wrote:
>>>>
>>>>> (1) Either issue a WG LC, or
>>>>
>>>> +1
>>>>
>>>> Francis.Dupont@fdupont.fr
>>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>
>>
>> --
>>
>> ------
>> Best Regards,
>> Dapeng Liu
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
>


--=20

------
Best Regards,
Dapeng Liu

From ichiroumakino@gmail.com  Fri Feb 24 04:13:47 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735BA21F88E4 for ; Fri, 24 Feb 2012 04:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Level: 
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHZA4V52-SpA for ; Fri, 24 Feb 2012 04:13:46 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA121F88E3 for ; Fri, 24 Feb 2012 04:13:46 -0800 (PST)
Received: by werg1 with SMTP id g1so1826571wer.31 for ; Fri, 24 Feb 2012 04:13:45 -0800 (PST)
Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.84.170 as permitted sender) client-ip=10.180.84.170; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.84.170 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com
Received: from mr.google.com ([10.180.84.170]) by 10.180.84.170 with SMTP id a10mr4623241wiz.9.1330085625896 (num_hops = 1); Fri, 24 Feb 2012 04:13:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=Bbu8PwC1WUElmn4B7BVOl0tzLKlybdv2OjCkE5vBfw4=; b=x92eY5feGCvn/4Os5PDbPhHir8cHRQQLcApqcE3Mc6Jf350UzVG1c7eEy8L2UfH8c6 auxGeuSbQJNLffqO1tu/f9F7U5Tqb243+OMkQkzwygZFEYeFh6ovlxv9IptZm8CsA+9B Qucz+rjQB0A2hvKV96OHleq5eVoyijs6pEjLI=
Received: by 10.180.84.170 with SMTP id a10mr3720276wiz.9.1330085625755; Fri, 24 Feb 2012 04:13:45 -0800 (PST)
Received: from dhcp-10-61-98-136.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gp8sm3093924wib.5.2012.02.24.04.13.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 04:13:44 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Fri, 24 Feb 2012 13:13:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FAADDB4-0B75-4C33-AD71-61229612F50F@employees.org>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net> 
To: liu dapeng 
X-Mailer: Apple Mail (2.1257)
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 12:13:47 -0000

Dapeng,

> CPE have to maintain NAT44 state in all the cases. Is that a state or =
not?

no _additional_ state in CPE. keep state close to end-user (as it is =
now), no state in SP network.

cheers,
Ole



>>=20
>>> It is obviously contradictory with this definition. We
>>> need more discussion regarding the definition of "stateless".
>>>=20
>>> regards,
>>> Dapeng Liu
>>>=20
>>> 2012/2/20, mohamed.boucadair@orange.com =
:
>>>> Dear chairs, WG members,
>>>>=20
>>>> The answers received so far are in favour of initiating a WG LC on =
this
>>>> document.
>>>>=20
>>>> As an editor of the document, I would like to progress this =
document for
>>>> the
>>>> next IETF meeting. Chairs, could you please issue the WG LC? =
Thanks.
>>>>=20
>>>> Cheers,
>>>> Med
>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>> Cc : softwires@ietf.org
>>>>> Objet : Re: [Softwires] Closing
>>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>>=20
>>>>> In your previous mail you wrote:
>>>>>=20
>>>>>> (1) Either issue a WG LC, or
>>>>>=20
>>>>> +1
>>>>>=20
>>>>> Francis.Dupont@fdupont.fr
>>>>>=20
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>=20
>>>=20
>>>=20
>>> --
>>>=20
>>> ------
>>> Best Regards,
>>> Dapeng Liu
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>=20
>>=20
>=20
>=20
> --=20
>=20
> ------
> Best Regards,
> Dapeng Liu
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From maxpassion@gmail.com  Fri Feb 24 04:21:16 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27A121F86BA for ; Fri, 24 Feb 2012 04:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.416
X-Spam-Level: 
X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=0.183,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XDE12gYpKGn for ; Fri, 24 Feb 2012 04:21:15 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4EB21F86B8 for ; Fri, 24 Feb 2012 04:21:15 -0800 (PST)
Received: by iagf6 with SMTP id f6so3657122iag.31 for ; Fri, 24 Feb 2012 04:21:15 -0800 (PST)
Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.217.130 as permitted sender) client-ip=10.50.217.130; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.217.130 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com
Received: from mr.google.com ([10.50.217.130]) by 10.50.217.130 with SMTP id oy2mr2460974igc.10.1330086075120 (num_hops = 1); Fri, 24 Feb 2012 04:21:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ESdii58hBPJdC4bh9o/P/KPFu9HSTl2EAY+9PxLdRSg=; b=wVNud92OhqHlMTGvahocSklbOHvMFi+xnJI5WI9G431KbeU+CDDPWud3qSLXixtTsl oc9P0fL/wpQjDGW+8J82b6Arrc/nCn182tvJSdln9eHmxwZUdyJZ03GpFSNsB/TvFsxN p59wXYqMY5VYgA+c0AujMx6+FPu96621LV0ZY=
MIME-Version: 1.0
Received: by 10.50.217.130 with SMTP id oy2mr2026894igc.10.1330086075073; Fri, 24 Feb 2012 04:21:15 -0800 (PST)
Received: by 10.42.161.74 with HTTP; Fri, 24 Feb 2012 04:21:14 -0800 (PST)
In-Reply-To: <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>
Date: Fri, 24 Feb 2012 20:21:14 +0800
Message-ID: 
From: liu dapeng 
To: tmohamed.boucadair@orange.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 12:21:16 -0000

2012/2/23, mohamed.boucadair@orange.com :
> Dear Dapeng,
>
> Are you considering the endpoint (host or CPE) as part of the service
> provider's network?
>
> If not, please read the definition again with the answer in mind.

Hi Med,

Yes, I am considering CPE. There are two reasons:

1. The definition of "stateless" should not be bind to the provider's
network. The document should define "stateless" for the Internet not
only for the operator.

2. Even for CPE itself, in many cases, it should be considered as
provider's network since operator need to control/configure the CPE
remotely in that case.

regards,
Dapeng Liu


> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : liu dapeng [mailto:maxpassion@gmail.com]
>> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04
>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>> Cc : Softwire Chairs; softwires@ietf.org
>> Objet : Re: [Softwires] Closing
>> draft-ietf-softwire-stateless-4v6-motivation
>>
>> Hi Med,
>>
>> I think it is still not clear about the definition of "stateless", in
>> current draft, it says:
>>
>> stateless denotes a solution which does not require any per-user state
>> (see Section
>>  2.3 of [RFC1958]) to be maintained by any IP address sharing
>> function in the Service Provider's network.
>>
>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
>> state in CPE. It is obviously contradictory with this definition. We
>> need more discussion regarding the definition of "stateless".
>>
>> regards,
>> Dapeng Liu
>>
>> 2012/2/20, mohamed.boucadair@orange.com
>> :
>> > Dear chairs, WG members,
>> >
>> > The answers received so far are in favour of initiating a
>> WG LC on this
>> > document.
>> >
>> > As an editor of the document, I would like to progress this
>> document for the
>> > next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
>> >
>> > Cheers,
>> > Med
>> >
>> >> -----Message d'origine-----
>> >> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>> >> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>> >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>> >> Cc : softwires@ietf.org
>> >> Objet : Re: [Softwires] Closing
>> >> draft-ietf-softwire-stateless-4v6-motivation
>> >>
>> >>  In your previous mail you wrote:
>> >>
>> >> >  (1) Either issue a WG LC, or
>> >>
>> >> +1
>> >>
>> >> Francis.Dupont@fdupont.fr
>> >>
>> > _______________________________________________
>> > Softwires mailing list
>> > Softwires@ietf.org
>> > https://www.ietf.org/mailman/listinfo/softwires
>> >
>>
>>
>> --
>>
>> ------
>> Best Regards,
>> Dapeng Liu
>>


--=20

------
Best Regards,
Dapeng Liu

From leaf.y.yeh@huawei.com  Fri Feb 24 04:24:44 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A602E21F85F2 for ; Fri, 24 Feb 2012 04:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.226
X-Spam-Level: 
X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP+mP7VcXldo for ; Fri, 24 Feb 2012 04:24:44 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B46CC21F871D for ; Fri, 24 Feb 2012 04:24:43 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00M4ZD51V5@szxga03-in.huawei.com> for softwires@ietf.org; Fri, 24 Feb 2012 20:24:37 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00584D51QG@szxga03-in.huawei.com> for softwires@ietf.org; Fri, 24 Feb 2012 20:24:37 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHA92090; Fri, 24 Feb 2012 20:24:03 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 20:23:41 +0800
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.80]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 20:23:59 +0800
Date: Fri, 24 Feb 2012 12:23:57 +0000
From: Leaf yeh 
In-reply-to: <1FAADDB4-0B75-4C33-AD71-61229612F50F@employees.org>
X-Originating-IP: [10.70.39.113]
To: =?utf-8?B?T2xlIFRyw7hhbg==?= , liu dapeng 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Thread-index: AQHM6Jdwz2ybbLr/8EC+mQeFduFL3ZZFX2iAgAR+6gCAACH/gIABgumAgAAA+QCAAIibEA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <9843A97E-CEF2-493B-BF57-43C2C488DDAD@laposte.net>  <1FAADDB4-0B75-4C33-AD71-61229612F50F@employees.org>
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 12:24:44 -0000

U3VwcG9zZWQgdGhlIHN0YXRlIGFzc29jaWF0aW9uIHR1cm5zIGZyb20gUG9ydCBVbnJlc3RyaWN0
ZWQgdG8gYmUgUG9ydCBSZXN0cmljdGVkIGF0IENFLCB0aGVuIENFIHdvcmtzIGFzIGEgUFJEIChQ
b3J0IFJlc3RyaWN0ZWQgRGV2aWNlKSBpbiByb3VnaGx5IGFsbCB0aGUgY2FzZXMuDQoNCg0KQ2hl
ZXJzDQpMZWFmDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNvZnR3aXJl
cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBPbGUgVHI/YW4NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTIgODox
NCBQTQ0KVG86IGxpdSBkYXBlbmcNCkNjOiBzb2Z0d2lyZXNAaWV0Zi5vcmc7IFNvZnR3aXJlIENo
YWlycw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIENsb3NpbmcgZHJhZnQtaWV0Zi1zb2Z0d2ly
ZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb24NCg0KRGFwZW5nLA0KDQo+IENQRSBoYXZlIHRvIG1h
aW50YWluIE5BVDQ0IHN0YXRlIGluIGFsbCB0aGUgY2FzZXMuIElzIHRoYXQgYSBzdGF0ZSBvciBu
b3Q/DQoNCm5vIF9hZGRpdGlvbmFsXyBzdGF0ZSBpbiBDUEUuIGtlZXAgc3RhdGUgY2xvc2UgdG8g
ZW5kLXVzZXIgKGFzIGl0IGlzIG5vdyksIG5vIHN0YXRlIGluIFNQIG5ldHdvcmsuDQoNCmNoZWVy
cywNCk9sZQ0KDQoNCg0KPj4gDQo+Pj4gSXQgaXMgb2J2aW91c2x5IGNvbnRyYWRpY3Rvcnkgd2l0
aCB0aGlzIGRlZmluaXRpb24uIFdlDQo+Pj4gbmVlZCBtb3JlIGRpc2N1c3Npb24gcmVnYXJkaW5n
IHRoZSBkZWZpbml0aW9uIG9mICJzdGF0ZWxlc3MiLg0KPj4+IA0KPj4+IHJlZ2FyZHMsDQo+Pj4g
RGFwZW5nIExpdQ0KPj4+IA0KPj4+IDIwMTIvMi8yMCwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl
LmNvbSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT46DQo+Pj4+IERlYXIgY2hhaXJzLCBX
RyBtZW1iZXJzLA0KPj4+PiANCj4+Pj4gVGhlIGFuc3dlcnMgcmVjZWl2ZWQgc28gZmFyIGFyZSBp
biBmYXZvdXIgb2YgaW5pdGlhdGluZyBhIFdHIExDIG9uIHRoaXMNCj4+Pj4gZG9jdW1lbnQuDQo+
Pj4+IA0KPj4+PiBBcyBhbiBlZGl0b3Igb2YgdGhlIGRvY3VtZW50LCBJIHdvdWxkIGxpa2UgdG8g
cHJvZ3Jlc3MgdGhpcyBkb2N1bWVudCBmb3INCj4+Pj4gdGhlDQo+Pj4+IG5leHQgSUVURiBtZWV0
aW5nLiBDaGFpcnMsIGNvdWxkIHlvdSBwbGVhc2UgaXNzdWUgdGhlIFdHIExDPyBUaGFua3MuDQo+
Pj4+IA0KPj4+PiBDaGVlcnMsDQo+Pj4+IE1lZA0KPj4+PiANCj4+Pj4+IC0tLS0tTWVzc2FnZSBk
J29yaWdpbmUtLS0tLQ0KPj4+Pj4gRGUgOiBGcmFuY2lzLkR1cG9udEBmZHVwb250LmZyIFttYWls
dG86RnJhbmNpcy5EdXBvbnRAZmR1cG9udC5mcl0NCj4+Pj4+IEVudm95w6kgOiBzYW1lZGkgMTEg
ZsOpdnJpZXIgMjAxMiAwOTozMA0KPj4+Pj4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL05B
RC9USVANCj4+Pj4+IENjIDogc29mdHdpcmVzQGlldGYub3JnDQo+Pj4+PiBPYmpldCA6IFJlOiBb
U29mdHdpcmVzXSBDbG9zaW5nDQo+Pj4+PiBkcmFmdC1pZXRmLXNvZnR3aXJlLXN0YXRlbGVzcy00
djYtbW90aXZhdGlvbg0KPj4+Pj4gDQo+Pj4+PiBJbiB5b3VyIHByZXZpb3VzIG1haWwgeW91IHdy
b3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gKDEpIEVpdGhlciBpc3N1ZSBhIFdHIExDLCBvcg0KPj4+Pj4g
DQo+Pj4+PiArMQ0KPj4+Pj4gDQo+Pj4+PiBGcmFuY2lzLkR1cG9udEBmZHVwb250LmZyDQo+Pj4+
PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPj4+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4+Pj4g
DQo+Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiANCj4+PiAtLS0tLS0NCj4+PiBCZXN0IFJlZ2FyZHMs
DQo+Pj4gRGFwZW5nIExpdQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPj4+IFNvZnR3aXJlc0Bp
ZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdp
cmVzDQo+PiANCj4+IA0KPiANCj4gDQo+IC0tIA0KPiANCj4gLS0tLS0tDQo+IEJlc3QgUmVnYXJk
cywNCj4gRGFwZW5nIExpdQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJlc0BpZXRmLm9y
Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVz
IG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0K

From yiu_lee@cable.comcast.com  Fri Feb 24 18:49:37 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4FC21F8516 for ; Fri, 24 Feb 2012 18:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.195
X-Spam-Level: 
X-Spam-Status: No, score=-101.195 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcyLVE4WDfL2 for ; Fri, 24 Feb 2012 18:49:36 -0800 (PST)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 79FEC21F8504 for ; Fri, 24 Feb 2012 18:49:34 -0800 (PST)
Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.7255826; Fri, 24 Feb 2012 19:38:56 -0700
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 21:49:29 -0500
From: "Lee, Yiu" 
To: liu dapeng , "tmohamed.boucadair@orange.com" 
Thread-Topic: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Thread-Index: AQHM82gXoBxVJKEPhkiLvQBGPTq6bg==
Date: Sat, 25 Feb 2012 02:49:26 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [24.40.55.72]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3412964966_908408"
MIME-Version: 1.0
Cc: "softwires@ietf.org" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Feb 2012 02:49:37 -0000

--B_3412964966_908408
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Dapeng,

IMHO both sides are right. Whether in CPE or in the SP, there are states.
I guess when people say stateless on this list, they always refer to SP
network (vs. CPE). But we all agree that there would be states in the CPE
for the "stateless" solutions we discuss here. If we can clarify
"stateless" refers to SP network, does this work better for you?

We can argue that CPE is part of "SP" network. However, states in CPE
exist since introducing NAT. This is well understood and everybody has
lots of experience of it. States in SP are new to many operators and some
of them prefer keeping the states in the CPE due to various reasons we
discuss in the draft. That said, there are always pros and cons, it is up
to the operators to decide what path they would prefer.


Regards,
Yiu



On 2/24/12 7:21 AM, "liu dapeng"  wrote:

>Hi Med,
>
>Yes, I am considering CPE. There are two reasons:
>
>1. The definition of "stateless" should not be bind to the provider's
>network. The document should define "stateless" for the Internet not
>only for the operator.
>
>2. Even for CPE itself, in many cases, it should be considered as
>provider's network since operator need to control/configure the CPE
>remotely in that case.
>
>regards,
>Dapeng Liu
>

--B_3412964966_908408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX
DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa
djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA
Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8
dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf
WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn
c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0
W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED
BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI
KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u
YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0
cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1
cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG
A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB
AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq
ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV
/F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss
oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7
mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC
AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS
VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE
AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx
MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY
1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp
ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU
gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/
FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ
Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME
GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5
xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV
HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF
UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw
ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp
ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq
hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5
yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z
X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG
1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u
5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl
cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe
Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt
VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq
mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM
yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN
oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR
Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/
MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa
MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF
BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW
uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR
zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd
lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg
7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC
BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT
C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi
MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y
MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0
IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz
5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6
2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO
rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B
X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq
WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O
BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/
MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT
RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU
UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG
SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD
UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69
FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh
jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE
MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw
NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQXdMYs
HwdTFLNwUM7m6YrDQU3D3TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMjAyMjUwMjQ5MjVaMA0GCSqGSIb3DQEBAQUABIIBAJ2CVJnFpn/zSXMxcBlAqLW/
cbtxa0EM7RverSG6WVdnx74zBX9LVTyoBO3qAQPAfoBy5D7Q+j5n/XZRl9E3VCh5yQs1PM8B
OZpDNetVVzELySoUPjml5or7vLELN6bacCeQ+TGmx89KOokacOxir6XJdCpKfkzRoZRnZmZH
8dCB5k3XQG6Fhx+VGu9LX05l+IyP7ld+z8dQUj2aZDMNMWQlu/RuBMdL71qvoSsR0rVlLKRZ
igAd+ktEtGij9+3F1WvgLBm6t7e2YOa5JW5aYnGjl9d1p9C+l26gAFfbM3Bs/UvZN3oDOd6M
McZitdrzKY0gO108l+XrxaV+z87bAAo=

--B_3412964966_908408--

From dxhbupt@gmail.com  Sun Feb 26 20:27:47 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3394121F848B for ; Sun, 26 Feb 2012 20:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsV0CLh3rcx9 for ; Sun, 26 Feb 2012 20:27:46 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F97C21F8489 for ; Sun, 26 Feb 2012 20:27:46 -0800 (PST)
Received: by werb10 with SMTP id b10so955440wer.31 for ; Sun, 26 Feb 2012 20:27:45 -0800 (PST)
Received-SPF: pass (google.com: domain of dxhbupt@gmail.com designates 10.216.134.37 as permitted sender) client-ip=10.216.134.37; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of dxhbupt@gmail.com designates 10.216.134.37 as permitted sender) smtp.mail=dxhbupt@gmail.com; dkim=pass header.i=dxhbupt@gmail.com
Received: from mr.google.com ([10.216.134.37]) by 10.216.134.37 with SMTP id r37mr6034640wei.38.1330316865675 (num_hops = 1); Sun, 26 Feb 2012 20:27:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aUgKpmUbh5FaV2gjSfMgXrk2t8e/WjJpeXqI0RPBLWA=; b=bkaQer4wGrVrulDNTCcySytsKZ0pZw+lGbWFIWjwaW5/c9rFqgOgGEn8UfaBiTVW3c qBtXQtn3RH0GDgIqSangZnTVB7HNOuecXsD5/AqSGeJ55F3cXkc6HD1mNKux2H0YTAcj wY6Bvj8mldzyXG5DuBHekj7/upRzgB1diD73A=
MIME-Version: 1.0
Received: by 10.216.134.37 with SMTP id r37mr4817224wei.38.1330316865594; Sun, 26 Feb 2012 20:27:45 -0800 (PST)
Received: by 10.180.98.103 with HTTP; Sun, 26 Feb 2012 20:27:45 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 27 Feb 2012 12:27:45 +0800
Message-ID: 
From: Xiaohong Deng 
To: softwires@ietf.org
Content-Type: multipart/alternative; boundary=0016e6d7e97836652004b9ea88e3
Subject: Re: [Softwires] Softwires Digest, Vol 75, Issue 46
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 04:27:47 -0000

--0016e6d7e97836652004b9ea88e3
Content-Type: text/plain; charset=ISO-8859-1

Hi Dapeng,

On Sun, Feb 26, 2012 at 4:00 AM,  wrote:

>
> On 2/24/12 7:21 AM, "liu dapeng"  wrote:
>
> >Hi Med,
> >
> >Yes, I am considering CPE. There are two reasons:
> >
> >1. The definition of "stateless" should not be bind to the provider's
> >network. The document should define "stateless" for the Internet not
> >only for the operator.
>

Defining/Attempting "statless" for the Internet would be a bit ambitious
IMHO.
Consider routing tables on routers, firewall rules on firewall devices,
user data base
on servers...No means exists to avoid "state" in that sense, thereby
invalidating of
definition of "statelss for the Internet".

Cheers,
Xiaohong

--0016e6d7e97836652004b9ea88e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Dapeng,

On Sun, Feb 26, 2012 at 4:00 A=
M,  <sof=
twires-request@ietf.org> wrote:



On 2/24/12 7:21 AM, "liu dapeng" <maxpassion@gmail.com> wrote:



>Hi Med,

>

>Yes, I am considering CPE. There are two reasons:

>

>1. The definition of "stateless" should not be bind to the pr=
ovider's

>network. The document should define "stateless" for the Inter=
net not

>only for the operator.

Defining/Attempting &qu=
ot;statless" for the Internet would be a bit ambitious IMHO.
Consid=
er routing tables on routers, firewall rules on firewall devices, user data=
 base

on servers...No means exists to avoid "state" in that sense, ther=
eby invalidating of 
definition of "statelss for the Internet"=
.

Cheers,
Xiaohong




--0016e6d7e97836652004b9ea88e3--

From despres.remi@laposte.net  Mon Feb 27 00:41:56 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6652E21F855F for ; Mon, 27 Feb 2012 00:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.055
X-Spam-Level: 
X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.244,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcx1DW6-H3MV for ; Mon, 27 Feb 2012 00:41:55 -0800 (PST)
Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 5C74621F851D for ; Mon, 27 Feb 2012 00:41:54 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id ewhi1i00837Y3f403whikE; Mon, 27 Feb 2012 09:41:50 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Mon, 27 Feb 2012 09:41:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr> 
To: liu dapeng 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , tmohamed.boucadair@orange.com, Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 08:41:56 -0000

Liu,
Please see more clarification in line.

Le 2012-02-24 =E0 13:21, liu dapeng a =E9crit :

> 2012/2/23, mohamed.boucadair@orange.com =
:
>> Dear Dapeng,
>>=20
>> Are you considering the endpoint (host or CPE) as part of the service
>> provider's network?
>>=20
>> If not, please read the definition again with the answer in mind.
>=20
> Hi Med,
>=20
> Yes, I am considering CPE. There are two reasons:
>=20
> 1. The definition of "stateless" should not be bind to the provider's
> network.

Agreed.

> The document should define "stateless" for the Internet not
> only for the operator.

Because the document deals only with solutions deployed within =
individual ISP networks (similar in that to 6rd), it is AFAIK right to =
limit its stateless concern to individual ISP network.

>=20
> 2. Even for CPE itself, in many cases, it should be considered as
> provider's network since operator need to control/configure the CPE
> remotely in that case.

Agreed that CPEs, are part of the model.
But the important point AFAIK is that, "stateless 4/6 solution" is =
defined in the document itself as meaning without "per-user state".
All under-study solutions that refer to this draft are without =
"per-user" state" in "active data plane network elements". They are =
therefore din scope of this draft.
If a CPE includes a NAT for its IPv4 operation (with states that are per =
only session states, and only IPv4), the 4/6 solution proper remains =
without "per-user state".

Considering that publication of this draft is much expected to pursue =
the work on solutions themselves, and that it isn't freezing a standard =
(just clarifying a need that too many wanted to better understand), =
could you then agree that the draft can proceed as is.

Thank you,
RD


>=20
> regards,
> Dapeng Liu
>=20
>=20
>> Cheers,
>> Med
>>=20
>>> -----Message d'origine-----
>>> De : liu dapeng [mailto:maxpassion@gmail.com]
>>> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04
>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>> Cc : Softwire Chairs; softwires@ietf.org
>>> Objet : Re: [Softwires] Closing
>>> draft-ietf-softwire-stateless-4v6-motivation
>>>=20
>>> Hi Med,
>>>=20
>>> I think it is still not clear about the definition of "stateless", =
in
>>> current draft, it says:
>>>=20
>>> stateless denotes a solution which does not require any per-user =
state
>>> (see Section
>>> 2.3 of [RFC1958]) to be maintained by any IP address sharing
>>> function in the Service Provider's network.
>>>=20
>>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to =
maitain
>>> state in CPE. It is obviously contradictory with this definition. We
>>> need more discussion regarding the definition of "stateless".
>>>=20
>>> regards,
>>> Dapeng Liu
>>>=20
>>> 2012/2/20, mohamed.boucadair@orange.com
>>> :
>>>> Dear chairs, WG members,
>>>>=20
>>>> The answers received so far are in favour of initiating a
>>> WG LC on this
>>>> document.
>>>>=20
>>>> As an editor of the document, I would like to progress this
>>> document for the
>>>> next IETF meeting. Chairs, could you please issue the WG LC? =
Thanks.
>>>>=20
>>>> Cheers,
>>>> Med
>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>> Cc : softwires@ietf.org
>>>>> Objet : Re: [Softwires] Closing
>>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>>=20
>>>>> In your previous mail you wrote:
>>>>>=20
>>>>>> (1) Either issue a WG LC, or
>>>>>=20
>>>>> +1
>>>>>=20
>>>>> Francis.Dupont@fdupont.fr
>>>>>=20
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>=20
>>>=20
>>>=20
>>> --
>>>=20
>>> ------
>>> Best Regards,
>>> Dapeng Liu
>>>=20
>=20
>=20
> --=20
>=20
> ------
> Best Regards,
> Dapeng Liu
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


From maxpassion@gmail.com  Mon Feb 27 03:04:33 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA521F860F for ; Mon, 27 Feb 2012 03:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.289
X-Spam-Level: 
X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.010,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov2P6FwhuQ5C for ; Mon, 27 Feb 2012 03:04:32 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF2D21F8608 for ; Mon, 27 Feb 2012 03:04:32 -0800 (PST)
Received: by iagf6 with SMTP id f6so7490630iag.31 for ; Mon, 27 Feb 2012 03:04:31 -0800 (PST)
Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.155.202 as permitted sender) client-ip=10.50.155.202; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.155.202 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com
Received: from mr.google.com ([10.50.155.202]) by 10.50.155.202 with SMTP id vy10mr16118195igb.8.1330340671896 (num_hops = 1); Mon, 27 Feb 2012 03:04:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nG8Bfu10bYT8vLS5iJuJQc1B1PA2GJ9+EY89q+cKo/U=; b=xNPhqO6Z/McyNV+blPUzfZsJAo0BdJLZnY+pnn4M4PBJOnokQ1tW7AruLg4MXfnxWk Hz0gdUMTWFjcXu8PxNdk7WCzEz981jmiZwGVHE+nQERlanNcsK0SbtmanxU3QwTC4GIM 2lWAGzPwbXjU06cLPfHlmUZ1e5pl8d9u960zo=
MIME-Version: 1.0
Received: by 10.50.155.202 with SMTP id vy10mr13075633igb.8.1330340671814; Mon, 27 Feb 2012 03:04:31 -0800 (PST)
Received: by 10.42.161.74 with HTTP; Mon, 27 Feb 2012 03:04:31 -0800 (PST)
In-Reply-To: 
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>  
Date: Mon, 27 Feb 2012 19:04:31 +0800
Message-ID: 
From: liu dapeng 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , tmohamed.boucadair@orange.com, Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 11:04:34 -0000

Hi Remi,

Please see my reply inline:

2012/2/27, R=E9mi Despr=E9s :
> Liu,
> Please see more clarification in line.
>
> Le 2012-02-24 =E0 13:21, liu dapeng a =E9crit :
>
>> 2012/2/23, mohamed.boucadair@orange.com :
>>> Dear Dapeng,
>>>
>>> Are you considering the endpoint (host or CPE) as part of the service
>>> provider's network?
>>>
>>> If not, please read the definition again with the answer in mind.
>>
>> Hi Med,
>>
>> Yes, I am considering CPE. There are two reasons:
>>
>> 1. The definition of "stateless" should not be bind to the provider's
>> network.
>
> Agreed.
>
>> The document should define "stateless" for the Internet not
>> only for the operator.
>
> Because the document deals only with solutions deployed within individual
> ISP networks (similar in that to 6rd), it is AFAIK right to limit its
> stateless concern to individual ISP network.

The solutions currently under study have many requirement&enhancement
to the CPE. So I think the document does not "deals only with
soltuions deployed within individual ISP networks" if not considering
the CPE as part of ISP network.

>>
>> 2. Even for CPE itself, in many cases, it should be considered as
>> provider's network since operator need to control/configure the CPE
>> remotely in that case.
>
> Agreed that CPEs, are part of the model.
> But the important point AFAIK is that, "stateless 4/6 solution" is define=
d
> in the document itself as meaning without "per-user state".
> All under-study solutions that refer to this draft are without "per-user"
> state" in "active data plane network elements". They are therefore din sc=
ope
> of this draft.

> If a CPE includes a NAT for its IPv4 operation (with states that are per
> only session states, and only IPv4), the 4/6 solution proper remains with=
out
> "per-user state".

If  having "per-user state" is stateful, why "per session state" is
not stateful?

> Considering that publication of this draft is much expected to pursue the
> work on solutions themselves, and that it isn't freezing a standard (just
> clarifying a need that too many wanted to better understand), could you t=
hen
> agree that the draft can proceed as is.

The concern that I have is: If we want to move forward, we need more
clear and strict definition of "stateless" and also need more
investigation before we give the conclusion that "stateless is
superior than stateful".

Thanks.

Regards,
Dapeng Liu


> Thank you,
> RD
>
>
>>
>> regards,
>> Dapeng Liu
>>
>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : liu dapeng [mailto:maxpassion@gmail.com]
>>>> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04
>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>> Cc : Softwire Chairs; softwires@ietf.org
>>>> Objet : Re: [Softwires] Closing
>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>
>>>> Hi Med,
>>>>
>>>> I think it is still not clear about the definition of "stateless", in
>>>> current draft, it says:
>>>>
>>>> stateless denotes a solution which does not require any per-user state
>>>> (see Section
>>>> 2.3 of [RFC1958]) to be maintained by any IP address sharing
>>>> function in the Service Provider's network.
>>>>
>>>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
>>>> state in CPE. It is obviously contradictory with this definition. We
>>>> need more discussion regarding the definition of "stateless".
>>>>
>>>> regards,
>>>> Dapeng Liu
>>>>
>>>> 2012/2/20, mohamed.boucadair@orange.com
>>>> :
>>>>> Dear chairs, WG members,
>>>>>
>>>>> The answers received so far are in favour of initiating a
>>>> WG LC on this
>>>>> document.
>>>>>
>>>>> As an editor of the document, I would like to progress this
>>>> document for the
>>>>> next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>>>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>>> Cc : softwires@ietf.org
>>>>>> Objet : Re: [Softwires] Closing
>>>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>>>
>>>>>> In your previous mail you wrote:
>>>>>>
>>>>>>> (1) Either issue a WG LC, or
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Francis.Dupont@fdupont.fr
>>>>>>
>>>>> _______________________________________________
>>>>> Softwires mailing list
>>>>> Softwires@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> ------
>>>> Best Regards,
>>>> Dapeng Liu
>>>>
>>
>>
>> --
>>
>> ------
>> Best Regards,
>> Dapeng Liu
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>
>


--=20

------
Best Regards,
Dapeng Liu

From maxpassion@gmail.com  Mon Feb 27 03:20:02 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0FF21F86A5 for ; Mon, 27 Feb 2012 03:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.44
X-Spam-Level: 
X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL2rqB7Dh-Ae for ; Mon, 27 Feb 2012 03:20:02 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 189C121F866D for ; Mon, 27 Feb 2012 03:20:02 -0800 (PST)
Received: by iagf6 with SMTP id f6so7512298iag.31 for ; Mon, 27 Feb 2012 03:20:01 -0800 (PST)
Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.178.8 as permitted sender) client-ip=10.50.178.8; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.178.8 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com
Received: from mr.google.com ([10.50.178.8]) by 10.50.178.8 with SMTP id cu8mr10615152igc.12.1330341601846 (num_hops = 1); Mon, 27 Feb 2012 03:20:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+22LBxYsoF3V/rqOHugBAYUSCpJHWe7U7urKZNXYzs0=; b=fZFAgZWL72kg5pJWeEN1TT8NNO6/DmPd2tMgx97s6TgpoKoz3YqdXN5ryK8qmN1Jpo NdHpzHnajtDParD/ugiCBSFOkh/YYCEwbq0PFG8qHWqTJPHIz4KTaBEj4Xv7Z5pXnmCw eBnKwXyLZ5+MKSqI+WIJ3ouw5n5TlwgJ9BLhs=
MIME-Version: 1.0
Received: by 10.50.178.8 with SMTP id cu8mr8699917igc.12.1330341601789; Mon, 27 Feb 2012 03:20:01 -0800 (PST)
Received: by 10.42.161.74 with HTTP; Mon, 27 Feb 2012 03:20:01 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 27 Feb 2012 19:20:01 +0800
Message-ID: 
From: liu dapeng 
To: "Lee, Yiu" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "softwires@ietf.org" , "tmohamed.boucadair@orange.com" , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 11:20:02 -0000

2012/2/25, Lee, Yiu :
> Hi Dapeng,
>
> IMHO both sides are right. Whether in CPE or in the SP, there are states.
> I guess when people say stateless on this list, they always refer to SP
> network (vs. CPE). But we all agree that there would be states in the CPE
> for the "stateless" solutions we discuss here. If we can clarify
> "stateless" refers to SP network, does this work better for you?

 The problem is: SP network can not exclude CPE..

> We can argue that CPE is part of "SP" network. However, states in CPE
> exist since introducing NAT. This is well understood and everybody has
> lots of experience of it. States in SP are new to many operators and some
> of them prefer keeping the states in the CPE due to various reasons we
> discuss in the draft. That said, there are always pros and cons, it is up
> to the operators to decide what path they would prefer.

Yes, I agree that there are always pros and cons but we should try to
avoid confusing&misleading the reader before we decide to move
forward.

Thanks.

Regards,
Dapeng Liu
>
> Regards,
> Yiu
>
>
>
> On 2/24/12 7:21 AM, "liu dapeng"  wrote:
>
>>Hi Med,
>>
>>Yes, I am considering CPE. There are two reasons:
>>
>>1. The definition of "stateless" should not be bind to the provider's
>>network. The document should define "stateless" for the Internet not
>>only for the operator.
>>
>>2. Even for CPE itself, in many cases, it should be considered as
>>provider's network since operator need to control/configure the CPE
>>remotely in that case.
>>
>>regards,
>>Dapeng Liu
>>
>


-- 

------
Best Regards,
Dapeng Liu

From despres.remi@laposte.net  Mon Feb 27 04:48:15 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9F421F8702 for ; Mon, 27 Feb 2012 04:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.059
X-Spam-Level: 
X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.240,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcKUNLKp984w for ; Mon, 27 Feb 2012 04:48:15 -0800 (PST)
Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7751621F86FF for ; Mon, 27 Feb 2012 04:48:13 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id f0o51i00H37Y3f4030o57y; Mon, 27 Feb 2012 13:48:12 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Mon, 27 Feb 2012 13:48:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>   
To: liu dapeng 
X-Mailer: Apple Mail (2.1084)
Cc: "softwires@ietf.org" , tmohamed.boucadair@orange.com, Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 12:48:15 -0000

Le 2012-02-27 =E0 12:04, liu dapeng a =E9crit :

> Hi Remi,
>=20
> Please see my reply inline:
>=20
> 2012/2/27, R=E9mi Despr=E9s :
>> Liu,
>> Please see more clarification in line.
>>=20
>> Le 2012-02-24 =E0 13:21, liu dapeng a =E9crit :
>>=20
>>> 2012/2/23, mohamed.boucadair@orange.com =
:
>>>> Dear Dapeng,
>>>>=20
>>>> Are you considering the endpoint (host or CPE) as part of the =
service
>>>> provider's network?
>>>>=20
>>>> If not, please read the definition again with the answer in mind.
>>>=20
>>> Hi Med,
>>>=20
>>> Yes, I am considering CPE. There are two reasons:
>>>=20
>>> 1. The definition of "stateless" should not be bind to the =
provider's
>>> network.
>>=20
>> Agreed.
>>=20
>>> The document should define "stateless" for the Internet not
>>> only for the operator.
>>=20
>> Because the document deals only with solutions deployed within =
individual
>> ISP networks (similar in that to 6rd), it is AFAIK right to limit its
>> stateless concern to individual ISP network.
>=20
> The solutions currently under study have many requirement&enhancement
> to the CPE. So I think the document does not "deals only with
> soltuions deployed within individual ISP networks" if not considering
> the CPE as part of ISP network.

Misunderstanding.
Yes the 4/6 function of the CPE is part of the ISP-network solution, =
even if the CPE isn't provided by the ISP.
I think we agree on this.


>=20
>>>=20
>>> 2. Even for CPE itself, in many cases, it should be considered as
>>> provider's network since operator need to control/configure the CPE
>>> remotely in that case.
>>=20
>> Agreed that CPEs, are part of the model.
>> But the important point AFAIK is that, "stateless 4/6 solution" is =
defined
>> in the document itself as meaning without "per-user state".
>> All under-study solutions that refer to this draft are without =
"per-user"
>> state" in "active data plane network elements". They are therefore =
din scope
>> of this draft.
>=20
>> If a CPE includes a NAT for its IPv4 operation (with states that are =
per
>> only session states, and only IPv4), the 4/6 solution proper remains =
without
>> "per-user state".
>=20
> If  having "per-user state" is stateful, why "per session state" is
> not stateful?

It is stateful too, yes, but differently.
Also, if a CPE includes a NAT44, its states are not IPv4-over-IPv6 =
related (only IPv4 related).=20
=3D> Would you be satisfied if, in the terminology section, definition =
of Stateless 4/6 solution and  Stateful 4/6 solution would be clarified =
as follows:

Stateless  4/6 solution (or stateless solution in short): denotes in =
this document a solution which, as far as IPv4 aver IPv6 is concerned, =
does not require any per-user state ...

Stateful 4/6 solution  (or stateful solution in short): denotes in this =
document a solution which, as far as IPv4 aver IPv6 is concerned, =
requires neither per-customer nor per connection state ...

>=20
>> Considering that publication of this draft is much expected to pursue =
the
>> work on solutions themselves, and that it isn't freezing a standard =
(just
>> clarifying a need that too many wanted to better understand), could =
you then
>> agree that the draft can proceed as is.
>=20
> The concern that I have is: If we want to move forward, we need more
> clear and strict definition of "stateless" and also need more
> investigation before we give the conclusion that "stateless is
> superior than stateful".

The draft only reflects the wish of an number of operators to have a =
stateless solution standardized, acknowledging that this is in addition =
to the more advanced stateful solutions (it doesn't even include the =
word "superior").=20

Hoping that you will be more open to permit parallel progress on =
stateless,
Regards,

RD



>=20
> Thanks.
>=20
> Regards,
> Dapeng Liu
>=20
>=20
>> Thank you,
>> RD
>>=20
>>=20
>>>=20
>>> regards,
>>> Dapeng Liu
>>>=20
>>>=20
>>>> Cheers,
>>>> Med
>>>>=20
>>>>> -----Message d'origine-----
>>>>> De : liu dapeng [mailto:maxpassion@gmail.com]
>>>>> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04
>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>> Cc : Softwire Chairs; softwires@ietf.org
>>>>> Objet : Re: [Softwires] Closing
>>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>>=20
>>>>> Hi Med,
>>>>>=20
>>>>> I think it is still not clear about the definition of "stateless", =
in
>>>>> current draft, it says:
>>>>>=20
>>>>> stateless denotes a solution which does not require any per-user =
state
>>>>> (see Section
>>>>> 2.3 of [RFC1958]) to be maintained by any IP address sharing
>>>>> function in the Service Provider's network.
>>>>>=20
>>>>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to =
maitain
>>>>> state in CPE. It is obviously contradictory with this definition. =
We
>>>>> need more discussion regarding the definition of "stateless".
>>>>>=20
>>>>> regards,
>>>>> Dapeng Liu
>>>>>=20
>>>>> 2012/2/20, mohamed.boucadair@orange.com
>>>>> :
>>>>>> Dear chairs, WG members,
>>>>>>=20
>>>>>> The answers received so far are in favour of initiating a
>>>>> WG LC on this
>>>>>> document.
>>>>>>=20
>>>>>> As an editor of the document, I would like to progress this
>>>>> document for the
>>>>>> next IETF meeting. Chairs, could you please issue the WG LC? =
Thanks.
>>>>>>=20
>>>>>> Cheers,
>>>>>> Med
>>>>>>=20
>>>>>>> -----Message d'origine-----
>>>>>>> De : Francis.Dupont@fdupont.fr =
[mailto:Francis.Dupont@fdupont.fr]
>>>>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>>>> Cc : softwires@ietf.org
>>>>>>> Objet : Re: [Softwires] Closing
>>>>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>>>>=20
>>>>>>> In your previous mail you wrote:
>>>>>>>=20
>>>>>>>> (1) Either issue a WG LC, or
>>>>>>>=20
>>>>>>> +1
>>>>>>>=20
>>>>>>> Francis.Dupont@fdupont.fr
>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Softwires mailing list
>>>>>> Softwires@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>>=20
>>>>> ------
>>>>> Best Regards,
>>>>> Dapeng Liu
>>>>>=20
>>>=20
>>>=20
>>> --
>>>=20
>>> ------
>>> Best Regards,
>>> Dapeng Liu
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>=20
>>=20
>=20
>=20
> --=20
>=20
> ------
> Best Regards,
> Dapeng Liu


From cb.list6@gmail.com  Mon Feb 27 07:02:44 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A6F21F8783 for ; Mon, 27 Feb 2012 07:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.264
X-Spam-Level: 
X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy26B7a3IrVt for ; Mon, 27 Feb 2012 07:02:43 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1356521F8782 for ; Mon, 27 Feb 2012 07:02:42 -0800 (PST)
Received: by pbcwz17 with SMTP id wz17so850230pbc.31 for ; Mon, 27 Feb 2012 07:02:41 -0800 (PST)
Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.129.130 as permitted sender) client-ip=10.68.129.130; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.129.130 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com
Received: from mr.google.com ([10.68.129.130]) by 10.68.129.130 with SMTP id nw2mr37495977pbb.8.1330354961931 (num_hops = 1); Mon, 27 Feb 2012 07:02:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kMNbew+U6naUyb4NvSXfAJSw3dSGiXydY6YBZRGeVXo=; b=j6TJO4sdQv/gv2lorrD+1Kd+NdeQtv5XeO8hZYfgR1502Ou674ca1w44H9dhSOGaHG zy2qskn33GRSiizW/gXy7Sn8m8xSdhWD9/fD+ots7sZI9dyUcYkleHGI+3GyFhI2qfHl T2xbenz0JQ8flgt3Sb5oO8lijt8rLY2sbYFGM=
MIME-Version: 1.0
Received: by 10.68.129.130 with SMTP id nw2mr31852814pbb.8.1330354961770; Mon, 27 Feb 2012 07:02:41 -0800 (PST)
Received: by 10.142.99.12 with HTTP; Mon, 27 Feb 2012 07:02:41 -0800 (PST)
Received: by 10.142.99.12 with HTTP; Mon, 27 Feb 2012 07:02:41 -0800 (PST)
In-Reply-To: <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>    <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>
Date: Mon, 27 Feb 2012 07:02:41 -0800
Message-ID: 
From: Cameron Byrne 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: multipart/alternative; boundary=047d7b10ccb5ebea5504b9f366e3
Cc: "softwires@ietf.org" , tmohamed.boucadair@orange.com, Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 15:02:44 -0000

--047d7b10ccb5ebea5504b9f366e3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Feb 27, 2012 4:48 AM, "R=E9mi Despr=E9s"  wrot=
e:
>
>
> Le 2012-02-27 =E0 12:04, liu dapeng a =E9crit :
>
> > Hi Remi,
> >
> > Please see my reply inline:
> >
> > 2012/2/27, R=E9mi Despr=E9s :
> >> Liu,
> >> Please see more clarification in line.
> >>
> >> Le 2012-02-24 =E0 13:21, liu dapeng a =E9crit :
> >>
> >>> 2012/2/23, mohamed.boucadair@orange.com :
> >>>> Dear Dapeng,
> >>>>
> >>>> Are you considering the endpoint (host or CPE) as part of the servic=
e
> >>>> provider's network?
> >>>>
> >>>> If not, please read the definition again with the answer in mind.
> >>>
> >>> Hi Med,
> >>>
> >>> Yes, I am considering CPE. There are two reasons:
> >>>
> >>> 1. The definition of "stateless" should not be bind to the provider's
> >>> network.
> >>
> >> Agreed.
> >>
> >>> The document should define "stateless" for the Internet not
> >>> only for the operator.
> >>
> >> Because the document deals only with solutions deployed within
individual
> >> ISP networks (similar in that to 6rd), it is AFAIK right to limit its
> >> stateless concern to individual ISP network.
> >
> > The solutions currently under study have many requirement&enhancement
> > to the CPE. So I think the document does not "deals only with
> > soltuions deployed within individual ISP networks" if not considering
> > the CPE as part of ISP network.
>
> Misunderstanding.
> Yes the 4/6 function of the CPE is part of the ISP-network solution, even
if the CPE isn't provided by the ISP.
> I think we agree on this.
>
>
> >
> >>>
> >>> 2. Even for CPE itself, in many cases, it should be considered as
> >>> provider's network since operator need to control/configure the CPE
> >>> remotely in that case.
> >>
> >> Agreed that CPEs, are part of the model.
> >> But the important point AFAIK is that, "stateless 4/6 solution" is
defined
> >> in the document itself as meaning without "per-user state".
> >> All under-study solutions that refer to this draft are without
"per-user"
> >> state" in "active data plane network elements". They are therefore din
scope
> >> of this draft.
> >
> >> If a CPE includes a NAT for its IPv4 operation (with states that are
per
> >> only session states, and only IPv4), the 4/6 solution proper remains
without
> >> "per-user state".
> >
> > If  having "per-user state" is stateful, why "per session state" is
> > not stateful?
>
> It is stateful too, yes, but differently.
> Also, if a CPE includes a NAT44, its states are not IPv4-over-IPv6
related (only IPv4 related).
> =3D> Would you be satisfied if, in the terminology section, definition of
Stateless 4/6 solution and  Stateful 4/6 solution would be clarified as
follows:
>
> Stateless  4/6 solution (or stateless solution in short): denotes in this
document a solution which, as far as IPv4 aver IPv6 is concerned, does not
require any per-user state ...
>
> Stateful 4/6 solution  (or stateful solution in short): denotes in this
document a solution which, as far as IPv4 aver IPv6 is concerned, requires
neither per-customer nor per connection state ...
>
> >
> >> Considering that publication of this draft is much expected to pursue
the
> >> work on solutions themselves, and that it isn't freezing a standard
(just
> >> clarifying a need that too many wanted to better understand), could
you then
> >> agree that the draft can proceed as is.
> >
> > The concern that I have is: If we want to move forward, we need more
> > clear and strict definition of "stateless" and also need more
> > investigation before we give the conclusion that "stateless is
> > superior than stateful".
>
> The draft only reflects the wish of an number of operators to have a
stateless solution standardized, acknowledging that this is in addition to
the more advanced stateful solutions (it doesn't even include the word
"superior").
>
> Hoping that you will be more open to permit parallel progress on
stateless,
>

+1.

I believe the consensus is that one is not better than the other, or at
least it is not possible to quantify.

In the end, deployments of transition scenarios will be dependent on
operator preference, cost, timeline, features...

Cb

> RD
>
>
>
> >
> > Thanks.
> >
> > Regards,
> > Dapeng Liu
> >
> >
> >> Thank you,
> >> RD
> >>
> >>
> >>>
> >>> regards,
> >>> Dapeng Liu
> >>>
> >>>
> >>>> Cheers,
> >>>> Med
> >>>>
> >>>>> -----Message d'origine-----
> >>>>> De : liu dapeng [mailto:maxpassion@gmail.com]
> >>>>> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04
> >>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> >>>>> Cc : Softwire Chairs; softwires@ietf.org
> >>>>> Objet : Re: [Softwires] Closing
> >>>>> draft-ietf-softwire-stateless-4v6-motivation
> >>>>>
> >>>>> Hi Med,
> >>>>>
> >>>>> I think it is still not clear about the definition of "stateless",
in
> >>>>> current draft, it says:
> >>>>>
> >>>>> stateless denotes a solution which does not require any per-user
state
> >>>>> (see Section
> >>>>> 2.3 of [RFC1958]) to be maintained by any IP address sharing
> >>>>> function in the Service Provider's network.
> >>>>>
> >>>>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to
maitain
> >>>>> state in CPE. It is obviously contradictory with this definition. W=
e
> >>>>> need more discussion regarding the definition of "stateless".
> >>>>>
> >>>>> regards,
> >>>>> Dapeng Liu
> >>>>>
> >>>>> 2012/2/20, mohamed.boucadair@orange.com
> >>>>> :
> >>>>>> Dear chairs, WG members,
> >>>>>>
> >>>>>> The answers received so far are in favour of initiating a
> >>>>> WG LC on this
> >>>>>> document.
> >>>>>>
> >>>>>> As an editor of the document, I would like to progress this
> >>>>> document for the
> >>>>>> next IETF meeting. Chairs, could you please issue the WG LC?
Thanks.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Med
> >>>>>>
> >>>>>>> -----Message d'origine-----
> >>>>>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
> >>>>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
> >>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
> >>>>>>> Cc : softwires@ietf.org
> >>>>>>> Objet : Re: [Softwires] Closing
> >>>>>>> draft-ietf-softwire-stateless-4v6-motivation
> >>>>>>>
> >>>>>>> In your previous mail you wrote:
> >>>>>>>
> >>>>>>>> (1) Either issue a WG LC, or
> >>>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> Francis.Dupont@fdupont.fr
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> Softwires mailing list
> >>>>>> Softwires@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/softwires
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> ------
> >>>>> Best Regards,
> >>>>> Dapeng Liu
> >>>>>
> >>>
> >>>
> >>> --
> >>>
> >>> ------
> >>> Best Regards,
> >>> Dapeng Liu
> >>> _______________________________________________
> >>> Softwires mailing list
> >>> Softwires@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/softwires
> >>
> >>
> >
> >
> > --
> >
> > ------
> > Best Regards,
> > Dapeng Liu
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

--047d7b10ccb5ebea5504b9f366e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Feb 27, 2012 4:48 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:

>

>

> Le 2012-02-27 =E0 12:04, liu dapeng a =E9crit :

>

> > Hi Remi,

> >

> > Please see my reply inline:

> >

> > 2012/2/27, R=E9mi Despr=E9s <despres.remi@laposte.net>:

> >> Liu,

> >> Please see more clarification in line.

> >>

> >> Le 2012-02-24 =E0 13:21, liu dapeng a =E9crit :

> >>

> >>> 2012/2/23, mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>:

> >>>> Dear Dapeng,

> >>>>

> >>>> Are you considering the endpoint (host or CPE) as par=
t of the service

> >>>> provider's network?

> >>>>

> >>>> If not, please read the definition again with the ans=
wer in mind.

> >>>

> >>> Hi Med,

> >>>

> >>> Yes, I am considering CPE. There are two reasons:

> >>>

> >>> 1. The definition of "stateless" should not be =
bind to the provider's

> >>> network.

> >>

> >> Agreed.

> >>

> >>> The document should define "stateless" for the =
Internet not

> >>> only for the operator.

> >>

> >> Because the document deals only with solutions deployed withi=
n individual

> >> ISP networks (similar in that to 6rd), it is AFAIK right to l=
imit its

> >> stateless concern to individual ISP network.

> >

> > The solutions currently under study have many requirement&enh=
ancement

> > to the CPE. So I think the document does not "deals only wit=
h

> > soltuions deployed within individual ISP networks" if not co=
nsidering

> > the CPE as part of ISP network.

>

> Misunderstanding.

> Yes the 4/6 function of the CPE is part of the ISP-network solution, e=
ven if the CPE isn't provided by the ISP.

> I think we agree on this.

>

>

> >

> >>>

> >>> 2. Even for CPE itself, in many cases, it should be consi=
dered as

> >>> provider's network since operator need to control/con=
figure the CPE

> >>> remotely in that case.

> >>

> >> Agreed that CPEs, are part of the model.

> >> But the important point AFAIK is that, "stateless 4/6 so=
lution" is defined

> >> in the document itself as meaning without "per-user stat=
e".

> >> All under-study solutions that refer to this draft are withou=
t "per-user"

> >> state" in "active data plane network elements"=
. They are therefore din scope

> >> of this draft.

> >

> >> If a CPE includes a NAT for its IPv4 operation (with states t=
hat are per

> >> only session states, and only IPv4), the 4/6 solution proper =
remains without

> >> "per-user state".

> >

> > If =A0having "per-user state" is stateful, why "pe=
r session state" is

> > not stateful?

>

> It is stateful too, yes, but differently.

> Also, if a CPE includes a NAT44, its states are not IPv4-over-IPv6 rel=
ated (only IPv4 related).

> =3D> Would you be satisfied if, in the terminology section, definit=
ion of Stateless 4/6 solution and =A0Stateful 4/6 solution would be clarifi=
ed as follows:

>

> Stateless =A04/6 solution (or stateless solution in short): denotes in=
 this document a solution which, as far as IPv4 aver IPv6 is concerned, doe=
s not require any per-user state ...

>

> Stateful 4/6 solution =A0(or stateful solution in short): denotes in t=
his document a solution which, as far as IPv4 aver IPv6 is concerned, requi=
res neither per-customer nor per connection state ...

>

> >

> >> Considering that publication of this draft is much expected t=
o pursue the

> >> work on solutions themselves, and that it isn't freezing =
a standard (just

> >> clarifying a need that too many wanted to better understand),=
 could you then

> >> agree that the draft can proceed as is.

> >

> > The concern that I have is: If we want to move forward, we need m=
ore

> > clear and strict definition of "stateless" and also nee=
d more

> > investigation before we give the conclusion that "stateless =
is

> > superior than stateful".

>

> The draft only reflects the wish of an number of operators to have a s=
tateless solution standardized, acknowledging that this is in addition to t=
he more advanced stateful solutions (it doesn't even include the word &=
quot;superior").


>

> Hoping that you will be more open to permit parallel progress on state=
less,

>


+1. 


I believe the consensus is that one is not better than the other, or at =
least it is not possible to quantify. 


In the end, deployments of transition scenarios will be dependent on ope=
rator preference, cost, timeline, features...


Cb


> RD

>

>

>

> >

> > Thanks.

> >

> > Regards,

> > Dapeng Liu

> >

> >

> >> Thank you,

> >> RD

> >>

> >>

> >>>

> >>> regards,

> >>> Dapeng Liu

> >>>

> >>>

> >>>> Cheers,

> >>>> Med

> >>>>

> >>>>> -----Message d'origine-----

> >>>>> De : liu dapeng [mailto:maxpassion@gmail.com]

> >>>>> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04

> >>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP

> >>>>> Cc : Softwire Chairs; softwires@ietf.org

> >>>>> Objet : Re: [Softwires] Closing

> >>>>> draft-ietf-softwire-stateless-4v6-motivation

> >>>>>

> >>>>> Hi Med,

> >>>>>

> >>>>> I think it is still not clear about the definitio=
n of "stateless", in

> >>>>> current draft, it says:

> >>>>>

> >>>>> stateless denotes a solution which does not requi=
re any per-user state

> >>>>> (see Section

> >>>>> 2.3 of [RFC1958]) to be maintained by any IP addr=
ess sharing

> >>>>> function in the Service Provider's network.
> >>>>>

> >>>>> But all the candidate solutions: MAP-T/MAP-E/4rd-=
U all need to maitain

> >>>>> state in CPE. It is obviously contradictory with =
this definition. We

> >>>>> need more discussion regarding the definition of =
"stateless".

> >>>>>

> >>>>> regards,

> >>>>> Dapeng Liu

> >>>>>

> >>>>> 2012/2/20, mohamed.boucadair@orange.com

> >>>>> <mohamed.boucadair@orange.com>:

> >>>>>> Dear chairs, WG members,

> >>>>>>

> >>>>>> The answers received so far are in favour of =
initiating a

> >>>>> WG LC on this

> >>>>>> document.

> >>>>>>

> >>>>>> As an editor of the document, I would like to=
 progress this

> >>>>> document for the

> >>>>>> next IETF meeting. Chairs, could you please i=
ssue the WG LC? Thanks.

> >>>>>>

> >>>>>> Cheers,

> >>>>>> Med

> >>>>>>

> >>>>>>> -----Message d'origine-----

> >>>>>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]

> >>>>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30=


> >>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP

> >>>>>>> Cc : softwires@ietf.org

> >>>>>>> Objet : Re: [Softwires] Closing

> >>>>>>> draft-ietf-softwire-stateless-4v6-motivat=
ion

> >>>>>>>

> >>>>>>> In your previous mail you wrote:

> >>>>>>>

> >>>>>>>> (1) Either issue a WG LC, or

> >>>>>>>

> >>>>>>> +1

> >>>>>>>

> >>>>>>> Francis.Dupont@fdupont.fr

> >>>>>>>

> >>>>>> _____________________________________________=
__

> >>>>>> Softwires mailing list

> >>>>>> Softwir=
es@ietf.org

> >>>>>> https://www.ietf.org/mailman/listinfo/softwires

> >>>>>>

> >>>>>

> >>>>>

> >>>>> --

> >>>>>

> >>>>> ------

> >>>>> Best Regards,

> >>>>> Dapeng Liu

> >>>>>

> >>>

> >>>

> >>> --

> >>>

> >>> ------

> >>> Best Regards,

> >>> Dapeng Liu

> >>> _______________________________________________

> >>> Softwires mailing list

> >>> Softwires@ietf.org<=
/a>

> >>> https://www.ietf.org/mailman/listinfo/softwires

> >>

> >>

> >

> >

> > --

> >

> > ------

> > Best Regards,

> > Dapeng Liu

>

> _______________________________________________

> Softwires mailing list

> Softwires@ietf.org

> https://ww=
w.ietf.org/mailman/listinfo/softwires




--047d7b10ccb5ebea5504b9f366e3--

From maxpassion@gmail.com  Tue Feb 28 06:07:00 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7218621F866E for ; Tue, 28 Feb 2012 06:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.006
X-Spam-Level: 
X-Spam-Status: No, score=-3.006 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMTuY9xjQ0Nj for ; Tue, 28 Feb 2012 06:06:59 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A41521F8672 for ; Tue, 28 Feb 2012 06:06:59 -0800 (PST)
Received: by iagf6 with SMTP id f6so9524032iag.31 for ; Tue, 28 Feb 2012 06:06:56 -0800 (PST)
Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.42.177.133 as permitted sender) client-ip=10.42.177.133; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.42.177.133 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com
Received: from mr.google.com ([10.42.177.133]) by 10.42.177.133 with SMTP id bi5mr20802107icb.40.1330438016422 (num_hops = 1); Tue, 28 Feb 2012 06:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d4oECzPaSdetRdGpW4VPJ4JRn+ATGjVBtqw/6mte3t8=; b=KhgaHxJLvUo7x6vX1i6lu765mK2llpimDxOh484Zmev0JHQnqmPUFhBAFR1XueSmAn x1LCxZvArNI5JtG0NSveRZjYsPXfI0kuNiZEmQoJxbNpBiwmZGKyKfHFWBsO0DOBfsVX rdmc3VMqcqTS6Tw3GpwDxkeNgziNPtJXTU1ms=
MIME-Version: 1.0
Received: by 10.42.177.133 with SMTP id bi5mr16969968icb.40.1330438016345; Tue, 28 Feb 2012 06:06:56 -0800 (PST)
Received: by 10.42.161.74 with HTTP; Tue, 28 Feb 2012 06:06:56 -0800 (PST)
In-Reply-To: <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>    <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>
Date: Tue, 28 Feb 2012 22:06:56 +0800
Message-ID: 
From: liu dapeng 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "softwires@ietf.org" , tmohamed.boucadair@orange.com, Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 14:07:00 -0000

2012/2/27, R=E9mi Despr=E9s :
>
> Le 2012-02-27 =E0 12:04, liu dapeng a =E9crit :
>
>> Hi Remi,
>>
>> Please see my reply inline:
>>
>> 2012/2/27, R=E9mi Despr=E9s :
>>> Liu,
>>> Please see more clarification in line.
>>>
>>> Le 2012-02-24 =E0 13:21, liu dapeng a =E9crit :
>>>
>>>> 2012/2/23, mohamed.boucadair@orange.com =
:
>>>>> Dear Dapeng,
>>>>>
>>>>> Are you considering the endpoint (host or CPE) as part of the service
>>>>> provider's network?
>>>>>
>>>>> If not, please read the definition again with the answer in mind.
>>>>
>>>> Hi Med,
>>>>
>>>> Yes, I am considering CPE. There are two reasons:
>>>>
>>>> 1. The definition of "stateless" should not be bind to the provider's
>>>> network.
>>>
>>> Agreed.
>>>
>>>> The document should define "stateless" for the Internet not
>>>> only for the operator.
>>>
>>> Because the document deals only with solutions deployed within individu=
al
>>> ISP networks (similar in that to 6rd), it is AFAIK right to limit its
>>> stateless concern to individual ISP network.
>>
>> The solutions currently under study have many requirement&enhancement
>> to the CPE. So I think the document does not "deals only with
>> soltuions deployed within individual ISP networks" if not considering
>> the CPE as part of ISP network.
>
> Misunderstanding.
> Yes the 4/6 function of the CPE is part of the ISP-network solution, even=
 if
> the CPE isn't provided by the ISP.
> I think we agree on this.
>
>
>>
>>>>
>>>> 2. Even for CPE itself, in many cases, it should be considered as
>>>> provider's network since operator need to control/configure the CPE
>>>> remotely in that case.
>>>
>>> Agreed that CPEs, are part of the model.
>>> But the important point AFAIK is that, "stateless 4/6 solution" is
>>> defined
>>> in the document itself as meaning without "per-user state".
>>> All under-study solutions that refer to this draft are without "per-use=
r"
>>> state" in "active data plane network elements". They are therefore din
>>> scope
>>> of this draft.
>>
>>> If a CPE includes a NAT for its IPv4 operation (with states that are pe=
r
>>> only session states, and only IPv4), the 4/6 solution proper remains
>>> without
>>> "per-user state".
>>
>> If  having "per-user state" is stateful, why "per session state" is
>> not stateful?
>
> It is stateful too, yes, but differently.
> Also, if a CPE includes a NAT44, its states are not IPv4-over-IPv6 relate=
d
> (only IPv4 related).
> =3D> Would you be satisfied if, in the terminology section, definition of
> Stateless 4/6 solution and  Stateful 4/6 solution would be clarified as
> follows:
>
> Stateless  4/6 solution (or stateless solution in short): denotes in this
> document a solution which, as far as IPv4 aver IPv6 is concerned, does no=
t
> require any per-user state ...
>
> Stateful 4/6 solution  (or stateful solution in short): denotes in this
> document a solution which, as far as IPv4 aver IPv6 is concerned, require=
s
> neither per-customer nor per connection state ...
>
>>
>>> Considering that publication of this draft is much expected to pursue t=
he
>>> work on solutions themselves, and that it isn't freezing a standard (ju=
st
>>> clarifying a need that too many wanted to better understand), could you
>>> then
>>> agree that the draft can proceed as is.
>>
>> The concern that I have is: If we want to move forward, we need more
>> clear and strict definition of "stateless" and also need more
>> investigation before we give the conclusion that "stateless is
>> superior than stateful".
>
> The draft only reflects the wish of an number of operators to have a
> stateless solution standardized, acknowledging that this is in addition t=
o
> the more advanced stateful solutions (it doesn't even include the word
> "superior").
>
> Hoping that you will be more open to permit parallel progress on stateles=
s,
> Regards,

Hi Remi,

Thanks for the discussion but the fundamental question is:

If we consider [CPE(stateful) + BR(partially stateless maybe)] as a
stateless solution,

then, why  [CPE(stateless) + xlate(stateful)] is not a stateless solution?

Regards,
Dapeng Liu

> RD
>
>
>
>>
>> Thanks.
>>
>> Regards,
>> Dapeng Liu
>>
>>
>>> Thank you,
>>> RD
>>>
>>>
>>>>
>>>> regards,
>>>> Dapeng Liu
>>>>
>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : liu dapeng [mailto:maxpassion@gmail.com]
>>>>>> Envoy=E9 : jeudi 23 f=E9vrier 2012 12:04
>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>>> Cc : Softwire Chairs; softwires@ietf.org
>>>>>> Objet : Re: [Softwires] Closing
>>>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>>>
>>>>>> Hi Med,
>>>>>>
>>>>>> I think it is still not clear about the definition of "stateless", i=
n
>>>>>> current draft, it says:
>>>>>>
>>>>>> stateless denotes a solution which does not require any per-user sta=
te
>>>>>> (see Section
>>>>>> 2.3 of [RFC1958]) to be maintained by any IP address sharing
>>>>>> function in the Service Provider's network.
>>>>>>
>>>>>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maita=
in
>>>>>> state in CPE. It is obviously contradictory with this definition. We
>>>>>> need more discussion regarding the definition of "stateless".
>>>>>>
>>>>>> regards,
>>>>>> Dapeng Liu
>>>>>>
>>>>>> 2012/2/20, mohamed.boucadair@orange.com
>>>>>> :
>>>>>>> Dear chairs, WG members,
>>>>>>>
>>>>>>> The answers received so far are in favour of initiating a
>>>>>> WG LC on this
>>>>>>> document.
>>>>>>>
>>>>>>> As an editor of the document, I would like to progress this
>>>>>> document for the
>>>>>>> next IETF meeting. Chairs, could you please issue the WG LC? Thanks=
.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Med
>>>>>>>
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
>>>>>>>> Envoy=E9 : samedi 11 f=E9vrier 2012 09:30
>>>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>>>>> Cc : softwires@ietf.org
>>>>>>>> Objet : Re: [Softwires] Closing
>>>>>>>> draft-ietf-softwire-stateless-4v6-motivation
>>>>>>>>
>>>>>>>> In your previous mail you wrote:
>>>>>>>>
>>>>>>>>> (1) Either issue a WG LC, or
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Francis.Dupont@fdupont.fr
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Softwires mailing list
>>>>>>> Softwires@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> ------
>>>>>> Best Regards,
>>>>>> Dapeng Liu
>>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> ------
>>>> Best Regards,
>>>> Dapeng Liu
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>
>>
>> --
>>
>> ------
>> Best Regards,
>> Dapeng Liu
>
>


--=20

------
Best Regards,
Dapeng Liu

From tom.taylor.stds@gmail.com  Tue Feb 28 06:41:20 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0333421F85E4 for ; Tue, 28 Feb 2012 06:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.272
X-Spam-Level: 
X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ayqWlc5M0sr for ; Tue, 28 Feb 2012 06:41:19 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10C21F85D3 for ; Tue, 28 Feb 2012 06:41:19 -0800 (PST)
Received: by iagf6 with SMTP id f6so9567327iag.31 for ; Tue, 28 Feb 2012 06:41:19 -0800 (PST)
Received-SPF: pass (google.com: domain of tom.taylor.stds@gmail.com designates 10.50.180.194 as permitted sender) client-ip=10.50.180.194; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of tom.taylor.stds@gmail.com designates 10.50.180.194 as permitted sender) smtp.mail=tom.taylor.stds@gmail.com; dkim=pass header.i=tom.taylor.stds@gmail.com
Received: from mr.google.com ([10.50.180.194]) by 10.50.180.194 with SMTP id dq2mr2732690igc.42.1330440079255 (num_hops = 1); Tue, 28 Feb 2012 06:41:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=I+4jOma9jXitPG6G9DFIAPQGUWqqTpSNAbK6GJz6pH4=; b=JWN0duEJHL91sxyfJ8T2prBYyPM6V8rXMK8mPTInHszOpUGN6XpLN2JvJr1a/vivB4 vQwXKCIvF2yQp/ngaXNWjA+PQI8y3t0GRs7m7tR5fTqAMqWiKAkOxgGqus/LH/DfQI0D CPwK1Prt/4yVBOFmwR40Wue1K2awhKHL/NA0A=
Received: by 10.50.180.194 with SMTP id dq2mr2302156igc.42.1330440079223; Tue, 28 Feb 2012 06:41:19 -0800 (PST)
Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id b6sm13807121igj.7.2012.02.28.06.41.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 06:41:18 -0800 (PST)
Message-ID: <4F4CE78D.4020308@gmail.com>
Date: Tue, 28 Feb 2012 09:41:17 -0500
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: softwires@ietf.org, maxpassion@gmail.com
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>    <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120228-1, 28/02/2012), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 14:41:20 -0000

The fundamental issue is total cost to the operator. Different operators 
have different cost structures, hence need different engineering 
solutions. This isn't a matter of using precise language -- "stateless" 
is a term of convenience fitting the perceptions of the particular group 
of persons interested in the MAP and 4rd work.

Rather than argue over the use of the term, perhaps you could describe 
the engineering solution that interests you (though I suppose the 
question below gives a hint).

Tom Taylor

On 28/02/2012 9:06 AM, liu dapeng wrote:
...
>
> Hi Remi,
>
> Thanks for the discussion but the fundamental question is:
>
> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a
> stateless solution,
>
> then, why  [CPE(stateless) + xlate(stateful)] is not a stateless solution?
>
> Regards,
> Dapeng Liu
>
...

From despres.remi@laposte.net  Tue Feb 28 06:50:04 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E25F21F85AC for ; Tue, 28 Feb 2012 06:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.763
X-Spam-Level: 
X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2Xl0Vhf6xtu for ; Tue, 28 Feb 2012 06:50:04 -0800 (PST)
Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id C9A0F21F85A4 for ; Tue, 28 Feb 2012 06:50:03 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id fSq01i00737Y3f403Sq03L; Tue, 28 Feb 2012 15:50:02 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Tue, 28 Feb 2012 15:49:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>    <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net> 
To: Liu Dapeng 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 14:50:04 -0000

2012-02-28 15:06, liu dapeng :
...
> 2012/2/27, R=E9mi Despr=E9s :
...
>> The draft only reflects the wish of an number of operators to have a
>> stateless solution standardized, acknowledging that this is in =
addition to
>> the more advanced stateful solutions (it doesn't even include the =
word
>> "superior").
...
> Thanks for the discussion but the fundamental question is:
>=20
> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a
> stateless solution,
>=20
> then, why  [CPE(stateless) + xlate(stateful)] is not a stateless =
solution?


What I see as important is that IPv6-only routing can be deployed ASAP =
without sacrificing a good residual IPv4 service, including where ISPs =
prefer per-user stateless operation.

The point has already been made that functions are defined in the draft =
as "stateless" if they don't need (for IPv4 over IPv6) any "per-user" =
state.=20
A CE can therefore be considered stateless *in the draft* even if it has =
NAT44 (a function that is purely IPv4, and whose statefulness is per =
session). =20
Because of that, the draft is self consistent an doesn't need to be =
modified.

I do hope that, with these additional explanations, and in order to =
avoid waste of energy, you can accept to join a consensus that it is =
time to close this discussion and accept the draft.
=20

Looking forward to further discussions on solutions themselves,
Regards,
RD






=20





From sunqi.csnet.thu@gmail.com  Wed Feb 29 01:18:48 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18F21F87BE for ; Wed, 29 Feb 2012 01:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.581
X-Spam-Level: 
X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK0y5GkAfGp2 for ; Wed, 29 Feb 2012 01:18:48 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2393021F8841 for ; Wed, 29 Feb 2012 01:18:47 -0800 (PST)
Received: by iazz13 with SMTP id z13so255776iaz.31 for ; Wed, 29 Feb 2012 01:18:46 -0800 (PST)
Received-SPF: pass (google.com: domain of sunqi.csnet.thu@gmail.com designates 10.50.87.199 as permitted sender) client-ip=10.50.87.199; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of sunqi.csnet.thu@gmail.com designates 10.50.87.199 as permitted sender) smtp.mail=sunqi.csnet.thu@gmail.com; dkim=pass header.i=sunqi.csnet.thu@gmail.com
Received: from mr.google.com ([10.50.87.199]) by 10.50.87.199 with SMTP id ba7mr18783440igb.15.1330507126830 (num_hops = 1); Wed, 29 Feb 2012 01:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:reply-to:subject:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=7bQnUQktRq9DxQ1m048yxtrRj6sPMbaKXLhKyexMFWE=; b=RpJjEFF3NLeRQUAuc6H6jnm639bztMqTTm3T400C+ppk+HTeh7EpFDdRpK1iNpsFDz 5b/kEV2t8UGvkRmjyryNzKh6V93HIpOCbzN0KqFNmDeZf0/jN1qEAqRgCza25gx+I4Ar HJQpsWNvqTYUyVK6mfG2nhZatY3kQZzcSIVo0=
Received: by 10.50.87.199 with SMTP id ba7mr15353926igb.15.1330507126787; Wed, 29 Feb 2012 01:18:46 -0800 (PST)
Received: from sunqi ([166.111.68.231]) by mx.google.com with ESMTPS id dl10sm5073940igb.9.2012.02.29.01.18.42 (version=SSLv3 cipher=OTHER); Wed, 29 Feb 2012 01:18:46 -0800 (PST)
Date: Wed, 29 Feb 2012 17:18:37 +0800
From: "Qi Sun" 
To: "Tetsuya Murakami" 
X-Priority: 3
X-GUID: A32C4ADA-08F8-4E14-9045-260ACD6C77A3
X-Mailer: Foxmail 7.0.1.83[cn]
Mime-Version: 1.0
Message-ID: <2012022917183726704470@gmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart314588363826_=----"
Cc: softwires WG 
Subject: [Softwires] Comments on MAP-E draft
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "sunqi.csnet.thu" 
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 09:18:48 -0000

This is a multi-part message in MIME format.

------=_001_NextPart314588363826_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGkgTXVyYWthbWksDQogICAgIEl0J3MgYSBnb29kIGRyYWZ0IGFuZCBtYWtlcyBhIG5pY2Ugc3Vw
cG9ydCBmb3IgdGhlIE1BUCBtZWNoYW5pc20uIEkgd291bGQgbGlrZSB0byBwcm9wb3NlIHNvbWUg
Y29tbWVudHMgb24gdGhlIGRyYWZ0KHNvcnJ5IGlmIHRoZXkndmUgYmVlbiBkaXNjdXNzZWQgZXZl
cikuIFBsZWFzZSBjaGVjayBiZWxvdy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogU2VjdGlvbiA1LjIgUGFja2V0IEZv
cndhcmRpbmcgQmVoYXZpb3Igb24gTUFQLUUgQlINClBhcnQgKGIpIEJSIHJlY2VwdGlvbiBvZiBh
biBJUHY2IHBhY2tldA0KICAgICAgICAgICAgQlIgZGVyaXZlcyBhIENFIElQdjYgYWRkcmVzcyBm
cm9tDQogICAgICAgICAgICB0aGUgSVB2NCBzb3VyY2UgYWRkcmVzcyBvciB0aGUgSVB2NCBzb3Vy
Y2UNCiAgICAgICAgICAgIGFkZHJlc3MgYW5kIHRoZSBzb3VyY2UgcG9ydCBpbiB0aGUgZW5jYXBz
dWxhdGVkDQogICAgICAgICAgICBJUHY0IHBhY2tldCBiYXNlZCBvbiB0aGUgQk1SLiAgSWYgdGhl
IENFIElQdjYNCiAgICAgICAgICAgIGFkZHJlc3MgaXMgZXFhdWwgdG8gdGhlIElQdjYgc291cmNl
IGFkZHJlc3MgaW4NCiAgICAgICAgICAgIHRoZSByZWNlaXZlZCBJUHY2IHBhY2tldCwgQlIgZGVj
YXBzdWxhdGVzIHRoZQ0KICAgICAgICAgICAgSVB2NCBwYWNrZXQgYW5kIHRoZW4gZm9yd2FyZCBp
dCB2aWEgdGhlIElQdjQNCiAgICAgICAgICAgIGludGVyZmFjZS4NCkkgaGF2ZSBhIGZldyBxdWVz
dGlvbnMgaGVyZS4NCjEuIEhvdyBjYW4gdGhlIEJSIGdldCBmcm9tIGFuIElQdjYgcGFja2V0IHRo
ZSBJUHY0IHNvdXJjZSBhZGRyZXNzIG9yIHRoZSBJUHY0IHNvdXJjZSBhZGRyZXNzIGFuZCB0aGUg
c291cmNlIHBvcnQgaW4gdGhlIGVuY2Fwc3VsYXRlZCBJUHY0IHBhY2tldD8NCjIuIElmIHRoZSBy
ZWNlaXZlZCBJUHY2IHBhY2tldCBpcyBhIG5vcm1hbCBvbmUsIGluc3RlYWQgb2YgYW4gSVB2NC1l
bmNhcHN1bGF0ZWQgcGFja2V0LCB3aGF0IHdpbGwgdGhlIEJSIGRvPyAgVGhhdCBpcywgZG9zZSB0
aGUgQlIgY2FuIGFjdCBhcyBhIG5vcm1hbCByb3V0ZXI/DQozLiBXaGF0IGNhbiBjYXVzZSB0aGUg
aW5lcXVhbGl0eSBiZXR3ZWVuIHRoZSBkZXJpdmVkIENFIElQdjYgYWRkcmVzcyBhbmQgdGhlIElQ
djYgc291cmNlIGFkZHJlc3MgaW4gdGhlIHJlY2VpdmVkIElQdjYgcGFja2V0PyBBbmQgd2hhdCB3
aWxsIEJSIGRvIHdpdGggaXQsIGRpc2NhcmQgaXQgPyANCg0KSSdtIGxvb2tpbmcgZm9yd2FyZCB0
byB5b3VyIHJlcGx5fg0KDQpCZXN0IFJlZ2FyZHMsDQoNClFpIFN1bg0KVHNpbmdodWEgVW5pdmVy
c2l0eSwgQmVpamluZywgQ2hpbmE=

------=_001_NextPart314588363826_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Murakami,


   &n=
bsp; It's a good draft and=20
makes a nice support for the MAP mechanism. I would like to propose some=20
comments on the draft(sorry if they've been discussed ever). Please check=20
below.

-------------------------=
----------------------------------------


 Section 
5.2 Packet Forwarding=20
Behavior on MAP-E BR


Part (b) BR reception of an IPv6 packet


            BR derives a CE IPv6 address from
            the IPv4 source address or the IPv4 source
            address and the source port in the encapsulated
            IPv4 packet based on the BMR.  If the CE IPv6
            address is eqaul to the IPv6 source address in
            the received IPv6 packet, BR decapsulates the
            IPv4 packet and then forward it via the IPv4
            interface.


I have a few&nb=
sp;questions here.


1. How can the BR ge=
t from an IPv6=20
packet the IPv4 source address or the IPv4 source address and the sou=
rce=20
port in the encapsulated IPv4 packet?


2. If the received I=
Pv6 packet is a normal one,=20
instead of an IPv4-encapsulated packet, what will the BR do?  That is=
, dose=20
the BR can act as a normal router?


3. What can cause th=
e inequality between the=20
derived CE IPv6 address and the IPv6 source address in the received IPv6 p=
acket?=20
And what will BR do with it, discard it ? 


 


I'm looking forward =
to your reply~


 


Best Regards,


 


Qi Sun


Tsinghua University,=
 Beijing, China


 


------=_001_NextPart314588363826_=------


From maxpassion@gmail.com  Wed Feb 29 01:53:04 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B6621F8889 for ; Wed, 29 Feb 2012 01:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.978
X-Spam-Level: 
X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMf7HauyGbqY for ; Wed, 29 Feb 2012 01:53:04 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F211B21F8888 for ; Wed, 29 Feb 2012 01:53:03 -0800 (PST)
Received: by iazz13 with SMTP id z13so309805iaz.31 for ; Wed, 29 Feb 2012 01:53:01 -0800 (PST)
Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.186.198 as permitted sender) client-ip=10.50.186.198; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.186.198 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com
Received: from mr.google.com ([10.50.186.198]) by 10.50.186.198 with SMTP id fm6mr6107703igc.40.1330509181974 (num_hops = 1); Wed, 29 Feb 2012 01:53:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JFP90VTGxY4FtCiEdf74g2CI9vTx4pV9LPGh/ZN2kQY=; b=SPmFvk6NjK2Wem1+4OYbeUzoKTbakWPCv01ZIn1U4iyB1/1gk6Tjp+kXRtDXoIiqJG ugxFoUZbc0ZESrNa2kWMxDra6HB6NQI4enj9mV3Rur6FQkJzb7f0Uf1U5aVCtoNjwdmw 7hyRMR83rSvIbWnXsRrkMyMu8kT7BTLqHqYI4=
MIME-Version: 1.0
Received: by 10.50.186.198 with SMTP id fm6mr5077302igc.40.1330509181929; Wed, 29 Feb 2012 01:53:01 -0800 (PST)
Received: by 10.42.161.74 with HTTP; Wed, 29 Feb 2012 01:53:00 -0800 (PST)
In-Reply-To: 
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>    <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>  
Date: Wed, 29 Feb 2012 17:53:00 +0800
Message-ID: 
From: liu dapeng 
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Softwires WG , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 09:53:04 -0000

2012/2/28, R=E9mi Despr=E9s :
>
> 2012-02-28 15:06, liu dapeng :
> ...
>> 2012/2/27, R=E9mi Despr=E9s :
> ...
>>> The draft only reflects the wish of an number of operators to have a
>>> stateless solution standardized, acknowledging that this is in addition
>>> to
>>> the more advanced stateful solutions (it doesn't even include the word
>>> "superior").
> ...
>> Thanks for the discussion but the fundamental question is:
>>
>> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a
>> stateless solution,
>>
>> then, why  [CPE(stateless) + xlate(stateful)] is not a stateless solutio=
n?
>
>
> What I see as important is that IPv6-only routing can be deployed ASAP
> without sacrificing a good residual IPv4 service, including where ISPs
> prefer per-user stateless operation.
>
> The point has already been made that functions are defined in the draft a=
s
> "stateless" if they don't need (for IPv4 over IPv6) any "per-user" state.
> A CE can therefore be considered stateless *in the draft* even if it has
> NAT44 (a function that is purely IPv4, and whose statefulness is per
> session).
> Because of that, the draft is self consistent an doesn't need to be
> modified.
>
> I do hope that, with these additional explanations, and in order to avoid
> waste of energy, you can accept to join a consensus that it is time to cl=
ose
> this discussion and accept the draft.
>
>
> Looking forward to further discussions on solutions themselves,
> Regards,
> RD
>
Hello Remi

Firstly, this draft will mis-lead other operators thinking that this
is a pure stateless solution from the title and the document (maybe
terminology such as "Maping" is better). IETF WG should not hurry up
without the correct description on what the document is. For my
understanding, both of above two solutions are stateful solution. Even
in the first case of BR' side there are still stateful information for
control plane.

Secondly, since this is also stateful solution principally. Then why
IETF need to invent a second wheel about the same scenario, should
IETF obsolete previous one such as DS-Lite, then start to work on
this?

Thanks

-Dapeng

>
>
>
>
>
>
>
>
>
>

From ichiroumakino@gmail.com  Wed Feb 29 02:01:42 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458FF21F87F9 for ; Wed, 29 Feb 2012 02:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYhV91PDNGcW for ; Wed, 29 Feb 2012 02:01:41 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6849B21F87F8 for ; Wed, 29 Feb 2012 02:01:41 -0800 (PST)
Received: by werb10 with SMTP id b10so2987452wer.31 for ; Wed, 29 Feb 2012 02:01:40 -0800 (PST)
Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.79.229 as permitted sender) client-ip=10.180.79.229; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.79.229 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com
Received: from mr.google.com ([10.180.79.229]) by 10.180.79.229 with SMTP id m5mr47055950wix.6.1330509700582 (num_hops = 1); Wed, 29 Feb 2012 02:01:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=+QoIl7UfR1ZhXyrOf8dK2z3o2PMBCbsaNli3jwAEjug=; b=XSQUsZhA30I2lQxGi/TGRopU6hZVg0MZZNIZf4dsLI6FTDLdVUOAx+smB9KpZeNSG+ /3+RUrdWUiZm4l3AN0QEoY6u/8GOk8xhRTS1JvdJhnSg7ZYqe9PdKaF5VoGVL5RDok+3 AJX0sUnzuSuoEZlhIWGlt8pt6zA7VVI60HeWY=
Received: by 10.180.79.229 with SMTP id m5mr37424609wix.6.1330509700468; Wed, 29 Feb 2012 02:01:40 -0800 (PST)
Received: from [173.38.129.239] ([173.38.129.239]) by mx.google.com with ESMTPS id s2sm84852594wix.3.2012.02.29.02.01.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 02:01:39 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Wed, 29 Feb 2012 11:01:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>    <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>   
To: liu dapeng 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 10:01:42 -0000

> Firstly, this draft will mis-lead other operators thinking that this
> is a pure stateless solution from the title and the document (maybe
> terminology such as "Maping" is better). IETF WG should not hurry up
> without the correct description on what the document is. For my
> understanding, both of above two solutions are stateful solution. Even
> in the first case of BR' side there are still stateful information for
> control plane.
>=20
> Secondly, since this is also stateful solution principally. Then why
> IETF need to invent a second wheel about the same scenario, should
> IETF obsolete previous one such as DS-Lite, then start to work on
> this?

- there is new or _additional_ state introduced in the network
- existing state is kept close to the edge (RFC1958)

I don't see how this is going to mislead or confuse anyone.

what point are you trying to make? that the total amount of state in a =
DS-lite versus stateless solution is about the same? that's correct as =
far as it goes. but _where_ the state is does matter. no-one would argue =
against putting state in the end host or application, while adding state =
in the network is problematic for all the reasons outlined in the draft.

cheers,
Ole=

From despres.remi@laposte.net  Wed Feb 29 02:48:29 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D59721F890A for ; Wed, 29 Feb 2012 02:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Level: 
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgNWs3vszrul for ; Wed, 29 Feb 2012 02:48:15 -0800 (PST)
Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6400821F8907 for ; Wed, 29 Feb 2012 02:48:15 -0800 (PST)
Received: from [192.168.1.75] ([89.170.204.217]) by mwinf8503-out with ME id fmoA1i00C4hwz7503moA5C; Wed, 29 Feb 2012 11:48:13 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Wed, 29 Feb 2012 11:48:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <941C4201-CC42-4E27-A1E1-7E3970FC6F77@laposte.net>
References: <94C682931C08B048B7A8645303FDC9F35BC477AC05@PUEXCB1B.nanterre.francetelecom.fr> <201202110830.q1B8UDvM008903@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F35D8868DAA6@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F35D88A1402B@PUEXCB1B.nanterre.francetelecom.fr>    <418FA4E2-7586-4277-ABC6-7025823B6D0D@laposte.net>   
To: liu dapeng 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG , Softwire Chairs 
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 10:48:29 -0000

Le 2012-02-29 =E0 10:53, liu dapeng a =E9crit :

> 2012/2/28, R=E9mi Despr=E9s :
>>=20
>> 2012-02-28 15:06, liu dapeng :
>> ...
>>> 2012/2/27, R=E9mi Despr=E9s :
>> ...
>>>> The draft only reflects the wish of an number of operators to have =
a
>>>> stateless solution standardized, acknowledging that this is in =
addition
>>>> to
>>>> the more advanced stateful solutions (it doesn't even include the =
word
>>>> "superior").
>> ...
>>> Thanks for the discussion but the fundamental question is:
>>>=20
>>> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a
>>> stateless solution,
>>>=20
>>> then, why  [CPE(stateless) + xlate(stateful)] is not a stateless =
solution?
>>=20
>>=20
>> What I see as important is that IPv6-only routing can be deployed =
ASAP
>> without sacrificing a good residual IPv4 service, including where =
ISPs
>> prefer per-user stateless operation.
>>=20
>> The point has already been made that functions are defined in the =
draft as
>> "stateless" if they don't need (for IPv4 over IPv6) any "per-user" =
state.
>> A CE can therefore be considered stateless *in the draft* even if it =
has
>> NAT44 (a function that is purely IPv4, and whose statefulness is per
>> session).
>> Because of that, the draft is self consistent an doesn't need to be
>> modified.
>>=20
>> I do hope that, with these additional explanations, and in order to =
avoid
>> waste of energy, you can accept to join a consensus that it is time =
to close
>> this discussion and accept the draft.
>>=20
>>=20
>> Looking forward to further discussions on solutions themselves,
>> Regards,
>> RD
>>=20
> Hello Remi
>=20
> Firstly, this draft will mis-lead other operators thinking that this
> is a pure stateless solution from the title and the document (maybe
> terminology such as "Maping" is better). IETF WG should not hurry up
> without the correct description on what the document is. For my
> understanding, both of above two solutions are stateful solution. Even
> in the first case of BR' side there are still stateful information for
> control plane.
>=20
> Secondly, since this is also stateful solution principally. Then why
> IETF need to invent a second wheel about the same scenario,


> should
> IETF obsolete previous one such as DS-Lite, then start to work on
> this?

Surely not.
This debate has been finished when it was decided that Softwire would =
work ALSO on solutions that are stateless, at least in ISP gateways to =
the IPv4 Internet.

You may have not been personally part of this consensus, which is =
obviously your right, but the consensus remains.
Since no one prevents you from using stateful solutions of you choice, =
trying to prevent those who want a more stateless solution to have a =
specification isn't, IMHO, fair contribution to standardization.

RD =20
 =20
>=20
> Thanks
>=20
> -Dapeng
>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20


From adurand@juniper.net  Wed Feb 29 07:17:57 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D8821F8644 for ; Wed, 29 Feb 2012 07:17:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.369
X-Spam-Level: 
X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVLUgfAd5rQ1 for ; Wed, 29 Feb 2012 07:17:47 -0800 (PST)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4463E21F8633 for ; Wed, 29 Feb 2012 07:17:43 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT05BloNCo4f0LuzbPqTADYbWDNbRenUS@postini.com; Wed, 29 Feb 2012 07:17:47 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 29 Feb 2012 07:16:40 -0800
From: Alain Durand 
To: Softwires WG 
Date: Wed, 29 Feb 2012 07:16:38 -0800
Thread-Topic: Call for agenda items
Thread-Index: Acz29SMMvpX4G6TmQvyQeUhVnPPPog==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Yong Cui 
Subject: [Softwires] Call for agenda items
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 15:17:57 -0000

If you intend to present in Paris, please send Yong and I a request by 3/7.

   - Alain.

From ichiroumakino@gmail.com  Wed Feb 29 09:09:23 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3D921F85FB for ; Wed, 29 Feb 2012 09:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.269
X-Spam-Level: 
X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It007ThKCo5P for ; Wed, 29 Feb 2012 09:09:22 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8871721F85F6 for ; Wed, 29 Feb 2012 09:09:22 -0800 (PST)
Received: by wicr5 with SMTP id r5so2880121wic.31 for ; Wed, 29 Feb 2012 09:09:21 -0800 (PST)
Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.107.162 as permitted sender) client-ip=10.180.107.162; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.107.162 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com
Received: from mr.google.com ([10.180.107.162]) by 10.180.107.162 with SMTP id hd2mr19342372wib.8.1330535361478 (num_hops = 1); Wed, 29 Feb 2012 09:09:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=KvAlAr7oPsjuwb0EbC4cAqdp6nsrTaA5cx/LJai9bqw=; b=kidGqsLdvqi3/vC2yqONc2oRT3+4WFP2bOdXCGQN+HP/aW/r8NpmZkqVDne0eq6in2 yJnG9y0wj842J7zP+LbL53L9fCDuepBdSPfY3vfS6+S2Eb8X82p6458iP977CI7KfG+5 0i7FyPVpLytdFKqm2H98GnFdeH/f7Y0/y40Cw=
Received: by 10.180.107.162 with SMTP id hd2mr15440873wib.8.1330535361374; Wed, 29 Feb 2012 09:09:21 -0800 (PST)
Received: from dhcp-10-61-98-223.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fw5sm36347242wib.0.2012.02.29.09.09.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 09:09:20 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Ole_Tr=F8an?= 
In-Reply-To: 
Date: Wed, 29 Feb 2012 18:09:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Alain Durand , Yong Cui 
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG 
Subject: Re: [Softwires] Call for agenda items
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 17:09:23 -0000

Chairs,

> If you intend to present in Paris, please send Yong and I a request by =
3/7.

on behalf of the MAP design team I would like to request a set of slots =
to present the results of the DT effort.
 draft-mdt-softwire-mapping-address-and-port-03
 draft-mdt-softwire-map-dhcp-option-02
 draft-mdt-softwire-map-encapsulation-00
 draft-mdt-softwire-map-translation-00

cheers,
Ole
=20=

From jiangsheng@huawei.com  Wed Feb 29 17:36:57 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F181721E8056 for ; Wed, 29 Feb 2012 17:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.503
X-Spam-Level: 
X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7iEV2TYtk0M for ; Wed, 29 Feb 2012 17:36:57 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBAB21E804B for ; Wed, 29 Feb 2012 17:36:57 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0600H89N5H6Z@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 01 Mar 2012 09:36:54 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0600IK9N5HNG@szxga03-in.huawei.com> for softwires@ietf.org; Thu, 01 Mar 2012 09:36:53 +0800 (CST)
Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHD76718; Thu, 01 Mar 2012 09:36:53 +0800
Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Mar 2012 09:36:22 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.198]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Thu, 01 Mar 2012 09:36:43 +0800
Date: Thu, 01 Mar 2012 01:36:42 +0000
From: Sheng Jiang 
In-reply-to: 
X-Originating-IP: [10.108.4.88]
To: Alain Durand , Yong Cui 
Message-id: <5D36713D8A4E7348A7E10DF7437A4B92188F20D9@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: [Softwires] Call for agenda items
Thread-index: Acz29SMMvpX4G6TmQvyQeUhVnPPPov//mVsA//7uuoA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:  
Cc: Softwires WG 
Subject: Re: [Softwires] Call for agenda items
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Mar 2012 01:36:58 -0000

> > If you intend to present in Paris, please send Yong and I a request
> by 3/7.
> 
> on behalf of the MAP design team I would like to request a set of slots
> to present the results of the DT effort.
>  draft-mdt-softwire-mapping-address-and-port-03
>  draft-mdt-softwire-map-dhcp-option-02
>  draft-mdt-softwire-map-encapsulation-00
>  draft-mdt-softwire-map-translation-00

Dear Chairs,

We'd like to present our two MAP complemental drafts:
  draft-jiang-softwire-map-radius-00
  draft-fu-softwire-map-mib-00 (replacing draft-fu-softwire-4rd-mib)

Best regards,

Sheng
 
> cheers,
> Ole
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From tetsuya@ipinfusion.com  Wed Feb 29 18:14:09 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EEF21E801E for ; Wed, 29 Feb 2012 18:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level: 
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIAWKQSOw6x1 for ; Wed, 29 Feb 2012 18:14:08 -0800 (PST)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE0921E801C for ; Wed, 29 Feb 2012 18:14:08 -0800 (PST)
Received: by daec6 with SMTP id c6so172137dae.27 for ; Wed, 29 Feb 2012 18:14:08 -0800 (PST)
Received-SPF: pass (google.com: domain of tetsuya@ipinfusion.com designates 10.68.228.193 as permitted sender) client-ip=10.68.228.193; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of tetsuya@ipinfusion.com designates 10.68.228.193 as permitted sender) smtp.mail=tetsuya@ipinfusion.com
Received: from mr.google.com ([10.68.228.193]) by 10.68.228.193 with SMTP id sk1mr14233255pbc.60.1330568048100 (num_hops = 1); Wed, 29 Feb 2012 18:14:08 -0800 (PST)
Received: by 10.68.228.193 with SMTP id sk1mr11807985pbc.60.1330568048035; Wed, 29 Feb 2012 18:14:08 -0800 (PST)
Received: from [10.70.2.197] ([12.248.239.142]) by mx.google.com with ESMTPS id f8sm674490pbe.42.2012.02.29.18.14.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 18:14:07 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_02611177-E200-41F9-9438-2BB3B9E429B6"
From: Tetsuya Murakami 
X-Priority: 3
In-Reply-To: <2012022917183726704470@gmail.com>
Date: Wed, 29 Feb 2012 18:14:04 -0800
Message-Id: 
References: <2012022917183726704470@gmail.com>
To: sunqi.csnet.thu 
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQkK3vwLqXAMFkBWHLG/CMAntQ6e00jei7QC4voi0mIUQy21yJagAuQdRsgGLDnSvquHkAPs
Cc: softwires WG 
Subject: Re: [Softwires] Comments on MAP-E draft
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Mar 2012 02:14:09 -0000

--Apple-Mail=_02611177-E200-41F9-9438-2BB3B9E429B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Qi,

Thank you for your comments. Please see my comments in line.

On 2012/02/29, at 1:18, Qi Sun wrote:

> Hi Murakami,
>      It's a good draft and makes a nice support for the MAP mechanism. =
I would like to propose some comments on the draft(sorry if they've been =
discussed ever). Please check below.
> -----------------------------------------------------------------
>  Section=20
> 5.2 Packet Forwarding=20
> Behavior on MAP-E BR
> Part (b) BR reception of an IPv6 packet
>             BR derives a CE IPv6 address from
>             the IPv4 source address or the IPv4 source
>             address and the source port in the encapsulated
>             IPv4 packet based on the BMR.  If the CE IPv6
>             address is eqaul to the IPv6 source address in
>             the received IPv6 packet, BR decapsulates the
>             IPv4 packet and then forward it via the IPv4
>             interface.
> I have a few questions here.
> 1. How can the BR get from an IPv6 packet the IPv4 source address or =
the IPv4 source address and the source port in the encapsulated IPv4 =
packet?
In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text is =
for check the validation of the received packet. In terms of IPv6 packet =
received at BR, the IPv6 source address should be based on the IPv6 =
prefix delegated to CE. Also, according to the MAP rule, IPv4 address =
and port number can be derived from the same delegated IPv6 prefix. So, =
BR can calculate CE IPv6 address from the IPv4 source address and source =
port number in IPv4 packet encapsulated in the received IPv6 packet. If =
the calculation is failed, then the packet could be dropped. If the =
calculation is succeeded but the calculated CE IPv6 address is not =
matched to the source IPv6 address in the received IPv6 packet, then the =
packet could be dropped.

> 2. If the received IPv6 packet is a normal one, instead of an =
IPv4-encapsulated packet, what will the BR do?  That is, dose the BR can =
act as a normal router?

In this case, BR should handle this IPv6 packet based on the normal IPv6 =
routing because the next header is not IPv4 in this case.

> 3. What can cause the inequality between the derived CE IPv6 address =
and the IPv6 source address in the received IPv6 packet? And what will =
BR do with it, discard it ?

It might depend on the implementation. But the derived CE IPv6 address =
must be same as the IPv6 source address in case of MAP-E because the =
derived CE IPv6 address should be the tunnel end-point address on the =
CE. So, the received packet should be discarded or not processed as =
MAP-E packet.

Thanks,
Tetsuya Murakami

> I'm looking forward to your reply~
> =20
> Best Regards,
> =20
> Qi Sun
> Tsinghua University, Beijing, China
> =20


--Apple-Mail=_02611177-E200-41F9-9438-2BB3B9E429B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi Qi,

Thank you for your =
comments. Please see my comments in line.

On =
2012/02/29, at 1:18, Qi Sun wrote:

Hi Murakami,
     It's a =
good draft and makes a nice support for the MAP mechanism. I would like =
to propose some comments on the draft(sorry if they've been discussed =
ever). Please check =
below.
---------------------------------------------------------=
--------
 Section 

5.2 Packet Forwarding=20
Behavior on MAP-E BR
Part (b) BR =
reception of an IPv6 packet
            BR derives a CE IPv6 address from
            the IPv4 source address or the IPv4 source
            address and the source port in the encapsulated
            IPv4 packet based on the BMR.  If the CE IPv6
            address is eqaul to the IPv6 source address in
            the received IPv6 packet, BR decapsulates the
            IPv4 packet and then forward it via the IPv4
            interface.
I have a =
few questions here.
1. How can the BR get from an IPv6 =
packet the IPv4 source address or the IPv4 source address and the =
source port in the encapsulated IPv4 =
packet?
In case of MAP-E, IPv4 =
packet is encapsulated in IPv6. The above text is for check the =
validation of the received packet. In terms of IPv6 packet received at =
BR, the IPv6 source address should be based on the IPv6 prefix delegated =
to CE. Also, according to the MAP rule, IPv4 address and port number can =
be derived from the same delegated IPv6 prefix. So, BR can calculate CE =
IPv6 address from the IPv4 source address and source port number in IPv4 =
packet encapsulated in the received IPv6 packet. If the calculation is =
failed, then the packet could be dropped. If the calculation is =
succeeded but the calculated CE IPv6 address is not matched to the =
source IPv6 address in the received IPv6 packet, then the packet could =
be dropped.

2. If the received IPv6 packet is a normal one, =
instead of an IPv4-encapsulated packet, what will the BR do?  That =
is, dose the BR can act as a normal =
router?

In this =
case, BR should handle this IPv6 packet based on the normal IPv6 routing =
because the next header is not IPv4 in this case.

3. What can cause the inequality between the derived =
CE IPv6 address and the IPv6 source address in the received IPv6 packet? =
And what will BR do with it, discard it =
?

It might =
depend on the implementation. But the derived CE IPv6 address must be =
same as the IPv6 source address in case of MAP-E because the derived CE =
IPv6 address should be the tunnel end-point address on the CE. So, the =
received packet should be discarded or not processed as MAP-E =
packet.

Thanks,
Tetsuya =
Murakami

I'm looking forward to your =
reply~
 
Best =
Regards,
 
Qi Sun
Tsinghua =
University, Beijing, =
China
 

=

--Apple-Mail=_02611177-E200-41F9-9438-2BB3B9E429B6--

From despres.remi@laposte.net  Wed Feb 29 23:50:25 2012
Return-Path: 
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03121E802F for ; Wed, 29 Feb 2012 23:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.096,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tNqJi8Qfys8 for ; Wed, 29 Feb 2012 23:50:24 -0800 (PST)
Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 80B1C21E803C for ; Wed, 29 Feb 2012 23:50:23 -0800 (PST)
Received: from [192.168.1.75] ([89.170.204.217]) by mwinf8501-out with ME id g7qK1i00C4hwz75037qKrY; Thu, 01 Mar 2012 08:50:22 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 1 Mar 2012 08:50:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net>
References: 
To: Alain Durand , Yong Cui 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Call for agenda items
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Mar 2012 07:50:25 -0000

Alain, Yong,

Le 2012-02-29 =E0 16:16, Alain Durand a =E9crit :

> If you intend to present in Paris, please send Yong and I a request by =
3/7.

With several co-authors, we are preparing version-04 of =
draft-despres-softwire-4rd-u.
Unlike the previous version, it will only describe tunnels based on =
header-mapping (the unified 4rd solution designed to replace the =
two-standards approach of MAP-T + MAP-E).

We would like to have time to present it in Paris, noting that its =
substance covers the equivalent of 3 drafts of the MAP approach, plus =
some use-case examples.

Thanks,
RD
   =20

>=20
>   - Alain.
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires