Re: [Softwires] Checksum neutrality and L4-protocol independence

Rémi Després <despres.remi@laposte.net> Wed, 15 February 2012 14:45 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 00B7121E803A for <softwires@ietfa.amsl.com>; 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 <softwires@ietfa.amsl.com>; 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 <softwires@ietf.org>; 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: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAFUBMqWFiY+5oHucg83mAG3b3EW-xvjhoPTux_fUqfnp2Ee_Cw@mail.gmail.com>
Date: Wed, 15 Feb 2012 15:45:21 +0100
Message-Id: <9E4E7E78-336B-4871-B96A-2C11B4ECCD3B@laposte.net>
References: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net> <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <C694D7DC-2F98-434F-8123-751E2C1A98D0@employees.org> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <B94D39A0-CA66-4AE6-BDC5-E4DFA2D47BEC@employees.org> <A8A6FDA2-0FFC-44D2-BEDF-29FB012D3113@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <C38B2AD1-08F1-4ECD-8ADB-AE88BC34A0B9@laposte.net> <CAFUBMqW+RrHKYJbgLBSbm3RebQWcr6oMZRcCwbv3_QR13MLV1Q@mail.gmail.com> <9FD6B92C-9B42-4A30-9FF5-30A86F845E72@laposte.net> <CAFUBMqVygJv4k_zHsyccL-W3x_=tcaWe61_BoHheyN6p-FH5rA@mail.gmail.com> <8D2093C7-EC77-4CBA-9E4B-E4BEB3F74A26@laposte.net> <CAFUBMqWFiY+5oHucg83mAG3b3EW-xvjhoPTux_fUqfnp2Ee_Cw@mail.gmail.com>
To: Maoke <fibrib@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
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 <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, 15 Feb 2012 14:45:29 -0000

2012-02-15 à 03:15, Maoke a écrit :

> 
> 
> 2012/2/15 Rémi Després <despres.remi@laposte.net>
> 
> Le 2012-02-14 à 16:21, Maoke a écrit :
> 
>> 
>> 
>> 2012/2/14 Rémi Després 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) => 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 => ok, that the NAT44 checks protocol unknown. 
> (b) B initiates connection to A => 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 => 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.

> ...