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. 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
