Hi Brian, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Saturday, December 24, 2011 12:07 PM > To: Fernando Gont > Cc: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > On 2011-12-24 18:34, Fernando Gont wrote: > > Hi, Florian, > > > > On 12/23/2011 07:46 AM, Florian Weimer 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.
Some tunnels may not be able to provide a 1280 MTU as-seen by the inner packet, since the outer encapsulating headers may cause the packet to exceed the path MTU. Especially for nested encapsulations, a tunnel ingress may be required to use IPv6 fragmentation in order to convey 1280 and smaller packets to the tunnel egress. This is effectively a "link- specific fragmentation and reassembly ... at a layer below IPv6." IPv6 tunnel fragmentation and reassembly is explained in RFC2473, and also in draft-templin-intarea-seal: http://tools.ietf.org/html/draft-templin-intarea-seal-42 SEAL in particular solves the tunnel path MTU problem for both IPv4 and IPv6 as the outer encapsulation layer. > IPv6 requires that every link in the internet have an MTU of 1280 > octets or greater. On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and > reassembly must > be provided at a layer below IPv6. [RFC 2460, sectioin 5]. You stopped short quoting the final paragraph of Section 5: "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." Thanks - Fred fred.l.temp...@boeing.com > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
