2012/3/16 Rémi Després <despres.r...@laposte.net>
> 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 <despres.r...@laposte.net>
>
>> Le 2012-03-15 à 14:52, Maoke a écrit :
>>
>> 2012/3/15 Rémi Després <despres.r...@laposte.net>
>>
>> ...
>
>
>>> 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].
>
no different understanding here.
> - 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".
>
>
well, a new topic. i don't think you plan to apply CNP into v6ops-464xlat
/96 address format. do you?
>
> 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.
>
ok. then in BIH case, no case of stateless translator talking with stateful
NAT64. cleared.
>
> 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."
>
i remember people has clarified this. but my question is: do you mean 4rd
tunneling is a sort of the recommended tunneling? but the other message of
you said 4rd tunnel is not of "any" tunnel.
>
>
> 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)
>
actually i must say "NAT64+ mapping rule" is a very confusing concept. may
i understand it is a rule that, when the stateful translation is performed,
the translator using an (IPv4 addr, CNP) combination for the IID for an
IPv4 remote peer out of the domain? may i ask you for a detailed example on
how this NAT64+ address is used, with specifying a pair of source and
destination addresses, and explaining how such a scenario happens.
>
> 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 <despres.r...@laposte.net>
>>>>>>>
>>>>>>>>
>>>>>>>> Le 2012-03-14 à 10:46, Maoke a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/3/14 Rémi Després <despres.r...@laposte.net>
>>>>>>>>
>>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>>>> 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
>>>>>>> Softwires@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
