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