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? (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
