6rd Tunnel MTUBoeing Research & TechnologyP.O. Box 3707SeattleWA98124USAfltemplin@acm.orgI-DInternet-DraftThe tunnel MTU on 6rd Provider Edge (PE) and Consumer Edge (CE)
routers is currently recommended to be set to 1480. This is to avoid
IPv4 fragmentation within the tunnel, but requires the tunnel ingress to
drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet
Too Big (PTB) message. Concerns for operational issues with both IPv4
and IPv6 Path MTU Discovery point to the possibility of MTU-related
black holes when a packet is dropped due to an MTU restriction somewhere
in the Internet. Fortunately, the "Internet cell size" is 1500 bytes
(i.e., the minimum MTU configured by the vast majority of links in the
Internet) so if the 6rd PE router can set a tunnel MTU of at least 1500
bytes the MTU issues are alleviated. This document specifies methods
that can be employed to support these larger sizes.The tunnel MTU on 6rd Provider Edge (PE) and Consumer Edge (CE)
routers is currently recommended to be set to 1500 bytes minus the IPv4
header encapsulation overhead minus the encapsulation overhead for any
additional encapsulations that may occur on the path . This is to avoid IPv4 fragmentation within the
tunnel , but requires the tunnel ingress to drop
any IPv6 packet larger than the tunnel MTU and return an ICMPv6 Packet
Too Big (PTB) message . Concerns for operational
issues with both IPv4 and IPv6 Path MTU Discovery point to the possibility of
MTU-related black holes when a packet is dropped due to an MTU
restriction somewhere in the Internet. Fortunately, the "Internet cell
size" is 1500 bytes (i.e., the minimum MTU configured by the vast
majority of links in the Internet) so if the 6rd PE router can set a
tunnel MTU of at least 1500 bytes the MTU issues are alleviated. This
document specifies methods that can be employed to support these larger
sizes.Pushing the 6rd tunnel MTU to 1500 bytes or larger is met with the
challenge that the addition of the IPv4 encapsulation header would cause
a 1500 byte IPv6 packet to appear as a 1520 byte IPv4 packet on the
wire. This can result in the packet being either fragmented or dropped
by an IPv4 router that configures a smaller link MTU, depending on the
setting of the "Don't Fragment" (DF) bit in the IPv4 header. Therefore,
this document recommends complementary mechanisms to ensure that packets
of various sizes can be delivered as long as the underlying IPv4 network
can support the larger sizes. The following two sections present the
methods used by 6rd PE and CE routers.The 6rd PE Router employs the following MTU-handling mitigations:The 6rd CE Router employs the following MTU-handling techhniques:There are several interrelated aspects to the recommended MTU
mitigations. First, the unconditional rewriting of the MSS by CE routers
ensures that the initial packets sent by IPv6 correspondents will be no
larger than the minimum tunnel path MTU following encapsulation. The
IPv6 correspondents can thereafter use [RFC4821] to attempt to increase
the MSS during the course of the TCP session and thereby take advantage
of larger packet sizes when avaialble.However, not all transport protocols observe the TCP MSS and so the
packets of other protocols generated by IPv6 hosts may be larger than
would fit in the minimum tunnel path MTU. Since most IPv6 hosts expect
to see a minimum MTU of 1500 bytes without any ancillary MTU assurance
mitigations, the approach specified here takes special care of packets
larger than the minimum tunnel path MTU but no larger than 1500 bytes.
Namely, these packets are allowed to undergo IPv4 fragmentation on the
path from the PE to a CE or on the path from a CE to another CE. Since
sustained fragmentation at high data rates is dangerous however packets in this size range must only be admitted into
the tunnel subject to rate limiting so that reassembly misassociations
do not occur. Meanwhile, packets larger than 1500 bytes are admitted
into the tunnel unconditionally on a "best effort" basis with the
understanding that these packets may be dropped silently.Using these methods, CE routers may need to perform a small amount of
IPv4 reassembly. PE routers on the other hand will never be asked to
perform reassembly.There are no IANA considerations for this document.The security considerations for 6rd apply also to this document.This method was inspired through many years of discussion on IETF
lists and other forums on the topic of tunnel MTU.