rfc2003.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         C. Perkins
Request for Comment: 2003                                            IBM
Category: Standards Track                                   October 1996


                       IP Encapsulation within IP

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document specifies a method by which an IP datagram may be
   encapsulated (carried as payload) within an IP datagram.
   Encapsulation is suggested as a means to alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination that
   would otherwise not be selected by the (network part of the) IP
   Destination Address field in the original IP header.  Encapsulation
   may serve a variety of purposes, such as delivery of a datagram to a
   mobile node using Mobile IP.

1. Introduction

   This document specifies a method by which an IP datagram may be
   encapsulated (carried as payload) within an IP datagram.
   Encapsulation is suggested as a means to alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination that
   would otherwise not be selected based on the (network part of the) IP
   Destination Address field in the original IP header.  Once the
   encapsulated datagram arrives at this intermediate destination node,
   it is decapsulated, yielding the original IP datagram, which is then
   delivered to the destination indicated by the original Destination
   Address field.  This use of encapsulation and decapsulation of a
   datagram is frequently referred to as "tunneling" the datagram, and
   the encapsulator and decapsulator are then considered to be the
   "endpoints" of the tunnel.

   In the most general tunneling case we have

      source ---> encapsulator --------> decapsulator ---> destination

   with the source, encapsulator, decapsulator, and destination being
   separate nodes.  The encapsulator node is considered the "entry



Perkins                     Standards Track                     [Page 1]

RFC 2003                      IP-within-IP                  October 1996


   point" of the tunnel, and the decapsulator node is considered the
   "exit point" of the tunnel.  There in general may be multiple
   source-destination pairs using the same tunnel between the
   encapsulator and decapsulator.

2. Motivation

   The Mobile IP working group has specified the use of encapsulation as
   a way to deliver datagrams from a mobile node's "home network" to an
   agent that can deliver datagrams locally by conventional means to the
   mobile node at its current location away from home [8].  The use of
   encapsulation may also be desirable whenever the source (or an
   intermediate router) of an IP datagram must influence the route by
   which a datagram is to be delivered to its ultimate destination.
   Other possible applications of encapsulation include multicasting,
   preferential billing, choice of routes with selected security
   attributes, and general policy routing.

   It is generally true that encapsulation and the IP loose source
   routing option [10] can be used in similar ways to affect the routing
   of a datagram, but there are several technical reasons to prefer
   encapsulation:

    -  There are unsolved security problems associated with the use of
       the IP source routing options.

    -  Current Internet routers exhibit performance problems when
       forwarding datagrams that contain IP options, including the IP
       source routing options.

    -  Many current Internet nodes process IP source routing options
       incorrectly.

    -  Firewalls may exclude IP source-routed datagrams.

    -  Insertion of an IP source route option may complicate the
       processing of authentication information by the source and/or
       destination of a datagram, depending on how the authentication is
       specified to be performed.

    -  It is considered impolite for intermediate routers to make
       modifications to datagrams which they did not originate.

   These technical advantages must be weighed against the disadvantages
   posed by the use of encapsulation:

    -  Encapsulated datagrams typically are larger than source routed
       datagrams.



Perkins                     Standards Track                     [Page 2]

RFC 2003                      IP-within-IP                  October 1996


    -  Encapsulation cannot be used unless it is known in advance that
       the node at the tunnel exit point can decapsulate the datagram.

   Since the majority of Internet nodes today do not perform well when
   IP loose source route options are used, the second technical
   disadvantage of encapsulation is not as serious as it might seem at
   first.

3. IP in IP Encapsulation

   To encapsulate an IP datagram using IP in IP encapsulation, an outer
   IP header [10] is inserted before the datagram's existing IP header,
   as follows:

                                         +---------------------------+
                                         |                           |
                                         |      Outer IP Header      |
                                         |                           |
     +---------------------------+       +---------------------------+
     |                           |       |                           |
     |         IP Header         |       |         IP Header         |
     |                           |       |                           |
     +---------------------------+ ====> +---------------------------+
     |                           |       |                           |
     |                           |       |                           |
     |         IP Payload        |       |         IP Payload        |
     |                           |       |                           |
     |                           |       |                           |
     +---------------------------+       +---------------------------+

   The outer IP header Source Address and Destination Address identify
   the "endpoints" of the tunnel.  The inner IP header Source Address
   and Destination Addresses identify the original sender and recipient
   of the datagram, respectively.  The inner IP header is not changed by
   the encapsulator, except to decrement the TTL as noted below, and
   remains unchanged during its delivery to the tunnel exit point.  No
   change to IP options in the inner header occurs during delivery of
   the encapsulated datagram through the tunnel.  If need be, other
   protocol headers such as the IP Authentication header [1] may be
   inserted between the outer IP header and the inner IP header.  Note
   that the security options of the inner IP header MAY affect the
   choice of security options for the encapsulating (outer) IP header.









Perkins                     Standards Track                     [Page 3]

RFC 2003                      IP-within-IP                  October 1996


3.1. IP Header Fields and Handling

   The fields in the outer IP header are set by the encapsulator as
   follows:

      Version

         4

      IHL

         The Internet Header Length (IHL) is the length of the outer IP
         header measured in 32-bit words [10].

      TOS

         The Type of Service (TOS) is copied from the inner IP header.

      Total Length

         The Total Length measures the length of the entire encapsulated
         IP datagram, including the outer IP header, the inner IP
         header, and its payload.

      Identification, Flags, Fragment Offset

         These three fields are set as specified in [10].  However, if
         the "Don't Fragment" bit is set in the inner IP header, it MUST
         be set in the outer IP header; if the "Don't Fragment" bit is
         not set in the inner IP header, it MAY be set in the outer IP
         header, as described in Section 5.1.

      Time to Live

         The Time To Live (TTL) field in the outer IP header is set to a
         value appropriate for delivery of the encapsulated datagram to
         the tunnel exit point.

      Protocol

         4

      Header Checksum

         The Internet Header checksum [10] of the outer IP header.






Perkins                     Standards Track                     [Page 4]

RFC 2003                      IP-within-IP                  October 1996


      Source Address

         The IP address of the encapsulator, that is, the tunnel entry
         point.

      Destination Address

         The IP address of the decapsulator, that is, the tunnel exit
         point.

      Options

         Any options present in the inner IP header are in general NOT
         copied to the outer IP header.  However, new options specific
         to the tunnel path MAY be added.  In particular, any supported
         types of security options of the inner IP header MAY affect the
         choice of security options for the outer header.  It is not
         expected that there be a one-to-one mapping of such options to
         the options or security headers selected for the tunnel.

   When encapsulating a datagram, the TTL in the inner IP header is
   decremented by one if the tunneling is being done as part of
   forwarding the datagram; otherwise, the inner header TTL is not
   changed during encapsulation.  If the resulting TTL in the inner IP
   header is 0, the datagram is discarded and an ICMP Time Exceeded
   message SHOULD be returned to the sender.  An encapsulator MUST NOT
   encapsulate a datagram with TTL = 0.

   The TTL in the inner IP header is not changed when decapsulating.
   If, after decapsulation, the inner datagram has TTL = 0, the
   decapsulator MUST discard the datagram.  If, after decapsulation, the
   decapsulator forwards the datagram to one of its network interfaces,
   it will decrement the TTL as a result of doing normal IP forwarding.
   See also Section 4.4.

   The encapsulator may use any existing IP mechanisms appropriate for
   delivery of the encapsulated payload to the tunnel exit point.  In
   particular, use of IP options is allowed, and use of fragmentation is
   allowed unless the "Don't Fragment" bit is set in the inner IP
   header.  This restriction on fragmentation is required so that nodes
   employing Path MTU Discovery [7] can obtain the information they
   seek.

3.2. Routing Failures

   Routing loops within a tunnel are particularly dangerous when they
   cause datagrams to arrive again at the encapsulator.  Suppose a
   datagram arrives at a router for forwarding, and the router



Perkins                     Standards Track                     [Page 5]

RFC 2003                      IP-within-IP                  October 1996


   determines that the datagram has to be encapsulated before further
   delivery.  Then:

    -  If the IP Source Address of the datagram matches the router's own
       IP address on any of its network interfaces, the router MUST NOT
       tunnel the datagram; instead, the datagram SHOULD be discarded.

    -  If the IP Source Address of the datagram matches the IP address
       of the tunnel destination (the tunnel exit point is typically
       chosen by the router based on the Destination Address in the
       datagram's IP header), the router MUST NOT tunnel the datagram;
       instead, the datagram SHOULD be discarded.

   See also Section 4.4.

4. ICMP Messages from within the Tunnel

   After an encapsulated datagram has been sent, the encapsulator may
   receive an ICMP [9] message from any intermediate router within the
   tunnel other than the tunnel exit point.  The action taken by the
   encapsulator depends on the type of ICMP message received.  When the
   received message contains enough information, the encapsulator MAY
   use the incoming message to create a similar ICMP message, to be sent
   to the originator of the original unencapsulated IP datagram (the
   original sender).  This process will be referred to as "relaying" the
   ICMP message from the tunnel.

   ICMP messages indicating an error in processing a datagram include a
   copy of (a portion of) the datagram causing the error.  Relaying an
   ICMP message requires that the encapsulator strip off the outer IP
   header from this returned copy of the original datagram.  For cases
   in which the received ICMP message does not contain enough data to
   relay the message, see Section 5.

4.1. Destination Unreachable (Type 3)

   ICMP Destination Unreachable messages are handled by the encapsulator
   depending upon their Code field.  The model suggested here allows the
   tunnel to "extend" a network to include non-local (e.g., mobile)
   nodes.  Thus, if the original destination in the unencapsulated
   datagram is on the same network as the encapsulator, certain
   Destination Unreachable Code values may be modified to conform to the
   suggested model.








Perkins                     Standards Track                     [Page 6]

RFC 2003                      IP-within-IP                  October 1996


      Network Unreachable (Code 0)

         An ICMP Destination Unreachable message SHOULD be returned
         to the original sender.  If the original destination in
         the unencapsulated datagram is on the same network as the
         encapsulator, the newly generated Destination Unreachable
         message sent by the encapsulator MAY have Code 1 (Host
         Unreachable), since presumably the datagram arrived at the
         correct network and the encapsulator is trying to create the
         appearance that the original destination is local to that
         network even if it is not.  Otherwise, if the encapsulator
         returns a Destination Unreachable message, the Code field MUST
         be set to 0 (Network Unreachable).

      Host Unreachable (Code 1)

         The encapsulator SHOULD relay Host Unreachable messages to the
         sender of the original unencapsulated datagram, if possible.

      Protocol Unreachable (Code 2)

         When the encapsulator receives an ICMP Protocol Unreachable
         message, it SHOULD send a Destination Unreachable message with
         Code 0 or 1 (see the discussion for Code 0) to the sender of
         the original unencapsulated datagram.  Since the original
         sender did not use protocol 4 in sending the datagram, it would
         be meaningless to return Code 2 to that sender.

      Port Unreachable (Code 3)

         This Code should never be received by the encapsulator, since
         the outer IP header does not refer to any port number.  It MUST
         NOT be relayed to the sender of the original unencapsulated
         datagram.

      Datagram Too Big (Code 4)

         The encapsulator MUST relay ICMP Datagram Too Big messages to
         the sender of the original unencapsulated datagram.

      Source Route Failed (Code 5)

         This Code SHOULD be handled by the encapsulator itself.
         It MUST NOT be relayed to the sender of the original
         unencapsulated datagram.






Perkins                     Standards Track                     [Page 7]