Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

[Maoke <[e-mail]>]

2012/3/14 Rémi Després <[e-mail]>

>
> Le 2012-03-14 à 10:46, Maoke a écrit :
>
>
>
> 2012/3/14 Rémi Després <[e-mail]>
>
>>
>> Le 2012-03-14 à 10:00, Maoke a écrit :
>>
>>
>>
>> 2012/3/14 Rémi Després <[e-mail]>
>>
>>>
>>> Le 2012-03-14 à 06:51, Maoke a écrit :
>>>
>>>
>>>
>>> 2012/3/13 Rémi Després <[e-mail]>
>>>
>>>> 2012-03-13 12:02, Maoke :
>>>>
>>>> 2012/3/13 Rémi Després <[e-mail]>
>>>>
>>>> ...
>>>>
>>>>  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.
>
>
> 1. I agree that, between CEs and BRs, there can be no problem for DCCP
> (provided the draft is completed to this effect). The comparison table was
> explicitly made with existing drafts, and intended to be updatable.
>
> 2. The MAP-T draft is also claimed to allow "communication between
> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only
> servers in the domain that are using IPv4-mapped IPv6 address". In this
> case, AFAIK, the backward compatibility problem exists
> Thought?
>

surely it does not exist. that statement applies to the MAP-T-compliant
equipments, when it is used as a IPv4-to-IPv6 single translator or as an
native IPv6 router. same deployment of equipments should support
double-translation, single-translation, and native IPv6 accesses
simultanenously. that's one of the points of the MAP-T.

- maoke


>
>
> 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.
>
>
> Will see what to do, then, when changes to the MAP-T draft concerning DCCP
> are known.
>

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