doc: Add RFC documents

1 files changed, 5603 insertions, 0 deletions

diff --git a/doc/rfc/rfc5944.txt b/doc/rfc/rfc5944.txt
new file mode 100644
index 0000000..eb9756d
--- /dev/null
+++ b/doc/rfc/rfc5944.txt
@@ -0,0 +1,5603 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   C. Perkins, Ed.
+Request for Comments: 5944                                 WiChorus Inc.
+Obsoletes: 3344                                            November 2010
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                 IP Mobility Support for IPv4, Revised
+
+Abstract
+
+   This document specifies protocol enhancements that allow transparent
+   routing of IP datagrams to mobile nodes in the Internet.  Each mobile
+   node is always identified by its home address, regardless of its
+   current point of attachment to the Internet.  While situated away
+   from its home, a mobile node is also associated with a care-of
+   address, which provides information about its current point of
+   attachment to the Internet.  The protocol provides for registering
+   the care-of address with a home agent.  The home agent sends
+   datagrams destined for the mobile node through a tunnel to the care-
+   of address.  After arriving at the end of the tunnel, each datagram
+   is then delivered to the mobile node.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5944.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                    [Page 1]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                    [Page 2]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................5
+      1.1. Protocol Requirements ......................................5
+      1.2. Goals ......................................................6
+      1.3. Assumptions ................................................6
+      1.4. Applicability ..............................................6
+      1.5. New Architectural Entities .................................7
+      1.6. Terminology ................................................7
+      1.7. Protocol Overview .........................................11
+      1.8. Message Format and Protocol Extensibility .................14
+      1.9. Type-Length-Value Extension Format for Mobile IP
+           Extensions ................................................16
+      1.10. Long Extension Format ....................................17
+      1.11. Short Extension Format ...................................18
+   2. Agent Discovery ................................................18
+      2.1. Agent Advertisement .......................................19
+           2.1.1. Mobility Agent Advertisement Extension .............21
+           2.1.2. Prefix-Lengths Extension ...........................23
+           2.1.3. One-Byte Padding Extension .........................24
+      2.2. Agent Solicitation ........................................24
+      2.3. Foreign Agent and Home Agent Considerations ...............24
+           2.3.1. Advertised Router Addresses ........................26
+           2.3.2. Sequence Numbers and Rollover Handling .............26
+      2.4. Mobile Node Considerations ................................26
+           2.4.1. Registration Required ..............................28
+           2.4.2. Move Detection .....................................28
+           2.4.3. Returning Home .....................................29
+           2.4.4. Sequence Numbers and Rollover Handling .............29
+   3. Registration ...................................................29
+      3.1. Registration Overview .....................................30
+      3.2. Authentication ............................................31
+      3.3. Registration Request ......................................32
+      3.4. Registration Reply ........................................34
+      3.5. Registration Extensions ...................................38
+           3.5.1. Computing Authentication Extension Values ..........38
+           3.5.2. Mobile-Home Authentication Extension ...............39
+           3.5.3. Mobile-Foreign Authentication Extension ............40
+           3.5.4. Foreign-Home Authentication Extension ..............40
+      3.6. Mobile Node Considerations ................................41
+           3.6.1. Sending Registration Requests ......................43
+           3.6.2. Receiving Registration Replies .....................47
+           3.6.3. Registration Retransmission ........................50
+      3.7. Foreign Agent Considerations ..............................50
+           3.7.1. Configuration and Registration Tables ..............51
+           3.7.2. Receiving Registration Requests ....................52
+           3.7.3. Receiving Registration Replies .....................56
+
+
+
+
+Perkins                      Standards Track                    [Page 3]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      3.8. Home Agent Considerations .................................58
+           3.8.1. Configuration and Registration Tables ..............58
+           3.8.2. Receiving Registration Requests ....................59
+           3.8.3. Sending Registration Replies .......................64
+   4. Routing Considerations .........................................66
+      4.1. Encapsulation Types .......................................67
+      4.2. Unicast Datagram Routing ..................................67
+           4.2.1. Mobile Node Considerations .........................67
+           4.2.2. Foreign Agent Considerations .......................68
+           4.2.3. Home Agent Considerations ..........................69
+      4.3. Broadcast Datagrams .......................................70
+      4.4. Multicast Datagram Routing ................................71
+      4.5. Mobile Routers ............................................72
+      4.6. ARP, Proxy ARP, and Gratuitous ARP ........................74
+   5. Security Considerations ........................................77
+      5.1. Message Authentication Codes ..............................77
+      5.2. Areas of Security Concern in This Protocol ................78
+      5.3. Key Management ............................................78
+      5.4. Picking Good Random Numbers ...............................78
+      5.5. Privacy ...................................................79
+      5.6. Ingress Filtering .........................................79
+      5.7. Replay Protection for Registration Requests ...............79
+           5.7.1. Replay Protection Using Timestamps .................80
+           5.7.2. Replay Protection Using Nonces .....................81
+   6. IANA Considerations ............................................82
+      6.1. Mobile IP Message Types ...................................82
+      6.2. Extensions to RFC 1256 Router Advertisement Messages ......83
+      6.3. Extensions to Mobile IP Registration Messages .............83
+      6.4. Code Values for Mobile IP Registration Reply Messages .....84
+   7. Acknowledgments ................................................84
+   8. References .....................................................86
+      8.1. Normative References ......................................86
+      8.2. Informative References ....................................87
+   Appendix A. Link-Layer Considerations .............................90
+   Appendix B. TCP Considerations ....................................90
+      B.1. TCP Timers ................................................90
+      B.2. TCP Congestion Management .................................91
+   Appendix C.  Example Scenarios ....................................92
+      C.1. Registering with a Foreign Agent Care-of Address ..........92
+      C.2. Registering with a Co-Located Care-of Address .............93
+      C.3. Deregistration ............................................94
+   Appendix D. Applicability of Prefix-Lengths Extension .............94
+   Appendix E. Interoperability Considerations .......................95
+   Appendix F. Changes since RFC 3344 ................................96
+   Appendix G. Example Messages ......................................98
+      G.1. Example ICMP Agent Advertisement Message Format ...........98
+      G.2. Example Registration Request Message Format ...............99
+      G.3. Example Registration Reply Message Format ................100
+
+
+
+Perkins                      Standards Track                    [Page 4]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+1.  Introduction
+
+   IP version 4 assumes that a node's IP address uniquely identifies the
+   node's point of attachment to the Internet.  Therefore, a node must
+   be located on the network indicated by its IP address in order to
+   receive datagrams destined to it; otherwise, datagrams destined to
+   the node would be undeliverable.  For a node to change its point of
+   attachment without losing its ability to communicate, currently one
+   of the two following mechanisms must typically be employed:
+
+   o  the node must change its IP address whenever it changes its point
+      of attachment, or
+
+   o  host-specific routes must be propagated throughout much of the
+      Internet routing fabric.
+
+   Both of these alternatives are often unacceptable.  The first makes
+   it impossible for a node to maintain transport and higher-layer
+   connections when the node changes location.  The second has obvious
+   and severe scaling problems, especially relevant considering the
+   explosive growth in sales of notebook (mobile) computers.
+
+   A new, scalable mechanism is required for accommodating node mobility
+   within the Internet.  This document defines such a mechanism, which
+   enables nodes to change their point of attachment to the Internet
+   without changing their IP address.
+
+   Changes between this revised specification for Mobile IP and the
+   original specifications (see [44], [14], [15], [20], [4], and [50])
+   are detailed in Appendix F.
+
+1.1.  Protocol Requirements
+
+   A mobile node must be able to communicate with other nodes after
+   changing its link-layer point of attachment to the Internet, yet
+   without changing its IP address.
+
+   A mobile node must be able to communicate with other nodes that do
+   not implement these mobility functions.  No protocol enhancements are
+   required in hosts or routers that are not acting as any of the new
+   architectural entities introduced in Section 1.5.
+
+   All messages used to update another node as to the location of a
+   mobile node must be authenticated in order to protect against remote
+   redirection attacks.
+
+
+
+
+
+
+Perkins                      Standards Track                    [Page 5]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+1.2.  Goals
+
+   The link by which a mobile node is directly attached to the Internet
+   may often be a wireless link.  This link may thus have a
+   substantially lower bandwidth and higher error rate than traditional
+   wired networks.  Moreover, mobile nodes are likely to be battery
+   powered, and minimizing power consumption is important.  Therefore,
+   the number of administrative messages sent over the link by which a
+   mobile node is directly attached to the Internet should be minimized,
+   and the size of these messages should be kept as small as is
+   reasonably possible.
+
+1.3.  Assumptions
+
+   The protocols defined in this document place no additional
+   constraints on the assignment of IP addresses.  That is, a mobile
+   node can be assigned an IP address by the organization that owns the
+   machine.
+
+   This protocol assumes that mobile nodes will generally not change
+   their point of attachment to the Internet more frequently than once
+   per second.
+
+   This protocol assumes that IP unicast datagrams are routed based on
+   the Destination Address in the datagram header (and not, for example,
+   by source address).
+
+1.4.  Applicability
+
+   Mobile IP is intended to enable nodes to move from one IP subnet to
+   another.  It is just as suitable for mobility across homogeneous
+   media as it is for mobility across heterogeneous media.  That is,
+   Mobile IP facilitates node movement from one Ethernet segment to
+   another, as well as from an Ethernet segment to a wireless LAN, as
+   long as the mobile node's IP address remains the same after such a
+   movement.
+
+   One can think of Mobile IP as solving the "macro" mobility management
+   problem.  It is less well suited for more "micro" mobility management
+   applications -- for example, handoff amongst wireless transceivers,
+   each of which covers only a very small geographic area.  As long as
+   node movement does not occur between points of attachment on
+   different IP subnets, link-layer mechanisms for mobility (i.e., link-
+   layer handoff) may offer faster convergence and far less overhead
+   than Mobile IP.
+
+
+
+
+
+
+Perkins                      Standards Track                    [Page 6]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+1.5.  New Architectural Entities
+
+   Mobile IP introduces the following new functional entities:
+
+   Mobile Node
+
+      A host or router that changes its point of attachment from one
+      network or subnetwork to another.  A mobile node may change its
+      location without changing its IP address; it may continue to
+      communicate with other Internet nodes at any location using its
+      (constant) IP address, assuming link-layer connectivity to a point
+      of attachment is available.
+
+   Home Agent
+
+      A router on a mobile node's home network that tunnels datagrams
+      for delivery to the mobile node when it is away from home, and
+      maintains current location information for the mobile node.
+
+   Foreign Agent
+
+      A router on a mobile node's visited network that provides routing
+      services to the mobile node while registered.  The foreign agent
+      detunnels and delivers to the mobile node datagrams that were
+      tunneled by the mobile node's home agent.  For datagrams sent by a
+      mobile node, the foreign agent may serve as a default router for
+      registered mobile nodes.
+
+   A mobile node is given a long-term IP address on a home network.
+   This home address is administered in the same way that a "permanent"
+   IP address is provided to a stationary host.  When away from its home
+   network, a "care-of address" is associated with the mobile node and
+   reflects the mobile node's current point of attachment.  The mobile
+   node uses its home address as the source address of all IP datagrams
+   that it sends, except where otherwise described in this document for
+   datagrams sent for certain mobility management functions (e.g., as in
+   Section 3.6.1.1).
+
+1.6.  Terminology
+
+   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 [1].
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                    [Page 7]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   In addition, this document frequently uses the following terms:
+
+   Authorization-Enabling Extension
+
+      An authentication that makes a (registration) message acceptable
+      to the ultimate recipient of the registration message.  An
+      authorization-enabling extension MUST contain a Security Parameter
+      Index (SPI).
+
+      In this document, all uses of authorization-enabling extension
+      refer to authentication extensions that enable the Registration
+      Request message to be acceptable to the home agent.  Using
+      additional protocol structures specified outside of this document,
+      it may be possible for the mobile node to provide authentication
+      of its registration to the home agent, by way of another
+      authenticating entity within the network that is acceptable to the
+      home agent (for example, see RFC 2794 [2]).
+
+   Agent Advertisement
+
+      An advertisement message constructed by attaching a special
+      Extension to a Router Advertisement [5] message.
+
+   Authentication
+
+      The process of verifying (using cryptographic techniques, for all
+      applications in this specification) the identity of the originator
+      of a message.
+
+   Care-of Address
+
+      The termination point of a tunnel toward a mobile node, for
+      datagrams forwarded to the mobile node while it is away from home.
+      The protocol can use two different types of care-of address: a
+      "foreign agent care-of address" is an address of a foreign agent
+      with which the mobile node is registered, and a "co-located care-
+      of address" is an externally obtained local address that the
+      mobile node has associated with one of its own network interfaces.
+
+   Correspondent Node
+
+      A peer with which a mobile node is communicating.  A correspondent
+      node may be either mobile or stationary.
+
+   Foreign Network
+
+      Any network other than the mobile node's home network.
+
+
+
+
+Perkins                      Standards Track                    [Page 8]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   Gratuitous ARP
+
+      An Address Resolution Protocol (ARP) packet sent by a node in
+      order to spontaneously cause other nodes to update an entry in
+      their ARP cache [45].  See Section 4.6.
+
+   Home Address
+
+      An IP address that is assigned for an extended period of time to a
+      mobile node.  It remains unchanged regardless of where the node is
+      attached to the Internet.
+
+   Home Network
+
+      A network, possibly virtual, having a network prefix matching that
+      of a mobile node's home address.  Note that standard IP routing
+      mechanisms will deliver datagrams destined to a mobile node's home
+      address to the mobile node's home network.
+
+   Link
+
+      A facility or medium over which nodes can communicate at the link
+      layer.  A link underlies the network layer.
+
+   Link-Layer Address
+
+      The address used to identify an endpoint of some communication
+      over a physical link.  Typically, the link-layer address is an
+      interface's Media Access Control (MAC) address.
+
+   Mobility Agent
+
+      Either a home agent or a foreign agent.
+
+   Mobility Binding
+
+      The association of a home address with a care-of address, along
+      with the remaining Lifetime of that association.
+
+   Mobility Security Association
+
+      A collection of security contexts, between a pair of nodes, which
+      may be applied to Mobile IP protocol messages exchanged between
+      them.  Each context indicates an authentication algorithm and mode
+      (Section 5.1), a secret (a shared key, or appropriate public/
+      private key pair), and a style of replay protection in use
+      (Section 5.7).
+
+
+
+
+Perkins                      Standards Track                    [Page 9]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   Node
+
+      A host or a router.
+
+   Nonce
+
+      A randomly chosen value, different from previous choices, inserted
+      in a message to protect against replays.
+
+   Security Parameter Index (SPI)
+
+      An index identifying a security context between a pair of nodes,
+      among the contexts available in the Mobility Security Association.
+      SPI values 0 through 255 are reserved and MUST NOT be used in any
+      Mobility Security Association.
+
+   Tunnel
+
+      The path followed by a datagram while it is encapsulated.  The
+      model is that, while it is encapsulated, a datagram is routed to a
+      knowledgeable decapsulating agent, which decapsulates the datagram
+      and then correctly delivers it to its ultimate destination.
+
+   Virtual Network
+
+      A network with no physical instantiation beyond a router (with a
+      physical network interface on another network).  The router (e.g.,
+      a home agent) generally advertises reachability to the virtual
+      network using conventional routing protocols.
+
+   Visited Network
+
+      A network other than a mobile node's home network, to which the
+      mobile node is currently connected.
+
+   Visitor List
+
+      The list of mobile nodes visiting a foreign agent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 10]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+1.7.  Protocol Overview
+
+   The following support services are defined for Mobile IP:
+
+   Agent Discovery
+
+      Home agents and foreign agents may advertise their availability on
+      each link for which they provide service.  A newly arrived mobile
+      node can send a solicitation on the link to learn if any
+      prospective agents are present.
+
+   Registration
+
+      When the mobile node is away from home, it registers its care-of
+      address with its home agent.  Depending on its method of
+      attachment, the mobile node will register either directly with its
+      home agent, or through a foreign agent that forwards the
+      registration to the home agent.
+
+   Silently Discard
+
+      The implementation discards the datagram without further
+      processing, and without indicating an error to the sender.  The
+      implementation SHOULD provide the capability of logging the error,
+      including the contents of the discarded datagram, and SHOULD
+      record the event in a statistics counter.
+
+   The following steps provide a rough outline of operation of the
+   Mobile IP protocol:
+
+   o  Mobility agents (i.e., foreign agents and home agents) advertise
+      their presence via Agent Advertisement messages (Section 2).  A
+      mobile node may optionally solicit an Agent Advertisement message
+      from any locally attached mobility agents through an Agent
+      Solicitation message.
+
+   o  A mobile node receives these Agent Advertisements and determines
+      whether it is on its home network or a foreign network.
+
+   o  When the mobile node detects that it is located on its home
+      network, it operates without mobility services.  If returning to
+      its home network from being registered elsewhere, the mobile node
+      deregisters with its home agent, through exchange of a
+      Registration Request and Registration Reply message with it.
+
+   o  When a mobile node detects that it has moved to a foreign network,
+      it obtains a care-of address on the foreign network.  The care-of
+      address can either be determined from a foreign agent's
+
+
+
+Perkins                      Standards Track                   [Page 11]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      advertisements (a foreign agent care-of address), or by some
+      external assignment mechanism such as DHCP [34] (a co-located
+      care-of address).
+
+   o  The mobile node operating away from home then registers its new
+      care-of address with its home agent through exchange of a
+      Registration Request and Registration Reply message with the home
+      agent, possibly via a foreign agent (Section 3).
+
+   o  Datagrams sent to the mobile node's home address are intercepted
+      by its home agent, tunneled by the home agent to the mobile node's
+      care-of address, received at the tunnel endpoint (either at a
+      foreign agent or at the mobile node itself), and finally delivered
+      to the mobile node (Section 4.2.3).
+
+   o  In the reverse direction, datagrams sent by the mobile node are
+      generally delivered to their destination using standard IP routing
+      mechanisms, not necessarily passing through the home agent.
+
+   When away from home, Mobile IP uses protocol tunneling to hide a
+   mobile node's home address from intervening routers between its home
+   network and its current location.  The tunnel terminates at the
+   mobile node's care-of address.  The care-of address must be an
+   address to which datagrams can be delivered via conventional IP
+   routing.  At the care-of address, the original datagram is removed
+   from the tunnel and delivered to the mobile node.
+
+   Mobile IP provides two alternative modes for the acquisition of a
+   care-of address:
+
+   a.  A "foreign agent care-of address" is a care-of address provided
+       by a foreign agent through its Agent Advertisement messages.  In
+       this case, the care-of address is an IP address of the foreign
+       agent.  In this mode, the foreign agent is the endpoint of the
+       tunnel and, upon receiving tunneled datagrams, decapsulates them
+       and delivers the inner datagram to the mobile node.  This mode of
+       acquisition is preferred because it allows many mobile nodes to
+       share the same care-of address and therefore does not place
+       unnecessary demands on the already limited IPv4 address space.
+
+   b.  A "co-located care-of address" is a care-of address acquired by
+       the mobile node as a local IP address through some external
+       means, which the mobile node then associates with one of its own
+       network interfaces.  The address may be dynamically acquired as a
+       temporary address by the mobile node, such as through DHCP [34],
+       or may be owned by the mobile node as a long-term address for its
+       use only while visiting some foreign network.  Specific external
+       methods of acquiring a local IP address for use as a co-located
+
+
+
+Perkins                      Standards Track                   [Page 12]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+       care-of address are beyond the scope of this document.  When
+       using a co-located care-of address, the mobile node serves as the
+       endpoint of the tunnel and itself performs decapsulation of the
+       datagrams tunneled to it.
+
+   The mode of using a co-located care-of address has the advantage that
+   it allows a mobile node to function without a foreign agent, for
+   example, in networks that have not yet deployed a foreign agent.  It
+   does, however, place additional burden on the IPv4 address space
+   because it requires a pool of addresses within the foreign network to
+   be made available to visiting mobile nodes.  It is difficult to
+   efficiently maintain pools of addresses for each subnet that may
+   permit mobile nodes to visit.
+
+   It is important to understand the distinction between the care-of
+   address and the foreign agent functions.  The care-of address is
+   simply the endpoint of the tunnel.  It might indeed be an address of
+   a foreign agent (a foreign agent care-of address), but it might
+   instead be an address temporarily acquired by the mobile node (a
+   co-located care-of address).  A foreign agent, on the other hand, is
+   a mobility agent that provides services to mobile nodes.  See
+   Sections 3.7 and 4.2.2 for additional details.
+
+   A home agent MUST be able to attract and intercept datagrams that are
+   destined to the home address of any of its registered mobile nodes.
+   Using the proxy and gratuitous ARP mechanisms described in Section
+   4.6, this requirement can be satisfied if the home agent has a
+   network interface on the link indicated by the mobile node's home
+   address.  Other placements of the home agent relative to the mobile
+   node's home location MAY also be possible using other mechanisms for
+   intercepting datagrams destined to the mobile node's home address.
+   Such placements are beyond the scope of this document.
+
+   Similarly, a mobile node and a prospective or current foreign agent
+   MUST be able to exchange datagrams without relying on standard IP
+   routing mechanisms; that is, those mechanisms that make forwarding
+   decisions based upon the network-prefix of the Destination Address in
+   the IP header.  This requirement can be satisfied if the foreign
+   agent and the visiting mobile node have an interface on the same
+   link.  In this case, the mobile node and foreign agent simply bypass
+   their normal IP routing mechanism when sending datagrams to each
+   other, addressing the underlying link-layer packets to their
+   respective link-layer addresses.  Other placements of the foreign
+   agent relative to the mobile node MAY also be possible using other
+   mechanisms to exchange datagrams between these nodes, but such
+   placements are beyond the scope of this document.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 13]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+               2) Datagram is intercepted   3) Datagram is
+                  by home agent and            detunneled and
+                  is tunneled to the           delivered to the
+                  care-of address.             mobile node.
+
+                     +-----+          +-------+         +------+
+                     |home | =======> |foreign| ------> |mobile|
+                     |agent|          | agent | <------ | node |
+                     +-----+          +-------+         +------+
+    1) Datagram to    /|\         /
+       mobile node     |        /   4) For datagrams sent by the
+       arrives on      |      /        mobile node, standard IP
+       home network    |    /          routing delivers each to its
+       via standard    |  |_           destination.  In this figure,
+       IP routing.   +----+            the foreign agent is the
+                     |host|            mobile node's default router.
+                     +----+
+
+                    Figure 1:  Operation of Mobile IPv4
+
+   If a mobile node is using a co-located care-of address (as described
+   in item (b) above), the mobile node MUST be located on the link
+   identified by the network prefix of this care-of address.  Otherwise,
+   datagrams destined to the care-of address would be undeliverable.
+
+   For example, Figure 1 illustrates the routing of datagrams to and
+   from a mobile node away from home, once the mobile node has
+   registered with its home agent.  In Figure 1, the mobile node is
+   using a foreign agent care-of address, not a co-located care-of
+   address.
+
+1.8.  Message Format and Protocol Extensibility
+
+   Mobile IP defines a set of new control messages, sent with UDP [17]
+   using well-known port number 434.  The following two message types
+   are defined in this document:
+
+      1 Registration Request
+
+      3 Registration Reply
+
+   Up-to-date values for the message types for Mobile IP control
+   messages are specified in the IANA online database [48].
+
+   In addition, for Agent Discovery, Mobile IP makes use of the existing
+   Router Advertisement and Router Solicitation messages defined for
+   ICMP Router Discovery [5].
+
+
+
+
+Perkins                      Standards Track                   [Page 14]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   Mobile IP defines a general Extension mechanism to allow optional
+   information to be carried by Mobile IP control messages or by ICMP
+   Router Discovery messages.  Some extensions have been specified to be
+   encoded in the simple Type-Length-Value format described in Section
+   1.9.
+
+   Extensions allow variable amounts of information to be carried within
+   each datagram.  The end of the list of extensions is indicated by the
+   total length of the IP datagram.
+
+   Two separately maintained sets of numbering spaces, from which
+   Extension Type values are allocated, are used in Mobile IP:
+
+   o  The first set consists of those Extensions that may appear in
+      Mobile IP control messages (those sent to and from UDP port number
+      434).  In this document, the following types are defined for
+      Extensions appearing in Mobile IP control messages:
+
+        0  One-byte Padding (encoded with neither Length nor Data field)
+        32 Mobile-Home Authentication
+        33 Mobile-Foreign Authentication
+        34 Foreign-Home Authentication
+
+   o  The second set consists of those Extensions that may appear in
+      ICMP Router Discovery messages [5].  In this document, the
+      following types are defined for Extensions appearing in ICMP
+      Router Discovery messages:
+
+        0  One-byte Padding (encoded with neither Length nor Data field)
+        16 Mobility Agent Advertisement
+        19 Prefix-Lengths
+
+   Each individual Extension is described in detail in a separate
+   section later in this document.  Up-to-date values for these
+   Extension Type numbers are specified in the IANA online database
+   [48].
+
+   Due to the separation (orthogonality) of these sets, it is
+   conceivable that two Extensions that are defined at a later date
+   could have identical Type values, so long as one of the Extensions
+   may be used only in Mobile IP control messages and the other may be
+   used only in ICMP Router Discovery messages.
+
+   The Type field in the Mobile IP extension structure can support up to
+   255 (skippable and non-skippable) uniquely identifiable extensions.
+   When an Extension numbered in either of these sets within the range 0
+   through 127 is encountered but not recognized, the message containing
+   that Extension MUST be silently discarded.  When an Extension
+
+
+
+Perkins                      Standards Track                   [Page 15]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   numbered in the range 128 through 255 is encountered that is not
+   recognized, that particular Extension is ignored, but the rest of the
+   Extensions and message data MUST still be processed.  The Length
+   field of the Extension is used to skip the Data field in searching
+   for the next Extension.
+
+   Unless additional structure is utilized for the extension types, new
+   developments or additions to Mobile IP might require so many new
+   extensions that the available space for extension types might run
+   out.  Two new extension structures are proposed to solve this
+   problem.  Certain types of extensions can be aggregated, using
+   subtypes to identify the precise extension, for example as has been
+   done with the Generic Authentication Keys extensions [46].  In many
+   cases, this may reduce the rate of allocation for new values of the
+   Type field.
+
+   Since the new extension structures will cause an efficient usage of
+   the extension type space, it is recommended that new Mobile IP
+   extensions follow one of the two new extension formats whenever there
+   may be the possibility of grouping related extensions together.
+
+   The following subsections provide details about three distinct
+   structures for Mobile IP extensions:
+
+   o  The simple extension format
+
+   o  The long extension format
+
+   o  The short extension format
+
+1.9.  Type-Length-Value Extension Format for Mobile IP Extensions
+
+   The Type-Length-Value format illustrated in Figure 2 is used for
+   extensions that are specified in this document.  Since this simple
+   extension structure does not encourage the most efficient usage of
+   the extension type space, it is recommended that new Mobile IP
+   extensions follow one of the two new extension formats specified in
+   Section 1.10 or Section 1.11 whenever there may be the possibility of
+   grouping related extensions together.
+
+               0                   1                   2
+               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+              |     Type      |    Length     |    Data ...
+              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+       Figure 2:  Type-Length-Value Extension Format for Mobile IPv4
+
+
+
+
+Perkins                      Standards Track                   [Page 16]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   Type     Indicates the particular type of Extension.
+
+   Length   Indicates the length (in bytes) of the Data field within
+            this Extension.  The length does NOT include the Type and
+            Length bytes.
+
+   Data     The particular data associated with this Extension.  This
+            field may be zero or more bytes in length.  The format and
+            length of the Data field is determined by the Type and
+            Length fields.
+
+1.10.  Long Extension Format
+
+   This format is applicable for non-skippable extensions that carry
+   information of more than 256 bytes.  Skippable extensions can never
+   use the long format, because the receiver is not required to include
+   parsing code and is likely to treat the 8 bits immediately following
+   the Type as the Length field.
+
+     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      |  Sub-Type     |           Length              |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                           Data      .....
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Long Extension format requires that the following fields be
+   specified as the first fields of the extension.
+
+   Type     is the type, which describes a collection of extensions
+            having a common data type.
+
+   Sub-Type is a unique number given to each member in the aggregated
+            type.
+
+   Length   indicates the length (in bytes) of the Data field within
+            this Extension.  It does NOT include the Type, Length, and
+            Sub-Type bytes.
+
+   Data     is the data associated with the subtype of this extension.
+            This specification does not place any additional structure
+            on the subtype data.
+
+   Since the Length field is 16 bits wide, the extension data can exceed
+   256 bytes in length.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 17]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+1.11.  Short Extension Format
+
+   This format is compatible with the skippable extensions defined in
+   Section 1.9.  It is not applicable for extensions that require more
+   than 256 bytes of data; for such extensions, use the format described
+   in Section 1.10.
+
+     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      |    Sub-Type   |    Data ....
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Short Extension format requires that the following fields be
+   specified as the first fields of the extension:
+
+   Type     is the type, which describes a collection of extensions
+            having a common data type.
+
+   Sub-Type is a unique number given to each member in the aggregated
+            type.
+
+   Length   8-bit unsigned integer.  Length of the extension, in bytes,
+            excluding the extension Type and the extension Length
+            fields.  This field MUST be set to 1 plus the total length
+            of the Data field.
+
+   Data     is the data associated with this extension.  This
+            specification does not place any additional structure on the
+            subtype data.
+
+2.  Agent Discovery
+
+   Agent Discovery is the method by which a mobile node determines
+   whether it is currently connected to its home network or to a foreign
+   network, and by which a mobile node can detect when it has moved from
+   one network to another.  When connected to a foreign network, the
+   methods specified in this section also allow the mobile node to
+   determine the foreign agent care-of address being offered by each
+   foreign agent on that network.
+
+   Mobile IP extends ICMP Router Discovery [5] as its primary mechanism
+   for Agent Discovery.  An Agent Advertisement is formed by including a
+   Mobility Agent Advertisement Extension in an ICMP Router
+   Advertisement message (Section 2.1).  An Agent Solicitation message
+   is identical to an ICMP Router Solicitation, except that its IP Time
+
+
+
+
+
+Perkins                      Standards Track                   [Page 18]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   to Live (TTL) MUST be set to 1 (Section 2.2).  This section describes
+   the message formats and procedures by which mobile nodes, foreign
+   agents, and home agents cooperate to realize Agent Discovery.
+
+   Agent Advertisement and Agent Solicitation may not be necessary for
+   link layers that already provide this functionality.  The method by
+   which mobile nodes establish link-layer connections with prospective
+   agents is outside the scope of this document (but see Appendix A).
+   The procedures described below assume that such link-layer
+   connectivity has already been established.
+
+   No authentication is required for Agent Advertisement and Agent
+   Solicitation messages.  They MAY be authenticated using the IP
+   Authentication Header [9], which is unrelated to the messages
+   described in this document.  Further specification of the way in
+   which Advertisement and Solicitation messages may be authenticated is
+   outside of the scope of this document.
+
+2.1.  Agent Advertisement
+
+   Agent Advertisements are transmitted by a mobility agent to advertise
+   its services on a link.  Mobile nodes use these advertisements to
+   determine their current point of attachment to the Internet.  An
+   Agent Advertisement is an ICMP Router Advertisement that has been
+   extended to also carry a Mobility Agent Advertisement Extension
+   (Section 2.1.1) and, optionally, a Prefix-Lengths Extension (Section
+   2.1.2), One-byte Padding Extension (Section 2.1.3), or other
+   Extensions that might be defined in the future.
+
+   Within an Agent Advertisement message, ICMP Router Advertisement
+   fields of the message are required to conform to the following
+   additional specifications:
+
+      -  Link-Layer Fields
+
+         Destination Address
+
+                  The link-layer Destination Address of a unicast Agent
+                  Advertisement MUST be the same as the source link-
+                  layer address of the Agent Solicitation that prompted
+                  the Advertisement.
+
+      -  IP Fields
+
+         TTL      The TTL for all Agent Advertisements MUST be set to 1.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 19]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+         Destination Address
+
+                  As specified for ICMP Router Discovery [5], the IP
+                  Destination Address of a multicast Agent Advertisement
+                  MUST be either the "all systems on this link"
+                  multicast address (224.0.0.1) [6] or the "limited
+                  broadcast" address (255.255.255.255).  The subnet-
+                  directed broadcast address of the form <prefix>.<-1>
+                  cannot be used since mobile nodes will not generally
+                  know the prefix of the foreign network.  When the
+                  Agent Advertisement is unicast to a mobile node, the
+                  IP home address of the mobile node SHOULD be used as
+                  the Destination Address.
+
+      -  ICMP Fields
+
+         Code     The Code field of the Agent Advertisement is
+                  interpreted as follows:
+
+                  0  The mobility agent handles common traffic -- that
+                     is, it acts as a router for IP datagrams not
+                     necessarily related to mobile nodes.
+
+                  16 The mobility agent does not route common traffic.
+                     However, all foreign agents MUST (minimally)
+                     forward to a default router any datagrams received
+                     from a registered mobile node (Section 4.2.2).
+
+         Lifetime
+
+               The maximum length of time that the Advertisement is
+               considered valid in the absence of further
+               Advertisements.
+
+         Router Address(es)
+
+               See Section 2.3.1 for a discussion of the addresses that
+               may appear in this portion of the Agent Advertisement.
+
+         Num Addrs
+
+               The number of router addresses advertised in this
+               message.  Note that in an Agent Advertisement message,
+               the number of router addresses specified in the ICMP
+               Router Advertisement portion of the message MAY be set to
+               0.  See Section 2.3.1 for details.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 20]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   If sent periodically, the nominal interval at which Agent
+   Advertisements are sent SHOULD be no longer than 1/3 of the
+   advertisement Lifetime given in the ICMP header.  This interval MAY
+   be shorter than 1/3 the advertised Lifetime.  This allows a mobile
+   node to miss three successive advertisements before deleting the
+   agent from its list of valid agents.  The actual transmission time
+   for each advertisement SHOULD be slightly randomized [5] in order to
+   avoid synchronization and subsequent collisions with other Agent
+   Advertisements that may be sent by other agents (or with other Router
+   Advertisements sent by other routers).  Note that this field has no
+   relation to the "Registration Lifetime" field within the Mobility
+   Agent Advertisement Extension defined below.
+
+2.1.1.  Mobility Agent Advertisement Extension
+
+   The Mobility Agent Advertisement Extension follows the ICMP Router
+   Advertisement fields.  It is used to indicate that an ICMP Router
+   Advertisement message is also an Agent Advertisement being sent by a
+   mobility agent.  The Mobility Agent Advertisement Extension is
+   defined as follows:
+
+     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        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    Registration Lifetime      |R|B|H|F|M|G|r|T|U|X|I|reserved |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                  zero or more Care-of Addresses               |
+    |                              ...                              |
+
+      Type     16
+
+      Length   (6 + 4*N), where 6 accounts for the number of bytes in
+               the Sequence Number, Registration Lifetime, flags, and
+               reserved fields, and N is the number of care-of addresses
+               advertised.
+
+      Sequence Number
+
+               The count of Agent Advertisement messages sent since the
+               agent was initialized (Section 2.3.2).
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 21]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      Registration Lifetime
+
+               The longest lifetime (measured in seconds) that this
+               agent is willing to accept in any Registration Request.
+               A value of 0xffff indicates infinity.  This field has no
+               relation to the "Lifetime" field within the ICMP Router
+               Advertisement portion of the Agent Advertisement.
+
+      R        Registration required.  Registration with this foreign
+               agent (or another foreign agent on this link) is required
+               even when using a co-located care-of address.
+
+      B        Busy.  The foreign agent will not accept registrations
+               from additional mobile nodes.
+
+      H        Home agent.  This agent offers service as a home agent on
+               the link on which this Agent Advertisement message is
+               sent.
+
+      F        Foreign agent.  This agent offers service as a foreign
+               agent on the link on which this Agent Advertisement
+               message is sent.
+
+      M        Minimal encapsulation.  This agent implements receiving
+               tunneled datagrams that use minimal encapsulation [15].
+
+      G        Generic Routing Encapsulation (GRE) encapsulation.  This
+               agent implements receiving tunneled datagrams that use
+               GRE encapsulation [13].
+
+      r        Sent as zero; ignored on reception.  SHOULD NOT be
+               allocated for any other uses.
+
+      T        Foreign agent supports reverse tunneling as specified in
+               [12].
+
+      U        Mobility agent supports UDP Tunneling as specified in
+               [27].
+
+      X        Mobility agent supports Registration Revocation as
+               specified in [28].
+
+      I        Foreign agent supports Regional Registration as specified
+               in [29].
+
+      reserved
+               Sent as zero; ignored on reception.
+
+
+
+
+Perkins                      Standards Track                   [Page 22]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      Care-of Address(es)
+
+               The advertised foreign agent care-of address(es) provided
+               by this foreign agent.  An Agent Advertisement MUST
+               include at least one care-of address if the 'F' bit is
+               set.  The number of care-of addresses present is
+               determined by the Length field in the Extension.
+
+   A home agent MUST always be prepared to serve the mobile nodes for
+   which it is the home agent.  A foreign agent may at times be too busy
+   to serve additional mobile nodes; even so, it must continue to send
+   Agent Advertisements, so that any mobile nodes already registered
+   with it will know that they have not moved out of range of the
+   foreign agent and that the foreign agent has not failed.  A foreign
+   agent may indicate that it is "too busy" to allow new mobile nodes to
+   register with it, by setting the 'B' bit in its Agent Advertisements.
+   An Agent Advertisement message MUST NOT have the 'B' bit set if the
+   'F' bit is not also set.  Furthermore, at least one of the 'F' bit
+   and the 'H' bit MUST be set in any Agent Advertisement message sent.
+
+   When a foreign agent wishes to require registration even from those
+   mobile nodes that have acquired a co-located care-of address, it sets
+   the 'R' bit to one.  Because this bit applies only to foreign agents,
+   an agent MUST NOT set the 'R' bit to one unless the 'F' bit is also
+   set to one.
+
+2.1.2.  Prefix-Lengths Extension
+
+   The Prefix-Lengths Extension MAY follow the Mobility Agent
+   Advertisement Extension.  It is used to indicate the number of bits
+   of network prefix that applies to each router address listed in the
+   ICMP Router Advertisement portion of the Agent Advertisement.  Note
+   that the prefix lengths given DO NOT apply to care-of address(es)
+   listed in the Mobility Agent Advertisement Extension.  The Prefix-
+   Lengths Extension is defined as follows:
+
+    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     | Prefix Length |      ....
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type     19 (Prefix-Lengths Extension)
+
+      Length   N, where N is the value (possibly zero) of the Num Addrs
+               field in the ICMP Router Advertisement portion of the
+               Agent Advertisement.
+
+
+
+
+Perkins                      Standards Track                   [Page 23]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      Prefix Length(s)
+
+               The number of leading bits that define the network number
+               of the corresponding router address listed in the ICMP
+               Router Advertisement portion of the message.  The prefix
+               length for each router address is encoded as a separate
+               byte, in the order that the router addresses are listed
+               in the ICMP Router Advertisement portion of the message.
+
+   See Section 2.4.2 for information about how the Prefix-Lengths
+   Extension MAY be used by a mobile node when determining whether it
+   has moved.  See Appendix D for implementation details about the use
+   of this Extension.
+
+2.1.3.  One-Byte Padding Extension
+
+   Some IP protocol implementations insist upon padding ICMP messages to
+   an even number of bytes.  If the ICMP length of an Agent
+   Advertisement is odd, this Extension MAY be included in order to make
+   the ICMP length even.  Note that this Extension is NOT intended to be
+   a general-purpose Extension to be included in order to word- or long-
+   align the various fields of the Agent Advertisement.  An Agent
+   Advertisement SHOULD NOT include more than one One-byte Padding
+   Extension and if present, this Extension SHOULD be the last Extension
+   in the Agent Advertisement.
+
+   Note that, unlike other Extensions used in Mobile IP, the One-byte
+   Padding Extension is encoded as a single byte, with no Length nor
+   Data field present.  The One-byte Padding Extension is defined as
+   follows:
+
+        0 1 2 3 4 5 6 7
+       +-+-+-+-+-+-+-+-+
+       |     Type      |
+       +-+-+-+-+-+-+-+-+
+
+   Type 0 (One-byte Padding Extension)
+
+2.2.  Agent Solicitation
+
+   An Agent Solicitation is identical to an ICMP Router Solicitation
+   with the further restriction that the IP TTL Field MUST be set to 1.
+
+2.3.  Foreign Agent and Home Agent Considerations
+
+   Any mobility agent that cannot be discovered by a link-layer protocol
+   MUST send Agent Advertisements.  An agent that can be discovered by a
+   link-layer protocol SHOULD also implement Agent Advertisements.
+
+
+
+Perkins                      Standards Track                   [Page 24]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   However, the Advertisements need not be sent, except when the site
+   policy requires registration with the agent (i.e., when the 'R' bit
+   is set), or as a response to a specific Agent Solicitation.  All
+   mobility agents MUST process packets that they receive addressed to
+   the Mobile-Agents multicast group, at address 224.0.0.11.  A mobile
+   node MAY send an Agent Solicitation to 224.0.0.11.  All mobility
+   agents SHOULD respond to Agent Solicitations.
+
+   The same procedures, defaults, and constants are used in Agent
+   Advertisement messages and Agent Solicitation messages as specified
+   for ICMP Router Discovery [5], except that:
+
+   o  a mobility agent MUST limit the rate at which it sends broadcast
+      or multicast Agent Advertisements; the maximum rate SHOULD be
+      chosen so that the Advertisements do not consume a significant
+      amount of network bandwidth, AND
+
+   o  a mobility agent that receives a Router Solicitation MUST NOT
+      require that the IP Source Address is the address of a neighbor
+      (i.e., an address that matches one of the router's own addresses
+      on the arrival interface, under the subnet mask associated with
+      that address of the router).
+
+   o  a mobility agent MAY be configured to send Agent Advertisements
+      only in response to an Agent Solicitation message.
+
+   If the home network is not a virtual network, then the home agent for
+   any mobile node SHOULD be located on the link identified by the
+   mobile node's home address, and Agent Advertisement messages sent by
+   the home agent on this link MUST have the 'H' bit set.  In this way,
+   mobile nodes on their own home network will be able to determine that
+   they are indeed at home.  Any Agent Advertisement messages sent by
+   the home agent on another link to which it may be attached (if it is
+   a mobility agent serving more than one link), MUST NOT have the 'H'
+   bit set unless the home agent also serves as a home agent (to other
+   mobile nodes) on that other link.  A mobility agent MAY use different
+   settings for each of the 'R', 'H', and 'F' bits on different network
+   interfaces.
+
+   If the home network is a virtual network, the home network has no
+   physical realization external to the home agent itself.  In this
+   case, there is no physical network link on which to send Agent
+   Advertisement messages advertising the home agent.  Mobile nodes for
+   which this is the home network are always treated as being away from
+   home.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 25]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   On a particular subnet, either all mobility agents MUST include the
+   Prefix-Lengths Extension or all of them MUST NOT include this
+   Extension.  Equivalently, it is prohibited for some agents on a given
+   subnet to include the Extension but for others not to include it.
+   Otherwise, one of the move detection algorithms designed for mobile
+   nodes will not function properly (Section 2.4.2).
+
+2.3.1.  Advertised Router Addresses
+
+   The ICMP Router Advertisement portion of the Agent Advertisement MAY
+   contain one or more router addresses.  An agent SHOULD only put its
+   own addresses, if any, in the advertisement.  Whether or not its own
+   address appears in the router addresses, a foreign agent MUST route
+   datagrams it receives from registered mobile nodes (Section 3.7).
+
+2.3.2.  Sequence Numbers and Rollover Handling
+
+   The sequence number in Agent Advertisements ranges from 0 to 0xffff.
+   After booting, an agent MUST use the number 0 for its first
+   advertisement.  Each subsequent advertisement MUST use the sequence
+   number one greater, with the exception that the sequence number
+   0xffff MUST be followed by sequence number 256.  In this way, mobile
+   nodes can distinguish a reduction in the sequence number that occurs
+   after a reboot from a reduction that results in rollover of the
+   sequence number after it attains the value 0xffff.
+
+2.4.  Mobile Node Considerations
+
+   Every mobile node MUST implement Agent Solicitation.  Solicitations
+   SHOULD only be sent in the absence of Agent Advertisements and when a
+   care-of address has not been determined through a link-layer protocol
+   or other means.  The mobile node uses the same procedures, defaults,
+   and constants for Agent Solicitation as specified for ICMP Router
+   Solicitation messages [5], except that the mobile node MAY solicit
+   more often than once every three seconds, and that a mobile node that
+   is currently not connected to any foreign agent MAY solicit more
+   times than MAX_SOLICITATIONS.
+
+   The rate at which a mobile node sends solicitations MUST be limited
+   by the mobile node.  The mobile node MAY send three initial
+   solicitations at a maximum rate of one per second while searching for
+   an agent.  After this, the rate at which solicitations are sent MUST
+   be reduced so as to limit the overhead on the local link.  Subsequent
+   solicitations MUST be sent using a binary exponential backoff
+   mechanism, doubling the interval between consecutive solicitations,
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 26]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   up to a maximum interval.  The maximum interval SHOULD be chosen
+   appropriately based upon the characteristics of the media over which
+   the mobile node is soliciting.  This maximum interval SHOULD be at
+   least one minute between solicitations.
+
+   While still searching for an agent, the mobile node MUST NOT increase
+   the rate at which it sends solicitations unless it has received a
+   positive indication that it has moved to a new link.  After
+   successfully registering with an agent, the mobile node SHOULD also
+   increase the rate at which it will send solicitations when it next
+   begins searching for a new agent with which to register.  The
+   increased solicitation rate MAY revert to the maximum rate, but then
+   MUST be limited in the manner described above.  In all cases, the
+   recommended solicitation intervals are nominal values.  Mobile nodes
+   MUST randomize their solicitation times around these nominal values
+   as specified for ICMP Router Discovery [5].
+
+   Mobile nodes MUST process received Agent Advertisements.  A mobile
+   node can distinguish an Agent Advertisement message from other uses
+   of the ICMP Router Advertisement message by examining the number of
+   advertised addresses and the IP Total Length field.  When the IP
+   total length indicates that the ICMP message is longer than needed
+   for the number of advertised addresses, the remaining data is
+   interpreted as one or more Extensions.  The presence of a Mobility
+   Agent Advertisement Extension identifies the advertisement as an
+   Agent Advertisement.
+
+   If there is more than one advertised address, the mobile node SHOULD
+   pick the first address for its initial registration attempt.  If the
+   registration attempt fails with a status code indicating rejection by
+   the foreign agent, the mobile node MAY retry the attempt with each
+   subsequent advertised address in turn.
+
+   When multiple methods of agent discovery are in use, the mobile node
+   SHOULD first attempt registration with agents including Mobility
+   Agent Advertisement Extensions in their advertisements, in preference
+   to those discovered by other means.  This preference maximizes the
+   likelihood that the registration will be recognized, thereby
+   minimizing the number of registration attempts.
+
+   A mobile node MUST ignore reserved bits in Agent Advertisements, as
+   opposed to discarding such advertisements.  In this way, new bits can
+   be defined later, without affecting the ability for mobile nodes to
+   use the advertisements even when the newly defined bits are not
+   understood.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 27]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+2.4.1.  Registration Required
+
+   When the mobile node receives an Agent Advertisement with the 'R' bit
+   set, the mobile node SHOULD register through the foreign agent, even
+   when the mobile node might be able to acquire its own co-located
+   care-of address.  This feature is intended to allow sites to enforce
+   visiting policies (such as accounting) that require exchanges of
+   authorization.
+
+   If formerly reserved bits require some kind of monitoring/enforcement
+   at the foreign link, foreign agents implementing the new
+   specification for the formerly reserved bits can set the 'R' bit.
+   This has the effect of forcing the mobile node to register through
+   the foreign agent, so the foreign agent could then monitor/enforce
+   the policy.
+
+2.4.2.  Move Detection
+
+   Two primary mechanisms are provided for mobile nodes to detect when
+   they have moved from one subnet to another.  Other mechanisms MAY
+   also be used.  When the mobile node detects that it has moved, it
+   SHOULD register (Section 3) with a suitable care-of address on the
+   new foreign network.  However, the mobile node MUST NOT register more
+   frequently than once per second on average, as specified in Section
+   3.6.3.
+
+2.4.2.1.  Algorithm 1
+
+   The first method of move detection is based upon the Lifetime field
+   within the main body of the ICMP Router Advertisement portion of the
+   Agent Advertisement.  A mobile node SHOULD record the Lifetime
+   received in any Agent Advertisements, until that Lifetime expires.
+   If the mobile node fails to receive another advertisement from the
+   same agent within the specified Lifetime, it SHOULD assume that it
+   has lost contact with that agent.  If the mobile node has previously
+   received an Agent Advertisement from another agent for which the
+   Lifetime field has not yet expired, the mobile node MAY immediately
+   attempt registration with that other agent.  Otherwise, the mobile
+   node SHOULD attempt to discover a new agent with which to register.
+
+2.4.2.2.  Algorithm 2
+
+   The second method uses network prefixes.  The Prefix-Lengths
+   Extension MAY be used in some cases by a mobile node to determine
+   whether or not a newly received Agent Advertisement was received on
+   the same subnet as the mobile node's current care-of address.  If the
+   prefixes differ, the mobile node MAY assume that it has moved.  If a
+   mobile node is currently using a foreign agent care-of address, the
+
+
+
+Perkins                      Standards Track                   [Page 28]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   mobile node SHOULD NOT use this method of move detection unless both
+   the current agent and the new agent include the Prefix-Lengths
+   Extension in their respective Agent Advertisements; if this Extension
+   is missing from one or both of the advertisements, this method of
+   move detection SHOULD NOT be used.  Similarly, if a mobile node is
+   using a co-located care-of address, it SHOULD NOT use this method of
+   move detection unless the new agent includes the Prefix-Lengths
+   Extension in its Advertisement and the mobile node knows the network
+   prefix of its current co-located care-of address.  On the expiration
+   of its current registration, if this method indicates that the mobile
+   node has moved, rather than re-registering with its current care-of
+   address, a mobile node MAY choose instead to register with the
+   foreign agent sending the new Advertisement with the different
+   network prefix.  The Agent Advertisement on which the new
+   registration is based MUST NOT have expired according to its Lifetime
+   field.
+
+2.4.3.  Returning Home
+
+   A mobile node can detect that it has returned to its home network
+   when it receives an Agent Advertisement from its own home agent.  If
+   so, it SHOULD deregister with its home agent (Section 3).  Before
+   attempting to deregister, the mobile node SHOULD configure its
+   routing table appropriately for its home network (Section 4.2.1).  In
+   addition, if the home network is using ARP [16], the mobile node MUST
+   follow the procedures described in Section 4.6 with regard to ARP,
+   proxy ARP, and gratuitous ARP.
+
+2.4.4.  Sequence Numbers and Rollover Handling
+
+   If a mobile node detects two successive values of the sequence number
+   in the Agent Advertisements from the foreign agent with which it is
+   registered, the second of which is less than the first and inside the
+   range 0 to 255, the mobile node SHOULD register again.  If the second
+   value is less than the first but is greater than or equal to 256, the
+   mobile node SHOULD assume that the sequence number has rolled over
+   past its maximum value (0xffff), and that re-registration is not
+   necessary (Section 2.3).
+
+3.  Registration
+
+   Mobile IP registration provides a flexible mechanism for mobile nodes
+   to communicate their current reachability information to their home
+   agent.  It is the method by which mobile nodes:
+
+   o  request forwarding services when visiting a foreign network,
+
+   o  inform their home agent of their current care-of address,
+
+
+
+Perkins                      Standards Track                   [Page 29]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   o  renew a registration that is due to expire, and/or
+
+   o  deregister when they return home.
+
+   Registration messages exchange information between a mobile node,
+   (optionally) a foreign agent, and the home agent.  Registration
+   creates or modifies a mobility binding at the home agent, associating
+   the mobile node's home address with its care-of address for the
+   specified Lifetime.
+
+   Several other (optional) capabilities are available through the
+   registration procedure, which enable a mobile node to:
+
+   o  discover its home address, if the mobile node is not configured
+      with this information,
+
+   o  maintain multiple simultaneous registrations, so that a copy of
+      each datagram will be tunneled to each active care-of address,
+
+   o  deregister specific care-of addresses while retaining other
+      mobility bindings, and
+
+   o  discover the address of a home agent if the mobile node is not
+      configured with this information.
+
+3.1.  Registration Overview
+
+   Mobile IP defines two different registration procedures, one via a
+   foreign agent that relays the registration to the mobile node's home
+   agent, and one directly with the mobile node's home agent.  The
+   following rules determine which of these two registration procedures
+   to use in any particular circumstance:
+
+   o  If a mobile node is registering a foreign agent care-of address,
+      the mobile node MUST register via that foreign agent.
+
+   o  If a mobile node is using a co-located care-of address, and
+      receives an Agent Advertisement from a foreign agent on the link
+      on which it is using this care-of address, the mobile node SHOULD
+      register via that foreign agent (or via another foreign agent on
+      this link) if the 'R' bit is set in the received Agent
+      Advertisement message.
+
+   o  If a mobile node is otherwise using a co-located care-of address,
+      the mobile node MUST register directly with its home agent.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 30]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   o  If a mobile node has returned to its home network and is
+      (de)registering with its home agent, the mobile node MUST register
+      directly with its home agent.
+
+   Both registration procedures involve the exchange of Registration
+   Request and Registration Reply messages (Section 3.3 and Section
+   3.4).  When registering via a foreign agent, the registration
+   procedure requires the following four messages:
+
+   a.  The mobile node sends a Registration Request to the prospective
+       foreign agent to begin the registration process.
+
+   b.  The foreign agent processes the Registration Request and then
+       relays it to the home agent.
+
+   c.  The home agent sends a Registration Reply to the foreign agent to
+       grant or deny the Request.
+
+   d.  The foreign agent processes the Registration Reply and then
+       relays it to the mobile node to inform it of the disposition of
+       its Request.
+
+   When the mobile node instead registers directly with its home agent,
+   the registration procedure requires only the following two messages:
+
+   a.  The mobile node sends a Registration Request to the home agent.
+
+   b.  The home agent sends a Registration Reply to the mobile node,
+       granting or denying the Request.
+
+   The registration messages defined in Sections 3.3 and 3.4 use the
+   User Datagram Protocol (UDP) [17].  A nonzero UDP checksum SHOULD be
+   included in the header, and MUST be checked by the recipient.  A zero
+   UDP checksum SHOULD be accepted by the recipient.  The behavior of
+   the mobile node and the home agent with respect to their mutual
+   acceptance of packets with zero UDP checksums SHOULD be defined as
+   part of the Mobility Security Association that exists between them.
+
+3.2.  Authentication
+
+   Each mobile node, foreign agent, and home agent MUST be able to
+   support a Mobility Security Association for mobile entities, indexed
+   by their SPI and IP address.  In the case of the mobile node, this
+   must be its home address.  See Section 5.1 for requirements for
+   support of authentication algorithms.  Registration messages between
+   a mobile node and its home agent MUST be authenticated with an
+   authorization-enabling extension, e.g., the Mobile-Home
+   Authentication Extension (Section 3.5.2).  This extension MUST be the
+
+
+
+Perkins                      Standards Track                   [Page 31]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   first authentication extension; other foreign-agent-specific
+   extensions MAY be added to the message after the mobile node computes
+   the authentication.
+
+3.3.  Registration Request
+
+   A mobile node registers with its home agent using a Registration
+   Request message so that its home agent can create or modify a
+   mobility binding for that mobile node (e.g., with a new Lifetime).
+   The Request may be relayed to the home agent by the foreign agent
+   through which the mobile node is registering, or it may be sent
+   directly to the home agent in the case in which the mobile node is
+   registering a co-located care-of address.
+
+   IP fields:
+
+      Source Address
+
+                     Typically the interface address from which the
+                     message is sent.
+
+      Destination Address
+
+                     Typically that of the foreign agent or the home
+                     agent.
+
+      See Sections 3.6.1.1 and 3.7.2.2 for details.
+
+   UDP fields:
+
+      Source Port       variable
+
+      Destination Port  434
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 32]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   The UDP header is followed by the Mobile IP fields shown below:
+
+     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|r|T|x|          Lifetime             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Home Address                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                           Home Agent                          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Care-of Address                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    +                         Identification                        +
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Extensions ...
+    +-+-+-+-+-+-+-+-
+
+      Type     1 (Registration Request)
+
+      S        Simultaneous bindings.  If the 'S' bit is set, the mobile
+               node is requesting that the home agent retain its prior
+               mobility bindings, as described in Section 3.6.1.2.
+
+      B        Broadcast datagrams.  If the 'B' bit is set, the mobile
+               node requests that the home agent tunnel to it any
+               broadcast datagrams that it receives on the home network,
+               as described in Section 4.3.
+
+      D        Decapsulation by mobile node.  If the 'D' bit is set, the
+               mobile node will itself decapsulate datagrams that are
+               sent to the care-of address.  That is, the mobile node is
+               using a co-located care-of address.
+
+      M        Minimal encapsulation.  If the 'M' bit is set, the mobile
+               node requests that its home agent use minimal
+               encapsulation [16] for datagrams tunneled to the mobile
+               node.
+
+      G        GRE encapsulation.  If the 'G' bit is set, the mobile
+               node requests that its home agent use GRE encapsulation
+               [13] for datagrams tunneled to the mobile node.
+
+      r        Sent as zero; ignored on reception.  SHOULD NOT be
+               allocated for any other uses.
+
+
+
+
+Perkins                      Standards Track                   [Page 33]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      T        Reverse Tunneling requested; see [12].
+
+      x        Sent as zero; ignored on reception.
+
+      Lifetime
+
+               The number of seconds remaining before the registration
+               is considered expired.  A value of zero indicates a
+               request for deregistration.  A value of 0xffff indicates
+               infinity.
+
+      Home Address
+
+               The IP address of the mobile node.
+
+      Home Agent
+
+               The IP address of the mobile node's home agent.
+
+      Care-of Address
+
+               The IP address for the end of the tunnel.
+
+      Identification
+
+               A 64-bit number, constructed by the mobile node, used for
+               matching Registration Requests with Registration Replies,
+               and for protecting against replay attacks of registration
+               messages.  See Sections 5.4 and 5.7.
+
+      Extensions
+
+               The fixed portion of the Registration Request is followed
+               by one or more of the Extensions listed in Section 3.5.
+               An authorization-enabling extension MUST be included in
+               all Registration Requests.  See Sections 3.6.1.3 and
+               3.7.2.2 for information on the relative order in which
+               different extensions, when present, MUST be placed in a
+               Registration Request message.
+
+3.4.  Registration Reply
+
+   A mobility agent typically returns a Registration Reply message to a
+   mobile node that has sent a Registration Request message.  If the
+   mobile node is requesting service from a foreign agent, that foreign
+   agent will typically receive the Reply from the home agent and
+
+
+
+
+
+Perkins                      Standards Track                   [Page 34]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   subsequently relay it to the mobile node.  Reply messages contain the
+   necessary codes to inform the mobile node about the status of its
+   Request, along with the lifetime granted by the home agent, which MAY
+   be smaller than the original Request.
+
+   The foreign agent MUST NOT increase the Lifetime selected by the
+   mobile node in the Registration Request, since the Lifetime is
+   covered by an authentication extension that enables authorization by
+   the home agent.  Such an extension contains authentication data that
+   cannot be correctly (re)computed by the foreign agent.  The home
+   agent MUST NOT increase the Lifetime selected by the mobile node in
+   the Registration Request, since doing so could increase it beyond the
+   maximum Registration Lifetime allowed by the foreign agent.  If the
+   Lifetime received in the Registration Reply is greater than that in
+   the Registration Request, the Lifetime in the Request MUST be used.
+   When the Lifetime received in the Registration Reply is less than
+   that in the Registration Request, the Lifetime in the Reply MUST be
+   used.
+
+   IP fields:
+
+      Source Address
+
+                     Typically copied from the Destination Address of
+                     the Registration Request to which the agent is
+                     replying.  See Sections 3.7.2.3 and 3.8.3.2 for
+                     complete details.
+
+      Destination Address
+
+                     Copied from the source address of the Registration
+                     Request to which the agent is replying.
+
+   UDP fields:
+
+      Source Port
+
+                     Copied from the UDP Destination Port of the
+                     corresponding Registration Request.
+
+      Destination Port
+
+                     Copied from the source port of the corresponding
+                     Registration Request (Section 3.7.1).
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 35]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   The UDP header is followed by the Mobile IP fields shown below:
+
+     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      |     Code      |           Lifetime            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Home Address                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                           Home Agent                          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    +                         Identification                        +
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Extensions ...
+    +-+-+-+-+-+-+-+-
+
+      Type     3 (Registration Reply)
+
+      Code
+
+               A value indicating the result of the Registration
+               Request.  See below for a list of currently defined code
+               values.
+
+      Lifetime
+
+               If the Code field indicates that the registration was
+               accepted, the Lifetime field is set to the number of
+               seconds remaining before the registration is considered
+               expired.  A value of zero indicates that the mobile node
+               has been deregistered.  A value of 0xffff indicates
+               infinity.  If the Code field indicates that the
+               registration was denied, the contents of the Lifetime
+               field are unspecified and MUST be ignored on reception.
+
+      Home Address
+
+               The IP address of the mobile node.
+
+      Home Agent
+
+               The IP address of the mobile node's home agent.
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 36]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      Identification
+
+               A 64-bit number used for matching Registration Requests
+               with Registration Replies, and for protecting against
+               replay attacks of registration messages.  The value is
+               based on the Identification field from the Registration
+               Request message from the mobile node, and on the style of
+               replay protection used in the security context between
+               the mobile node and its home agent (defined by the
+               Mobility Security Association between them, and SPI value
+               in the authorization-enabling extension).  See Sections
+               5.4 and 5.7.
+
+      Extensions
+
+               The fixed portion of the Registration Reply is followed
+               by one or more of the Extensions listed in Section 3.5.
+               An authorization-enabling extension MUST be included in
+               all Registration Replies returned by the home agent.  See
+               Sections 3.7.2.2 and 3.8.3.3 for rules on placement of
+               extensions to Reply messages.
+
+      The following values are defined for use within the Code field.
+      Registration successful:
+
+         0 registration accepted
+         1 registration accepted, but simultaneous mobility bindings
+         unsupported
+
+      Registration denied by the foreign agent:
+
+         64  reason unspecified
+         65  administratively prohibited
+         66  insufficient resources
+         67  mobile node failed authentication
+         68  home agent failed authentication
+         69  requested Lifetime too long
+         70  poorly formed Request
+         71  poorly formed Reply
+         72  requested encapsulation unavailable
+         73  reserved and unavailable
+         77  invalid care-of address
+         78  registration timeout
+         80  home network unreachable (ICMP error received)
+         81  home agent host unreachable (ICMP error received)
+         82  home agent port unreachable (ICMP error received)
+         88  home agent unreachable (other ICMP error received)
+         194 Invalid Home Agent Address
+
+
+
+Perkins                      Standards Track                   [Page 37]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      Registration denied by the home agent:
+
+         128 reason unspecified
+         129 administratively prohibited
+         130 insufficient resources
+         131 mobile node failed authentication
+         132 foreign agent failed authentication
+         133 registration Identification mismatch
+         134 poorly formed Request
+         135 too many simultaneous mobility bindings
+         136 unknown home agent address
+
+      Up-to-date values of the Code field are specified in the IANA
+      online database [48].
+
+3.5.  Registration Extensions
+
+3.5.1.  Computing Authentication Extension Values
+
+   The Authenticator value computed for each authentication Extension
+   MUST protect the following fields from the registration message:
+
+   o  the UDP payload (that is, the Registration Request or Registration
+      Reply data),
+
+   o  all prior Extensions in their entirety, and
+
+   o  the Type, Length, and SPI of this Extension.
+
+   The default authentication algorithm uses HMAC-MD5 [10] to compute a
+   128-bit "message digest" of the registration message.  The data over
+   which the HMAC is computed is defined as:
+
+   o  the UDP payload (that is, the Registration Request or Registration
+      Reply data),
+
+   o  all prior Extensions in their entirety, and
+
+   o  the Type, Length, and SPI of this Extension.
+
+   Note that the Authenticator field itself and the UDP header are NOT
+   included in the computation of the default Authenticator value.  See
+   Section 5.1 for information about support requirements for message
+   authentication codes, which are to be used with the various
+   authentication Extensions.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 38]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   The Security Parameter Index (SPI) within any of the authentication
+   Extensions defines the security context that is used to compute the
+   Authenticator value and that MUST be used by the receiver to check
+   that value.  In particular, the SPI selects the authentication
+   algorithm and mode (Section 5.1) and secret (a shared key, or
+   appropriate public/private key pair) used in computing the
+   Authenticator.  In order to ensure interoperability between different
+   implementations of the Mobile IP protocol, an implementation MUST be
+   able to associate any SPI value with any authentication algorithm and
+   mode that it implements.  In addition, all implementations of Mobile
+   IP MUST implement the default authentication algorithm (HMAC-MD5)
+   specified above.
+
+3.5.2.  Mobile-Home Authentication Extension
+
+   At least one authorization-enabling extension MUST be present in all
+   Registration Requests, and also in all Registration Replies generated
+   by the home agent.  The Mobile-Home Authentication Extension is
+   always an authorization-enabling extension for registration messages
+   specified in this document.  This requirement is intended to
+   eliminate problems [30] that result from the uncontrolled propagation
+   of remote redirects in the Internet.  The location of the
+   authorization-enabling extension marks the end of the data to be
+   authenticated by the authorizing agent interpreting that
+   authorization-enabling 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    |         SPI  ....
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           ... SPI (cont.)          |       Authenticator ...
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type     32
+
+      Length   4 plus the number of bytes in the Authenticator.
+
+      SPI      Security Parameter Index (4 bytes).  An opaque identifier
+               (see Section 1.6).
+
+      Authenticator
+
+               (variable length) (See Section 3.5.1.)
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 39]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+3.5.3.  Mobile-Foreign Authentication Extension
+
+   This Extension MAY be included in Registration Requests and Replies
+   in cases in which a Mobility Security Association exists between the
+   mobile node and the foreign agent.  See Section 5.1 for information
+   about support requirements for message authentication codes.
+
+     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    |         SPI  ....
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           ... SPI (cont.)          |       Authenticator ...
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type     33
+
+      Length   4 plus the number of bytes in the Authenticator.
+
+      SPI      Security Parameter Index (4 bytes).  An opaque identifier
+               (see Section 1.6).
+
+      Authenticator
+
+               (variable length) (See Section 3.5.1.)
+
+3.5.4.  Foreign-Home Authentication Extension
+
+   This Extension MAY be included in Registration Requests and Replies
+   in cases in which a Mobility Security Association exists between the
+   foreign agent and the home agent, as long as the Registration Request
+   is not a deregistration (i.e., the mobile node requested a nonzero
+   Lifetime and the home address is different than the care-of address).
+   The Foreign-Home Authentication extension MUST NOT be applied to
+   deregistration messages.  See Section 5.1 for information about
+   support requirements for message authentication codes.
+
+     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    |         SPI  ....
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           ... SPI (cont.)          |       Authenticator ...
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type     34
+
+      Length   4 plus the number of bytes in the Authenticator.
+
+
+
+Perkins                      Standards Track                   [Page 40]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      SPI      Security Parameter Index (4 bytes).  An opaque identifier
+               (see Section 1.6).
+
+      Authenticator
+
+               (variable length) (See Section 3.5.1).
+
+   In order to perform the authentication, the home agent and the
+   foreign agent are configured with a Mobility Security Association
+   that is indexed by the SPI (in the appended Foreign-Home
+   Authentication Extension) and the IP Source Address of the
+   Registration Request.  When the extension is used with a Registration
+   Reply message, the foreign agent address MUST be used as the
+   Destination IP Address in the IP header.
+
+   When this extension is applied to a Registration Request message, the
+   Mobility Security Association for verifying the correctness of the
+   authentication data is selected by the home agent based on the value
+   of the Source IP Address field of the Registration Request and the
+   SPI of the Authentication extension.  The Source IP Address will be
+   the same as the Care-of Address field of the Registration Request
+   (see Section 3.7.2.2).
+
+   When this extension is applied to a Registration Reply message, the
+   Mobility Security Association for verifying the correctness of the
+   authentication data is selected by the foreign agent based on the
+   value of the home agent Address field of the Registration Reply.
+
+   If the Care-of Address in the Registration Request is not in the
+   Agent Advertisement, then the foreign agent MUST NOT append the
+   Foreign-Home Authentication Extension when relaying the message to
+   the home agent.  Moreover, for a deregistration message (i.e.,
+   Lifetime = 0), the foreign agent MUST NOT append the Foreign-Home
+   Authentication Extension when relaying the message to the home agent.
+   Consequently, when the home agent (HA) receives a deregistration
+   request that does not contain a Foreign-Home Authentication
+   Extension, it MUST NOT for this reason discard the request as part of
+   security association processing.
+
+3.6.  Mobile Node Considerations
+
+   A mobile node MUST be configured (statically or dynamically) with a
+   netmask and a Mobility Security Association for each of its home
+   agents.  In addition, a mobile node MAY be configured with its home
+   address, and the IP address of one or more of its home agents;
+   otherwise, the mobile node MAY discover a home agent using the
+   procedures described in Section 3.6.1.2.
+
+
+
+
+Perkins                      Standards Track                   [Page 41]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   If the mobile node is not configured with a home address, it MAY use
+   the Mobile Node Network Access Identifier (NAI) extension [2] to
+   identify itself, and set the Home Address field of the Registration
+   Request to 0.0.0.0.  In this case, the mobile node MUST be able to
+   assign its home address after extracting this information from the
+   Registration Reply from the home agent.
+
+   For each pending registration, the mobile node maintains the
+   following information:
+
+   o  the link-layer address of the foreign agent to which the
+      Registration Request was sent, if applicable,
+
+   o  the IP Destination Address of the Registration Request,
+
+   o  the care-of address used in the registration,
+
+   o  the Identification value sent in the registration,
+
+   o  the originally requested Lifetime, and
+
+   o  the remaining Lifetime of the pending registration.
+
+   A mobile node SHOULD initiate a registration whenever it detects a
+   change in its network connectivity.  See Section 2.4.2 for methods by
+   which mobile nodes MAY make such a determination.  When it is away
+   from home, the mobile node's Registration Request allows its home
+   agent to create or modify a mobility binding for it.  When it is at
+   home, the mobile node's (de)Registration Request allows its home
+   agent to delete any previous mobility binding(s) for it.  A mobile
+   node operates without the support of mobility functions when it is at
+   home.
+
+   There are other conditions under which the mobile node SHOULD
+   (re)register with its foreign agent, such as when the mobile node
+   detects that the foreign agent has rebooted (as specified in Section
+   2.4.4) and when the current registration's Lifetime is near
+   expiration.
+
+   In the absence of link-layer indications of changes in point of
+   attachment, Agent Advertisements from new agents SHOULD NOT cause a
+   mobile node to attempt a new registration, if its current
+   registration has not expired and it is still also receiving Agent
+   Advertisements from the foreign agent with which it is currently
+   registered.  In the absence of link-layer indications, a mobile node
+   MUST NOT attempt to register more often than once per second.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 42]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   A mobile node MAY register with a different agent when transport-
+   layer protocols indicate excessive retransmissions.  A mobile node
+   MUST NOT consider reception of an ICMP Redirect from a foreign agent
+   that is currently providing service to it as reason to register with
+   a new foreign agent.  Within these constraints, the mobile node MAY
+   register again at any time.
+
+   Appendix C shows some examples of how the fields in registration
+   messages would be set up in some typical registration scenarios.
+
+3.6.1.  Sending Registration Requests
+
+   The following sections specify details for the values that the mobile
+   node MUST supply in the fields of Registration Request messages.
+
+3.6.1.1.  IP Fields
+
+   This section provides the specific rules by which mobile nodes pick
+   values for the IP header fields of a Registration Request.
+
+   IP Source Address:
+
+   o  When registering on a foreign network with a co-located care-of
+      address, the IP source address MUST be the care-of address.
+
+   o  Otherwise, if the mobile node does not have a home address, the IP
+      source address MUST be 0.0.0.0.
+
+   o  In all other circumstances, the IP source address MUST be the
+      mobile node's home address.
+
+   IP Destination Address:
+
+   o  When the mobile node has discovered the agent with which it is
+      registering, through some means (e.g., link-layer) that does not
+      provide the IP address of the agent (the IP address of the agent
+      is unknown to the mobile node), then the "All Mobility Agents"
+      multicast address (224.0.0.11) MUST be used.  In this case, the
+      mobile node MUST use the agent's link-layer unicast address in
+      order to deliver the datagram to the correct agent.
+
+   o  When registering with a foreign agent, the address of the agent as
+      learned from the IP source address of the corresponding Agent
+      Advertisement MUST be used.  This MAY be an address that does not
+      appear as an advertised care-of address in the Agent
+      Advertisement.  In addition, when transmitting this Registration
+
+
+
+
+
+Perkins                      Standards Track                   [Page 43]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      Request message, the mobile node MUST use a link-layer Destination
+      Address copied from the link-layer source address of the Agent
+      Advertisement message in which it learned this foreign agent's IP
+      address.
+
+   o  When the mobile node is registering directly with its home agent
+      and knows the (unicast) IP address of its home agent, the
+      Destination Address MUST be set to this address.
+
+   o  If the mobile node is registering directly with its home agent,
+      but does not know the IP address of its home agent, the mobile
+      node may use dynamic home agent address resolution to
+      automatically determine the IP address of its home agent (Section
+      3.6.1.2).  In this case, the IP Destination Address is set to the
+      subnet-directed broadcast address of the mobile node's home
+      network.  This address MUST NOT be used as the Destination IP
+      Address if the mobile node is registering via a foreign agent,
+      although it MAY be used as the home agent address in the body of
+      the Registration Request when registering via a foreign agent.
+
+   IP Time to Live:
+
+   o  The IP TTL field MUST be set to 1 if the IP Destination Address is
+      set to the "All Mobility Agents" multicast address as described
+      above.  Otherwise, a suitable value should be chosen in accordance
+      with standard IP practice [18].
+
+3.6.1.2.  Registration Request Fields
+
+   This section provides specific rules by which mobile nodes pick
+   values for the fields within the fixed portion of a Registration
+   Request.
+
+   A mobile node MAY set the 'S' bit in order to request that the home
+   agent maintain prior mobility binding(s).  Otherwise, the home agent
+   deletes any previous binding(s) and replaces them with the new
+   binding specified in the Registration Request.  Multiple simultaneous
+   mobility bindings are likely to be useful when a mobile node using at
+   least one wireless network interface moves within wireless
+   transmission range of more than one foreign agent.  IP explicitly
+   allows duplication of datagrams.  When the home agent allows
+   simultaneous bindings, it will tunnel a separate copy of each
+   arriving datagram to each care-of address, and the mobile node will
+   receive multiple copies of datagrams destined to it.
+
+   The mobile node SHOULD set the 'D' bit if it is registering with a
+   co-located care-of address.  Otherwise, the 'D' bit MUST NOT be set.
+
+
+
+
+Perkins                      Standards Track                   [Page 44]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   A mobile node MAY set the 'B' bit to request its home agent to
+   forward to it a copy of broadcast datagrams received by its home
+   agent from the home network.  The method used by the home agent to
+   forward broadcast datagrams depends on the type of care-of address
+   registered by the mobile node, as determined by the 'D' bit in the
+   mobile node's Registration Request:
+
+   o  If the 'D' bit is set, then the mobile node has indicated that it
+      will decapsulate any datagrams tunneled to this care-of address
+      itself (the mobile node is using a co-located care-of address).
+      In this case, to forward such a received broadcast datagram to the
+      mobile node, the home agent MUST tunnel it to this care-of
+      address.  The mobile node detunnels the received datagram in the
+      same way as any other datagram tunneled directly to it.
+
+   o  If the 'D' bit is NOT set, then the mobile node has indicated that
+      it is using a foreign agent care-of address, and that the foreign
+      agent will thus decapsulate arriving datagrams before forwarding
+      them to the mobile node.  In this case, to forward such a received
+      broadcast datagram to the mobile node, the home agent MUST first
+      encapsulate the broadcast datagram in a unicast datagram addressed
+      to the mobile node's home address, and then MUST tunnel this
+      resulting datagram to the mobile node's care-of address.
+
+      When decapsulated by the foreign agent, the inner datagram will
+      thus be a unicast IP datagram addressed to the mobile node,
+      identifying to the foreign agent the intended destination of the
+      encapsulated broadcast datagram, and will be delivered to the
+      mobile node in the same way as any tunneled datagram arriving for
+      the mobile node.  The foreign agent MUST NOT decapsulate the
+      encapsulated broadcast datagram and MUST NOT use a local network
+      broadcast to transmit it to the mobile node.  The mobile node thus
+      MUST decapsulate the encapsulated broadcast datagram itself, and
+      thus MUST NOT set the 'B' bit in its Registration Request in this
+      case unless it is capable of decapsulating datagrams.
+
+   The mobile node MAY request alternative forms of encapsulation by
+   setting the 'M' bit and/or the 'G' bit, but only if the mobile node
+   is decapsulating its own datagrams (the mobile node is using a
+   co-located care-of address) or if its foreign agent has indicated
+   support for these forms of encapsulation by setting the corresponding
+   bits in the Mobility Agent Advertisement Extension of an Agent
+   Advertisement received by the mobile node.  Otherwise, the mobile
+   node MUST NOT set these bits.
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 45]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   The Lifetime field is chosen as follows:
+
+   o  If the mobile node is registering with a foreign agent, the
+      Lifetime SHOULD NOT exceed the value in the Registration Lifetime
+      field of the Agent Advertisement message received from the foreign
+      agent.  When the method by which the care-of address is learned
+      does not include a Lifetime, the default ICMP Router Advertisement
+      Lifetime (1800 seconds) MAY be used.
+
+   o  The mobile node MAY ask a home agent to delete a particular
+      mobility binding, by sending a Registration Request with the care-
+      of address for this binding, with the Lifetime field set to zero
+      (Section 3.8.2).
+
+   o  Similarly, a Lifetime of zero is used when the mobile node
+      deregisters all care-of addresses, such as upon returning home.
+
+   The Home Address field MUST be set to the mobile node's home address,
+   if this information is known.  Otherwise, the Home Address field MUST
+   be set to zeroes.
+
+   The Home Agent field MUST be set to the address of the mobile node's
+   home agent, if the mobile node knows this address.  Otherwise, the
+   mobile node MAY use dynamic home agent address resolution to learn
+   the address of its home agent.  In this case, the mobile node MUST
+   set the Home Agent field to the subnet-directed broadcast address of
+   the mobile node's home network.  Each home agent receiving such a
+   Registration Request with a broadcast Destination Address MUST reject
+   the mobile node's registration and SHOULD return a rejection
+   Registration Reply indicating its unicast IP address for use by the
+   mobile node in a future registration attempt.
+
+   The Care-of Address field MUST be set to the value of the particular
+   care-of address that the mobile node wishes to (de)register.  In the
+   special case in which a mobile node wishes to deregister all care-of
+   addresses, it MUST set this field to its home address.
+
+   The mobile node chooses the Identification field in accordance with
+   the style of replay protection it uses with its home agent.  This is
+   part of the Mobility Security Association the mobile node shares with
+   its home agent.  See Section 5.7 for the method by which the mobile
+   node computes the Identification field.
+
+3.6.1.3.  Extensions
+
+   This section describes the ordering of any mandatory and any optional
+   Extensions that a mobile node appends to a Registration Request.
+   This ordering is REQUIRED:
+
+
+
+Perkins                      Standards Track                   [Page 46]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   a.  The IP header, followed by the UDP header, followed by the fixed-
+       length portion of the Registration Request, followed by
+
+   b.  If present, any non-authentication Extensions expected to be used
+       by the home agent or other authorizing agent (which may or may
+       not also be useful to the foreign agent), followed by
+
+   c.  All authorization-enabling extensions (see Section 1.6), followed
+       by
+
+   d.  If present, any non-authentication Extensions used only by the
+       foreign agent, followed by
+
+   e.  The Mobile-Foreign Authentication Extension, if present.
+
+   Note that items (a) and (c) MUST appear in every Registration Request
+   sent by the mobile node.  Items (b), (d), and (e) are optional.
+   However, item (e) MUST be included when the mobile node and the
+   foreign agent share a Mobility Security Association.
+
+3.6.2.  Receiving Registration Replies
+
+   Registration Replies will be received by the mobile node in response
+   to its Registration Requests.  Registration Replies generally fall
+   into three categories:
+
+   o  the registration was accepted,
+
+   o  the registration was denied by the foreign agent, or
+
+   o  the registration was denied by the home agent.
+
+   The remainder of this section describes the Registration Reply
+   handling by a mobile node in each of these three categories.
+
+3.6.2.1.  Validity Checks
+
+   Registration Replies with an invalid, non-zero UDP checksum MUST be
+   silently discarded.
+
+   In addition, the low-order 32 bits of the Identification field in the
+   Registration Reply MUST be compared to the low-order 32 bits of the
+   Identification field in the most recent Registration Request sent to
+   the replying agent.  If they do not match, the Reply MUST be silently
+   discarded.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 47]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   Also, the Registration Reply MUST be checked for presence of an
+   authorization-enabling extension.  For all Registration Reply
+   messages containing a status code indicating status from the home
+   agent, the mobile node MUST check for the presence of an
+   authorization-enabling extension, acting in accordance with the Code
+   field in the Reply.  The rules are as follows:
+
+   a.  If the mobile node and the foreign agent share a Mobility
+       Security Association, exactly one Mobile-Foreign Authentication
+       Extension MUST be present in the Registration Reply, and the
+       mobile node MUST check the Authenticator value in the Extension.
+       If no Mobile-Foreign Authentication Extension is found, or if
+       more than one Mobile-Foreign Authentication Extension is found,
+       or if the Authenticator is invalid, the mobile node MUST silently
+       discard the Reply and SHOULD log the event as a security
+       exception.
+
+   b.  If the Code field indicates that service is denied by the home
+       agent, or if the Code field indicates that the registration was
+       accepted by the home agent, exactly one Mobile-Home
+       Authentication Extension MUST be present in the Registration
+       Reply, and the mobile node MUST check the Authenticator value in
+       the Extension.  If the Registration Reply was generated by the
+       home agent but no Mobile-Home Authentication Extension is found,
+       or if more than one Mobile-Home Authentication Extension is
+       found, or if the Authenticator is invalid, the mobile node MUST
+       silently discard the Reply and SHOULD log the event as a security
+       exception.
+
+   If the Code field indicates an authentication failure, either at the
+   foreign agent or the home agent, then it is quite possible that any
+   authenticators in the Registration Reply will also be in error.  This
+   could happen, for example, if the shared secret between the mobile
+   node and home agent was erroneously configured.  The mobile node
+   SHOULD log such errors as security exceptions.
+
+3.6.2.2.  Registration Request Accepted
+
+   If the Code field indicates that the request has been accepted, the
+   mobile node SHOULD configure its routing table appropriately for its
+   current point of attachment (Section 4.2.1).
+
+   If the mobile node is returning to its home network and that network
+   is one that implements ARP, the mobile node MUST follow the
+   procedures described in Section 4.6 with regard to ARP, proxy ARP,
+   and gratuitous ARP.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 48]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   If the mobile node has registered on a foreign network, it SHOULD
+   re-register before the expiration of the Lifetime of its
+   registration.  As described in Section 3.6, for each pending
+   Registration Request, the mobile node MUST maintain the remaining
+   lifetime of this pending registration, as well as the original
+   Lifetime from the Registration Request.  When the mobile node
+   receives a valid Registration Reply, the mobile node MUST decrease
+   its view of the remaining lifetime of the registration by the amount
+   by which the home agent decreased the originally requested Lifetime.
+   This procedure is equivalent to the mobile node starting a timer for
+   the granted Lifetime at the time it sent the Registration Request,
+   even though the granted Lifetime is not known to the mobile node
+   until the Registration Reply is received.  Since the Registration
+   Request is certainly sent before the home agent begins timing the
+   registration Lifetime (also based on the granted Lifetime), this
+   procedure ensures that the mobile node will re-register before the
+   home agent expires and deletes the registration, in spite of possibly
+   non-negligible transmission delays for the original Registration
+   Request and Reply that started the timing of the Lifetime at the
+   mobile node and its home agent.
+
+3.6.2.3.  Registration Request Denied
+
+   If the Code field indicates that service is being denied, the mobile
+   node SHOULD log the error.  In certain cases, the mobile node may be
+   able to "repair" the error.  These include:
+
+   Code 69: (Denied by foreign agent, requested Lifetime too long)
+
+      In this case, the Lifetime field in the Registration Reply will
+      contain the maximum Lifetime value that the foreign agent is
+      willing to accept in any Registration Request.  The mobile node
+      MAY attempt to register with this same agent, using a Lifetime in
+      the Registration Request that MUST be less than or equal to the
+      value specified in the Reply.
+
+   Code 133: (Denied by home agent, registration Identification
+      mismatch)
+
+      In this case, the Identification field in the Registration Reply
+      will contain a value that allows the mobile node to synchronize
+      with the home agent, based upon the style of replay protection in
+      effect (Section 5.7).  The mobile node MUST adjust the parameters
+      it uses to compute the Identification field based upon the
+      information in the Registration Reply, before issuing any future
+      Registration Requests.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 49]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   Code 136: (Denied by home agent, unknown home agent address)
+
+      This code is returned by a home agent when the mobile node is
+      performing dynamic home agent address resolution as described in
+      Sections 3.6.1.1 and 3.6.1.2.  In this case, the Home Agent field
+      within the Reply will contain the unicast IP address of the home
+      agent returning the Reply.  The mobile node MAY then attempt to
+      register with this home agent in future Registration Requests.  In
+      addition, the mobile node SHOULD adjust the parameters it uses to
+      compute the Identification field based upon the corresponding
+      field in the Registration Reply, before issuing any future
+      Registration Requests.
+
+3.6.3.  Registration Retransmission
+
+   When no Registration Reply has been received within a reasonable
+   time, another Registration Request MAY be transmitted.  When
+   timestamps are used, a new registration Identification is chosen for
+   each retransmission; thus, it counts as a new registration.  When
+   nonces are used, the unanswered Request is retransmitted unchanged;
+   thus, the retransmission does not count as a new registration
+   (Section 5.7).  In this way, a retransmission will not require the
+   home agent to resynchronize with the mobile node by issuing another
+   nonce in the case in which the original Registration Request (rather
+   than its Registration Reply) was lost by the network.
+
+   The maximum time until a new Registration Request is sent SHOULD be
+   no greater than the requested Lifetime of the Registration Request.
+   The minimum value SHOULD be large enough to account for the size of
+   the messages, twice the round-trip time for transmission to the home
+   agent, and at least an additional 100 milliseconds to allow for
+   processing the messages before responding.  The round-trip time for
+   transmission to the home agent will be at least as large as the time
+   required to transmit the messages at the link speed of the mobile
+   node's current point of attachment.  Some circuits add another 200
+   milliseconds of satellite delay in the total round-trip time to the
+   home agent.  The minimum time between Registration Requests MUST NOT
+   be less than 1 second.  Each successive retransmission timeout period
+   SHOULD be at least twice the previous period, as long as that is less
+   than the maximum as specified above.
+
+3.7.  Foreign Agent Considerations
+
+   The foreign agent plays a mostly passive role in Mobile IP
+   registration.  It relays Registration Requests between mobile nodes
+   and home agents, and, when it provides the care-of address,
+
+
+
+
+
+Perkins                      Standards Track                   [Page 50]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   decapsulates datagrams for delivery to the mobile node.  It SHOULD
+   also send periodic Agent Advertisement messages to advertise its
+   presence as described in Section 2.3, if not detectable by link-layer
+   means.
+
+   A foreign agent MUST NOT transmit a Registration Request, unless the
+   request is being relayed from a mobile node to that mobile node's
+   home agent.  A foreign agent MUST NOT transmit a Registration Reply
+   except when relaying a Registration Reply received from a mobile
+   node's home agent, or when replying to a Registration Request
+   received from a mobile node in the case in which the foreign agent is
+   denying service to the mobile node.  In particular, a foreign agent
+   MUST NOT generate a Registration Request or Reply because a mobile
+   node's registration Lifetime has expired.  A foreign agent also MUST
+   NOT originate a Registration Request message that asks for
+   deregistration of a mobile node; however, it MUST relay well-formed
+   (de)Registration Requests originated by a mobile node.
+
+3.7.1.  Configuration and Registration Tables
+
+   Each foreign agent MUST be configured with a care-of address.  In
+   addition, for each pending or current registration the foreign agent
+   MUST maintain a visitor list entry containing the following
+   information obtained from the mobile node's Registration Request:
+
+   o  the link-layer source address of the mobile node
+
+   o  the IP Source Address (the mobile node's home address) or its co-
+      located care-of address (see description of the 'R' bit in Section
+      2.1.1)
+
+   o  the IP Destination Address (as specified in Section 3.6.1.1)
+
+   o  the UDP Source Port
+
+   o  the home agent address
+
+   o  the Identification field
+
+   o  the requested registration Lifetime, and
+
+   o  the remaining Lifetime of the pending or current registration
+
+   If there is an NAI extension in the Registration Request message
+   (often, for example, when the mobile node's Home Address is zero),
+   then the foreign agent MUST follow the procedures specified in RFC
+
+
+
+
+
+Perkins                      Standards Track                   [Page 51]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   2794 [2].  In particular, if the foreign agent cannot manage pending
+   Registration Request records with such a zero Home Address for the
+   mobile node, the foreign agent MUST return a Registration Reply with
+   a code indicating NONZERO_HOMEADDR_REQD (see [2]).
+
+   The foreign agent MAY configure a maximum number of pending
+   registrations that it is willing to maintain (typically 5).
+   Additional registrations SHOULD then be rejected by the foreign agent
+   with Code 66.  The foreign agent MAY delete any pending Registration
+   Request after the request has been pending for more than 7 seconds;
+   in this case, the foreign agent SHOULD reject the Request with Code
+   78 (registration timeout).
+
+   As with any node on the Internet, a foreign agent MAY also share
+   Mobility Security Associations with any other nodes.  When relaying a
+   Registration Request from a mobile node to its home agent, if the
+   foreign agent shares a Mobility Security Association with the home
+   agent, it MUST add a Foreign-Home Authentication Extension to the
+   Request.  In this case, when the Registration Reply has nonzero
+   Lifetime, the foreign agent MUST check the required Foreign-Home
+   Authentication Extension in the Registration Reply from the home
+   agent (Sections 3.3 and 3.4).  Similarly, when receiving a
+   Registration Request from a mobile node, if the foreign agent shares
+   a Mobility Security Association with the mobile node, it MUST check
+   the required Mobile-Foreign Authentication Extension in the Request
+   and MUST add a Mobile-Foreign Authentication Extension to the
+   Registration Reply to the mobile node.
+
+3.7.2.  Receiving Registration Requests
+
+   If the foreign agent accepts a Registration Request from a mobile
+   node, it checks to make sure that the indicated home agent address
+   does not belong to any network interface of the foreign agent.  If
+   not, the foreign agent then MUST relay the Request to the indicated
+   home agent.  Otherwise, if the foreign agent denies the Request, it
+   MUST send a Registration Reply to the mobile node with an appropriate
+   denial code, except in cases where the foreign agent would be
+   required to send out more than one such denial per second to the same
+   mobile node.  The following sections describe this behavior in more
+   detail.
+
+   If the foreign agent has configured one of its network interfaces
+   with the IP address specified by the mobile node as its home agent
+   address, the foreign agent MUST NOT forward the Request again.  If
+   the foreign agent serves the mobile node as a home agent, the foreign
+   agent follows the procedures specified in Section 3.8.2.  Otherwise,
+
+
+
+
+
+Perkins                      Standards Track                   [Page 52]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   if the foreign agent does not serve the mobile node as a home agent,
+   the foreign agent rejects the Registration Request with Code 194
+   (Invalid Home Agent Address).
+
+   If a foreign agent receives a Registration Request from a mobile node
+   in its visitor list, the existing visitor list entry for the mobile
+   node SHOULD NOT be deleted or modified until the foreign agent
+   receives a valid Registration Reply from the home agent with a code
+   indicating success.  The foreign agent MUST record the new pending
+   Request as a separate part of the existing visitor list entry for the
+   mobile node.  If the Registration Request asks for deregistration,
+   the existing visitor list entry for the mobile node SHOULD NOT be
+   deleted until the foreign agent has received a successful
+   Registration Reply.  If the Registration Reply indicates that the
+   Request (for registration or deregistration) was denied by the home
+   agent, the existing visitor list entry for the mobile node MUST NOT
+   be modified as a result of receiving the Registration Reply.
+
+3.7.2.1.  Validity Checks
+
+   Registration Requests with an invalid, non-zero UDP checksum MUST be
+   silently discarded.  Requests with non-zero bits in reserved fields
+   MUST be rejected with Code 70 (poorly formed Request).  Requests with
+   the 'D' bit set to 0, nonzero Lifetime, and specifying a care-of
+   address not offered by the foreign agent, MUST be rejected with Code
+   77 (invalid care-of address).
+
+   Also, the authentication in the Registration Request MUST be checked.
+   If the foreign agent and the mobile node share a Mobility Security
+   Association, exactly one Mobile-Foreign Authentication Extension MUST
+   be present in the Registration Request, and the foreign agent MUST
+   check the Authenticator value in the Extension.  If no Mobile-Foreign
+   Authentication Extension is found, or if more than one Mobile-Foreign
+   Authentication Extension is found, or if the Authenticator is
+   invalid, the foreign agent MUST silently discard the Request and
+   SHOULD log the event as a security exception.  The foreign agent also
+   SHOULD send a Registration Reply to the mobile node with Code 67.
+
+3.7.2.2.  Forwarding a Valid Request to the Home Agent
+
+   If the foreign agent accepts the mobile node's Registration Request,
+   it MUST relay the Request to the mobile node's home agent as
+   specified in the Home Agent field of the Registration Request.  The
+   foreign agent MUST NOT modify any of the fields beginning with the
+   fixed portion of the Registration Request up through and including
+   the Mobile-Home Authentication Extension or other authentication
+   extension supplied by the mobile node as an authorization-enabling
+
+
+
+
+Perkins                      Standards Track                   [Page 53]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   extension for the home agent.  Otherwise, an authentication failure
+   is very likely to occur at the home agent.  In addition, the foreign
+   agent proceeds as follows:
+
+   o  It MUST process and remove any extensions that do not precede any
+      authorization-enabling extension,
+
+   o  It MAY append any of its own non-authentication Extensions of
+      relevance to the home agent, if applicable, and
+
+   o  If the foreign agent shares a Mobility Security Association with
+      the home agent, and the Request has Lifetime != 0, then it MUST
+      append the Foreign-Home Authentication Extension.
+
+   Specific fields within the IP header and the UDP header of the
+   relayed Registration Request MUST be set as follows:
+
+      IP Source Address
+
+         The care-of address offered by the foreign agent for the mobile
+         node sending the Registration Request.
+
+      IP Destination Address
+
+         Copied from the Home Agent field within the Registration
+         Request.
+
+      UDP Source Port
+
+         variable
+
+      UDP Destination Port
+
+         434
+
+   After forwarding a valid Registration Request to the home agent, the
+   foreign agent MUST begin timing the remaining lifetime of the pending
+   registration based on the Lifetime in the Registration Request.  If
+   this lifetime expires before receiving a valid Registration Reply,
+   the foreign agent MUST delete its visitor list entry for this pending
+   registration.
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 54]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+3.7.2.3.  Denying Invalid Requests
+
+   If the foreign agent denies the mobile node's Registration Request
+   for any reason, it SHOULD send the mobile node a Registration Reply
+   with a suitable denial code.  In such a case, the Home Address, Home
+   Agent, and Identification fields within the Registration Reply are
+   copied from the corresponding fields of the Registration Request.
+
+   If the Reserved field is nonzero, the foreign agent MUST deny the
+   Request and SHOULD return a Registration Reply with Status Code 70 to
+   the mobile node.  If the Request is being denied because the
+   requested Lifetime is too long, the foreign agent sets the Lifetime
+   in the Reply to the maximum Lifetime value it is willing to accept in
+   any Registration Request, and sets the Code field to 69.  Otherwise,
+   the Lifetime SHOULD be copied from the Lifetime field in the Request.
+
+   Specific fields within the IP header and the UDP header of the
+   Registration Reply MUST be set as follows:
+
+      IP Source Address
+
+         Copied from the IP Destination Address of the Registration
+         Request, unless the "All Agents Multicast" address was used.
+         In this case, the foreign agent's address (on the interface
+         from which the message will be sent) MUST be used.
+
+      IP Destination Address
+
+         If the Registration Reply is generated by the foreign agent in
+         order to reject a mobile node's Registration Request, and the
+         Registration Request contains a Home Address that is not
+         0.0.0.0, then the IP Destination Address is copied from the
+         Home Address field of the Registration Request.  Otherwise, if
+         the Registration Reply is received from the home agent, and
+         contains a Home Address that is not 0.0.0.0, then the IP
+         Destination Address is copied from the Home Address field of
+         the Registration Reply.  Otherwise, the IP Destination Address
+         of the Registration Reply is set to be 255.255.255.255.
+
+      UDP Source Port
+
+         434
+
+      UDP Destination Port
+
+         Copied from the UDP Source Port of the Registration Request.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 55]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+3.7.3.  Receiving Registration Replies
+
+   The foreign agent updates its visitor list when it receives a valid
+   Registration Reply from a home agent.  It then relays the
+   Registration Reply to the mobile node.  The following sections
+   describe this behavior in more detail.
+
+   If upon relaying a Registration Request to a home agent, the foreign
+   agent receives an ICMP error message instead of a Registration Reply,
+   then the foreign agent SHOULD send to the mobile node a Registration
+   Reply with an appropriate "home agent unreachable" failure code
+   (within the range 80-95, inclusive).  See Section 3.7.2.3 for details
+   on building the Registration Reply.
+
+3.7.3.1.  Validity Checks
+
+   Registration Replies with an invalid, non-zero UDP checksum MUST be
+   silently discarded.
+
+   When a foreign agent receives a Registration Reply message, it MUST
+   search its visitor list for a pending Registration Request with the
+   same mobile node home address as indicated in the Reply.  If there
+   are multiple entries with the same home address, and if the
+   Registration Reply has the Mobile Node NAI extension [2], the foreign
+   agent MUST use the NAI to disambiguate the pending Registration
+   Requests with the same home address.  If no matching pending Request
+   is found, and if the Registration Reply does not correspond with any
+   pending Registration Request with a zero mobile node home address
+   (see Section 3.7.1), the foreign agent MUST silently discard the
+   Reply.  The foreign agent MUST also silently discard the Reply if the
+   low-order 32 bits of the Identification field in the Reply do not
+   match those in the Request.
+
+   Also, the authentication in the Registration Reply MUST be checked.
+   If the foreign agent and the home agent share a Mobility Security
+   Association, exactly one Foreign-Home Authentication Extension MUST
+   be present in the Registration Reply, and the foreign agent MUST
+   check the Authenticator value in the Extension.  If no Foreign-Home
+   Authentication Extension is found, or if more than one Foreign-Home
+   Authentication Extension is found, or if the Authenticator is
+   invalid, the foreign agent MUST silently discard the Reply and SHOULD
+   log the event as a security exception.  The foreign agent also MUST
+   reject the mobile node's registration and SHOULD send a Registration
+   Reply to the mobile node with Code 68.
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 56]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+3.7.3.2.  Forwarding Replies to the Mobile Node
+
+   A Registration Reply that satisfies the validity checks of Section
+   3.8.2.1 is relayed to the mobile node.  The foreign agent MUST also
+   update its visitor list entry for the mobile node to reflect the
+   results of the Registration Request, as indicated by the Code field
+   in the Reply.  If the code indicates that the home agent has accepted
+   the registration and the Lifetime field is nonzero, the foreign agent
+   SHOULD set the Lifetime in the visitor list entry to the minimum of
+   the following two values:
+
+   o  the value specified in the Lifetime field of the Registration
+      Reply, and
+
+   o  the foreign agent's own maximum value for allowable registration
+      Lifetime.
+
+   If, instead, the code indicates that the Lifetime field is zero, the
+   foreign agent MUST delete its visitor list entry for the mobile node.
+   Finally, if the code indicates that the registration was denied by
+   the home agent, the foreign agent MUST delete its pending
+   registration list entry, but not its visitor list entry, for the
+   mobile node.
+
+   The foreign agent MUST NOT modify any of the fields beginning with
+   the fixed portion of the Registration Reply up through and including
+   the Mobile-Home Authentication Extension.  Otherwise, an
+   authentication failure is very likely to occur at the mobile node.
+   In addition, the foreign agent SHOULD perform the following
+   additional procedures:
+
+   o  It MUST process and remove any Extensions that are not covered by
+      any authorization-enabling extension,
+
+   o  It MAY append its own non-authentication Extensions that supply
+      information to the mobile node, if applicable, and
+
+   o  It MUST append the Mobile-Foreign Authentication Extension, if the
+      foreign agent shares a Mobility Security Association with the
+      mobile node.
+
+   Specific fields within the IP header and the UDP header of the
+   relayed Registration Reply are set according to the same rules
+   specified in Section 3.7.2.3.
+
+   After forwarding a valid Registration Reply to the mobile node, the
+   foreign agent MUST update its visitor list entry for this
+   registration as follows.  If the Registration Reply indicates that
+
+
+
+Perkins                      Standards Track                   [Page 57]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   the registration was accepted by the home agent, the foreign agent
+   resets its timer of the lifetime of the registration to the Lifetime
+   granted in the Registration Reply; unlike the mobile node's timing of
+   the registration lifetime as described in Section 3.6.2.2, the
+   foreign agent considers this lifetime to begin when it forwards the
+   Registration Reply message, ensuring that the foreign agent will not
+   expire the registration before the mobile node does.  On the other
+   hand, if the Registration Reply indicates that the registration was
+   rejected by the home agent, the foreign agent deletes its visitor
+   list entry for this attempted registration.
+
+3.8.  Home Agent Considerations
+
+   Home agents play a reactive role in the registration process.  The
+   home agent receives Registration Requests from the mobile node
+   (perhaps relayed by a foreign agent), updates its record of the
+   mobility bindings for this mobile node, and issues a suitable
+   Registration Reply in response to each.
+
+   A home agent MUST NOT transmit a Registration Reply except when
+   replying to a Registration Request received from a mobile node.  In
+   particular, the home agent MUST NOT generate a Registration Reply to
+   indicate that the Lifetime has expired.
+
+3.8.1.  Configuration and Registration Tables
+
+   Each home agent MUST be configured with an IP address and with the
+   prefix size for the home network.  The home agent MUST be configured
+   with the Mobility Security Association of each authorized mobile node
+   that it is serving as a home agent.
+
+   When the home agent accepts a valid Registration Request from a
+   mobile node that it serves as a home agent, the home agent MUST
+   create or modify the entry for this mobile node in its mobility
+   binding list containing:
+
+   o  the mobile node's home address
+
+   o  the mobile node's care-of address
+
+   o  the Identification field from the Registration Reply
+
+   o  the remaining Lifetime of the registration
+
+   The home agent MAY optionally offer the capability to dynamically
+   associate a home address to a mobile node upon receiving a
+   Registration Request from that mobile node.  The method by which a
+   home address is allocated to the mobile node is beyond the scope of
+
+
+
+Perkins                      Standards Track                   [Page 58]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   this document, but see [2].  After the home agent makes the
+   association of the home address to the mobile node, the home agent
+   MUST put that home address into the Home Address field of the
+   Registration Reply.
+
+   The home agent MAY also maintain Mobility Security Associations with
+   various foreign agents.  When receiving a Registration Request from a
+   foreign agent, if the home agent shares a Mobility Security
+   Association with the foreign agent, the home agent MUST check the
+   Authenticator in the required Foreign-Home Authentication Extension
+   in the message, based on this Mobility Security Association, unless
+   the Lifetime field equals 0.  When processing a Registration Request
+   with Lifetime = 0, the HA MAY skip checking for the presence and
+   validity of a Foreign-Home Authentication Extension.  Similarly, when
+   sending a Registration Reply to a foreign agent, if the home agent
+   shares a Mobility Security Association with the foreign agent, the
+   home agent MUST include a Foreign-Home Authentication Extension in
+   the message, based on this Mobility Security Association.
+
+3.8.2.  Receiving Registration Requests
+
+   If the home agent accepts an incoming Registration Request, it MUST
+   update its record of the mobile node's mobility binding(s) and SHOULD
+   send a Registration Reply with a suitable code.  Otherwise (the home
+   agent has denied the Request), it SHOULD in most cases send a
+   Registration Reply with an appropriate code specifying the reason the
+   Request was denied.  The following sections describe this behavior in
+   more detail.  If the home agent does not support broadcasts (see
+   Section 4.3), it MUST ignore the 'B' bit (as opposed to rejecting the
+   Registration Request).
+
+3.8.2.1.  Validity Checks
+
+   Registration Requests with an invalid, non-zero UDP checksum MUST be
+   silently discarded by the home agent.
+
+   The authentication in the Registration Request MUST be checked.  This
+   involves the following operations:
+
+   a.  The home agent MUST check for the presence of at least one
+       authorization-enabling extension, and ensure that all indicated
+       authentications are carried out.  At least one authorization-
+       enabling extension MUST be present in the Registration Request,
+       and the home agent MUST either check the Authenticator value in
+       the extension or verify that the Authenticator Value has been
+       checked by another agent with which it has a security
+       association.
+
+
+
+
+Perkins                      Standards Track                   [Page 59]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+       If the home agent receives a Registration Request from a mobile
+       node with which it does not have any security association, the
+       home agent MUST silently discard the Registration Request.
+
+       If the home agent receives a Registration Request without any
+       authorization-enabling extension, the home agent MUST silently
+       discard the Registration Request.
+
+       If the Authenticator is invalid, the home agent MUST reject the
+       mobile node's registration.  Further action to be taken in this
+       case depends upon whether the Request has a valid Foreign-Home
+       authentication extension (as follows):
+
+       *  If there is a valid Foreign-Home authentication extension, the
+          home agent MUST send a Registration Reply with Code 131.
+
+       *  Otherwise, if there is no Foreign-Home Security Association,
+          the home agent MAY send a Registration Reply with Code 131.
+          If the home agent sends a Registration Reply, it MUST contain
+          a valid Mobile-Home Authentication Extension.  In constructing
+          the Reply, the home agent SHOULD choose a security association
+          that is likely to exist in the mobile node; for example, this
+          may be an older security association or one with a longer
+          lifetime than the one that the mobile node attempted to use in
+          its Request.  Deployments should take care when updating
+          security associations to ensure that there is at least one
+          common security association shared between the mobile node and
+          home agent.  In any case of a failed Authenticator, the home
+          agent MUST then discard the Request without further processing
+          and SHOULD log the error as a security exception.
+
+   b.  The home agent MUST check that the registration Identification
+       field is correct using the context selected by the SPI within the
+       authorization-enabling extension that the home agent used to
+       authenticate the mobile node's Registration Request.  See Section
+       5.7 for a description of how this is performed.  If incorrect,
+       the home agent MUST reject the Request and SHOULD send a
+       Registration Reply to the mobile node with Code 133, including an
+       Identification field computed in accordance with the rules
+       specified in Section 5.7.  The home agent MUST do no further
+       processing with such a Request, though it SHOULD log the error as
+       a security exception.
+
+   c.  If the home agent shares a Mobility Security Association with the
+       foreign agent, and this is a Registration Request (has non-zero
+       Lifetime), the home agent MUST check for the presence of a valid
+       Foreign-Home Authentication Extension.  Exactly one Foreign-Home
+       Authentication Extension MUST be present in the Registration
+
+
+
+Perkins                      Standards Track                   [Page 60]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+       Request in this case, and the home agent MUST check the
+       Authenticator Value in the Extension.  If no Foreign-Home
+       Authentication Extension is found, or if more than one Foreign-
+       Home Authentication Extension is found, or if the Authenticator
+       is invalid, the home agent MUST reject the mobile node's
+       registration and SHOULD send a Registration Reply to the mobile
+       node with Code 132.  The home agent MUST then discard the Request
+       and SHOULD log the error as a security exception.
+
+   d.  If the home agent and the foreign agent do not share a Mobility
+       Security Association, and the Registration contains a Foreign-
+       Home Authentication Extension, the home agent MUST discard the
+       Request and SHOULD log the error as a security exception.
+
+   In addition to checking the authentication in the Registration
+   Request, home agents MUST deny Registration Requests that are sent to
+   the subnet-directed broadcast address of the home network (as opposed
+   to being unicast to the home agent).  The home agent MUST discard the
+   Request and SHOULD return a Registration Reply with a Code of 136.
+   In this case, the Registration Reply will contain the home agent's
+   unicast address, so that the mobile node can re-issue the
+   Registration Request with the correct home agent address.
+
+   Note that some routers change the IP Destination Address of a
+   datagram from a subnet-directed broadcast address to 255.255.255.255
+   before injecting it into the destination subnet.  In this case, home
+   agents that attempt to pick up dynamic home agent discovery requests
+   by binding a socket explicitly to the subnet-directed broadcast
+   address will not see such packets.  Home agent implementors should be
+   prepared for both the subnet-directed broadcast address and
+   255.255.255.255 if they wish to support dynamic home agent discovery.
+
+3.8.2.2.  Accepting a Valid Request
+
+   If the Registration Request satisfies the validity checks in Section
+   3.8.2.1, and the home agent is able to accommodate the Request, the
+   home agent MUST update its mobility binding list for the requesting
+   mobile node and MUST return a Registration Reply to the mobile node.
+   In this case, the code in the Registration Reply will be either 0 if
+   the home agent supports simultaneous mobility bindings, or 1 if it
+   does not.  See Section 3.8.3 for details on building the Registration
+   Reply message.
+
+   The home agent updates its record of the mobile node's mobility
+   bindings as follows, based on the fields in the Registration Request:
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 61]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   o  If the Lifetime is zero and the Care-of Address equals the mobile
+      node's home address, the home agent deletes all of the entries in
+      the mobility binding list for the requesting mobile node.  This is
+      how a mobile node requests that its home agent cease providing
+      mobility services.
+
+   o  If the Lifetime is zero and the Care-of Address does not equal the
+      mobile node's home address, the home agent deletes only the entry
+      containing the specified Care-of Address from the mobility binding
+      list for the requesting mobile node.  Any other active entries
+      containing other care-of addresses will remain active.
+
+   o  If the Lifetime is nonzero, the home agent adds an entry
+      containing the requested Care-of Address to the mobility binding
+      list for the mobile node.  If the 'S' bit is set and the home
+      agent supports simultaneous mobility bindings, the previous
+      mobility binding entries are retained.  Otherwise, the home agent
+      removes all previous entries in the mobility binding list for the
+      mobile node.
+
+   In all cases, the home agent MUST send a Registration Reply to the
+   source of the Registration Request, which might indeed be a different
+   foreign agent than that whose care-of address is being
+   (de)registered.  If the home agent shares a Mobility Security
+   Association with the foreign agent whose care-of address is being
+   deregistered, and that foreign agent is different from the one that
+   relayed the Registration Request, the home agent MAY additionally
+   send a Registration Reply to the foreign agent whose care-of address
+   is being deregistered.  The home agent MUST NOT send such a Reply if
+   it does not share a Mobility Security Association with the foreign
+   agent.  If no Reply is sent, the foreign agent's visitor list will
+   expire naturally when the original Lifetime expires.
+
+   When a foreign agent relays a deregistration message containing a
+   care-of address that it does not own, it MUST NOT add a Foreign-Home
+   Authentication Extension to that deregistration.  See Section 3.5.4
+   for more details.
+
+   The home agent MUST NOT increase the Lifetime above that specified by
+   the mobile node in the Registration Request.  However, it is not an
+   error for the mobile node to request a Lifetime longer than the home
+   agent is willing to accept.  In this case, the home agent simply
+   reduces the Lifetime to a permissible value and returns this value in
+   the Registration Reply.  The Lifetime value in the Registration Reply
+   informs the mobile node of the granted Lifetime of the registration,
+   indicating when it SHOULD re-register in order to maintain continued
+
+
+
+
+
+Perkins                      Standards Track                   [Page 62]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   service.  After the expiration of this registration Lifetime, the
+   home agent MUST delete its entry for this registration in its
+   mobility binding list.
+
+   If the Registration Request duplicates an accepted current
+   Registration Request, the new Lifetime MUST NOT extend beyond the
+   Lifetime originally granted.  A Registration Request is a duplicate
+   if the home address, care-of address, and Identification fields all
+   equal those of an accepted current registration.
+
+   In addition, if the home network implements ARP [16], and the
+   Registration Request asks the home agent to create a mobility binding
+   for a mobile node that previously had no binding (the mobile node was
+   previously assumed to be at home), then the home agent MUST follow
+   the procedures described in Section 4.6 with regard to ARP, proxy
+   ARP, and gratuitous ARP.  If the mobile node already had a previous
+   mobility binding, the home agent MUST continue to follow the rules
+   for proxy ARP described in Section 4.6.
+
+3.8.2.3.  Denying an Invalid Request
+
+   If the Registration Request does not satisfy all of the validity
+   checks in Section 3.8.2.1, or the home agent is unable to accommodate
+   the Request, the home agent SHOULD return a Registration Reply to the
+   mobile node with a Code that indicates the reason for the error.  If
+   a foreign agent was involved in relaying the Request, this allows the
+   foreign agent to delete its pending visitor list entry.  Also, this
+   informs the mobile node of the reason for the error such that it may
+   attempt to fix the error and issue another Request.
+
+   This section lists a number of reasons the home agent might reject a
+   Request, and provides the code value it should use in each instance.
+   See Section 3.8.3 for additional details on building the Registration
+   Reply message.
+
+   Many reasons for rejecting a registration are administrative in
+   nature.  For example, a home agent can limit the number of
+   simultaneous registrations for a mobile node, by rejecting any
+   registrations that would cause its limit to be exceeded, and
+   returning a Registration Reply with a Code of 135.  Similarly, a home
+   agent may refuse to grant service to mobile nodes that have entered
+   unauthorized service areas by returning a Registration Reply with a
+   Code of 129.
+
+   Requests with non-zero bits in reserved fields MUST be rejected with
+   Code 134 (poorly formed Request).
+
+
+
+
+
+Perkins                      Standards Track                   [Page 63]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+3.8.3.  Sending Registration Replies
+
+   If the home agent accepts a Registration Request, it then MUST update
+   its record of the mobile node's mobility binding(s) and SHOULD send a
+   Registration Reply with a suitable Code.  Otherwise (the home agent
+   has denied the Request), it SHOULD in most cases send a Registration
+   Reply with an appropriate Code specifying the reason the Request was
+   denied.  The following sections provide additional detail for the
+   values the home agent MUST supply in the fields of Registration Reply
+   messages.
+
+3.8.3.1.  IP/UDP Fields
+
+   This section provides the specific rules by which home agents pick
+   values for the IP and UDP header fields of a Registration Reply.
+
+      IP Source Address
+
+         Copied from the IP Destination Address of the Registration
+         Request, unless a multicast or broadcast address was used.  If
+         the IP Destination Address of the Registration Request was a
+         broadcast or multicast address, the IP Source Address of the
+         Registration Reply MUST be set to the home agent's (unicast) IP
+         address.
+
+      IP Destination Address
+
+         Copied from the IP Source Address of the Registration Request.
+
+      UDP Source Port
+
+         Copied from the UDP Destination Port of the Registration
+         Request.
+
+      UDP Destination Port
+
+         Copied from the UDP Source Port of the Registration Request.
+
+   When sending a Registration Reply in response to a Registration
+   Request that requested deregistration of the mobile node (the
+   Lifetime is zero and the Care-of Address equals the mobile node's
+   home address) and in which the IP Source Address was also set to the
+   mobile node's home address (this is the normal method used by a
+   mobile node to deregister when it returns to its home network), the
+   IP Destination Address in the Registration Reply will be set to the
+   mobile node's home address, as copied from the IP Source Address of
+   the Request.
+
+
+
+
+Perkins                      Standards Track                   [Page 64]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   In this case, when transmitting the Registration Reply, the home
+   agent MUST transmit the Reply directly onto the home network as if
+   the mobile node were at home, bypassing any mobility binding list
+   entry that may still exist at the home agent for the destination
+   mobile node.  In particular, for a mobile node returning home after
+   being registered with a care-of address, if the mobile node's new
+   Registration Request is not accepted by the home agent, the mobility
+   binding list entry for the mobile node will still indicate that
+   datagrams addressed to the mobile node should be tunneled to the
+   mobile node's registered care-of address; when sending the
+   Registration Reply indicating the rejection of this Request, this
+   existing binding list entry MUST be ignored, and the home agent MUST
+   transmit this Reply as if the mobile node were at home.
+
+3.8.3.2.  Registration Reply Fields
+
+   This section provides the specific rules by which home agents pick
+   values for the fields within the fixed portion of a Registration
+   Reply.
+
+   The Code field of the Registration Reply is chosen in accordance with
+   the rules specified in the previous sections.  When replying to an
+   accepted registration, a home agent SHOULD respond with Code 1 if it
+   does not support simultaneous registrations.
+
+   The Lifetime field MUST be copied from the corresponding field in the
+   Registration Request, unless the requested value is greater than the
+   maximum length of time the home agent is willing to provide the
+   requested service.  In such a case, the Lifetime MUST be set to the
+   length of time that service will actually be provided by the home
+   agent.  This reduced Lifetime SHOULD be the maximum Lifetime allowed
+   by the home agent (for this mobile node and care-of address).
+
+   If the Home Address field of the Registration Request is non-zero, it
+   MUST be copied into the Home Address field of the Registration Reply
+   message.  If the home agent cannot support the specified nonzero
+   unicast address in the Home Address field of the Registration
+   Request, then the home agent MUST reject the Registration Request
+   with a Code of 129.
+
+   Otherwise, if the Home Address field of the Registration Request is
+   zero as specified in Section 3.6, the home agent SHOULD arrange for
+   the selection of a home address for the mobile node, and insert the
+   selected address into the Home Address field of the Registration
+   Reply message.  See [2] for further relevant details in the case
+   where mobile nodes identify themselves using an NAI instead of their
+   IP home address.
+
+
+
+
+Perkins                      Standards Track                   [Page 65]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   If the Home Agent field in the Registration Request contains a
+   unicast address of this home agent, then that field MUST be copied
+   into the Home Agent field of the Registration Reply.  Otherwise, the
+   home agent MUST set the Home Agent field in the Registration Reply to
+   its unicast address.  In this latter case, the home agent MUST reject
+   the registration with a suitable code (e.g., Code 136) to prevent the
+   mobile node from possibly being simultaneously registered with two or
+   more home agents.
+
+3.8.3.3.  Extensions
+
+   This section describes the ordering of any required and any optional
+   Mobile IP Extensions that a home agent appends to a Registration
+   Reply.  The following ordering MUST be followed:
+
+   a.  The IP header, followed by the UDP header, followed by the fixed-
+       length portion of the Registration Reply,
+
+   b.  If present, any non-authentication Extensions used by the mobile
+       node (which may or may not also be used by the foreign agent),
+
+   c.  The Mobile-Home Authentication Extension,
+
+   d.  If present, any non-authentication Extensions used only by the
+       foreign agent, and
+
+   e.  The Foreign-Home Authentication Extension, if present.
+
+   Note that items (a) and (c) MUST appear in every Registration Reply
+   sent by the home agent.  Items (b), (d), and (e) are optional.
+   However, item (e) MUST be included when the home agent and the
+   foreign agent share a Mobility Security Association.
+
+4.  Routing Considerations
+
+   This section describes how mobile nodes, home agents, and (possibly)
+   foreign agents cooperate to route datagrams to/from mobile nodes that
+   are connected to a foreign network.  The mobile node informs its home
+   agent of its current location using the registration procedure
+   described in Section 3.  See the protocol overview in Section 1.7 for
+   the relative locations of the mobile node's home address with respect
+   to its home agent, and the mobile node itself with respect to any
+   foreign agent with which it might attempt to register.
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 66]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+4.1.  Encapsulation Types
+
+   Home agents and foreign agents MUST support tunneling datagrams using
+   IP in IP encapsulation [14].  Any mobile node that uses a co-located
+   care-of address MUST support receiving datagrams tunneled using IP in
+   IP encapsulation.  Minimal encapsulation [15] and GRE encapsulation
+   [13] are alternate encapsulation methods that MAY optionally be
+   supported by mobility agents and mobile nodes.  The use of these
+   alternative forms of encapsulation, when requested by the mobile
+   node, is otherwise at the discretion of the home agent.
+
+4.2.  Unicast Datagram Routing
+
+4.2.1.  Mobile Node Considerations
+
+   When connected to its home network, a mobile node operates without
+   the support of mobility services.  That is, it operates in the same
+   way as any other (fixed) host or router.  The method by which a
+   mobile node selects a default router when connected to its home
+   network, or when away from home and using a co-located care-of
+   address, is outside the scope of this document.  ICMP Router
+   Advertisement [5] is one such method.
+
+   When registered on a foreign network, the mobile node chooses a
+   default router by the following rules:
+
+   o  If the mobile node is registered using a foreign agent care-of
+      address, it MAY use its foreign agent as a first-hop router.  The
+      foreign agent's MAC address can be learned from the foreign
+      agent's Agent Advertisement message.  Otherwise, the mobile node
+      MUST choose its default router from among the router addresses
+      advertised in the ICMP Router Advertisement portion of that Agent
+      Advertisement message.
+
+   o  If the mobile node is registered directly with its home agent
+      using a co-located care-of address, then the mobile node SHOULD
+      choose its default router from among those advertised in any ICMP
+      Router Advertisement message that it receives for which its
+      externally obtained care-of address and the router address match
+      under the network prefix.  If the mobile node's externally
+      obtained care-of address matches the IP source address of the
+      Agent Advertisement under the network prefix, the mobile node MAY
+      also consider that IP source address as another possible choice
+      for the IP address of a default router.  The network prefix MAY be
+      obtained from the Prefix-Lengths Extension in the Router
+      Advertisement, if present.  The prefix MAY also be obtained
+      through other mechanisms beyond the scope of this document.
+
+
+
+
+Perkins                      Standards Track                   [Page 67]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   While they are away from the home network, mobile nodes MUST NOT
+   broadcast ARP packets to find the MAC address of another Internet
+   node.  Thus, the (possibly empty) list of router addresses from the
+   ICMP Router Advertisement portion of the message is not useful for
+   selecting a default router, unless the mobile node has some means not
+   involving broadcast ARP and not specified within this document for
+   obtaining the MAC address of one of the routers in the list.
+   Similarly, in the absence of unspecified mechanisms for obtaining MAC
+   addresses on foreign networks, the mobile node MUST ignore redirects
+   to other routers on foreign networks.
+
+4.2.2.  Foreign Agent Considerations
+
+   Upon receipt of an encapsulated datagram sent to its advertised care-
+   of address, a foreign agent MUST compare the inner Destination
+   Address to those entries in its visitor list.  When the Destination
+   does not match the address of any mobile node currently in the
+   visitor list, the foreign agent MUST NOT forward the datagram without
+   modifications to the original IP header, because otherwise a routing
+   loop is likely to result.  The datagram SHOULD be silently discarded.
+   ICMP Destination Unreachable MUST NOT be sent when a foreign agent is
+   unable to forward an incoming tunneled datagram.  Otherwise, the
+   foreign agent forwards the decapsulated datagram to the mobile node.
+
+   The foreign agent MUST NOT advertise to other routers in its routing
+   domain, nor to any other mobile node, the presence of a mobile router
+   (Section 4.5) or mobile node in its visitor list.
+
+   The foreign agent MUST route datagrams it receives from registered
+   mobile nodes.  At a minimum, this means that the foreign agent must
+   verify the IP Header Checksum, decrement the IP Time To Live,
+   recompute the IP Header Checksum, and forward such datagrams to a
+   default router.
+
+   A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC
+   address on a foreign network.  It may obtain the MAC address by
+   copying the information from an Agent Solicitation or a Registration
+   Request transmitted from a mobile node.  A foreign agent's ARP cache
+   for the mobile node's IP address MUST NOT be allowed to expire before
+   the mobile node's visitor list entry expires, unless the foreign
+   agent has some way other than broadcast ARP to refresh its MAC
+   address associated with the mobile node's IP address.
+
+   Each foreign agent SHOULD support the mandatory features for reverse
+   tunneling [12].
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 68]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+4.2.3.  Home Agent Considerations
+
+   The home agent MUST be able to intercept any datagrams on the home
+   network addressed to the mobile node while the mobile node is
+   registered away from home.  Proxy and gratuitous ARP MAY be used in
+   enabling this interception, as specified in Section 4.6.
+
+   The home agent must examine the IP Destination Address of all
+   arriving datagrams to see if it is equal to the home address of any
+   of its mobile nodes registered away from home.  If so, the home agent
+   tunnels the datagram to the mobile node's currently registered care-
+   of address or addresses.  If the home agent supports the optional
+   capability of multiple simultaneous mobility bindings, it tunnels a
+   copy to each care-of address in the mobile node's mobility binding
+   list.  If the mobile node has no current mobility bindings, the home
+   agent MUST NOT attempt to intercept datagrams destined for the mobile
+   node, and thus will not in general receive such datagrams.  However,
+   if the home agent is also a router handling common IP traffic, it is
+   possible that it will receive such datagrams for forwarding onto the
+   home network.  In this case, the home agent MUST assume the mobile
+   node is at home and simply forward the datagram directly onto the
+   home network.
+
+   For multihomed home agents, the source address in the outer IP header
+   of the encapsulated datagram MUST be the address sent to the mobile
+   node in the Home Agent field of the Registration Reply.  That is, the
+   home agent cannot use the address of some other network interface as
+   the source address.
+
+   See Section 4.1 regarding methods of encapsulation that may be used
+   for tunneling.  Nodes implementing tunneling SHOULD also implement
+   the "tunnel soft state" mechanism [14], which allows ICMP error
+   messages returned from the tunnel to correctly be reflected back to
+   the original senders of the tunneled datagrams.
+
+   Home agents MUST decapsulate packets addressed to themselves, sent by
+   a mobile node for the purpose of maintaining location privacy, as
+   described in Section 5.5.  This feature is also required for support
+   of reverse tunneling [12].
+
+   If the Lifetime for a given mobility binding expires before the home
+   agent has received another valid Registration Request for that mobile
+   node, then that binding is deleted from the mobility binding list.
+   The home agent MUST NOT send any Registration Reply message simply
+   because the mobile node's binding has expired.  The entry in the
+   visitor list of the mobile node's current foreign agent will expire
+   naturally, probably at the same time as the binding expired at the
+   home agent.  When a mobility binding's lifetime expires, the home
+
+
+
+Perkins                      Standards Track                   [Page 69]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   agent MUST delete the binding, but it MUST retain any other (non-
+   expired) simultaneous mobility bindings that it holds for the mobile
+   node.
+
+   When a home agent receives a datagram, intercepted for one of its
+   mobile nodes registered away from home, the home agent MUST examine
+   the datagram to check if it is already encapsulated.  If so, special
+   rules apply in the forwarding of that datagram to the mobile node:
+
+   o  If the inner (encapsulated) Destination Address is the same as the
+      outer Destination Address (the mobile node), then the home agent
+      MUST also examine the outer Source Address of the encapsulated
+      datagram (the source address of the tunnel).  If this outer Source
+      Address is the same as the mobile node's current care-of address,
+      the home agent MUST silently discard that datagram in order to
+      prevent a likely routing loop.  If, instead, the outer Source
+      Address is NOT the same as the mobile node's current care-of
+      address, then the home agent SHOULD forward the datagram to the
+      mobile node.  In order to forward the datagram in this case, the
+      home agent MAY simply alter the outer Destination Address to the
+      care-of address, rather than re-encapsulating the datagram.
+
+   o  Otherwise (the inner Destination Address is NOT the same as the
+      outer Destination Address), the home agent SHOULD encapsulate the
+      datagram again (nested encapsulation), with the new outer
+      Destination Address set equal to the mobile node's care-of
+      address.  That is, the home agent forwards the entire datagram to
+      the mobile node in the same way as any other datagram
+      (encapsulated already or not).
+
+4.3.  Broadcast Datagrams
+
+   When a home agent receives a broadcast datagram, it MUST NOT forward
+   the datagram to any mobile nodes in its mobility binding list other
+   than those that have requested forwarding of broadcast datagrams.  A
+   mobile node MAY request forwarding of broadcast datagrams by setting
+   the 'B' bit in its Registration Request message (Section 3.3).  For
+   each such registered mobile node, the home agent SHOULD forward
+   received broadcast datagrams to the mobile node, although it is a
+   matter of configuration at the home agent as to which specific
+   categories of broadcast datagrams will be forwarded to such mobile
+   nodes.
+
+   If the 'D' bit was set in the mobile node's Registration Request
+   message, indicating that the mobile node is using a co-located care-
+   of address, the home agent simply tunnels appropriate broadcast IP
+   datagrams to the mobile node's care-of address.  Otherwise (the 'D'
+   bit was NOT set), the home agent first encapsulates the broadcast
+
+
+
+Perkins                      Standards Track                   [Page 70]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   datagram in a unicast datagram addressed to the mobile node's home
+   address, and then tunnels this encapsulated datagram to the foreign
+   agent.  This extra level of encapsulation is required so that the
+   foreign agent can determine which mobile node should receive the
+   datagram after it is decapsulated.  When received by the foreign
+   agent, the unicast encapsulated datagram is detunneled and delivered
+   to the mobile node in the same way as any other datagram.  In either
+   case, the mobile node must decapsulate the datagram it receives in
+   order to recover the original broadcast datagram.
+
+4.4.  Multicast Datagram Routing
+
+   As mentioned previously, a mobile node that is connected to its home
+   network functions in the same way as any other (fixed) host or
+   router.  Thus, when it is at home, a mobile node functions
+   identically to other multicast senders and receivers.  This section
+   therefore describes the behavior of a mobile node that is visiting a
+   foreign network.
+
+   In order to receive multicasts, a mobile node MUST join the multicast
+   group in one of two ways.  First, a mobile node MAY join the group
+   via a (local) multicast router on the visited subnet.  This option
+   assumes that there is a multicast router present on the visited
+   subnet.  If the mobile node is using a co-located care-of address, it
+   SHOULD use this address as the source IP address of its IGMP [6]
+   messages.  Otherwise, it MAY use its home address.
+
+   Alternatively, a mobile node that wishes to receive multicasts MAY
+   join groups via a bidirectional tunnel to its home agent, assuming
+   that its home agent is a multicast router.  The mobile node tunnels
+   IGMP messages to its home agent, and the home agent forwards
+   multicast datagrams down the tunnel to the mobile node.  For packets
+   tunneled to the home agent, the source address in the IP header
+   SHOULD be the mobile node's home address.
+
+   The rules for multicast datagram delivery to mobile nodes in this
+   case are identical to those for broadcast datagrams (Section 4.3).
+   Namely, if the mobile node is using a co-located care-of address (the
+   'D' bit was set in the mobile node's Registration Request), then the
+   home agent SHOULD tunnel the datagram to this care-of address;
+   otherwise, the home agent MUST first encapsulate the datagram in a
+   unicast datagram addressed to the mobile node's home address and then
+   MUST tunnel the resulting datagram (nested tunneling) to the mobile
+   node's care-of address.  For this reason, the mobile node MUST be
+   capable of decapsulating packets sent to its home address in order to
+   receive multicast datagrams using this method.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 71]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   A mobile node that wishes to send datagrams to a multicast group also
+   has two options: (1) send directly on the visited network; or (2)
+   send via a tunnel to its home agent.  Because multicast routing in
+   general depends upon the IP source address, a mobile node that sends
+   multicast datagrams directly on the visited network MUST use a
+   co-located care-of address as the IP source address.  Similarly, a
+   mobile node that tunnels a multicast datagram to its home agent MUST
+   use its home address as the IP source address of both the (inner)
+   multicast datagram and the (outer) encapsulating datagram.  This
+   second option assumes that the home agent is a multicast router.
+
+4.5.  Mobile Routers
+
+   A mobile node can be a router that is responsible for the mobility of
+   one or more entire networks moving together, perhaps on an airplane,
+   a ship, a train, an automobile, a bicycle, or a kayak.  The nodes
+   connected to a network served by the mobile router may themselves be
+   fixed nodes or mobile nodes or routers.  In this document, such
+   networks are called "mobile networks".
+
+   A mobile router MAY act as a foreign agent and provide a foreign
+   agent care-of address to mobile nodes connected to the mobile
+   network.  Typical routing to a mobile node via a mobile router in
+   this case is illustrated by the following example:
+
+   a.  A laptop computer is disconnected from its home network and later
+       attached to a network port in the seat back of an aircraft.  The
+       laptop computer uses Mobile IP to register on this foreign
+       network, using a foreign agent care-of address discovered through
+       an Agent Advertisement from the aircraft's foreign agent.
+
+   b.  The aircraft network is itself mobile.  Suppose the node serving
+       as the foreign agent on the aircraft also serves as the default
+       router that connects the aircraft network to the rest of the
+       Internet.  When the aircraft is at home, this router is attached
+       to some fixed network at the airline's headquarters, which is the
+       router's home network.  While the aircraft is in flight, this
+       router registers from time to time over its radio link with a
+       series of foreign agents below it on the ground.  This router's
+       home agent is a node on the fixed network at the airline's
+       headquarters.
+
+   c.  Some correspondent node sends a datagram to the laptop computer,
+       addressing the datagram to the laptop's home address.  This
+       datagram is initially routed to the laptop's home network.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 72]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   d.  The laptop's home agent intercepts the datagram on the home
+       network and tunnels it to the laptop's care-of address, which in
+       this example is an address of the node serving as the router and
+       foreign agent on the aircraft.  Normal IP routing will route the
+       datagram to the fixed network at the airline's headquarters.
+
+   e.  The aircraft router and foreign agent's home agent there
+       intercept the datagram and tunnel it to its current care-of
+       address, which in this example is some foreign agent on the
+       ground below the aircraft.  The original datagram from the
+       correspondent node has now been encapsulated twice: once by the
+       laptop's home agent and again by the aircraft's home agent.
+
+   f.  The foreign agent on the ground decapsulates the datagram,
+       yielding a datagram still encapsulated by the laptop's home
+       agent, with a Destination Address of the laptop's care-of
+       address.  The ground foreign agent sends the resulting datagram
+       over its radio link to the aircraft.
+
+   g.  The foreign agent on the aircraft decapsulates the datagram,
+       yielding the original datagram from the correspondent node, with
+       a Destination Address of the laptop's home address.  The aircraft
+       foreign agent delivers the datagram over the aircraft network to
+       the laptop's link-layer address.
+
+   This example illustrates the case in which a mobile node is attached
+   to a mobile network.  That is, the mobile node is mobile with respect
+   to the network, which itself is also mobile (here with respect to the
+   ground).  If, instead, the node is fixed with respect to the mobile
+   network (the mobile network is the fixed node's home network), then
+   either of two methods may be used to cause datagrams from
+   correspondent nodes to be routed to the fixed node.
+
+   For the fixed node, a home agent MAY be configured to have a
+   permanent registration that indicates the mobile router's address as
+   the fixed host's care-of address.  The mobile router's home agent
+   will normally be used for this purpose.  The home agent is then
+   responsible for advertising connectivity using normal routing
+   protocols to the fixed node.  Any datagrams sent to the fixed node
+   will thus use nested tunneling as described above.
+
+   Alternatively, the mobile router MAY advertise connectivity to the
+   entire mobile network using normal IP routing protocols through a
+   bidirectional tunnel to its own home agent.  This method avoids the
+   need for nested tunneling of datagrams.
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 73]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+4.6.  ARP, Proxy ARP, and Gratuitous ARP
+
+   The use of ARP [16] requires special rules for correct operation when
+   wireless or mobile nodes are involved.  The requirements specified in
+   this section apply to all home networks in which ARP is used for
+   address resolution.
+
+   In addition to the normal use of ARP for resolving a target node's
+   link-layer address from its IP address, this document distinguishes
+   two special uses of ARP:
+
+   o  A Proxy ARP [49] is an ARP Reply sent by one node on behalf of
+      another node that is either unable or unwilling to answer its own
+      ARP Requests.  The sender of a Proxy ARP reverses the Sender and
+      Target Protocol Address fields as described in [16], but supplies
+      some configured link-layer address (generally, its own) in the
+      Sender Hardware Address field.  The node receiving the Reply will
+      then associate this link-layer address with the IP address of the
+      original target node, causing it to transmit future datagrams for
+      this target node to the node with that link-layer address.
+
+   o  A Gratuitous ARP [45] is an ARP packet sent by a node in order to
+      spontaneously cause other nodes to update an entry in their ARP
+      cache.  A gratuitous ARP MAY use either an ARP Request or an ARP
+      Reply packet.  In either case, the ARP Sender Protocol Address and
+      ARP Target Protocol Address are both set to the IP address of the
+      cache entry to be updated, and the ARP Sender Hardware Address is
+      set to the link-layer address to which this cache entry should be
+      updated.  When using an ARP Reply packet, the Target Hardware
+      Address is also set to the link-layer address to which this cache
+      entry should be updated (this field is not used in an ARP Request
+      packet).
+
+      In either case, for a gratuitous ARP, the ARP packet MUST be
+      transmitted as a local broadcast packet on the local link.  As
+      specified in [16], any node receiving any ARP packet (Request or
+      Reply) MUST update its local ARP cache with the Sender Protocol
+      and Hardware Addresses in the ARP packet, if the receiving node
+      has an entry for that IP address already in its ARP cache.  This
+      requirement in the ARP protocol applies even for ARP Request
+      packets, and for ARP Reply packets that do not match any ARP
+      Request transmitted by the receiving node [16].
+
+   While a mobile node is registered on a foreign network, its home
+   agent uses proxy ARP [49] to reply to ARP Requests it receives that
+   seek the mobile node's link-layer address.  When receiving an ARP
+   Request, the home agent MUST examine the target IP address of the
+   Request, and if this IP address matches the home address of any
+
+
+
+Perkins                      Standards Track                   [Page 74]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   mobile node for which it has a registered mobility binding, the home
+   agent MUST transmit an ARP Reply on behalf of the mobile node.  After
+   exchanging the sender and target addresses in the packet [49], the
+   home agent MUST set the sender link-layer address in the packet to
+   the link-layer address of its own interface over which the Reply will
+   be sent.
+
+   When a mobile node leaves its home network and registers a binding on
+   a foreign network, its home agent uses gratuitous ARP to update the
+   ARP caches of nodes on the home network.  This causes such nodes to
+   associate the link-layer address of the home agent with the mobile
+   node's home (IP) address.  When registering a binding for a mobile
+   node for which the home agent previously had no binding (the mobile
+   node was assumed to be at home), the home agent MUST transmit a
+   gratuitous ARP on behalf of the mobile node.  This gratuitous ARP
+   packet MUST be transmitted as a broadcast packet on the link on which
+   the mobile node's home address is located.  Since broadcasts on the
+   local link (such as Ethernet) are typically not guaranteed to be
+   reliable, the gratuitous ARP packet SHOULD be retransmitted a small
+   number of times to increase its reliability.
+
+   When a mobile node returns to its home network, the mobile node and
+   its home agent use gratuitous ARP to cause all nodes on the mobile
+   node's home network to update their ARP caches to once again
+   associate the mobile node's own link-layer address with the mobile
+   node's home (IP) address.  Before transmitting the (de)Registration
+   Request message to its home agent, the mobile node MUST transmit this
+   gratuitous ARP on its home network as a local broadcast on this link.
+   The gratuitous ARP packet SHOULD be retransmitted a small number of
+   times to increase its reliability, but these retransmissions SHOULD
+   proceed in parallel with the transmission and processing of the
+   mobile node's (de)Registration Request.
+
+   When the mobile node's home agent receives and accepts this
+   (de)Registration Request, the home agent MUST also transmit a
+   gratuitous ARP on the mobile node's home network.  This gratuitous
+   ARP also is used to associate the mobile node's home address with the
+   mobile node's own link-layer address.  A gratuitous ARP is
+   transmitted by both the mobile node and its home agent, since in the
+   case of wireless network interfaces, the area within transmission
+   range of the mobile node will likely differ from that within range of
+   its home agent.  The ARP packet from the home agent MUST be
+   transmitted as a local broadcast on the mobile node's home link, and
+   SHOULD be retransmitted a small number of times to increase its
+   reliability; these retransmissions, however, SHOULD proceed in
+   parallel with the transmission and processing of the mobile node's
+   (de)Registration Reply.
+
+
+
+
+Perkins                      Standards Track                   [Page 75]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   While the mobile node is away from home, it MUST NOT transmit any
+   broadcast ARP Request or ARP Reply messages.  Finally, while the
+   mobile node is away from home, it MUST NOT reply to ARP Requests in
+   which the target IP address is its own home address unless the ARP
+   Request is unicast by a foreign agent with which the mobile node is
+   attempting to register or a foreign agent with which the mobile node
+   has an unexpired registration.  In the latter case, the mobile node
+   MUST use a unicast ARP Reply to respond to the foreign agent.  Note
+   that if the mobile node is using a co-located care-of address and
+   receives an ARP Request in which the target IP address is this care-
+   of address, then the mobile node SHOULD reply to this ARP Request.
+   Note also that, when transmitting a Registration Request on a foreign
+   network, a mobile node may discover the link-layer address of a
+   foreign agent by storing the address as it is received from the Agent
+   Advertisement from that foreign agent, but not by transmitting a
+   broadcast ARP Request message.
+
+   The specific order in which each of the above requirements for the
+   use of ARP, proxy ARP, and gratuitous ARP are applied, relative to
+   the transmission and processing of the mobile node's Registration
+   Request and Registration Reply messages when leaving home or
+   returning home, are important to the correct operation of the
+   protocol.
+
+   To summarize the above requirements, when a mobile node leaves its
+   home network, the following steps, in this order, MUST be performed:
+
+   o  The mobile node decides to register away from home, perhaps
+      because it has received an Agent Advertisement from a foreign
+      agent and has not recently received one from its home agent.
+
+   o  Before transmitting the Registration Request, the mobile node
+      disables its own future processing of any ARP Requests it may
+      subsequently receive requesting the link-layer address
+      corresponding to its home address, except insofar as necessary to
+      communicate with foreign agents on visited networks.
+
+   o  The mobile node transmits its Registration Request.
+
+   o  When the mobile node's home agent receives and accepts the
+      Registration Request, it performs a gratuitous ARP on behalf of
+      the mobile node, and begins using proxy ARP to reply to ARP
+      Requests that it receives requesting the mobile node's link-layer
+      address.  In the gratuitous ARP, the ARP Sender Hardware Address
+      is set to the link-layer address of the home agent.  If, instead,
+      the home agent rejects the Registration Request, no ARP processing
+      (neither gratuitous nor proxy) is performed by the home agent.
+
+
+
+
+Perkins                      Standards Track                   [Page 76]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   When a mobile node later returns to its home network, the following
+   steps, in this order, MUST be performed:
+
+   o  The mobile node decides to register at home, perhaps because it
+      has received an Agent Advertisement from its home agent.
+
+   o  Before transmitting the Registration Request, the mobile node
+      re-enables its own future processing of any ARP Requests it may
+      subsequently receive requesting its link-layer address.
+
+   o  The mobile node performs a gratuitous ARP for itself.  In this
+      gratuitous ARP, the ARP Sender Hardware Address is set to the
+      link-layer address of the mobile node.
+
+   o  The mobile node transmits its Registration Request.
+
+   o  When the mobile node's home agent receives and accepts the
+      Registration Request, it stops using proxy ARP to reply to ARP
+      Requests that it receives requesting the mobile node's link-layer
+      address, and then performs a gratuitous ARP on behalf of the
+      mobile node.  In this gratuitous ARP, the ARP Sender Hardware
+      Address is set to the link-layer address of the mobile node.  If,
+      instead, the home agent rejects the Registration Request, the home
+      agent MUST NOT make any change to the way it performs ARP
+      processing (neither gratuitous nor proxy) for the mobile node.  In
+      this latter case, the home agent should operate as if the mobile
+      node has not returned home, and continue to perform proxy ARP on
+      behalf of the mobile node.
+
+5.  Security Considerations
+
+   The mobile computing environment is potentially very different from
+   the ordinary computing environment.  In many cases, mobile computers
+   will be connected to the network via wireless links.  Such links are
+   particularly vulnerable to passive eavesdropping, active replay
+   attacks, and other active attacks.
+
+5.1.  Message Authentication Codes
+
+   Home agents and mobile nodes MUST be able to perform authentication.
+   The default algorithm is HMAC-MD5 [10], with a key size of 128 bits.
+   The foreign agent MUST also support authentication using HMAC-MD5 and
+   key sizes of 128 bits or greater, with manual key distribution.  Keys
+   with arbitrary binary values MUST be supported.
+
+   The "prefix+suffix" use of MD5 to protect data and a shared secret is
+   considered vulnerable to attack by the cryptographic community.
+   Where backward compatibility with existing Mobile IP implementations
+
+
+
+Perkins                      Standards Track                   [Page 77]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   that use this mode is needed, new implementations SHOULD include
+   keyed MD5 [19] as one of the additional authentication algorithms for
+   use when producing and verifying the authentication data that is
+   supplied with Mobile IP registration messages, for instance, in the
+   extensions specified in Sections 3.5.2, 3.5.3, and 3.5.4.
+
+   More authentication algorithms, algorithm modes, key distribution
+   methods, and key sizes MAY also be supported for all of these
+   extensions.
+
+5.2.  Areas of Security Concern in This Protocol
+
+   The registration protocol described in this document will result in a
+   mobile node's traffic being tunneled to its care-of address.  This
+   tunneling feature could be a significant vulnerability if the
+   registration were not authenticated.  Such remote redirection, for
+   instance, as performed by the mobile registration protocol, is widely
+   understood to be a security problem in the current Internet if not
+   authenticated [30].  Moreover, the Address Resolution Protocol (ARP)
+   is not authenticated, and can potentially be used to steal another
+   host's traffic.  The use of gratuitous ARP (Section 4.6) brings with
+   it all of the risks associated with the use of ARP.
+
+5.3.  Key Management
+
+   This specification requires a strong authentication mechanism (keyed
+   MD5) that precludes many potential attacks based on the Mobile IP
+   registration protocol.  However, because key distribution is
+   difficult in the absence of a network key management protocol,
+   messages with the foreign agent are not all required to be
+   authenticated.  In a commercial environment it might be important to
+   authenticate all messages between the foreign agent and the home
+   agent, so that billing is possible and service providers do not
+   provide service to users that are not legitimate customers of that
+   service provider.
+
+5.4.  Picking Good Random Numbers
+
+   The strength of any authentication mechanism depends on several
+   factors, including the innate strength of the authentication
+   algorithm, the secrecy of the key used, the strength of the key used,
+   and the quality of the particular implementation.  This specification
+   requires implementation of keyed MD5 for authentication, but does not
+   preclude the use of other authentication algorithms and modes.  For
+   keyed MD5 authentication to be useful, the 128-bit key must be both
+   secret (that is, known only to authorized parties) and pseudo-random.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 78]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   If nonces are used in connection with replay protection, they must
+   also be selected carefully.  RFC 4086 [8] written by Eastlake, et al.
+   provides more information on generating pseudo-random numbers.
+
+5.5.  Privacy
+
+   Users who have sensitive data that they do not wish others to see
+   should use mechanisms outside the scope of this document (such as
+   encryption) to provide appropriate protection.  Users concerned about
+   traffic analysis should consider appropriate use of link encryption.
+   If absolute location privacy is desired, the mobile node can create a
+   tunnel to its home agent.  Then, datagrams destined for correspondent
+   nodes will appear to emanate from the home network, and it may be
+   more difficult to pinpoint the location of the mobile node.  Such
+   mechanisms are all beyond the scope of this document.
+
+5.6.  Ingress Filtering
+
+   Many routers implement security policies such as "ingress filtering"
+   [35] that do not allow forwarding of packets that have a Source
+   Address that appears topologically incorrect.  In environments where
+   this is a problem, mobile nodes may use reverse tunneling [12] with
+   the foreign agent supplied care-of address as the Source Address.
+   Reverse-tunneled packets will be able to pass normally through such
+   routers, while ingress filtering rules will still be able to locate
+   the true topological source of the packet in the same way as packets
+   from non-mobile nodes.
+
+5.7.  Replay Protection for Registration Requests
+
+   The Identification field is used to let the home agent verify that a
+   registration message has been freshly generated by the mobile node,
+   not replayed by an attacker from some previous registration.  Two
+   methods are described in this section: timestamps (mandatory) and
+   "nonces" (optional).  All mobile nodes and home agents MUST implement
+   timestamp-based replay protection.  These nodes MAY also implement
+   nonce-based replay protection.
+
+   The style of replay protection in effect between a mobile node and
+   its home agent is part of the Mobility Security Association.  A
+   mobile node and its home agent MUST agree on which method of replay
+   protection will be used.  The interpretation of the Identification
+   field depends on the method of replay protection as described in the
+   subsequent subsections.
+
+   Whatever method is used, the low-order 32 bits of the Identification
+   field MUST be copied unchanged from the Registration Request to the
+   Reply.  The foreign agent uses those bits (and the mobile node's home
+
+
+
+Perkins                      Standards Track                   [Page 79]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   address) to match Registration Requests with corresponding replies.
+   The mobile node MUST verify that the low-order 32 bits of any
+   Registration Reply are identical to the bits it sent in the
+   Registration Request.
+
+   The Identification field in a new Registration Request MUST NOT be
+   the same as in an immediately preceding Request, and SHOULD NOT
+   repeat while the same security context is being used between the
+   mobile node and the home agent.  Retransmission as in Section 3.6.3
+   is allowed.
+
+5.7.1.  Replay Protection Using Timestamps
+
+   The basic principle of timestamp replay protection is that the node
+   generating a message inserts the current time of day, and the node
+   receiving the message checks that this timestamp is sufficiently
+   close to its own time of day.  Unless specified differently in the
+   security association between the nodes, a default value of 7 seconds
+   MAY be used to limit the time difference.  This value SHOULD be
+   greater than 3 seconds.  Obviously the two nodes must have adequately
+   synchronized time-of-day clocks.  As with any messages, time
+   synchronization messages may be protected against tampering by an
+   authentication mechanism determined by the security context between
+   the two nodes.
+
+   If timestamps are used, the mobile node MUST set the Identification
+   field to a 64-bit value formatted as specified by the Network Time
+   Protocol [11].  The low-order 32 bits of the NTP format represent
+   fractional seconds, and those bits that are not available from a time
+   source SHOULD be generated from a good source of randomness.  Note,
+   however, that when using timestamps, the 64-bit Identification used
+   in a Registration Request from the mobile node MUST be greater than
+   that used in any previous Registration Request, as the home agent
+   uses this value as a sequence number.  Without such a sequence
+   number, it would be possible for a delayed duplicate of an earlier
+   Registration Request to arrive at the home agent (within the clock
+   synchronization required by the home agent), and thus be applied out
+   of order, mistakenly altering the mobile node's current registered
+   care-of address.
+
+   Upon receipt of a Registration Request with an authorization-enabling
+   extension, the home agent MUST check the Identification field for
+   validity.  In order to be valid, the timestamp contained in the
+   Identification field MUST be close enough to the home agent's time-
+   of-day clock, and the timestamp MUST be greater than all previously
+   accepted timestamps for the requesting mobile node.  Time tolerances
+   and resynchronization details are specific to a particular Mobility
+   Security Association.
+
+
+
+Perkins                      Standards Track                   [Page 80]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   If the timestamp is valid, the home agent copies the entire
+   Identification field into the Registration Reply it returns to the
+   mobile node.  If the timestamp is not valid, the home agent copies
+   only the low-order 32 bits into the Registration Reply, and supplies
+   the high-order 32 bits from its own time of day.  In this latter
+   case, the home agent MUST reject the registration by returning Code
+   133 (registration Identification mismatch) in the Registration Reply.
+
+   As described in Section 3.6.2.1, the mobile node MUST verify that the
+   low-order 32 bits of the Identification field in the Registration
+   Reply are identical to those in the rejected registration attempt,
+   before using the high-order bits for clock resynchronization.
+
+5.7.2.  Replay Protection Using Nonces
+
+   The basic principle of nonce replay protection is that node A
+   includes a new random number in every message to node B, and checks
+   that node B returns that same number in its next message to node A.
+   Both messages use an authentication code to protect against
+   alteration by an attacker.  At the same time, node B can send its own
+   nonces in all messages to node A (to be echoed by node A), so that it
+   too can verify that it is receiving fresh messages.
+
+   The home agent may be expected to have resources for computing
+   pseudo-random numbers useful as nonces [8].  It inserts a new nonce
+   as the high-order 32 bits of the Identification field of every
+   Registration Reply.  The home agent copies the low-order 32 bits of
+   the Identification field from the Registration Request message into
+   the low-order 32 bits of the Identification field in the Registration
+   Reply.  When the mobile node receives an authenticated Registration
+   Reply from the home agent, it saves the high-order 32 bits of the
+   Identification field for use as the high-order 32 bits of its next
+   Registration Request.
+
+   The mobile node is responsible for generating the low-order 32 bits
+   of the Identification field in each Registration Request.  Ideally,
+   it should generate its own random nonces.  However, it may use any
+   expedient method, including duplication of the random value sent by
+   the home agent.  The method chosen is of concern only to the mobile
+   node, because it is the node that checks for valid values in the
+   Registration Reply.  The high-order and low-order 32 bit values of
+   the identification chosen SHOULD both differ from their previous
+   values.  The home agent uses a new high-order value, and the mobile
+   node uses a new low-order value for each registration message.  The
+   foreign agent uses the low-order value (and the mobile host's home
+   address) to correctly match registration replies with pending
+   Requests (Section 3.7.1).
+
+
+
+
+Perkins                      Standards Track                   [Page 81]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   If a registration message is rejected because of an invalid nonce,
+   the Reply always provides the mobile node with a new nonce to be used
+   in the next registration.  Thus, the nonce protocol is self-
+   synchronizing.
+
+6.  IANA Considerations
+
+   Mobile IP specifies several new number spaces for values to be used
+   in various message fields.  These number spaces include the
+   following:
+
+   o  Mobile IP message types sent to UDP port 434, as defined in
+      Section 1.8.
+
+   o  types of extensions to Registration Request and Registration Reply
+      messages (see Sections 3.3 and 3.4, and also consult [12], [43],
+      [2], [3], and [7]).
+
+   o  values for the code in the Registration Reply message (see Section
+      3.4, and also consult [12], [43], [2], [3], and [7]).
+
+   o  Mobile IP defines so-called Agent Solicitation and Agent
+      Advertisement messages.  These messages are in fact Router
+      Discovery messages [5] augmented with Mobile-IP-specific
+      extensions.  Thus, they do not define a new name space, but do
+      define additional Router Discovery extensions as described below
+      in Section 6.2.  Also see Section 2.1, and consult [3] and [7].
+
+   There are additional Mobile IP numbering spaces specified in [3].
+
+   Information about assignment of Mobile IP numbers derived from
+   specifications external to this document is given by IANA at
+   http://www.iana.org/protocols.  From that URL, see the "Mobile
+   Internet Protocol (IP) Numbers" section.
+
+   In this revised specification, a new code value (for the field in the
+   Registration Reply message) is needed within the range typically used
+   for foreign agent messages.  This error code is needed to indicate
+   the status "Invalid Home Agent Address".  See Section 3.7.2 for
+   details.
+
+6.1.  Mobile IP Message Types
+
+   Mobile IP messages are defined to be those that are sent to a message
+   recipient at port 434 (UDP or TCP).  The number space for Mobile IP
+   messages is specified in Section 1.8.  Approval of new extension
+
+
+
+
+
+Perkins                      Standards Track                   [Page 82]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   numbers is subject to Expert Review, and a specification is required
+   [22].  The currently standardized message types have the following
+   numbers, and are specified in the indicated sections.
+
+     Type  Name                                             Section
+     ----  --------------------------------------------     ---------
+     1     Registration Request                             3.3
+     3     Registration Reply                               3.4
+
+6.2.  Extensions to RFC 1256 Router Advertisement
+
+   RFC 1256 defines two ICMP message types, Router Advertisement and
+   Router Solicitation.  Mobile IP defines a number space for extensions
+   to Router Advertisement, which could be used by protocols other than
+   Mobile IP.  The extension types currently standardized for use with
+   Mobile IP have the following numbers.
+
+     Type  Name                                             Section
+     ----  --------------------------------------------     ---------
+     0     One-byte Padding                                 2.1.3
+     16    Mobility Agent Advertisement                     2.1.1
+     19    Prefix-Lengths                                   2.1.2
+
+   Approval of new extension numbers for use with Mobile IP is subject
+   to Expert Review, and a specification is required [22].
+
+6.3.  Extensions to Mobile IP Registration Messages
+
+   The Mobile IP messages specified within this document and listed in
+   Sections 1.8 and 6.1 may have extensions.  Mobile IP message
+   extensions all share the same number space, even if they are to be
+   applied to different Mobile IP messages.  The number space for Mobile
+   IP message extensions is specified within this document.  Approval of
+   new extension numbers is subject to Expert Review, and a
+   specification is required [22].
+
+     Type  Name                                             Section
+     ----  --------------------------------------------     ---------
+     0     One-byte Padding
+     32    Mobile-Home Authentication                       3.5.2
+     33    Mobile-Foreign Authentication                    3.5.3
+     34    Foreign-Home Authentication                      3.5.4
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 83]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+6.4.  Code Values for Mobile IP Registration Reply Messages
+
+   The Mobile IP Registration Reply message, specified in Section 3.4,
+   has a Code field.  The number space for the Code field values is also
+   specified in Section 3.4.  The Code number space is structured
+   according to whether the registration was successful, the foreign
+   agent denied the Registration Request, or the home agent denied the
+   Registration Request, as follows:
+
+   +---------+------------------------------------------------------+
+   | Code #s |                       Guideline                      |
+   +---------+------------------------------------------------------+
+   |   0-8   |                     Success Codes                    |
+   |         |                                                      |
+   |   9-63  | Allocation guidelines not specified in this document |
+   |         |                                                      |
+   |  64-127 |          Error Codes from the Foreign Agent          |
+   |         |                                                      |
+   | 128-192 |            Error Codes from the Home Agent           |
+   |         |                                                      |
+   | 193-200 |    Error Codes from the Gateway Foreign Agent [29]   |
+   |         |                                                      |
+   | 201-255 | Allocation guidelines not specified in this document |
+   +---------+------------------------------------------------------+
+
+         Approval of new code values requires Expert Review [22].
+
+            Table 1:  Guidelines for Allocation of Code Values
+
+7.  Acknowledgments
+
+   Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp
+   and John Ioannidis (JI) (Columbia University), for forming the
+   working group, chairing it, and putting so much effort into its early
+   development.  Columbia's early Mobile IP work can be found in [37],
+   [38], [39].
+
+   Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon,
+   Erik Nordmark, Basavaraj Patil, and Phil Roberts for their
+   contributions to the group while performing the duties of
+   chairperson, as well as for their many useful comments.
+
+   Thanks to the active members of the Mobile IP Working Group,
+   particularly those who contributed text, including (in alphabetical
+   order)
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 84]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+      Ran Atkinson (Naval Research Lab)
+      Samita Chakrabarti (Sun Microsystems)
+      Ken Imboden (Candlestick Networks, Inc.)
+      Dave Johnson (Carnegie Mellon University)
+      Frank Kastenholz (FTP Software)
+      Anders Klemets (KTH)
+      Chip Maguire (KTH)
+      Alison Mankin (ISI)
+      Andrew Myles (Macquarie University)
+      Thomas Narten (IBM)
+      Al Quirt (Bell Northern Research)
+      Yakov Rekhter (IBM)
+      Fumio Teraoka (Sony)
+      Alper Yegin (NTT DoCoMo)
+
+   Thanks to Charlie Kunzinger and to Bill Simpson, the editors who
+   produced the first drafts of this document, reflecting the
+   discussions of the working group.  Much of the new text in the later
+   revisions preceding RFC 2002 is due to Jim Solomon and Dave Johnson.
+
+   Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank
+   Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for
+   their generous support in hosting interim working group meetings.
+
+   Sections 1.10 and 1.11, which specify new extension formats to be
+   used with aggregatable extension types, were included from a
+   specification document (entitled "Mobile IP Extensions
+   Rationalization (MIER)", which was written by
+
+      Mohamed Khalil (Nortel Networks)
+      Raja Narayanan (nVisible Networks)
+      Haseeb Akhtar (Nortel Networks)
+      Emad Qaddoura (Nortel Networks)
+
+   Thanks to these authors, and also for the additional work on MIER,
+   which was contributed by Basavaraj Patil, Pat Calhoun, Neil
+   Justusson, N. Asokan, and Jouni Malinen.
+
+   Thanks to Vijay Devarapalli, who put in many hours to convert the
+   source for this text document into XML format.
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 85]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Calhoun, P. and C. Perkins, "Mobile IP Network Access
+         Identifier Extension for IPv4", RFC 2794, March 2000.
+
+   [3]   Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
+         Challenge/Response Extensions (Revised)", RFC 4721, January
+         2007.
+
+   [4]   Cong, D., Hamlen, M., and C. Perkins, "The Definitions of
+         Managed Objects for IP Mobility Support using SMIv2", RFC 2006,
+         October 1996.
+
+   [5]   Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256,
+         September 1991.
+
+   [6]   Deering, S., "Host extensions for IP multicasting", STD 5, RFC
+         1112, August 1989.
+
+   [7]   Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-
+         Specific Extensions", RFC 3115, April 2001.
+
+   [8]   Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness
+         Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [9]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.
+
+   [10]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+         for Message Authentication", RFC 2104, February 1997.
+
+   [11]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network
+         Time Protocol Version 4: Protocol and Algorithms
+         Specification", RFC 5905, June 2010.
+
+   [12]  Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
+         revised", RFC 3024, January 2001.
+
+   [13]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
+         "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
+
+   [14]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
+         1996.
+
+
+
+
+Perkins                      Standards Track                   [Page 86]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   [15]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
+         October 1996.
+
+   [16]  Plummer, D., "Ethernet Address Resolution Protocol: Or
+         Converting Network Protocol Addresses to 48.bit Ethernet
+         Address for Transmission on Ethernet Hardware", STD 37, RFC
+         826, November 1982.
+
+   [17]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+         1980.
+
+   [18]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+         1981.
+
+   [19]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+         1992.
+
+   [20]  Solomon, J., "Applicability Statement for IP Mobility Support",
+         RFC 2005, October 1996.
+
+   [21]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
+         August 2002.
+
+   [22]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
+
+8.2.  Informative References
+
+   [23]  Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
+         PPP IPCP", RFC 2290, February 1998.
+
+   [24]  Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
+         Vaidya, "Long Thin Networks", RFC 2757, January 2000.
+
+   [25]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
+         Satellite Channels using Standard Mechanisms", BCP 28, RFC
+         2488, January 1999.
+
+   [26]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
+         Timer", RFC 2988, November 2000.
+
+   [27]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
+         Address Translation (NAT) Devices", RFC 3519, April 2003.
+
+   [28]  Glass, S. and M. Chandra, "Registration Revocation in Mobile
+         IPv4", RFC 3543, August 2003.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 87]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   [29]  Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
+         Regional Registration", RFC 4857, June 2007.
+
+   [30]  Bellovin, S., "Security Problems in the TCP/IP Protocol Suite",
+         ACM Computer Communications Review, 19(2), March 1989.
+
+   [31]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
+         Shelby, "Performance Enhancing Proxies Intended to Mitigate
+         Link-Related Degradations", RFC 3135, June 2001.
+
+   [32]  Caceres, R. and L. Iftode, "Improving the Performance of
+         Reliable Transport Protocols in Mobile Computing Environments",
+         IEEE Journal on Selected Areas in Communication, 13(5):850-857,
+         June 1995.
+
+   [33]  Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
+         Vaidya, "End-to-end Performance Implications of Links with
+         Errors", BCP 50, RFC 3155, August 2001.
+
+   [34]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+         March 1997.
+
+   [35]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
+         Defeating Denial of Service Attacks which employ IP Source
+         Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+   [36]  Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
+         Links", RFC 1144, February 1990.
+
+   [37]  Ioannidis, J., Duchamp, D., and G. Maguire, "IP-Based Protocols
+         for Mobile Internetworking", In Proceedings of the SIGCOMM '01
+         Conference: Communications Architectures and Protocols, pages
+         235-245, September 1991.
+
+   [38]  Ioannidis, J. and G. Maguire, "The Design and Implementation of
+         a Mobile Internetworking Architecture", In Proceedings of the
+         Winter USENIX Technical Conference, pages 489-500, January
+         1993.
+
+   [39]  Ioannidis, J., "Protocols for Mobile Internetworking", PhD
+         Dissertation - Columbia University in the City of New York,
+         July 1993.
+
+   [40]  Jacobson, V., "Congestion Avoidance and Control", In
+         Proceedings of the SIGCOMM '88 Workshop, ACM SIGCOMM, ACM
+         Press, pages 314-329, August 1998.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 88]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   [41]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
+         RFC 2863, June 2000.
+
+   [42]  McGregor, G., "The PPP Internet Protocol Control Protocol
+         (IPCP)", RFC 1332, May 1992.
+
+   [43]  Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
+         Mobile IP", RFC 2356, June 1998.
+
+   [44]  Perkins, C., Ed., "IP Mobility Support", RFC 2002, October
+         1996.
+
+   [45]  Stevens, R., "TCP/IP Illustrated, Volume 1: The Protocols",
+         Addison-Wesley, Reading, Massachusetts, 1994.
+
+   [46]  Perkins, C. and P. Calhoun, "Authentication, Authorization, and
+         Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
+         March 2005.
+
+   [47]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
+         RFC 1661, July 1994.
+
+   [48]  IANA, "Mobile IPv4 Numbers", http://www.iana.org.
+
+   [49]  Postel, J., "Multi-LAN address resolution", RFC 925, October
+         1984.
+
+   [50]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3220,
+         January 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 89]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+Appendix A.  Link-Layer Considerations
+
+   The mobile node MAY use link-layer mechanisms to decide that its
+   point of attachment has changed.  Such indications include the Down/
+   Testing/Up interface status [41], and changes in cell or
+   administration.  The mechanisms will be specific to the particular
+   link-layer technology, and are outside the scope of this document.
+
+   The Point-to-Point-Protocol (PPP) [47] and its Internet Protocol
+   Control Protocol (IPCP) [42] negotiate the use of IP addresses.
+
+   The mobile node SHOULD first attempt to specify its home address, so
+   that if the mobile node is attaching to its home network, the
+   unrouted link will function correctly.  When the home address is not
+   accepted by the peer, but a transient IP address is dynamically
+   assigned to the mobile node, and the mobile node is capable of
+   supporting a co-located care-of address, the mobile node MAY register
+   that address as a co-located care-of address.  When the peer
+   specifies its own IP address, that address MUST NOT be assumed to be
+   a foreign agent care-of address or the IP address of a home agent.
+   PPP extensions for Mobile IP have been specified in RFC 2290 [23].
+   Please consult that document for additional details for how to handle
+   care-of address assignment from PPP in a more efficient manner.
+
+Appendix B.  TCP Considerations
+
+B.1.  TCP Timers
+
+   When high-delay (e.g., SATCOM) or low-bandwidth (e.g., High-Frequency
+   Radio) links are in use, some TCP stacks may have insufficiently
+   adaptive (non-standard) retransmission timeouts.  There may be
+   spurious retransmission timeouts, even when the link and network are
+   actually operating properly, but just with a high delay because of
+   the medium in use.  This can cause an inability to create or maintain
+   TCP connections over such links, and can also cause unneeded
+   retransmissions that consume already scarce bandwidth.  Vendors are
+   encouraged to follow the algorithms in RFC 2988 [26] when
+   implementing TCP retransmission timers.  Vendors of systems designed
+   for low-bandwidth, high-delay links should consult RFCs 2757 and 2488
+   [24], [25].  Designers of applications targeted to operate on mobile
+   nodes should be sensitive to the possibility of timer-related
+   difficulties.
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 90]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+B.2.  TCP Congestion Management
+
+   Mobile nodes often use media that are more likely to introduce
+   errors, effectively causing more packets to be dropped.  This
+   introduces a conflict with the mechanisms for congestion management
+   found in modern versions of TCP [40].  Now, when a packet is dropped,
+   the correspondent node's TCP implementation is likely to react as if
+   there were a source of network congestion, and initiate the slow-
+   start mechanisms [40] designed for controlling that problem.
+   However, those mechanisms are inappropriate for overcoming errors
+   introduced by the links themselves, and have the effect of magnifying
+   the discontinuity introduced by the dropped packet.  This problem has
+   been analyzed by Caceres, et al. [32].  TCP approaches to the problem
+   of handling errors that might interfere with congestion management
+   are discussed in documents from the PILC working group [31] [33].
+   While such approaches are beyond the scope of this document, they
+   illustrate that providing performance transparency to mobile nodes
+   involves understanding mechanisms outside the network layer.
+   Problems introduced by higher media error rates also indicate the
+   need to avoid designs that systematically drop packets; such designs
+   might otherwise be considered favorably when making engineering
+   tradeoffs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 91]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+Appendix C.  Example Scenarios
+
+   This section shows example Registration Requests for several common
+   scenarios.
+
+C.1.  Registering with a Foreign Agent Care-of Address
+
+   The mobile node receives an Agent Advertisement from a foreign agent
+   and wishes to register with that agent using the advertised foreign
+   agent care-of address.  The mobile node wishes only IP-in-IP
+   encapsulation, does not want broadcasts, and does not want
+   simultaneous mobility bindings:
+
+        IP fields:
+          Source Address = mobile node's home address
+          Destination Address = copied from the IP source address of the
+            Agent Advertisement
+          Time to Live = 1
+        UDP fields:
+          Source Port = <any>
+          Destination Port = 434
+        Registration Request fields:
+          Type = 1
+          S=0,B=0,D=0,M=0,G=0
+          Lifetime = the Registration Lifetime copied from the
+            Mobility Agent Advertisement Extension of the
+            Router Advertisement message
+          Home Address = the mobile node's home address
+          Home Agent = IP address of mobile node's home agent
+          Care-of Address = the Care-of Address copied from the
+            Mobility Agent Advertisement Extension of the
+            Router Advertisement message
+          Identification = Network Time Protocol timestamp or Nonce
+        Extensions:
+          An authorization-enabling extension (e.g., the Mobile-Home
+            Authentication Extension)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 92]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+C.2.  Registering with a Co-Located Care-of Address
+
+   The mobile node enters a foreign network that contains no foreign
+   agents.  The mobile node obtains an address from a DHCP server [34]
+   for use as a co-located care-of address.  The mobile node supports
+   all forms of encapsulation (IP-in-IP, minimal encapsulation, and
+   GRE), desires a copy of broadcast datagrams on the home network, and
+   does not want simultaneous mobility bindings:
+
+        IP fields:
+          Source Address = care-of address obtained from DHCP server
+          Destination Address = IP address of home agent
+          Time to Live = 64
+        UDP fields:
+          Source Port = <any>
+          Destination Port = 434
+        Registration Request fields:
+          Type = 1
+          S=0,B=1,D=1,M=1,G=1
+          Lifetime = 1800 (seconds)
+          Home Address = the mobile node's home address
+          Home Agent = IP address of mobile node's home agent
+          Care-of Address = care-of address obtained from DHCP server
+          Identification = Network Time Protocol timestamp or Nonce
+        Extensions:
+          The Mobile-Home Authentication Extension
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 93]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+C.3.  Deregistration
+
+   The mobile node returns home and wishes to deregister all care-of
+   addresses with its home agent:
+
+        IP fields:
+          Source Address = mobile node's home address
+          Destination Address = IP address of home agent
+          Time to Live = 1
+        UDP fields:
+          Source Port = <any>
+          Destination Port = 434
+        Registration Request fields:
+          Type = 1
+          S=0,B=0,D=0,M=0,G=0
+          Lifetime = 0
+          Home Address = the mobile node's home address
+          Home Agent = IP address of mobile node's home agent
+          Care-of Address = the mobile node's home address
+          Identification = Network Time Protocol timestamp or Nonce
+        Extensions:
+          An authorization-enabling extension (e.g., the Mobile-Home
+            Authentication Extension)
+
+Appendix D.  Applicability of Prefix-Lengths Extension
+
+   Caution is indicated with the use of the Prefix-Lengths Extension
+   over wireless links, due to the irregular coverage areas provided by
+   wireless transmitters.  As a result, it is possible that two foreign
+   agents advertising the same prefix might indeed provide different
+   connectivity to prospective mobile nodes.  The Prefix-Lengths
+   Extension SHOULD NOT be included in the advertisements sent by agents
+   in such a configuration.
+
+   Foreign agents using different wireless interfaces would have to
+   cooperate using special protocols to provide identical coverage in
+   space, and thus be able to claim to have wireless interfaces situated
+   on the same subnetwork.  In the case of wired interfaces, a mobile
+   node disconnecting and subsequently connecting to a new point of
+   attachment may well send in a new Registration Request no matter
+   whether the new advertisement is on the same medium as the last
+   recorded advertisement.  And, finally, in areas with dense
+   populations of foreign agents it would seem unwise to require the
+   propagation via routing protocols of the subnet prefixes associated
+   with each individual wireless foreign agent; such a strategy could
+   lead to quick depletion of available space for routing tables,
+
+
+
+
+
+Perkins                      Standards Track                   [Page 94]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   unwarranted increases in the time required for processing routing
+   updates, and longer decision times for route selection if routes
+   (which are almost always unnecessary) are stored for wireless
+   "subnets".
+
+Appendix E.  Interoperability Considerations
+
+   This document specifies revisions to RFC 2002 that are intended to
+   improve interoperability by resolving ambiguities contained in the
+   earlier text.  Implementations that perform authentication according
+   to the new more precisely specified algorithm would be interoperable
+   with earlier implementations that did what was originally expected
+   for producing authentication data.  That was a major source of non-
+   interoperability before.
+
+   However, this specification does have new features that, if used,
+   would cause interoperability problems with older implementations.
+   All features specified in RFC 2002 will work with the new
+   implementations, except for V-J compression [36].  The following list
+   details some of the possible areas of compatibility problems that may
+   be experienced by nodes conforming to this revised specification,
+   when attempting to interoperate with nodes obeying RFC 2002.
+
+   o  A client that expects some of the newly mandatory features (like
+      reverse tunneling) from a foreign agent (FA) would still be
+      interoperable as long as it pays attention to the 'T' bit.
+
+   o  Mobile nodes (MNs) that use the NAI extension to identify
+      themselves would not work with old mobility agents.
+
+   o  Mobile nodes that use a zero home address and expect to receive
+      their home address in the Registration Reply would not work with
+      old mobility agents.
+
+   o  Mobile nodes that attempt to authenticate themselves without using
+      the Mobile-Home authentication extension will be unable to
+      successfully register with their home agent.
+
+   In all of these cases, a robust and well-configured mobile node is
+   very likely to be able to recover if it takes reasonable actions upon
+   receipt of a Registration Reply with an error code indicating the
+   cause for rejection.  For instance, if a mobile node sends a
+   Registration Request that is rejected because it contains the wrong
+   kind of authentication extension, then the mobile node could retry
+   the registration with a mobile-home authentication extension, since
+   the foreign agent and/or home agent in this case will not be
+   configured to demand the alternative authentication data.
+
+
+
+
+Perkins                      Standards Track                   [Page 95]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+Appendix F.  Changes since RFC 3344
+
+   The following revisions to details of the specification in this
+   document were made after RFC 3344 was published.  A list of changes
+   from RFC 2002 made during the development of RFC 3344 [21] may be
+   found in the latter document.  For items marked with issue numbers,
+   more information is available by consulting the MIP4 mailing list
+   archives.
+
+   o  Showed more bit definitions in the Agent Advertisement message
+      structure (see Section 2.1.1).  New advertisement bits have been
+      defined by other specification documents, but not reflected in
+      previous publications of this specification; this has led to
+      confusion.  Citations for the other specification documents have
+      also been included.
+
+   o  (Issue 6) The behavior of the home agent was changed to avoid
+      mandating error replies to Registration Requests that were
+      invalidated because the foreign agent failed authentication.  The
+      intention is to make the home agent more robust against Denial of
+      Service attacks in which the malicious device has no intention of
+      providing a valid Registration Request but only wants to congest
+      traffic on the home network.  See Section 3.8.2.1.
+
+   o  Due to non-unique assignment of IPv4 addresses in many domains, it
+      is possible for different mobile nodes to have the same home
+      address.  If they use the NAI, the foreign agent can still
+      distinguish them.  Language was added to Section 3.7.1 and Section
+      3.7.3.1 to specify that the foreign agent MUST use the NAI to
+      distinguish mobile nodes with the same home address.
+
+   o  (Issue 45) Specified that a foreign agent MUST NOT apply a
+      Foreign-Home Authentication extension to a mobile node's
+      deregistration request.  Also, the foreign agent MUST NOT apply a
+      Foreign-Home Authentication extension unless the Care-of Address
+      in the Registration Request matches an address advertised by the
+      foreign agent.
+
+   o  Specified that the Mobility Security Association to be used by the
+      foreign agent and home agent depends upon values contained in the
+      message data, not the IP headers.
+
+   o  (Issues 9, 18) Created a new error code for use by the foreign
+      agent, for the case when the foreign agent does not serve the
+      mobile node as a home agent.  Formerly, the foreign agent could
+      use an error Code of 136 for this case.
+
+
+
+
+
+Perkins                      Standards Track                   [Page 96]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+   o  (Issue 17) Specified that, if the home agent cannot support the
+      requested nonzero unicast address in the Home Address field of the
+      Registration Request, then it MUST reject the registration with an
+      error Code of 129.  See Section 3.8.3.2.
+
+   o  (Issue 19) Specified that multiple authorization-enabling
+      extensions may be present in the Registration Request message, but
+      that the home agent has to (somehow) ensure that all have been
+      checked (see Section 3.8.3.1).
+
+   o  (Issue 20) Specified that the foreign agent SHOULD NOT modify any
+      of the fields of the Registration Reply message that are covered
+      by the Mobile-Home Authentication Extension, when it relays the
+      packet to the mobile node.
+
+   o  (Issue 21) Clarified that the foreign agent removes extensions
+      that do not precede any authorization-enabling extension, not just
+      the Mobile-Home Authentication extension (Section 3.7.3.2).
+
+   o  (Issue 44) Specified that the address advertised by the foreign
+      agent in Agent Advertisements is the care-of address offered on
+      that network interface, not necessarily the address of the network
+      interface (Section 3.7.2.2).
+
+   o  (Issue 45) Clarification in Section 3.7.2.1 that Code 77 can only
+      apply to a Registration Request with nonzero Lifetime.
+
+   o  Created a new error code for use when a foreign agent can detect
+      that the Home Agent address field is incorrect.
+
+   o  Prohibited the use of the Foreign-Home Authorization Extension on
+      deregistration messages.
+
+   o  Cleaned up some more wording having to do with authorization-
+      enabling extensions.
+
+   o  For consistency, changed some wording about copying UDP ports.
+
+   o  Added wording to clearly not disallow dynamically configuring
+      netmask and security information at the mobile node.
+
+   o  Revamped Changes section.
+
+   o  Updated citations.
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 97]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+Appendix G.  Example Messages
+
+G.1.  Example ICMP Agent Advertisement Message Format
+
+     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      |     Code      |           Checksum            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Num Addrs   |Addr Entry Size|           Lifetime            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       Router Address[1]                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      Preference Level[1]                      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       Router Address[2]                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      Preference Level[2]                      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        ....                                   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Type = 16   |     Length    |      Sequence Number          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    Registration Lifetime      |R|B|H|F|M|G|r|T|U|X|I|reserved |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                     Care-of Address[1]                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                     Care-of Address[2]                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         ....                                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    :                     Optional  Extensions                      :
+    :   ....                ......                      ......      :
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 98]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+G.2.  Example Registration Request Message Format
+
+   The UDP header is followed by the Mobile IP fields shown below:
+
+     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 = 1  |S|B|D|M|G|r|T|x|          Lifetime             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Home Address                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                           Home Agent                          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Care-of Address                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    +                         Identification                        +
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                Optional Non-Auth Extensions for HA ...        |
+    |                     ( variable length )                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Type = 32   |      Length   |           SPI                 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          SPI (cont.)          |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+    :         MN-HA Authenticator ( variable length )               :
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    :           Optional  Non-Auth Extensions for FA .........
+    :           Optional  MN-FA  Authentication Extension...
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                   [Page 99]
+
+RFC 5944                   IP Mobility Support             November 2010
+
+
+G.3.  Example Registration Reply Message Format
+
+   The UDP header is followed by the Mobile IP fields shown below:
+
+     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 = 3    |     Code      |           Lifetime            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Home Address                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                           Home Agent                          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    +                         Identification                        +
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                 Optional  HA  Non-Auth Extensions ...         |
+    |                     ( variable length )                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Type = 32   |      Length   |           SPI                 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          SPI (cont.)          |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+    :         MN-HA Authenticator ( variable length )               :
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    :           Optional  Extensions used by FA.........
+    :           Optional  MN-FA Authentication Extension...
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Author's Address
+
+   Charles E. Perkins (editor)
+   WiChorus Inc.
+   3590 N. 1st Street, Suite 300
+   San Jose, CA  95134
+   USA
+
+   EMail: charliep@computer.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins                      Standards Track                  [Page 100]
+