Maoke, Please see inline.
Le 2012-03-16 à 11:34, Maoke a écrit : > 2012/3/16 Rémi Després <[email protected]> > 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 <[email protected]> >> Le 2012-03-15 à 14:52, Maoke a écrit : >>> 2012/3/15 Rémi Després <[email protected]> > ... >>> >>> 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? I don't plan to propose modifications of the informational draft on 464XLAT discussed in v6ops. What I propose is entirely in 4rd-u draft-05. - The goal is to better treat the 464XLAT *use case* that with its current protocol specification, exploiting for this what had been initially designed in the context of stateless solutions. - This use case is AFAIK characterized by DS nodes (hosts and/or routers) attached to an IPv6-only network in which they have no statelessly assigned IPv4 addresses. >> 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. With 4rd tunnels between CE nodes and NAT64+, IPv4 applications in DS nodes can access IPv4-only servers without using twice RFC5145. (RFC6145 is actually not used at all, thus ensuring better IPv4 transparency.) > 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? The draft defines the NAT64+ mapping rule as that which applies to IPv4 addresses reachable via a NAT64+. It also says that its Rule IPv4 prefix is /0, that its EA-bits length is 32, and that it is used by CEs that are assigned no public IPv4 address (and that are in a Domains having a NAT64+). > 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. When you have seen further explanations I just gave on the specific thread on NAT64+, we will see what you still find unclear. Regards, RD > > > > 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 <[email protected]> >>>>>>> >>>>>>> Le 2012-03-14 à 10:46, Maoke a écrit : >>>>>>>> >>>>>>>> 2012/3/14 Rémi Després <[email protected]> >>>>>> ... >>>>>>>> >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
