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

[Maoke <[e-mail]>]

Remi,

up to this message, i think we both have stated our points and have
clarified where we agree to each other where we don't. for some part, even
with the different terminology, we have known what each other are talking
about. it looks i have no further comments for this thread any more. :)

thanks and regards,
maoke

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

>
> Le 2012-02-16 à 12:19, Maoke a écrit :
>
> 2012/2/16 Rémi Després <[e-mail]>
>
>>
>> Le 2012-02-16 à 03:34, Maoke a écrit
>>
>> 2012/2/15 Rémi Després <[e-mail]>
>>>
>>> 2012-02-15 à 03:15, Maoke a écrit :
>>>
>>>
>>> "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.
>>
>>
>> 2 cases:
>> - If the new protocol has ports at their usual place, and has TCP-like
>> checksum, no problem. "Your CE", as you call it, does forward packets of
>> the new protocol.
>> - In other cases, any CE or BR would need needs an update to work, and
>> incompatibilities cold result.
>>
>>
>> ...
>>
>>
>>>  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.)
>>
>>
>> Optional "for the operation domain" would work only if there would be
>> means to inform CEs of the choice made for the domain.
>> Such means don't exist, right?
>>
>
> agree. for this point, we'd prefer to propose an update to RFC6145 in
> order to clear the uncertainty, if the authors have not other concern we
> haven't noticed.
>
>
> Seems good to me.
> However, a specification change doesn't ensure that all devices support
> the change.
> A problem therefore remains.
>
>
>
>>
>>
>> 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?
>>
>>
>> Yes.
>> We are in sync on this point.
>>
>
> good. thanks!
>
>
>>
>>
>> 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.
>>
>>
>> Still a misunderstanding here.
>> No new protocol will work for shared IPv4 addresses, be it with MAP or
>> 4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their usual
>> place, and a TCP-like checksum somewhere).
>> A NAT44 that is coupled with a CE MUST remain operational ONLY for
>> "traditional" protocols.
>>
>> (Future protocols, if not "traditional", will need IPv6 to work safely,
>> including with shared-IPv4-address CEs.
>>
>
> it confuses me.
>
>
> if there is no new protocol, where we have the talking topic on the
> *change* of BR? neither MAP nor 4rd-U needs change if there is no new
> protocol.
>
>
> Clear.
>
> if there is new protocol in consideration, how do you assert such a new
> protocol surely not work for shared IPv4 addresses unless it is a
> "traditional" one?
>
>
> Yes, I do suggest that a transition tool such as MAP/4rd shouldn't be
> modified to support a new protocol that would have been be specified with
> consciousness that it is difficult to support in NAT44s.
>
> do you mean non-traditional protocol is nonsense and we have no obligation
> to consider?
>
>
> A nonsense, by no means!
> Defining new protocols, even with non-TCP checksum, can make a lot of
> sense, but only in the context of IPv6.
>
>
> or do you mean, new protocol working with shared IPv4 addresses must be
> traditional?
>
>
> My point is that any new protocol that should work for hosts having IPv4
> shared addresses SHOULD use the TCP-like checksum, yes.
> (I use SHOULD instead of MUST because we talk about the future, which is
> uncertain by nature.)
>
>
>  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.
>>
>>
>> 1.
>> I don't know which "Ole's argument" you agree to (making your own points
>> directly would be clearer).
>>
>
> i think i focuses on the point that the "BR needs no change ...".
>
>
>>
>> - In particular, Ole wrote "any A+P solution requires support for L4
>> protocols to extract ports. L4 checksum rewrite, as well as port extraction
>> will have to be supported for all new L4 protocols."
>> - The fact is that 4rd-U, because of checksum neutrality, doesn't have to
>> support L4 checksum rewrite. Yet, it is an A+P solution that has no
>> identified operational problem.
>>
>> 2.
>> 4rd-U "certainly" supports All "traditional" protocols, an Echo requests
>> in identified conditions,  and nothing else.
>> MAP-T is AFAIK uncertain for DCCP.
>>
>
> MAP-T has been in running code and it is not complicated to remove the
> uncertainty with changing the OPTIONAL to a definite word, unless there is
> something we haven't noticed.
>
>
> This point has no relationship with the fact that checksum neutrality
> provides BR support of all L4 protocols using TCP-like checksum.
>
>
>  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.
>>
>>
>> 1.
>> Well, there remains an inconsistency that I didn't see in the 4rd-U
>> draft(!):
>> - "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class
>> that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel
>> traversal is treated in IPv4 as a single-link traversal.
>>
>
> right, here the "single-link traversal" causes TTL decreases more than 1.
> well, you removed this self-contradictory.
>
>
>>  Without it, Explicit Congestion Notification of [RFC3168] MAY be
>> propagated from intermediate IPv6 nodes to IPv4 destinations,
>>
>
>
> and IPv4 Time to live values progress with the number of traversed IPv6
>> links."
>>
>
> Note that this part of the sentence no longer appears in the revised R-4
>
>
> misunderstanding!
>
>
> please note that ECN being propagated from intermediate IPv6 to IPv4 is
> correct even for the mode of encapsulation!
>
>
> Exactly, where it it applies in 4rd-U (no Tunnel traffic class
> parameter) it does it for both -H AND -E.
>
>
> because congestion is a link-wise behavior. RFC3168 Sec 9 discussed this
> and its succeeding updates RFC6040 takes a huge effort in order to achieve
> compatibility among different processing proposals regarding the potential
> inconsistency between the outer header's ECN and inner header's ECN. the
> basic operation is: tunnel entry point should copy ECN from inner to outer
> header while tunnel exit should copy ECN from outer to inner.
>
>
> Right
>
>
>
> - Table 2 has:
>> +---------------------+-----------------------------------+
>> | IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT         |
>> +---------------------+-----------------------------------+
>>                     ...
>> | Time to live        | Hop limit                         |
>>                     ...
>> +---------------------+-----------------------------------+
>>
>>  Correction should be:
>> "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class
>> that BRs and CEs MUST set in Tunnel packets.  Without it, Explicit
>> Congestion Notification of [RFC3168] MAY be propagated from intermediate
>> IPv6 nodes to IPv4 destinations."
>> Thanks for the opportunity to notice this inconsistency.
>>
>> 2.
>> IPv4 time-to-live of an IPv4 may thus progress by more than one during
>> domain traversal, right, but this isn't a breach to IPv4 end-to-end
>> transparency (the TTL is THE field that always evolve during network
>> traversal).
>>
>
>>
>> 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).
>>
>>
>> 1. How an IPv6-generated ICMP message is translated into an IPMPv4
>> message, doesn't belong to "IPv4 transparency".
>>
>
> "belongs to" or not is only a text gaming. i focus on the behavior:
>
>
> you stated it is "as encapsulation" and therefore i argue its behavior is
> not encapsulation behavior at all.
>
>
> 4rd-H IS NOT "encapsulation" (not more than it is "double translation").
> The only claim is that it is, end-to end, as transparent to IPv4 packets
> as encapsulation.
>
>
>
>
>> 2. MAP-E has the same need. Otherwise unreachable CEs couldn't be
>> signaled to IPv4 sources, right?
>>
>
> MAP-E applying any existing encapsulation standard such as RFC2473 or GRE
> as the packet processing method surely has been ready for that. the same
> need has been satisfied without need to define again. it could be emphasize
> the RFC2473's ICMPv6-to-ICMPv4 processing is consistent with the semantics
> of "virtual link" which the encapsulation contributes to the Internet
> architecture.
>
>
> I didn't see this ICMP translation in the BR behavior of the MAP-E draft
> sec. 5.2, but it certainly can be added.
> In any case, this doesn't make 4rd-U less end-to-end transparent to IPv4
> than encapsulation.
>
>
> The point remains that 4rd-U is "as transparent to IPv4 as MAP-E".
>>
>
> narrow sense transparency, no problem in wording. but i suppose people are
> concerning the behavior rather than the wording itself.
>
>
>> This is AFAIK a simple and important fact (it was designed for that).
>>
>>
>> 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.
>>
>>
>> Agreed.
>> (But with due understanding of the exception of time-to-live: it always
>> decreases end to end, and more or less depending on peculiarities of
>> traversed infrastructures).
>>
>
> encapsulation makes underlay as a link-layer, and certainly the TTL only
> decreases by 1 if no trouble. decreasing as the same in the underlay
> network is the behavior of translation.
>
>
> it exposes the details of the underlay and therefore not transparent as
> encapsulation.
>
>
> Different view (IMHO, this statement is just playing with words)
>
> Regards,
> RD
>
>
>
>
> best,
> maoke
>
>
>>
>>
>> Regards,
>> RD
>>
>>
>>
>>
>>
>> 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.
>>>
>>> ...
>>>
>>>
>>
>>
>
>