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

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

Maoke,

In a forthcoming answer to another of you emails, on thread "4rd-u tunnels and stateful NAT64s", I will try to describe more completely what the latest 4rd brings in the stateful NAT64 context.


Le 2012-03-16 à 01:27, Maoke a écrit :
> 2012/3/15 Rémi Després <[e-mail]>
> Le 2012-03-15 à 14:52, Maoke a écrit :
>> 2012/3/15 Rémi Després <[e-mail]>
...
>> 
>> Just referring to:
>> 
>> DS-RFC6145-host --(v6net) -- NAPT64 -- IPv4 Internet
(Typo corrected, as indicated in another email)
>>  
>>  
>> 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.
> 
> then inside the host, there a RFC6145 module, right?

Right:
- RFC6535 says:
"When BIH is implemented at the network layer, the IPv4 packets are intercepted and converted to IPv6 using the IP conversion mechanism defined in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145].
- The v6ops draft on 464XLAT says that it combines "existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge". 


> my point is, if there is no NAT64 module, this cannot talk with another NAT64 box elsewhere as only one of the (src,dst)-pair is stateless IPv4-converted IPv6 address.

In my understanding, this discussion is about *stateful* NAT64s (those that work for hosts having no assigned public IPv4 address).
There is then no "stateless IPv4-converted IPv6 address" in this context.

> my previous analysis doesn't matter whether the translator and the end host are separated or integrated into one box.

Not sure to understand the point (which translator, and why separated?).
Yet, I think there is no problem here.

RFC6535 on BIH says:
"The IETF recommends using solutions based on dual stack or tunneling for IPv6 transition and specifically recommends against deployments utilizing double protocol translation."


This is why it is AFAIK useful, in BIH- and/or 464XLAT-capable hosts, to add support of 4rd NAT64+ mapping rules. 
Benefit is that, with upgraded NAT64s (NAT64+ supporting 4rd tunneling), DS hosts having no public IPv4 address  can reach IPv4 servers without any RFC6145 translation (avoiding transparency limitations)

In the answer I will send on on the other thread, I plan to restate this, and explain in more details. 
If you agree, we could limit this discussion to the other thread.

Regards,
RD


 


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