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]> > >> >> 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?? > > > 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? 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. my previous analysis doesn't matter whether the translator and the end host are separated or integrated into one box. - 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
