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:29, Maoke a écrit :
>
>
>
> 2012/3/15 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.
>>
>
> more clearly speaking: stateful NAT64, i think, only needs to be done once
> in a delivery, therefore either the DCCP is supported or it is not. there's
> no "interwork" between NAT64 who has been modified with the NAT64 who has
> not. incorrect?
>
>
> The full sentence was: "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."
>
> I assumed an RFC6145 complying node can talk to a NAT64, right or not?
>

you mean the stateful NAT64-ed IPv4 host (let's call it A) having access to
an IPv4 host (let's call it B) behind a stateless RFC6145 translator,
mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not
right that RFC6145 complying node can talk to a NAT64. let's see the
details:

model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145
translator --- B

because A would be translated by NAT64 to an arbitrary IPv6 address, A',
which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6145
translator cannot handle it statelessly for any end-to-end communication.
the box in front of B should be another NAT64, and as i said previously, no
problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum;
if the other doesn't support, it drops DCCP. no case of asymmetrically
processed but end-to-end deliverable DCCP here.

- maoke


> (A NAT64 talking to another NAT64 was part of what I wrote!!!)
>
> RD
>
>
>
>
>
>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>