rfc2003.txt

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


RFC 2003                      IP-within-IP                  October 1996


4.2. Source Quench (Type 4)

   The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
   sender of the original unencapsulated datagram, but instead SHOULD
   activate whatever congestion control mechanisms it implements to help
   alleviate the congestion detected within the tunnel.

4.3. Redirect (Type 5)

   The encapsulator MAY handle the ICMP Redirect messages itself.  It
   MUST NOT not relay the Redirect to the sender of the original
   unencapsulated datagram.

4.4. Time Exceeded (Type 11)

   ICMP Time Exceeded messages report (presumed) routing loops within
   the tunnel itself.  Reception of Time Exceeded messages by the
   encapsulator MUST be reported to the sender of the original
   unencapsulated datagram as Host Unreachable (Type 3, Code 1).  Host
   Unreachable is preferable to Network Unreachable; since the datagram
   was handled by the encapsulator, and the encapsulator is often
   considered to be on the same network as the destination address in
   the original unencapsulated datagram, then the datagram is considered
   to have reached the correct network, but not the correct destination
   node within that network.

4.5. Parameter Problem (Type 12)

   If the Parameter Problem message points to a field copied from the
   original unencapsulated datagram, the encapsulator MAY relay the ICMP
   message to the sender of the original unencapsulated datagram;
   otherwise, if the problem occurs with an IP option inserted by the
   encapsulator, then the encapsulator MUST NOT relay the ICMP message
   to the original sender.  Note that an encapsulator following
   prevalent current practice will never insert any IP options into the
   encapsulated datagram, except possibly for security reasons.

4.6. Other ICMP Messages

   Other ICMP messages are not related to the encapsulation operations
   described within this protocol specification, and should be acted on
   by the encapsulator as specified in [9].









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


5. Tunnel Management

   Unfortunately, ICMP only requires IP routers to return 8 octets (64
   bits) of the datagram beyond the IP header.  This is not enough to
   include a copy of the encapsulated (inner) IP header, so it is not
   always possible for the encapsulator to relay the ICMP message from
   the interior of a tunnel back to the original sender.  However, by
   carefully maintaining "soft state" about tunnels into which it sends,
   the encapsulator can return accurate ICMP messages to the original
   sender in most cases.  The encapsulator SHOULD maintain at least the
   following soft state information about each tunnel:

    - MTU of the tunnel (Section 5.1)
    - TTL (path length) of the tunnel
    - Reachability of the end of the tunnel

   The encapsulator uses the ICMP messages it receives from the interior
   of a tunnel to update the soft state information for that tunnel.
   ICMP errors that could be received from one of the routers along the
   tunnel interior include:

    - Datagram Too Big
    - Time Exceeded
    - Destination Unreachable
    - Source Quench

   When subsequent datagrams arrive that would transit the tunnel, the
   encapsulator checks the soft state for the tunnel.  If the datagram
   would violate the state of the tunnel (for example, the TTL of the
   new datagram is less than the tunnel "soft state" TTL) the
   encapsulator sends an ICMP error message back to the sender of the
   original datagram, but also encapsulates the datagram and forwards it
   into the tunnel.

   Using this technique, the ICMP error messages sent by the
   encapsulator will not always match up one-to-one with errors
   encountered within the tunnel, but they will accurately reflect the
   state of the network.

   Tunnel soft state was originally developed for the IP Address
   Encapsulation (IPAE) specification [4].

5.1. Tunnel MTU Discovery

   When the Don't Fragment bit is set by the originator and copied into
   the outer IP header, the proper MTU of the tunnel will be learned
   from ICMP Datagram Too Big (Type 3, Code 4) messages reported to the
   encapsulator.  To support sending nodes which use Path MTU Discovery,



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


   all encapsulator implementations MUST support Path MTU Discovery [5,
   7] soft state within their tunnels.  In this particular application,
   there are several advantages:

    -  As a benefit of Path MTU Discovery within the tunnel, any
       fragmentation which occurs because of the size of the
       encapsulation header is performed only once after encapsulation.
       This prevents multiple fragmentation of a single datagram, which
       improves processing efficiency of the decapsulator and the
       routers within the tunnel.

    -  If the source of the unencapsulated datagram is doing Path MTU
       Discovery, then it is desirable for the encapsulator to know
       the MTU of the tunnel.  Any ICMP Datagram Too Big messages from
       within the tunnel are returned to the encapsulator, and as noted
       in Section 5, it is not always possible for the encapsulator to
       relay ICMP messages to the source of the original unencapsulated
       datagram.  By maintaining "soft state" about the MTU of the
       tunnel, the encapsulator can return correct ICMP Datagram Too Big
       messages to the original sender of the unencapsulated datagram to
       support its own Path MTU Discovery.  In this case, the MTU that
       is conveyed to the original sender by the encapsulator SHOULD
       be the MTU of the tunnel minus the size of the encapsulating
       IP header.  This will avoid fragmentation of the original IP
       datagram by the encapsulator.

    -  If the source of the original unencapsulated datagram is
       not doing Path MTU Discovery, it is still desirable for the
       encapsulator to know the MTU of the tunnel.  In particular, it is
       much better to fragment the original datagram when encapsulating,
       than to allow the encapsulated datagram to be fragmented.
       Fragmenting the original datagram can be done by the encapsulator
       without special buffer requirements and without the need to
       keep reassembly state in the decapsulator.  By contrast, if
       the encapsulated datagram is fragmented, then the decapsulator
       must reassemble the fragmented (encapsulated) datagram before
       decapsulating it, requiring reassembly state and buffer space
       within the decapsulator.

   Thus, the encapsulator SHOULD normally do Path MTU Discovery,
   requiring it to send all datagrams into the tunnel with the "Don't
   Fragment" bit set in the outer IP header.  However there are problems
   with this approach.  When the original sender sets the "Don't
   Fragment" bit, the sender can react quickly to any returned ICMP
   Datagram Too Big error message by retransmitting the original
   datagram.  On the other hand, suppose that the encapsulator receives
   an ICMP Datagram Too Big message from within the tunnel.  In that
   case, if the original sender of the unencapsulated datagram had not



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


   set the "Don't Fragment" bit, there is nothing sensible that the
   encapsulator can do to let the original sender know of the error.
   The encapsulator MAY keep a copy of the sent datagram whenever it
   tries increasing the tunnel MTU, in order to allow it to fragment and
   resend the datagram if it gets a Datagram Too Big response.
   Alternatively the encapsulator MAY be configured for certain types of
   datagrams not to set the "Don't Fragment" bit when the original
   sender of the unencapsulated datagram has not set the "Don't
   Fragment" bit.

5.2. Congestion

   An encapsulator might receive indications of congestion from the
   tunnel, for example, by receiving ICMP Source Quench messages from
   nodes within the tunnel.  In addition, certain link layers and
   various protocols not related to the Internet suite of protocols
   might provide such indications in the form of a Congestion
   Experienced [6] flag.  The encapsulator SHOULD reflect conditions of
   congestion in its "soft state" for the tunnel, and when subsequently
   forwarding datagrams into the tunnel, the encapsulator SHOULD use
   appropriate means for controlling congestion [3]; However, the
   encapsulator SHOULD NOT send ICMP Source Quench messages to the
   original sender of the unencapsulated datagram.

6. Security Considerations

   IP encapsulation potentially reduces the security of the Internet,
   and care needs to be taken in the implementation and deployment of IP
   encapsulation.  For example, IP encapsulation makes it difficult for
   border routers to filter datagrams based on header fields.  In
   particular, the original values of the Source Address, Destination
   Address, and Protocol fields in the IP header, and the port numbers
   used in any transport header within the datagram, are not located in
   their normal positions within the datagram after encapsulation.
   Since any IP datagram can be encapsulated and passed through a
   tunnel, such filtering border routers need to carefully examine all
   datagrams.

6.1. Router Considerations

   Routers need to be aware of IP encapsulation protocols in order to
   correctly filter incoming datagrams.  It is desirable that such
   filtering be integrated with IP authentication [1].  Where IP
   authentication is used, encapsulated packets might be allowed to
   enter an organization when the encapsulating (outer) packet or the
   encapsulated (inner) packet is sent by an authenticated, trusted
   source.  Encapuslated packets containing no such authentication
   represent a potentially large security risk.



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


   IP datagrams which are encapsulated and encrypted [2] might also pose
   a problem for filtering routers.  In this case, the router can filter
   the datagram only if it shares the security association used for the
   encryption.  To allow this sort of encryption in environments in
   which all packets need to be filtered (or at least accounted for), a
   mechanism must be in place for the receiving node to securely
   communicate the security association to the border router.  This
   might, more rarely, also apply to the security association used for
   outgoing datagrams.

6.2. Host Considerations

   Host implementations that are capable of receiving encapsulated IP
   datagrams SHOULD admit only those datagrams fitting into one or more
   of the following categories:

    -  The protocol is harmless:  source address-based authentication is
       not needed.

    -  The encapsulating (outer) datagram comes from an authentically
       identified, trusted source.  The authenticity of the source could
       be established by relying on physical security in addition to
       border router configuration, but is more likely to come from use
       of the IP Authentication header [1].

    -  The encapuslated (inner) datagram includes an IP Authentication
       header.

    -  The encapsulated (inner) datagram is addressed to a network
       interface belonging to the decapsulator, or to a node with which
       the decapsulator has entered into a special relationship for
       delivering such encapsulated datagrams.

   Some or all of this checking could be done in border routers rather
   than the receiving node, but it is better if border router checks are
   used as backup, rather than being the only check.















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


7. Acknowledgements

   Parts of Sections 3 and 5 of this document were taken from portions
   (authored by Bill Simpson) of earlier versions of the Mobile IP
   Internet Draft [8].  The original text for section 6 (Security
   Considerations) was contributed by Bob Smart.  Good ideas have also
   been included from RFC 1853 [11], also authored by Bill Simpson.
   Thanks also to Anders Klemets for finding mistakes and suggesting
   improvements to the draft.  Finally, thanks to David Johnson for
   going over the draft with a fine-toothed comb, finding mistakes,
   improving consistency, and making many other improvements to the
   draft.

References

   [1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.

   [2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
       August 1995.

   [3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
       1812, June 1995.

   [4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
       Interoperability and Transition Mechanism", Work in Progress.

   [5] Knowles, S., "IESG Advice from Experience with Path MTU
       Discovery", RFC 1435, March 1993.

   [6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
       Survey", RFC 1254, August 1991.

   [7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.

   [8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
       October 1996.

   [9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
       RFC 792, September 1981.

   [10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
        September 1981.

   [11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.






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


Author's Address

   Questions about this memo can be directed to:

   Charles Perkins
   Room H3-D34
   T. J. Watson Research Center
   IBM Corporation
   30 Saw Mill River Rd.
   Hawthorne, NY  10532

   Work:   [phone]
   Fax:    [phone]
   EMail: [e-mail]

   The working group can be contacted via the current chair:

   Jim Solomon
   Motorola, Inc.
   1301 E. Algonquin Rd.
   Schaumburg, IL  60196

   Work:   [phone]
   EMail: [e-mail]



























Perkins                     Standards Track                    [Page 14]