[dns-operations] v6, fragmentation, DNS

Joe Abley jabley at hopcount.ca
Sun May 23 14:47:06 UTC 2010


On 2010-05-22, at 22:10, bmanning at vacation.karoshi.com wrote:

> 	er... with VPNs in place, the effective MTU for IPv6 is 1220, not 1280.
> 	last I heard, both G and B run with that "fix" in play -- at least for 
> 	the moment.

I've heard you say this before Bill, but I still think the specification is pretty clear. Any link layer that can't carry 1280-byte IPv6 datagrams is supposed to do link-layer fragmentation and reassembly such that the *IPv6* interface really does have a 1280-byte MTU.

I realise that it's not exactly unusual for people to bend the spec and see what they can get away with. However, someone who chooses to build an IPv6 interface with an MTU lower than 1280 and notices that some things break really only has themselves to blame.


Joe

[from RFC 2460]

5. Packet Size Issues

   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.

   Links that have a configurable MTU (for example, PPP links [RFC-
   1661]) must be configured to have an MTU of at least 1280 octets; it
   is recommended that they be configured with an MTU of 1500 octets or
   greater, to accommodate possible encapsulations (i.e., tunneling)
   without incurring IPv6-layer fragmentation.

   From each link to which a node is directly attached, the node must be
   able to accept packets as large as that link's MTU.

   It is strongly recommended that IPv6 nodes implement Path MTU
   Discovery [RFC-1981], in order to discover and take advantage of path
   MTUs greater than 1280 octets.  However, a minimal IPv6
   implementation (e.g., in a boot ROM) may simply restrict itself to
   sending packets no larger than 1280 octets, and omit implementation
   of Path MTU Discovery.

   In order to send a packet larger than a path's MTU, a node may use
   the IPv6 Fragment header to fragment the packet at the source and
   have it reassembled at the destination(s).  However, the use of such
   fragmentation is discouraged in any application that is able to
   adjust its packets to fit the measured path MTU (i.e., down to 1280
   octets).

   A node must be able to accept a fragmented packet that, after
   reassembly, is as large as 1500 octets.  A node is permitted to
   accept fragmented packets that reassemble to more than 1500 octets.
   An upper-layer protocol or application that depends on IPv6
   fragmentation to send packets larger than the MTU of a path should
   not send packets larger than 1500 octets unless it has assurance that
   the destination is capable of reassembling packets of that larger
   size.

   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.





More information about the dns-operations mailing list