Network Working Group D. Johnson Request for Comments: 3775 Rice University Category: Standards Track C. Perkins Nokia Research Center J. Arkko Ericsson June 2004 Mobility Support in IPv6 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 (2004). Abstract This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 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 the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. Johnson, et al. Standard Track [Page 1] RFC 3775 Mobility Support in IPv6 June 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . 6 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. General Terms . . . . . . . . . . . . . . . . . . . 8 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . 10 4. Overview of Mobile IPv6. . . . . . . . . . . . . . . . . . 13 4.1. Basic Operation . . . . . . . . . . . . . . . . . . 13 4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . 15 4.3. New IPv6 Destination Option . . . . . . . . . . . . 17 4.4. New IPv6 ICMP Messages. . . . . . . . . . . . . . . 17 4.5. Conceptual Data Structure Terminology . . . . . . . 17 4.6. Site-Local Addressability . . . . . . . . . . . . . 18 5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . 18 5.1. Binding Updates to Home Agents. . . . . . . . . . . 18 5.2. Binding Updates to Correspondent Nodes. . . . . . . 20 5.2.1. Node Keys . . . . . . . . . . . . . . . . . 20 5.2.2. Nonces. . . . . . . . . . . . . . . . . . . 20 5.2.3. Cookies and Tokens. . . . . . . . . . . . . 21 5.2.4. Cryptographic Functions . . . . . . . . . . 22 5.2.5. Return Routability Procedure. . . . . . . . 22 5.2.6. Authorizing Binding Management Messages . . 27 5.2.7. Updating Node Keys and Nonces . . . . . . . 29 5.2.8. Preventing Replay Attacks . . . . . . . . . 30 5.3. Dynamic Home Agent Address Discovery. . . . . . . . 30 5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . 30 5.5. Payload Packets . . . . . . . . . . . . . . . . . . 30 6. New IPv6 Protocol, Message Types, and Destination Option . 31 6.1. Mobility Header . . . . . . . . . . . . . . . . . . 31 6.1.1. Format. . . . . . . . . . . . . . . . . . . 32 6.1.2. Binding Refresh Request Message . . . . . . 34 6.1.3. Home Test Init Message. . . . . . . . . . . 35 6.1.4. Care-of Test Init Message . . . . . . . . . 36 6.1.5. Home Test Message . . . . . . . . . . . . . 37 6.1.6. Care-of Test Message. . . . . . . . . . . . 38 6.1.7. Binding Update Message. . . . . . . . . . . 39 6.1.8. Binding Acknowledgement Message . . . . . . 42 6.1.9. Binding Error Message . . . . . . . . . . . 44 6.2. Mobility Options. . . . . . . . . . . . . . . . . . 46 6.2.1. Format. . . . . . . . . . . . . . . . . . . 46 6.2.2. Pad1. . . . . . . . . . . . . . . . . . . . 47 6.2.3. PadN. . . . . . . . . . . . . . . . . . . . 48 6.2.4. Binding Refresh Advice. . . . . . . . . . . 48 6.2.5. Alternate Care-of Address . . . . . . . . . 49 6.2.6. Nonce Indices . . . . . . . . . . . . . . . 49 6.2.7. Binding Authorization Data. . . . . . . . . 50 6.3. Home Address Option . . . . . . . . . . . . . . . . 51 Johnson, et al. Standard Track [Page 2] RFC 3775 Mobility Support in IPv6 June 2004 6.4. Type 2 Routing Header . . . . . . . . . . . . . . . 53 6.4.1. Format. . . . . . . . . . . . . . . . . . . 54 6.5. ICMP Home Agent Address Discovery Request Message . 55 6.6. ICMP Home Agent Address Discovery Reply Message . . 56 6.7. ICMP Mobile Prefix Solicitation Message Format. . . 57 6.8. ICMP Mobile Prefix Advertisement Message Format . . 59 7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . 61 7.1. Modified Router Advertisement Message Format. . . . 61 7.2. Modified Prefix Information Option Format . . . . . 62 7.3. New Advertisement Interval Option Format. . . . . . 64 7.4. New Home Agent Information Option Format. . . . . . 65 7.5. Changes to Sending Router Advertisements. . . . . . 67 8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . 69 8.1. All IPv6 Nodes. . . . . . . . . . . . . . . . . . . 69 8.2. IPv6 Nodes with Support for Route Optimization. . . 69 8.3. All IPv6 Routers. . . . . . . . . . . . . . . . . . 71 8.4. IPv6 Home Agents. . . . . . . . . . . . . . . . . . 71 8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . 73 9. Correspondent Node Operation . . . . . . . . . . . . . . . 74 9.1. Conceptual Data Structures. . . . . . . . . . . . . 74 9.2. Processing Mobility Headers . . . . . . . . . . . . 75 9.3. Packet Processing . . . . . . . . . . . . . . . . . 76 9.3.1. Receiving Packets with Home Address Option. 76 9.3.2. Sending Packets to a Mobile Node. . . . . . 77 9.3.3. Sending Binding Error Messages. . . . . . . 78 9.3.4. Receiving ICMP Error Messages . . . . . . . 79 9.4. Return Routability Procedure. . . . . . . . . . . . 79 9.4.1. Receiving Home Test Init Messages . . . . . 80 9.4.2. Receiving Care-of Test Init Messages. . . . 80 9.4.3. Sending Home Test Messages. . . . . . . . . 80 9.4.4. Sending Care-of Test Messages . . . . . . . 81 9.5 Processing Bindings . . . . . . . . . . . . . . . . 81 9.5.1. Receiving Binding Updates . . . . . . . . . 81 9.5.2. Requests to Cache a Binding . . . . . . . . 84 9.5.3. Requests to Delete a Binding. . . . . . . . 84 9.5.4. Sending Binding Acknowledgements. . . . . . 85 9.5.5. Sending Binding Refresh Requests. . . . . . 86 9.6. Cache Replacement Policy. . . . . . . . . . . . . . 86 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . 87 10.1. Conceptual Data Structures. . . . . . . . . . . . . 87 10.2. Processing Mobility Headers . . . . . . . . . . . . 88 10.3. Processing Bindings . . . . . . . . . . . . . . . . 88 10.3.1. Primary Care-of Address Registration. . . . 88 10.3.2. Primary Care-of Address De-Registration . . 92 10.4. Packet Processing . . . . . . . . . . . . . . . . . 94 10.4.1. Intercepting Packets for a Mobile Node. . . 94 10.4.2. Processing Intercepted Packets. . . . . . . 95 10.4.3. Multicast Membership Control. . . . . . . . 96 Johnson, et al. Standard Track [Page 3] RFC 3775 Mobility Support in IPv6 June 2004 10.4.4. Stateful Address Autoconfiguration. . . . . 98 10.4.5. Handling Reverse Tunneled Packets . . . . . 98 10.4.6. Protecting Return Routability Packets . . . 99 10.5. Dynamic Home Agent Address Discovery. . . . . . . . 99 10.5.1. Receiving Router Advertisement Messages . . 100 10.6. Sending Prefix Information to the Mobile Node . . . 102 10.6.1. List of Home Network Prefixes . . . . . . . 102 10.6.2. Scheduling Prefix Deliveries. . . . . . . . 102 10.6.3. Sending Advertisements. . . . . . . . . . . 104 10.6.4. Lifetimes for Changed Prefixes. . . . . . . 105 11. Mobile Node Operation. . . . . . . . . . . . . . . . . . . 105 11.1. Conceptual Data Structures. . . . . . . . . . . . . 105 11.2. Processing Mobility Headers . . . . . . . . . . . . 107 11.3. Packet Processing . . . . . . . . . . . . . . . . . 107 11.3.1. Sending Packets While Away from Home. . . . 107 11.3.2. Interaction with Outbound IPsec Processing. 110 11.3.3. Receiving Packets While Away from Home. . . 112 11.3.4. Routing Multicast Packets . . . . . . . . . 114 11.3.5. Receiving ICMP Error Messages . . . . . . . 115 11.3.6. Receiving Binding Error Messages. . . . . . 116 11.4. Home Agent and Prefix Management. . . . . . . . . . 117 11.4.1. Dynamic Home Agent Address Discovery. . . . 117 11.4.2. Sending Mobile Prefix Solicitations . . . . 118 11.4.3. Receiving Mobile Prefix Advertisements. . . 118 11.5. Movement. . . . . . . . . . . . . . . . . . . . . . 120 11.5.1. Movement Detection. . . . . . . . . . . . . 120 11.5.2. Forming New Care-of Addresses . . . . . . . 122 11.5.3. Using Multiple Care-of Addresses. . . . . . 123 11.5.4. Returning Home. . . . . . . . . . . . . . . 124 11.6. Return Routability Procedure. . . . . . . . . . . . 126 11.6.1. Sending Test Init Messages. . . . . . . . . 126 11.6.2. Receiving Test Messages . . . . . . . . . . 127 11.6.3. Protecting Return Routability Packets . . . 128 11.7. Processing Bindings . . . . . . . . . . . . . . . . 128 11.7.1. Sending Binding Updates to the Home Agent . 128 11.7.2. Correspondent Registration. . . . . . . . . 131 11.7.3. Receiving Binding Acknowledgements. . . . . 134 11.7.4. Receiving Binding Refresh Requests. . . . . 136 11.8. Retransmissions and Rate Limiting . . . . . . . . . 137 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 138 13. Protocol Configuration Variables . . . . . . . . . . . . . 138 14. IANA Considerations. . . . . . . . . . . . . . . . . . . . 139 15. Security Considerations. . . . . . . . . . . . . . . . . . 142 15.1. Threats . . . . . . . . . . . . . . . . . . . . . . 142 15.2. Features. . . . . . . . . . . . . . . . . . . . . . 144 15.3. Binding Updates to Home Agent . . . . . . . . . . . 145 15.4. Binding Updates to Correspondent Nodes. . . . . . . 148 15.4.1. Overview. . . . . . . . . . . . . . . . . . 149 Johnson, et al. Standard Track [Page 4] RFC 3775 Mobility Support in IPv6 June 2004 15.4.2. Achieved Security Properties. . . . . . . . 149 15.4.3. Comparison to Regular IPv6 Communications . 150 15.4.4. Replay Attacks. . . . . . . . . . . . . . . 152 15.4.5. Denial-of-Service Attacks . . . . . . . . . 152 15.4.6. Key Lengths . . . . . . . . . . . . . . . . 153 15.5. Dynamic Home Agent Address Discovery. . . . . . . . 154 15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . 155 15.7. Tunneling via the Home Agent. . . . . . . . . . . . 155 15.8. Home Address Option . . . . . . . . . . . . . . . . 156 15.9. Type 2 Routing Header . . . . . . . . . . . . . . . 156 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . 157 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 157 18. References . . . . . . . . . . . . . . . . . . . . . . . . 158 18.1. Normative References. . . . . . . . . . . . . . . . 158 18.2. Informative References. . . . . . . . . . . . . . . 159 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 161 A.1. Piggybacking. . . . . . . . . . . . . . . . . . . . 161 A.2. Triangular Routing. . . . . . . . . . . . . . . . . 161 A.3. New Authorization Methods . . . . . . . . . . . . . 161 A.4. Dynamically Generated Home Addresses. . . . . . . . 161 A.5. Remote Home Address Configuration . . . . . . . . . 162 A.6. Neighbor Discovery Extensions . . . . . . . . . . . 163 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 164 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 165 1. Introduction This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Without specific support for mobility in IPv6 [11], packets destined to a mobile node would not be able to reach it while the mobile node is away from its home link. In order to continue communication in spite of its movement, a mobile node could change its IP address each time it moves to a new link, but the mobile node would then not be able to maintain transport and higher-layer connections when it changes location. Mobility support in IPv6 is particularly important, as mobile computers are likely to account for a majority or at least a substantial fraction of the population of the Internet during the lifetime of IPv6. The protocol defined in this document, known as Mobile IPv6, allows a mobile node to move from one link to another without changing the mobile node's "home address". Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a Johnson, et al. Standard Track [Page 5] RFC 3775 Mobility Support in IPv6 June 2004 new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications. The Mobile IPv6 protocol is just as suitable for mobility across homogeneous media as for mobility across heterogeneous media. For example, Mobile IPv6 facilitates node movement from one Ethernet segment to another as well as it facilitates node movement from an Ethernet segment to a wireless LAN cell, with the mobile node's IP address remaining unchanged in spite of such movement. One can think of the Mobile IPv6 protocol as solving the network- layer mobility management problem. Some mobility management applications -- for example, handover among wireless transceivers, each of which covers only a very small geographic area -- have been solved using link-layer techniques. For example, in many current wireless LAN products, link-layer mobility mechanisms allow a "handover" of a mobile node from one cell to another, re-establishing link-layer connectivity to the node in each new location. Mobile IPv6 does not attempt to solve all general problems related to the use of mobile computers or wireless networks. In particular, this protocol does not attempt to solve: o Handling links with unidirectional connectivity or partial reachability, such as the hidden terminal problem where a host is hidden from only some of the routers on the link. o Access control on a link being visited by a mobile node. o Local or hierarchical forms of mobility management (similar to many current link-layer mobility management solutions). o Assistance for adaptive applications. o Mobile routers. o Service Discovery. o Distinguishing between packets lost due to bit errors vs. network congestion. 2. Comparison with Mobile IP for IPv4 The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both from the experiences gained from the development of Mobile IP support in IPv4 (Mobile IPv4) [22, 23, 24], and from the opportunities provided by IPv6. Mobile IPv6 thus shares many features with Mobile Johnson, et al. Standard Track [Page 6] RFC 3775 Mobility Support in IPv6 June 2004 IPv4, but is integrated into IPv6 and offers many other improvements. This section summarizes the major differences between Mobile IPv4 and Mobile IPv6: o There is no need to deploy special routers as "foreign agents", as in Mobile IPv4. Mobile IPv6 operates in any location without any special support required from the local router. o Support for route optimization is a fundamental part of the protocol, rather than a nonstandard set of extensions. o Mobile IPv6 route optimization can operate securely even without pre-arranged security associations. It is expected that route optimization can be deployed on a global scale between all mobile nodes and correspondent nodes. o Support is also integrated into Mobile IPv6 for allowing route optimization to coexist efficiently with routers that perform "ingress filtering" [26]. o The IPv6 Neighbor Unreachability Detection assures symmetric reachability between the mobile node and its default router in the current location. o Most packets sent to a mobile node while away from home in Mobile IPv6 are sent using an IPv6 routing header rather than IP encapsulation, reducing the amount of resulting overhead compared to Mobile IPv4. o Mobile IPv6 is decoupled from any particular link layer, as it uses IPv6 Neighbor Discovery [12] instead of ARP. This also improves the robustness of the protocol. o The use of IPv6 encapsulation (and the routing header) removes the need in Mobile IPv6 to manage "tunnel soft state". o The dynamic home agent address discovery mechanism in Mobile IPv6 returns a single reply to the mobile node. The directed broadcast approach used in IPv4 returns separate replies from each home agent. 3. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. Johnson, et al. Standard Track [Page 7] RFC 3775 Mobility Support in IPv6 June 2004 3.1. General Terms IP Internet Protocol Version 6 (IPv6). node A device that implements IP. router A node that forwards IP packets not explicitly addressed to itself. unicast routable address An identifier for a single interface such that a packet sent to it from another IPv6 subnet is delivered to the interface identified by that address. Accordingly, a unicast routable address must have either a global or site-local scope (but not link-local). host Any node that is not a router. link A communication facility or medium over which nodes can communicate at the link layer, such as an Ethernet (simple or bridged). A link is the layer immediately below IP. interface A node's attachment to a link. subnet prefix A bit string that consists of some number of initial bits of an IP address. interface identifier A number used to identify a node's interface on a link. The interface identifier is the remaining low-order bits in the node's IP address after the subnet prefix. Johnson, et al. Standard Track [Page 8] RFC 3775 Mobility Support in IPv6 June 2004 link-layer address A link-layer identifier for an interface, such as IEEE 802 addresses on Ethernet links. packet An IP header plus payload. security association An IPsec security association is a cooperative relationship formed by the sharing of cryptographic keying material and associated context. Security associations are simplex. That is, two security associations are needed to protect bidirectional traffic between two nodes, one for each direction. security policy database A database that specifies what security services are to be offered to IP packets and in what fashion. destination option Destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 node given as the destination address in the IPv6 header, not by routers in between. Mobile IPv6 defines one new destination option, the Home Address destination option (see Section 6.3). routing header A routing header may be present as an IPv6 header extension, and indicates that the payload has to be delivered to a destination IPv6 address in some way that is different from what would be carried out by standard Internet routing. In this document, use of the term "routing header" typically refers to use of a type 2 routing header, as specified in Section 6.4. "|" (concatenation) Some formulas in this specification use the symbol "|" to indicate bytewise concatenation, as in A | B. This concatenation requires that all of the octets of the datum A appear first in the result, followed by all of the octets of the datum B. Johnson, et al. Standard Track [Page 9] RFC 3775 Mobility Support in IPv6 June 2004 First (size, input) Some formulas in this specification use a functional form "First (size, input)" to indicate truncation of the "input" data so that only the first "size" bits remain to be used. 3.2. Mobile IPv6 Terms home address A unicast routable address assigned to a mobile node, used as the permanent address of the mobile node. This address is within the mobile node's home link. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Mobile nodes can have multiple home addresses, for instance when there are multiple home prefixes on the home link. home subnet prefix The IP subnet prefix corresponding to a mobile node's home address. home link The link on which a mobile node's home subnet prefix is defined. mobile node A node that can change its point of attachment from one link to another, while still being reachable via its home address. movement A change in a mobile node's point of attachment to the Internet such that it is no longer connected to the same link as it was previously. If a mobile node is not currently attached to its home link, the mobile node is said to be "away from home". L2 handover A process by which the mobile node changes from one link-layer connection to another. For example, a change of wireless access point is an L2 handover. Johnson, et al. Standard Track [Page 10] RFC 3775 Mobility Support in IPv6 June 2004 L3 handover Subsequent to an L2 handover, a mobile node detects a change in an on-link subnet prefix that would require a change in the primary care-of address. For example, a change of access router subsequent to a change of wireless access point typically results in an L3 handover. correspondent node A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. foreign subnet prefix Any IP subnet prefix other than the mobile node's home subnet prefix. foreign link Any link other than the mobile node's home link. care-of address A unicast routable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple care-of addresses that a mobile node may have at any given time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent for a given home address is called its "primary" care-of address. home agent A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and tunnels them to the mobile node's registered care-of address. binding The association of the home address of a mobile node with a care- of address for that mobile node, along with the remaining lifetime of that association. Johnson, et al. Standard Track [Page 11] RFC 3775 Mobility Support in IPv6 June 2004 registration The process during which a mobile node sends a Binding Update to its home agent or a correspondent node, causing a binding for the mobile node to be registered. mobility message A message containing a Mobility Header (see Section 6.1). binding authorization Correspondent registration needs to be authorized to allow the recipient to believe that the sender has the right to specify a new binding. return routability procedure The return routability procedure authorizes registrations by the use of a cryptographic token exchange. correspondent registration A return routability procedure followed by a registration, run between the mobile node and a correspondent node. home registration A registration between the mobile node and its home agent, authorized by the use of IPsec. nonce Nonces are random numbers used internally by the correspondent node in the creation of keygen tokens related to the return routability procedure. The nonces are not specific to a mobile node, and are kept secret within the correspondent node. nonce index A nonce index is used to indicate which nonces have been used when creating keygen token values, without revealing the nonces themselves. Johnson, et al. Standard Track [Page 12] RFC 3775 Mobility Support in IPv6 June 2004 cookie A cookie is a random number used by a mobile node to prevent spoofing by a bogus correspondent node in the return routability procedure. care-of init cookie A cookie sent to the correspondent node in the Care-of Test Init message, to be returned in the Care-of Test message. home init cookie A cookie sent to the correspondent node in the Home Test Init message, to be returned in the Home Test message. keygen token A keygen token is a number supplied by a correspondent node in the return routability procedure to enable the mobile node to compute the necessary binding management key for authorizing a Binding Update. care-of keygen token A keygen token sent by the correspondent node in the Care-of Test message. home keygen token A keygen token sent by the correspondent node in the Home Test message. binding management key (Kbm) A binding management key (Kbm) is a key used for authorizing a binding cache management message (e.g., Binding Update or Binding Acknowledgement). Return routability provides a way to create a binding management key. 4. Overview of Mobile IPv6 4.1. Basic Operation A mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a Johnson, et al. Standard Track [Page 13] RFC 3775 Mobility Support in IPv6 June 2004 mobile node is at home, packets addressed to its home address are routed to the mobile node's home link, using conventional Internet routing mechanisms. While a mobile node is attached to some foreign link away from home, it is also addressable at one or more care-of addresses. A care-of address is an IP address associated with a mobile node that has the subnet prefix of a particular foreign link. The mobile node can acquire its care-of address through conventional IPv6 mechanisms, such as stateless or stateful auto-configuration. As long as the mobile node stays in this location, packets addressed to this care-of address will be routed to the mobile node. The mobile node may also accept packets from several care-of addresses, such as when it is moving but still reachable at the previous link. The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message. The operation of the mobile node is specified in Section 11, and the operation of the home agent is specified in Section 10. Any node communicating with a mobile node is referred to in this document as a "correspondent node" of the mobile node, and may itself be either a stationary node or a mobile node. Mobile nodes can provide information about their current location to correspondent nodes. This happens through the correspondent registration. As a part of this procedure, a return routability test is performed in order to authorize the establishment of the binding. The operation of the correspondent node is specified in Section 9. There are two possible modes for communications between the mobile node and a correspondent node. The first mode, bidirectional tunneling, does not require Mobile IPv6 support from the correspondent node and is available even if the mobile node has not registered its current binding with the correspondent node. Packets from the correspondent node are routed to the home agent and then tunneled to the mobile node. Packets to the correspondent node are tunneled from the mobile node to the home agent ("reverse tunneled") and then routed normally from the home network to the correspondent node. In this mode, the home agent uses proxy Neighbor Discovery to intercept any IPv6 packets addressed to the mobile node's home Johnson, et al. Standard Track [Page 14] RFC 3775 Mobility Support in IPv6 June 2004 address (or home addresses) on the home link. Each intercepted packet is tunneled to the mobile node's primary care-of address. This tunneling is performed using IPv6 encapsulation [15]. The second mode, "route optimization", requires the mobile node to register its current binding at the correspondent node. Packets from the correspondent node can be routed directly to the care-of address of the mobile node. When sending a packet to any IPv6 destination, the correspondent node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node uses a new type of IPv6 routing header [11] (see Section 6.4) to route the packet to the mobile node by way of the care-of address indicated in this binding. Routing packets directly to the mobile node's care-of address allows the shortest communications path to be used. It also eliminates congestion at the mobile node's home agent and home link. In addition, the impact of any possible failure of the home agent or networks on the path to or from it is reduced. When routing packets directly to the mobile node, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. A new type of IPv6 routing header (see Section 6.4) is also added to the packet to carry the desired home address. Similarly, the mobile node sets the Source Address in the packet's IPv6 header to its current care-of addresses. The mobile node adds a new IPv6 "Home Address" destination option (see Section 6.3) to carry its home address. The inclusion of home addresses in these packets makes the use of the care-of address transparent above the network layer (e.g., at the transport layer). Mobile IPv6 also provides support for multiple home agents, and a limited support for the reconfiguration of the home network. In these cases, the mobile node may not know the IP address of its own home agent, and even the home subnet prefixes may change over time. A mechanism, known as "dynamic home agent address discovery" allows a mobile node to dynamically discover the IP address of a home agent on its home link, even when the mobile node is away from home. Mobile nodes can also learn new information about home subnet prefixes through the "mobile prefix discovery" mechanism. These mechanisms are described starting from Section 6.5. 4.2. New IPv6 Protocol Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header (see Section 6.1). This Header is used to carry the following messages: Johnson, et al. Standard Track [Page 15] RFC 3775 Mobility Support in IPv6 June 2004 Home Test Init Home Test Care-of Test Init Care-of Test These four messages are used to perform the return routability procedure from the mobile node to a correspondent node. This ensures authorization of subsequent Binding Updates, as described in Section 5.2.5. Binding Update A Binding Update is used by a mobile node to notify a correspondent node or the mobile node's home agent of its current binding. The Binding Update sent to the mobile node's home agent to register its primary care-of address is marked as a "home registration". Binding Acknowledgement A Binding Acknowledgement is used to acknowledge receipt of a Binding Update, if an acknowledgement was requested in the Binding Update, the binding update was sent to a home agent, or an error occurred. Binding Refresh Request A Binding Refresh Request is used by a correspondent node to request a mobile node to re-establish its binding with the correspondent node. This message is typically used when the cached binding is in active use but the binding's lifetime is close to expiration. The correspondent node may use, for instance, recent traffic and open transport layer connections as an indication of active use. Binding Error The Binding Error is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding. Johnson, et al. Standard Track [Page 16] RFC 3775 Mobility Support in IPv6 June 2004 4.3. New IPv6 Destination Option Mobile IPv6 defines a new IPv6 destination option, the Home Address destination option. This option is described in detail in Section 6.3. 4.4. New IPv6 ICMP Messages Mobile IPv6 also introduces four new ICMP message types, two for use in the dynamic home agent address discovery mechanism, and two for renumbering and mobile configuration mechanisms. As described in Section 10.5 and Section 11.4.1, the following two new ICMP message types are used for home agent address discovery: o Home Agent Address Discovery Request, described in Section 6.5. o Home Agent Address Discovery Reply, described in Section 6.6. The next two message types are used for network renumbering and address configuration on the mobile node, as described in Section 10.6: o Mobile Prefix Solicitation, described in Section 6.7. o Mobile Prefix Advertisement, described in Section 6.8. 4.5. Conceptual Data Structure Terminology This document describes the Mobile IPv6 protocol in terms of the following conceptual data structures: Binding Cache A cache of bindings for other nodes. This cache is maintained by home agents and correspondent nodes. The cache contains both "correspondent registration" entries (see Section 9.1) and "home registration" entries (see Section 10.1). Binding Update List This list is maintained by each mobile node. The list has an item for every binding that the mobile node has or is trying to establish with a specific other node. Both correspondent and home registrations are included in this list. Entries from the list are deleted as the lifetime of the binding expires. See Section 11.1. Johnson, et al. Standard Track [Page 17] RFC 3775 Mobility Support in IPv6 June 2004 Home Agents List Home agents need to know which other home agents are on the same link. This information is stored in the Home Agents List, as described in more detail in Section 10.1. The list is used for informing mobile nodes during dynamic home agent address discovery. 4.6. Site-Local Addressability This specification requires that home and care-of addresses MUST be unicast routable addresses. Site-local addresses may be usable on networks that are not connected to the Internet, but this specification does not define when such usage is safe and when it is not. Mobile nodes may not be aware of which site they are currently in, it is hard to prevent accidental attachment to other sites, and ambiguity of site-local addresses can cause problems if the home and visited networks use the same addresses. Therefore, site-local addresses SHOULD NOT be used as home or care-of addresses. 5. Overview of Mobile IPv6 Security This specification provides a number of security features. These include the protection of Binding Updates both to home agents and correspondent nodes, the protection of mobile prefix discovery, and the protection of the mechanisms that Mobile IPv6 uses for transporting data packets. Binding Updates are protected by the use of IPsec extension headers, or by the use of the Binding Authorization Data option. This option employs a binding management key, Kbm, which can be established through the return routability procedure. Mobile prefix discovery is protected through the use of IPsec extension headers. Mechanisms related to transporting payload packets - such as the Home Address destination option and type 2 routing header - have been specified in a manner which restricts their use in attacks. 5.1. Binding Updates to Home Agents The mobile node and the home agent MUST use an IPsec security association to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [6] header in transport mode and MUST use a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. Note that Authentication Header (AH) [5] is also possible but for brevity not discussed in this specification. Johnson, et al. Standard Track [Page 18] RFC 3775 Mobility Support in IPv6 June 2004 In order to protect messages exchanged between the mobile node and the home agent with IPsec, appropriate security policy database entries must be created. A mobile node must be prevented from using its security association to send a Binding Update on behalf of another mobile node using the same home agent. This MUST be achieved by having the home agent check that the given home address has been used with the right security association. Such a check is provided in the IPsec processing, by having the security policy database entries unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent. In order to make this possible, it is necessary that the home address of the mobile node is visible in the Binding Updates and Acknowledgements. The home address is used in these packets as a source or destination, or in the Home Address Destination option or the type 2 routing header. As with all IPsec security associations in this specification, manual configuration of security associations MUST be supported. The used shared secrets MUST be random and unique for different mobile nodes, and MUST be distributed off-line to the mobile nodes. Automatic key management with IKE [9] MAY be supported. When IKE is used, either the security policy database entries or the Mobile IPv6 processing MUST unequivocally identify the IKE phase 1 credentials which can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address. How these mappings are maintained is outside the scope of this specification, but they may be maintained, for instance, as a locally administered table in the home agent. If the phase 1 identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS may also be used. Section 11.3.2 discusses how IKE connections to the home agent need a careful treatment of the addresses used for transporting IKE. This is necessary to ensure that a Binding Update is not needed before the IKE exchange which is needed for securing the Binding Update. When IKE version 1 is used with preshared secret authentication between the mobile node and the home agent, aggressive mode MUST be used. The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1. Reference [21] contains a more detailed description and examples on using IPsec to protect the communications between the mobile node and the home agent. Johnson, et al. Standard Track [Page 19] RFC 3775 Mobility Support in IPv6 June 2004 5.2. Binding Updates to Correspondent Nodes The protection of Binding Updates sent to correspondent nodes does not require the configuration of security associations or the existence of an authentication infrastructure between the mobile nodes and correspondent nodes. Instead, a method called the return routability procedure is used to assure that the right mobile node is sending the message. This method does not protect against attackers who are on the path between the home network and the correspondent node. However, attackers in such a location are capable of performing the same attacks even without Mobile IPv6. The main advantage of the return routability procedure is that it limits the potential attackers to those having an access to one specific path in the Internet, and avoids forged Binding Updates from anywhere else in the Internet. For a more in depth explanation of the security properties of the return routability procedure, see Section 15. The integrity and authenticity of the Binding Updates messages to correspondent nodes is protected by using a keyed-hash algorithm. The binding management key, Kbm, is used to key the hash algorithm for this purpose. Kbm is established using data exchanged during the return routability procedure. The data exchange is accomplished by use of node keys, nonces, cookies, tokens, and certain cryptographic functions. Section 5.2.5 outlines the basic return routability procedure. Section 5.2.6 shows how the results of this procedure are used to authorize a Binding Update to a correspondent node. 5.2.1. Node Keys Each correspondent node has a secret key, Kcn, called the "node key", which it uses to produce the keygen tokens sent to the mobile nodes. The node key MUST be a random number, 20 octets in length. The node key allows the correspondent node to verify that the keygen tokens used by the mobile node in authorizing a Binding Update are indeed its own. This key MUST NOT be shared with any other entity. A correspondent node MAY generate a fresh node key at any time; this avoids the need for secure persistent key storage. Procedures for optionally updating the node key are discussed later in Section 5.2.7. 5.2.2. Nonces Each correspondent node also generates nonces at regular intervals. The nonces should be generated by using a random number generator that is known to have good randomness properties [1]. A correspondent node may use the same Kcn and nonce with all the mobiles it is in communication with. Johnson, et al. Standard Track [Page 20] RFC 3775 Mobility Support in IPv6 June 2004 Each nonce is identified by a nonce index. When a new nonce is generated, it must be associated with a new nonce index; this may be done, for example, by incrementing the value of the previous nonce index, if the nonce index is used as an array pointer into a linear array of nonces. However, there is no requirement that nonces be stored that way, or that the values of subsequent nonce indices have any particular relationship to each other. The index value is communicated in the protocol, so that if a nonce is replaced by new nonce during the run of a protocol, the correspondent node can distinguish messages that should be checked against the old nonce from messages that should be checked against the new nonce. Strictly speaking, indices are not necessary in the authentication, but allow the correspondent node to efficiently find the nonce value that it used in creating a keygen token. Correspondent nodes keep both the current nonce and a small set of valid previous nonces whose lifetime has not yet expired. Expired values MUST be discarded, and messages using stale or unknown indices will be rejected. The specific nonce index values cannot be used by mobile nodes to determine the validity of the nonce. Expected validity times for the nonces values and the procedures for updating them are discussed later in Section 5.2.7. A nonce is an octet string of any length. The recommended length is 64 bits. 5.2.3. Cookies and Tokens The return routability address test procedure uses cookies and keygen tokens as opaque values within the test init and test messages, respectively. o The "home init cookie" and "care-of init cookie" are 64 bit values sent to the correspondent node from the mobile node, and later returned to the mobile node. The home init cookie is sent in the Home Test Init message, and returned in the Home Test message. The care-of init cookie is sent in the Care-of Test Init message, and returned in the Care-of Test message. o The "home keygen token" and "care-of keygen token" are 64-bit values sent by the correspondent node to the mobile node via the home agent (via the Home Test message) and the care-of address (by the Care-of Test message), respectively. Johnson, et al. Standard Track [Page 21] RFC 3775 Mobility Support in IPv6 June 2004 The mobile node should set the home init or care-of init cookie to a newly generated random number in every Home or Care-of Test Init message it sends. The cookies are used to verify that the Home Test or Care-of Test message matches the Home Test Init or Care-of Test Init message, respectively. These cookies also serve to ensure that parties who have not seen the request cannot spoof responses. Home and care-of keygen tokens are produced by the correspondent node based on its currently active secret key (Kcn) and nonces, as well as the home or care-of address (respectively). A keygen token is valid as long as both the secret key (Kcn) and the nonce used to create it are valid. 5.2.4. Cryptographic Functions In this specification, the function used to compute hash values is SHA1 [20]. Message Authentication Codes (MACs) are computed using HMAC_SHA1 [25, 20]. HMAC_SHA1(K,m) denotes such a MAC computed on message m with key K. 5.2.5. Return Routability Procedure The Return Routability Procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed care-of address. This is done by testing whether packets addressed to the two claimed addresses are routed to the mobile node. The mobile node can pass the test only if it is able to supply proof that it received certain data (the "keygen tokens") which the correspondent node sends to those addresses. These data are combined by the mobile node into a binding management key, denoted Kbm. The figure below shows the message flow for the return routability procedure. Johnson, et al. Standard Track [Page 22] RFC 3775 Mobility Support in IPv6 June 2004 Mobile node Home agent Correspondent node | | | Home Test Init (HoTI) | | |------------------------->|------------------------->| | | | | Care-of Test Init (CoTI) | |---------------------------------------------------->| | | | | Home Test (HoT) | |<-------------------------|<-------------------------| | | | | Care-of Test (CoT) | |<----------------------------------------------------| | | The Home and Care-of Test Init messages are sent at the same time. The procedure requires very little processing at the correspondent node, and the Home and Care-of Test messages can be returned quickly, perhaps nearly simultaneously. These four messages form the return routability procedure. Home Test Init A mobile node sends a Home Test Init message to the correspondent node (via the home agent) to acquire the home keygen token. The contents of the message can be summarized as follows: * Source Address = home address * Destination Address = correspondent * Parameters: + home init cookie The Home Test Init message conveys the mobile node's home address to the correspondent node. The mobile node also sends along a home init cookie that the correspondent node must return later. The Home Test Init message is reverse tunneled through the home agent. (The headers and addresses related to reverse tunneling have been omitted from the above discussion of the message contents.) The mobile node remembers these cookie values to obtain some assurance that its protocol messages are being processed by the desired correspondent node. Johnson, et al. Standard Track [Page 23] RFC 3775 Mobility Support in IPv6 June 2004 Care-of Test Init The mobile node sends a Care-of Test Init message to the correspondent node (directly, not via the home agent) to acquire the care-of keygen token. The contents of this message can be summarized as follows: * Source Address = care-of address * Destination Address = correspondent * Parameters: + care-of init cookie The Care-of Test Init message conveys the mobile node's care-of address to the correspondent node. The mobile node also sends along a care-of init cookie that the correspondent node must return later. The Care-of Test Init message is sent directly to the correspondent node. Home Test The Home Test message is sent in response to a Home Test Init message. It is sent via the home agent. The contents of the message are: * Source Address = correspondent * Destination Address = home address * Parameters: + home init cookie + home keygen token + home nonce index Johnson, et al. Standard Track [Page 24] RFC 3775 Mobility Support in IPv6 June 2004 When the correspondent node receives the Home Test Init message, it generates a home keygen token as follows: home keygen token := First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) where | denotes concatenation. The final "0" inside the HMAC_SHA1 function is a single zero octet, used to distinguish home and care-of cookies from each other. The home keygen token is formed from the first 64 bits of the MAC. The home keygen token tests that the mobile node can receive were messages sent to its home address. Kcn is used in the production of home keygen token in order to allow the correspondent node to verify that it generated the home and care-of nonces, without forcing the correspondent node to remember a list of all tokens it has handed out. The Home Test message is sent to the mobile node via the home network, where it is presumed that the home agent will tunnel the message to the mobile node. This means that the mobile node needs to already have sent a Binding Update to the home agent, so that the home agent will have received and authorized the new care-of address for the mobile node before the return routability procedure. For improved security, the data passed between the home agent and the mobile node is made immune to inspection and passive attacks. Such protection is gained by encrypting the home keygen token as it is tunneled from the home agent to the mobile node as specified in Section 10.4.6. The security properties of this additional security are discussed in Section 15.4.1. The home init cookie from the mobile node is returned in the Home Test message, to ensure that the message comes from a node on the route between the home agent and the correspondent node. The home nonce index is delivered to the mobile node to later allow the correspondent node to efficiently find the nonce value that it used in creating the home keygen token. Care-of Test This message is sent in response to a Care-of Test Init message. This message is not sent via the home agent, it is sent directly to the mobile node. The contents of the message are: * Source Address = correspondent * Destination Address = care-of address Johnson, et al. Standard Track [Page 25] RFC 3775 Mobility Support in IPv6 June 2004 * Parameters: + care-of init cookie + care-of keygen token + care-of nonce index When the correspondent node receives the Care-of Test Init message, it generates a care-of keygen token as follows: care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1))) Here, the final "1" inside the HMAC_SHA1 function is a single octet containing the hex value 0x01, and is used to distinguish home and care-of cookies from each other. The keygen token is formed from the first 64 bits of the MAC, and sent directly to the mobile node at its care-of address. The care-of init cookie from the Care-of Test Init message is returned to ensure that the message comes from a node on the route to the correspondent node. The care-of nonce index is provided to identify the nonce used for the care-of keygen token. The home and care-of nonce indices MAY be the same, or different, in the Home and Care-of Test messages. When the mobile node has received both the Home and Care-of Test messages, the return routability procedure is complete. As a result of the procedure, the mobile node has the data it needs to send a Binding Update to the correspondent node. The mobile node hashes the tokens together to form a 20 octet binding key Kbm: Kbm = SHA1 (home keygen token | care-of keygen token) A Binding Update may also be used to delete a previously established binding (Section 6.1.7). In this case, the care-of keygen token is not used. Instead, the binding management key is generated as follows: Kbm = SHA1(home keygen token) Note that the correspondent node does not create any state specific to the mobile node, until it receives the Binding Update from that mobile node. The correspondent node does not maintain the value for the binding management key Kbm; it creates Kbm when given the nonce indices and the mobile node's addresses. Johnson, et al. Standard Track [Page 26] RFC 3775 Mobility Support in IPv6 June 2004 5.2.6. Authorizing Binding Management Messages After the mobile node has created the binding management key (Kbm), it can supply a verifiable Binding Update to the correspondent node. This section provides an overview of this registration. The below figure shows the message flow. Mobile node Correspondent node | | | Binding Update (BU) | |---------------------------------------------->| | (MAC, seq#, nonce indices, care-of address) | | | | | | Binding Acknowledgement (BA) (if sent) | |<----------------------------------------------| | (MAC, seq#, status) | Binding Update To authorize a Binding Update, the mobile node creates a binding management key Kbm from the keygen tokens as described in the previous section. The contents of the Binding Update include the following: * Source Address = care-of address * Destination Address = correspondent * Parameters: + home address (within the Home Address destination option if different from the Source Address) + sequence number (within the Binding Update message header) + home nonce index (within the Nonce Indices option) + care-of nonce index (within the Nonce Indices option) + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU))) Johnson, et al. Standard Track [Page 27] RFC 3775 Mobility Support in IPv6 June 2004 The Binding Update contains a Nonce Indices option, indicating to the correspondent node which home and care-of nonces to use to recompute Kbm, the binding management key. The MAC is computed as described in Section 6.2.7, using the correspondent node's address as the destination address and the Binding Update message itself ("BU" above) as the MH Data. Once the correspondent node has verified the MAC, it can create a Binding Cache entry for the mobile. Binding Acknowledgement The Binding Update is in some cases acknowledged by the correspondent node. The contents of the message are as follows: * Source Address = correspondent * Destination Address = care-of address * Parameters: + sequence number (within the Binding Update message header) + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA))) The Binding Acknowledgement contains the same sequence number as the Binding Update. The MAC is computed as described in Section 6.2.7, using the correspondent node's address as the destination address and the message itself ("BA" above) as the MH Data. Bindings established with correspondent nodes using keys created by way of the return routability procedure MUST NOT exceed MAX_RR_BINDING_LIFETIME seconds (see Section 12). The value in the Source Address field in the IPv6 header carrying the Binding Update is normally also the care-of address which is used in the binding. However, a different care-of address MAY be specified by including an Alternate Care-of Address mobility option in the Binding Update (see Section 6.2.5). When such a message is sent to the correspondent node and the return routability procedure is used as the authorization method, the Care-of Test Init and Care-of Test messages MUST have been performed for the address in the Alternate Care-of Address option (not the Source Address). The nonce indices and MAC value MUST be based on information gained in this test. Johnson, et al. Standard Track [Page 28] RFC 3775 Mobility Support in IPv6 June 2004 Binding Updates may also be sent to delete a previously established binding. In this case, generation of the binding management key depends exclusively on the home keygen token and the care-of nonce index is ignored. 5.2.7. Updating Node Keys and Nonces Correspondent nodes generate nonces at regular intervals. It is recommended to keep each nonce (identified by a nonce index) acceptable for at least MAX_TOKEN_LIFETIME seconds (see Section 12) after it has been first used in constructing a return routability message response. However, the correspondent node MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 12) after the first use. As the difference between these two constants is 30 seconds, a convenient way to enforce the above lifetimes is to generate a new nonce every 30 seconds. The node can then continue to accept tokens that have been based on the last 8 (MAX_NONCE_LIFETIME / 30) nonces. This results in tokens being acceptable MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been sent to the mobile node, depending on whether the token was sent at the beginning or end of the first 30 second period. Note that the correspondent node may also attempt to generate new nonces on demand, or only if the old nonces have been used. This is possible, as long as the correspondent node keeps track of how long a time ago the nonces were used for the first time, and does not generate new nonces on every return routability request. Due to resource limitations, rapid deletion of bindings, or reboots the correspondent node may not in all cases recognize the nonces that the tokens were based on. If a nonce index is unrecognized, the correspondent node replies with an error code in the Binding Acknowledgement (either 136, 137, or 138 as discussed in Section 6.1.8). The mobile node can then retry the return routability procedure. An update of Kcn SHOULD be done at the same time as an update of a nonce, so that nonce indices can identify both the nonce and the key. Old Kcn values have to be therefore remembered as long as old nonce values. Given that the tokens are normally expected to be usable for MAX_TOKEN_LIFETIME seconds, the mobile node MAY use them beyond a single run of the return routability procedure until MAX_TOKEN_LIFETIME expires. After this the mobile node SHOULD NOT use the tokens. A fast moving mobile node MAY reuse a recent home keygen token from a correspondent node when moving to a new location, and just acquire a new care-of keygen token to show routability in the new location. Johnson, et al. Standard Track [Page 29] RFC 3775 Mobility Support in IPv6 June 2004 While this does not save the number of round-trips due to the simultaneous processing of home and care-of return routability tests, there are fewer messages being exchanged, and a potentially long round-trip through the home agent is avoided. Consequently, this optimization is often useful. A mobile node that has multiple home addresses, MAY also use the same care-of keygen token for Binding Updates concerning all of these addresses. 5.2.8. Preventing Replay Attacks The return routability procedure also protects the participants against replayed Binding Updates through the use of the sequence number and a MAC. Care must be taken when removing bindings at the correspondent node, however. Correspondent nodes must retain bindings and the associated sequence number information at least as long as the nonces used in the authorization of the binding are still valid. Alternatively, if memory is very constrained, the correspondent node MAY invalidate the nonces that were used for the binding being deleted (or some larger group of nonces that they belong to). This may, however, impact the ability to accept Binding Updates from mobile nodes that have recently received keygen tokens. This alternative is therefore recommended only as a last measure. 5.3. Dynamic Home Agent Address Discovery No security is required for dynamic home agent address discovery. 5.4. Mobile Prefix Discovery The mobile node and the home agent SHOULD use an IPsec security association to protect the integrity and authenticity of the Mobile Prefix Solicitations and Advertisements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) header in transport mode with a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. 5.5. Payload Packets Payload packets exchanged with mobile nodes can be protected in the usual manner, in the same way as stationary hosts can protect them. However, Mobile IPv6 introduces the Home Address destination option, a routing header, and tunneling headers in the payload packets. In the following we define the security measures taken to protect these, and to prevent their use in attacks against other parties. Johnson, et al. Standard Track [Page 30] RFC 3775 Mobility Support in IPv6 June 2004 This specification limits the use of the Home Address destination option to the situation where the correspondent node already has a Binding Cache entry for the given home address. This avoids the use of the Home Address option in attacks described in Section 15.1. Mobile IPv6 uses a Mobile IPv6 specific type of a routing header. This type provides the necessary functionality but does not open vulnerabilities discussed in Section 15.1. Tunnels between the mobile node and the home agent are protected by ensuring proper use of source addresses, and optional cryptographic protection. The mobile node verifies that the outer IP address corresponds to its home agent. The home agent verifies that the outer IP address corresponds to the current location of the mobile node (Binding Updates sent to the home agents are secure). The home agent identifies the mobile node through the source address of the inner packet. (Typically, this is the home address of the mobile node, but it can also be a link-local address, as discussed in Section 10.4.2. To recognize the latter type of addresses, the home agent requires that the Link-Local Address Compatibility (L) was set in the Binding Update.) These measures protect the tunnels against vulnerabilities discussed in Section 15.1. For traffic tunneled via the home agent, additional IPsec ESP encapsulation MAY be supported and used. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported. 6. New IPv6 Protocol, Message Types, and Destination Option 6.1. Mobility Header The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. The subsections within this section describe the message types that may be sent using the Mobility Header. Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section 9.5.4 for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Section 11.7.1 and Section 11.7.2 for Binding Update. Binding Update List or Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass both the Binding Cache check described in Section 9.3.2 and the Binding Update List check described in Section Johnson, et al. Standard Track [Page 31] RFC 3775 Mobility Support in IPv6 June 2004 11.3.1 which are normally performed for all packets. This applies even to messages sent to or from a correspondent node which is itself a mobile node. 6.1.1. Format The Mobility Header is identified by a Next Header value of 135 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . Message Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload Proto 8-bit selector. Identifies the type of header immediately following the Mobility Header. Uses the same values as the IPv6 Next Header field [11]. This field is intended to be used by a future extension (see Appendix B.1). Implementations conforming to this specification SHOULD set the payload protocol type to IPPROTO_NONE (59 decimal). Header Len 8-bit unsigned integer, representing the length of the Mobility Header in units of 8 octets, excluding the first 8 octets. The length of the Mobility Header MUST be a multiple of 8 octets. MH Type 8-bit selector. Identifies the particular mobility message in question. Current values are specified in Section 6.1.2 and onward. An unrecognized MH Type field causes an error indication to be sent. Johnson, et al. Standard Track [Page 32] RFC 3775 Mobility Support in IPv6 June 2004 Reserved 8-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Checksum 16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is calculated from the octet string consisting of a "pseudo-header" followed by the entire Mobility Header starting with the Payload Proto field. The checksum is the 16-bit one's complement of the one's complement sum of this string. The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of RFC 2460 [11]. The Next Header value used in the pseudo-header is 2. The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet carrying the Mobility Header. Note that the procedures of calculating upper layer checksums while away from home described in Section 11.3.1 apply even for the Mobility Header. If a mobility message has a Home Address destination option, then the checksum calculation uses the home address in this option as the value of the IPv6 Source Address field. The type 2 routing header is treated as explained in [11]. The Mobility Header is considered as the upper layer protocol for the purposes of calculating the pseudo-header. The Upper-Layer Packet Length field in the pseudo-header MUST be set to the total length of the Mobility Header. For computing the checksum, the checksum field is set to zero. Message Data A variable length field containing the data specific to the indicated Mobility Header type. Mobile IPv6 also defines a number of "mobility options" for use within these messages; if included, any options MUST appear after the fixed portion of the message data specified in this document. The presence of such options will be indicated by the Header Len field within the message. When the Header Len value is greater than the length required for the message specified here, the remaining octets are interpreted as mobility options. These options include padding options that can be used to ensure that other options are aligned Johnson, et al. Standard Track [Page 33] RFC 3775 Mobility Support in IPv6 June 2004 properly, and that the total length of the message is divisible by 8. The encoding and format of defined options are described in Section 6.2. Alignment requirements for the Mobility Header are the same as for any IPv6 protocol Header. That is, they MUST be aligned on an 8- octet boundary. 6.1.2. Binding Refresh Request Message The Binding Refresh Request (BRR) message requests a mobile node to update its mobility binding. This message is sent by correspondent nodes according to the rules in Section 9.5.5. When a mobile node receives a packet containing a Binding Refresh Request message it processes the message according to the rules in Section 11.7.4. The Binding Refresh Request message uses the MH Type value 0. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2. The receiver MUST ignore and skip any options which it does not understand. Johnson, et al. Standard Track [Page 34] RFC 3775 Mobility Support in IPv6 June 2004 There MAY be additional information, associated with this Binding Refresh Request message that need not be present in all Binding Refresh Request messages sent. Mobility options allow future extensions to the format of the Binding Refresh Request message to be defined. This specification does not define any options valid for the Binding Refresh Request message. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 0. 6.1.3. Home Test Init Message A mobile node uses the Home Test Init (HoTI) message to initiate the return routability procedure and request a home keygen token from a correspondent node (see Section 11.6.1). The Home Test Init message uses the MH Type value 1. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. This value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Home Init Cookie 64-bit field which contains a random value, the home init cookie. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver Johnson, et al. Standard Track [Page 35] RFC 3775 Mobility Support in IPv6 June 2004 MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Home Test Init message. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 1. This message is tunneled through the home agent when the mobile node is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between the home agent and the mobile node. This protection is indicated by the IPsec security policy database. The protection of Home Test Init messages is unrelated to the requirement to protect regular payload traffic, which MAY use such tunnels as well. 6.1.4. Care-of Test Init Message A mobile node uses the Care-of Test Init (CoTI) message to initiate the return routability procedure and request a care-of keygen token from a correspondent node (see Section 11.6.1). The Care-of Test Init message uses the MH Type value 2. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Care-of Init Cookie 64-bit field which contains a random value, the care-of init cookie. Johnson, et al. Standard Track [Page 36] RFC 3775 Mobility Support in IPv6 June 2004 Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Care-of Test Init message. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 1. 6.1.5. Home Test Message The Home Test (HoT) message is a response to the Home Test Init message, and is sent from the correspondent node to the mobile node (see Section 5.2.5). The Home Test message uses the MH Type value 3. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Nonce Index This field will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update. Home Init Cookie 64-bit field which contains the home init cookie. Johnson, et al. Standard Track [Page 37] RFC 3775 Mobility Support in IPv6 June 2004 Home Keygen Token This field contains the 64 bit home keygen token used in the return routability procedure. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Home Test message. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2. 6.1.6. Care-of Test Message The Care-of Test (CoT) message is a response to the Care-of Test Init message, and is sent from the correspondent node to the mobile node (see Section 11.6.2). The Care-of Test message uses the MH Type value 4. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Care-of Nonce Index This value will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update. Johnson, et al. Standard Track [Page 38] RFC 3775 Mobility Support in IPv6 June 2004 Care-of Init Cookie 64-bit field which contains the care-of init cookie. Care-of Keygen Token This field contains the 64 bit care-of keygen token used in the return routability procedure. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Care-of Test message. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2. 6.1.7. Binding Update Message The Binding Update (BU) message is used by a mobile node to notify other nodes of a new care-of address for itself. Binding Updates are sent as described in Section 11.7.1 and Section 11.7.2. The Binding Update uses the MH Type value 5. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Acknowledge (A) The Acknowledge (A) bit is set by the sending mobile node to request a Binding Acknowledgement (Section 6.1.8) be returned upon receipt of the Binding Update. Johnson, et al. Standard Track [Page 39] RFC 3775 Mobility Support in IPv6 June 2004 Home Registration (H) The Home Registration (H) bit is set by the sending mobile node to request that the receiving node should act as this node's home agent. The destination of the packet carrying this message MUST be that of a router sharing the same subnet prefix as the home address of the mobile node in the binding. Link-Local Address Compatibility (L) The Link-Local Address Compatibility (L) bit is set when the home address reported by the mobile node has the same interface identifier as the mobile node's link-local address. Key Management Mobility Capability (K) If this bit is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) If manual IPsec configuration is used, the bit MUST be cleared. This bit is valid only in Binding Updates sent to the home agent, and MUST be cleared in other Binding Updates. Correspondent nodes MUST ignore this bit. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Sequence # A 16-bit unsigned integer used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. Lifetime 16-bit unsigned integer. The number of time units remaining before the binding MUST be considered expired. A value of zero indicates that the Binding Cache entry for the mobile node MUST be deleted. (In this case the specified care-of address MUST also be set equal to the home address.) One time unit is 4 seconds. Johnson, et al. Standard Track [Page 40] RFC 3775 Mobility Support in IPv6 June 2004 Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2. The receiver MUST ignore and skip any options which it does not understand. The following options are valid in a Binding Update: * Binding Authorization Data option (this option is mandatory in Binding Updates sent to a correspondent node) * Nonce Indices option. * Alternate Care-of Address option If no options are present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1. The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. The care-of address MUST be a unicast routable address. IPv6 Source Address MUST be a topologically correct source address. Binding Updates for a care-of address which is not a unicast routable address MUST be silently discarded. Similarly, the Binding Update MUST be silently discarded if the care-of address appears as a home address in an existing Binding Cache entry, with its current location creating a circular reference back to the home address specified in the Binding Update (possibly through additional entries). The deletion of a binding can be indicated by setting the Lifetime field to 0 and by setting the care-of address equal to the home address. In deletion, the generation of the binding management key depends exclusively on the home keygen token, as explained in Section 5.2.5. (Note that while the senders are required to set both the Lifetime field to 0 and the care-of address equal to the home address, Section 9.5.1 rules for receivers are more liberal, and interpret either condition as a deletion.) Correspondent nodes SHOULD NOT delete the Binding Cache entry before the lifetime expires, if any application hosted by the correspondent node is still likely to require communication with the mobile node. A Binding Cache entry that is de-allocated prematurely might cause subsequent packets to be dropped from the mobile node, if they contain the Home Address destination option. This situation is recoverable, since a Binding Error message is sent to the mobile node Johnson, et al. Standard Track [Page 41] RFC 3775 Mobility Support in IPv6 June 2004 (see Section 6.1.9); however, it causes unnecessary delay in the communications. 6.1.8. Binding Acknowledgement Message The Binding Acknowledgement is used to acknowledge receipt of a Binding Update (Section 6.1.7). This packet is sent as described in Section 9.5.4 and Section 10.3.1. The Binding Acknowledgement has the MH Type value 6. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Management Mobility Capability (K) If this bit is cleared, the protocol used by the home agent for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) Correspondent nodes MUST set the K bit to 0. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Johnson, et al. Standard Track [Page 42] RFC 3775 Mobility Support in IPv6 June 2004 Status 8-bit unsigned integer indicating the disposition of the Binding Update. Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. Values greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following Status values are currently defined: 0 Binding Update accepted 1 Accepted but prefix discovery necessary 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Home registration not supported 132 Not home subnet 133 Not home agent for this mobile node 134 Duplicate Address Detection failed 135 Sequence number out of window 136 Expired home nonce index 137 Expired care-of nonce index 138 Expired nonces 139 Registration type change disallowed Up-to-date values of the Status field are to be specified in the IANA registry of assigned numbers [19]. Sequence # The Sequence Number in the Binding Acknowledgement is copied from the Sequence Number field in the Binding Update. It is used by the mobile node in matching this Binding Acknowledgement with an outstanding Binding Update. Johnson, et al. Standard Track [Page 43] RFC 3775 Mobility Support in IPv6 June 2004 Lifetime The granted lifetime, in time units of 4 seconds, for which this node SHOULD retain the entry for this mobile node in its Binding Cache. The value of this field is undefined if the Status field indicates that the Binding Update was rejected. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2. The receiver MUST ignore and skip any options which it does not understand. There MAY be additional information, associated with this Binding Acknowledgement that need not be present in all Binding Acknowledgements sent. Mobility options allow future extensions to the format of the Binding Acknowledgement to be defined. The following options are valid for the Binding Acknowledgement: * Binding Authorization Data option (this option is mandatory in Binding Acknowledgements sent by a correspondent node, except where otherwise noted in Section 9.5.4) * Binding Refresh Advice option If no options are present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1. 6.1.9. Binding Error Message The Binding Error (BE) message is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding; see Section 9.3.3 for details. Johnson, et al. Standard Track [Page 44] RFC 3775 Mobility Support in IPv6 June 2004 The Binding Error message uses the MH Type value 7. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status 8-bit unsigned integer indicating the reason for this message. The following values are currently defined: 1 Unknown binding for Home Address destination option 2 Unrecognized MH Type value Reserved A 8-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Home Address The home address that was contained in the Home Address destination option. The mobile node uses this information to determine which binding does not exist, in cases where the mobile node has several home addresses. Johnson, et al. Standard Track [Page 45] RFC 3775 Mobility Support in IPv6 June 2004 Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. There MAY be additional information, associated with this Binding Error message that need not be present in all Binding Error messages sent. Mobility options allow future extensions to the format of the format of the Binding Error message to be defined. The encoding and format of defined options are described in Section 6.2. This specification does not define any options valid for the Binding Error message. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2. 6.2. Mobility Options Mobility messages can include zero or more mobility options. This allows optional fields that may not be needed in every use of a particular Mobility Header, as well as future extensions to the format of the messages. Such options are included in the Message Data field of the message itself, after the fixed portion of the message data specified in the message subsections of Section 6.1. The presence of such options will be indicated by the Header Len of the Mobility Header. If included, the Binding Authorization Data option (Section 6.2.7) MUST be the last option and MUST NOT have trailing padding. Otherwise, options can be placed in any order. 6.2.1. Format Mobility options are encoded within the remaining space of the Message Data field of a mobility message, using a type-length-value (TLV) format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Option Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Johnson, et al. Standard Track [Page 46] RFC 3775 Mobility Support in IPv6 June 2004 Option Type 8-bit identifier of the type of mobility option. When processing a Mobility Header containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST quietly ignore and skip over the option, correctly handling any remaining options in the message. Option Length 8-bit unsigned integer, representing the length in octets of the mobility option, not including the Option Type and Option Length fields. Option Data A variable length field that contains data specific to the option. The following subsections specify the Option types which are currently defined for use in the Mobility Header. Implementations MUST silently ignore any mobility options that they do not understand. Mobility options may have alignment requirements. Following the convention in IPv6, these options are aligned in a packet so that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8) [11]. 6.2.2. Pad1 The Pad1 option does not have any alignment requirements. Its format is as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0 | +-+-+-+-+-+-+-+-+ NOTE! the format of the Pad1 option is a special case - it has neither Option Length nor Option Data fields. Johnson, et al. Standard Track [Page 47] RFC 3775 Mobility Support in IPv6 June 2004 The Pad1 option is used to insert one octet of padding in the Mobility Options area of a Mobility Header. If more than one octet of padding is required, the PadN option, described next, should be used rather than multiple Pad1 options. 6.2.3. PadN The PadN option does not have any alignment requirements. Its format is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Type = 1 | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - The PadN option is used to insert two or more octets of padding in the Mobility Options area of a mobility message. For N octets of padding, the Option Length field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. PadN Option data MUST be ignored by the receiver. 6.2.4. Binding Refresh Advice The Binding Refresh Advice option has an alignment requirement of 2n. Its format is 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 = 2 | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Binding Refresh Advice option is only valid in the Binding Acknowledgement, and only on Binding Acknowledgements sent from the mobile node's home agent in reply to a home registration. The Refresh Interval is measured in units of four seconds, and indicates remaining time until the mobile node SHOULD send a new home registration to the home agent. The Refresh Interval MUST be set to indicate a smaller time interval than the Lifetime value of the Binding Acknowledgement. Johnson, et al. Standard Track [Page 48] RFC 3775 Mobility Support in IPv6 June 2004 6.2.5. Alternate Care-of Address The Alternate Care-of Address option has an alignment requirement of 8n+6. Its format is 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 = 3 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Normally, a Binding Update specifies the desired care-of address in the Source Address field of the IPv6 header. However, this is not possible in some cases, such as when the mobile node wishes to indicate a care-of address which it cannot use as a topologically correct source address (Section 6.1.7 and Section 11.7.2) or when the used security mechanism does not protect the IPv6 header (Section 11.7.1). The Alternate Care-of Address option is provided for these situations. This option is valid only in Binding Update. The Alternate Care-of Address field contains an address to use as the care-of address for the binding, rather than using the Source Address of the packet as the care-of address. 6.2.6. Nonce Indices The Nonce Indices option has an alignment requirement of 2n. Its format is 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 = 4 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Johnson, et al. Standard Track [Page 49] RFC 3775 Mobility Support in IPv6 June 2004 The Nonce Indices option is valid only in the Binding Update message sent to a correspondent node, and only when present together with a Binding Authorization Data option. When the correspondent node authorizes the Binding Update, it needs to produce home and care-of keygen tokens from its stored random nonce values. The Home Nonce Index field tells the correspondent node which nonce value to use when producing the home keygen token. The Care-of Nonce Index field is ignored in requests to delete a binding. Otherwise, it tells the correspondent node which nonce value to use when producing the care-of keygen token. 6.2.7. Binding Authorization Data The Binding Authorization Data option does not have alignment requirements as such. However, since this option must be the last mobility option, an implicit alignment requirement is 8n + 2. The format of this option is 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 = 5 | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Binding Authorization Data option is valid in the Binding Update and Binding Acknowledgement. The Option Length field contains the length of the authenticator in octets. The Authenticator field contains a cryptographic value which can be used to determine that the message in question comes from the right authority. Rules for calculating this value depends on the used authorization procedure. Johnson, et al. Standard Track [Page 50] RFC 3775 Mobility Support in IPv6 June 2004 For the return routability procedure, this option can appear in the Binding Update and Binding Acknowledgements. Rules for calculating the Authenticator value are the following: Mobility Data = care-of address | correspondent | MH Data Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) Where | denotes concatenation. "Care-of address" is the care-of address which will be registered for the mobile node if the Binding Update succeeds, or the home address of the mobile node if this option is used in de-registration. Note also that this address might be different from the source address of the Binding Update message, if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero. The "correspondent" is the IPv6 address of the correspondent node. Note that, if the message is sent to a destination which is itself mobile, the "correspondent" address may not be the address found in the Destination Address field of the IPv6 header; instead the home address from the type 2 Routing header should be used. "MH Data" is the content of the Mobility Header, excluding the Authenticator field itself. The Authenticator value is calculated as if the Checksum field in the Mobility Header was zero. The Checksum in the transmitted packet is still calculated in the usual manner, with the calculated Authenticator being a part of the packet protected by the Checksum. Kbm is the binding management key, which is typically created using nonces provided by the correspondent node (see Section 9.4). Note that while the contents of a potential Home Address destination option are not covered in this formula, the rules for the calculation of the Kbm do take the home address in account. This ensures that the MAC will be different for different home addresses. The first 96 bits from the MAC result are used as the Authenticator field. 6.3. Home Address Option The Home Address option is carried by the Destination Option extension header (Next Header value = 60). It is used in a packet sent by a mobile node while away from home, to inform the recipient of the mobile node's home address. Johnson, et al. Standard Track [Page 51] RFC 3775 Mobility Support in IPv6 June 2004 The Home Address option is encoded in type-length-value (TLV) format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 201 = 0xC9 Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Home Address The home address of the mobile node sending the packet. This address MUST be a unicast routable address. The alignment requirement [11] for the Home Address option is 8n+6. The three highest-order bits of the Option Type field are encoded to indicate specific processing of the option [11]; for the Home Address option, these three bits are set to 110. This indicates the following processing requirements: o Any IPv6 node that does not recognize the Option Type must discard the packet, and if the packet's Destination Address was not a multicast address, return an ICMP Parameter Problem, Code 2, message to the packet's Source Address. The Pointer field in the ICMP message SHOULD point at the Option Type field. Otherwise, for multicast addresses, the ICMP message MUST NOT be sent. o The data within the option cannot change en route to the packet's final destination. Johnson, et al. Standard Track [Page 52] RFC 3775 Mobility Support in IPv6 June 2004 The Home Address option MUST be placed as follows: o After the routing header, if that header is present o Before the Fragment Header, if that header is present o Before the AH Header or ESP Header, if either one of those headers are present For each IPv6 packet header, the Home Address Option MUST NOT appear more than once. However, an encapsulated packet [15] MAY contain a separate Home Address option associated with each encapsulating IP header. The inclusion of a Home Address destination option in a packet affects the receiving node's processing of only this single packet. No state is created or modified in the receiving node as a result of receiving a Home Address option in a packet. In particular, the presence of a Home Address option in a received packet MUST NOT alter the contents of the receiver's Binding Cache and MUST NOT cause any changes in the routing of subsequent packets sent by this receiving node. 6.4. Type 2 Routing Header Mobile IPv6 defines a new routing header variant, the type 2 routing header, to allow the packet to be routed directly from a correspondent to the mobile node's care-of address. The mobile node's care-of address is inserted into the IPv6 Destination Address field. Once the packet arrives at the care-of address, the mobile node retrieves its home address from the routing header, and this is used as the final destination address for the packet. The new routing header uses a different type than defined for "regular" IPv6 source routing, enabling firewalls to apply different rules to source routed packets than to Mobile IPv6. This routing header type (type 2) is restricted to carry only one IPv6 address. All IPv6 nodes which process this routing header MUST verify that the address contained within is the node's own home address in order to prevent packets from being forwarded outside the node. The IP address contained in the routing header, since it is the mobile node's home address, MUST be a unicast routable address. Furthermore, if the scope of the home address is smaller than the scope of the care-of address, the mobile node MUST discard the packet (see Section 4.6). Johnson, et al. Standard Track [Page 53] RFC 3775 Mobility Support in IPv6 June 2004 6.4.1. Format The type 2 routing header has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the routing header. Uses the same values as the IPv6 Next Header field [11]. Hdr Ext Len 2 (8-bit unsigned integer); length of the routing header in 8- octet units, not including the first 8 octets. Routing Type 2 (8-bit unsigned integer). Segments Left 1 (8-bit unsigned integer). Reserved 32-bit reserved field. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Home Address The Home Address of the destination Mobile Node. Johnson, et al. Standard Track [Page 54] RFC 3775 Mobility Support in IPv6 June 2004 For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments Left value describes the number of route segments remaining; i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. Segments Left MUST be 1. The ordering rules for extension headers in an IPv6 packet are described in Section 4.1 of RFC 2460 [11]. The type 2 routing header defined for Mobile IPv6 follows the same ordering as other routing headers. If both a type 0 and a type 2 routing header are present, the type 2 routing header should follow the other routing header. A packet containing such nested encapsulation should be created as if the inner (type 2) routing header was constructed first and then treated as an original packet by the outer (type 0) routing header construction process. In addition, the general procedures defined by IPv6 for routing headers suggest that a received routing header MAY be automatically "reversed" to construct a routing header for use in any response packets sent by upper-layer protocols, if the received packet is authenticated [6]. This MUST NOT be done automatically for type 2 routing headers. 6.5. ICMP Home Agent Address Discovery Request Message The ICMP Home Agent Address Discovery Request message is used by a mobile node to initiate the dynamic home agent address discovery mechanism, as described in Section 11.4.1. The mobile node sends the Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its own home subnet prefix. (Note that the currently defined anycast addresses may not work with all prefix lengths other than those defined in RFC 2373 [3, 35].) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 144 Code 0 Johnson, et al. Standard Track [Page 55] RFC 3775 Mobility Support in IPv6 June 2004 Checksum The ICMP checksum [14]. Identifier An identifier to aid in matching Home Agent Address Discovery Reply messages to this Home Agent Address Discovery Request message. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. The Source Address of the Home Agent Address Discovery Request message packet is typically one of the mobile node's current care-of addresses. At the time of performing this dynamic home agent address discovery procedure, it is likely that the mobile node is not registered with any home agent. Therefore, neither the nature of the address nor the identity of the mobile node can be established at this time. The home agent MU