2012/3/15 Rémi Després <[email protected]> > > Le 2012-03-15 à 10:22, Maoke a écrit : > > > > 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. > > > OK, we are now in sync on this point :-). > > on the other hand, i cannot understand how the CNP helps stateful checksum > validity. may you please to clarify? > > > On this new subject, could you be more precise on what you mean > by "stateful checksum validity"? >
i mean i didn't understand the how the stateful NAT64 benefits from CNP. maoke > > RD > > > > > > 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
