Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Maoke <fibrib@gmail.com> Thu, 15 March 2012 09:29 UTC
Return-Path: <fibrib@gmail.com>
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 A401E21F8661 for <softwires@ietfa.amsl.com>; Thu, 15 Mar 2012 02:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.22
X-Spam-Level:
X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.078, 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 m6ym4vigYbEL for <softwires@ietfa.amsl.com>; Thu, 15 Mar 2012 02:29:27 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0121F865F for <softwires@ietf.org>; Thu, 15 Mar 2012 02:29:26 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so3196551ggm.31 for <softwires@ietf.org>; Thu, 15 Mar 2012 02:29:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kI471ijo0sFeIak3NUMWdx3XBXUKS1jkOlyhgvDHmpM=; b=PwUkxZl/H3uhALS4oDVBR9i9LXf/eDCChCDtttfJCbcAe9kZ1+omNLfcYt812as+IK xNbJLMWh3WMldsSPJH+hKNxSYClkDofIobHpZOGgWThq2ru900rQYvN1qHKpVj1thbjx 3wlsBKsbh3w9yf9o4E+yEzfgnD0UdyIlQQAJmoGUHnsQAouRlut3l0IgvwdUanB7hSjr TaHGVgQ1lBsLTXM5r/Nw9McmPdjhGao1W3MGD1e8Mc0eaio9JH2qP8hL+DZ+vUZXWKW3 stEC+l/qI8lQzdNxfpo+uR8LRHJroDkc17VQ72lLmAn9lOZnpVBRnxQA1ofCoQj9M89q Z2bA==
MIME-Version: 1.0
Received: by 10.229.134.207 with SMTP id k15mr2024681qct.49.1331803765658; Thu, 15 Mar 2012 02:29:25 -0700 (PDT)
Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 02:29:25 -0700 (PDT)
In-Reply-To: <CAFUBMqU+Bv1L6b7BLOwYwACbma4nDhpq_5BziC_Y0qxvCGkJ_A@mail.gmail.com>
References: <B509CB1C-4A0A-408B-9B4A-C0F847169431@juniper.net> <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <D6428903-FBA0-419C-A37F-A00874F28118@laposte.net> <CAM+vMERsVz7cuC1C52gw12wySaEgw8=44JjS8AUygj0vJ899Cg@mail.gmail.com> <DDD20574-4ECD-4285-BB15-548628FB0425@laposte.net> <CAM+vMETahum9rB+fr=OHAmVobDZSzRRy9mUwkjryhqRvaJWe-Q@mail.gmail.com> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <CAAuHL_D68nkd36ifLzEeVR67Q124VH-pMhM1pkEE_PcLbGxBrw@mail.gmail.com> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <CAFUBMqX9dj8MSeZdJTic5iOT=Jjg4oihWs30FWVAca08v_3=7g@mail.gmail.com> <D476AFD2-3B6B-48A0-971D-C65CC2CFA46B@laposte.net> <CAFUBMqU1wtP5prSaLG8hDSuv-EGWP5Diqoj6WEMHb_q8hNVDdQ@mail.gmail.com> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <CAFUBMqVzbtZ7JxunHv7m1zgWjRa2sh7zZS+91aURAy8-xTZW8g@mail.gmail.com> <CAFUBMqXPAA7RjCzgvbuq0WqbKijXwuFebnmrL-zDx_XoZh=Xkg@mail.gmail.com> <FED38071-241D-480C-9A8A-CFA7A55A4F3B@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <CAFUBMqWv2V2PnZg5iTSuT6Jdbtredzj-4GPuS4VHqpDG+aP4dA@mail.gmail.com> <A4A7C9E3-DBA9-4AA5-A60B-E3D3A187BD7F@laposte.net> <CAFUBMqVT=E=GqBG_-q458GCpYKLk66vuvE-cx81=eTdgyUbj7A@mail.gmail.com> <D1EF9447-336A-48B4-91F4-D514654AC93D@laposte.net> <CAFUBMqWTRb_pjV_VFEDpNof7H+AnOvRM_acQXZ4XRPzAG-865A@mail.gmail.com> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <CAFUBMqUVme5Vmm0QuJT4rcZeWo-CZyZoGBkq6RLjO=DRYLKYSg@mail.gmail.com> <AD2E97A4-98FF-4F00-BC28-44AB430870FB@laposte.net> <CAFUBMqXi02DcrTkJ3zjt4fv8EvVJPfAv=CTkM7gesi95jNQSQQ@mail.gmail.com> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <CAFUBMqXuvBt6DD8JpWt_5+JP33ETqTrz3KbSRm1Kp9ZQBjqs+w@mail.gmail.com> <F2C46FAE-30EF-4707-8680-F4CED8A3A7F9@free.fr> <CAFUBMqU_ggCiE1Jr=HEAY1a1sunNXQZu1Oi98Jaa7jfd_0puLg@mail.gmail.com> <11773427-F939-4F5D-8011-C24E4B7FF58C@laposte.net> <CAFUBMqU+Bv1L6b7BLOwYwACbma4nDhpq_5BziC_Y0qxvCGkJ_A@mail.gmail.com>
Date: Thu, 15 Mar 2012 09:29:25 +0000
Message-ID: <CAFUBMqWOXU27iNucVzLCa=J7FN7XJ4UKcq1xCtdNbMyCp5fUXg@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="00248c767e965cd41f04bb44baf6"
Cc: Softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Mar 2012 09:29:28 -0000
2012/3/15 Maoke <fibrib@gmail.com> > > > 2012/3/15 Rémi Després <despres.remi@laposte.net> > >> >> Le 2012-03-15 à 10:02, Maoke a écrit : >> >> >> >> 2012/3/15 Rémi Després <remi.despres@free.fr> >> >>> Maoke, >>> >>> Let's try, once more, to understand each other. >>> >>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which >>> is AFAIAC a positive result of our discussion): >>> a) Such a CE can communicate with an IPv6-only host including in DCCP. >>> b) The same would apply to UDP lite if MAP-T would also require UDP-lite >>> translation. >>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, >>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate >>> DCCP (as permitted by RFC6145). >>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose >>> DCCP translation, nodes complying with modified versions and those >>> complying with previous versions wouldn't be guaranteed to interwork for >>> DCCP. >>> >>> If we don't agree on this, there is still something to be clarified >>> between us. >>> >> >> surely do not. RFC6146 clearly states: >> >> The current specification only defines how stateful NAT64 translates >> unicast packets carrying TCP, UDP, and ICMP traffic. Multicast >> packets and other protocols, including the Stream Control >> Transmission Protocol (SCTP), the Datagram Congestion Control >> Protocol (DCCP), and IPsec, are out of the scope of this >> specification. >> >> >> I said "If RFC614... would be modified to also impose DCCP translation" >> => I take the point that you are not interested in that, but I don't think >> there was a contradiction. >> OK? >> > > it is not yet modified. with the current statement of RFC6146, the current > equipment doesn't support DCCP. if it is modified, the update may state > mandatory imposement for DCCP. i don't see any problem here. > more clearly speaking: stateful NAT64, i think, only needs to be done once in a delivery, therefore either the DCCP is supported or it is not. there's no "interwork" between NAT64 who has been modified with the NAT64 who has not. incorrect? > on the other hand, i cannot understand how the CNP helps stateful checksum > validity. may you please to clarify? > > maoke > > >> >> RD >> >> >> >> - maoke >> >> >>> If we agree, I have nothing else on this point. >>> >>> Regards, >>> RD >>> >>> >>> >>> If, as you suggest, >>> 2012-03-15 02:04, Maoke: >>> >>> 2012/3/14 Rémi Després <despres.remi@laposte.net> >>> >>>> >>>> Le 2012-03-14 à 10:46, Maoke a écrit : >>>> >>>> >>>> 2012/3/14 Rémi Després <despres.remi@laposte.net> >>>> >>>> ... >>> >>> >>>>> Changing DCCP support from optional to mandatory in RFC6145 isn't >>>>> backward compatible (an upgraded node isn't guaranteed to interwork with a >>>>> non upgraded node). >>>>> >>>> >>>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is >>>> still in development. if we state to enforce DCCP mandatorily rather than >>>> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward >>>> compatible problem. to this extend, MAP-T is at the same kick-off line of >>>> the 4rd-U. >>>> >>>> >>>> 1. I agree that, between CEs and BRs, there can be no problem for DCCP >>>> (provided the draft is completed to this effect). The comparison table was >>>> explicitly made with existing drafts, and intended to be updatable. >>>> >>>> 2. The MAP-T draft is also claimed to allow "communication between >>>> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only >>>> servers in the domain that are using IPv4-mapped IPv6 address". In >>>> this case, AFAIK, the backward compatibility problem exists >>>> Thought? >>>> >>> >>> surely it does not exist. that statement applies to the MAP-T-compliant >>> equipments, when it is used as a IPv4-to-IPv6 single translator or as an >>> native IPv6 router. same deployment of equipments should support >>> double-translation, single-translation, and native IPv6 accesses >>> simultanenously. that's one of the points of the MAP-T. >>> >>> - maoke >>> >>> >>>> >>>> >>>> To be even more precise, H6 of the comparison table can be: >>>>> "For ISPs that don't provide all CE nodes, and for shared IPv4 >>>>> addresses, DCCP and UDP-Lite are supported, as well as future protocols >>>>> using the TCP checksum algorithm and ports at the same place" >>>>> >>>> >>>> i actually think the original text is fine. "For .... shared IPv4 >>>> addresses" is not needed for 4rd-U, to my understanding, nor needed to >>>> MAP-T. >>>> >>>> >>>> Will see what to do, then, when changes to the MAP-T draft concerning >>>> DCCP are known. >>>> >>> >>>> RD >>>> >>>> >>>> >>>> >>>> maoke >>>> >>>> >>>>> >>>>> Does this cover the point? >>>>> >>>>> RD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ;-) >>>>> maoke >>>>> >>>>> >>>>>> >>>>>> but this is not my point. my point is: there must be something we >>>>>> don't know ("non omnia possumus omnes"). even we have gone through the >>>>>> RFCs, there might be some other proprietary L4 protocols, or experimental >>>>>> protocols. even they are minority, i don't think ignoring their existance >>>>>> in our solution fits the spirit of the Internet. it might be argued that >>>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may >>>>>> makes his own NAT44, either attached to the CE or separated. if 4rd-U >>>>>> respects such an effort, it should state "currently blahblabla L4 protocols >>>>>> are supported". the similar statement applies to the RFC6145 or MAP as well. >>>>>> >>>>>> >>>>>> i somehow am hard to accept words like "far fetched theoretical >>>>>> problem". >>>>>> >>>>>> >>>>>> If I had thought it might be so, I would have avoided the word. >>>>>> >>>>>> >>>>>> the L4-recalculate is a generic, architectural solution, surely >>>>>> needing codes for every L4 protocol. but this generality in architecture >>>>>> makes RFC6145 or MAP-T equipment be easily enhanced to support anything new >>>>>> with the same logic. but for the 4rd-U BR, it looks to me we cannot have >>>>>> the unified logic for all (even limited to existing and well-known) L4 >>>>>> protocols. >>>>>> >>>>>> only my 2 cents. >>>>>> >>>>>> >>>>>> With amendments above, the point is AFAIK completely covered: >>>>>> everything is rigorously true, and worth noting. >>>>>> Thanks for the useful reference to the RDP of RFC1151. >>>>>> >>>>>> RD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> >> >> >
- [Softwires] Call for agenda items Durand, Alain
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Templin, Fred L
- Re: [Softwires] Call for agenda items Mingwei Xu
- Re: [Softwires] Call for agenda items Sheng Jiang
- [Softwires] Call for agenda items Alain Durand
- Re: [Softwires] Call for agenda items mohamed.boucadair
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Mingwei Xu
- Re: [Softwires] Call for agenda items Yiu L. Lee
- Re: [Softwires] Call for agenda items Templin, Fred L
- Re: [Softwires] Call for agenda items Templin, Fred L
- Re: [Softwires] Call for agenda items Mingwei Xu
- Re: [Softwires] Call for agenda items Jacni Qin
- Re: [Softwires] Call for agenda items Tina Tsou
- Re: [Softwires] Call for agenda items Sheng Jiang
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] Call for agenda items Tomasz Mrugalski
- Re: [Softwires] Call for agenda items Eleven Fu(Yu)
- Re: [Softwires] Call for agenda items GangChen
- [Softwires] Call for agenda items Alain Durand
- Re: [Softwires] Call for agenda items Xing Li
- Re: [Softwires] Call for agenda items Jacni Qin
- Re: [Softwires] Call for agenda items xiaohong.deng
- Re: [Softwires] Call for agenda items Reinaldo Penno
- Re: [Softwires] Call for agenda items Tetsuya Murakami
- Re: [Softwires] Call for agenda items GangChen
- Re: [Softwires] Call for agenda items Ole Troan
- Re: [Softwires] Call for agenda items GangChen
- Re: [Softwires] Call for agenda items Shishio Tsuchiya
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Qiong
- [Softwires] Call for agenda items Alain Durand
- Re: [Softwires] Call for agenda items Ole Trøan
- Re: [Softwires] Call for agenda items Sheng Jiang
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Shishio Tsuchiya
- Re: [Softwires] Call for agenda items Behcet Sarikaya
- Re: [Softwires] Call for agenda items Qiong
- [Softwires] IPv4 Residual Deployment - Unified-st… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Behcet Sarikaya
- Re: [Softwires] Call for agenda items Naoki Matsuhira
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… GangChen
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] Call for agenda items Peng Wu
- Re: [Softwires] IPv4 Residual Deployment - Unifie… GangChen
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Washam Fan
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] Call for agenda items Naoki Matsuhira
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Lee, Yiu
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] Call for agenda items Naoki Matsuhira
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després