Hi Fernando, I did qyuite some work on "Tiny Fragments" for IPv6 a while back. We seem to be having the same set of discussions over again. http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-03
The draft seemed to have been well received, but never got back to taking it to completetion. Let me know what you think of the work. Thanks, Vishwas On Sun, Dec 25, 2011 at 6:14 PM, Fernando Gont <ferna...@gont.com.ar> wrote: > Hi, Brian, > > On 12/24/2011 05:06 PM, Brian E Carpenter wrote: > >>>> That aside, I don't know whether e.g. NAT64 or the like used this > >>>> (.e.g, whether they are used for transition technologies as envisioned > >>>> in RFC 2460). However, it might also be the case that such "atomic > >>>> fragments" are generated when communicating through networks that do > >>>> not really have a MTU >= 1280. In such scenarios there might be some > >>>> for of gateway that sends the ICMPv6 PTB advertising a Next-Hop MTU > >>>> smaller than 1280, thus resulting in atomic fragments (such that it's > >>>> easier for the "gateway" to fragment the IPv6 packets). > >>> Yes, this seems a plausible explanation. I wouldn't consider this > >>> actual use, rather network misconfiguration. > >> > >> Why? > > > > MTU <1280 is a complete breach of the IPv6 standard, so it is by > > definition a misconfiguration. > > Well, as long as communication does work without requiring the sending > node to fragment packets to < 1280, the standard is not being "broken". > > In the scenario I was describing, the underlying reason for receiving an > ICMPv6 PTB <1280 might be a network that doesn't support an MTU >= 1280 > (and hence, that violates the standard). However, that's irrelevant as > long as the sending host is not required to fragment to <1280 for > communication to work. > > That aside, from my perspecitive std violation != misconfiguration. A > misconfiguration is probably the result of an error (probably on the > side of the administrator), while an std violation such as the one that > we're possibly talking about is most likely the result of a deliverate > action (which is probably not going to be fixed even if it's reported). > > Thanks, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
