6rd Tunnel MTUBoeing Research & TechnologyP.O. Box 3707SeattleWA98124USAfltemplin@acm.orgI-DInternet-DraftThe 6rd tunnel MTU is currently recommended to be set to 1480. This
is to avoid IPv4 fragmentation within the tunnel, but requires the 6rd
tunnel ingress interface 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, so dropping packets is considered highly
undesirable. Fortunately, the "Internet cell size" is 1500 bytes, i.e.,
the minimum MTU configured by the vast majority of links in the
Internet. This document therefore presents a method to boost the 6rd MTU
to 1500 bytes.The 6rd tunnel MTU is currently recommended to be set to 1480 . This is to avoid IPv4 fragmentation within the
tunnel , but requires the 6rd tunnel
ingress interface 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, so dropping
packets is considered highly undesirable. Fortunately, the "Internet
cell size" is 1500 bytes, i.e., the minimum MTU configured by the vast
majority of links in the Internet, such that 1500 byte or smaller
packets are likely to be delivered without loss to MTU limitations in
the vast majority of cases. This document therefore presents a method to
boost the 6rd tunnel MTU to 1500 bytes.Pushing the 6rd tunnel MTU to 1500 bytes 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 1500 byte link, depending on the setting of the
"Don't Fragment" (DF) bit in the IPv4 header. Using the approach
outlined in this document, the 6rd tunnel avoids this issue by
performing IPv6 fragmentation on the inner IPv6 packet before IPv4
encapsulation. The approach is outlined in the following sections.Setting the 6rd MTU to 1500 bytes is accomplished via the following
algorithm:In the algorithm given in Section 2, the 6rd tunnel interface MTU for
6rd CPE routers and/or Border Routers (BRs) can be set to 1500 bytes
independently of other 6rd interfaces within the operator network, i.e.,
the approach is incrementally deployable.The algorithm in Section 2 further ignores the IPv6 requirement that
routers in the network must not fragment IPv6 packets, i.e.
fragmentation must be performed only by hosts. However, we observe that
the 6rd CPE is close enough to the IPv6 host such that its fragmentation
behavior is very close to that of a host. We further observe that the
6rd BR is tied through stateless address mapping to a single CPE that
provides access to the 6rd site such that there would not be multiple
paths into the site via different CPEs with widely varying delay
characteristics.The algorithm in Section 2 requires that 6rd ingress tunnel endpoint
perform IPv6 fragmentation (when necessary), but the 6rd egress tunnel
endpoint does not perform reassembly; hence, the 6rd tunnel endpoints
remain stateless. Instead, the final destination IPv6 host may be
obliged to reassemble IPv6 packets up to 1500 bytes in length, but hosts
are required to reassemble at least that much by the IPv6 standard .Since the 6rd tunnel endpoints set the Identification field in
fragmented IPv6 packets to a random 32-but value, there is no
possibility for "serialization" in which an IPv6 host might find the
number of distinct outstanding Identification values reduced due to the
6rd tunnel endpoint applying a single serial Identification value for
all IPv6 hosts. And, the use of a random 32-bit value would still allow
for far more than enough outstanding IPv6 packet reassemblies without
risk of colliding Identification values. This is especially true since
6rd sites do not connect to their ISPs via high data rate interfaces,
i.e., their interface data rates are normally O(10Mb/sec) and not
O(10Gbps).There are no IANA considerations for this document.The security considerations for 6rd apply also to this document.This method was inspired through discussion on the IETF v6ops list in
the May 2012 timeframe.