MTU and Fragmentation Issues with In-the-Network Tunneling
RFC 4459

 
Document Type RFC - Informational (April 2006; No errata)
Was draft-savola-mtufrag-network-tunneling (individual in int area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4459 (Informational)
Telechat date
Responsible AD Mark Townsley
Send notices to psavola@funet.fi
Network Working Group                                          P. Savola
Request for Comments: 4459                                     CSC/FUNET
Category: Informational                                       April 2006

       MTU and Fragmentation Issues with In-the-Network Tunneling

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Tunneling techniques such as IP-in-IP when deployed in the middle of
   the network, typically between routers, have certain issues regarding
   how large packets can be handled: whether such packets would be
   fragmented and reassembled (and how), whether Path MTU Discovery
   would be used, or how this scenario could be operationally avoided.
   This memo justifies why this is a common, non-trivial problem, and
   goes on to describe the different solutions and their characteristics
   at some length.

Table of Contents

   1. Introduction ....................................................2
   2. Problem Statement ...............................................3
   3. Description of Solutions ........................................4
      3.1. Fragmentation and Reassembly by the Tunnel Endpoints .......4
      3.2. Signalling the Lower MTU to the Sources ....................5
      3.3. Encapsulate Only When There is Free MTU ....................6
      3.4. Fragmentation of the Inner Packet ..........................8
   4. Conclusions .....................................................9
   5. Security Considerations ........................................10
   6. Acknowledgements ...............................................11
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................12

Savola                       Informational                      [Page 1]
RFC 4459         Packet Size Issues in Network Tunnels        April 2006

1.  Introduction

   A large number of ways to encapsulate datagrams in other packets,
   i.e., tunneling mechanisms, have been specified over the years: for
   example, IP-in-IP (e.g., [1] [2], [3]), Generic Routing Encapsulation
   (GRE) [4], Layer 2 Tunneling Protocol (L2TP) [5], or IP Security
   (IPsec) [6] in tunnel mode -- any of which might run on top of IPv4,
   IPv6, or some other protocol and carrying the same or a different
   protocol.

   All of these can be run so that the endpoints of the inner protocol
   are co-located with the endpoints of the outer protocol; in a typical
   scenario, this would correspond to "host-to-host" tunneling.  It is
   also possible to have one set of endpoints co-located, i.e.,
   host-to-router or router-to-host tunneling.  Finally, many of these
   mechanisms are also employed between the routers for all or a part of
   the traffic that passes between them, resulting in router-to-router
   tunneling.

   All these protocols and scenarios have one issue in common: how does
   the source select the maximum packet size so that the packets will
   fit, even encapsulated, in the smallest Maximum Transmission Unit
   (MTU) of the traversed path in the network; and if you cannot affect
   the packet sizes, what do you do to be able to encapsulate them in
   any case?  The four main solutions are as follows (these will be
   elaborated in Section 3):

   1.  Fragmenting all too big encapsulated packets to fit in the paths,
       and reassembling them at the tunnel endpoints.

   2.  Signal to all the sources whose traffic must be encapsulated, and
       is larger than fits, to send smaller packets, e.g., using Path
       MTU Discovery (PMTUD)[7][8].

   3.  Ensure that in the specific environment, the encapsulated packets
       will fit in all the paths in the network, e.g., by using MTU
       bigger than 1500 in the backbone used for encapsulation.

   4.  Fragmenting the original too big packets so that their fragments
       will fit, even encapsulated, in the paths, and reassembling them
       at the destination nodes.  Note that this approach is only
       available for IPv4 under certain assumptions (see Section 3.4).

   It is also common to run multiple layers of encapsulation, for
   example, GRE or L2TP over IPsec; with nested tunnels in the network,
   the tunnel endpoints can be the same or different, and both the inner
   and outer tunnels may have different MTU handling strategies.  In

Savola                       Informational                      [Page 2]
RFC 4459         Packet Size Issues in Network Tunnels        April 2006
Show full document text