home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2004.txt < prev    next >
Text File  |  1996-10-17  |  12KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Perkins
  8. Request for Comments: 2004                                           IBM
  9. Category: Standards Track                                   October 1996
  10.  
  11.  
  12.                     Minimal Encapsulation within IP
  13.  
  14. Status of This Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document specifies a method by which an IP datagram may be
  25.    encapsulated (carried as payload) within an IP datagram, with less
  26.    overhead than "conventional" IP encapsulation that adds a second IP
  27.    header to each encapsulated datagram.  Encapsulation is suggested as
  28.    a means to alter the normal IP routing for datagrams, by delivering
  29.    them to an intermediate destination that would otherwise not be
  30.    selected by the (network part of the) IP Destination Address field in
  31.    the original IP header.  Encapsulation may be serve a variety of
  32.    purposes, such as delivery of a datagram to a mobile node using
  33.    Mobile IP.
  34.  
  35. 1. Introduction
  36.  
  37.    This document specifies a method by which an IP datagram may be
  38.    encapsulated (carried as payload) within an IP datagram, with less
  39.    overhead than "conventional" IP encapsulation [4] that adds a second
  40.    IP header to each encapsulated datagram.  Encapsulation is suggested
  41.    as a means to alter the normal IP routing for datagrams, by
  42.    delivering them to an intermediate destination that would otherwise
  43.    not be selected by the (network part of the) IP Destination Address
  44.    field in the original IP header.  The process of encapsulation and
  45.    decapsulation of a datagram is frequently referred to as "tunneling"
  46.    the datagram, and the encapsulator and decapsulator are then
  47.    considered to be the the "endpoints" of the tunnel; the encapsulator
  48.    node is refered to as the "entry point" of the tunnel, and the
  49.    decapsulator node is refered to as the "exit point" of the tunnel.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Perkins                     Standards Track                     [Page 1]
  59.  
  60. RFC 2004              Minimal Encapsulation for IP          October 1996
  61.  
  62.  
  63. 2. Motivation
  64.  
  65.    The Mobile IP working group has specified the use of encapsulation as
  66.    a way to deliver packets from a mobile node's "home network" to an
  67.    agent that can deliver datagrams locally by conventional means to the
  68.    mobile node at its current location away from home [5].  The use of
  69.    encapsulation may also be indicated whenever the source (or an
  70.    intermediate router) of an IP datagram must influence the route by
  71.    which a datagram is to be delivered to its ultimate destination.
  72.    Other possible applications of encapsulation include multicasting,
  73.    preferential billing, choice of routes with selected security
  74.    attributes, and general policy routing.
  75.  
  76.    See [4] for a discussion concerning the advantages of encapsulation
  77.    versus use of the IP loose source routing option.  Using IP headers
  78.    to encapsulate IP datagrams requires the unnecessary duplication of
  79.    several fields within the inner IP header; it is possible to save
  80.    some additional space by specifying a new encapsulation mechanism
  81.    that eliminates the duplication.  The scheme outlined here comes from
  82.    the Mobile IP Working Group (in earlier Internet Drafts), and is
  83.    similar to that which had been defined in [2].
  84.  
  85. 3. Minimal Encapsulation
  86.  
  87.    A minimal forwarding header is defined for datagrams which are not
  88.    fragmented prior to encapsulation.  Use of this encapsulating method
  89.    is optional.  Minimal encapsulation MUST NOT be used when an original
  90.    datagram is already fragmented, since there is no room in the minimal
  91.    forwarding header to store fragmentation information.  To encapsulate
  92.    an IP datagram using minimal encapsulation, the minimal forwarding
  93.    header is inserted into the datagram, as follows:
  94.  
  95.      +---------------------------+       +---------------------------+
  96.      |                           |       |                           |
  97.      |         IP Header         |       |     Modified IP Header    |
  98.      |                           |       |                           |
  99.      +---------------------------+ ====> +---------------------------+
  100.      |                           |       | Minimal Forwarding Header |
  101.      |                           |       +---------------------------+
  102.      |         IP Payload        |       |                           |
  103.      |                           |       |                           |
  104.      |                           |       |         IP Payload        |
  105.      +---------------------------+       |                           |
  106.                                          |                           |
  107.                                          +---------------------------+
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Perkins                     Standards Track                     [Page 2]
  115.  
  116. RFC 2004              Minimal Encapsulation for IP          October 1996
  117.  
  118.  
  119.    The IP header of the original datagram is modified, and the minimal
  120.    forwarding header is inserted into the datagram after the IP header,
  121.    followed by the unmodified IP payload of the original datagram (e.g.,
  122.    transport header and transport data).  No additional IP header is
  123.    added to the datagram.
  124.  
  125.    In encapsulating the datagram, the original IP header [6] is modified
  126.    as follows:
  127.  
  128.     -  The Protocol field in the IP header is replaced by protocol
  129.        number 55 for the minimal encapsulation protocol.
  130.  
  131.     -  The Destination Address field in the IP header is replaced by the
  132.        IP address of the exit point of the tunnel.
  133.  
  134.     -  If the encapsulator is not the original source of the datagram,
  135.        the Source Address field in the IP header is replaced by the IP
  136.        address of the encapsulator.
  137.  
  138.     -  The Total Length field in the IP header is incremented by the
  139.        size of the minimal forwarding header added to the datagram.
  140.        This incremental size is either 12 or 8 octets, depending on
  141.        whether or not the Original Source Address Present (S) bit is set
  142.        in the forwarding header.
  143.  
  144.     -  The Header Checksum field in the IP header is recomputed [6] or
  145.        updated to account for the changes in the IP header described
  146.        here for encapsulation.
  147.  
  148.     Note that unlike IP-in-IP encapsulation [4], the Time to Live
  149.     (TTL) field in the IP header is not modified during encapsulation;
  150.     if the encapsulator is forwarding the datagram, it will decrement
  151.     the TTL as a result of doing normal IP forwarding.  Also, since
  152.     the original TTL remains in the IP header after encapsulation,
  153.     hops taken by the datagram within the tunnel are visible, for
  154.     example, to "traceroute".
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Perkins                     Standards Track                     [Page 3]
  171.  
  172. RFC 2004              Minimal Encapsulation for IP          October 1996
  173.  
  174.  
  175.    The format of the minimal forwarding header is as follows:
  176.  
  177.     0                   1                   2                   3
  178.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  179.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.    |   Protocol    |S|  reserved   |        Header Checksum        |
  181.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.    |                 Original Destination Address                  |
  183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.    :            (if present) Original Source Address               :
  185.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.  
  187.       Protocol
  188.  
  189.          Copied from the Protocol field in the original IP header.
  190.  
  191.       Original Source Address Present (S)
  192.  
  193.             0  The Original Source Address field is not present.  The
  194.                length of the minimal tunneling header in this case is
  195.                8 octets.
  196.  
  197.             1  The Original Source Address field is present.  The
  198.                length of the minimal tunneling header in this case is
  199.                12 octets.
  200.  
  201.       reserved
  202.  
  203.          Sent as zero; ignored on reception.
  204.  
  205.       Header Checksum
  206.  
  207.          The 16-bit one's complement of the one's complement sum of all
  208.          16-bit words in the minimal forwarding header.  For purposes of
  209.          computing the checksum, the value of the checksum field is 0.
  210.          The IP header and IP payload (after the minimal forwarding
  211.          header) are not included in this checksum computation.
  212.  
  213.       Original Destination Address
  214.  
  215.          Copied from the Destination Address field in the original IP
  216.          header.
  217.  
  218.       Original Source Address
  219.  
  220.          Copied from the Source Address field in the original IP header.
  221.          This field is present only if the Original Source Address
  222.          Present (S) bit is set.
  223.  
  224.  
  225.  
  226. Perkins                     Standards Track                     [Page 4]
  227.  
  228. RFC 2004              Minimal Encapsulation for IP          October 1996
  229.  
  230.  
  231.    When decapsulating a datagram, the fields in the minimal forwarding
  232.    header are restored to the IP header, and the forwarding header is
  233.    removed from the datagram.  In addition, the Total Length field in
  234.    the IP header is decremented by the size of the minimal forwarding
  235.    header removed from the datagram, and the Header Checksum field in
  236.    the IP header is recomputed [6] or updated to account for the changes
  237.    to the IP header described here for decapsulation.
  238.  
  239.    The encapsulator may use existing IP mechanisms appropriate for
  240.    delivery of the encapsulated payload to the tunnel exit point.  In
  241.    particular, use of IP options are allowed, and use of fragmentation
  242.    is allowed unless the "Don't Fragment" bit is set in the IP header.
  243.    This restriction on fragmentation is required so that nodes employing
  244.    Path MTU Discovery [3] can obtain the information they seek.
  245.  
  246. 4. Routing Failures
  247.  
  248.    The use of any encapsulation method for routing purposes brings with
  249.    it increased susceptibility to routing loops.  To cut down the
  250.    danger, a router should follow the same procedures outlined in [4].
  251.  
  252. 5. ICMP Messages from within the Tunnel
  253.  
  254.    ICMP messages are to be handled as specified in [4], including the
  255.    maintenance of tunnel "soft state".
  256.  
  257. 6. Security Considerations
  258.  
  259.    Security considerations are not addressed in this document, but are
  260.    generally similar to those outlined in [4].
  261.  
  262. 7. Acknowledgements
  263.  
  264.    The original text for much of Section 3 was taken from the Mobile IP
  265.    draft [1].  Thanks to David Johnson for improving consistency and
  266.    making many other improvements to the draft.
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Perkins                     Standards Track                     [Page 5]
  283.  
  284. RFC 2004              Minimal Encapsulation for IP          October 1996
  285.  
  286.  
  287. References
  288.  
  289.    [1] Perkins, C., Editor, "IPv4 Mobility Support", Work in Progress,
  290.        May 1995.
  291.  
  292.    [2] David B. Johnson.  Scalable and Robust Internetwork Routing
  293.        for Mobile Hosts.  In Proceedings of the 14th International
  294.        Conference on Distributed Computing Systems, pages 2--11, June
  295.        1994.
  296.  
  297.    [3] Mogul, J.,  and S. Deering, "Path MTU Discovery", RFC 1191,
  298.        November 1990.
  299.  
  300.    [4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
  301.        October 1996.
  302.  
  303.    [5] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
  304.        October 1996.
  305.  
  306.    [6] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
  307.        September 1981.
  308.  
  309. Author's Address
  310.  
  311.    Questions about this memo can be directed to:
  312.  
  313.    Charles Perkins
  314.    Room H3-D34
  315.    T. J. Watson Research Center
  316.    IBM Corporation
  317.    30 Saw Mill River Rd.
  318.    Hawthorne, NY  10532
  319.  
  320.    Work:   +1-914-784-7350
  321.    Fax:    +1-914-784-6205
  322.    EMail: perk@watson.ibm.com
  323.  
  324.    The working group can be contacted via the current chair:
  325.  
  326.    Jim Solomon
  327.    Motorola, Inc.
  328.    1301 E. Algonquin Rd.
  329.    Schaumburg, IL  60196
  330.  
  331.    Work:   +1-847-576-2753
  332.    EMail: solomon@comm.mot.com
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Perkins                     Standards Track                     [Page 6]
  339.  
  340.