> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Fernando Gont > Sent: Sunday, December 25, 2011 6:14 PM > To: Brian E Carpenter > Cc: [email protected] > Subject: Re: Fragmentation-related security issues > > 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).
It is not a violation to send PTB of less then 1280. Never has been, even going back to RFC1883 when the IPv6 minimum MTU was 576, http://tools.ietf.org/html/rfc1883#section-5 says: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 576. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 576, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 528 octets (576 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. Note: Path MTU Discovery must be performed even in cases where a host "thinks" a destination is attached to the same link as itself. and the current IPv6 specification also allows PTB < 1280, http://tools.ietf.org/html/rfc2460#section-5 says: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. > 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). -d > Thanks, > -- > Fernando Gont > e-mail: [email protected] || [email protected] > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
