Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Maoke <fibrib@gmail.com> Wed, 14 March 2012 09:00 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 12CFE21F866A for <softwires@ietfa.amsl.com>; Wed, 14 Mar 2012 02:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.195
X-Spam-Level:
X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=0.103, 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 fzSjoQ0VX55C for <softwires@ietfa.amsl.com>; Wed, 14 Mar 2012 02:00:32 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C1A21F8663 for <softwires@ietf.org>; Wed, 14 Mar 2012 02:00:28 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1753543ghb.31 for <softwires@ietf.org>; Wed, 14 Mar 2012 02:00:27 -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=zJvT8arjJDr5jkKArKaAP6GREKpwbj/qwApdGgBnPBc=; b=N8uBvSRdg4PoFKAFWh5jpMRhjAMgvyCqa+bwnZjCp7OOePncdY1CGAdM44G4I6RFPZ 1Xo3mkiyOl3UvlWiR3niT8H7sr0qnAMYI7BhaVcEZzFzD6P2DSgBn+GmUQju+wxXw4sJ TZPKgjqGOhnOp9sOY2TQbOYuJ/Q5bB8IYg157WFIs97RxFXjeHueChOzRAMo424qcUqv mLt2MGMWS5yaTOhpCL6l2wLEAvlsa7AJKYkj71JVa6pobqxs6zGJQpCpU2TjItqgGOJl 9pAx5Ah+r/Qaf7y/VkBTZXX2Y3oU3RENt/JH1+HQc7QO7O7WNrUrhAjlh3wYTy6NEsqk kf3g==
MIME-Version: 1.0
Received: by 10.229.136.200 with SMTP id s8mr587860qct.9.1331715627655; Wed, 14 Mar 2012 02:00:27 -0700 (PDT)
Received: by 10.229.98.21 with HTTP; Wed, 14 Mar 2012 02:00:27 -0700 (PDT)
In-Reply-To: <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net>
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> <CAFUBMqUqoEnNouOJzc2Z3iziQsCvqXDNjA9NtN94kGQnsay0LA@mail.gmail.com> <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>
Date: Wed, 14 Mar 2012 09:00:27 +0000
Message-ID: <CAFUBMqUVme5Vmm0QuJT4rcZeWo-CZyZoGBkq6RLjO=DRYLKYSg@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="002354530350eda12d04bb3034c8"
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: Wed, 14 Mar 2012 09:00:34 -0000
2012/3/14 Rémi Després <despres.remi@laposte.net> > > Le 2012-03-14 à 06:51, Maoke a écrit : > > > > 2012/3/13 Rémi Després <despres.remi@laposte.net> > >> 2012-03-13 12:02, Maoke : >> >> 2012/3/13 Rémi Després <despres.remi@laposte.net> >> >> ... >> >> The 4rd mechanism is for protocols that have ports at their usual place >>>> (all existing protocols that have ports have them at the same place, even >>>> if using another checksum algorithm like SCTP). >>>> >>> >> may you have a check on the statement of "all existing protocols" >> again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol >> over IP. >> >> >> I missed this one. >> None of the proposed stateless solutions supports it, but it remains that >> you are right: it has ports at a different place. >> > > alright. so 4rd-U doesn't not support "all existing transport protocol" > either. > > > Never said that without qualifying which protocols. > > but i suppose you may make an update in the 4rd-u-06 so that a new > "if...else..." is added the port pick-up logic, and surely the CNP is not a > problem for RDP because the old version (RFC908) has 32bit checksum but not > involving pseudo-header while the newer version (RFC1151) changed to use > TCP-checksum. no big deal but only needs a new patch to the draft. > > > In the Note in 4.4 (7), the first sentence is: > "This guarantees that, for all protocols that use the same checksum > algorithm as TCP, Tunnel packets are valid IPv6 packets, and this > independently from where the checksum field is placed for each protocol." > It can become: > "This guarantees that, for all protocols that use the same checksum > algorithm as TCP and have ports at the same place, Tunnel packets are > valid IPv6 packets, and this independently from where the checksum field is > placed for each protocol." > > Similarly, in the comparison table, H6 is: > "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as > future protocols using the TCP checksum algorithm" > It can become: > "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any > future protocol that might use the TCP checksum algorithm and ports at the > same place" > then it is fine. with these statement, 4rd-U can support - TCP - UDP - DCCP - any future or less well-known protocol as long as it uses TCP checksum and port at the same place as a counterpart, we may suggest MAP-T to state it supports - TCP - UDP - DCCP (with enforcing it rather than RFC6145's "optional") - any future or less well-known protocol, no matter what layout it is nor how the checksum is defined, with the similar logic of L4 checksum recalculation ;-) 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] 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