2012/3/15 Rémi Després <[email protected]> > > Le 2012-03-15 à 11:40, Maoke a écrit : > > > > 2012/3/15 Rémi Després <[email protected]> > >> >> Le 2012-03-15 à 10:29, Maoke a écrit : >> >> >> >> 2012/3/15 Maoke <[email protected]> >> >>> >>> >>> 2012/3/15 Rémi Després <[email protected]> >>> >>>> >>>> Le 2012-03-15 à 10:02, Maoke a écrit : >>>> >>>> >>>> >>>> 2012/3/15 Rémi Després <[email protected]> >>>> >>>>> 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?? (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"? - 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
