IETF Mobile IP Working Group David B. Johnson INTERNET-DRAFT Rice University Charles E. Perkins Nokia Research Center Jari Arkko Ericsson 1 June 2002 Mobility Support in IPv6 Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents, valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document specifies the operation the IPv6 Internet with mobile computers. 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, MUST support communications with mobile nodes. Johnson, Perkins, Arkko Expires 1 December 2002 [Page i] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Comparison with Mobile IP for IPv4 2 3. Terminology 3 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 4 4. Overview of Mobile IPv6 7 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 4.2. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 9 4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 10 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 10 4.5. Conceptual Data Structures . . . . . . . . . . . . . . . 11 5. Overview of Mobile IPv6 Security 12 5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 12 5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 12 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . 13 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . 13 5.2.3. Cookies . . . . . . . . . . . . . . . . . . . . . 14 5.2.4. Cryptographic Functions . . . . . . . . . . . . . 14 5.2.5. Return Routability Procedure . . . . . . . . . . 14 5.2.6. Applying Return Routability for Correspondent Bindings . . . . . . . . . . . . . . . . . 18 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . 20 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . 20 5.3. Payload Packets . . . . . . . . . . . . . . . . . . . . . 21 6. New IPv6 Protocols, Message Types, and Destination Option 21 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 21 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 22 6.1.2. Binding Refresh Request (BRR) Message . . . . . . 23 6.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 24 6.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 26 6.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 27 6.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 28 6.1.7. Binding Update (BU) Message . . . . . . . . . . . 29 6.1.8. Binding Acknowledgement (BA) Message . . . . . . 32 6.1.9. Binding Error (BE) Message . . . . . . . . . . . 34 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 35 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 35 Johnson, Perkins, Arkko Expires 1 December 2002 [Page ii] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 36 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 37 6.2.4. Unique Identifier . . . . . . . . . . . . . . . . 37 6.2.5. Alternate Care-of Address . . . . . . . . . . . . 38 6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 38 6.2.7. Binding Authorization Data . . . . . . . . . . . 39 6.2.8. Binding Refresh Advice . . . . . . . . . . . . . 39 6.3. Home Address Destination Option . . . . . . . . . . . . . 40 6.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 42 6.4.1. Routing Header Packet format . . . . . . . . . . 42 6.5. ICMP Home Agent Address Discovery Request Message . . . . 43 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 45 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 47 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 49 7. Modifications to IPv6 Neighbor Discovery 51 7.1. Modified Router Advertisement Message Format . . . . . . 51 7.2. Modified Prefix Information Option Format . . . . . . . . 52 7.3. New Advertisement Interval Option Format . . . . . . . . 54 7.4. New Home Agent Information Option Format . . . . . . . . 55 7.5. Changes to Sending Router Advertisements . . . . . . . . 57 7.6. Changes to Sending Router Solicitations . . . . . . . . . 58 8. Requirements for Types of IPv6 Nodes 59 8.1. General Requirements for All IPv6 Nodes . . . . . . . . . 59 8.2. Route Optimization Requirements for All IPv6 Nodes . . . 59 8.3. Requirements for All IPv6 Routers . . . . . . . . . . . . 60 8.4. Requirements for IPv6 Home Agents . . . . . . . . . . . . 61 8.5. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 62 9. Correspondent Node Operation 63 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 63 9.2. Receiving Packets from a Mobile Node . . . . . . . . . . 64 9.2.1. Processing Mobility Header (MH) Messages . . . . 64 9.2.2. Receiving Packets with Home Address Destination Option . . . . . . . . . . . . . . . . . . 65 9.3. Return Routability Procedure . . . . . . . . . . . . . . 66 9.3.1. Receiving Home Test Init Messages . . . . . . . . 66 9.3.2. Receiving Care-of Test Init Messages . . . . . . 66 9.3.3. Sending Home Test Messages . . . . . . . . . . . 67 9.3.4. Sending Care-of Test Messages . . . . . . . . . . 67 9.4. Processing Bindings . . . . . . . . . . . . . . . . . . . 67 9.4.1. Receiving Binding Updates . . . . . . . . . . . . 67 9.4.2. Requests to Cache a Binding . . . . . . . . . . . 69 9.4.3. Requests to Delete a Binding . . . . . . . . . . 69 9.4.4. Sending Binding Acknowledgements . . . . . . . . 70 9.4.5. Sending Binding Refresh Requests . . . . . . . . 71 9.4.6. Sending Binding Error Messages . . . . . . . . . 71 9.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 71 9.6. Sending Packets to a Mobile Node . . . . . . . . . . . . 72 9.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 73 Johnson, Perkins, Arkko Expires 1 December 2002 [Page iii] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 10. Home Agent Operation 74 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 74 10.2. Primary Care-of Address Registration . . . . . . . . . . 75 10.3. Primary Care-of Address De-Registration . . . . . . . . . 79 10.4. Intercepting Packets for a Mobile Node . . . . . . . . . 80 10.5. Tunneling Intercepted Packets to a Mobile Node . . . . . 81 10.6. Handling Reverse Tunneled Packets from a Mobile Node . . 83 10.7. Protecting Return Routability Packets . . . . . . . . . . 83 10.8. Receiving Router Advertisement Messages . . . . . . . . . 84 10.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 85 10.9.1. Aggregate List of Home Network Prefixes . . . . . 87 10.9.2. Scheduling Prefix Deliveries to the Mobile Node . 89 10.9.3. Sending Advertisements to the Mobile Node . . . . 90 10.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 91 11. Mobile Node Operation 91 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 91 11.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 93 11.2.1. Sending Packets While Away from Home . . . . . . 93 11.2.2. Interaction with Outbound IPsec Processing . . . 96 11.2.3. Receiving Packets While Away from Home . . . . . 97 11.2.4. Routing Multicast Packets . . . . . . . . . . . . 99 11.3. Home Agent and Prefix Management . . . . . . . . . . . . 100 11.3.1. Receiving Local Router Advertisement Messages . . 100 11.3.2. Dynamic Home Agent Address Discovery . . . . . . 101 11.3.3. Sending Mobile Prefix Solicitations . . . . . . . 102 11.3.4. Receiving Mobile Prefix Advertisements . . . . . 103 11.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . 104 11.4.1. Movement Detection . . . . . . . . . . . . . . . 104 11.4.2. Forming New Care-of Addresses . . . . . . . . . . 107 11.4.3. Using Multiple Care-of Addresses . . . . . . . . 108 11.5. Return Routability Procedure . . . . . . . . . . . . . . 109 11.5.1. Sending Home and Care-of Test Init Messages . . . 109 11.5.2. Receiving Return Routability Messages . . . . . . 109 11.5.3. Retransmitting in the Return Routability Procedure 111 11.5.4. Rate Limiting for Return Routability Procedure . 111 11.6. Processing Bindings . . . . . . . . . . . . . . . . . . . 111 11.6.1. Sending Binding Updates to the Home Agent . . . . 111 11.6.2. Correspondent Binding Procedure . . . . . . . . . 114 11.6.3. Receiving Binding Acknowledgements . . . . . . . 117 11.6.4. Receiving Binding Refresh Requests . . . . . . . 118 11.6.5. Receiving Binding Error Messages . . . . . . . . 119 11.6.6. Forwarding from a Previous Care-of Address . . . 120 11.6.7. Returning Home . . . . . . . . . . . . . . . . . 121 11.6.8. Retransmitting Binding Updates . . . . . . . . . 123 11.6.9. Rate Limiting Binding Updates . . . . . . . . . . 124 11.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 124 12. Protocol Constants 125 13. IANA Considerations 126 Johnson, Perkins, Arkko Expires 1 December 2002 [Page iv] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 14. Security Considerations 127 14.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 127 14.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 129 14.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 130 14.4. Binding Updates to Correspondent Nodes . . . . . . . . . 132 14.4.1. Overview . . . . . . . . . . . . . . . . . . . . 132 14.4.2. Offered Protection . . . . . . . . . . . . . . . 132 14.4.3. Comparison to Regular IPv6 Communications . . . . 133 14.4.4. Return Routability Replays . . . . . . . . . . . 135 14.4.5. Return Routability Denial-of-Service . . . . . . 135 14.5. Tunneling via the Home Agent . . . . . . . . . . . . . . 136 14.6. Home Address Destination Option . . . . . . . . . . . . . 137 14.7. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 138 Acknowledgements 138 References 140 A. State Machine for the Correspondent Binding Procedure 142 A.1. Main State Machine . . . . . . . . . . . . . . . . . . . 143 A.2. Return Routability Procedure . . . . . . . . . . . . . . 149 B. Changes from Previous Version of the Draft 153 C. Future Extensions 154 C.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 154 C.2. Triangular Routing and Unverified Home Addresses . . . . 154 C.3. New Authorization Methods beyond Return Routability . . . 155 C.4. Security and Dynamically Generated Home Addresses . . . . 155 C.5. Remote Home Address Configuration . . . . . . . . . . . . 155 Chairs' Addresses 157 Authors' Addresses 157 Johnson, Perkins, Arkko Expires 1 December 2002 [Page v] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 1. Introduction This document specifies how the IPv6 Internet operates with mobile computers. 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 IP address. A mobile node is always addressable by its "home address", an IP address assigned to the mobile node within its home subnet prefix on its home link. 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 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, reestablishing link-layer connectivity to the node in each new location. Mobile IP 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: - Handling links with partial reachability, or unidirectional connectivity, such as are often found in wireless networks (but see Section 11.4.1). - Access control on a link being visited by a mobile node. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 1] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 - Local or hierarchical forms of mobility management (similar to many current link-layer mobility management solutions). - Assistance for adaptive applications - Mobile routers - Service Discovery - 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) represents a natural combination of the experiences gained from the development of Mobile IP support in IPv4 (Mobile IPv4) [20, 21, 22], together with the opportunities provided by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, but is integrated into IP and provides many improvements. This section summarizes the major differences between Mobile IPv4 and Mobile IPv6: - There is no longer any need to deploy special routers as "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, mobile nodes make use of IPv6 features, to operate in any location without any special support required from the local router. - Support for what is known in Mobile IPv4 as "route optimization" [23] is now built in as a fundamental part of the protocol, rather than being added on as an optional set of extensions that may not be supported by all nodes as in Mobile IPv4. - 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. - Support is also integrated into Mobile IPv6 for allowing route optimization to coexist efficiently with routers that perform "ingress filtering" [24]. Both the current care-of address and the home address can be carried in packets, allowing packets to pass normally through ingress filtering routers. - In Mobile IPv6, the mobile node does not have to tunnel multicast packets to its home agent. The inclusion of the home address in packets is compatible with multicast routing that is based in part on the packet's Source Address. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 2] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 - The movement detection mechanism in Mobile IPv6 provides bidirectional confirmation of a mobile node's ability to communicate with its default router in its current location. - 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. - 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. - The use of IPv6 encapsulation (and the Routing header) removes the need in Mobile IPv6 to manage "tunnel soft state". - 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 RFC 2119 [2]. 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. 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. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 3] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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. 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 A security object shared between two nodes which includes the data mutually agreed on for operation of some cryptographic algorithm (typically including a key). security policy database A database of rules that describe what security associations should be applied for different kinds of packets. destination option Destination options are carried by the IPv6 Destination Options extension header. Mobile IPv6 defines one new destination option, the Home Address destination option. 3.2. Mobile IPv6 Terms home address An IP 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. 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 Johnson, Perkins, Arkko Expires 1 December 2002 [Page 4] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 node is not currently attached to its home link, the mobile node is said to be "away from home". 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 An IP 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 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. binding procedure A binding procedure is initiated by the mobile node to inform either a correspondent node or the mobile node's home agent of the current binding of the mobile node. binding authorization Binding procedure 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 binding procedures by the use of a cryptographic cookie exchange. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 5] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 correspondent binding procedure A return routability procedure followed by a binding procedure, run between the mobile node and a correspondent node. home binding procedure A binding procedure 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 cookies related to the return routability procedure. The nonces are not specific to a mobile node, and are kept secret within the correspondent node, only used as one input in the creation of the cookies. cookie Cookies are numbers that are used by mobile nodes and correspondent nodes in the return routability procedure. care-of cookie A cookie sent directly to the mobile node's claimed care-of address from the correspondent node. home cookie A cookie sent to the mobile node's claimed home address from the correspondent node. mobile cookie A cookie sent to the correspondent node from the mobile node, and later returned to the mobile node. Mobile cookies are produced randomly. There are two kinds of mobile cookies: the HoT cookie and the CoT cookie. CoT cookie A cookie sent by the mobile node to the the correspondent node in the CoTI message, to be returned to the mobile node in the CoT message. HoT cookie A cookie sent by the mobile node to the the correspondent node in the HoTI message, to be returned to the mobile node in the HoT message. nonce index The mobile node uses a particular set of cookies in the return routability procedure. The cookies have been produced using a particular set of nonces. A nonce index is used to indicate which nonces have been used, without revealing the nonces themselves. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 6] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 binding key a key used for authenticating binding cache management messages. binding security association a security association established specifically for the purpose of producing and verifying authentication data passed with a Binding Authorization Data option. 4. Overview of Mobile IPv6 4.1. Basic Operation A mobile node is always addressable at its home address, whether it is currently attached to its home link or is away from home. While a mobile node is at home, packets addressed to its home address are routed to it using conventional Internet routing mechanisms in the same way as if the node were stationary. The subnet prefix of a mobile node's home address is one of the subnet prefixes of the mobile node's home link. Packets addressed to the mobile node will therefore be routed to its home link. 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 while visiting a particular foreign link. The subnet prefix of a mobile node's care-of address is one of the subnet prefixes on the foreign link. 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 association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. A mobile node typically acquires its care-of address through stateless [13] or stateful (e.g., DHCPv6 [25]) Address Autoconfiguration, according to the methods of IPv6 Neighbor Discovery [12]. Other methods of acquiring a care-of address are also possible, but are beyond the scope of this document. The operation of the mobile node is specified in Section 11. While away from home, a mobile node registers one of its care-of addresses 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 care-of address associated with this binding registration is known as the mobile node's "primary care-of address". The mobile node's home agent thereafter uses proxy Neighbor Discovery to intercept any IPv6 packets addressed to the mobile node's home address (or home Johnson, Perkins, Arkko Expires 1 December 2002 [Page 7] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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], with the outer IPv6 header addressed to the mobile node's primary care-of address. 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. The operation of the correspondent node is specified in Section 9. Mobile nodes can inform the correspondent nodes of the current location of the mobile node. This happens through the correspondent binding procedure. As a part of this procedure, a return routability test is performed in order to authorize the establishment of the binding. This is specified in Sections 5.2.5 and 5.2.6. When sending a packet to any IPv6 destination, a 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. If, instead, the sending node has no cached binding for this destination address, the node sends the packet normally (with no Routing header), and the packet is subsequently intercepted and tunneled by the mobile node's home agent as described above. When a mobile node receives a packet tunneled to it in this manner, it can use this as an indication that the correspondent node has no binding for the mobile node. The mobile node can then establish a binding with the correspondent node. It is expected that correspondent nodes usually will route packets directly to the mobile node's care-of address, so that the home agent is rarely involved with packet transmission to the mobile node. This is important for scalability and reliability, and for minimizing overall network load. Routing packets directly to the mobile node's care-of address 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, the home link, or intervening networks leading to or from the home link is reduced, since these nodes and links are not involved in the delivery of most packets to the mobile node. Mobile IPv6 defines a new IPv6 destination option. When a mobile node sends a packet while away from home, it could generally use a tunnel via the home agent to send this packet. However, if the correspondent node in question has a binding for this mobile node, the mobile node can deliver packets directly to the correspondent node. The mobile node sets the Source Address in the packet's IPv6 header to one of its current care-of addresses, and include a "Home Address" destination option in the packet, giving the mobile node's home address. By also including the Home Address destination option in each packet, the sending mobile node can communicate its home address to the correspondent node receiving this packet. This makes Johnson, Perkins, Arkko Expires 1 December 2002 [Page 8] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 the use of the care-of address transparent above the Mobile IPv6 support level (e.g., at the transport layer). It is possible that while a mobile node is away from home, some nodes on its home link may be reconfigured. The router that was operating as the mobile node's home agent can be replaced by a different router serving the same role. In this case, the mobile node may not know the IP address of its own home agent. Mobile IPv6 provides a mechanism, known as "dynamic home agent address discovery", that allows a mobile node to dynamically discover the IP address of a home agent on its home link with which it may register its (primary) care-of address while away from home. The mobile node sends an ICMP "Home Agent Address Discovery Request" message to the "Mobile IPv6 Home-Agents" anycast address for its own home subnet prefix [16] and thus reaches one of the routers on its home link currently operating as a home agent. This home agent then returns an ICMP "Home Agent Address Discovery Reply" message to the mobile node, including a list of home agents on the home link. This procedure is specified in Sections 10.9 and 11.3.2. When a mobile node arrives to a new link and allocates a new care-of address, it is desirable for packets arriving at the previous care-of address to still reach the mobile node. The mobile node may still accept packets at the previous address, if it is still attached to the previous link as well as the new one. This is discussed in Section 11.4.3. If the mobile node is no longer attached to the previous link, procedures described in Section 11.6.6 may be used to establish temporary tunneling from the previous link. 4.2. New IPv6 Protocols Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header (see Section 6.1). This Header is used to carry the following messages: Home Test Init Home Test Care-of Test Init Care-of Test These four messages are used to initiate 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. The format of the messages are defined in Sections 6.1.3 through 6.1.6. Binding Update A Binding Update message is used by a mobile node to notify a correspondent node or the mobile node's home agent of its Johnson, Perkins, Arkko Expires 1 December 2002 [Page 9] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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". The Binding Update message is described in detail in Section 6.1.7. Binding Acknowledgement A Binding Acknowledgement message is used to acknowledge receipt of a Binding Update, if an acknowledgement was requested in the Binding Update. The Binding Acknowledgement message is described in detail in Section 6.1.8. Binding Refresh Request A Binding Refresh Request message is used 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. The Binding Refresh Request message is described in detail in Section 6.1.2. Binding Error The Binding Error 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. This message is described in detail in Section 6.1.9. 4.3. New IPv6 Destination Options 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 discussed in general in Section 4.1, the following two new ICMP message types are used for home agent address discovery: - Home Agent Address Discovery Request, described in Section 6.5. - Home Agent Address Discovery Reply, described in Section 6.6. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 10] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 The next two message types are used for network renumbering and address configuration on the mobile node, as described in Section 10.9.1: - Mobile Prefix Solicitation, described in Section 6.7. - Mobile Prefix Advertisement, described in Section Section 10.9.3. 4.5. Conceptual Data Structures This document describes the Mobile IPv6 protocol in terms of the following three conceptual data structures: Binding Cache A cache, maintained by each IPv6 node, of bindings for other nodes. A separate Binding Cache is maintained by each IPv6 node for each of its IPv6 addresses. When sending a packet, the Binding Cache is searched before the Neighbor Discovery conceptual Destination Cache [12]. The Binding Cache for any one of a node's IPv6 addresses may contain at most one entry for each mobile node home address. The contents of all of a node's Binding Cache entries are cleared when it reboots. Binding Cache entries are marked either as "home registration" entries or "correspondent registration" entries. Home registration entries are deleted when its binding lifetime expires, while other entries may be replaced at any time through a local cache replacement policy. Binding Update List A list, maintained by each mobile node, recording information for each Binding Update sent by this mobile node, for which the Lifetime sent in that Binding Update has not yet expired. The Binding Update List includes all bindings sent by the mobile node: those to correspondent nodes, those to the mobile node's home agent, and those to a home agent on the link on which the mobile node's previous care-of address is located. Home Agents List A list, maintained by each home agent and each mobile node, recording information about each home agent from which this node has recently received a Router Advertisement in which the Home Agent (H) bit is set. This list is similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [12]. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 11] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Each home agent maintains a separate Home Agents List for each link on which it is serving as a home agent; this list is used by a home agent in the dynamic home agent address discovery mechanism. Each mobile node, while away from home, also maintains a Home Agents List, to enable it to notify a home agent on its previous link when it moves to a new link. 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, and the protection of tunnels, home address information, and routing instructions in data packets. 5.1. Binding Updates to Home Agents Signaling between the mobile node and the home agent requires message integrity, correct ordering and replay protection. The mobile node and the home agent must have an security association to protect this signaling. Authentication Header (AH) or Encapsulating Security Payload (ESP) can be used for integrity protection. For ESP we require that a non-null authentication algorithm is applied. Mobile IPv6 provides its own ordering mechanism inside the Binding Update and Acknowledgement messages. A sequence number field is used, as described in Section 6.1.7. In order to protect messages exchanged between the mobile node and the home agent with IPsec, appropriate security policy database entries must be created. We need to avoid the possibility that a mobile node could use its security association to send a Binding Update on behalf of another mobile node using the same home agent. In order to do this, the security policy database entries MUST unequivocally identify a single SA for any given home address and home agent. In order for the home address of the mobile node to be visible when the policy check is made, the mobile node MUST use the Home Address destination option in Binding Updates sent to the home agent. 5.2. Binding Updates to Correspondent Nodes Binding Updates to correspondent nodes can be protected by using data exchanged during the return routability procedure. We will first discuss a number of preliminary concepts such as node keys, nonces, and cookies and the cryptographic functions used. Section 5.2.5 outlines the basic return routability procedure. Section 5.2.6 shows Johnson, Perkins, Arkko Expires 1 December 2002 [Page 12] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 how the results of this procedure are used to authorize a Binding Update to a correspondent node. Finally, Sections 5.2.7 and 5.2.8 discuss some additional issues. 5.2.1. Node Keys Each correspondent node has a secret key, Kcn. The correspondent node uses this key to verify that the cookies it receives in messages are those which it has created itself. This key does not need to be shared with any other entity. A correspondent node can generate a fresh Kcn each time that it boots to avoid the need for secure persistent storage for Kcn. Kcn can be either a fixed value or regularly updated. Procedures for updating Kcn are discussed later in Section 5.2.7. Kcn consists of 20 octets. 5.2.2. Nonces Each correspondent node also generates nonces at regular intervals, for example every few minutes. 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, so that it does not need to generate and store a new nonce when a new mobile contacts it. Each nonce is identified by a nonce index. Nonce indices are 16-bit values that are e.g. incremented each time a new nonce is created. 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 cookie. Correspondent nodes keep both the current nonce and a small set of old nonces. Older values can be discarded, and messages using them will be rejected as replays. The specific nonce index values can not 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. Nonce is an octet string of any length. The recommended length is 64-bit. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 13] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 5.2.3. Cookies Three different types of cookies are used in the protocol: - Two mobile cookies are sent to the correspondent node from the mobile node, and later returned to the mobile node. The mobile cookies are produced randomly, and used to verify that the response matches the request, and to ensure that parties who have not seen the request can not spoof responses. One of the mobile cookies is sent in the HoTI message, and returned in the HoT message. This is called the HoT cookie. The other mobile cookie is sent in the CoTI message, and returned in the CoT message. This is called the CoT cookie. - A home cookie sent to the mobile node from the correspondent node via the home agent. Home cookies are produced cryptographically from nonces. - A care-of cookie is similar to a home cookie, but sent directly to the mobile node from the correspondent node. A newly generated random number is typically used for each request that carries a mobile cookie. Home and care-of cookies are produced by the correspondent node, and they are based on the currently active secret keys and nonces of the correspondent node as well as the home or care-of address. Such a cookie is valid as long as both the secret key and the nonce used to create it are valid. 5.2.4. Cryptographic Functions MAC_K(m) denotes a Message Authentication Code computed on message m with key K. In this specification, HMAC SHA1 function [26, 19] is used to compute these codes. Hash(m) denotes a hash of message m. In this specification, the function used to compute the hash is SHA1 [19]. 5.2.5. Return Routability Procedure The return routability signaling happens as follows: Mobile node Home agent Correspondent node | | | 1a. | | Home Test Init(HoTI) | | Src = home address, | | Dst = correspondent | | Johnson, Perkins, Arkko Expires 1 December 2002 [Page 14] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 | Parameters: | | | - HoT cookie | | |------------------------->|------------------------->| | | | | | | 1b. | | Care-of Test Init(CoTI) | | Src = care-of address | | Dst = correspondent | | Parameters: | | - CoT cookie | |---------------------------------------------------->| | | | 2a. | | Home Test (HoT) | | Src = correspondent, | | Dst = home address | | Parameters: | | - HoT cookie | | | - home cookie | | | - home nonce index | |<-------------------------|<-------------------------| | | | | | | 2b. | | Care-of Test(CoT) | | Src = correspondent, | | Dst = care-of address | | Parameters: | | - CoT cookie | | - care-of cookie | | - care-of nonce index | |<----------------------------------------------------| | | The Home and Care-of Test Init messages are sent at the same time. The correspondent node returns the Home and Care-of Test messages as quickly as possible, and perhaps nearly simultaneously, requiring very little processing. Those four messages form the return routability procedure. Due to the nearly simultaneous message delivery, the return routability procedure completes in about roundtrip between the mobile node and the correspondent. 1a. Home Test Init A mobile node sends a Home Test Init message to the correspondent node to acquire the home cookie. The contents of the message can be summarized as follows: Src = home address Dst = correspondent Johnson, Perkins, Arkko Expires 1 December 2002 [Page 15] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Parameters: - HoT cookie This message conveys the mobile node's home address to the correspondent node. The mobile node also sends along a 64 bit HoT cookie that the correspondent node must return later. The Home Test Init message is reverse tunneled through the home agent. 1b. Care-of Test Init The mobile node sends a Care-of Test Init message to the correspondent node to acquire the care-of cookie. The contents of this message can be summarized as follows: Src = care-of address Dst = correspondent Parameters: - CoT cookie The second message conveys the mobile node's care-of address to the correspondent node. The mobile node also sends along a 64 bit CoT cookie that the correspondent node must return later. The Care-of Test Init message is sent directly to the correspondent node. 2a. Home Test This message is sent in response to a Home Test Init message. The contents of the message are: Src = correspondent Dst = home address Parameters: - HoT cookie - home cookie - home nonce index When the correspondent node receives the Home Test Init message, it generates a 64-bit home cookie as follows: home cookie = First64(MAC_Kcn(home address | nonce)) The home cookie is formed from the first 64 bits of the MAC result. The message is sent to the mobile node via the home agent; the protocol relies on the assumption that the route between the home agent and the mobile node is secure. The home cookie also acts as a challenge to test that the mobile can receive messages sent to its home address. Kcn is used in the production of home cookie in order to allow the correspondent node to verify that it generated the home and care-of cookies, Johnson, Perkins, Arkko Expires 1 December 2002 [Page 16] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 without forcing the correspondent node to remember a list of all cookies it has handed out. The HoT 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 cookie. 2b. Care-of Test This message is sent in response to a Care-of Test Init message. The contents of the message are: Src = correspondent Dst = care-of address Parameters: - CoT cookie - care-of cookie - care-of nonce index The correspondent node also sends a challenge to the mobile's care-of address. When the correspondent node receives the Care-of Test Init message, it generates a 64-bit care-of cookie as follows: care-of cookie = First64(MAC_Kcn(care-of address | nonce)) The cookie is formed from the first 64 bits of the MAC result. The cookie is sent directly to the mobile node at its care-of address. The CoT cookie from the from CoTI message is returne 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 cookie. The home and care-of nonce indices are often the same 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, the mobile node has the means to prove its authority to send a Binding Update to the correspondent node. The mobile node hashes together the challenges to form a 16 octet session key Kbu: Kbu = Hash(home cookie | care-of cookie) 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 is unaware of the session Johnson, Perkins, Arkko Expires 1 December 2002 [Page 17] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 key Kbu, though it can recreate Kbu if it is presented the right addresses and nonce indices. 5.2.6. Applying Return Routability for Correspondent Bindings After the above procedure has completed, the mobile node can supply a Binding Update to the correspondent node. An overview of the binding procedure is shown below. Mobile Node Correspondent node | | | 1. Binding Update | | Src = care-of address, Dst = correspondent | | Parameters: | | - home address | | - a MAC | | - home nonce index | | - care-of nonce index | | - sequence number | | - ... | |---------------------------------------------------->| | | | 2. Binding Acknowledgement | | (if requested) | | Src = correspondent, | | Dst = care-of address | | Parameters: | | - sequence number | | - a MAC | | - ... | |<----------------------------------------------------| | | Message 1 actually creates a binding, and message 2 is optional. The correspondent binding procedure consists of the return routability procedure followed by the messages 1 and 2. 1. Binding Update The mobile node uses the created session key Kbu to authorize the Binding Update. The contents of the message are as follows: Src = care-of address Dst = correspondent Parameters: - home address - MAC_Kbu(care-of address | correspondent node address | BU) - home nonce index - care-of nonce index Johnson, Perkins, Arkko Expires 1 December 2002 [Page 18] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 - sequence number - ... The Binding Update message contains Nonce Index option, so that the correspondent node knows which home and care-of nonces to use to recompute the session key. "BU" is the content of the Binding Update message, excluding (1) the IP header, (2) any extension headers between the IP header the Mobility Header, and (3) the Authenticator field inside the Binding Update. The first 96 bits from the MAC result are used as the Authenticator field. A sequence number will be used to match an eventual acknowledgement with this message. The sequence numbers start from a random value. The three dots represent all the remaining (not security related) information in the message. Once the correspondent node has verified the MAC, it can create a binding cache entry for the mobile. 2. Binding Acknowledgement The Binding Update is optionally acknowledged by the correspondent node. The contents of the message are as follows: Src = correspondent Dst = care-of address Parameters: - sequence number - MAC_Kbu(care-of address | correspondent node address | BA) - ... The Binding Acknowledgement contains the same sequence number as the Binding Update did. "BA" is the content of the Binding Acknowledgement message, excluding (1) the IP header, (2) any extension headers between the IP header the Mobility Header, and (3) the Authenticator field inside the Binding Acknowledgement. The first 96 bits from the MAC result are used as the Authenticator field. The three dots represent all the remaining (not security related) information in the message. Bindings established with correspondent nodes using the return routability procedure MUST NOT exceed MAX_RR_BINDING_LIFE seconds. The value in the Source Address field in the IPv6 header carrying the Binding Update message 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 message (see Section 6.2.5). When such message is sent to the correspondent node and the return routability procedure is used as the authorization method, the Care-of Test Init Johnson, Perkins, Arkko Expires 1 December 2002 [Page 19] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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 MAC value MUST be based on information gained in this test. 5.2.7. Updating Node Keys and Nonces An update of Kcn can be done at the same time as an update of a nonce, so that the nonce index identifies both the nonce and the key. Old Kcn values have to be therefore remembered as long as old nonce values. Before sending a Binding Update, the mobile node has to wait for both the Home and Care-of Cookies to arrive. Due to resource limitations, rapid deletion of bindings, or reboots it can not be guaranteed that the cookies are still fresh and acceptable when the correspondent node uses them in the processing of the Binding Update. If the cookies have become too old, the correspondent node replies with an an error code in the Binding Acknowledgement. The mobile node can then retry the return routability procedure. However, it is recommended that correspondent nodes try to keep these cookies acceptable as long as possible and SHOULD NOT accept them beyond MAX_COOKIE_LIFE seconds. Given that the cookies are normally expected to be usable for some time, the mobile node MAY use them beyond a single run of the return routability procedure. A fast moving mobile node may reuse a recent Home Cookie from a correspondent node when moving to a new location, and just acquire a new Care-of Cookie to show routability in the new location. While this does not save roundtrips due to the parallel nature of the home and care-of return routability tests, the roundtrip through the home agent may be longer, and consequently this optimization is often useful. A mobile node that has multiple home addresses, may also use the same Care-of Cookie 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. The correspondent node can, for instance, change the nonce often enough to ensure that the nonces used when removed entries were created are no longer valid. If many such deletions occur the correspondent node can batch them together to avoid having to increment the nonce index too often. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 20] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 5.3. 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. 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 14.1. We also allow the option to be used when the packet containing it has been protected by IPsec. 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 14.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). These measures protect the tunnels against vulnerabilities discussed in Section 14.1. For tunneled traffic to and from the mobile node, encapsulating the traffic inside IPsec AH or ESP offers an optional mechanism to protect the integrity and confidentiality of the traffic against on-path attackers. 6. New IPv6 Protocols, Message Types, and Destination Option 6.1. Mobility Header The Mobility Header is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Sections 6.1.2 through 6.1.9 describe the message types used in this protocol. These sections also define which addresses to use in the IPv6 header in these messages. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 21] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.1.1. Format The Mobility Header is identified by a Next Header value of TBD in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 specification of piggybacking binding messages on payload packets (see Section C.1). Implementations conforming to this specification SHOULD set the payload protocol type to NO_NXTHDR (59 decimal). Header Len 8-bit unsigned integer. Length of the Mobility Header in units of 8 octets, including the the Payload Proto, MH Type, Header Len, Checksum, and Message Data fields. We require that the Mobility Header length is a multiple of 8 octets. MH Type 16-bit selector. Identifies the particular mobility message in question. Current values are specified in Sections 6.1.2 to 6.1.9. An unrecognized MH Type field causes an error to be sent to the source. 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 Johnson, Perkins, Arkko Expires 1 December 2002 [Page 22] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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 [11]. The Next Header value used in the pseudo-header is TBD. 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. 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 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 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 (BRR) Message The Binding Refresh Request (BRR) message is used to request a mobile node's binding from the mobile node. It is sent according to the rules in Section 9.4.5. When a mobile node receives a packet containing a Binding Refresh Request message and there already exists a Binding Update List entry for the source of the Binding Refresh Request, it MAY start a return routability procedure (see Section 5.2) if it believes the amount of traffic with the correspondent justifies the use of route optimization. Note that the mobile node SHOULD NOT respond to Binding Refresh Requests from previously unknown correspondent nodes due to Denial-of-Service concerns. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 23] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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. Contains one 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 Refresh Request message, that need not be present in all Binding Requests sent. This use of mobility options also allows for future extensions to the format of the Binding Refresh Request message to be defined. The following options are valid in a Binding Refresh Request message: - Unique Identifier Option - Binding Authorization option If no actual options are present in this message, no padding is necessary and the Header Length field will be set to 1. 6.1.3. Home Test Init (HoTI) Message A mobile node uses the Home Test Init (HoTI) message to initiate the return routability procedure and request a home cookie from a correspondent node (see Section 11.5.1). The Home Test Init message uses the MH Type value 1. When this value is indicated in the MH Johnson, Perkins, Arkko Expires 1 December 2002 [Page 24] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + HoT 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. HoT cookie 64-bit field which contains a random value, the HoT cookie. Mobility options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. Contains one 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 Init message. If no actual options are present in this message, no padding is necessary and the Header Length field will be set to 2. This message is sent with the Source Address set to the home address of the mobile node, and the Destination Address set to the correspondent node's address. The 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 policy data base. The protection of Home Test Init messages is unrelated to the requirement to protect regular payload traffic, which MAY use such tunnels as well. A packet that includes a Home Test Init message MUST NOT include a Home Address destination option between the Mobility Header and the preceding IPv6 header. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 25] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.1.4. Care-of Test Init (CoTI) Message A mobile node uses the Care-of Test Init (CoTI) message to initiate the return routability procedure and request a care-of cookie from a correspondent node (see Section 11.5.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + CoT 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. CoT cookie 64-bit field which contains a random value, the CoT cookie. Mobility options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. Contains one 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 Length field will be set to 2. This message is always sent with the Source Address set to the care-of address of the mobile node, and is sent directly to the correspondent node. A packet that includes a Care-of Test Init message MUST NOT include a Home Address destination option between the Mobility Header and the preceding IPv6 header. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 26] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.1.5. Home Test (HoT) Message The Home Test (HoT) message is a response to the HoTI 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + HoT cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Nonce Index This field will be echoed back by the mobile node to the correspondent node in a subsequent binding update. HoT cookie 64-bit field which contains the HoT cookie. Home Cookie This field contains the 64 bit home cookie in the return routability procedure; it is the first of two cookies which are to be processed to form a key which is then used to authenticate a binding update. Mobility options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. Contains one 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. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 27] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 If no actual options are present in this message, no padding is necessary and the Header Length field will be set to 3. This message is always sent with the Destination Address set to the home address of the mobile node, Source Address set to the address of the correspondent node, and is tunneled through the home agent when the mobile node is away from home. Note that the Home Test message is always sent to the home address of the mobile node, even when there is an existing binding for the mobile node. The tunneling between the home agent and the mobile node SHOULD employ IPsec ESP in tunnel mode. This protection is indicated by the IPsec policy data base. 6.1.6. Care-of Test (CoT) Message The Care-of Test (CoT) message is a response to the CoTI message, and is sent from the correspondent node to the mobile node (see Section 11.5.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + CoT cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved The two 16-bit fields are reserved for future use. These values MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Care-of Nonce Index This field will be echoed back by the mobile node to the correspondent node in a subsequent binding update. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 28] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 CoT cookie 64-bit field which contains the CoT cookie. Care-of Cookie This field contains the 64 bit care-of cookie in the return routability procedure; it is the second of two cookies which are to be processed to form a key which is then used to authenticate a binding update. Mobility options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. Contains one 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. The CoT message is always sent with the Source Address set to the address of the correspondent node, and the Destination Address set to the care-of address of the mobile node; it is sent directly to the mobile node. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 3. 6.1.7. Binding Update (BU) Message The Binding Update (BU) message is used by a mobile node to notify other nodes of a new care-of address for itself. A packet containing a Binding Update message is sent with the Source Address set to the care-of address of the mobile node and the Destination Address set to the correspondent node's address. The Binding Update message 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|S|D|L| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Johnson, Perkins, Arkko Expires 1 December 2002 [Page 29] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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. 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. Single Address Only (S) If the `S' bit is set, the mobile node requests that the home agent make no changes to any other Binding Cache entry except for the particular one containing the home address specified in the Home Address destination option. This disables home agent processing for other related addresses, as is described in Section 10.2. Duplicate Address Detection (D) The Duplicate Address Detection (D) bit is set by the sending mobile node to request that the receiving node (the mobile node's home agent) perform Duplicate Address Detection [13] on the mobile node's home link for the home address in this binding. This bit is only valid when the Home Registration (H) and Acknowledge (A) bits are also set, and MUST NOT be set otherwise. 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 (IID) as the mobile node's link-local address. 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 number used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 30] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Lifetime 16-bit unsigned integer. The number of time units remaining before the binding MUST be considered expired. A value of all one bits (0xffffffff) indicates infinity. A value of zero indicates that the Binding Cache entry for the mobile node MUST be deleted. One time unit is 16 seconds. Mobility options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. Contains one 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 message: - Unique Identifier option - Binding Authorization Data option - Nonce Indices option. - Alternate Care-of Address option If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 4. A Binding Update to the home agent MUST include the Home Address destination option if the Source Address field in the IPv6 header is not the home address of the mobile node. The care-of address MUST NOT be any IPv6 address which is prohibited for use within a Routing Header; thus multicast addresses, the unspecified address, loop-back address, and link-local addresses are excluded. Binding Updates indicating any such excluded care-of address MUST be silently discarded. The deletion of a binding can be indicated by setting the Lifetime field to 0 or by setting the care-of address equal to the home address. Correspondent nodes SHOULD NOT expire 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 deallocated 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 an error message is sent to the mobile node; however, it causes unnecessary delay in the communications. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 31] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.1.8. Binding Acknowledgement (BA) Message The Binding Acknowledgement message is used to acknowledge receipt of a Binding Update message (Section 6.1.7). When a node receives a packet containing a Binding Update message, with this node being the destination of the packet, this node MUST return a Binding Acknowledgement to the mobile node, if the Acknowledge (A) bit is set in the the Binding Update. The Binding Acknowledgement message is sent to the Source Address of the Binding Update message which is being acknowledged. The packet includes a Routing header if the Source Address was not the home address of the mobile node, as described in Sections 10.2 and 9.4.4. The Source Address of the Binding Acknowledgement is the Destination Address from the Binding Update. The Binding Acknowledgement message 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. 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 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Home registration not supported 132 Not home subnet Johnson, Perkins, Arkko Expires 1 December 2002 [Page 32] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 133 Not home agent for this mobile node 134 Duplicate Address Detection failed 135 Sequence number out of window 136 Route optimization unnecessary due to low traffic 137 Invalid authenticator 138 Expired Home Nonce Index 139 Expired Care-of Nonce Index Up-to-date values of the Status field are to be specified in the IANA registry of assigned numbers [18]. Sequence # The Sequence Number in the Binding Acknowledgement is copied from the Sequence Number field in the Binding Update. It used by the mobile node in matching this Acknowledgement with an outstanding Binding Update. 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. A value of all one bits (0xffffffff) indicates infinity. 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. Contains one 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 message, that need not be present in all Binding Acknowledgements sent. This use of mobility options also allows for future extensions to the format of the Binding Acknowledgement message to be defined. The following options are valid for the Binding Acknowledgement message: - Binding Authorization Data option - Binding Refresh Advice option If no options are present in this message, 4 bytes of padding is necessary and the Header Len field will be set to 2. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 33] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 The Binding Acknowledgement is sent to the source address of the Binding Update message, regardless of whether the Binding Update succeeded or failed. No Routing Headers are added to the message. 6.1.9. Binding Error (BE) 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. A packet containing a Binding Error message is sent to the source address of the offending packet. For instance, in the case of the Home Address destination option error, the packet is the one that contained the Home Address destination option and therefore the Binding Error message is sent to the care-of address of the mobile node. The source address of the Binding Error message is the correspondent node's address. 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 such Status values are currently defined: 1 Home Address destination option used without a binding 2 Received message had an unknown value for the MH Type field Johnson, Perkins, Arkko Expires 1 December 2002 [Page 34] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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. Mobility options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. Contains one 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. This use of mobility options also allows for future extensions to 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 3. 6.2. Mobility Options 6.2.1. Format In order to allow optional fields that may not be needed in every use of any given Mobility Header, and to allow future extensions to the format of these messages to be defined, the Mobility Header messages defined in this document can include one or more mobility options. Such options are included in the data portion 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. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 35] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 These options are encoded within the remaining space of the message data for that 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 Len | Option Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Len 8-bit unsigned integer. Length of this mobility option, in octets. The Option Len does not include the length of the Option Type and Option Len 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. 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 +-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ NOTE! the format of the Pad1 option is a special case -- it has neither Option Len nor Option Data fields. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 36] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Option Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - The PadN option is used to insert two or more octets of padding in the Mobility Options area of a Mobility Header message. For N octets of padding, the Option Len field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. Option data MUST be ignored by the receiver. 6.2.4. Unique Identifier The Unique Identifier option has the 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 | Unique Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Unique Identifier option is valid only in Binding Refresh Request, and Binding Update messages. The Unique Identifier field contains a 16-bit value that serves to uniquely identify a Binding Request among those sent by this Source Address, and to allow the Binding Update to identify the specific Binding Refresh Request to which it responds. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 37] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Alternate Care-of Address option is valid only in Binding Update message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Nonce Indices option is valid only in the Binding Update message, and only when present together with an Binding Authorization Data option. The Home Nonce Index field tells the correspondent node that receives the message which of the challenge values (Ni) are to be used to authenticate the Binding Update. The Care-of Nonce Index field tells the correspondent node that receives the message which of the challenge values (Nj) are to be used to authenticate the Binding Update. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 38] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.2.7. Binding Authorization Data The Binding Authorization Data option has an alignment requirement of 4n+2. 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 = 5 | Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Binding Authorization Data option is valid only in the Binding Refresh Request, Binding Update, and Binding Acknowledgment messages. The Option Len 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 depend on the used authorization procedure. This specification gives the rules only for the return routability procedure. For this procedure, this option can only appear in a Binding Update message and rules for calculating the Authenticator value are described in Section 6.1.7. 6.2.8. 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 = 7 | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Binding Refresh Advice option is only valid in the Binding Acknowledgement message, and only on Acknowledgements sent from the mobile node's home agent in reply to a home registration. The Refresh Interval is measured in seconds, and indicates how long before the mobile node SHOULD send a new home registration to the Johnson, Perkins, Arkko Expires 1 December 2002 [Page 39] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 home agent. The Refresh Interval MUST be set to indicate a smaller time interval than the Lifetime value of the Binding Acknowledgement. 6.3. Home Address Destination Option The Home Address destination option 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. Multicast addresses, link-local addresses, loopback addresses, IPv4 mapped addresses, and the unspecified address, MUST NOT be used within a Home Address option. The Home Address Option MUST NOT appear more than once in any given packet, except inside the payload part of the packet if tunneling is involved. 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. IPv6 requires that options appearing in a Hop-by-Hop Options header or Destination Options header be 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 Johnson, Perkins, Arkko Expires 1 December 2002 [Page 40] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Home Address option is 8n+6. The three highest-order bits of the Option Type are encoded to indicate specific processing of the option [11]. For the Home Address option, these three bits are set to 110, indicating that any IPv6 node processing this option that does not recognize the Option Type must discard the packet and, only 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; and that the data within the option cannot change en-route to the packet's final destination. A packet MUST NOT contain more than one Home Address option, except that an encapsulated packet [15] MAY contain a separate Home Address option associated with each encapsulating IP header. The Home Address option MUST be placed as follows: - After the Routing Header, if that header is present - Before the Fragment Header, if that header is present - Before the AH Header or ESP Header, if either one of those headers is present 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. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 41] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.4. Routing Header type 2 Mobile IPv6 uses a Routing header to carry the Home Address for packets sent from a correspondent node to a mobile node. The Care of Address of the mobile node is carried in the IPv6 destination field. 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 MIPv6. 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. 6.4.1. Routing Header Packet 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 8-bit unsigned integer. Length of the Routing header in 8-octet units, not including the first 8 octets. For the Type 2 Routing header, Hdr Ext Len is always 2. Routing Type 8-bit unsigned integer that contains the value 2. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 42] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Segments Left 8-bit unsigned integer. Number of route segments remaining; i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. Packets transmitted through an interface have Segments left is always 1 in this type of Routing header. Reserved 32-bit reserved field. Initialized to zero for transmission, and ignored on reception. Home Address The Home Address of the destination Mobile Node. The ordering rules for extension headers in an IPv6 packet are described in Section 4.1 of [11]. The new Routing header (Type 2) defined for Mobile IPv6 follows the same ordering as other routing headers. If more than one Routing header (e.g., both a Type 0 and a Type 2 Routing header are present), the Type 2 Routing header should follow all other Routing headers. Otherwise the order of routing headers is independent of their type and follows [11]. 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.3.2. The mobile node sends a Home Agent Address Discovery Request message to the "Mobile IPv6 Home-Agents" anycast address for its own home subnet prefix [16]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Johnson, Perkins, Arkko Expires 1 December 2002 [Page 43] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Type 150 Code 0 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 MUST be one of the mobile node's current care-of addresses. The home agent MUST then return the Home Agent Address Discovery Reply message directly to the Source Address chosen by the mobile node. Note that, at the time of performing this dynamic home agent address discovery, it is likely that the mobile node is not registered with any home agent within the specified anycast group. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 44] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.6. ICMP Home Agent Address Discovery Reply Message The ICMP Home Agent Address Discovery Reply message is used by a home agent to respond to a mobile node that uses the dynamic home agent address discovery mechanism, as described in Section 10.9. One of the home agents on the home link responds to the mobile node with a Home Agent Address Discovery Reply message, providing a list of the routers on the mobile node's home link serving as home agents. 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . Home Agent Addresses . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 151 Code 0 Checksum The ICMP checksum [14]. Identifier The identifier from the invoking 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. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 45] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Home Agent Addresses A list of addresses of home agents on the home link for the mobile node. The number of addresses present in the list is indicated by the remaining length of the IPv6 packet carrying the Home Agent Address Discovery Reply message. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 46] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.7. ICMP Mobile Prefix Solicitation Message Format The ICMP Mobile Prefix Solicitation Message is sent by a mobile node to its home agent while it is away from home. The purpose of the message is to solicit a Mobile Prefix Advertisement from the home agent, which will allow the mobile node to gather prefix information about its home network. This information can be used to configure home address(es) by stateless address autoconfiguration [13], or update address(es) according to changes in prefix information supplied by the home agent. The Mobile Prefix Solicitation is similar to the Router Solicitation used in Neighbor Discovery [12], except it is routed from the mobile node on the visited network to the home agent on the home network by usual unicast routing rules. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address The mobile node's care-of address. Destination Address The address of the mobile node's home agent. This home agent must be on the link which the mobile node wishes to learn prefix information about. Hop Limit Set to an initial hop limit value, similarly to any other unicast packet sent by the mobile node. Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. [subject to change] ICMP Fields: Johnson, Perkins, Arkko Expires 1 December 2002 [Page 47] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Type 152 Code 0 Checksum The ICMP checksum [14]. Identifier An identifier to aid in matching a future Mobile Prefix Advertisement message to this Mobile Prefix Solicitation message. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. If the mobile node receives a Mobile Prefix Advertisement Message from its home agent (see section 6.8), and the advertisement does not contain any authentication data, the mobile node MAY nevertheless send a Binding Update message to its home agent using its new home address which has been formed from the newly advertised prefix information. If there are security concerns that would inhibit responding to unauthenticated advertisements, then the mobile node SHOULD send a Mobile Prefix Solicitation message to its home agent, with a nonzero Identifier value that can be used to match a future advertisement with the solicitation. The mobile node SHOULD include authentication data along with any Mobile Prefix Solicitation message that it sends to the home agent. Johnson, Perkins, Arkko Expires 1 December 2002 [Page 48] INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 6.8. ICMP Mobile Prefix Advertisement Message Format A home agent will send a Mobile Prefix Advertisement message to a mobile node to distribute prefix information about the home link while the mobile node is traveling away from the home network. This will occur in response to a Mobile Prefix Solicitation with an Advertisement, or by an unsolicited Advertisement sent according to the rules in Section 10.9.1. 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