diff options
Diffstat (limited to 'doc/rfc/rfc2002.txt')
| -rw-r--r-- | doc/rfc/rfc2002.txt | 4427 |
1 files changed, 4427 insertions, 0 deletions
diff --git a/doc/rfc/rfc2002.txt b/doc/rfc/rfc2002.txt new file mode 100644 index 0000000..6b230db --- /dev/null +++ b/doc/rfc/rfc2002.txt @@ -0,0 +1,4427 @@ + + + + + + +Network Working Group C. Perkins, Editor +Request for Comments: 2002 IBM +Category: Standards Track October 1996 + + IP Mobility Support + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +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. + +Table of Contents + + 1. Introduction 3 + 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 3 + 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 + 1.5. New Architectural Entities . . . . . . . . . . . . . . . 5 + 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 + 1.8. Specification Language . . . . . . . . . . . . . . . . . 11 + 1.9. Message Format and Protocol Extensibility . . . . . . . . 12 + 2. Agent Discovery 14 + 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . . 14 + 2.1.1. Mobility Agent Advertisement Extension . . . . . 16 + 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . . 18 + 2.1.3. One-byte Padding Extension . . . . . . . . . . . 19 + 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . . 19 + 2.3. Foreign Agent and Home Agent Considerations . . . . . . . 19 + 2.3.1. Advertised Router Addresses . . . . . . . . . . . 20 + + + +Perkins Standards Track [Page 1] + +RFC 2002 IP Mobility Support October 1996 + + + 2.3.2. Sequence Numbers and Rollover Handling . . . . . 21 + 2.4. Mobile Node Considerations . . . . . . . . . . . . . . . 21 + 2.4.1. Registration Required . . . . . . . . . . . . . . 22 + 2.4.2. Move Detection . . . . . . . . . . . . . . . . . 22 + 2.4.3. Returning Home . . . . . . . . . . . . . . . . . 24 + 2.4.4. Sequence Numbers and Rollover Handling . . . . . 24 + 3. Registration 24 + 3.1. Registration Overview . . . . . . . . . . . . . . . . . . 25 + 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 26 + 3.3. Registration Request . . . . . . . . . . . . . . . . . . 26 + 3.4. Registration Reply . . . . . . . . . . . . . . . . . . . 29 + 3.5. Registration Extensions . . . . . . . . . . . . . . . . . 32 + 3.5.1. Computing Authentication Extension Values . . . . 32 + 3.5.2. Mobile-Home Authentication Extension . . . . . . 33 + 3.5.3. Mobile-Foreign Authentication Extension . . . . . 33 + 3.5.4. Foreign-Home Authentication Extension . . . . . . 34 + 3.6. Mobile Node Considerations . . . . . . . . . . . . . . . 34 + 3.6.1. Sending Registration Requests . . . . . . . . . . 36 + 3.6.2. Receiving Registration Replies . . . . . . . . . 40 + 3.6.3. Registration Retransmission . . . . . . . . . . . 42 + 3.7. Foreign Agent Considerations . . . . . . . . . . . . . . 43 + 3.7.1. Configuration and Registration Tables . . . . . . 44 + 3.7.2. Receiving Registration Requests . . . . . . . . . 44 + 3.7.3. Receiving Registration Replies . . . . . . . . . 47 + 3.8. Home Agent Considerations . . . . . . . . . . . . . . . . 49 + 3.8.1. Configuration and Registration Tables . . . . . . 49 + 3.8.2. Receiving Registration Requests . . . . . . . . . 49 + 3.8.3. Sending Registration Replies . . . . . . . . . . 53 + 4. Routing Considerations 55 + 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . . 56 + 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . . 56 + 4.2.1. Mobile Node Considerations . . . . . . . . . . . 56 + 4.2.2. Foreign Agent Considerations . . . . . . . . . . 57 + 4.2.3. Home Agent Considerations . . . . . . . . . . . . 58 + 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . . 59 + 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . . 60 + 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 61 + 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . . 62 + 5. Security Considerations 66 + 5.1. Message Authentication Codes . . . . . . . . . . . . . . 66 + 5.2. Areas of Security Concern in this Protocol . . . . . . . 66 + 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 67 + 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . . 67 + 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 67 + 5.6. Replay Protection for Registration Requests . . . . . . . 68 + 5.6.1. Replay Protection using Timestamps . . . . . . . 68 + 5.6.2. Replay Protection using Nonces . . . . . . . . . 69 + 6. Acknowledgments 71 + + + +Perkins Standards Track [Page 2] + +RFC 2002 IP Mobility Support October 1996 + + + A. Patent Issues 72 + A.1. IBM Patent #5,159,592 . . . . . . . . . . . . . . . . . . 72 + A.2. IBM Patent #5,148,479 . . . . . . . . . . . . . . . . . . 72 + B. Link-Layer Considerations 73 + C. TCP Considerations 73 + C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 73 + C.2. TCP Congestion Management . . . . . . . . . . . . . . . . 73 + D. Example Scenarios 74 + D.1. Registering with a Foreign Agent Care-of Address . . . . 74 + D.2. Registering with a Co-Located Care-of Address . . . . . . 75 + D.3. Deregistration . . . . . . . . . . . . . . . . . . . . . 76 + E. Applicability of Prefix Lengths Extension 76 +Editor's Address 79 + +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: + + a) the node must change its IP address whenever it changes its + point of attachment, or + + b) 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. + +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. + + + + + +Perkins Standards Track [Page 3] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + +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 it accommodates node movement 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 + + + +Perkins Standards Track [Page 4] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + +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 which 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 which provides + routing services to the mobile node while registered. The + foreign agent detunnels and delivers datagrams to the mobile + node 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 as 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). + + + + + + +Perkins Standards Track [Page 5] + +RFC 2002 IP Mobility Support October 1996 + + +1.6. Terminology + + This document frequently uses the following terms: + + Agent Advertisement + An advertisement message constructed by attaching a + special Extension to a router advertisement [4] 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 which 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. + + 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. + + + +Perkins Standards Track [Page 6] + +RFC 2002 IP Mobility Support October 1996 + + + 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.6). + + 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 7] + +RFC 2002 IP Mobility Support October 1996 + + +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 which forwards the registration to the home agent. + + The following steps provide a rough outline of operation of the + Mobile IP protocol: + + - 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. + + - A mobile node receives these Agent Advertisements and determines + whether it is on its home network or a foreign network. + + - 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. + + - 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 advertisements (a foreign agent care-of address), or by + some external assignment mechanism such as DHCP [6] (a co-located + care-of address). + + - 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 it, + possibly via a foreign agent (Section 3). + + + + + +Perkins Standards Track [Page 8] + +RFC 2002 IP Mobility Support October 1996 + + + - 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). + + - 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 "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. + + - 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 [6], + 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 + 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. + + + +Perkins Standards Track [Page 9] + +RFC 2002 IP Mobility Support October 1996 + + + 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 which 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. + + If a mobile node is using a co-located care-of address (as described + in (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, the figure below 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 the figure below, the mobile node + is using a foreign agent care-of address: + + + +Perkins Standards Track [Page 10] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + +----+ + +1.8. Specification Language + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that + the definition is an absolute requirement of the + specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means + that, in some circumstances, valid reasons may exist + to ignore this item, but the full implications must + be understood and carefully weighed before choosing + a different course. Unexpected results may result + otherwise. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST + be prepared to interoperate with another implementation + which does include the option. + + + + + + + + + +Perkins Standards Track [Page 11] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + +1.9. Message Format and Protocol Extensibility + + Mobile IP defines a set of new control messages, sent with UDP [17] + using well-known port number 434. Currently, the following two + message types are defined: + + 1 Registration Request + 3 Registration Reply + + Up-to-date values for the message types for Mobile IP control + messages are specified in the most recent "Assigned Numbers" [20]. + + In addition, for Agent Discovery, Mobile IP makes use of the existing + Router Advertisement and Router Solicitation messages defined for + ICMP Router Discovery [4]. + + 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. Each of these Extensions (with one + exception) is encoded in the following Type-Length-Value format: + + 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 ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + 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. + + + + + + +Perkins Standards Track [Page 12] + +RFC 2002 IP Mobility Support October 1996 + + + 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: + + - The first set consists of those Extensions which may appear only + in Mobile IP control messages (those sent to and from UDP port + number 434). Currently, the following Types are defined for + Extensions appearing in Mobile IP control messages: + + 32 Mobile-Home Authentication + 33 Mobile-Foreign Authentication + 34 Foreign-Home Authentication + + - The second set consists of those extensions which may appear only + in ICMP Router Discovery messages [4]. Currently, Mobile IP + defines the following Types for Extensions appearing in ICMP + Router Discovery messages: + + 0 One-byte Padding (encoded with no 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 most recent "Assigned + Numbers" [20]. + + 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. + + 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 + numbered in the range 128 through 255 is encountered which 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. + + + + + + + +Perkins Standards Track [Page 13] + +RFC 2002 IP Mobility Support October 1996 + + +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 [4] 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 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 B). + 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 [1], 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 an 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: + + + + +Perkins Standards Track [Page 14] + +RFC 2002 IP Mobility Support October 1996 + + + - 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 which + prompted the Advertisement. + + - IP Fields + + TTL The TTL for all Agent Advertisements MUST be set + to 1. + + Destination Address + As specified for ICMP Router Discovery [4], the IP + destination address of an Agent Advertisement MUST + be either the "all systems on this link" multicast + address (224.0.0.1) [5] 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. + + - 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. + + + + + + +Perkins Standards Track [Page 15] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + + If sent periodically, the nominal interval at which Agent + Advertisements are sent SHOULD be 1/3 of the advertisement Lifetime + given in the ICMP header. 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 [4] 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|V| reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | zero or more Care-of Addresses | + | ... | + + Type 16 + + Length (6 + 4*N), where 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 16] + +RFC 2002 IP Mobility Support October 1996 + + + 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 + rather than 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 GRE encapsulation. This agent implements receiving + tunneled datagrams that use GRE encapsulation [8]. + + V Van Jacobson header compression. This agent supports use + of Van Jacobson header compression [10] over the link + with any registered mobile node. + + reserved + Sent as zero; ignored on reception. + + 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 + + + +Perkins Standards Track [Page 17] + +RFC 2002 IP Mobility Support October 1996 + + + 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, and 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 which 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 of the Num Addrs field in + the ICMP Router Advertisement portion of the Agent + Advertisement. + + 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 E for implementation details about the use + of this Extension. + + + + + +Perkins Standards Track [Page 18] + +RFC 2002 IP Mobility Support October 1996 + + +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 which cannot be discovered by a link-layer + protocol MUST send Agent Advertisements. An agent which can be + discovered by a link-layer protocol SHOULD also implement Agent + Advertisements. 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 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 [4], except that: + + - a mobility agent MUST limit the rate at which it sends broadcast + or multicast Agent Advertisements; a recommended maximum rate is + once per second, AND + + + + +Perkins Standards Track [Page 19] + +RFC 2002 IP Mobility Support October 1996 + + + - 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). + + - 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. + + 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. + + 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. Thus, an agent MAY include one + of its own addresses in the advertisement. A foreign agent MAY + discourage use of this address as a default router by setting the + preference to a low value and by including the address of another + router in the advertisement (with a correspondingly higher + preference). Nevertheless, a foreign agent MUST route datagrams it + receives from registered mobile nodes (Section 4.2.2). + + + + + + + +Perkins Standards Track [Page 20] + +RFC 2002 IP Mobility Support October 1996 + + +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 reductions in sequence numbers that result from + reboots, from reductions that result 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 [4], 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, + 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 [4]. + + + + + +Perkins Standards Track [Page 21] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + + 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. + +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) which require exchanges of + authorization. + +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. + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 22] + +RFC 2002 IP Mobility Support October 1996 + + +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 + 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 a 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. + + + + + + + + + + + + + +Perkins Standards Track [Page 23] + +RFC 2002 IP Mobility Support October 1996 + + +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 reregistration 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: + + - request forwarding services when visiting a foreign network, + + - inform their home agent of their current care-of address, + + - renew a registration which is due to expire, and/or + + - 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. + + + + + + + + + + +Perkins Standards Track [Page 24] + +RFC 2002 IP Mobility Support October 1996 + + + Several other (optional) capabilities are available through the + registration procedure, which enable a mobile node to: + + - maintain multiple simultaneous registrations, so that a copy of + each datagram will be tunneled to each active care-of address + + - deregister specific care-of addresses while retaining other + mobility bindings, and + + - 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: + + - If a mobile node is registering a foreign agent care-of address, + the mobile node MUST register via that foreign agent. + + - 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. + + - If a mobile node is otherwise using a co-located care-of address, + the mobile node MUST register directly with its home agent. + + - 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 (Sections 3.3 and 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. + + + + +Perkins Standards Track [Page 25] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + +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 the + Mobile-Home Authentication Extension (Section 3.5.2). This Extension + immediately follows all non-authentication Extensions, except those + foreign agent-specific Extensions which 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. + + + + +Perkins Standards Track [Page 26] + +RFC 2002 IP Mobility Support October 1996 + + + 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 + + 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|V|rsv| 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 which are + sent to the care-of address. That is, the mobile node is + using a co-located care-of address. + + + + + +Perkins Standards Track [Page 27] + +RFC 2002 IP Mobility Support October 1996 + + + M Minimal encapsulation. If the 'M' bit is set, the + mobile node requests that its home agent use minimal + encapsulation [15] 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 [8] for datagrams tunneled to the mobile + node. + + V The mobile node requests that its mobility agent use Van + Jacobson header compression [10] over its link with the + mobile node. + + rsv Reserved bits; sent as zero + + 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.6. + + Extensions + The fixed portion of the Registration Request is followed + by one or more of the Extensions listed in Section 3.5. + The Mobile-Home Authentication 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. + + + + + + +Perkins Standards Track [Page 28] + +RFC 2002 IP Mobility Support October 1996 + + +3.4. Registration Reply + + A mobility agent returns a Registration Reply message to a mobile + node which has sent a Registration Request (Section 3.3) message. If + the mobile node is requesting service from a foreign agent, that + foreign agent will receive the Reply from the home agent and + subsequently relay it to the mobile node. The Reply message contains + 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 the Mobile-Home Authentication Extension, which 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.1 for complete details. + + Destination Address Copied from the source address of the + Registration Request to which the agent is + replying + + UDP fields: + + Source Port <variable> + + Destination Port Copied from the source port of the + corresponding Registration Request + (Section 3.7.1). + + + + + + + + + + +Perkins Standards Track [Page 29] + +RFC 2002 IP Mobility Support October 1996 + + + 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 30] + +RFC 2002 IP Mobility Support October 1996 + + + 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 Mobile-Home Authentication Extension). See + Sections 5.4 and 5.6. + + Extensions + The fixed portion of the Registration Reply is followed + by one or more of the Extensions listed in Section 3.5. + The Mobile-Home Authentication 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 requested Van Jacobson compression unavailable + 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) + + + + + + + + +Perkins Standards Track [Page 31] + +RFC 2002 IP Mobility Support October 1996 + + + 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 most recent + "Assigned Numbers" [20]. + +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: + + - the UDP payload (that is, the Registration Request or + Registration Reply data), + + - all prior Extensions in their entirety, and + + - the Type and Length of this Extension. + + The default authentication algorithm uses keyed-MD5 [21] in + "prefix+suffix" mode to compute a 128-bit "message digest" of the + registration message. The default authenticator is a 128-bit value + computed as the MD5 checksum over the the following stream of bytes: + + - the shared secret defined by the mobility security association + between the nodes and by SPI value specified in the + authentication Extension, followed by + + - the protected fields from the registration message, in the order + specified above, followed by + + - the shared secret again. + + 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 32] + +RFC 2002 IP Mobility Support October 1996 + + + The Security Parameter Index (SPI) within any of the authentication + Extensions defines the security context which is used to compute the + Authenticator value and which 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 which it implements. In addition, all implementations of Mobile + IP MUST implement the default authentication algorithm (keyed-MD5) + and mode ("prefix+suffix") defined above. + +3.5.2. Mobile-Home Authentication Extension + + Exactly one Mobile-Home Authentication Extension MUST be present in + all Registration Requests and Registration Replies, and is intended + to eliminate problems [2] which result from the uncontrolled + propagation of remote redirects in the Internet. The location of the + extension marks the end of the authenticated data. + + 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.) + +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. + + + + + + + +Perkins Standards Track [Page 33] + +RFC 2002 IP Mobility Support October 1996 + + + 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. 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. + + SPI Security Parameter Index (4 bytes). An opaque + identifier (see Section 1.6). + + Authenticator (variable length) (See Section 3.5.1.) + +3.6. Mobile Node Considerations + + A mobile node MUST be configured with its home address, a netmask, + and a mobility security association for each home agent. In + addition, a mobile node MAY be configured with 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 34] + +RFC 2002 IP Mobility Support October 1996 + + + For each pending registration, the mobile node maintains the + following information: + + - the link-layer address of the foreign agent to which the + Registration Request was sent, if applicable, + - the IP destination address of the Registration Request, + - the care-of address used in the registration, + - the Identification value sent in the registration, + - the originally requested Lifetime, and + - 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. + + 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 D shows some examples of how the fields in registration + messages would be set up in some typical registration scenarios. + + + + + + + +Perkins Standards Track [Page 35] + +RFC 2002 IP Mobility Support October 1996 + + +3.6.1. Sending Registration Requests + + The following sections specify details for the values 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: + + - When registering on a foreign network with a co-located care-of + address, the IP source address MUST be the care-of address. + + - In all other circumstances, the IP source address MUST be the + mobile node's home address. + + IP Destination Address: + + - 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. + + - 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. In addition, when transmitting + this Registration 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. + + - 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. + + + + + + + + + + + + +Perkins Standards Track [Page 36] + +RFC 2002 IP Mobility Support October 1996 + + + - 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: + + - 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 [19]. + +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. + + 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: + + + + + + +Perkins Standards Track [Page 37] + +RFC 2002 IP Mobility Support October 1996 + + + - 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 de-tunnels the received datagram in the + same way as any other datagram tunneled directly to it. + + - 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. + + The Lifetime field is chosen as follows: + + - 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. + + + + +Perkins Standards Track [Page 38] + +RFC 2002 IP Mobility Support October 1996 + + + - 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). + + - Similarly, a Lifetime of zero is used when the mobile node + deregisters all care-of addresses, such as upon returning home. + + 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.6 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 following ordering MUST be followed: + + 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 (which may or may not also be used by + the foreign agent), followed by + + c) The Mobile-Home Authentication Extension, followed by + + d) If present, any non-authentication Extensions used only by + the foreign agent, followed by + + + + +Perkins Standards Track [Page 39] + +RFC 2002 IP Mobility Support October 1996 + + + 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: + + - the registration was accepted, + - the registration was denied by the foreign agent, or + - 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. + + Also, the authentication in the Registration Reply MUST be checked. + That is, the mobile node MUST check for the presence of a valid + authentication 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. + + + + + + +Perkins Standards Track [Page 40] + +RFC 2002 IP Mobility Support October 1996 + + + 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 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 which implements ARP, the mobile node MUST follow the + procedures described in Section 4.6 with regard to ARP, proxy ARP, + and gratuitous ARP. + + 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 + + + +Perkins Standards Track [Page 41] + +RFC 2002 IP Mobility Support October 1996 + + + 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, Lifetime too long) + + In this case, the Lifetime field in the Registration Reply will + contain the maximum Lifetime value which that 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, 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.6). 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. + + 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; + + + +Perkins Standards Track [Page 42] + +RFC 2002 IP Mobility Support October 1996 + + + thus the retransmission does not count as a new registration (Section + 5.6). 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, + 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 except when + relaying a Registration Request received from a mobile node, to the + 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 + valid (de)Registration Requests originated by a mobile node. + + + + + + + + +Perkins Standards Track [Page 43] + +RFC 2002 IP Mobility Support October 1996 + + +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: + + - the link-layer source address of the mobile node + - the IP Source Address (the mobile node's Home Address) + - the IP Destination Address (as specified in 3.6.2.3) + - the UDP Source Port + - the Home Agent address + - the Identification field + - the requested registration Lifetime, and + - the remaining Lifetime of the pending or current registration. + + 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 and 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 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 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 + + + + + + +Perkins Standards Track [Page 44] + +RFC 2002 IP Mobility Support October 1996 + + + Request separately from the existing visitor list entry for the + mobile node. If the Registration Request requests 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. + + 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. Otherwise, an + authentication failure is very likely to occur at the home agent. In + addition, the foreign agent proceeds as follows: + + - It MUST process and remove any Extensions following the + Mobile-Home Authentication Extension, + - It MAY append any of its own non-authentication Extensions of + relevance to the home agent, if applicable, and + - It MUST append the Foreign-Home Authentication Extension, if the + foreign agent shares a mobility security association with the home + agent. + + + + + + + + +Perkins Standards Track [Page 45] + +RFC 2002 IP Mobility Support October 1996 + + + Specific fields within the IP header and the UDP header of the + relayed Registration Request MUST be set as follows: + + IP Source Address + The foreign agent's address on the interface from which + the message will be sent. + + 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. + +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 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 + + + +Perkins Standards Track [Page 46] + +RFC 2002 IP Mobility Support October 1996 + + + used. + + IP Destination Address + Copied from the IP Source Address of the Registration + Request. + + UDP Source Port + 434 + + UDP Destination Port + Copied from the UDP Source Port of the Registration + Request. + +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 no + pending Request is found, 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 + + + +Perkins Standards Track [Page 47] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + +3.7.3.2. Forwarding Replies to the Mobile Node + + A Registration Reply which 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 mobile node has + accepted the registration and the Lifetime field is nonzero, the + foreign agent MUST set the Lifetime in the visitor list entry to the + value specified in the Lifetime field of the Registration Reply. 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: + + - It MUST process and remove any Extensions following the + Mobile-Home Authentication Extension, + - It MAY append its own non-authentication Extensions of relevance + to the mobile node, if applicable, and + - 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 + 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 + + + +Perkins Standards Track [Page 48] + +RFC 2002 IP Mobility Support October 1996 + + + 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 home address and 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: + + - the mobile node's care-of address + - the Identification field from the Registration Reply + - the remaining Lifetime of the registration + + 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. + 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 + + + + +Perkins Standards Track [Page 49] + +RFC 2002 IP Mobility Support October 1996 + + + If the home agent accepts an incoming Registration Request, it MUST + update its record of the the mobile node's mobility binding(s) and + SHOULD send a Registration Reply with a suitable Code. Otherwise + (the home agent denies the Request), it SHOULD send a Registration + Reply with an appropriate Code specifying the reason the Request was + denied. The following sections describe this behavior in more + detail. + +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 a valid + Mobile-Home Authentication Extension, and perform the + indicated authentication. Exactly one Mobile-Home + Authentication Extension MUST be present in the Registration + Request, and the home agent MUST check the Authenticator + value in the Extension. If 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 home agent MUST reject the mobile node's + registration and SHOULD send a Registration Reply to the + mobile node with Code 131. The home agent MUST then discard + the Request 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 Mobile-Home Authentication Extension. See + Section 5.6 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.6. 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, 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 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 + + + +Perkins Standards Track [Page 50] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + + 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 returning 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. + +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 Reply Code 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: + + - 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. + + - 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. + + - 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. + + + + +Perkins Standards Track [Page 51] + +RFC 2002 IP Mobility Support October 1996 + + + 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 which + 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. + + 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 + 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 which 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 Reply 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 + + + +Perkins Standards Track [Page 52] + +RFC 2002 IP Mobility Support October 1996 + + + 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 error code 135. Similarly, a + home agent may refuse to grant service to mobile nodes which have + entered unauthorized service areas by returning a Registration Reply + with a Code of 129. + + If the Reserved field is nonzero, it MUST deny the Request with a + Code of 134. + +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 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 mobile nodes pick + values for the IP and UDP header fields of a Registration Reply. + + IP Source Address + Copied from the IP Destination Address of 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. + + + + + +Perkins Standards Track [Page 53] + +RFC 2002 IP Mobility Support October 1996 + + + 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. + + 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 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). + + + +Perkins Standards Track [Page 54] + +RFC 2002 IP Mobility Support October 1996 + + + The Home Address field MUST be copied from the corresponding field in + the Registration Request. + + 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 55] + +RFC 2002 IP Mobility Support October 1996 + + +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 + [8] are alternate encapsulation methods which 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 [4] is one such method. + + When registered on a foreign network, the mobile node chooses a + default router by the following rules: + + - If the mobile node is registered using a foreign agent care-of + address, then 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. The + mobile node MAY also consider the IP source address of the Agent + Advertisement as another possible choice for the IP address of a + default router, along with the (possibly empty) list of Router + Addresses from the ICMP Router Advertisement portion of the + message. In such cases, the IP source address MUST be considered + to be the worst choice (lowest preference) for a default router. + + - 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, along with the + (possibly empty) list of Router Addresses from the ICMP Router + + + +Perkins Standards Track [Page 56] + +RFC 2002 IP Mobility Support October 1996 + + + Advertisement portion of the message. If so, the IP source + address MUST be considered to be the worst choice (lowest + preference) for 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. + + Beyond these rules, the actual selection of the default router is + made by the selection method specified for ICMP Router Discovery [4], + among the Router Addresses specified above. In any case, a mobile + node registered via a foreign agent MAY choose its foreign agent as a + default router. + + Note that Van Jacobson header compression [10] will not function + properly unless all TCP IP datagrams to and from the mobile node + pass, respectively, through the same first and last-hop router. The + mobile node, therefore, MUST select its foreign agent as its default + router if it performs Van Jacobson header compression with its + foreign agent. + +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). + + 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. In addition, the foreign agent SHOULD send an + appropriate ICMP Redirect message to the mobile node. + + + + + + + + +Perkins Standards Track [Page 57] + +RFC 2002 IP Mobility Support October 1996 + + +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. + + 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 SHOULD be able to decapsulate and further deliver packets + addressed to themselves, sent by a mobile node for the purpose of + maintaining location privacy, as described in Section 5.5. + + 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 + 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 + + + +Perkins Standards Track [Page 58] + +RFC 2002 IP Mobility Support October 1996 + + + rules apply in the forwarding of that datagram to the mobile node: + + - 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. + + - Otherwise (the inner Destination Address is NOT the same as the + outer Destination Address), the home agent SHOULD encapsulate + the datagram again (recursive 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 + 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 + + + +Perkins Standards Track [Page 59] + +RFC 2002 IP Mobility Support October 1996 + + + 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 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 [5] + messages. Otherwise, it MUST use its home address. + + Alternatively, a mobile node which wishes to receive multicasts MAY + join groups via a bi-directional 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. 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 (recursive tunneling) to the mobile + node's care-of address. + + 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 which 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 which 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. + + + + + +Perkins Standards Track [Page 60] + +RFC 2002 IP Mobility Support October 1996 + + +4.5. Mobile Routers + + A mobile node can be a router, which 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. + + 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 router + and foreign agent on the aircraft. Normal IP routing will + route the datagram to the fixed network at the airline's + headquarters. + + + + + + + + +Perkins Standards Track [Page 61] + +RFC 2002 IP Mobility Support October 1996 + + + e) The aircraft router and foreign agent's home agent there + intercepts the datagram and tunnels 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 illustrated 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. + + A home agent MAY be configured to have a permanent registration for + the fixed node, that indicates the mobile router's address as the + fixed host's care-of address. The mobile router's home agent will + usually 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 + recursive tunneling as described above. + + Alternatively, the mobile router MAY advertise connectivity to the + entire mobile network using normal IP routing protocols through a + bi-directional tunnel to its own home agent. This method avoids the + need for recursive tunneling of datagrams. + +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. + + + + +Perkins Standards Track [Page 62] + +RFC 2002 IP Mobility Support October 1996 + + + 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: + + - A Proxy ARP [18] is an ARP Reply sent by one node on behalf + of another node which 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. + + - A Gratuitous ARP [23] 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 [18] 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 + 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 [18], 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. + + + +Perkins Standards Track [Page 63] + +RFC 2002 IP Mobility Support October 1996 + + + 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 its + (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 its home agent. Th 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 its (de)Registration + Reply. + + 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 sent 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 + + + +Perkins Standards Track [Page 64] + +RFC 2002 IP Mobility Support October 1996 + + + 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: + + - 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. + + - 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. + + - The mobile node transmits its Registration Request. + + - 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. If, instead, the home agent rejects the Registration + Request, no ARP processing (gratuitous nor proxy) is performed by + the home agent. + + When a mobile node later returns to its home network, the following + steps, in this order, MUST be performed: + + - The mobile node decides to register at home, perhaps because it + has received an Agent Advertisement from its home agent. + + + + + + +Perkins Standards Track [Page 65] + +RFC 2002 IP Mobility Support October 1996 + + + - 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. + + - The mobile node performs a gratuitous ARP for itself. + + - The mobile node transmits its Registration Request. + + - 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. If, instead, the home agent rejects the + Registration Request, no ARP processing (gratuitous nor proxy) is + performed by the home agent. + +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 keyed MD5 [21], with a key size of 128 bits. + The default mode of operation is to both precede and follow the data + to be hashed, by the 128-bit key; that is, MD5 is to be used in + "prefix+suffix" mode. The foreign agent MUST also support + authentication using keyed MD5 and key sizes of 128 bits or greater, + with manual key distribution. More authentication algorithms, + algorithm modes, key distribution methods, and key sizes MAY also be + supported. + +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 [2]. 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. + + + +Perkins Standards Track [Page 66] + +RFC 2002 IP Mobility Support October 1996 + + +5.3. Key Management + + This specification requires a strong authentication mechanism (keyed + MD5) which 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. + If nonces are used in connection with replay protection, they must + also be selected carefully. Eastlake, et al. [7] 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. + + + + + + + + + + + + + +Perkins Standards Track [Page 67] + +RFC 2002 IP Mobility Support October 1996 + + +5.6. 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 (but see Appendix A.2 for a patent that + may apply to nonce-based replay protection). + + The style of replay protection in effect between a mobile node and + its home agent is part of the mobile 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 + MUST be copied unchanged from the Registration Request to the Reply. + The foreign agent uses those bits (and the mobile node's home + 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 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.6.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. 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 [13]. The low-order 32 bits of the NTP format represent + fractional seconds, and those bits which 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 + + + +Perkins Standards Track [Page 68] + +RFC 2002 IP Mobility Support October 1996 + + + 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 field also 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 a valid Mobile-Home + Authentication 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. + + If the timestamp is valid, the home agent copies the entire + Identification field into the Registration Reply it returns the Reply + 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 (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 in the Registration Reply are + identical to those in the rejected registration attempt, before using + the high-order bits for clock resynchronization. + +5.6.2. Replay Protection using Nonces + + Implementors of this optional mechanism should examine Appendix A.2 + for a patent that may be applicable to nonce-based replay protection. + + 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 [7]. 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 + + + +Perkins Standards Track [Page 69] + +RFC 2002 IP Mobility Support October 1996 + + + the Identification from the Registration Request message into the + low-order 32 bits of the Identification 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 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 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 bits 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). + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 70] + +RFC 2002 IP Mobility Support October 1996 + + +6. Acknowledgments + + Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp + and John Ioannidis (JI) (Columbia), for forming the working group, + chairing it, and putting so much effort into its early development. + + Thanks also to Kannan Alaggapan, Greg Minshall, and Tony Li 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) + + - Ran Atkinson (Naval Research Lab), + - Dave Johnson (Carnegie Mellon University), + - Frank Kastenholz (FTP Software), + - Anders Klemets (KTH), + - Chip Maguire (KTH), + - Andrew Myles (Macquarie University), + - Al Quirt (Bell Northern Research), + - Yakov Rekhter (IBM), and + - Fumio Teraoka (Sony). + + Thanks to Charlie Kunzinger and to Bill Simpson, the editors who + produced the first drafts for of this document, reflecting the + discussions of the Working Group. Much of the new text of this memo + is due to Jim Solomon and Dave Johnson. + + Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), and Frank + Kastenholz (FTP Software) for their generous support in hosting + interim Working Group meetings. + + + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 71] + +RFC 2002 IP Mobility Support October 1996 + + +A. Patent Issues + + As of the time of publication, the IETF had been made aware of two + patents that may be relevant to implementors of the protocol + described in this technical specification. + +A.1. IBM Patent #5,159,592 + + Charles Perkins, editor of this memo, is sole inventor of U.S. Patent + No. 5,159,592, assigned to IBM. In a letter dated May 30, 1995, IBM + brought this patent to the attention of the IETF, stating that this + patent "relates to the Mobile IP." We understand that IBM did not + intend to assert that any particular implementation of Mobile IP + would or would not infringe the patent, but rather that IBM was + meeting what it viewed as a duty to disclose information that could + be relevant to the process of adopting a standard. + + Based on a review of the claims of the patent, IETF believes that a + system of registering an address obtained from a foreign agent, as + described in the document, would not necessarily infringe any of the + claims of the patent; and that a system in which an address is + obtained elsewhere and then registered can be implemented without + necessarily infringing any claims of the patent. Accordingly, our + view is that the proposed protocol can be implemented without + necessarily infringing the Perkins Patent. + + Parties considering adopting this protocol must be aware that some + specific implementations, or features added to otherwise non- + infringing implementations, may raise an issue of infringement with + respect to this patent or to some other patent. + + This statement is for the IETF's assistance in its standard-setting + procedure, and should not be relied upon by any party as an opinion + or guarantee that any implementation it might make or use would not + be covered by the Perkins Patent and any other patents. In + particular, IBM might disagree with the interpretation of this patent + described herein. + +A.2. IBM Patent #5,148,479 + + This patent, also assigned to IBM, may be relevant to those who + implement nonce-based replay protection as described in Section + 5.6.2. Note that nonce-based replay protection is an optional + feature of this specification. Timestamp-based replay protection, on + the other hand, (Section 5.6.1) is a requirement of this + specification. + + + + + +Perkins Standards Track [Page 72] + +RFC 2002 IP Mobility Support October 1996 + + +B. 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 [11], 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) [22] and its Internet Protocol + Control Protocol (IPCP) [12], negotiates 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. + +C. TCP Considerations + +C.1. TCP Timers + + Most hosts and routers which implement TCP/IP do not permit easy + configuration of the TCP timer values. When high-delay (e.g., + SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are in + use, the default TCP timer values in many systems may cause + retransmissions or timeouts, even when the link and network are + actually operating properly with greater than usual delays 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 which consume already scarce bandwidth. Vendors are + encouraged to make TCP timers more configurable. Vendors of systems + designed for the mobile computing markets should pick default timer + values more suited to low-bandwidth, high-delay links. Users of + mobile nodes should be sensitive to the possibility of timer-related + difficulties. + +C.2. TCP Congestion Management + + Mobile nodes often use media which 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 [9]. 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- + + + +Perkins Standards Track [Page 73] + +RFC 2002 IP Mobility Support October 1996 + + + start mechanisms [9] 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. [3]; there is no easy solution + available, and certainly no solution likely to be installed soon on + all correspondent nodes. While this problem is beyond the scope of + this document, it does illustrate that providing performance + transparency to mobile nodes involves understanding mechanisms + outside the network layer. It also indicates the need to avoid + designs which systematically drop packets; such designs might + otherwise be considered favorably when making engineering tradeoffs. + +D. Example Scenarios + + This section shows example Registration Requests for several common + scenarios. + +D.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: + The Mobile-Home Authentication Extension + + + +Perkins Standards Track [Page 74] + +RFC 2002 IP Mobility Support October 1996 + + +D.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 [6] + 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 75] + +RFC 2002 IP Mobility Support October 1996 + + +D.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: + The Mobile-Home Authentication Extension + +E. 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. + + + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 76] + +RFC 2002 IP Mobility Support October 1996 + + + 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, + 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". + +References + + [1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. + + [2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. + ACM Computer Communications Review, 19(2), March 1989. + + [3] Ramon Caceres and Liviu Iftode. Improving the Performance + of Reliable Transport Protocols in Mobile Computing + Environments. IEEE Journal on Selected Areas in Communications, + 13(5):850--857, June 1995. + + [4] Deering, S., Editor, "ICMP Router Discovery Messages", + RFC 1256, September 1991. + + [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, + RFC 1112, August 1989. + + [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, + October 1993. + + [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness + Requirements for Security", RFC 1750, December 1994. + + [8] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic + Routing Encapsulation (GRE)", RFC 1701, October 1994. + + [9] Van Jacobson. Congestion Avoidance and Control. In Proceedings + of the SIGCOMM '88 Symposium: Communications Architectures & + Protocols, pages 314--329, August 1988. + + + + +Perkins Standards Track [Page 77] + +RFC 2002 IP Mobility Support October 1996 + + + [10] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial + Links", RFC 1144, February 1990. + + [11] McCloghrie, K., and F. Kastenholz, "Evolution of the + Interfaces Group of MIB-II", RFC 1573, January 1994. + + [12] McGregor, G., "The PPP Internet Protocol Control Protocol + (IPCP)", RFC 1332, May 1992. + + [13] Mills, D., "Network Time Protocol (Version 3): + Specification, Implementation and Analysis", RFC 1305, March + 1992. + + [14] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, + October 1996. + + [16] Plummer, D., "An Ethernet Address Resolution Protocol: + Or Converting Network Protocol Addresses to 48.bit Ethernet + Addresses 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., "Multi-LAN Address Resolution", RFC 925, October + 1984. + + [19] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, + September 1981. + + [20] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, + RFC 1700, October 1994. + + [21] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [22] Simpson, W., Editor, "The Point-to-Point Protocol + (PPP)", STD 51, RFC 1661, July 1994. + + [23] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The + Protocols. Addison-Wesley, Reading, Massachusetts, 1994. + + + + + + + +Perkins Standards Track [Page 78] + +RFC 2002 IP Mobility Support October 1996 + + +Editor's Address + + Questions about this memo can also be directed to the editor: + + Charles Perkins + Room H3-D34 + T. J. Watson Research Center + IBM Corporation + 30 Saw Mill River Rd. + Hawthorne, NY 10532 + + Work: +1-914-784-7350 + Fax: +1-914-784-6205 + EMail: perk@watson.ibm.com + + The working group can be contacted via the current chair: + + Jim Solomon + Motorola, Inc. + 1301 E. Algonquin Rd. + Schaumburg, IL 60196 + + Work: +1-847-576-2753 + EMail: solomon@comm.mot.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 79] + |