Hi Tom, If a statement proceeds to be added, I propose something like this in the introduction:
Warning: on paths that traverse MAP-T IPv6 networks, ICMP-independent PathMTU Discovery, as specified in [RFC 4821], ceases to be reliable. (This is because DF=1/MF=1 combination, used in [RFC 4821], becomes DF=0&MF=1 after traversal of a MAP-T network). This specification is for service providers that, being conscious of this limitation, accept it as negligible. (This is, I believe, more explanatory here than what Gang had proposed in the different context of 464XLAT.) Regards, RD 16 nov. 2014 16:12, Tom Taylor <[email protected]> : > As a WG participant aware of the history of this whole effort, I would > support adding the statement to MAP-T in particular. > Tom Taylor > > On 15/11/2014 11:45 PM, Ole Troan wrote: >> Remi, >> >>>> It is true that double translation has the problem that the DF bit is not >>>> communicated through. This is a limitation of the MAP-T specification. >>> >>>> I've asked the authors about this, and they did not deny that this >>>> limitation exists, >>> >>> Good to know authors confirmed. >>> (Note that denial would have been difficult. That’s just a simple technical >>> analysis.) >>> But did they confirm my complete point, namely that MAP-T breaks the >>> ICMP-independent Path MTU Discovery of RFC4821? >>> If they didn’t, the fact remains, is important, and is also easy to verify. >> >> while you may consider it simple, it took me quite some effort to refresh >> all the context necessary, thanks for providing the simple explanation of >> the issue. >> >> you are correct that MAP-T has this issue (or any double translation using >> RFC6145) including 464XLAT. >> >>>> so your claim that the authors are trying to conceal it seems a bit >>>> un-collegial. >>> >>> It seemed to you a bit un-collegial, but it certainly didn’t intend to be: >>> - To explain why I didn’t insist at that time to document the PMTUD >>> problem, I just said "I felt a strong preference of MAP-T authors for >>> keeping it concealed, and I had to move to other activities." . >>> - This is just the truth about what I felt then. >>> - In any case, if anyone is crossed by what I said, I apologize for having >>> told, in good faith but too frankly, what I had felt. >> >> not claiming to speak for all the authors here, but I don't think anyone was >> trying to conceal anything. I think it was more that we didn't feel that the >> issue was serious enough to warrant not reusing RFC6145 for double >> translation. (I also think someone did measurements in live networks looking >> for DF=MF=1 packets and found very few?) >> >> >>>> As I said, the working group did consider this issue, and it was not a >>>> factor in the coin toss. >>> >>> This seems to suggest that someone viewed this issue had been "a factor in >>> the coin toss". >>> No one did AFAIK, and certainly not me. >>> But this isn’t the point. >>> >>> Even in its experimental status, I do think MAP-T's specification should >>> have included a warning that it is incompatible with Path MTU Discovery of >>> RFC4821, and that MAP-E should be used if such compatibility is desired. >>> >>> Yet, IMHO, harm of this warning being absent remains limited enough to be >>> acceptable as long as the status of MAP-T remains Experimental. >> >> we had this exact same discussion 464XLAT, RFC6877. in the end the >> disclaimer wasn't included in that document. >> >> I agree with you that the issue is worth pointing out though, with f.ex text >> similar to what was proposed for RFC6877. see: >> https://mailarchive.ietf.org/arch/msg/v6ops/66dSxb-i9kjGi1UeySBu5MYAV3w >> >> cheers, >> Ole >> >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
