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

[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.
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