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

[Rémi Després <[e-mail]>]

Le 2012-03-15 à 14:52, Maoke a écrit :

> 
> 
> 2012/3/15 Rémi Després <[e-mail]>
> 
> Le 2012-03-15 à 11:40, Maoke a écrit :
> 
>> 
>> 
>> 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?
> 
> 
> Just referring to:
> 
> DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet
>  
>  
> what is RFC6145-host??

E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports IPv4 applications and is attached to an IPv6-only network.
Clear enough?

> (seeing you have corrected the v4net with v6net) if it is a host connected to an IPv6 network, it is the case of single NAT64, where we have the problem of "interwork"?

See above.

RD


>  
> - maoke
>  
>  
> 
> Is this excluded?
> 
> RD
> 
> 
>> 
>> 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
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
>