doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc3024.txt b/doc/rfc/rfc3024.txt
new file mode 100644
index 0000000..b0cf429
--- /dev/null
+++ b/doc/rfc/rfc3024.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+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:
+
+      -  Mobile routers: reverse tunnels obviate the need for recursive
+         tunneling [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].
+
+      -  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:
+
+      -  There are no intervening firewalls along the path of the
+         tunneled packets.
+
+      -  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
+
+         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]
+
+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:
+
+      -  detect packets sent by the mobile node, and
+
+      -  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:
+
+      -  decapsulates to recover the inner packet,
+
+      -  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:
+
+      -  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.
+
+      -  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.
+
+      -  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:
+
+      -  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.
+
+      -  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.
+
+      -  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:
+
+      -  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
+
+
+      -  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).
+
+      -  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:
+
+      -  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.
+
+      -  source IP address of the external header
+
+         This, the remote end of the tunnel, is Hb in the above example.
+
+      -  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:
+
+      -  destination IP address of the payload (internal) packet
+
+      -  source IP address of the delivery (external) packet
+
+      -  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:
+
+      -  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.
+
+      -  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).
+
+   - Added Appendix A on support for Disparate Addresses spaces and
+     private addresses.
+
+   - Added the corresponding section (6.3) under 'Security
+     Considerations'.
+
+   - 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).
+
+   - Mentioned the possibility of an admissible authentication
+     extension which may be different from the Mobile-Home
+     authentication extension.
+
+   - 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]
+