Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

Rémi Després <despres.remi@laposte.net> Wed, 14 March 2012 08:47 UTC

Return-Path: <despres.remi@laposte.net>
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 1DBD821F86E5 for <softwires@ietfa.amsl.com>; Wed, 14 Mar 2012 01:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level:
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.067, 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 OBesmUZNaue5 for <softwires@ietfa.amsl.com>; Wed, 14 Mar 2012 01:47:49 -0700 (PDT)
Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id B969021F86E1 for <softwires@ietf.org>; Wed, 14 Mar 2012 01:47:47 -0700 (PDT)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id lLng1i00s37Y3f403Lng4U; Wed, 14 Mar 2012 09:47:42 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-116--927141668"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAFUBMqWTRb_pjV_VFEDpNof7H+AnOvRM_acQXZ4XRPzAG-865A@mail.gmail.com>
Date: Wed, 14 Mar 2012 09:47:40 +0100
Message-Id: <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> <CAFUBMqUqoEnNouOJzc2Z3iziQsCvqXDNjA 9NtN94kGQnsay0LA@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>
To: Maoke <fibrib@gmail.com>
X-Mailer: Apple Mail (2.1084)
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 08:47:50 -0000

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"    

> 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