doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc4459.txt b/doc/rfc/rfc4459.txt
new file mode 100644
index 0000000..90d04f2
--- /dev/null
+++ b/doc/rfc/rfc4459.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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
+
+
+   particular, signalling may be a scalable option for the outer tunnel
+   or tunnels if the number of innermost tunnel endpoints is limited.
+
+   The tunneling packet size issues are relatively straightforward in
+   host-to-host tunneling or host-to-router tunneling where Path MTU
+   Discovery only needs to signal to one source node.  The issues are
+   significantly more difficult in router-to-router and certain
+   router-to-host scenarios, which are the focus of this memo.
+
+   It is worth noting that most of this discussion applies to a more
+   generic case, where there exists a link with a lower MTU in the path.
+   A concrete and widely deployed example of this is the usage of PPP
+   over Ethernet (PPPoE) [11] at the customers' access link.  These
+   lower-MTU links, and particularly PPPoE links, are typically not
+   deployed in topologies where fragmentation and reassembly might be
+   unfeasible (e.g., a backbone), so this may be a slightly easier
+   problem.  However, this more generic case is considered out of scope
+   of this memo.
+
+   There are also known challenges in specifying and implementing a
+   mechanism that would be used at the tunnel endpoint to obtain the
+   best suitable packet size to use for encapsulation: if a static value
+   is chosen, a lot of fragmentation might end up being performed.  On
+   the other hand, if PMTUD is used, the implementation would need to
+   update the discovered interface MTU based on the ICMP Packet Too Big
+   messages and originate ICMP Packet Too Big message(s) back to the
+   source(s) of the encapsulated packets; this also assumes that
+   sufficient data has been piggybacked on the ICMP messages (beyond the
+   required 64 bits after the IPv4 header).  We'll discuss using PMTUD
+   to signal the sources briefly in Section 3.2, but in-depth
+   specification and analysis are described elsewhere (e.g., in [4] and
+   [2]) and are out of scope of this memo.
+
+   Section 2 includes a problem statement, section 3 describes the
+   different solutions with their drawbacks and advantages, and section
+   4 presents conclusions.
+
+2.  Problem Statement
+
+   It is worth considering why exactly this is considered a problem.
+
+   It is possible to fix all the packet size issues using solution 1,
+   fragmenting the resulting encapsulated packet, and reassembling it by
+   the tunnel endpoint.  However, this is considered problematic for at
+   least three reasons, as described in Section 3.1.
+
+   Therefore, it is desirable to avoid fragmentation and reassembly if
+   possible.  On the other hand, the other solutions may not be
+
+
+
+Savola                       Informational                      [Page 3]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+   practical either: especially in router-to-router or router-to-host
+   tunneling, Path MTU Discovery might be very disadvantageous --
+   consider the case where a backbone router would send ICMP Packet Too
+   Big messages to every source that would try to send packets through
+   it.  Fragmenting before encapsulation is also not available in IPv6,
+   and not available when the Don't Fragment (DF) bit has been set (see
+   Section 3.4 for more).  Ensuring a high enough MTU so encapsulation
+   is always possible is of course a valid approach, but requires
+   careful operational planning, and may not be a feasible assumption
+   for implementors.
+
+   This yields that there is no trivial solution to this problem, and it
+   needs to be further explored to consider the trade offs, as is done
+   in this memo.
+
+3.  Description of Solutions
+
+   This section describes the potential solutions in a bit more detail.
+
+3.1.  Fragmentation and Reassembly by the Tunnel Endpoints
+
+   The seemingly simplest solution to tunneling packet size issues is
+   fragmentation of the outer packet by the encapsulator and reassembly
+   by the decapsulator.  However, this is highly problematic for at
+   least three reasons:
+
+   o  Fragmentation causes overhead: every fragment requires the IP
+      header (20 or 40 bytes), and with IPv6, an additional 8 bytes for
+      the Fragment Header.
+
+   o  Fragmentation and reassembly require computation: splitting
+      datagrams to fragments is a non-trivial procedure, and so is their
+      reassembly.  For example, software router forwarding
+      implementations may not be able to perform these operations at
+      line rate.
+
+   o  At the time of reassembly, all the information (i.e., all the
+      fragments) is normally not available; when the first fragment
+      arrives to be reassembled, a buffer of the maximum possible size
+      may have to be allocated because the total length of the
+      reassembled datagram is not known at that time.  Furthermore, as
+      fragments might get lost, or be reordered or delayed, the
+      reassembly engine has to wait with the partial packet for some
+      time (e.g., 60 seconds [9]).  When this would have to be done at
+      the line rate, with, for example 10 Gbit/s speed, the length of
+      the buffers that reassembly might require would be prohibitive.
+
+
+
+
+
+Savola                       Informational                      [Page 4]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+   When examining router-to-router tunneling, the third problem is
+   likely the worst; certainly, a hardware computation and
+   implementation requirement would also be significant, but not all
+   that difficult in the end -- and the link capacity wasted in the
+   backbones by additional overhead might not be a huge problem either.
+
+   However, IPv4 identification header length is only 16 bits (compared
+   to 32 bits in IPv6), and if a larger number of packets are being
+   tunneled between two IP addresses, the ID is very likely to wrap and
+   cause data misassociation.  This reassembly wrongly combining data
+   from two unrelated packets causes data integrity and potentially a
+   confidentiality violation.  This problem is further described in
+   [12].
+
+   IPv6, and IPv4 with the DF bit set in the encapsulating header,
+   allows the tunnel endpoints to optimize the tunnel MTU and minimize
+   network-based reassembly.  This also prevents fragmentation of the
+   encapsulated packets on the tunnel path.  If the IPv4 encapsulating
+   header does not have the DF bit set, the tunnel endpoints will have
+   to perform a significant amount of fragmentation and reassembly,
+   while the use of PMTUD is minimized.
+
+   As Appendix A describes, the MTU of the tunnel is also a factor on
+   which packets require fragmentation and reassembly; the worst case
+   occurs if the tunnel MTU is "infinite" or equal to the physical
+   interface MTUs.
+
+   So, if reassembly could be made to work sufficiently reliably, this
+   would be one acceptable fallback solution but only for IPv6.
+
+3.2.  Signalling the Lower MTU to the Sources
+
+   Another approach is to use techniques like Path MTU Discovery (or
+   potentially a future derivative [13]) to signal to the sources whose
+   packets will be encapsulated in the network to send smaller packets
+   so that they can be encapsulated; in particular, when done on
+   routers, this includes two separable functions:
+
+   a.  Forwarding behaviour: when forwarding packets, if the IPv4-only
+       DF bit is set, the router sends an ICMP Packet Too Big message to
+       the source if the MTU of the egress link is too small.
+
+   b.  Router's "host" behaviour: when the router receives an ICMP
+       Packet Too Big message related to a tunnel, it (1) adjusts the
+       tunnel MTU, and (2) originates an ICMP Packet Too Big message to
+       the source address of the encapsulated packet. (2) can be done
+       either immediately or by waiting for the next packet to trigger
+       an ICMP; the former minimizes the packet loss due to MTU changes.
+
+
+
+Savola                       Informational                      [Page 5]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+   Note that this only works if the MTU of the tunnel is of reasonable
+   size, and not, for example, 64 kilobytes: see Appendix A for more.
+
+   This approach would presuppose that PMTUD works.  While it is
+   currently working for IPv6, and critical for its operation, there is
+   ample evidence that in IPv4, PMTUD is far from reliable due to, for
+   example firewalls and other boxes being configured to inappropriately
+   drop all the ICMP packets [14], or software bugs rendering PMTUD
+   inoperational.
+
+   Furthermore, there are two scenarios where signalling from the
+   network would be highly undesirable.  The first is when the
+   encapsulation would be done in such a prominent place in the network
+   that a very large number of sources would need to be signalled with
+   this information (possibly even multiple times, depending on how long
+   they keep their PMTUD state).  The second is when the encapsulation
+   is done for passive monitoring purposes (network management, lawful
+   interception, etc.) -- when it's critical that the sources whose
+   traffic is being encapsulated are not aware of this happening.
+
+   When desiring to avoid fragmentation, IPv4 requires one of two
+   alternatives [1]: copy the DF bit from the inner packets to the
+   encapsulating header, or always set the DF bit of the outer header.
+   The latter is better, especially in controlled environments, because
+   it forces PMTUD to converge immediately.
+
+   A related technique, which works with TCP under specific scenarios
+   only, is so-called "MSS clamping".  With that technique or rather a
+   "hack", the TCP packets' Maximum Segment Size (MSS) is reduced by
+   tunnel endpoints so that the TCP connection automatically restricts
+   itself to the maximum available packet size.  Obviously, this does
+   not work for UDP or other protocols that have no MSS.  This approach
+   is most applicable and used with PPPoE, but could be applied
+   otherwise as well; the approach also assumes that all the traffic
+   goes through tunnel endpoints that do MSS clamping -- this is trivial
+   for the single-homed access links, but could be a challenge
+   otherwise.
+
+   A new approach to PMTUD is in the works [13], but it is uncertain
+   whether that would fix the problems -- at least not the passive
+   monitoring requirements.
+
+3.3.  Encapsulate Only When There is Free MTU
+
+   The third approach is an operational one, depending on the
+   environment where encapsulation and decapsulation are being
+   performed.  That is, if an ISP would deploy tunneling in its
+   backbone, which would consist only of links supporting high MTUs
+
+
+
+Savola                       Informational                      [Page 6]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+   (e.g., Gigabit Ethernet or SDH/SONET), but all its customers and
+   peers would have a lower MTU (e.g., 1500, or the backbone MTU minus
+   the encapsulation overhead), this would imply that no packets (with
+   the encapsulation overhead added) would have a larger MTU than the
+   "backbone MTU", and all the encapsulated packets would always fit
+   MTU-wise in the backbone links.
+
+   This approach is highly assumptive of the deployment scenario.  It
+   may be desirable to build a tunnel to/from another ISP, for example,
+   where this might no longer hold; or there might be links in the
+   network that cannot support the higher MTUs to satisfy the tunneling
+   requirements; or the tunnel might be set up directly between the
+   customer and the ISP, in which case fragmentation would occur, with
+   tunneled fragments terminating on the ISP and thus requiring
+   reassembly capability from the ISP's equipment.
+
+   To restate, this approach can only be considered when tunneling is
+   done inside a part of specific kind of ISP's own network, not, for
+   example, transiting an ISP.
+
+   Another, related approach might be having the sources use only a low
+   enough MTU that would fit in all the physical MTUs; for example, IPv6
+   specifies the minimum MTU of 1280 bytes.  For example, if all the
+   sources whose traffic would be encapsulated would use this as the
+   maximum packet size, there would probably always be enough free MTU
+   for encapsulation in the network.  However, this is not the case
+   today, and it would be completely unrealistic to assume that this
+   kind of approach could be made to work in general.
+
+   It is worth remembering that while the IPv6 minimum MTU is 1280 bytes
+   [10], there are scenarios where the tunnel implementation must
+   implement fragmentation and reassembly [3]: for example, when having
+   an IPv6-in-IPv6 tunnel on top of a physical interface with an MTU of
+   1280 bytes, or when having two layers of IPv6 tunneling.  This can
+   only be avoided by ensuring that links on top of which IPv6 is being
+   tunneled have a somewhat larger MTU (e.g., 40 bytes) than 1280 bytes.
+   This conclusion can be generalized: because IP can be tunneled on top
+   of IP, no single minimum or maximum MTU can be found such that
+   fragmentation or signalling to the sources would never be needed.
+
+   All in all, while in certain operational environments it might be
+   possible to avoid any problems by deployment choices, or limiting the
+   MTU that the sources use, this is probably not a sufficiently good
+   general solution for the equipment vendors.  Other solutions must
+   also be provided.
+
+
+
+
+
+
+Savola                       Informational                      [Page 7]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+3.4.  Fragmentation of the Inner Packet
+
+   A final possibility is fragmenting the inner packet, before
+   encapsulation, in such a manner that the encapsulated packet fits in
+   the tunnel's path MTU (discovered using PMTUD).  However, one should
+   note that only IPv4 supports this "in-flight" fragmentation;
+   furthermore, it isn't allowed for packets where the Don't Fragment
+   bit has been set.  Even if one could ignore IPv6 completely, so many
+   IPv4 host stacks send packets with the DF bit set that this would
+   seem unfeasible.
+
+   However, there are existing implementations that violate the standard
+   that:
+
+   o  discard too big packets with the DF bit not set instead of
+      fragmenting them (this is rare);
+
+   o  ignore the DF bit completely, for all or specified interfaces; or
+
+   o  clear the DF bit before encapsulation, in the egress of configured
+      interfaces.  This is typically done for all the traffic, not just
+      too big packets (allowing configuring this is common).
+
+   This is non-compliant behaviour, but there are certainly uses for it,
+   especially in certain tightly controlled passive monitoring
+   scenarios, and it has potential for more generic applicability as
+   well, to work around PMTUD issues.
+
+   Clearing the DF bit effectively disables the sender's PMTUD for the
+   path beyond the tunnel.  This may result in fragmentation later in
+   the network, but as the packets have already been fragmented prior to
+   encapsulation, this fragmentation later on does not make matters
+   significantly worse.
+
+   As this is an implemented and desired (by some) behaviour, the full
+   impacts e.g., for the functioning of PMTUD (for example) should be
+   analyzed, and the use of fragmentation-related IPv4 bits should be
+   re-evaluated.
+
+   In summary, this approach provides a relatively easy fix for IPv4
+   problems, with potential for causing problems for PMTUD; as this
+   would not work with IPv6, it could not be considered a generic
+   solution.
+
+
+
+
+
+
+
+
+Savola                       Informational                      [Page 8]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+4.  Conclusions
+
+   Fragmentation and reassembly by the tunnel endpoints are a clear and
+   simple solution to the problem, but the hardware reassembly when the
+   packets get lost may face significant implementation challenges that
+   may be insurmountable.  This approach does not seem feasible,
+   especially for IPv4 with high data rates due to problems with
+   wrapping the fragment identification field [12].  Constant wrapping
+   may occur when the data rate is in the order of MB/s for IPv4 and in
+   the order of dozens of GB/s for IPv6.  However, this reassembly
+   approach is probably not a problem for passive monitoring
+   applications.
+
+   PMTUD techniques, at least at the moment and especially for IPv4,
+   appear to be too unreliable or unscalable to be used in the
+   backbones.  It is an open question whether a future solution might
+   work better in this aspect.
+
+   It is clear that in some environments the operational approach to the
+   problem, ensuring that fragmentation is never necessary by keeping
+   higher MTUs in the networks where encapsulated packets traverse, is
+   sufficient.  But this is unlikely to be enough in general, and for
+   vendors that may not be able to make assumptions about the operators'
+   deployments.
+
+   Fragmentation of the inner packet is only possible with IPv4, and is
+   sufficient only if standards-incompliant behaviour, with potential
+   for bad side-effects (e.g., for PMTUD), is adopted.  It should not be
+   used if there are alternatives; fragmentation of the outer packet
+   seems a better option for passive monitoring.
+
+   However, if reassembly in the network must be avoided, there are
+   basically two possibilities:
+
+   1.  For IPv6, use ICMP signalling or operational methods.
+
+   2.  For IPv4, packets for which the DF bit is not set can be
+       fragmented before encapsulation (and the encapsulating header
+       would have the DF bit set); packets whose DF bit is set would
+       need to get the DF bit cleared (though this is non-compliant).
+       This also minimizes the need for (unreliable) Internet-wide
+       PMTUD.
+
+   An interesting thing to explicitly note is that when tunneling is
+   done in a high-speed backbone, typically one may be able to make
+   assumptions on the environment; however, when reassembly is not
+   performed in such a network, it might be done in software or with
+   lower requirements, and there exists either a reassembly
+
+
+
+Savola                       Informational                      [Page 9]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+   implementation using PMTUD or using a separate approach for passive
+   monitoring -- so this might not be a real problem.
+
+   In consequence, the critical questions at this point appear to be 1)
+   whether a higher MTU can be assumed in the high-speed networks that
+   deploy tunneling, and 2) whether "slower-speed" networks could cope
+   with a software-based reassembly, a less capable hardware-based
+   reassembly, or the other workarounds.  An important future task would
+   be analyzing the observed incompliant behaviour about the DF bit to
+   note whether it has any unanticipated drawbacks.
+
+5.  Security Considerations
+
+   This document describes different issues with packet sizes and in-
+   the-network tunneling; this does not have security considerations on
+   its own.
+
+   However, different solutions might have characteristics that may make
+   them more susceptible to attacks -- for example, a router-based
+   fragment reassembly could easily lead to (reassembly) buffer memory
+   exhaustion if the attacker sends a sufficient number of fragments
+   without sending all of them, so that the reassembly would be stalled
+   until a timeout; these and other fragment attacks (e.g., [15]) have
+   already been used against, for example, firewalls and host stacks,
+   and need to be taken into consideration in the implementations.
+
+   It is worth considering the cryptographic expense (which is typically
+   more significant than the reassembly, if done in software) with
+   fragmentation of the inner or outer packet.  If an outer fragment
+   goes missing, no cryptographic operations have been yet performed; if
+   an inner fragment goes missing, cryptographic operations have already
+   been performed.  Therefore, which of these approaches is preferable
+   also depends on whether cryptography or reassembly is already
+   provided in hardware; for high-speed routers, at least, one should be
+   able to assume that if it is performing relatively heavy
+   cryptography, hardware support is already required.
+
+   The solutions using PMTUD (and consequently ICMP) will also need to
+   take into account the attacks using ICMP.  In particular, an attacker
+   could send ICMP Packet Too Big messages indicating a very low MTU to
+   reduce the throughput and/or as a fragmentation/reassembly
+   denial-of-service attack.  This attack has been described in the
+   context of TCP in [16].
+
+
+
+
+
+
+
+
+Savola                       Informational                     [Page 10]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+6.  Acknowledgements
+
+   While the topic is far from new, recent discussions with W. Mark
+   Townsley on L2TP fragmentation issues caused the author to sit down
+   and write up the issues in general.  Michael Richardson and Mika
+   Joutsenvirta provided useful feedback on the first version.  When
+   soliciting comments from the NANOG list, Carsten Bormann, Kevin
+   Miller, Warren Kumari, Iljitsch van Beijnum, Alok Dube, and Stephen
+   J. Wilcox provided useful feedback.  Later, Carlos Pignataro provided
+   excellent input, helping to improve the document.  Joe Touch also
+   provided input on the memo.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]   Perkins, C., "IP Encapsulation within IP", RFC 2003, October
+         1996.
+
+   [2]   Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
+         IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [3]   Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
+         Specification", RFC 2473, December 1998.
+
+   [4]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
+         "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
+
+   [5]   Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
+         Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
+
+   [6]   Kent, S. and K. Seo, "Security Architecture for the Internet
+         Protocol", RFC 4301, December 2005.
+
+   [7]   Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+         November 1990.
+
+   [8]   McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for
+         IP version 6", RFC 1981, August 1996.
+
+   [9]   Braden, R., "Requirements for Internet Hosts - Communication
+         Layers", STD 3, RFC 1122, October 1989.
+
+   [10]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+         Specification", RFC 2460, December 1998.
+
+
+
+
+
+
+Savola                       Informational                     [Page 11]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+7.2.  Informative References
+
+   [11]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and
+         R. Wheeler, "A Method for Transmitting PPP Over Ethernet
+         (PPPoE)", RFC 2516, February 1999.
+
+   [12]  Mathis, M., "Fragmentation Considered Very Harmful", Work in
+         Progress, July 2004.
+
+   [13]  Mathis, M. and J. Heffner, "Path MTU Discovery", Work in
+         Progress, March 2006.
+
+   [14]  Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution
+         of Transport Protocols in the Internet", Computer
+         Communications Review, Apr 2005, <http://www.icir.org/tbit/>.
+
+   [15]  Miller, I., "Protection Against a Variant of the Tiny Fragment
+         Attack (RFC 1858)", RFC 3128, June 2001.
+
+   [16]  Gont, F., "ICMP attacks against TCP", Work in Progress,
+         February 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola                       Informational                     [Page 12]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+Appendix A.  MTU of the Tunnel
+
+   Different tunneling mechanisms may treat the tunnel links as having
+   different kinds of MTU values.  Some might use the same default MTU
+   as for other interfaces; some others might use the default MTU minus
+   the expected IP overhead (e.g., 20, 28, or 40 bytes); some others
+   might even treat the tunnel as having an "infinite MTU", e.g., 64
+   kilobytes.
+
+   As [2] describes, having an infinite MTU, i.e., always fragmenting
+   the outer packet (and never the inner packet) and never performing
+   PMTUD for the tunnel path, is a very bad idea, especially in
+   host-to-router scenarios.  (It could be argued that if the nodes are
+   sure that this is a host-to-host tunnel, a larger MTU might make
+   sense if fragmentation and reassembly are more efficient than just
+   sending properly sized packets -- but this seems like a stretch.)
+
+Author's Address
+
+   Pekka Savola
+   CSC/FUNET
+   Espoo
+   Finland
+
+   EMail: psavola@funet.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola                       Informational                     [Page 13]
+
+RFC 4459         Packet Size Issues in Network Tunnels        April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Savola                       Informational                     [Page 14]
+