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

[Maoke <[e-mail]>]

2012/2/15 Rémi Després <[e-mail]>

>
> Le 2012-02-14 à 16:21, Maoke a écrit :
>
>
>
> 2012/2/14 Rémi Després [e-mail]
>
>>
>>
>  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. "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 => 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.

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 happens
>> not to be considered/implemented).
>>
>> cheers,
>> maoke
>>
>>
>>
>
>