home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1800s / rfc1853.txt < prev    next >
Text File  |  1995-10-02  |  15KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Simpson
  8. Request for Comments: 1853                                    Daydreamer
  9. Category: Informational                                     October 1995
  10.  
  11.  
  12.                            IP in IP Tunneling
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21.  
  22. IESG Note:
  23.  
  24.    Note that this memo is an individual effort of the author.  This
  25.    document reflects a current informal practice in the internet.  There
  26.    is an effort underway within the IETF Mobile-IP Working Group to
  27.    provide an appropriate proposed standard to address this issue.
  28.  
  29.  
  30. Abstract
  31.  
  32.    This document discusses implementation techniques for using IP
  33.    Protocol/Payload number 4 Encapsulation for tunneling with IP
  34.    Security and other protocols.
  35.  
  36.  
  37. Table of Contents
  38.  
  39.      1.     Introduction ..........................................    2
  40.  
  41.      2.     Encapsulation .........................................    3
  42.  
  43.      3.     Tunnel Management .....................................    5
  44.         3.1       Tunnel MTU Discovery ............................    5
  45.         3.2       Congestion ......................................    6
  46.         3.3       Routing Failures ................................    6
  47.         3.4       Other ICMP Messages .............................    6
  48.  
  49.      SECURITY CONSIDERATIONS ......................................    7
  50.      REFERENCES ...................................................    7
  51.      ACKNOWLEDGEMENTS .............................................    8
  52.      AUTHOR'S ADDRESS .............................................    8
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                      Informational                      [Page 1]
  59.  
  60. RFC 1853                     IP Tunnelling                  October 1995
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    The IP in IP encapsulation Protocol/Payload number 4 [RFC-1700] has
  66.    long been used to bridge portions of the Internet which have disjoint
  67.    capabilities or policies.  This document describes implementation
  68.    techniques used for many years by the Amateur Packet Radio network
  69.    for joining a large mobile network, and also by early implementations
  70.    of IP Security protocols.
  71.  
  72.    Use of IP in IP encapsulation differs from later tunneling techniques
  73.    (for example, protocol numbers 98 [RFC-1241], 94 [IDM91a], 53
  74.    [swIPe], and 47 [RFC-1701]) in that it does not insert its own
  75.    special glue header between IP headers.  Instead, the original
  76.    unadorned IP Header is retained, and simply wrapped in another
  77.    standard IP header.
  78.  
  79.    This information applies principally to encapsulation of IP version
  80.    4.  Other IP versions will be described in separate documents.
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Simpson                      Informational                      [Page 2]
  115.  
  116. RFC 1853                     IP Tunnelling                  October 1995
  117.  
  118.  
  119. 2.  Encapsulation
  120.  
  121.    The encapsulation technique is fairly simple.  An outer IP header is
  122.    added before the original IP header.  Between them are any other
  123.    headers for the path, such as security headers specific to the tunnel
  124.    configuration.
  125.  
  126.    The outer IP header Source and Destination identify the "endpoints"
  127.    of the tunnel.  The inner IP header Source and Destination identify
  128.    the original sender and recipient of the datagram.
  129.  
  130.    Each header chains to the next using IP Protocol values [RFC-1700].
  131.  
  132.                                           +---------------------------+
  133.                                           |      Outer IP Header      |
  134.                                           +---------------------------+
  135.                                           |      Tunnel Headers       |
  136.       +---------------------------+       +---------------------------+
  137.       |         IP Header         |       |      Inner IP Header      |
  138.       +---------------------------+ ====> +---------------------------+
  139.       |                           |       |                           |
  140.       |         IP Payload        |       |         IP Payload        |
  141.       |                           |       |                           |
  142.       +---------------------------+       +---------------------------+
  143.  
  144.    The format of IP headers is described in [RFC-791].
  145.  
  146.    Type Of Service  copied from the inner IP header.  Optionally,
  147.                     another TOS may be used between cooperating peers.
  148.  
  149.                     This is in keeping with the transparency principle
  150.                     that if the user was expecting a given level of
  151.                     service, then the tunnel should provide the same
  152.                     service.  However, some tunnels may be constructed
  153.                     specifically to provide a different level of service
  154.                     as a matter of policy.
  155.  
  156.    Identification   A new number is generated for each outer IP header.
  157.  
  158.                     The encapsulated datagram may have already been
  159.                     fragmented, and another level of fragmentation may
  160.                     occur due to the tunnel encapsulation.  These tunnel
  161.                     fragments will be reassembled by the decapsulator,
  162.                     rather than the final destination.
  163.  
  164.    Reserved
  165.                     ignored (set to zero).
  166.  
  167.  
  168.  
  169.  
  170. Simpson                      Informational                      [Page 3]
  171.  
  172. RFC 1853                     IP Tunnelling                  October 1995
  173.  
  174.  
  175.                     This unofficial flag has seen experimental use, and
  176.                     while it remains in the inner IP header, does not
  177.                     affect the tunnel.
  178.  
  179.    Don't Fragment   copied from the inner IP header.  This allows the
  180.                     originator to control the level of performance
  181.                     tradeoffs.  See "Tunnel MTU Discovery".
  182.  
  183.    More Fragments   set as required when fragmenting.
  184.  
  185.                     The flag is not copied for the same reason that a
  186.                     separate Identification is used.
  187.  
  188.    Time To Live     the default value specified in the most recent
  189.                     "Assigned Numbers" [RFC-1700].  This ensures that
  190.                     long unanticipated tunnels do not interrupt the flow
  191.                     of datagrams between endpoints.
  192.  
  193.                     The inner TTL is decremented once before
  194.                     encapsulation, and is not affected by decapsulation.
  195.  
  196.    Protocol         the next header; 4 for the inner IP header, when no
  197.                     intervening tunnel headers are in use.
  198.  
  199.    Source           an IP address associated with the interface used to
  200.                     send the datagram.
  201.  
  202.    Destination      an IP address of the tunnel decapsulator.
  203.  
  204.    Options          not copied from the inner IP header.  However, new
  205.                     options particular to the path MAY be added.
  206.  
  207.                     Timestamp, Loose Source Route, Strict Source Route,
  208.                     and Record Route are deliberately hidden within the
  209.                     tunnel.  Often, tunnels are constructed to overcome
  210.                     the inadequacies of these options.
  211.  
  212.                     Any supported flavors of security options of the
  213.                     inner IP header MAY affect the choice of security
  214.                     options for the tunnel.  It is not expected that
  215.                     there be a one-to-one mapping of such options to the
  216.                     options or security headers selected for the tunnel.
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Simpson                      Informational                      [Page 4]
  227.  
  228. RFC 1853                     IP Tunnelling                  October 1995
  229.  
  230.  
  231. 3.  Tunnel Management
  232.  
  233.    It is possible that one of the routers along the tunnel interior
  234.    might encounter an error while processing the datagram, causing it to
  235.    return an ICMP [RFC-792] error message to the encapsulator at the IP
  236.    Source of the tunnel.  Unfortunately, ICMP only requires IP routers
  237.    to return 8 bytes (64 bits) of the datagram beyond the IP header.
  238.    This is not enough to include the entire encapsulated header.  Thus,
  239.    it is not generally possible for an encapsulating router to
  240.    immediately reflect an ICMP message from the interior of a tunnel
  241.    back to the originating host.
  242.  
  243.    However, by carefully maintaining "soft state" about its tunnels, the
  244.    encapsulator can return accurate ICMP messages in most cases.  The
  245.    router SHOULD maintain at least the following soft state information
  246.    about each tunnel:
  247.  
  248.     - Reachability of the end of the tunnel.
  249.     - Congestion of the tunnel.
  250.     - MTU of the tunnel.
  251.  
  252.    The router uses the ICMP messages it receives from the interior of a
  253.    tunnel to update the soft state information for that tunnel.  When
  254.    subsequent datagrams arrive that would transit the tunnel, the router
  255.    checks the soft state for the tunnel.  If the datagram would violate
  256.    the state of the tunnel (such as the MTU is greater than the tunnel
  257.    MTU when Don't Fragment is set), the router sends an appropriate ICMP
  258.    error message back to the originator, but also forwards the datagram
  259.    into the tunnel.  Forwarding the datagram despite returning the error
  260.    message ensures that changes in tunnel state will be learned.
  261.  
  262.    Using this technique, the ICMP error messages from encapsulating
  263.    routers will not always match one-to-one with errors encountered
  264.    within the tunnel, but they will accurately reflect the state of the
  265.    network.
  266.  
  267.  
  268. 3.1.  Tunnel MTU Discovery
  269.  
  270.    When the Don't Fragment bit is set by the originator and copied into
  271.    the outer IP header, the proper MTU of the tunnel will be learned
  272.    from ICMP (Type 3 Code 4) "Datagram Too Big" errors reported to the
  273.    encapsulator.  To support originating hosts which use this
  274.    capability, all implementations MUST support Path MTU Discovery
  275.    [RFC-1191, RFC-1435] within their tunnels.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Simpson                      Informational                      [Page 5]
  283.  
  284. RFC 1853                     IP Tunnelling                  October 1995
  285.  
  286.  
  287.    As a benefit of Tunnel MTU Discovery, any fragmentation which occurs
  288.    because of the size of the encapsulation header is done only once
  289.    after encapsulation.  This prevents more than one fragmentation of a
  290.    single datagram, which improves processing efficiency of the path
  291.    routers and tunnel decapsulator.
  292.  
  293.  
  294. 3.2.  Congestion
  295.  
  296.    Tunnel soft state will collect indications of congestion, such as an
  297.    ICMP (Type 4) Source Quench in datagrams from the decapsulator
  298.    (tunnel peer).  When forwarding another datagram into the tunnel,
  299.    it is appropriate to send Source Quench messages to the originator.
  300.  
  301.  
  302. 3.3.  Routing Failures
  303.  
  304.    Because the TTL is reset each time that a datagram is encapsulated,
  305.    routing loops within a tunnel are particularly dangerous when they
  306.    arrive again at the encapsulator.  If the IP Source matches any of
  307.    its interfaces, an implementation MUST NOT further encapsulate.
  308.    Instead, the datagram is forwarded normally.
  309.  
  310.    ICMP (Type 11) Time Exceeded messages report routing loops within the
  311.    tunnel itself.  ICMP (Type 3) Destination Unreachable messages report
  312.    delivery failures to the decapsulator.  This soft state MUST be
  313.    reported to the originator as (Type 3 Code 0) Network Unreachable.
  314.  
  315.  
  316. 3.4.  Other ICMP Messages
  317.  
  318.    Most ICMP error messages are not relevant to the use of the tunnel.
  319.    In particular, parameter problems are likely to be a result of
  320.    misconfiguration of the encapsulator, and MUST NOT be reported to the
  321.    originator.
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Simpson                      Informational                      [Page 6]
  339.  
  340. RFC 1853                     IP Tunnelling                  October 1995
  341.  
  342.  
  343. Security Considerations
  344.  
  345.    Security issues are briefly discussed in this memo.  The use of
  346.    tunneling may obviate some older IP security options (labelling), but
  347.    will better support newer IP Security headers.
  348.  
  349.  
  350. References
  351.  
  352.    [IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based
  353.             protocols for mobile internetworking", Proceedings of
  354.             SIGCOMM '91, ACM, September 1991.
  355.  
  356.    [RFC-791]
  357.             Postel, J., "Internet Protocol", STD 5, RFC 791,
  358.             USC/Information Sciences Institute, September 1981.
  359.  
  360.    [RFC-792]
  361.             Postel, J., "Internet Control Message Protocol", STD 5,
  362.             RFC 792, USC/Information Sciences Institute, September
  363.             1981.
  364.  
  365.    [RFC-1191]
  366.             Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
  367.             DECWRL, Stanford University, November 1990.
  368.  
  369.    [RFC-1241]
  370.             Mills, D., and R. Woodburn, "A Scheme for an Internet
  371.             Encapsulation Protocol: Version 1", UDEL, July 1991.
  372.  
  373.    [RFC-1435]
  374.             Knowles, S., "IESG Advice from Experience with Path MTU
  375.             Discovery", RFC 1435, FTP Software, March 1993.
  376.  
  377.    [RFC-1700]
  378.             Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
  379.             1700, USC/Information Sciences Institute, October 1994.
  380.  
  381.    [RFC-1701]
  382.             Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
  383.             Routing Encapsulation (GRE)", RFC 1701, October 1994.
  384.  
  385.    [swIPe]  Ioannidis, J., and Blaze, M., "The Architecture and
  386.             Implementation of Network-Layer Security Under Unix", Fourth
  387.             Usenix Security Symposium Proceedings, October 1993.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Simpson                      Informational                      [Page 7]
  395.  
  396. RFC 1853                     IP Tunnelling                  October 1995
  397.  
  398.  
  399. Acknowledgements
  400.  
  401.    These implementation details of IP Tunneling are derived in large
  402.    part from independent work in 1990 by Phil Karn and the TCP-Group
  403.    hams using KA9Q NOS.
  404.  
  405.    Special thanks to John Ioannidis (then of Columbia University) for
  406.    inspiration and experimentation which began this most recent round of
  407.    IP Mobility and IP Security development.  Some of this text was
  408.    derived from [IDM91a] and [swIPe].
  409.  
  410.    The chaining of headers was also described in "Simple Internet
  411.    Protocol", by Steve Deering (Xerox PARC).
  412.  
  413.    The overall organization and some of this text was derived from
  414.    [RFC-1241], by David Mills (U Delaware) and Robert Woodburn (SAIC).
  415.  
  416.    Some of the text on tunnel soft state was derived from "IP Address
  417.    Encapsulation (IPAE)", by Robert E. Gilligan, Erik Nordmark, and Bob
  418.    Hinden (all of Sun Microsystems).
  419.  
  420.  
  421. Author's Address
  422.  
  423.    Questions about this memo can also be directed to:
  424.  
  425.       William Allen Simpson
  426.       Daydreamer
  427.       Computer Systems Consulting Services
  428.       1384 Fontaine
  429.       Madison Heights, Michigan  48071
  430.  
  431.       Bill.Simpson@um.cc.umich.edu
  432.           bsimpson@MorningStar.com
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Simpson                      Informational                      [Page 8]
  451.  
  452.