diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3220.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3220.txt')
| -rw-r--r-- | doc/rfc/rfc3220.txt | 5491 |
1 files changed, 5491 insertions, 0 deletions
diff --git a/doc/rfc/rfc3220.txt b/doc/rfc/rfc3220.txt new file mode 100644 index 0000000..55290a6 --- /dev/null +++ b/doc/rfc/rfc3220.txt @@ -0,0 +1,5491 @@ + + + + + + +Network Working Group C. Perkins, Ed. +Request for Comments: 3220 Nokia Research Center +Obsoletes: 2002 January 2002 +Category: Standards Track + + + IP Mobility Support for IPv4 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +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. + +Contents + + 1. Introduction 3 + 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . 4 + 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . 5 + 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . 5 + 1.5. New Architectural Entities . . . . . . . . . . . . . . 5 + 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . 6 + 1.7. Protocol Overview . . . . . . . . . . . . . . . . . . . 9 + 1.8. Message Format and Protocol Extensibility . . . . . . . 13 + 1.9. Type-Length-Value Extension Format for Mobile IP + Extensions . . . . . . . . . . . . . . . . . . . . . 15 + 1.10. Long Extension Format . . . . . . . . . . . . . . . . . 16 + + + +Perkins Standards Track [Page 1] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 1.11. Short Extension Format . . . . . . . . . . . . . . . . 16 + 2. Agent Discovery 17 + 2.1. Agent Advertisement . . . . . . . . . . . . . . . . . . 18 + 2.1.1. Mobility Agent Advertisement Extension . . . . 20 + 2.1.2. Prefix-Lengths Extension . . . . . . . . . . . 22 + 2.1.3. One-byte Padding Extension . . . . . . . . . . 22 + 2.2. Agent Solicitation . . . . . . . . . . . . . . . . . . 23 + 2.3. Foreign Agent and Home Agent Considerations . . . . . . 23 + 2.3.1. Advertised Router Addresses . . . . . . . . . . 24 + 2.3.2. Sequence Numbers and Rollover Handling . . . . 24 + 2.4. Mobile Node Considerations . . . . . . . . . . . . . . 25 + 2.4.1. Registration Required . . . . . . . . . . . . . 26 + 2.4.2. Move Detection . . . . . . . . . . . . . . . . 26 + 2.4.3. Returning Home . . . . . . . . . . . . . . . . 27 + 2.4.4. Sequence Numbers and Rollover Handling . . . . 28 + 3. Registration 28 + 3.1. Registration Overview . . . . . . . . . . . . . . . . . 29 + 3.2. Authentication . . . . . . . . . . . . . . . . . . . . 30 + 3.3. Registration Request . . . . . . . . . . . . . . . . . 30 + 3.4. Registration Reply . . . . . . . . . . . . . . . . . . 33 + 3.5. Registration Extensions . . . . . . . . . . . . . . . . 36 + 3.5.1. Computing Authentication Extension Values . . . 36 + 3.5.2. Mobile-Home Authentication Extension . . . . . 37 + 3.5.3. Mobile-Foreign Authentication Extension . . . . 37 + 3.5.4. Foreign-Home Authentication Extension . . . . . 38 + 3.6. Mobile Node Considerations . . . . . . . . . . . . . . 38 + 3.6.1. Sending Registration Requests . . . . . . . . . 40 + 3.6.2. Receiving Registration Replies . . . . . . . . 43 + 3.6.3. Registration Retransmission . . . . . . . . . . 46 + 3.7. Foreign Agent Considerations . . . . . . . . . . . . . 46 + 3.7.1. Configuration and Registration Tables . . . . . 47 + 3.7.2. Receiving Registration Requests . . . . . . . . 48 + 3.7.3. Receiving Registration Replies . . . . . . . . 51 + 3.8. Home Agent Considerations . . . . . . . . . . . . . . . 53 + 3.8.1. Configuration and Registration Tables . . . . . 54 + 3.8.2. Receiving Registration Requests . . . . . . . . 55 + 3.8.3. Sending Registration Replies . . . . . . . . . 58 + 4. Routing Considerations 61 + 4.1. Encapsulation Types . . . . . . . . . . . . . . . . . . 61 + 4.2. Unicast Datagram Routing . . . . . . . . . . . . . . . 61 + 4.2.1. Mobile Node Considerations . . . . . . . . . . 61 + 4.2.2. Foreign Agent Considerations . . . . . . . . . 62 + 4.2.3. Home Agent Considerations . . . . . . . . . . . 63 + 4.3. Broadcast Datagrams . . . . . . . . . . . . . . . . . . 65 + 4.4. Multicast Datagram Routing . . . . . . . . . . . . . . 65 + 4.5. Mobile Routers . . . . . . . . . . . . . . . . . . . . 66 + 4.6. ARP, Proxy ARP, and Gratuitous ARP . . . . . . . . . . 68 + 5. Security Considerations 72 + + + +Perkins Standards Track [Page 2] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 5.1. Message Authentication Codes . . . . . . . . . . . . . 72 + 5.2. Areas of Security Concern in this Protocol . . . . . . 72 + 5.3. Key Management . . . . . . . . . . . . . . . . . . . . 73 + 5.4. Picking Good Random Numbers . . . . . . . . . . . . . . 73 + 5.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 73 + 5.6. Ingress Filtering . . . . . . . . . . . . . . . . . . . 74 + 5.7. Replay Protection for Registration Requests . . . . . . 74 + 5.7.1. Replay Protection using Timestamps . . . . . . 74 + 5.7.2. Replay Protection using Nonces . . . . . . . . 76 + 6. IANA Considerations 76 + 6.1. Mobile IP Message Types . . . . . . . . . . . . . . . . 77 + 6.2. Extensions to RFC 1256 Router Advertisement . . . . . . 77 + 6.3. Extensions to Mobile IP Registration Messages . . . . . 78 + 6.4. Code Values for Mobile IP Registration Reply + Messages. . . . . . . . . . . . . . . . . . . . . . 78 + 7. Acknowledgments 79 + A. Patent Issues 81 + B. Link-Layer Considerations 81 + C. TCP Considerations 82 + C.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . 82 + C.2. TCP Congestion Management . . . . . . . . . . . . . . . 82 + D. Example Scenarios 83 + D.1. Registering with a Foreign Agent Care-of Address . . . 83 + D.2. Registering with a Co-Located Care-of Address . . . . . 83 + D.3. Deregistration . . . . . . . . . . . . . . . . . . . . 84 + E. Applicability of Prefix-Lengths Extension 85 + F. Interoperability Considerations 85 + G. Changes since RFC 2002 86 + G.1. Major Changes . . . . . . . . . . . . . . . . . . . . . 86 + G.2. Minor Changes . . . . . . . . . . . . . . . . . . . . . 88 + G.3. Changes since revision 04 of RFC2002bis . . . . . . . . 90 + H. Example Messages 91 + H.1. Example ICMP Agent Advertisement Message Format . . . . 91 + H.2. Example Registration Request Message Format . . . . . . 92 + H.3. Example Registration Reply Message Format . . . . . . . 93 + References . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 98 + +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: + + + +Perkins Standards Track [Page 3] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + + Changes between this revised specification for Mobile IP and the + original specifications (see [33, 32, 34, 43, 8]) are detailed in the + appendix section G. + +1.1. Protocol Requirements + + A mobile node must be able to communicate with other nodes after + changing its link-layer point of attachment to the Internet, yet + without changing its IP address. + + A mobile node must be able to communicate with other nodes that do + not implement these mobility functions. No protocol enhancements are + required in hosts or routers that are not acting as any of the new + architectural entities introduced in Section 1.5. + + All messages used to update another node as to the location of a + mobile node must be authenticated in order to protect against remote + redirection attacks. + +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. + + + + +Perkins Standards Track [Page 4] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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 + 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. + + + + + +Perkins Standards Track [Page 5] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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). + +1.6. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + + In addition, this document frequently uses the following terms: + + Authorization-enabling extension + + An authentication which makes a (registration) message + acceptable to the ultimate recipient of the registration + message. An authorization-enabling extension MUST contain + an SPI. + + In this document, all uses of authorization-enabling + extension refer to authentication extensions that enable the + Registration Request message to be acceptable to the home + agent. Using additional protocol structures specified + outside of this document, it may be possible for the mobile + node to provide authentication of its registration to the + + + + +Perkins Standards Track [Page 6] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + home agent, by way of another authenticating entity within + the network that is acceptable to the home agent (for + example, see RFC 2794 [6]). + + Agent Advertisement + + An advertisement message constructed by attaching a special + Extension to a router advertisement [10] message. + + Authentication + + The process of verifying (using cryptographic techniques, + for all applications in this specification) the identity of + the originator of a message. + + Care-of Address + + The termination point of a tunnel toward a mobile node, for + datagrams forwarded to the mobile node while it is away from + home. The protocol can use two different types of care-of + address: a "foreign agent care-of address" is an address of + a foreign agent with which the mobile node is registered, + and a "co-located care-of address" is an externally obtained + local address 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. + + Gratuitous ARP + + An ARP packet sent by a node in order to spontaneously cause + other nodes to update an entry in their ARP cache [45]. See + section 4.6. + + Home Address + + An IP address that is assigned for an extended period of + time to a mobile node. It remains unchanged regardless of + where the node is attached to the Internet. + + + + + +Perkins Standards Track [Page 7] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + Home Network + + A network, possibly virtual, having a network prefix + matching that of a mobile node's home address. Note that + standard IP routing mechanisms will deliver datagrams + destined to a mobile node's Home Address to the mobile + node's Home Network. + + Link + + A facility or medium over which nodes can communicate at the + link layer. A link underlies the network layer. + + Link-Layer Address + + The address used to identify an endpoint of some + communication over a physical link. Typically, the Link- + Layer address is an interface's Media Access Control (MAC) + address. + + Mobility Agent + + Either a home agent or a foreign agent. + + Mobility Binding + + The association of a home address with a care-of address, + along with the remaining lifetime of that association. + + Mobility Security Association + + A collection of security contexts, between a pair of nodes, + which may be applied to Mobile IP protocol messages + exchanged between them. Each context indicates an + authentication algorithm and mode (Section 5.1), a secret (a + shared key, or appropriate public/private key pair), and a + style of replay protection in use (Section 5.7). + + Node + + A host or a router. + + Nonce + + A randomly chosen value, different from previous choices, + inserted in a message to protect against replays. + + + + + +Perkins Standards Track [Page 8] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + +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 + + + +Perkins Standards Track [Page 9] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + directly with its home agent, or through a foreign agent + which forwards the registration to the home agent. + + silently discard + + The implementation discards the datagram without further + processing, and without indicating an error to the sender. + The implementation SHOULD provide the capability of logging + the error, including the contents of the discarded datagram, + and SHOULD record the event in a statistics counter. + + The following steps provide a rough outline of operation of the + Mobile IP protocol: + + - 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 [13] (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). + + - 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). + + + +Perkins Standards Track [Page 10] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - In the reverse direction, datagrams sent by the mobile node are + generally delivered to their destination using standard IP + routing mechanisms, not necessarily passing through the home + agent. + + When away from home, Mobile IP uses protocol tunneling to hide a + mobile node's home address from intervening routers between its home + network and its current location. The tunnel terminates at the + mobile node's care-of address. The care-of address must be an + address to which datagrams can be delivered via conventional IP + routing. At the care-of address, the original datagram is removed + from the tunnel and delivered to the mobile node. + + Mobile IP provides two alternative modes for the acquisition of a + care-of address: + + a) A "foreign agent care-of address" is a care-of address provided + by a foreign agent through its Agent Advertisement messages. + In this case, the care-of address is an IP address of the + foreign agent. In this mode, the foreign agent is the endpoint + of the tunnel and, upon receiving tunneled datagrams, + decapsulates them and delivers the inner datagram to the mobile + node. This mode of acquisition is preferred because it allows + many mobile nodes to share the same care-of address and + therefore does not place unnecessary demands on the already + limited IPv4 address space. + + b) A "co-located care-of address" is a care-of address acquired by + the mobile node as a local IP address through some external + means, which the mobile node then associates with one of its + own network interfaces. The address may be dynamically + acquired as a temporary address by the mobile node such as + through DHCP [13], 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. It + does, however, place additional burden on the IPv4 address space + because it requires a pool of addresses within the foreign network to + + + + + +Perkins Standards Track [Page 11] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + + For example, figure 1 illustrates the routing of datagrams to and + from a mobile node away from home, once the mobile node has + registered with its home agent. In figure 1, the mobile node is + using a foreign agent care-of address, not a co-located care-of + address. + + 2) Datagram is intercepted 3) Datagram is + by home agent and detunneled and + is tunneled to the delivered to the + care-of address. mobile node. + + +-----+ +-------+ +------+ + |home | =======> |foreign| ------> |mobile| + |agent| | agent | <------ | node | + +-----+ +-------+ +------+ + 1) Datagram to /|\ / + mobile node | / 4) For datagrams sent by the + arrives on | / mobile node, standard IP + home network | / routing delivers each to its + via standard | |_ destination. In this figure, + IP routing. +----+ the foreign agent is the + |host| mobile node's default router. + +----+ + + Figure 1: Operation of Mobile IPv4 + + 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. + + + +Perkins Standards Track [Page 12] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + +1.8. Message Format and Protocol Extensibility + + Mobile IP defines a set of new control messages, sent with UDP [37] + using well-known port number 434. The following two message types + are defined in this document: + + 1 Registration Request + 3 Registration Reply + + Up-to-date values for the message types for Mobile IP control + messages are specified in the most recent "Assigned Numbers" [40]. + + In addition, for Agent Discovery, Mobile IP makes use of the + existing Router Advertisement and Router Solicitation messages + defined for ICMP Router Discovery [10]. + + Mobile IP defines a general Extension mechanism to allow optional + information to be carried by Mobile IP control messages or by ICMP + Router Discovery messages. Some extensions have been specified to + be encoded in the simple Type-Length-Value format described in + Section 1.9. + + Extensions allow variable amounts of information to be carried + within each datagram. The end of the list of Extensions is + indicated by the total length of the IP datagram. + + + + + + + +Perkins Standards Track [Page 13] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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). In this document, 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 [10]. In this document, + the following Types are defined 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" [40]. + + Due to the separation (orthogonality) of these sets, it is + conceivable that two Extensions that are defined at a later date + could have identical Type values, so long as one of the Extensions + may be used only in Mobile IP control messages and the other may be + used only in ICMP Router Discovery messages. + + The type field in the Mobile IP extension structure can support up to + 255 (skippable and not skippable) uniquely identifiable extensions. + When an Extension numbered in either of these sets within the range 0 + through 127 is encountered but not recognized, the message containing + that Extension MUST be silently discarded. When an Extension + 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. + + Unless additional structure is utilized for the extension types, new + developments or additions to Mobile IP might require so many new + extensions that the available space for extension types might run + out. Two new extension structures are proposed to solve this + problem. Certain types of extensions can be aggregated, using + + + +Perkins Standards Track [Page 14] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + subtypes to identify the precise extension, for example as has been + done with the Generic Authentication Keys extensions [35]. In many + cases, this may reduce the rate of allocation for new values of the + type field. + + Since the new extension structures will cause an efficient usage of + the extension type space, it is recommended that new Mobile IP + extensions follow one of the two new extension formats whenever there + may be the possibility to group related extensions together. + + The following subsections provide details about three distinct + structures for Mobile IP extensions: + + - The simple extension format + - The long extension format + - The short extension format + +1.9. Type-Length-Value Extension Format for Mobile IP Extensions + + The Type-Length-Value format illustrated in figure 2 is used for + extensions which are specified in this document. Since this simple + extension structure does not encourage the most efficient usage of + the extension type space, it is recommended that new Mobile IP + extensions follow one of the two new extension formats specified in + sections 1.10 or 1.11 whenever there may be the possibility to group + related extensions together. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Figure 2: Type-Length-Value extension format for Mobile IPv4 + + 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 15] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +1.10. Long Extension Format + + This format is applicable for non-skippable extensions which carry + information more than 256 bytes. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Sub-Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ..... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Long Extension format requires that the following fields be + specified as the first fields of the extension. + + Type is the type, which describes a collection of extensions + having a common data type. + + Sub-Type is a unique number given to each member in the aggregated + type. + + Length indicates the length (in bytes) of the data field within + this Extension. It does NOT include the Type, Length and + Sub-Type bytes. + + Data is the data associated with the subtype of this + extension. This specification does not place any + additional structure on the subtype data. + + Since the length field is 16 bits wide, a the extension data can + exceed 256 bytes in length. + +1.11. Short Extension Format + + This format is compatible with the skippable extensions defined in + section 1.9. It is not applicable for extensions which require more + than 256 bytes of data; for such extensions, use the format described + in section 1.10. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Sub-Type | Data .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Short Extension format requires that the following fields be + specified as the first fields of the extension: + + + +Perkins Standards Track [Page 16] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + Type is the type, which describes a collection of extensions + having a common data type. + + Sub-Type is a unique number given to each member in the aggregated + type. + + Length 8-bit unsigned integer. Length of the extension, in + bytes, excluding the extension Type and the extension + Length fields. This field MUST be set to 1 plus the + total length of the data field. + + Data is the data associated with this extension. This + specification does not place any additional structure on + the subtype data. + +2. Agent Discovery + + Agent Discovery is the method by which a mobile node determines + whether it is currently connected to its home network or to a foreign + network, and by which a mobile node can detect when it has moved from + one network to another. When connected to a foreign network, the + methods specified in this section also allow the mobile node to + determine the foreign agent care-of address being offered by each + foreign agent on that network. + + Mobile IP extends ICMP Router Discovery [10] 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 [22], 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. + + + + +Perkins Standards Track [Page 17] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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: + + - 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 [10], the IP + destination address of an multicast Agent Advertisement + MUST be either the "all systems on this link" multicast + address (224.0.0.1) [11] or the "limited broadcast" + address (255.255.255.255). The subnet-directed broadcast + address of the form <prefix>.<-1> cannot be used since + mobile nodes will not generally know the prefix of the + foreign network. When the Agent Advertisement is unicast + to a mobile node, the IP home address of the mobile node + SHOULD be used as the Destination Address. + + + + + + + + + + +Perkins Standards Track [Page 18] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - ICMP Fields + + Code The Code field of the agent advertisement is + interpreted as follows: + + 0 The mobility agent handles common traffic -- that + is, it acts as a router for IP datagrams not + necessarily related to mobile nodes. + 16 The mobility agent does not route common traffic. + However, all foreign agents MUST (minimally) + forward to a default router any datagrams received + from a registered mobile node (Section 4.2.2). + + Lifetime + + The maximum length of time that the Advertisement is + considered valid in the absence of further + Advertisements. + + Router Address(es) + + See Section 2.3.1 for a discussion of the addresses that + may appear in this portion of the Agent Advertisement. + + Num Addrs + + The number of Router Addresses advertised in this + message. Note that in an Agent Advertisement message, + the number of router addresses specified in the ICMP + Router Advertisement portion of the message MAY be set to + 0. See Section 2.3.1 for details. + + If sent periodically, the nominal interval at which Agent + Advertisements are sent SHOULD be no longer than 1/3 of the + advertisement Lifetime given in the ICMP header. This interval MAY + be shorter than 1/3 the advertised Lifetime. This allows a mobile + node to miss three successive advertisements before deleting the + agent from its list of valid agents. The actual transmission time + for each advertisement SHOULD be slightly randomized [10] 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. + + + + + + +Perkins Standards Track [Page 19] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +2.1.1. Mobility Agent Advertisement Extension + + The Mobility Agent Advertisement Extension follows the ICMP Router + Advertisement fields. It is used to indicate that an ICMP Router + Advertisement message is also an Agent Advertisement being sent by a + mobility agent. The Mobility Agent Advertisement Extension is + defined as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | zero or more Care-of Addresses | + | ... | + + Type 16 + + Length (6 + 4*N), where 6 accounts for the number of bytes in + the Sequence Number, Registration Lifetime, flags, and + reserved fields, and N is the number of care-of addresses + advertised. + + Sequence Number + + The count of Agent Advertisement messages sent since the + agent was initialized (Section 2.3.2). + + Registration Lifetime + + The longest lifetime (measured in seconds) that this + agent is willing to accept in any Registration Request. + A value of 0xffff indicates infinity. This field has no + relation to the "Lifetime" field within the ICMP Router + Advertisement portion of the Agent Advertisement. + + R Registration required. Registration with this foreign + agent (or another foreign agent on this link) is required + even when using a co-located care-of address. + + B Busy. The foreign agent will not accept registrations + from additional mobile nodes. + + H Home agent. This agent offers service as a home agent on + the link on which this Agent Advertisement message is + sent. + + + +Perkins Standards Track [Page 20] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 [34]. + + G GRE encapsulation. This agent implements receiving + tunneled datagrams that use GRE encapsulation [16]. + + r Sent as zero; ignored on reception. SHOULD NOT be + allocated for any other uses. + + T Foreign agent supports reverse tunneling [27]. + + 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 + agent may indicate that it is "too busy" to allow new mobile nodes to + register with it, by setting the 'B' bit in its Agent Advertisements. + An Agent Advertisement message MUST NOT have the 'B' bit set if the + 'F' bit is not also set. Furthermore, at least one of the 'F' bit + and the 'H' bit MUST be set in any Agent Advertisement message sent. + + When a foreign agent wishes to require registration even from those + mobile nodes 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. + + + + + + + + +Perkins Standards Track [Page 21] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +2.1.2. Prefix-Lengths Extension + + The Prefix-Lengths Extension MAY follow the Mobility Agent + Advertisement Extension. It is used to indicate the number of bits + of network prefix that applies to each Router Address listed in the + ICMP Router Advertisement portion of the Agent Advertisement. Note + that the prefix lengths given DO NOT apply to care-of address(es) + listed in the Mobility Agent Advertisement Extension. The Prefix- + Lengths Extension is defined as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Prefix Length | .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type 19 (Prefix-Lengths Extension) + + Length N, where N is the value (possibly zero) of the Num Addrs + field in the ICMP Router Advertisement portion of the + Agent Advertisement. + + 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. + +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. + + + + +Perkins Standards Track [Page 22] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 MUST process packets that they + receive addressed to the Mobile-Agents multicast group, at address + 224.0.0.11. A mobile node MAY send an Agent Solicitation to + 224.0.0.11. All mobility agents SHOULD respond to Agent + Solicitations. + + The same procedures, defaults, and constants are used in Agent + Advertisement messages and Agent Solicitation messages as specified + for ICMP Router Discovery [10], except that: + + - a mobility agent MUST limit the rate at which it sends broadcast + or multicast Agent Advertisements; the maximum rate SHOULD be + chosen so that the Advertisements do not consume a significant + amount of network bandwidth, AND + + - 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. + + + +Perkins Standards Track [Page 23] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + If the home network is not a virtual network, then the home agent for + any mobile node SHOULD be located on the link identified by the + mobile node's home address, and Agent Advertisement messages sent by + the home agent on this link MUST have the 'H' bit set. In this way, + mobile nodes on their own home network will be able to determine that + they are indeed at home. Any Agent Advertisement messages sent by + the home agent on another link to which it may be attached (if it is + a mobility agent serving more than one link), MUST NOT have the 'H' + bit set, unless the home agent also serves as a home agent (to other + mobile nodes) on that other link. A mobility agent MAY use different + settings for each of the 'R', 'H', and 'F' bits on different network + interfaces. + + If the home network is a virtual network, the home network has no + physical realization external to the home agent itself. In this + case, there is no physical network link on which to send Agent + Advertisement messages advertising the home agent. Mobile nodes for + which this is the home network are always treated as being away from + home. + + On a particular subnet, either all mobility agents MUST include the + Prefix-Lengths Extension or all of them MUST NOT include this + Extension. Equivalently, it is prohibited for some agents on a given + subnet to include the Extension but for others not to include it. + Otherwise, one of the move detection algorithms designed for mobile + nodes will not function properly (Section 2.4.2). + +2.3.1. Advertised Router Addresses + + The ICMP Router Advertisement portion of the Agent Advertisement MAY + contain one or more router addresses. An agent SHOULD only put its + own addresses, if any, in the advertisement. Whether or not its own + address appears in the Router Addresses, a foreign agent MUST route + datagrams it receives from registered mobile nodes (Section 4.2.2). + +2.3.2. Sequence Numbers and Rollover Handling + + The sequence number in Agent Advertisements ranges from 0 to 0xffff. + After booting, an agent MUST use the number 0 for its first + advertisement. Each subsequent advertisement MUST use the sequence + number one greater, with the exception that the sequence number + 0xffff MUST be followed by sequence number 256. In this way, mobile + nodes can distinguish a reduction in the sequence number that occurs + after a reboot from a reduction that results in rollover of the + sequence number after it attains the value 0xffff. + + + + + + +Perkins Standards Track [Page 24] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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 [10], 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 [10]. + + 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. + + + + + + +Perkins Standards Track [Page 25] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + If there is more than one advertised address, the mobile node SHOULD + pick the first address for its initial registration attempt. If the + registration attempt fails with a status Code indicating rejection by + the foreign agent, the mobile node MAY retry the attempt with each + subsequent advertised address in turn. + + When multiple methods of agent discovery are in use, the mobile node + SHOULD first attempt registration with agents including Mobility + Agent Advertisement Extensions in their advertisements, in preference + to those discovered by other means. This preference maximizes the + likelihood that the registration will be recognized, thereby + minimizing the number of registration attempts. + + A mobile node MUST ignore reserved bits in Agent Advertisements, as + opposed to discarding such advertisements. In this way, new bits can + be defined later, without affecting the ability for mobile nodes to + use the advertisements even when the newly defined bits are not + understood. + +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. + + If formerly reserved bits require some kind of monitoring/enforcement + at the foreign link, foreign agents implementing the new + specification for the formerly reserved bits can set the 'R' bit. + This has the effect of forcing the mobile node to register through + the foreign agent, so the foreign agent could then monitor/enforce + the policy. + +2.4.2. Move Detection + + Two primary mechanisms are provided for mobile nodes to detect when + they have moved from one subnet to another. Other mechanisms MAY + also be used. When the mobile node detects that it has moved, it + SHOULD register (Section 3) with a suitable care-of address on the + new foreign network. However, the mobile node MUST NOT register more + frequently than once per second on average, as specified in Section + 3.6.3. + + + + + + + +Perkins Standards Track [Page 26] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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. + +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 + + + + + +Perkins Standards Track [Page 27] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + addition, if the home network is using ARP [36], 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. + + Several other (optional) capabilities are available through the + registration procedure, which enable a mobile node to: + + - discover its home address, if the mobile node is not configured + with this information. + + - 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 + + + + + +Perkins Standards Track [Page 28] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - 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. + + 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. + + + + + +Perkins Standards Track [Page 29] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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) [37]. A nonzero UDP checksum SHOULD be + included in the header, and MUST be checked by the recipient. A zero + UDP checksum SHOULD be accepted by the recipient. The behavior of + the mobile node and the home agent with respect to their mutual + acceptance of packets with zero UDP checksums SHOULD be defined as + part of the mobility security association which exists between them. + +3.2. Authentication + + Each mobile node, foreign agent, and home agent MUST be able to + support a mobility security association for mobile entities, indexed + by their SPI and IP address. In the case of the mobile node, this + must be its Home Address. See Section 5.1 for requirements for + support of authentication algorithms. Registration messages between + a mobile node and its home agent MUST be authenticated with an + authorization-enabling extension, e.g. the Mobile-Home Authentication + Extension (Section 3.5.2). This extension MUST be the first + authentication extension; other foreign agent-specific extensions MAY + be added to the message after the mobile node computes the + authentication. + +3.3. Registration Request + + A mobile node registers with its home agent using a Registration + Request message so that its home agent can create or modify a + mobility binding for that mobile node (e.g., with a new lifetime). + The Request may be relayed to the home agent by the foreign agent + through which the mobile node is registering, or it may be sent + directly to the home agent in the case in which the mobile node is + registering a co-located care-of address. + + IP fields: + + Source Address Typically the interface address from which the + message is sent. + + Destination Address Typically that of the foreign agent or the + home agent. + + + + +Perkins Standards Track [Page 30] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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|r|T|x| Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Agent | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Care-of Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Identification + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extensions ... + +-+-+-+-+-+-+-+- + + Type 1 (Registration Request) + + S Simultaneous bindings. If the 'S' bit is set, + the mobile node is requesting that the home agent retain + its prior mobility bindings, as described in Section + 3.6.1.2. + + B Broadcast datagrams. If the 'B' bit is set, the mobile + node requests that the home agent tunnel to it any + broadcast datagrams that it receives on the home network, + as described in Section 4.3. + + D Decapsulation by mobile node. If the 'D' bit is set, the + mobile node will itself decapsulate datagrams which are + sent to the care-of address. That is, the mobile node is + using a co-located care-of address. + + M Minimal encapsulation. If the 'M' bit is set, the mobile + node requests that its home agent use minimal + encapsulation [34] for datagrams tunneled to the mobile + node. + + + + +Perkins Standards Track [Page 31] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + G GRE encapsulation. If the 'G' bit is set, the mobile + node requests that its home agent use GRE encapsulation + [16] for datagrams tunneled to the mobile node. + + r Sent as zero; ignored on reception. SHOULD NOT be + allocated for any other uses. + + T Reverse Tunneling requested; see [27]. + + x Sent as zero; ignored on reception. + + Lifetime + + The number of seconds remaining before the registration + is considered expired. A value of zero indicates a + request for deregistration. A value of 0xffff indicates + infinity. + + Home Address + + The IP address of the mobile node. + + Home Agent + + The IP address of the mobile node's home agent. + + Care-of Address + + The IP address for the end of the tunnel. + + Identification + + A 64-bit number, constructed by the mobile node, used for + matching Registration Requests with Registration Replies, + and for protecting against replay attacks of registration + messages. See Sections 5.4 and 5.7. + + Extensions + + The fixed portion of the Registration Request is followed + by one or more of the Extensions listed in Section 3.5. + An authorization-enabling extension MUST be included in + all Registration Requests. See Sections 3.6.1.3 and + 3.7.2.2 for information on the relative order in which + different extensions, when present, MUST be placed in a + Registration Request message. + + + + + +Perkins Standards Track [Page 32] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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 an authentication extension which enables authorization by + the home agent. Such an extension contains authentication data 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 33] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + + 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 + + + +Perkins Standards Track [Page 34] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + based on the Identification field from the Registration + Request message from the mobile node, and on the style of + replay protection used in the security context between + the mobile node and its home agent (defined by the + mobility security association between them, and SPI value + in the authorization-enabling extension). See Sections + 5.4 and 5.7. + + Extensions + + The fixed portion of the Registration Reply is followed + by one or more of the Extensions listed in Section 3.5. + An authorization-enabling extension MUST be included in + all Registration Replies returned by the home agent. See + Sections 3.7.2.2 and 3.8.3.3 for rules on placement of + extensions to Reply messages. + + The following values are defined for use within the Code field. + Registration successful: + + 0 registration accepted + 1 registration accepted, but simultaneous mobility + bindings unsupported + + Registration denied by the foreign agent: + + 64 reason unspecified + 65 administratively prohibited + 66 insufficient resources + 67 mobile node failed authentication + 68 home agent failed authentication + 69 requested Lifetime too long + 70 poorly formed Request + 71 poorly formed Reply + 72 requested encapsulation unavailable + 73 reserved and unavailable + 77 invalid care-of address + 78 registration timeout + 80 home network unreachable (ICMP error received) + 81 home agent host unreachable (ICMP error received) + 82 home agent port unreachable (ICMP error received) + 88 home agent unreachable (other ICMP error received) + + + + + + + + + +Perkins Standards Track [Page 35] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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" [40]. + +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, Length, and SPI of this Extension. + + The default authentication algorithm uses HMAC-MD5 [23] to compute a + 128-bit "message digest" of the registration message. The data over + which the HMAC is computed is defined as: + + - the UDP payload (that is, the Registration Request or + Registration Reply data), + + - all prior Extensions in their entirety, and + + - the Type, Length, and SPI of this Extension. + + Note that the Authenticator field itself and the UDP header are NOT + included in the computation of the default Authenticator value. See + Section 5.1 for information about support requirements for message + authentication codes, which are to be used with the various + authentication Extensions. + + + + + + +Perkins Standards Track [Page 36] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 (HMAC-MD5) + specified above. + +3.5.2. Mobile-Home Authentication Extension + + Exactly one authorization-enabling extension MUST be present in all + Registration Requests, and also in all Registration Replies generated + by the Home Agent. The Mobile-Home Authentication Extension is + always an authorization-enabling for registration messages specified + in this document. This requirement 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 37] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 a netmask and a mobility + security association for each of its home agents. In addition, a + mobile node MAY be configured with its home address, and the IP + + + + + +Perkins Standards Track [Page 38] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + + If the mobile node is not configured with a home address, it MAY use + the Mobile Node NAI extension [6] to identify itself, and set the + Home Address field of the Registration Request to 0.0.0.0. In this + case, the mobile node MUST be able to assign its home address after + extracting this information from the Registration Reply from the home + agent. + + For each pending registration, the mobile node maintains the + following information: + + - 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. + + + + + + +Perkins Standards Track [Page 39] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + +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. + + - Otherwise, if the mobile node does not have a home address, the + IP source address MUST be 0.0.0.0. + + - 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. This MAY be an address which + does not appear as an advertised care-of address in the Agent + Advertisement. In addition, when transmitting this + Registration Request message, the mobile node MUST use a link- + + + + +Perkins Standards Track [Page 40] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + + - 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 [38]. + +3.6.1.2. Registration Request Fields + + This section provides specific rules by which mobile nodes pick + values for the fields within the fixed portion of a Registration + Request. + + A mobile node MAY set the 'S' bit in order to request that the home + agent maintain prior mobility binding(s). Otherwise, the home agent + deletes any previous binding(s) and replaces them with the new + binding specified in the Registration Request. Multiple simultaneous + mobility bindings are likely to be useful when a mobile node using at + least one wireless network interface moves within wireless + transmission range of more than one foreign agent. IP explicitly + allows duplication of datagrams. When the home agent allows + simultaneous bindings, it will tunnel a separate copy of each + arriving datagram to each care-of address, and the mobile node will + receive multiple copies of datagrams destined to it. + + The mobile node SHOULD set the 'D' bit if it is registering with a + co-located care-of address. Otherwise, the 'D' bit MUST NOT be set. + + + + +Perkins Standards Track [Page 41] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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: + + - 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. + + + + +Perkins Standards Track [Page 42] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 useful to + the foreign agent), followed by + + c) An authorization-enabling extension, followed by + + d) If present, any non-authentication Extensions used only by the + foreign agent, followed by + + e) The Mobile-Foreign Authentication Extension, if present. + + Note that items (a) and (c) MUST appear in every Registration Request + sent by the mobile node. Items (b), (d), and (e) are optional. + However, item (e) MUST be included when the mobile node and the + foreign agent share a mobility security association. + +3.6.2. Receiving Registration Replies + + Registration Replies will be received by the mobile node in response + to its Registration Requests. Registration Replies generally fall + into three categories: + + - 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 Registration Reply MUST be checked for presence of an + authorization-enabling extension. For all Registration Reply + messages containing a Status Code indicating status from the Home + + + + + +Perkins Standards Track [Page 43] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + Agent, the mobile node MUST check for the presence of an + authorization-enabling extension, acting in accordance with the Code + field in the Reply. The rules are as follows: + + a) If the mobile node and the foreign agent share a mobility + security association, exactly one Mobile-Foreign Authentication + Extension MUST be present in the Registration Reply, and the + mobile node MUST check the Authenticator value in the + Extension. If no Mobile-Foreign Authentication Extension is + found, or if more than one Mobile-Foreign Authentication + Extension is found, or if the Authenticator is invalid, the + mobile node MUST silently discard the Reply and SHOULD log the + event as a security exception. + + b) If the Code field indicates that service is denied by the home + agent, or if the Code field indicates that the registration was + accepted by the home agent, exactly one Mobile-Home + Authentication Extension MUST be present in the Registration + Reply, and the mobile node MUST check the Authenticator value + in the Extension. If the Registration Reply was generated by + the home agent but no Mobile-Home Authentication Extension is + found, or if more than one Mobile-Home Authentication Extension + is found, or if the Authenticator is invalid, the mobile node + MUST silently discard the Reply and SHOULD log the event as a + security exception. + + If the Code field indicates an authentication failure, either at the + foreign agent or the home agent, then it is quite possible that any + authenticators in the Registration Reply will also be in error. This + could happen, for example, if the shared secret between the mobile + node and home agent was erroneously configured. The mobile node + SHOULD log such errors as security exceptions. + +3.6.2.2. Registration Request Accepted + + If the Code field indicates that the request has been accepted, the + mobile node SHOULD configure its routing table appropriately for its + current point of attachment (Section 4.2.1). + + If the mobile node is returning to its home network and that network + is one 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 + + + +Perkins Standards Track [Page 44] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + lifetime of this pending registration, as well as the original + Lifetime from the Registration Request. When the mobile node + receives a valid Registration Reply, the mobile node MUST decrease + its view of the remaining lifetime of the registration by the amount + by which the home agent decreased the originally requested Lifetime. + This procedure is equivalent to the mobile node starting a timer for + the granted Lifetime at the time it sent the Registration Request, + even though the granted Lifetime is not known to the mobile node + until the Registration Reply is received. Since the Registration + Request is certainly sent before the home agent begins timing the + registration Lifetime (also based on the granted Lifetime), this + procedure ensures that the mobile node will re-register before the + home agent expires and deletes the registration, in spite of possibly + non-negligible transmission delays for the original Registration + Request and Reply that started the timing of the Lifetime at the + mobile node and its home agent. + +3.6.2.3. Registration Request Denied + + If the Code field indicates that service is being denied, the mobile + node SHOULD log the error. In certain cases the mobile node may be + able to "repair" the error. These include: + + Code 69: (Denied by foreign agent, 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.7). The mobile node MUST + adjust the parameters it uses to compute the Identification + field based upon the information in the Registration Reply, + before issuing any future Registration Requests. + + 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 + + + +Perkins Standards Track [Page 45] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + the home agent returning the Reply. The mobile node MAY then + attempt to register with this home agent in future Registration + Requests. In addition, the mobile node SHOULD adjust the + parameters it uses to compute the Identification field based + upon the corresponding field in the Registration Reply, before + issuing any future Registration Requests. + +3.6.3. Registration Retransmission + + When no Registration Reply has been received within a reasonable + time, another Registration Request MAY be transmitted. When + timestamps are used, a new registration Identification is chosen for + each retransmission; thus it counts as a new registration. When + nonces are used, the unanswered Request is retransmitted unchanged; + thus the retransmission does not count as a new registration (Section + 5.7). In this way a retransmission will not require the home agent + to resynchronize with the mobile node by issuing another nonce in the + case in which the original Registration Request (rather than its + Registration Reply) was lost by the network. + + The maximum time until a new Registration Request is sent SHOULD be + no greater than the requested Lifetime of the Registration Request. + The minimum value SHOULD be large enough to account for the size of + the messages, twice the round trip time for transmission to the home + agent, and at least an additional 100 milliseconds to allow for + processing the messages before responding. The round trip time for + transmission to the home agent will be at least as large as the time + required to transmit the messages at the link speed of the mobile + node's current point of attachment. Some circuits add another 200 + milliseconds of satellite delay in the total round trip time to the + home agent. The minimum time between Registration Requests MUST NOT + be less than 1 second. Each successive retransmission timeout period + SHOULD be at least twice the previous period, as long as that is less + than the maximum as specified above. + +3.7. Foreign Agent Considerations + + The foreign agent plays a mostly passive role in Mobile IP + registration. It relays Registration Requests between mobile nodes + and home agents, and, when it provides the care-of address, + 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 + + + +Perkins Standards Track [Page 46] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + +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) or its + co-located care-of address (see description of the 'R' bit in + section 2.1.1) + - the IP Destination Address (as specified in 3.6.1.1) + - 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. + + If the mobile node's Home Address is zero in the Registration Request + message, then the foreign agent MUST follow the procedures specified + in RFC 2794 [6]. In particular, if the foreign agent cannot manage + pending registration request records with such a zero Home Address + for the mobile node, the foreign agent MUST return a Registration + Reply with Code indicating NONZERO_HOMEADDR_REQD (see [6]). + + The foreign agent MAY configure a maximum number of pending + registrations that it is willing to maintain (typically 5). + Additional registrations SHOULD then be rejected by the foreign agent + with code 66. The foreign agent MAY delete any pending Registration + Request after the request has been pending for more than 7 seconds; + in this case, the foreign agent SHOULD reject the Request with code + 78 (registration timeout). + + As with any node on the Internet, a foreign agent MAY also share + mobility security associations with any other nodes. When relaying a + Registration Request from a mobile node to its home agent, if the + foreign agent shares a mobility security association with the home + agent, it MUST add a Foreign-Home Authentication Extension to the + + + +Perkins Standards Track [Page 47] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 checks to make sure that the indicated home agent address + does not belong to any network interface of the foreign agent. If + not, the foreign agent then MUST relay the Request to the indicated + home agent. Otherwise, if the foreign agent denies the Request, it + MUST send a Registration Reply to the mobile node with an appropriate + denial Code, except in cases where the foreign agent would be + required to send out more than one such denial per second to the same + mobile node. The following sections describe this behavior in more + detail. + + If the foreign agent has configured one of its network interfaces + with the IP address specified by the mobile node as its home agent + address, the foreign agent MUST NOT forward the request again. If + the foreign agent serves the mobile node as a home agent, the foreign + agent follows the procedures specified in section 3.8.2. Otherwise, + if the foreign agent does not serve the mobile node as a home agent, + the foreign agent rejects the Registration Request with code 136 + (unknown home agent address). + + If a foreign agent receives a Registration Request from a mobile node + in its visitor list, the existing visitor list entry for the mobile + node SHOULD NOT be deleted or modified until the foreign agent + receives a valid Registration Reply from the home agent with a Code + indicating success. The foreign agent MUST record the new pending + Request as a separate part of the existing visitor list entry for the + mobile node. If the Registration Request 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. + + + + + + + +Perkins Standards Track [Page 48] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +3.7.2.1. Validity Checks + + Registration Requests with an invalid, non-zero UDP checksum MUST be + silently discarded. Requests with non-zero bits in reserved fields + MUST be rejected with code 70 (poorly formed request). Requests with + the 'D' bit set to 0, and specifying a care-of address not offered by + the foreign agent, MUST be rejected with code 77 (invalid care-of + address). + + Also, the authentication in the Registration Request MUST be checked. + If the foreign agent and the mobile node share a mobility security + association, exactly one Mobile-Foreign Authentication Extension MUST + be present in the Registration Request, and the foreign agent MUST + check the Authenticator value in the Extension. If no Mobile-Foreign + Authentication Extension is found, or if more than one Mobile-Foreign + Authentication Extension is found, or if the Authenticator is + invalid, the foreign agent MUST silently discard the Request and + SHOULD log the event as a security exception. The foreign agent also + SHOULD send a Registration Reply to the mobile node with Code 67. + +3.7.2.2. Forwarding a Valid Request to the Home Agent + + If the foreign agent accepts the mobile node's Registration Request, + it MUST relay the Request to the mobile node's home agent as + specified in the Home Agent field of the Registration Request. The + foreign agent MUST NOT modify any of the fields beginning with the + fixed portion of the Registration Request up through and including + the Mobile-Home Authentication Extension or other authentication + extension supplied by the mobile node as an authorization-enabling + extension for the home agent. Otherwise, an authentication failure + is very likely to occur at the home agent. In addition, the foreign + agent proceeds as follows: + + - 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. + + Specific fields within the IP header and the UDP header of the + relayed Registration Request MUST be set as follows: + + + + + + + + +Perkins Standards Track [Page 49] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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: + + + + + + + + +Perkins Standards Track [Page 50] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 + used. + + IP Destination Address + + If the Registration Reply is generated by the Foreign + Agent in order to reject a mobile node's Registration + Request, and the Registration Request contains a Home + Address which is not 0.0.0.0, then the IP Destination + Address is copied from the Home Address field of the + Registration Request. Otherwise, if the Registration + Reply is received from the Home Agent, and contains a + Home Address which is not 0.0.0.0, then the IP + Destination Address is copied from the Home Address field + of the Registration Reply. Otherwise, the IP Destination + Address of the Registration Reply is set to be + 255.255.255.255. + + UDP Source Port + + 434 + + UDP Destination Port + + Copied from the UDP Source Port of the Registration + Request. + +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. + + + + + + +Perkins Standards Track [Page 51] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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 such + pending Request is found, and if the Registration Reply does not + correspond with any pending Registration Request with a zero mobile + node home address (see section 3.7.1), the foreign agent MUST + silently discard the Reply. The foreign agent MUST also silently + discard the Reply if the low-order 32 bits of the Identification + field in the Reply do not match those in the Request. + + Also, the authentication in the Registration Reply MUST be checked. + If the foreign agent and the home agent share a mobility security + association, exactly one Foreign-Home Authentication Extension MUST + be present in the Registration Reply, and the foreign agent MUST + check the Authenticator value in the Extension. If no Foreign-Home + Authentication Extension is found, or if more than one Foreign-Home + Authentication Extension is found, or if the Authenticator is + invalid, the foreign agent MUST silently discard the Reply and SHOULD + log the event as a security exception. The foreign agent also MUST + reject the mobile node's registration and SHOULD send a Registration + Reply to the mobile node with Code 68. + +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 home agent has accepted + the registration and the Lifetime field is nonzero, the foreign agent + SHOULD set the Lifetime in the visitor list entry to the minimum of + the following two values: + + - the value specified in the Lifetime field of the Registration + Reply, and + + - the foreign agent's own maximum value for allowable + registration lifetime. + + If, instead, the Code indicates that the Lifetime field is zero, the + foreign agent MUST delete its visitor list entry for the mobile node. + Finally, if the Code indicates that the registration was denied by + + + + +Perkins Standards Track [Page 52] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 + 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. + + + + + + +Perkins Standards Track [Page 53] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + A home agent MUST NOT transmit a Registration Reply except when + replying to a Registration Request received from a mobile node. In + particular, the home agent MUST NOT generate a Registration Reply to + indicate that the Lifetime has expired. + +3.8.1. Configuration and Registration Tables + + Each home agent MUST be configured with an IP address and with the + prefix size for the home network. The home agent MUST be configured + with the mobility security association of each authorized mobile node + that it is serving as a home agent. + + When the home agent accepts a valid Registration Request from a + mobile node that it serves as a home agent, the home agent MUST + create or modify the entry for this mobile node in its mobility + binding list containing: + + - the mobile node's home address + - the mobile node's care-of address + - the Identification field from the Registration Reply + - the remaining Lifetime of the registration + + The home agent MAY optionally offer the capability to dynamically + associate a home address to a mobile node upon receiving a + Registration Request from that mobile node. The method by which a + home address is allocated to the mobile node is beyond the scope of + this document, but see [6]. After the home agent makes the + association of the home address to the mobile node, the home agent + MUST put that home address into the Home Address field of the + Registration Reply. + + The home agent MAY also maintain mobility security associations with + various foreign agents. When receiving a Registration Request from a + foreign agent, if the home agent shares a mobility security + association with the foreign agent, the home agent MUST check the + Authenticator in the required Foreign-Home Authentication Extension + in the message, based on this mobility security association. + 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. + + + + + + + + + +Perkins Standards Track [Page 54] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +3.8.2. Receiving Registration Requests + + 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. If the home agent does not support broadcasts (see section + 4.3), it MUST ignore the 'B' bit (as opposed to rejecting the + Registration Request). + +3.8.2.1. Validity Checks + + Registration Requests with an invalid, non-zero UDP checksum MUST be + silently discarded by the home agent. + + The authentication in the Registration Request MUST be checked. This + involves the following operations: + + a) The home agent MUST check for the presence of an + authorization-enabling extension, and perform the indicated + authentication. Exactly one authorization-enabling extension + MUST be present in the Registration Request; and the home agent + MUST either check the Authenticator value in the extension or + verify that the authenticator value has been checked by another + agent with which it has a security association. If no + authorization-enabling extension is found, or if more than one + authorization-enabling 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 authorization-enabling extension. See Section 5.7 for a + description of how this is performed. If incorrect, the home + agent MUST reject the Request and SHOULD send a Registration + Reply to the mobile node with Code 133, including an + Identification field computed in accordance with the rules + specified in Section 5.7. The home agent MUST do no further + processing with such a Request, though it SHOULD log the error + as a security exception. + + c) If the home agent shares a mobility security association with + the foreign agent, the home agent MUST check for the presence + of a valid Foreign-Home Authentication Extension. Exactly one + + + +Perkins Standards Track [Page 55] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 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. + + Note that some routers change the IP destination address of a + datagram from a subnet-directed broadcast address to 255.255.255.255 + before injecting it into the destination subnet. In this case, home + agents that attempt to pick up dynamic home agent discovery requests + by binding a socket explicitly to the subnet-directed broadcast + address will not see such packets. Home agent implementors should be + prepared for both the subnet-directed broadcast address and + 255.255.255.255 if they wish to support dynamic home agent discovery. + +3.8.2.2. Accepting a Valid Request + + If the Registration Request satisfies the validity checks in Section + 3.8.2.1, and the home agent is able to accommodate the Request, the + home agent MUST update its mobility binding list for the requesting + mobile node and MUST return a Registration Reply to the mobile node. + + In this case, the 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. + + + + +Perkins Standards Track [Page 56] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - 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. + + 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. + + + + + + +Perkins Standards Track [Page 57] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + In addition, if the home network implements ARP [36], 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 + 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. + + Requests with non-zero bits in reserved fields MUST be rejected with + code 134 (poorly formed request). + +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. + + + + + +Perkins Standards Track [Page 58] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +3.8.3.1. IP/UDP Fields + + This section provides the specific rules by which home agents pick + values for the IP and UDP header fields of a Registration Reply. + + IP Source Address + Copied from the IP Destination Address of Registration + Request, unless a multicast or broadcast address was + used. If the IP Destination Address of the Registration + Request was a broadcast or multicast address, the IP + Source Address of the Registration Reply MUST be set to + the home agent's (unicast) IP address. + + IP Destination Address + Copied from the IP Source Address of the Registration + Request. + + UDP Source Port + Copied from the UDP Destination Port of the Registration + Request. + + UDP Destination Port + Copied from the UDP Source Port of the Registration + Request. + + When sending a Registration Reply in response to a Registration + Request that requested deregistration of the mobile node (the + Lifetime is zero and the Care-of Address equals the mobile node's + home address) and in which the IP Source Address was also set to the + mobile node's home address (this is the normal method used by a + mobile node to deregister when it returns to its home network), the + IP Destination Address in the Registration Reply will be set to the + mobile node's home address, as copied from the IP Source Address of + the Request. + + 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. + + + +Perkins Standards Track [Page 59] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +3.8.3.2. Registration Reply Fields + + This section provides the specific rules by which home agents pick + values for the fields within the fixed portion of a Registration + Reply. + + The Code field of the Registration Reply is chosen in accordance with + the rules specified in the previous sections. When replying to an + accepted registration, a home agent SHOULD respond with Code 1 if it + does not support simultaneous registrations. + + The Lifetime field MUST be copied from the corresponding field in the + Registration Request, unless the requested value is greater than the + maximum length of time the home agent is willing to provide the + requested service. In such a case, the Lifetime MUST be set to the + length of time that service will actually be provided by the home + agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed + by the home agent (for this mobile node and care-of address). + + If the Home Address field of the Registration Request is nonzero, it + MUST be copied into the Home Address field of the Registration Reply + message. Otherwise, if the Home Address field of the Registration + Request is zero as specified in section 3.6, the home agent SHOULD + arrange for the selection of a home address for the mobile node, and + insert the selected address into the Home Address field of the + Registration Reply message. See [6] for further relevant details in + the case where mobile nodes identify themselves using an NAI instead + of their IP home address. + + 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, + + + + + +Perkins Standards Track [Page 60] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + +4.1. Encapsulation Types + + Home agents and foreign agents MUST support tunneling datagrams using + IP in IP encapsulation [32]. Any mobile node that uses a co-located + care-of address MUST support receiving datagrams tunneled using IP in + IP encapsulation. Minimal encapsulation [34] and GRE encapsulation + [16] 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 + + + + + +Perkins Standards Track [Page 61] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + network, or when away from home and using a co-located care-of + address, is outside the scope of this document. ICMP Router + Advertisement [10] 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, it MAY use its foreign agent as a first-hop router. + The foreign agent's MAC address can be learned from Agent + Advertisement. Otherwise, the mobile node MUST choose its + default router from among the Router Addresses advertised in + the ICMP Router Advertisement portion of that Agent + Advertisement message. + + - If the mobile node is registered directly with its home agent + using a co-located care-of address, then the mobile node SHOULD + choose its default router from among those advertised in any + ICMP Router Advertisement message that it receives for which + its externally obtained care-of address and the Router Address + match under the network prefix. If the mobile node's + externally obtained care-of address matches the IP source + address of the Agent Advertisement under the network prefix, + the mobile node MAY also consider that IP source address as + another possible choice for the IP address of a default router. + The network prefix MAY be obtained from the Prefix-Lengths + Extension in the Router Advertisement, if present. The prefix + MAY also be obtained through other mechanisms beyond the scope + of this document. + + While they are away from the home network, mobile nodes MUST NOT + broadcast ARP packets to find the MAC address of another Internet + node. Thus, the (possibly empty) list of Router Addresses from the + ICMP Router Advertisement portion of the message is not useful for + selecting a default router, unless the mobile node has some means not + involving broadcast ARP and not specified within this document for + obtaining the MAC address of one of the routers in the list. + Similarly, in the absence of unspecified mechanisms for obtaining MAC + addresses on foreign networks, the mobile node MUST ignore redirects + to other routers on foreign networks. + +4.2.2. Foreign Agent Considerations + + Upon receipt of an encapsulated datagram sent to its advertised + care-of address, a foreign agent MUST compare the inner destination + address to those entries in its visitor list. When the destination + does not match the address of any mobile node currently in the + visitor list, the foreign agent MUST NOT forward the datagram without + + + +Perkins Standards Track [Page 62] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + modifications to the original IP header, because otherwise a routing + loop is likely to result. The datagram SHOULD be silently discarded. + ICMP Destination Unreachable MUST NOT be sent when a foreign agent is + unable to forward an incoming tunneled datagram. Otherwise, the + foreign agent forwards the decapsulated datagram to the mobile node. + + The foreign agent MUST NOT advertise to other routers in its routing + domain, nor to any other mobile node, the presence of a mobile router + (Section 4.5) or mobile node in its visitor list. + + The foreign agent MUST route datagrams it receives from registered + mobile nodes. At a minimum, this means that the foreign agent must + verify the IP Header Checksum, decrement the IP Time To Live, + recompute the IP Header Checksum, and forward such datagrams to a + default router. + + A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC + address on a foreign network. It may obtain the MAC address by + copying the information from an Agent Solicitation or a Registration + Request transmitted from a mobile node. A foreign agent's ARP cache + for the mobile node's IP address MUST NOT be allowed to expire before + the mobile node's visitor list entry expires, unless the foreign + agent has some way other than broadcast ARP to refresh its MAC + address associated with the mobile node's IP address. + + Each foreign agent SHOULD support the mandatory features for reverse + tunneling [27]. + +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 + + + + +Perkins Standards Track [Page 63] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + home network. In this case, the home agent MUST assume the mobile + node is at home and simply forward the datagram directly onto the + home network. + + For multihomed home agents, the source address in the outer IP header + of the encapsulated datagram MUST be the address sent to the mobile + node in the home agent field of the registration reply. That is, the + home agent cannot use the the address of some other network interface + as the source address. + + See Section 4.1 regarding methods of encapsulation that may be used + for tunneling. Nodes implementing tunneling SHOULD also implement + the "tunnel soft state" mechanism [32], which allows ICMP error + messages returned from the tunnel to correctly be reflected back to + the original senders of the tunneled datagrams. + + Home agents MUST decapsulate packets addressed to themselves, sent by + a mobile node for the purpose of maintaining location privacy, as + described in Section 5.5. This feature is also required for support + of reverse tunneling [27]. + + 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 + 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 + + + +Perkins Standards Track [Page 64] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 (nested encapsulation), with the new outer + Destination Address set equal to the mobile node's care-of + address. That is, the home agent forwards the entire datagram + to the mobile node in the same way as any other datagram + (encapsulated already or not). + +4.3. Broadcast Datagrams + + When a home agent receives a broadcast datagram, it MUST NOT forward + the datagram to any mobile nodes in its mobility binding list other + than those that have requested forwarding of broadcast datagrams. A + mobile node MAY request forwarding of broadcast datagrams by setting + the 'B' bit in its Registration Request message (Section 3.3). For + each such registered mobile node, the home agent SHOULD forward + received broadcast datagrams to the mobile node, although it is a + matter of configuration at the home agent as to which specific + categories of broadcast datagrams will be forwarded to such mobile + nodes. + + If the 'D' bit was set in the mobile node's Registration Request + message, indicating that the mobile node is using a co-located care- + of address, the home agent simply tunnels appropriate broadcast IP + datagrams to the mobile node's care-of address. Otherwise (the 'D' + bit was NOT set), the home agent first encapsulates the broadcast + datagram in a unicast datagram addressed to the mobile node's home + address, and then tunnels this encapsulated datagram to the foreign + agent. This extra level of encapsulation is required so that the + foreign agent can determine which mobile node should receive the + datagram after it is decapsulated. When received by the foreign + agent, the unicast encapsulated datagram is detunneled and delivered + to the mobile node in the same way as any other datagram. In either + case, the mobile node must decapsulate the datagram it receives in + order to recover the original broadcast datagram. + +4.4. Multicast Datagram Routing + + As mentioned previously, a mobile node that is connected to its home + network functions in the same way as any other (fixed) host or + router. Thus, when it is at home, a mobile node functions + identically to other multicast senders and receivers. This section + therefore describes the behavior of a mobile node that is visiting a + foreign network. + + + +Perkins Standards Track [Page 65] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + In order to receive multicasts, a mobile node MUST join the multicast + group in one of two ways. First, a mobile node MAY join the group + via a (local) multicast router on the visited subnet. This option + assumes that there is a multicast router present on the visited + subnet. If the mobile node is using a co-located care-of address, it + SHOULD use this address as the source IP address of its IGMP [11] + messages. Otherwise, it MAY 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. For packets tunneled + to the home agent, the source address in the IP header SHOULD be the + mobile node's home address. + + The rules for multicast datagram delivery to mobile nodes in this + case are identical to those for broadcast datagrams (Section 4.3). + Namely, if the mobile node is using a co-located care-of address (the + 'D' bit was set in the mobile node's Registration Request), then the + home agent SHOULD tunnel the datagram to this care-of address; + otherwise, the home agent MUST first encapsulate the datagram in a + unicast datagram addressed to the mobile node's home address and then + MUST tunnel the resulting datagram (nested tunneling) to the mobile + node's care-of address. For this reason, the mobile node MUST be + capable of decapsulating packets sent to its home address in order to + receive multicast datagrams using this method. + + 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. + +4.5. Mobile Routers + + A mobile node can be a router that is responsible for the mobility of + one or more entire networks moving together, perhaps on an airplane, + a ship, a train, an automobile, a bicycle, or a kayak. The nodes + connected to a network served by the mobile router may themselves be + fixed nodes or mobile nodes or routers. In this document, such + networks are called "mobile networks". + + + + +Perkins Standards Track [Page 66] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + + 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. + + + + + +Perkins Standards Track [Page 67] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 + nested 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 nested tunneling of datagrams. + +4.6. ARP, Proxy ARP, and Gratuitous ARP + + The use of ARP [36] requires special rules for correct operation when + wireless or mobile nodes are involved. The requirements specified in + this section apply to all home networks in which ARP is used for + address resolution. + + In addition to the normal use of ARP for resolving a target node's + link-layer address from its IP address, this document distinguishes + two special uses of ARP: + + - A Proxy ARP [39] 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 [36], + 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. + + + +Perkins Standards Track [Page 68] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - A Gratuitous ARP [45] is an ARP packet sent by a node in order + to spontaneously cause other nodes to update an entry in their + ARP cache. A gratuitous ARP MAY use either an ARP Request or + an ARP Reply packet. In either case, the ARP Sender Protocol + Address and ARP Target Protocol Address are both set to the IP + address of the cache entry to be updated, and the ARP Sender + Hardware Address is set to the link-layer address to which this + cache entry should be updated. When using an ARP Reply packet, + the Target Hardware Address is also set to the link-layer + address to which this cache entry should be updated (this field + is not used in an ARP Request packet). + + In either case, for a gratuitous ARP, the ARP packet MUST be + transmitted as a local broadcast packet on the local link. As + specified in [36], 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 [36]. + + While a mobile node is registered on a foreign network, its home + agent uses proxy ARP [39] 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 [39], the + home agent MUST set the sender link-layer address in the packet to + the link-layer address of its own interface over which the Reply will + be sent. + + When a mobile node leaves its home network and registers a binding on + a foreign network, its home agent uses gratuitous ARP to update the + ARP caches of nodes on the home network. This causes such nodes to + associate the link-layer address of the home agent with the mobile + node's home (IP) address. When registering a binding for a mobile + node for which the home agent previously had no binding (the mobile + node was assumed to be at home), the home agent MUST transmit a + gratuitous ARP on behalf of the mobile node. This gratuitous ARP + packet MUST be transmitted as a broadcast packet on the link on which + the mobile node's home address is located. Since broadcasts on the + local link (such as Ethernet) are typically not guaranteed to be + reliable, the gratuitous ARP packet SHOULD be retransmitted a small + number of times to increase its reliability. + + + + +Perkins Standards Track [Page 69] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 home agent. The ARP packet from the home agent MUST be + transmitted as a local broadcast on the mobile node's home link, and + SHOULD be retransmitted a small number of times to increase its + reliability; these retransmissions, however, SHOULD proceed in + parallel with the transmission and processing of 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 unicast by a foreign agent with which the mobile node is + attempting to register or a foreign agent with which the mobile node + has an unexpired registration. In the latter case, the mobile node + MUST use a unicast ARP Reply to respond to the foreign agent. Note + that if the mobile node is using a co-located care-of address and + receives an ARP Request in which the target IP address is this care- + of address, then the mobile node SHOULD reply to this ARP Request. + Note also that, when transmitting a Registration Request on a foreign + network, a mobile node may discover the link-layer address of a + foreign agent by storing the address as it is received from the Agent + Advertisement from that foreign agent, but not by transmitting a + broadcast ARP Request message. + + + + + + + + +Perkins Standards Track [Page 70] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. In the gratuitous ARP, the ARP Sender Hardware + Address is set to the link-layer address of the home agent. + If, instead, the home agent rejects the Registration Request, + no ARP processing (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. + + - 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. In this + gratuitous ARP, the ARP Sender Hardware Address is set to the + link-layer address of the mobile node. + + - The mobile node transmits its Registration Request. + + + + +Perkins Standards Track [Page 71] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - When the mobile node's home agent receives and accepts the + Registration Request, it stops using proxy ARP to reply to ARP + Requests that it receives requesting the mobile node's link- + layer address, and then performs a gratuitous ARP on behalf of + the mobile node. In this gratuitous ARP, the ARP Sender + Hardware Address is set to the link-layer address of the mobile + node. If, instead, the home agent rejects the Registration + Request, the home agent MUST NOT make any change to the way it + performs ARP processing (gratuitous nor proxy) for the mobile + node. In this latter case, the home agent should operate as if + the mobile node has not returned home, and continue to perform + proxy ARP on behalf of the mobile node. + +5. Security Considerations + + The mobile computing environment is potentially very different from + the ordinary computing environment. In many cases, mobile computers + will be connected to the network via wireless links. Such links are + particularly vulnerable to passive eavesdropping, active replay + attacks, and other active attacks. + +5.1. Message Authentication Codes + + Home agents and mobile nodes MUST be able to perform authentication. + The default algorithm is HMAC-MD5 [23], with a key size of 128 bits. + The foreign agent MUST also support authentication using HMAC-MD5 and + key sizes of 128 bits or greater, with manual key distribution. Keys + with arbitrary binary values MUST be supported. + + The "prefix+suffix" use of MD5 to protect data and a shared secret is + considered vulnerable to attack by the cryptographic community. + Where backward compatibility with existing Mobile IP implementations + that use this mode is needed, new implementations SHOULD include + keyed MD5 [41] as one of the additional authentication algorithms for + use when producing and verifying the authentication data that is + supplied with Mobile IP registration messages, for instance in the + extensions specified in sections 3.5.2, 3.5.3, and 3.5.4. + + More authentication algorithms, algorithm modes, key distribution + methods, and key sizes MAY also be supported for all of these + extensions. + +5.2. Areas of Security Concern in this Protocol + + The registration protocol described in this document will result in a + mobile node's traffic being tunneled to its care-of address. This + tunneling feature could be a significant vulnerability if the + registration were not authenticated. Such remote redirection, for + + + +Perkins Standards Track [Page 72] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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. + +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. [14] 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 73] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +5.6. Ingress Filtering + + Many routers implement security policies such as "ingress filtering" + [15] that do not allow forwarding of packets that have a Source + Address which appears topologically incorrect. In environments where + this is a problem, mobile nodes may use reverse tunneling [27] with + the foreign agent supplied care-of address as the Source Address. + Reverse tunneled packets will be able to pass normally through such + routers, while ingress filtering rules will still be able to locate + the true topological source of the packet in the same way as packets + from non-mobile nodes. + +5.7. Replay Protection for Registration Requests + + The Identification field is used to let the home agent verify that a + registration message has been freshly generated by the mobile node, + not replayed by an attacker from some previous registration. Two + methods are described in this section: timestamps (mandatory) and + "nonces" (optional). All mobile nodes and home agents MUST implement + timestamp-based replay protection. These nodes MAY also implement + nonce-based replay protection (but see Appendix A). + + 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. + 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.7.1. Replay Protection using Timestamps + + The basic principle of timestamp replay protection is that the node + generating a message inserts the current time of day, and the node + receiving the message checks that this timestamp is sufficiently + close to its own time of day. Unless specified differently in the + security association between the nodes, a default value of 7 seconds + + + +Perkins Standards Track [Page 74] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + MAY be used to limit the time difference. This value SHOULD be + greater than 3 seconds. Obviously the two nodes must have adequately + synchronized time-of-day clocks. As with any messages, time + synchronization messages may be protected against tampering by an + authentication mechanism determined by the security context between + the two nodes. + + If timestamps are used, the mobile node MUST set the Identification + field to a 64-bit value formatted as specified by the Network Time + Protocol [26]. 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 + 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 an authorization-enabling + extension, the home agent MUST check the Identification field for + validity. In order to be valid, the timestamp contained in the + Identification field MUST be close enough to the home agent's time of + day clock and the timestamp MUST be greater than all previously + accepted timestamps for the requesting mobile node. Time tolerances + and resynchronization details are specific to a particular mobility + security association. + + 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. + + + + + + + + +Perkins Standards Track [Page 75] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +5.7.2. Replay Protection using Nonces + + The basic principle of nonce replay protection is that node A + includes a new random number in every message to node B, and checks + that node B returns that same number in its next message to node A. + Both messages use an authentication code to protect against + alteration by an attacker. At the same time node B can send its own + nonces in all messages to node A (to be echoed by node A), so that it + too can verify that it is receiving fresh messages. + + The home agent may be expected to have resources for computing + pseudo-random numbers useful as nonces [14]. It inserts a new nonce + as the high-order 32 bits of the identification field of every + Registration Reply. The home agent copies the low-order 32 bits of + the Identification 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. + +6. IANA Considerations + + Mobile IP specifies several new number spaces for values to be used + in various message fields. These number spaces include the + following: + + - Mobile IP message types sent to UDP port 434, as defined in + section 1.8. + + + +Perkins Standards Track [Page 76] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - types of extensions to Registration Request and Registration + Reply messages (see sections 3.3 and 3.4, and also consult [27, + 29, 6, 7, 12]) + + - values for the Code in the Registration Reply message (see + section 3.4, and also consult [27, 29, 6, 7, 12]) + + - Mobile IP defines so-called Agent Solicitation and Agent + Advertisement messages. These messages are in fact Router + Discovery messages [10] augmented with mobile-IP specific + extensions. Thus, they do not define a new name space, but do + define additional Router Discovery extensions as described + below in Section 6.2. Also see Section 2.1 and consult [7, + 12]. + + There are additional Mobile IP numbering spaces specified in [7]. + + Information about assignment of mobile-ip numbers derived from + specifications external to this document is given by IANA at + http://www.iana.org/numbers.html. From that URL, follow the + hyperlinks to [M] within the "Directory of General Assigned Numbers", + and subsequently to the specific section for "Mobile IP Numbers". + +6.1. Mobile IP Message Types + + Mobile IP messages are defined to be those that are sent to a message + recipient at port 434 (UDP or TCP). The number space for Mobile IP + messages is specified in Section 1.8. Approval of new extension + numbers is subject to Expert Review, and a specification is required + [30]. The currently standardized message types have the following + numbers, and are specified in the indicated sections. + + Type Name Section + ---- -------------------------------------------- --------- + 1 Registration Request 3.3 + 3 Registration Reply 3.4 + +6.2. Extensions to RFC 1256 Router Advertisement + + RFC 1256 defines two ICMP message types, Router Advertisement and + Router Solicitation. Mobile IP defines a number space for extensions + to Router Advertisement, which could be used by protocols other than + Mobile IP. The extension types currently standardized for use with + Mobile IP have the following numbers. + + + + + + + +Perkins Standards Track [Page 77] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + Type Name Reference + ---- -------------------------------------------- --------- + 0 One-byte Padding 2.1.3 + 16 Mobility Agent Advertisement 2.1.1 + 19 Prefix-Lengths 2.1.2 + + Approval of new extension numbers for use with Mobile IP is subject + to Expert Review, and a specification is required [30]. + +6.3. Extensions to Mobile IP Registration Messages + + The Mobile IP messages, specified within this document, and listed in + sections 1.8 and 6.1, may have extensions. Mobile IP message + extensions all share the same number space, even if they are to be + applied to different Mobile IP messages. The number space for Mobile + IP message extensions is specified within this document. Approval of + new extension numbers is subject to Expert Review, and a + specification is required [30]. + + Type Name Reference + ---- -------------------------------------------- --------- + 0 One-byte Padding + 32 Mobile-Home Authentication 3.5.2 + 33 Mobile-Foreign Authentication 3.5.3 + 34 Foreign-Home Authentication 3.5.4 + +6.4. Code Values for Mobile IP Registration Reply Messages + + The Mobile IP Registration Reply message, specified in section 3.4, + has a Code field. The number space for the Code field values is also + specified in Section 3.4. The Code number space is structured + according to whether the registration was successful, or whether the + foreign agent denied the registration request, or lastly whether the + home agent denied the registration request, as follows: + + 0-8 Success Codes + 9-63 No allocation guidelines currently exist + 64-127 Error Codes from the Foreign Agent + 128-192 Error Codes from the Home Agent + 193-255 No allocation guidelines currently exist + + Approval of new Code values requires Expert Review [30]. + + + + + + + + + +Perkins Standards Track [Page 78] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +7. Acknowledgments + + Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp + and John Ioannidis (JI) (Columbia University), for forming the + working group, chairing it, and putting so much effort into its early + development. Columbia's early Mobile IP work can be found in [18, + 19, 17]. + + Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, + Erik Nordmark, Basavaraj Patil, and Phil Roberts for their + contributions to the group while performing the duties of + chairperson, as well as for their many useful comments. + + Thanks to the active members of the Mobile IP Working Group, + particularly those who contributed text, including (in alphabetical + order) + + - Ran Atkinson (Naval Research Lab), + - Samita Chakrabarti (Sun Microsystems) + - Ken Imboden (Candlestick Networks, Inc.) + - Dave Johnson (Carnegie Mellon University), + - Frank Kastenholz (FTP Software), + - Anders Klemets (KTH), + - Chip Maguire (KTH), + - Alison Mankin (ISI) + - Andrew Myles (Macquarie University), + - Thomas Narten (IBM) + - Al Quirt (Bell Northern Research), + - Yakov Rekhter (IBM), and + - Fumio Teraoka (Sony). + - Alper Yegin (NTT DoCoMo) + + 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 in the later + revisions preceding RFC 2002 is due to Jim Solomon and Dave Johnson. + + Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank + Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for + their generous support in hosting interim Working Group meetings. + + Sections 1.10 and 1.11, which specify new extension formats to be + used with aggregatable extension types, were included from a + specification document (entitled "Mobile IP Extensions + Rationalization (MIER)", which was written by + + + + + + +Perkins Standards Track [Page 79] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - Mohamed M.Khalil, Nortel Networks + - Raja Narayanan, nVisible Networks + - Haseeb Akhtar, Nortel Networks + - Emad Qaddoura, Nortel Networks + + Thanks to these authors, and also for the additional work on + MIER, which was contributed by Basavaraj Patil, Pat Calhoun, Neil + Justusson, N. Asokan, and Jouni Malinen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 80] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +A. Patent Issues + + The IETF has been notified of intellectual property rights claimed + in regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on + the IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances + of licenses to be made available, or the result of an attempt + made to obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +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 [24], 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) [42] and its Internet Protocol + Control Protocol (IPCP) [25], 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. + + + + + +Perkins Standards Track [Page 81] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + PPP extensions for Mobile IP have been specified in RFC 2290 [44]. + Please consult that document for additional details for how to handle + care-of address assignment from PPP in a more efficient manner. + +C. TCP Considerations + +C.1. TCP Timers + + When high-delay (e.g. SATCOM) or low-bandwidth (e.g. High-Frequency + Radio) links are in use, some TCP stacks may have insufficiently + adaptive (non-standard) retransmission timeouts. There may be + spurious retransmission timeouts, even when the link and network + are actually operating properly, but just with a high delay because + of the medium in use. This can cause an inability to create or + maintain TCP connections over such links, and can also cause unneeded + retransmissions which consume already scarce bandwidth. Vendors + are encouraged to follow the algorithms in RFC 2988 [31] when + implementing TCP retransmission timers. Vendors of systems designed + for low-bandwidth, high-delay links should consult RFCs 2757 and + 2488 [28, 1]. Designers of applications targeted to operate on + 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 [21]. Now, when a packet is dropped, + the correspondent node's TCP implementation is likely to react as + if there were a source of network congestion, and initiate the + slow-start mechanisms [21] 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. [5]. TCP approaches to the problem + of handling errors that might interfere with congestion management + are discussed in documents from the [pilc] working group [3, 9]. + While such approaches are beyond the scope of this document, + they illustrate that providing performance transparency to mobile + nodes involves understanding mechanisms outside the network layer. + Problems introduced by higher media error rates also indicate the + need to avoid designs which systematically drop packets; such designs + might otherwise be considered favorably when making engineering + tradeoffs. + + + + + + +Perkins Standards Track [Page 82] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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: + An authorization-enabling extension (e.g., the + Mobile-Home Authentication Extension) + +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 [13] + 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: + + + + + + +Perkins Standards Track [Page 83] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + 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 + +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: + An authorization-enabling extension (e.g., the + Mobile-Home Authentication Extension) + + + + + + + + + +Perkins Standards Track [Page 84] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +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. + + 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". + +F. Interoperability Considerations + + This document specifies revisions to RFC 2002 that are intended to + improve interoperability by resolving ambiguities contained in the + earlier text. Implementations that perform authentication according + to the new more precisely specified algorithm would be interoperable + with earlier implementations that did what was originally expected + for producing authentication data. That was a major source of non- + interoperability before. + + However, this specification does have new features that, if used, + would cause interoperability problems with older implementations. + All features specified in RFC 2002 will work with the new + implementations, except for V-J compression [20]. The following list + details some of the possible areas of compatibility problems that may + be experienced by nodes conforming to this revised specification, + when attempting to interoperate with nodes obeying RFC 2002. + + - A client that expects some of the newly mandatory features + (like reverse tunneling) from a foreign agent would still be + interoperable as long as it pays attention to the `T' bit. + + + +Perkins Standards Track [Page 85] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - Mobile nodes that use the NAI extension to identify themselves + would not work with old mobility agents. + + - Mobile nodes that use a zero home address and expect to receive + their home address in the Registration Reply would not work + with old mobility agents. + + - Mobile nodes that attempt to authenticate themselves without + using the Mobile-Home authentication extension will be unable + to successful register with their home agent. + + In all of these cases, a robust and well-configured mobile node is + very likely to be able to recover if it takes reasonable actions upon + receipt of a Registration Reply with an error code indicating the + cause for rejection. For instance, if a mobile node sends a + registration request that is rejected because it contains the wrong + kind of authentication extension, then the mobile node could retry + the registration with a mobile-home authentication extension, since + the foreign agent and/or home agent in this case will not be + configured to demand the alternative authentication data. + +G. Changes since RFC 2002 + + This section details differences between the original Mobile IP base + specification (RFC 2002 and ff.) that have been made as part of this + revised protocol specification for Mobile IP. + +G.1. Major Changes + + - Specification for Destination IP address of Registration Reply + transmitted from Foreign Agent, to avoid any possible + transmission to IP address 0.0.0.0. + + - Specification of two new formats for Mobile IP extensions, + according to the ideas contained in MIER. + + - Specification that the SPI of the MN-HA authentication + extension is to be used as part of the data over which the + authentication algorithm must be computed. + + - Eliminated Van-Jacobson Compression feature + + - Specification that foreign agents MAY send advertisements at a + rate faster than once per second, but chosen so that the + advertisements do not burden the capacity of the local link. + For simplicity, the foreign agent now MAY send advertisements + at an interval less than 1/3 the advertised ICMP Lifetime. + + + + +Perkins Standards Track [Page 86] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - Specification that foreign agents SHOULD support reverse + tunneling, and home agents MUST support decapsulation of + reverse tunnels. + + - Changed the preconfiguration requirements in section 3.6 for + the mobile node to reflect the capability, specified in RFC + 2794 [6], for the mobile node to identify itself by using its + NAI, and then getting a home address from the Registration + Reply. + + - Changed section 3.7.3.1 so that a foreign agent is not required + to discard Registration Replies that have a Home Address field + that does not match any pending Registration Request. + + - Allowed registrations to be authenticated by use of a security + association between the mobile node and a suitable + authentication entity acceptable to the home agent. Defined + "Authorization-enabling Extension" to be an authentication + extension that makes a registration message acceptable to the + recipient. This is needed according to specification in [6]. + + - Mandated that HMAC-MD5 be used instead of the "prefix+suffix" + mode of MD5 as originally mandated in RFC 2002. + + - Specified that the mobile node SHOULD take the first care-of + address in a list offered by a foreign agent, and MAY try each + subsequent advertised address in turn if the attempted + registrations are rejected by the foreign agent + + - Clarification that a mobility agent SHOULD only put its own + addresses into the initial (i.e., not mobility-related) list of + routers in the mobility advertisement. RFC 2002 suggests that + a mobility agent might advertise other default routers. + + - Specification that a mobile node MUST ignore reserved bits in + Agent Advertisements, as opposed to discarding such + advertisements. In this way, new bits can be defined later, + without affecting the ability for mobile nodes to use the + advertisements even when the newly defined bits are not + understood. Furthermore, foreign agents can set the `R' bit to + make sure that new bits are handled by themselves instead of + some legacy mobility agent. + + - Specification that the foreign agent checks to make sure that + the indicated home agent address does not belong to any of its + network interfaces before relaying a Registration Request. If + + + + + +Perkins Standards Track [Page 87] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + the check fails, and the foreign agent is not the mobile node's + home agent, then the foreign agent rejects the request with + code 136 (unknown home agent address). + + - Specification that, while they are away from the home network, + mobile nodes MUST NOT broadcast ARP packets to find the MAC + address of another Internet node. Thus, the (possibly empty) + list of Router Addresses from the ICMP Router Advertisement + portion of the message is not useful for selecting a default + router, unless the mobile node has some means not involving + broadcast ARP and not specified within this document for + obtaining the MAC address of one of the routers in the list. + Similarly, in the absence of unspecified mechanisms for + obtaining MAC addresses on foreign networks, the mobile node + MUST ignore redirects to other routers on foreign networks. + + - Specification that a foreign agent MUST NOT use broadcast ARP + for a mobile node's MAC address on a foreign network. It may + obtain the MAC address by copying the information from an Agent + Solicitation or a Registration Request transmitted from a + mobile node. + + - Specification that a foreign agent's ARP cache for the mobile + node's IP address MUST NOT be allowed to expire before the + mobile node's visitor list entry expires, unless the foreign + agent has some way other than broadcast ARP to refresh its MAC + address associated to the mobile node's IP address. + + - At the end of section 4.6, clarified that a home agent MUST NOT + make any changes to the way it performs proxy ARP after it + rejects an invalid deregistration request. + + - In section 4.2.3, specification that multihomed home agents + MUST use the the address sent to the mobile node in the home + agent field of the registration reply as the source address in + the outer IP header of the encapsulated datagram. + + - Inserted 'T' bit into its proper place in the Registration + Request message format (section 3.3). + +G.2. Minor Changes + + - Allowed registration replies to be processed by the mobile + node, even in the absence of any Mobile-Home Authentication + extension, when containing rejection code by the foreign agent. + + + + + + +Perkins Standards Track [Page 88] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - Specification that the foreign agent MAY configure a maximum + number of pending registrations that it is willing to maintain + (typically 5). Additional registrations SHOULD then be + rejected by the foreign agent with code 66. The foreign agent + MAY delete any pending Registration Request after the request + has been pending for more than 7 seconds; in this case, the + foreign agent SHOULD reject the Request with code 78 + (registration timeout). + + - Relaxation of the requirement that, when a mobile node has + joined a multicast group at the router on the foreign network, + the mobile node MUST use its home address as the source IP + address for multicast packets, + + - Clarification that a mobility agent MAY use different settings + for each of the 'R', 'H', and 'F' bits on different network + interfaces. + + - Replacement of the terminology "recursive tunneling" by the + terminology "nested tunneling". + + - Specification that the mobile node MAY use the IP source + address of an agent advertisement as its default router + address. + + - Clarification that keys with arbitrary binary values MUST be + supported as part of mobility security associations. + + - Specification that the default value may be chosen as 7 + seconds, for allowable time skews between a home agent and + mobile node using timestamps for replay protection. Further + specification that this value SHOULD be greater than 3 seconds. + + - Specification that Registration Requests with the 'D' bit set + to 0, and specifying a care-of address not offered by the + foreign agent, MUST be rejected with code 77 (invalid care-of + address). + + - Clarification that the foreign agent SHOULD consider its own + maximum value when handling the Lifetime field of the + Registration Reply. + + - Clarification that the home agent MUST ignore the 'B' bit (as + opposed to rejecting the Registration Request) if it does not + support broadcasts. + + + + + + +Perkins Standards Track [Page 89] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + - Advice about the impossibility of using dynamic home agent + discovery in the case when routers change the IP destination + address of a datagram from a subnet-directed broadcast address + to 255.255.255.255 before injecting it into the destination + subnet. + + - Clarified that when an Agent Advertisement is unicast to a + mobile node, the specific IP home address of a mobile node MAY + be used as the destination IP address. + + - Included a reference to RFC 2290 within appendix B, which deals + with PPP operation. + + - Created IANA Considerations section + + - In section 3.8.3, clarified that a home agent SHOULD arrange + the selection of a home address for a mobile node when the + Registration Reply contains a zero Home Address. + +G.3. Changes since revision 04 of RFC2002bis + + This section lists the changes between this version (...-06.txt) and + the previous version (...-04.txt) of the document. This section can + be deleted by the RFC editor. + + - Noted that HMAC-MD5 should be considered for use in place of + the "prefix+suffix" mode of MD5 as originally mandated in RFC + 2002. + + - Included a reference to RFC 2290 within appendix B, which deals + with PPP operation. + + - Revamped IANA Considerations section + + - Revamped Changes section + + - Replaced Patents section with wording mandated from RFC 2026. + + - Updated citations. + + + + + + + + + + + + +Perkins Standards Track [Page 90] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +H. Example Messages + +H.1. Example ICMP Agent Advertisement Message Format + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Num Addrs |Addr Entry Size| Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router Address[1] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference Level[1] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router Address[2] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference Level[2] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | .... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 16 | Length | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Care-of Address[1] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Care-of Address[2] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | .... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : Optional Extensions : + : .... ...... ...... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 91] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +H.2. Example Registration Request Message Format + + The UDP header is followed by the Mobile IP fields shown below: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 1 |S|B|D|M|G|r|T|x| Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Agent | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Care-of Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Identification + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional Non-Auth Extensions for HA ... | + | ( variable length ) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type =32 | Length | SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SPI (cont..) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + : MN-HA Authenticator ( variable length ) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : Optional Non-Auth Extensions for FA ......... + : Optional MN-FA Authentication Extension... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 92] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +H.3. Example Registration Reply Message Format + + The UDP header is followed by the Mobile IP fields shown below: + + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 3 | Code | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Home Agent | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Identification + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional HA Non-Auth Extensions ... | + | ( variable length ) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type =32 | Length | SPI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SPI (cont...) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + : MN-HA Authenticator ( variable length ) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : Optional Extensions used by FA......... + : Optional MN-FA Authentication Extension... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +References + + [1] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over + Satellite Channels using Standard Mechanisms", BCP 28, RFC + 2488, January 1999. + + [2] S. M. Bellovin. Security Problems in the TCP/IP Protocol + Suite. ACM Computer Communications Review, 19(2), March 1989. + + [3] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, + "Performance Enhancing Proxies", RFC 3135, June 2001. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + +Perkins Standards Track [Page 93] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + [5] 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. + + [6] Calhoun P. and C. Perkins, "Mobile IP Network Access Identifier + Extension for IPv4", RFC 2794, January 2000. + + [7] Calhoun, P. and C. Perkins, "Mobile IP Foreign Agent + Challenge/Response Extension", RFC 3012, December 2000. + + [8] Cong, D., Hamlen, M. and C. Perkins, "The Definitions of + Managed Objects for IP Mobility Support using SMIv2", RFC 2006, + October 1996. + + [9] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. + Vaidya, "End-to-end Performance Implications of Links with + Errors", BCP 50, RFC 3155, August 2001. + + [10] Deering, S., "ICMP Router Discovery Messages", RFC 1256, + September 1991. + + [11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC + 1112, August 1989. + + [12] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization- + Specific Extensions", RFC 3115, April 2001. + + [13] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [14] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [15] Ferguson P. and D. Senie, "Network Ingress Filtering: Defeating + Denial of Service Attacks which employ IP Source Address + Spoofing", BCP 38, RFC 2827, May 2000. + + [16] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic + Routing Encapsulation (GRE)", RFC 1701, October 1994. + + [17] J. Ioannidis. Protocols for Mobile Internetworking. PhD + Dissertation - Columbia University in the City of New York, + July 1993. + + + + + + + +Perkins Standards Track [Page 94] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + [18] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. IP- + Based Protocols for Mobile Internetworking. In Proceedings of + the SIGCOMM '91 Conference: Communications Architectures & + Protocols, pages 235--245, September 1991. + + [19] John Ioannidis and Gerald Q. Maguire Jr. The Design and + Implementation of a Mobile Internetworking Architecture. In + Proceedings of the Winter USENIX Technical Conference, pages + 489--500, January 1993. + + [20] Jacobson, V., "Compressing TCP/IP headers for low-speed serial + links", RFC 1144, February 1990. + + [21] Jacobson, V., "Congestion Avoidance and Control. In + Proceedings, SIGCOMM '88 Workshop, pages 314--329. ACM Press, + August 1988. Stanford, CA. + + [22] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, + November 1998. + + [23] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [24] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", + RFC 2863, June 2000. + + [25] McGregor, G., "The PPP Internet Protocol Control Protocol + (IPCP)", RFC 1332, May 1992. + + [26] Mills, D., "Network Time Protocol (Version 3) Specification, + Implementation", RFC 1305, March 1992. + + [27] Montenegro, G., "Reverse Tunneling for Mobile IP (revised)", + RFC 3024, January 2001. + + [28] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N. + Vaidya, "Long Thin Networks", RFC 2757, January 2000. + + [29] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for + Mobile IP", RFC 2356, June 1998. + + [30] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", RFC 2434, October 1998. + + [31] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + + + + + +Perkins Standards Track [Page 95] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + + [32] Perkins, C., "IP Encapsulation within IP", RFC 2003, October + 1996. + + [33] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. + + [34] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, + October 1996. + + [35] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile + IP", Work in Progress, July 2001. + + [36] Plummer, D., "Ethernet Address Resolution Protocol: Or + converting network protocol addresses to 48.bit Ethernet + address for transmission on Ethernet hardware", STD 37, RFC + 826, November 1982. + + [37] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [38] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. + + [39] Postel, J., "Multi-LAN Address Resolution", RFC 925, October + 1984. + + [40] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, October 1994. + + [41] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [42] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [43] Solomon, J., "Applicability Statement for IP Mobility Support" + RFC 2005, October 1996. + + [44] Solomon J. and S. Glass, "Mobile-IPv4 Configuration Option for + PPP IPCP", RFC 2290, February 1998. + + [45] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols" + Addison-Wesley, Reading, Massachusetts, 1994. + + + + + + + + + +Perkins Standards Track [Page 96] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +Authors' Addresses + + The working group can be contacted via the current chairs: + + Basavaraj Patil + Nokia + 6000 Connection Dr. + Irving, TX. 75039 + USA + + Phone: +1 972-894-6709 + Email: Basavaraj.Patil@nokia.com + + Phil Roberts + Megisto Corp. Suite 120 + 20251 Century Blvd + Germantown MD 20874 + USA + + Phone: +1 847-202-9314 + Email: PRoberts@MEGISTO.com + + Questions about this memo can also be directed to the editor: + + Charles E. Perkins + Communications Systems Lab + Nokia Research Center + 313 Fairchild Drive + Mountain View, California 94043 + USA + + Phone: +1-650 625-2986 + EMail: charliep@iprg.nokia.com + Fax: +1 650 625-2502 + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 97] + +RFC 3220 IP Mobility Support for IPv4 January 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Perkins Standards Track [Page 98] + |