ISATAP Tunnel MTU
draft-bar-v6ops-ismtu-00.txt

Abstract

The ISATAP tunnel MTU is currently recommended to be set to 1480 or less. This is to avoid IPv4 fragmentation within the tunnel, but requires the ISATAP 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 ISATAP MTU to 1500 bytes.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 17, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Setting the ISATAP MTU to 1500 Bytes
• 3. Discussion
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgments
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

The ISATAP tunnel MTU is currently recommended to be set to 1480 [RFC5214]. This is to avoid IPv4 fragmentation within the tunnel [RFC0791], but requires the ISATAP tunnel ingress interface to drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet Too Big (PTB) message [RFC2460]. Concerns for operational issues with both IPv4 and IPv6 Path MTU Discovery [RFC1191][RFC1981] 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 ISATAP tunnel MTU to 1500 bytes.

Pushing the ISATAP 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 ISATAP tunnel avoids this issue by performing IPv6 fragmentation on the inner IPv6 packet before IPv4 encapsulation. The approach is outlined in the following sections.

2. Setting the ISATAP MTU to 1500 Bytes

Setting the ISATAP MTU to 1500 bytes is accomplished via the following algorithm:

   1. set the ISATAP tunnel interface MTU to 1500
   2. for IPv6 packets to be admitted into the ISATAP tunnel,
      do the following:

      a) drop the packet and send an ICMPv6 PTB if it is
         1501 or more
      b) encapsulate the packet in an IPv4 header and send
         it to the tunnel far end if it is 1280 or less
      c) if the packet is between 1281 - 1500:
         - break it into 2 equal-sized pieces and insert a
           fragment header on both pieces
         - choose a random 32-bit value and write the value
           in the Identification field in both pieces
         - encapsulate both pieces in an IPv4 header and
           send them to the tunnel far end
  3. the IPv6 destination host gets to reassemble if
         necessary

3. Discussion

In the algorithm given in Section 2, the ISATAP tunnel interface MTU for ISATAP hosts and/or routers can be set to 1500 bytes independently of other ISATAP interfaces within the site, 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 ISATAP host is allowed to perform IPv6 fragmentation. We further observe that the ISATAP router is tied through stateless address mapping to a single ISATAP host such that the fragments would not be delivered to multiple hosts.

The algorithm in Section 2 requires that ISATAP ingress tunnel endpoint perform IPv6 fragmentation (when necessary), but the ISATAP egress tunnel endpoint does not perform reassembly; hence, the ISATAP 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 [RFC2460].

Since the ISATAP 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 ISATAP 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.

4. IANA Considerations

There are no IANA considerations for this document.

5. Security Considerations

The security considerations for ISATAP apply also to this document.

6. Acknowledgments

This method was inspired through discussion on the IETF v6ops list in the May 2012 timeframe.

7. References

7.1. Normative References

7.2. Informative References

Author's Address