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

[Maoke <[e-mail]>]

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

>
> Le 2012-03-15 à 10:02, Maoke a écrit :
>
>
>
> 2012/3/15 Rémi Després <[e-mail]>
>
>> Maoke,
>>
>> Let's try, once more, to understand each other.
>>
>> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which
>> is AFAIAC a positive result of our discussion):
>> a) Such a CE can communicate with an IPv6-only host including in DCCP.
>> b) The same would apply to UDP lite if MAP-T would also require UDP-lite
>> translation.
>> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145,
>> i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate
>> DCCP (as permitted by RFC6145).
>> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose
>> DCCP translation, nodes complying with modified versions and those
>> complying with previous versions wouldn't be guaranteed to interwork for
>> DCCP.
>>
>> If we don't agree on this, there is still something to be clarified
>> between us.
>>
>
> surely do not. RFC6146 clearly states:
>
>    The current specification only defines how stateful NAT64 translates
>    unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
>    packets and other protocols, including the Stream Control
>    Transmission Protocol (SCTP), the Datagram Congestion Control
>    Protocol (DCCP), and IPsec, are out of the scope of this
>    specification.
>
>
> I said "If RFC614... would be modified to also impose DCCP translation" =>
> I take the point that you are not interested in that, but I don't think
> there was a contradiction.
> OK?
>

it is not yet modified. with the current statement of RFC6146, the current
equipment doesn't support DCCP. if it is modified, the update may state
mandatory imposement for DCCP. i don't see any problem here. on the other
hand, i cannot understand how the CNP helps stateful checksum validity. may
you please to clarify?

maoke


>
> RD
>
>
>
> - maoke
>
>
>> If we agree, I have nothing else on this point.
>>
>> Regards,
>> RD
>>
>>
>>
>> If, as you suggest,
>> 2012-03-15 02:04, Maoke:
>>
>> 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]>
>>>
>>> ...
>>
>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>>
>
>