[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Path MTU discovery - Matt Mathis



this was never published as rja wanted to add 100kg of fluff and
confusion.

randy

---






INTERNET-DRAFT                                     Tony Li, Procket
draft-ymbk-mtu-00.txt                              Ran Atkinson, Extreme
2001.12.23                                         Randy Bush, AT&T


              Recommendations for MTU when Beyond Ethernet


    Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

0. Abstract

   While the Ethernet standard [ETHERNET] is limited to MTUs in the
   range of 48 to 1500 bytes of payload, it is often advantageous to
   configure the MTU to suit the internet WAN or LAN environment.  This
   document suggests the most common ways this is done.

1. Fragmentation Considered Harmful

   When a packet is larger than the Maximum Transmission Unit (MTU) of
   the interface to which is is being forwarded, the packet is
   'fragmented' into two or more packets [RFC791].  Fragmentation is a
   work-around, not a feature, and is undesirable [KENTMOGUL].  Path MTU
   discovery [RFC1191] dynamically measures the MTU on an end-to-end
   path so that the sender can adjust the originating MTU, but it is far
   from a panacea [RFC2923].

   Therefore, to minimize fragmentation on Ethernet-like links, we
   recommend configuring them to the MTU of their larger neighbors.



Li, Atkinson, & Bush       Expires 2002.06.23                   [Page 1]

INTERNET-DRAFT      Recommended MTUs Beyond Ethernet          2001.12.23


2. Wide Area Network (WAN)

   Most IP backbones are running at rates of DS3 and above.  These WAN
   links have a default MTU of 4470 bytes, aka '4k'.  Hence, to prevent
   backbone packet fragmentation, it is recommended that operators
   configure inter-router Ethernet-like links and switches to an MTU of
   4470 bytes.

3. Local Area Network (LAN)

   LANs with high-performance servers are often configured so that
   Ethernet-like links and switches between the servers can accommodate
   the common transfers of the servers, often 8192 bytes of data, with
   an MTU of 9180, aka '9k'.

4. Mixed Environment

   If a server farm LAN (2) is connected to a WAN (1), traffic from the
   LAN to the WAN will be fragmented to match the WAN MTU.  Hence it is
   more sensible to run the LAN with the WAN's 4k MTU.

5. Warnings

   The Ethernet CRC was designed for the Ethernet MTU range, and
   provides weaker checking when MTUs are configured larger than that
   range.  IP packet fragmentation increases vulnerability and makes
   filtering more complex [RFC1858].

   It is often very hard to debug when all ends of an Ethernet-like link
   are not properly configured to the same MTU.

6. Security Considerations

   Non-standard MTUs are not known to open new security issues.
   Fragmentation is known to complicate security tools [RFC1858]
   [RFC3128].

7. Acknowledgments

   I dunno

8. References

[KENTMOGUL]
     Kent, C. and J. Mogul, "Fragmentation Considered Harmful", Proc.
     ACM SIGCOMM 1987, August 1987.





Li, Atkinson, & Bush       Expires 2002.06.23                   [Page 2]

INTERNET-DRAFT      Recommended MTUs Beyond Ethernet          2001.12.23


[ETHERNET]
     IEEE Std. 802.3 [2000 Edition], ISO/IEC 8802-3:2000.

[RFC791]
     Postel, J., Editor, "Internet Protocol - DARPA Internet Program
     Protocol Specification", STD 5, RFC 791, September 1981.

[RFC1191]
     J.C. Mogul, S.E. Deering,"Path MTU discovery", RFC 1191, November
     1990.

[RFC1858]
     G. Ziemba, D.  Reed, P. Traina, "Security Considerations for IP
     Fragment Filtering", RFC 1858, October 1995.

[RFC2923]
     K. Lahey, "TCP Problems with Path MTU Discovery", RFC 2923, Septem-
     ber 2000.

[RFC3128]
     I. Miller, "Protection Against a Variant of the Tiny Fragment
     Attack (RFC 1858)", RFC 3128, June 2001.

9. Authors' Addresses

   Tony Li
   1100 Cadillac Ct.
   Milpitas, CA 95035
   tony.li@tony.li

   Ran Atkinson
   ADDRESS INFO PLEASE

   Randy Bush
   5147 Crystal Springs
   Bainbridge Island, WA US-98110
   +1 206 780 0431
   randy@psg.com













Li, Atkinson, & Bush       Expires 2002.06.23                   [Page 3]

INTERNET-DRAFT      Recommended MTUs Beyond Ethernet          2001.12.23


10. Full Copyright Statement

    Copyright (C) The Internet Society (2001).  All Rights Reserved.

    This document and translations of it may be copied and furnished to others,
    and derivative works that comment on or otherwise explain it or assist in
    its implementation may be prepared, copied, published and distributed, in
    whole or in part, without restriction of any kind, provided that the above
    copyright notice and this paragraph are included on all such copies and
    derivative works.  However, this document itself may not be modified in any
    way, such as by removing the copyright notice or references to the Internet
    Society or other Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for copyrights
    defined in the Internet Standards process must be followed, or as required
    to translate it into languages other than English.

    The limited permissions granted above are perpetual and will not be revoked
    by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an "AS IS"
    basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
    DISCLAIMS 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.


























Li, Atkinson, & Bush       Expires 2002.06.23                   [Page 4]