rfc3024.txt

最新的RFC

Montenegro                  Standards Track                     [Page 6]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |S|B|D|M|G|V|T|-|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

   The only change to the Registration Request packet is the additional
   'T' bit:

   T        If the 'T' bit is set, the mobile node asks its home
            agent to accept a reverse tunnel from the care-of
            address.  Mobile nodes using a foreign agent care-of
            address ask the foreign agent to reverse-tunnel its
            packets.

3.3. Encapsulating Delivery Style Extension

   The Encapsulating Delivery Style Extension MAY be included by the
   mobile node in registration requests to further specify reverse
   tunneling behavior.  It is expected to be used only by the foreign
   agent.  Accordingly, the foreign agent MUST consume this extension
   (that is, it must not relay it to the home agent or include it in
   replies to the mobile node).  As per Section 3.6.1.3 of [1], the
   mobile node MUST include the Encapsulating Delivery Style Extension
   after the Mobile-Home Authentication Extension, and before the
   Mobile-Foreign Authentication Extension, if present.

   The Encapsulating Delivery Style Extension MUST NOT be included if
   the 'T' bit is not set in the Registration Request.

   If this extension is absent, Direct Delivery is assumed.
   Encapsulation is done according to what was negotiated for the
   forward tunnel (that is, IP in IP is assumed unless specified
   otherwise).  For more details on the delivery styles, please refer to
   section 5.





Montenegro                  Standards Track                     [Page 7]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   Foreign agents SHOULD support the Encapsulating Delivery Style
   Extension.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         130

      Length

         0

3.4. New Registration Reply Codes

   Foreign and home agent registration replies MUST convey if the
   reverse tunnel request failed.  These new reply codes are defined:

      Service denied by the foreign agent:

      74 requested reverse tunnel unavailable
      75 reverse tunnel is mandatory and 'T' bit not set
      76 mobile node too distant
      79 delivery style not supported

      NOTE: Code 79 has not yet been assigned by IANA.

   and

      Service denied by the home agent:

      137 requested reverse tunnel unavailable
      138 reverse tunnel is mandatory and 'T' bit not set
      139 requested encapsulation unavailable

   In response to a Registration Request with the 'T' bit set, mobile
   nodes may receive (and MUST accept) code 70 (poorly formed request)
   from foreign agents and code 134 (poorly formed request) from home
   agents.  However, foreign and home agents that support reverse
   tunneling MUST use codes 74 and 137, respectively.

   In addition to setting the 'T' bit, the mobile node also MAY request
   the Encapsulating Delivery Style by including the corresponding
   extension.  If a foreign agent does not implement the Encapsulating



Montenegro                  Standards Track                     [Page 8]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   Delivery Style, it MUST respond to the mobile node with code 79
   (delivery style not supported).  This also applies if the foreign
   agent does not support a requested delivery style that may be defined
   in the future.

   Absence of the 'T' bit in a Registration Request MAY elicit denials
   with codes 75 and 138 at the foreign agent and the home agent,
   respectively.

   Forward and reverse tunnels are symmetric, that is, both are able to
   use the same tunneling options negotiated at registration.  This
   implies that the home agent MUST deny registrations if an unsupported
   form of tunneling is requested (code 139).  Notice that Mobile IP [1]
   already defines the analogous failure code 72 for use by the foreign
   agent.

4. Changes in Protocol Behavior

   Unless otherwise specified, behavior specified by Mobile IP [1] is
   assumed.  In particular, if any two entities share a mobility
   security association, they MUST use the appropriate Authentication
   Extension (Mobile-Foreign, Foreign-Home or Mobile-Home Authentication
   Extension) when exchanging registration protocol datagrams.  An
   admissible authentication extension (for example the Mobile-Home
   Authentication Extension) MUST always be present to authenticate
   registration messages between a mobile node and its home agent.

   Reverse tunneling imposes additional protocol processing requirements
   on mobile entities.  Differences in protocol behavior with respect to
   Mobile IP [1] are specified in the subsequent sections.

4.1. Mobile Node Considerations

   This section describes how the mobile node handles registrations that
   request a reverse tunnel.

4.1.1. Sending Registration Requests to the Foreign Agent

   In addition to the considerations in [1], a mobile node sets the 'T'
   bit in its Registration Request to petition a reverse tunnel.

   The mobile node MUST set the TTL field of the IP header to 255.  This
   is meant to limit the reverse tunnel hijacking attack (Section 6).

   The mobile node MAY optionally include an Encapsulating Delivery
   Style Extension.





Montenegro                  Standards Track                     [Page 9]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


4.1.2. Receiving Registration Replies from the Foreign Agent

   Possible valid responses are:

      -  A registration denial issued by either the home agent or the
         foreign agent:

         a. The mobile node follows the error checking guidelines in
            [1], and depending on the reply code, MAY try modifying the
            registration request (for example, by eliminating the
            request for alternate forms of encapsulation or delivery
            style), and issuing a new registration.

         b. Depending on the reply code, the mobile node MAY try zeroing
            the 'T' bit, eliminating the Encapsulating Delivery Style
            Extension (if one was present), and issuing a new
            registration.  Notice that after doing so the registration
            may succeed, but due to the lack of a reverse tunnel data
            transfer may not be possible.

      -  The home agent returns a Registration Reply indicating that the
         service will be provided.

   In this last case, the mobile node has succeeded in establishing a
   reverse tunnel between its care-of address and its home agent.  If
   the mobile node is operating with a co-located care-of address, it
   MAY encapsulate outgoing data such that the destination address of
   the outer header is the home agent.  This ability to selectively
   reverse-tunnel packets is discussed further in section 5.4.

   If the care-of address belongs to a separate foreign agent, the
   mobile node MUST employ whatever delivery style was requested (Direct
   or Encapsulating) and proceed as specified in section 5.

   A successful registration reply is an assurance that both the foreign
   agent and the home agent support whatever alternate forms of
   encapsulation (other than IP in IP) were requested.  Accordingly, the
   mobile node MAY use them at its discretion.

4.2. Foreign Agent Considerations

   This section describes how the foreign agent handles registrations
   that request a reverse tunnel.








Montenegro                  Standards Track                    [Page 10]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


4.2.1. Receiving Registration Requests from the Mobile Node

   A foreign agent that receives a Registration Request with the 'T' bit
   set processes the packet as specified in the Mobile IP specification
   [1], and determines whether it can accommodate the forward tunnel
   request.  If it cannot, it returns an appropriate code.  In
   particular, if the foreign agent is unable to support the requested
   form of encapsulation it MUST return code 72.  If it cannot support
   the requested form of delivery style it MUST return code 79 (delivery
   style not supported).

   The foreign agent MAY reject Registration Requests without the 'T'
   bit set by denying them with code 75 (reverse tunnel is mandatory and
   'T' bit not set).

   The foreign agent MUST verify that the TTL field of the IP header is
   set to 255.  Otherwise, it MUST reject the registration with code 76
   (mobile node too distant).  The foreign agent MUST limit the rate at
   which it sends these registration replies to a maximum of one per
   second.

   As a last check, the foreign agent verifies that it can support a
   reverse tunnel with the same configuration.  If it cannot, it MUST
   return a Registration Reply denying the request with code 74
   (requested reverse tunnel unavailable).

4.2.2. Relaying Registration Requests to the Home Agent

   Otherwise, the foreign agent MUST relay the Registration Request to
   the home agent.

   Upon receipt of a Registration Reply that satisfies validity checks,
   the foreign agent MUST update its visitor list, including indication
   that this mobile node has been granted a reverse tunnel and the
   delivery style expected (section 5).

   While this visitor list entry is in effect, the foreign agent MUST
   process incoming traffic according to the delivery style, encapsulate
   it and tunnel it from the care-of address to the home agent's
   address.

4.3. Home Agent Considerations

   This section describes how the home agent handles registrations that
   request a reverse tunnel.






Montenegro                  Standards Track                    [Page 11]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


4.3.1. Receiving Registration Requests from the Foreign Agent

   A home agent that receives a Registration Request with the 'T' bit
   set processes the packet as specified in the Mobile IP specification
   [1] and determines whether it can accommodate the forward tunnel
   request.  If it cannot, it returns an appropriate code.  In
   particular, if the home agent is unable to support the requested form
   of encapsulation it MUST return code 139 (requested encapsulation
   unavailable).

   The home agent MAY reject registration requests without the 'T' bit
   set by denying them with code 138 (reverse tunnel is mandatory and '
   T' bit not set).

   As a last check, the home agent determines whether it can support a
   reverse tunnel with the same configuration as the forward tunnel.  If
   it cannot, it MUST send back a registration denial with code 137
   (requested reverse tunnel unavailable).

   Upon receipt of a Registration Reply that satisfies validity checks,
   the home agent MUST update its mobility bindings list to indicate
   that this mobile node has been granted a reverse tunnel and the type
   of encapsulation expected.

4.3.2. Sending Registration Replies to the Foreign Agent

   In response to a valid Registration Request, a home agent MUST issue
   a Registration Reply to the mobile node.

   After a successful registration, the home agent may receive
   encapsulated packets addressed to itself.  Decapsulating such packets
   and blindly injecting them into the network is a potential security
   weakness (section 6.1).  Accordingly, the home agent MUST implement,
   and, by default, SHOULD enable the following check for encapsulated
   packets addressed to itself:

      The home agent searches for a mobility binding whose care-of
      address is the source of the outer header, and whose mobile node
      address is the source of the inner header.

   If no such binding is found, or if the packet uses an encapsulation
   mechanism that was not negotiated at registration the home agent MUST
   silently discard the packet and SHOULD log the event as a security
   exception.

   Home agents that terminate tunnels unrelated to Mobile IP (for
   example, multicast tunnels) MAY turn off the above check, but this
   practice is discouraged for the aforementioned reasons.



Montenegro                  Standards Track                    [Page 12]