2012/3/14 Rémi Després <[email protected]>
>
> Le 2012-03-14 à 10:00, Maoke a écrit :
>
>
>
> 2012/3/14 Rémi Després <[email protected]>
>
>>
>> Le 2012-03-14 à 06:51, Maoke a écrit :
>>
>>
>>
>> 2012/3/13 Rémi Després <[email protected]>
>>
>>> 2012-03-13 12:02, Maoke :
>>>
>>> 2012/3/13 Rémi Després <[email protected]>
>>>
>>> ...
>>>
>>> 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"
>>
>
> then it is fine. with these statement, 4rd-U can support
> - TCP
> - UDP
> - DCCP
> - any future or less well-known protocol as long as it uses TCP checksum
> and port at the same place
>
> as a counterpart, we may suggest MAP-T to state it supports
> - TCP
> - UDP
> - DCCP (with enforcing it rather than RFC6145's "optional")
> - any future or less well-known protocol, no matter what layout it is nor
> how the checksum is defined, with the similar logic of L4 checksum
> recalculation
>
>
> Maybe I get the point you are making: you implicitly consider that BR and
> CE modifications can be synchronized. This is feasible if ISPs provide all
> CE nodes, but not in the general case.
>
i don't consider their modifications are synced but i do consider that each
device, either BR or CE, should has a specification on its supported
functionalities.
>
> Changing DCCP support from optional to mandatory in RFC6145 isn't backward
> compatible (an upgraded node isn't guaranteed to interwork with a non
> upgraded node).
>
the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still
in development. if we state to enforce DCCP mandatorily rather than
optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward
compatible problem. to this extend, MAP-T is at the same kick-off line of
the 4rd-U.
>
> To be even more precise, H6 of the comparison table can be:
> "For ISPs that don't provide all CE nodes, and for shared IPv4 addresses,
> DCCP and UDP-Lite are supported, as well as future protocols using the TCP
> checksum algorithm and ports at the same place"
>
i actually think the original text is fine. "For .... shared IPv4
addresses" is not needed for 4rd-U, to my understanding, nor needed to
MAP-T.
maoke
>
> Does this cover the point?
>
> RD
>
>
>
>
>
> ;-)
> maoke
>
>
>>
>> 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
>>
>>
>>
>>
>>
>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
