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

[Maoke <[e-mail]>]

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

>
> 2012-02-15 à 03:15, Maoke a écrit :
>
>
>
> 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.
>
>
> 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.
>

what if my NAT has understood XXXP but your CE hasn't? to my understanding,
CE only informs the restricted port set regardless of the protocol.


>
>
>
> 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".
>

it depends on the understanding of the "OPTIONAL". if it is OPTIONAL for
the operation domain, it is not a problem for double translation. if it is
OPTIONAL per device, the uncertainty is a problem where src-translator
makes DCCP checksum rewrite but dst-translator doesn't. (inverse case,
where src translator doesn't make but dst do, is not a problem though.)


>
>
> 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.
>

ok, i think we do understand your point but please check. you mean: if
addresses are checksum-neutral, we don't need to have a list of supported
protocol in BR and just let it pass any protocol with the assumption that
it is TCP-layouted/checksumed. if the "any protocol" happens to really have
TCP-layout and TCP-checksum, then things are happy and the addresses have
ensured the checksum validity even without L4 rewrite. if the "any
protocol", unfortunately, happens to have another layout and/or another
checksum, then BR also treat it as it were TCP-layouted/checksumed but let
it fail at the end host or CE. right?

here it is what i said R-22 (3) in 4rd-U is dangerous. it says:

   + If the packet Protocol is not ICMP, bits 0-15 for an
   IPv4 source address, and bits 16-31 for a destination
   address.

well doesn't it mean: even if the protocol has another layout, R-22 (3)'s
BR prefer to ignore the fact, making messy mapped addresses with blindly
assuming the protocol follows the TCP-layout!? (there is no NAT44 before BR
to ensure the "unknown" protocol has been dropped.) i would further point
out that, the messy mapped destination address may navigate your packet in
a wrong direction towards a wrong CE where even the "fail at end" may fail.

therefore i do agree Ole's argument. because we think any protocol should
be certainly supported, or certainly reported as not-supported, rather than
blindly trying a seemingly "universal" logic.


>
> 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
>

NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2 points:

1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. this
is not a behavior of encapsulation but a behavior of translation.

2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 message
will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. please note
that RFC6145 Sec 5.2 is a typical behavior of translation rather than
encapsulation. for the encapsulation, the semantics of ICMPv6 message
processing should be quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U
draft 03 contains the RFC2473 in the reference list but never cites it in
the main text).

if we say some fields are transparent, that's ok. but if we are talking
about the IP as a whole, TRANSPARENCY implies not only the consistency of
packet header fields but also the behavior of hiding details of the
carrying underlay infrastructure.

best,
maoke


> - 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.
>
> ...
>
>