GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3024

Network Working Group G. Montenegro, Editor Request for Comments: 3024 Sun Microsystems, Inc. Obsoletes: 2344 January 2001 Category: Standards Track

              Reverse Tunneling for Mobile IP, revised

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.

Copyright Notice

 Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

 Mobile Internet Protocol (IP) uses tunneling from the home agent to
 the mobile node's care-of address, but rarely in the reverse
 direction.  Usually, a mobile node sends its packets through a router
 on the foreign network, and assumes that routing is independent of
 source address.  When this assumption is not true, it is convenient
 to establish a topologically correct reverse tunnel from the care-of
 address to the home agent.
 This document proposes backwards-compatible extensions to Mobile IP
 to support topologically correct reverse tunnels.  This document does
 not attempt to solve the problems posed by firewalls located between
 the home agent and the mobile node's care-of address.
 This document obsoletes RFC 2344.

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

Table of Contents

 1. Introduction ...................................................  3
 1.1. Terminology ..................................................  4
 1.2. Assumptions ..................................................  4
 1.3. Justification ................................................  5
 2. Overview .......................................................  5
 3. New Packet Formats .............................................  6
 3.1. Mobility Agent Advertisement Extension .......................  6
 3.2. Registration Request .........................................  6
 3.3. Encapsulating Delivery Style Extension .......................  7
 3.4. New Registration Reply Codes .................................  8
 4. Changes in Protocol Behavior ...................................  9
 4.1. Mobile Node Considerations ...................................  9
 4.1.1. Sending Registration Requests to the Foreign Agent .........  9
 4.1.2. Receiving Registration Replies from the Foreign Agent ...... 10
 4.2. Foreign Agent Considerations ................................. 10
 4.2.1. Receiving Registration Requests from the Mobile Node ....... 11
 4.2.2. Relaying Registration Requests to the Home Agent ........... 11
 4.3. Home Agent Considerations .................................... 11
 4.3.1. Receiving Registration Requests from the Foreign Agent ..... 12
 4.3.2. Sending Registration Replies to the Foreign Agent .......... 12
 5. Mobile Node to Foreign Agent Delivery Styles ................... 13
 5.1. Direct Delivery Style ........................................ 13
 5.1.1. Packet Processing .......................................... 13
 5.1.2. Packet Header Format and Fields ............................ 13
 5.2. Encapsulating Delivery Style ................................. 14
 5.2.1 Packet Processing ........................................... 14
 5.2.2. Packet Header Format and Fields ............................ 15
 5.3. Support for Broadcast and Multicast Datagrams ................ 16
 5.4. Selective Reverse Tunneling .................................. 16
 6. Security Considerations ........................................ 17
 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 17
 6.2. Ingress Filtering ............................................ 18
 6.3. Reverse Tunneling for Disparate Address Spaces ............... 18
 7. IANA Considerations ............................................ 18
 8. Acknowledgements ............................................... 18
 References ........................................................ 19
 Editor and Chair Addresses ........................................ 20
 Appendix A: Disparate Address Space Support ....................... 21
    A.1. Scope of the Reverse Tunneling Solution ................... 21
    A.2. Terminating Forward Tunnels at the Foreign Agent .......... 24
    A.3. Initiating Reverse Tunnels at the Foreign Agent ........... 26
    A.4. Limited Private Address Scenario .......................... 26
 Appendix B: Changes from RFC2344 .................................. 29
 Full Copyright Statement .......................................... 30

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

1. Introduction

 Section 1.3 of the Mobile IP specification [1] lists the following
 assumption:
    It is assumed that IP unicast datagrams are routed based on the
    destination address in the datagram header (i.e., not by source
    address).
 Because of security concerns (for example, IP spoofing attacks), and
 in accordance with RFC 2267 [8] and CERT [3] advisories to this
 effect, routers that break this assumption are increasingly more
 common.
 In the presence of such routers, the source and destination IP
 address in a packet must be topologically correct.  The forward
 tunnel complies with this, as its endpoints (home agent address and
 care-of address) are properly assigned addresses for their respective
 locations.  On the other hand, the source IP address of a packet
 transmitted by the mobile node does not correspond to the network
 prefix from where it emanates.
 This document discusses topologically correct reverse tunnels.
 Mobile IP does dictate the use of reverse tunnels in the context of
 multicast datagram routing and mobile routers.  However, the source
 IP address is set to the mobile node's home address, so these tunnels
 are not topologically correct.
 Notice that there are several uses for reverse tunnels regardless of
 their topological correctness:
  1. Mobile routers: reverse tunnels obviate the need for recursive

tunneling [1].

  1. Multicast: reverse tunnels enable a mobile node away from home

to (1) join multicast groups in its home network, and (2)

       transmit multicast packets such that they emanate from its home
       network [1].
  1. The TTL of packets sent by the mobile node (for example, when

sending packets to other hosts in its home network) may be so

       low that they might expire before reaching their destination.
       A reverse tunnel solves the problem as it represents a TTL
       decrement of one [5].

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

1.1. Terminology

 The discussion below uses terms defined in the Mobile IP
 specification.  Additionally, it uses the following terms:
    Forward Tunnel
       A tunnel that shuttles packets towards the mobile node.  It
       starts at the home agent, and ends at the mobile node's care-of
       address.
    Reverse Tunnel
       A tunnel that starts at the mobile node's care-of address and
       terminates at the home agent.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [9].

1.2. Assumptions

 Mobility is constrained to a common IP address space (that is, the
 routing fabric between, say, the mobile node and the home agent is
 not partitioned into a "private" and a "public" network).
 This document does not attempt to solve the firewall traversal
 problem.  Rather, it assumes one of the following is true:
  1. There are no intervening firewalls along the path of the

tunneled packets.

  1. Any intervening firewalls share the security association

necessary to process any authentication [6] or encryption [7]

       headers which may have been added to the tunneled packets.
 The reverse tunnels considered here are symmetric, that is, they use
 the same configuration (encapsulation method, IP address endpoints)
 as the forward tunnel.  IP in IP encapsulation [2] is assumed unless
 stated otherwise.
 Route optimization [4] introduces forward tunnels initiated at a
 correspondent host.  Since a mobile node may not know if the
 correspondent host can decapsulate packets, reverse tunnels in that
 context are not discussed here.

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

1.3. Justification

 Why not let the mobile node itself initiate the tunnel to the home
 agent?  This is indeed what it should do if it is already operating
 with a topologically correct co-located care-of address.
 However, one of the primary objectives of the Mobile IP specification
 is not to require this mode of operation.
 The mechanisms outlined in this document are primarily intended for
 use by mobile nodes that rely on the foreign agent for forward tunnel
 support.  It is desirable to continue supporting these mobile nodes,
 even in the presence of filtering routers.

2. Overview

 A mobile node arrives at a foreign network, listens for agent
 advertisements and selects a foreign agent that supports reverse
 tunnels.  It requests this service when it registers through the
 selected foreign agent.  At this time, and depending on how the
 mobile node wishes to deliver packets to the foreign agent, it also
 requests either the Direct or the Encapsulating Delivery Style
 (section 5).
 In the Direct Delivery Style, the mobile node designates the foreign
 agent as its default router and proceeds to send packets directly to
 the foreign agent, that is, without encapsulation.  The foreign agent
 intercepts them, and tunnels them to the home agent.
 In the Encapsulating Delivery Style, the mobile node encapsulates all
 its outgoing packets to the foreign agent.  The foreign agent
 decapsulates and re-tunnels them to the home agent, using the foreign
 agent's care-of address as the entry-point of this new tunnel.

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

3. New Packet Formats

3.1. Mobility Agent Advertisement Extension

  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      |    Length     |        Sequence Number        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Lifetime            |R|B|H|F|M|G|V|T|  reserved     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  zero or more Care-of Addresses               |
 |                              ...                              |
 The only change to the Mobility Agent Advertisement Extension [1] is
 the additional 'T' bit:
    T        Agent offers reverse tunneling service.
 A foreign agent that sets the 'T' bit MUST support the Direct
 Delivery Style. Encapsulating Delivery Style SHOULD be supported as
 well (section 5).
 Using this information, a mobile node is able to choose a foreign
 agent that supports reverse tunnels.  Notice that if a mobile node
 does not understand this bit, it simply ignores it as per [1].

3.2. Registration Request

 Reverse tunneling support is added directly into the Registration
 Request by using one of the "rsvd" bits.  If a foreign or home agent
 that does not support reverse tunnels receives a request with the 'T'
 bit set, the Registration Request fails.  This results in a
 registration denial (failure codes are specified in section 3.4).
 Home agents SHOULD NOT object to providing reverse tunnel support,
 because they "SHOULD be able to decapsulate and further deliver
 packets addressed to themselves, sent by a mobile node" [1].  In the
 case of topologically correct reverse tunnels, the packets are not
 sent by the mobile node as distinguished by its home address.
 Rather, the outermost (encapsulating) IP source address on such
 datagrams is the care-of address of the mobile node.
 In Registration Requests sent by a mobile node, the Time to Live
 field in the IP header MUST be set to 255.  This limits a denial of
 service attack in which malicious hosts send false Registration
 Requests (see Section 6).

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

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:
  1. 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.
  1. 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] RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001

 While the registration is in effect, a home agent MUST process each
 valid reverse tunneled packet (as determined by checks like the
 above) by decapsulating it, recovering the original packet, and then
 forwarding it on behalf of its sender (the mobile node) to the
 destination address (the correspondent host).

5. Mobile Node to Foreign Agent Delivery Styles

 This section specifies how the mobile node sends its data traffic via
 the foreign agent.  In all cases, the mobile node learns the foreign
 agent's link-layer address from the link-layer header in the agent
 advertisement.

5.1. Direct Delivery Style

 This delivery mechanism is very simple to implement at the mobile
 node, and uses small (non-encapsulated) packets on the link between
 the mobile node and the foreign agent (potentially a very slow link).
 However, it only supports reverse-tunneling of unicast packets, and
 does not allow selective reverse tunneling (section 5.4).

5.1.1. Packet Processing

 The mobile node MUST designate the foreign agent as its default
 router.  Not doing so will not guarantee encapsulation of all the
 mobile node's outgoing traffic, and defeats the purpose of the
 reverse tunnel.  The foreign agent MUST:
  1. detect packets sent by the mobile node, and
  1. modify its forwarding function to encapsulate them before

forwarding.

5.1.2. Packet Header Format and Fields

 This section shows the format of the packet headers used by the
 Direct Delivery style.  The formats shown assume IP in IP
 encapsulation [2].
 Packet format received by the foreign agent (Direct Delivery Style):
    IP fields:
      Source Address = mobile node's home address
      Destination Address = correspondent host's address
    Upper Layer Protocol
 Packet format forwarded by the foreign agent (Direct Delivery Style):

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

    IP fields (encapsulating header):
      Source Address = foreign agent's care-of address
      Destination Address = home agent's address
      Protocol field: 4 (IP in IP)
    IP fields (original header):
      Source Address = mobile node's home address
      Destination Address = correspondent host's address
    Upper Layer Protocol
 These fields of the encapsulating header MUST be chosen as follows:
    IP Source Address
       Copied from the Care-of Address field within the Registration
       Request.
    IP Destination Address
       Copied from the Home Agent field within the most recent
       successful Registration Reply.
    IP Protocol Field
       Default is 4 (IP in IP [2]), but other methods of encapsulation
       MAY be used as negotiated at registration time.

5.2. Encapsulating Delivery Style

 This mechanism requires that the mobile node implement encapsulation,
 and explicitly directs packets at the foreign agent by designating it
 as the destination address in a new outermost header.  Mobile nodes
 that wish to send either broadcast or multicast packets MUST use the
 Encapsulating Delivery Style.

5.2.1 Packet Processing

 The foreign agent does not modify its forwarding function.  Rather,
 it receives an encapsulated packet and after verifying that it was
 sent by the mobile node, it:
  1. decapsulates to recover the inner packet,
  1. re-encapsulates, and sends it to the home agent.
 If a foreign agent receives an un-encapsulated packet from a mobile
 node which had explicitly requested the Encapsulated Delivery Style,
 then the foreign agent MUST NOT reverse tunnel such a packet and
 rather MUST forward it using standard, IP routing mechanisms.

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

5.2.2. Packet Header Format and Fields

 This section shows the format of the packet headers used by the
 Encapsulating Delivery style.  The formats shown assume IP in IP
 encapsulation [2].
 Packet format received by the foreign agent (Encapsulating Delivery
 Style):
    IP fields (encapsulating header):
      Source Address = mobile node's home address
      Destination Address = foreign agent's address
      Protocol field: 4 (IP in IP)
    IP fields (original header):
      Source Address = mobile node's home address
      Destination Address = correspondent host's address
    Upper Layer Protocol
 The fields of the encapsulating IP header MUST be chosen as follows:
    IP Source Address
       The mobile node's home address.
    IP Destination Address
       The address of the agent as learned from the IP source address
       of the agent's most recent successful registration reply.
    IP Protocol Field
       Default is 4 (IP in IP [2]), but other methods of encapsulation
       MAY be used as negotiated at registration time.
 Packet format forwarded by the foreign agent (Encapsulating Delivery
 Style):
    IP fields (encapsulating header):
      Source Address = foreign agent's care-of address
      Destination Address = home agent's address
      Protocol field: 4 (IP in IP)
    IP fields (original header):
      Source Address = mobile node's home address
      Destination Address = correspondent host's address
    Upper Layer Protocol
 These fields of the encapsulating IP header MUST be chosen as
 follows:

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

    IP Source Address
       Copied from the Care-of Address field within the Registration
       Request.
    IP Destination Address
       Copied from the Home Agent field within the most recent
       successful Registration Reply.
    IP Protocol Field
       Default is 4 (IP in IP [2]), but other methods of encapsulation
       MAY be used as negotiated at registration time.

5.3. Support for Broadcast and Multicast Datagrams

 If a mobile node is operating with a co-located care-of address,
 broadcast and multicast datagrams are handled according to Sections
 4.3 and 4.4 of the Mobile IP specification [1].  Mobile nodes using a
 foreign agent care-of address MAY have their broadcast and multicast
 datagrams reverse-tunneled by the foreign agent.  However, any mobile
 nodes doing so MUST use the encapsulating delivery style.
 This delivers the datagram only to the foreign agent.  The latter
 decapsulates it and then processes it as any other packet from the
 mobile node, namely, by reverse tunneling it to the home agent.

5.4. Selective Reverse Tunneling

 Packets destined to local resources (for example, a nearby printer)
 might be unaffected by ingress filtering.  A mobile node with a co-
 located care-of address MAY optimize delivery of these packets by not
 reverse tunneling them.  On the other hand, a mobile node using a
 foreign agent care-of address MAY use this selective reverse
 tunneling capability by requesting the Encapsulating Delivery Style,
 and following these guidelines:
    Packets NOT meant to be reversed tunneled:
       Sent using the Direct Delivery style.  The foreign agent MUST
       process these packets as regular traffic:  they MAY be
       forwarded but MUST NOT be reverse tunneled to the home agent.

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

    Packets meant to be reverse tunneled:
       Sent using the Encapsulating Delivery style.  The foreign agent
       MUST process these packets as specified in section 5.2: they
       MUST be reverse tunneled to the home agent.

6. Security Considerations

 The extensions outlined in this document are subject to the security
 considerations outlined in the Mobile IP specification [1].
 Essentially, creation of both forward and reverse tunnels involves an
 authentication procedure, which reduces the risk for attack.

6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks

 Once the tunnel is set up, a malicious node could hijack it to inject
 packets into the network.  Reverse tunnels might exacerbate this
 problem, because upon reaching the tunnel exit point packets are
 forwarded beyond the local network.  This concern is also present in
 the Mobile IP specification, as it already dictates the use of
 reverse tunnels for certain applications.
 Unauthenticated exchanges involving the foreign agent allow a
 malicious node to pose as a valid mobile node and re-direct an
 existing reverse tunnel to another home agent, perhaps another
 malicious node.  The best way to protect against these attacks is by
 employing the Mobile-Foreign and Foreign-Home Authentication
 Extensions defined in [1].
 If the necessary mobility security associations are not available,
 this document introduces a mechanism to reduce the range and
 effectiveness of the attacks.  The mobile node MUST set to 255 the
 TTL value in the IP headers of Registration Requests sent to the
 foreign agent.  This prevents malicious nodes more than one hop away
 from posing as valid mobile nodes.  Additional codes for use in
 registration denials make those attacks that do occur easier to
 track.
 With the goal of further reducing the attacks the Mobile IP Working
 Group considered other mechanisms involving the use of
 unauthenticated state.  However, these introduce the possibilities of
 denial-of-service attacks.  The consensus was that this was too much
 of a trade-off for mechanisms that guarantee no more than weak (non-
 cryptographic) protection against attacks.

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

6.2. Ingress Filtering

 There has been some concern regarding the long-term effectiveness of
 reverse-tunneling in the presence of ingress filtering.  The
 conjecture is that network administrators will target reverse-
 tunneled packets (IP in IP encapsulated packets) for filtering.  The
 ingress filtering recommendation spells out why this is not the case
 [8]:
    Tracking the source of an attack is simplified when the source is
    more likely to be "valid."

6.3. Reverse Tunneling for Disparate Address Spaces

 There are security implications involved with the foreign agent's
 using link-layer information to select the proper reverse tunnel for
 mobile node packets (section A.3).  Unauthenticated link-layers allow
 a malicious mobile node to misuse another's existing reverse tunnel,
 and inject packets into the network.
 For this solution to be viable, the link-layer MUST securely
 authenticate traffic received by the foreign agent from the mobile
 nodes.  Unauthenticated link-layer technologies (for example shared
 ethernet) are not recommended to implement disparate address support.

7. IANA Considerations

 The Encapsulating Delivery Style extension defined in section 3.3 is
 a Mobile IP registration extension as defined in [1].  IANA assigned
 the value of 130 for this purpose at the time of the publication of
 RFC 2344.
 The Code values defined in section 3.4 are error codes as defined in
 [1].  They correspond to error values associated with rejection by
 the home and foreign agents.  At the time of the publication of RFC
 2344, IANA assigned codes 74-76 for the foreign agent rejections and
 codes 137-139 for the home agent rejections.  The code for 'delivery
 style not supported' has been assigned a value of 79 by the IANA for
 this purpose.

8. Acknowledgements

 The encapsulating style of delivery was proposed by Charlie Perkins.
 Jim Solomon has been instrumental in shaping this document into its
 present form.  Thanks to Samita Chakrabarti for helpful comments on
 disparate address space support, and for most of the text in section
 A.4.

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

References

 [1]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
 [2]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
      1996.
 [3]  Computer Emergency Response Team (CERT), "IP Spoofing Attacks
      and Hijacked Terminal Connections", CA-95:01, January 1995.
      Available via anonymous ftp from info.cert.org in
      /pub/cert_advisories.
 [4]  Perkins, C. and D. Johnson, "Route Optimization in Mobile IP",
      Work in Progress.
 [5]  Manuel Rodriguez, private communication, August 1995.
 [6]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
      November 1998.
 [7]  Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406,
      November 1998.
 [8]  Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
      Denial of Service Attacks which employ IP Source Address
      Spoofing", RFC 2267, January 1998.
 [9]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
      "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
 [11] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
      2486, January 1999.
 [12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and
      E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
      1918, February 1996.
 [13] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC
      2890, August 2000.

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

Editor and Chair Addresses

 Questions about this document may be directed at:
 Gabriel E. Montenegro
 Sun Microsystems
 Laboratories, Europe
 29, chemin du Vieux Chene
 38240 Meylan
 FRANCE
 Phone: +33 476 18 80 45
 EMail: gab@sun.com
 The working group can be contacted via the current chairs:
 Basavaraj Patil
 Nokia Networks
 6000 Connection Drive
 Irving, TX 75039
 USA
 Phone:  +1 972-894-6709
 Fax :   +1 972-894-5349
 EMail:  Raj.Patil@nokia.com
 Phil Roberts
 Motorola
 1501 West Shure Drive
 Arlington Heights, IL 60004
 USA
 Phone:  +1 847-632-3148
 EMail:  QA3445@email.mot.com

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

Appendix A: Disparate Address Space Support

 Mobile IP [1] assumes that all the entities involved (mobile
 node, foreign agent and home agent) have addresses within the
 same globally routable address space.  In many deployment
 scenarios, when a mobile node leaves its home network it may
 wander into a region where its home address is not routable or
 known by the local routing fabric.  Similarly, the IP addresses
 of the foreign agent and the home agent may belong to disparate
 address spaces, which precludes their exchanging registration
 protocol messages directly.  These issues are possible
 particularly if the entities involved use addresses from the
 ranges specified in RFC1918 [12] to support private networks.
 Accurately speaking, the use of private addresses is not the
 only cause.  It may, in fact, be the most common, but the root of
 the problem lies in the use of disparate address spaces.  For
 example, corporations often have several properly allocated
 address ranges.  They typically advertise reachability to only a
 subset of those ranges, leaving the others for use exclusively
 within the corporate network.  Since these ranges are not
 routable in the general Internet, their use leads to the same
 problems encountered with "private" addresses, even though they
 are not taken from the ranges specified in RFC1918.
 Even if the mobile node, home agent and foreign agent all reside
 within the same address space, problems may arise if the
 correspondent node does not.  However, this problem is not
 specific to Mobile IP, and is beyond the scope of this
 document.  The next section limits even further the scope of the
 issues relevant to this document.  A subsequent section explains
 how reverse tunneling may be used to tackle them.

A.1. Scope of the Reverse Tunneling Solution

 Reverse tunneling (as defined in this document) may be used to
 cope with disparate address spaces, within the following
 constraints:
  1. There are no provisions to solve the case in which the

correspondent node and the mobile node are in disparate

       address spaces.  This limits the scope of the problem to
       only those issues specific to Mobile IP.
  1. The foreign agent and the home agent are directly reachable

to each other by virtue of residing in the same address

       space.  This limits the scope of the problem to only the
       simplest of cases.  This also implies that the registration

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

       protocol itself has a direct path between the foreign
       agent and the home agent, and, in this respect, is not
       affected by disparate address spaces.  This restriction
       also applies to mobile nodes operating with a co-located
       care-of address.  In this case, reverse tunneling is a
       complete and elegant solution.
  1. There are no additional protocol elements beyond those

defined by Mobile IP [1] and reverse tunneling. In

       particular, additional extensions to the registration
       requests or replies, or additional bits in the
       header--although potentially useful--are outside the scope
       of this document.
 In spite of the limitations, reverse tunneling may be used to
 solve the most common issues.  The range of problems that can be
 solved are best understood by looking at some simple diagrams:
 Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES
    Mc               Fa  Fb              Hb  Hc             Yc
 [MN]-----------------[FA]----------------[HA]---------------[Y]
      Addr space A          Addr space B       Addr space C
 In this diagram, there are three disparate address spaces:  A, B and
 C.  The home agent (HA) has one address each on address spaces B and
 C, and the foreign agent (FA), on address spaces A and B.  The mobile
 node's (MN) has a permanent address, Mc, within address space C.
 In the most common scenario both A and C are "private" address
 spaces, and B is the public Internet.
 Suppose MN sends a packet to correspondent node (Y) in its home
 network.  Presumably, MN has no difficulties delivering this packet
 to the FA, because it does so using layer 2 mechanisms.  Somehow, the
 FA must realize that this packet must be reverse tunneled, and it
 must fetch the proper binding to do so.  Possible mechanisms are
 outlined in section A.3.
 However, once the packet is in address space B it becomes non-
 routable.  Note that ingress filtering only exacerbates the problem,
 because it adds a requirement of topological significance to the
 source IP address in addition to the that of the destination address.
 As Mobile IP matures, others entities may be defined (for example,
 AAA servers).  Their addition places even more requirements on the
 address spaces in use.

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

 Reverse tunneling adds a topologically significant IP header to the
 packet (source IP address of Fb, destination of Hb) during its
 transit within address space B.  Assuming IP in IP encapsulation
 (although others, like GRE are also possible), this is what the
 packet looks like:
    Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA
                      +-----------------+
                      |        +-------+|
                      | Fb->Hb | Mc->Yc||
                      |        +-------+|
                      +--------+--------+
 HA receives this packet, recovers the original packet, and since it
 is cognizant of address space C, delivers it to the appropriate
 interface.
 Of course, for this to happen, the care-of address registered by the
 MN is not the usual Fa, but Fb.  How this happens is outside the
 scope of this document.  Some possible mechanisms are:
  1. FA recognizes mobile nodes whose addresses fall within the

private address ranges specified by RFC1918. In this case, the

       foreign agent could force the use of Fb as the care-of address,
       perhaps by rejecting the initial registration request with an
       appropriate error message and supplemental information.
  1. FA could be configured to always advertise Fb as long as H→Fb

and Fb→H are guaranteed to be valid forward and reverse

       tunnels, respectively, for all values of H.  Here, H is the
       address of any home agent whose mobile nodes may register via
       FA.
  1. FA could indicate that it supports disparate address spaces via

a currently undefined 'P' bit in its advertisements, and an

       indication of the relevant address space for any or all of its
       care-of addressed by including an NAI [11] or a realm indicator
       (perhaps a variant of the NAI).  Alternatively, mobile nodes so
       configured could solicit the NAI or realm indicator information
       in response to advertisements with the 'P' bit set.
 Additionally, the mobile node needs to supply the appropriate address
 for its home agent: Hb instead of the usual Hc.  How this happens is
 outside the scope of this document.  Some possible mechanisms are:
  1. This determination could be triggered in response to using the

foreign agent's Fb as the care-of address.

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

  1. The mobile node could always use Hb as its home agent address,

specially (1) if Hb is routable within address space C, or (2)

       if MN is certain never to be at home (in some configurations,
       the mobile nodes are always roaming).
  1. The mobile node could be configured with different home agent

addresses and their corresponding address space (perhaps

       indicated via an NAI [11] or a variant of it).
 Another major issue introduced by private addresses is that of two or
 more mobile nodes with the same numeric IP address:
    Figure A3: MOBILE NODES WITH CONFLICTING ADDRESSES
             Mc=M             H1b     H1c
        [MN1]-------+      +----[HA1]----+---------
                    |      |             | Address
                    |      |             | space C
       Address      |      |   Address   +----------
       Space       Fa-[FA]-Fb  Space
       A            |      |   B         +---------
                    |      |             | Address
                    |      |             | space D
        [MN2]-------+      +----[HA2]----+---------
             Md=M            H2b     H2d
 Suppose there are two address spaces A and B, and a foreign agent
 (FA) with interfaces on both.  There are two home agents (HA1 and
 HA2) in address space B, with addresses H1b and H2b, respectively.
 Each of the home agents has an interface in a private address space
 in addition to address space B: HA1 has H1c on C, and HA2 has H2d on
 D.  MN1 and MN2 are two mobile nodes with home addresses Mc and Md,
 corresponding to address space C and D, respectively.
 If Mc and Md are private addresses as defined in RFC1918, they may be
 numerically equivalent (both equal to M).  Because of this, the
 foreign agent can no longer rely on only the mobile node's home
 address to disambiguate amongst its different bindings.

A.2. Terminating Forward Tunnels at the Foreign Agent

 In figure A1, suppose the correspondent node Y sends a packet to the
 mobile node at address Mc.  The packet is intercepted by the home
 agent at Hc and tunneled towards the mobile node via address Fb.

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

 Once the packet reaches FA (via address Fb), the foreign agent must
 identify which of its registered mobile nodes is the ultimate
 destination for the internal packet.  In order to do so, it needs to
 identify the proper binding via a tuple guaranteed to be unique among
 all of its mobile nodes.
 The unique tuple sufficient for demultiplexing IP in IP packets
 [IPIP] (protocol 4) is:
  1. destination IP address of the encapsulated (internal) header
       This is mobile node MN's home address (Mc in the above
       example).  At first glance, it seems like this is unique among
       all mobile nodes, but as mentioned above, with private
       addresses another mobile may have an address Md numerically
       equivalent to Mc.
  1. source IP address of the external header
       This, the remote end of the tunnel, is Hb in the above example.
  1. destination IP address of the external header
       This, the local end of the tunnel, is Fb in the above example.
 The three values above are learned from a successful registration and
 are the mobile node's home address, the home agent's address and the
 care-of address.  Thus, it is possible to identify the right binding.
 Once FA identifies the ultimate destination of the packet, Mc, it
 delivers the internal packet using link layer mechanisms.
 GRE packets [10] (protocol 47) are only handled if their Protocol
 Type field has a value of 0x800 (other values are outside the scope
 of this document), and are demultiplexed based on the same tuple as
 IP in IP packets.  In GRE terminology, the tuple is:
  1. destination IP address of the payload (internal) packet
  1. source IP address of the delivery (external) packet
  1. destination IP address of the delivery (external) packet
 Notice that the Routing, Sequence Number, Strict Source Route and Key
 fields have been deprecated from GRE [10].  However, a separate
 document specifies their use [13].

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

 The above tuples work for IP-in-IP or GRE encapsulation, and assume
 that the inner packet is in the clear.  Encapsulations which encrypt
 the inner packet header are outside the scope of this document.

A.3. Initiating Reverse Tunnels at the Foreign Agent

 In figure A3, suppose mobile node M1 sends a packet to a
 correspondent node in its home address space, C, and mobile node M2
 sends a packet to a correspondent node in its home address space, D.
 At FA, the source addresses for both packets will be seen as M, thus
 this is not sufficient information.  The unique tuple required to
 identify the proper binding is:
  1. link-layer information related to the MN
       This may be in the form of a MAC address, a PPP session (or
       incoming interface) or channel coding for a digital cellular
       service.  Device ID's can also be used in this context.
  1. source IP address of the IP header.
       As was pointed out, this by itself is not guaranteed to be
       unique.
 This information must be established and recorded at registration
 time.  The above items are sufficient for the foreign agent to select
 the proper binding to use.  This, in turn, produces the address of
 the home agent, and the reverse tunneling options negotiated during
 the registration process.  The foreign agent can now proceed with
 reverse tunneling.

A.4. Limited Private Address Scenario

 The Limited Private Address Scenario (LPAS) has received much
 attention from the cellular wireless industry, so it is useful to
 define it and to clarify what its requirements are.
 LPAS is a subset of the disparate address space scenario discussed in
 this appendix.  This section explains how LPAS could be deployed
 given the current state of the Mobile IP specifications.

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

         Figure A4: EXAMPLE PRIVATE ADDRESS SCENARIO
      10.10.1.2
     +----+                IF1=COA1+-------+    HAA2 +-----+
     | MN1|------------------------|  FA   |---------| HA2 |
     +----+           +------------|       |         +-----+
                      |    IF2=COA2+-------+
                  +---+               |
                  |                   |
               +-----+                |
               | MN2 |                |
               +-----+                |
                10.10.1.2             |
                                      | HAA1
                                  +------+
                                  | HA1  |
                                  +------+
 The above figure presents a very simple scenario in which private
 addresses are used.  Here, "private addresses" are strictly those
 defined in RFC 1918 [12].  In this deployment scenario, the only
 entities that have private addresses are the mobile nodes.  Foreign
 agent and home agent addresses are publicly routable on the general
 Internet.  More specifically, the care-of addresses advertised by the
 foreign agents (COA1 and COA2 in Figure A4) and the home agent
 addresses used by mobile nodes in registration requests (HAA1 and
 HAA2 in Figure A4) are publicly routable on the general Internet.  As
 a consequence, any Mobile IP tunnels can be established between any
 home agent home address and any foreign agent care-of address.
 Also, note that two different mobile nodes (MN1 and MN2) with the
 same private address (10.10.1.2) are visiting the same foreign agent
 FA.  This is supported as long as MN1 and MN2 are serviced by
 different home agents.  Hence, from any given home agent's
 perspective, each mobile node has a unique IP address, even if it
 happens to be a private address as per RFC 1918.
 Operation in the presence of route optimization [4] is outside the
 scope of this document.
 Requirements for the above private address scenario:
    Mobile node requirements:
       Mobile nodes intending to use private addresses with Mobile IP
       MUST set the 'T' bit and employ reverse tunneling.  Mobile
       node's private addresses within a given address space MUST be
       unique.  Thus two mobile nodes belonging to a single home agent

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

       cannot have the same private addresses.  Thus, when receiving
       or sending tunneled traffic for a mobile node, the tunnel
       endpoints are used to disambiguate amongst conflicting mobile
       node addresses.
       If the mobile node happens to register with multiple home
       agents simultaneously through the same foreign agent, there
       must be some link-layer information that is distinct for each
       mobile node.  If no such distinct link-layer information is
       available, the mobile nodes MUST use unique address.
    Foreign agent requirements:
       All advertising interfaces of the foreign agent MUST have
       publicly routable care-of address.  Thus, a mobile node with a
       private address visits the foreign agent only in its publicly
       routable network.
       Foreign agents MUST support reverse tunneling in order to
       support private addressed mobile nodes.  If a foreign agent
       receives a registration request from a mobile node with a
       private address, and the mobile node has not set the 'T' bit,
       the foreign agent SHOULD reject it.
       When delivering packets to or receiving packets from mobile
       nodes, foreign agents MUST disambiguate among mobile node with
       conflicting private addresses by using link-layer information
       as mentioned previously (Appendix section A.2 and A.3).  A
       foreign agent in absence of route optimization, should make
       sure that two mobile nodes visiting the same foreign agent
       corresponds with each other through their respective home
       agents.
       If a foreign agent supports reverse tunneling, then it MUST
       support the simple scenario of private address support
       described in this section.
    Home agent requirements:
       Any home agent address used by mobile nodes in registration
       request MUST be a publicly routable address.  Home agents will
       not support overlapping private home addresses, thus each
       private home address of a mobile node registered with a home
       agent is unique.  When the 'T' bit is set in the registration
       request from the mobile node, the home agent MUST recognize and
       accept registration request from mobile nodes with private

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

       addresses. Also, the home agent SHOULD be able to assign
       private addresses out of its address pool to mobile nodes for
       use as home addresses.  This does not contravene home agent
       processing in section 3.8 of [1].

Appendix B: Changes from RFC2344

 This section lists the changes with respect to the previous version
 of this document (RFC2344).
  1. Added Appendix A on support for Disparate Addresses spaces and

private addresses.

  1. Added the corresponding section (6.3) under 'Security

Considerations'.

  1. Made Encapsulating Delivery Support optional by demoting from

a MUST to a should. This also required defining a new error

   code 79 (assigned by IANA).
  1. Mentioned the possibility of an admissible authentication

extension which may be different from the Mobile-Home

   authentication extension.
  1. An IANA considerations section was added.

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

Full Copyright Statement

 Copyright (C) The Internet Society (2001).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Montenegro Standards Track [Page 30]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3024.txt · Last modified: 2001/01/12 19:47 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki