idnits 2.17.1 draft-ietf-mobileip-ipv6-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 45: '... MUST support communications with mo...' RFC 2119 keyword, line 278: '...r mobility mechanisms MAY offer faster...' RFC 2119 keyword, line 873: '... Address option MUST also be covered ...' RFC 2119 keyword, line 999: '... mobile node SHOULD then start a cor...' RFC 2119 keyword, line 1011: '... Binding Refresh Request, it MAY reply...' (624 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 7793 has weird spacing: '...gements missi...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Home Address destination option is used in a packet sent by a mobile node while away from home, to inform the recipient of that packet of the mobile node's home address. For packets sent by a mobile node while away from home, the mobile node generally uses one of its care-of addresses as the Source Address in the packet's IPv6 header. By including a Home Address option in the IPv6 Destination Options header of the packet, the correspondent node receiving the packet is able to substitute the mobile node's home address for this care-of address when processing the packet. This makes the use of the care-of address transparent to the correspondent node above the Mobile IPv6 support level. Note that 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 May 2002) is 8031 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. '6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2267 (ref. '7') (Obsoleted by RFC 2827) ** Obsolete normative reference: RFC 2409 (ref. '8') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2373 (ref. '9') (Obsoleted by RFC 3513) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '10') ** Obsolete normative reference: RFC 2402 (ref. '12') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '13') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2401 (ref. '14') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '15') ** Obsolete normative reference: RFC 2408 (ref. '16') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '19') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (ref. '20') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Normative reference to a draft: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' ** Obsolete normative reference: RFC 2002 (ref. '25') (Obsoleted by RFC 3220) -- Possible downref: Normative reference to a draft: ref. '27' ** Obsolete normative reference: RFC 2407 (ref. '28') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1700 (ref. '30') (Obsoleted by RFC 3232) -- Possible downref: Normative reference to a draft: ref. '31' == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-01 -- Possible downref: Normative reference to a draft: ref. '32' ** Obsolete normative reference: RFC 2462 (ref. '33') (Obsoleted by RFC 4862) Summary: 23 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group David B. Johnson 2 INTERNET-DRAFT Rice University 3 Charles Perkins 4 Nokia Research Center 5 Jari Arkko 6 Ericsson 7 1 May 2002 9 Mobility Support in IPv6 10 12 Status of This Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note 19 that other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents, valid for a maximum of six 23 months, and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document specifies the operation of mobile computers using IPv6. 34 Each mobile node is always identified by its home address, regardless 35 of its current point of attachment to the Internet. While situated 36 away from its home, a mobile node is also associated with a care-of 37 address, which provides information about the mobile node's current 38 location. IPv6 packets addressed to a mobile node's home address are 39 transparently routed to its care-of address. The protocol enables 40 IPv6 nodes to cache the binding of a mobile node's home address 41 with its care-of address, and to then send any packets destined for 42 the mobile node directly to it at this care-of address. To support 43 this operation, Mobile IPv6 defines a new IPv6 protocol and a new 44 destination option. All IPv6 nodes, whether mobile or stationary, 45 MUST support communications with mobile nodes. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Comparison with Mobile IP for IPv4 2 57 3. Terminology 4 58 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 6 61 4. Overview of Mobile IPv6 9 62 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 63 4.2. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 12 64 4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 13 65 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14 66 4.5. Conceptual Data Structures . . . . . . . . . . . . . . . 15 67 4.6. Binding Management . . . . . . . . . . . . . . . . . . . 16 69 5. Overview of Mobile IPv6 Security 17 70 5.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 5.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 18 72 5.3. Tunnels to and from the Home Agents . . . . . . . . . . . 20 73 5.4. Binding Updates to Home Agents . . . . . . . . . . . . . 20 74 5.5. Binding Updates to Correspondent Nodes . . . . . . . . . 21 75 5.5.1. Node Keys . . . . . . . . . . . . . . . . . . . . 22 76 5.5.2. Nonces . . . . . . . . . . . . . . . . . . . . . 23 77 5.5.3. Cookies . . . . . . . . . . . . . . . . . . . . . 23 78 5.5.4. Cryptographic Functions . . . . . . . . . . . . . 24 79 5.5.5. Return Routability Procedure . . . . . . . . . . 24 80 5.5.6. Applying Return Routability for Correspondent 81 Bindings . . . . . . . . . . . . . . . . . 28 82 5.5.7. Updating Node Keys and Nonces . . . . . . . . . . 29 83 5.5.8. Preventing Replay Attacks . . . . . . . . . . . . 30 84 5.5.9. Preventing Denial-of-Service Attacks . . . . . . 30 85 5.5.10. Correspondent Binding Procedure Extensibility . . 31 87 6. New IPv6 Protocols, Message Types, and Destination Option 31 88 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 31 89 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 32 90 6.1.2. Binding Refresh Request (BRR) Message . . . . . . 33 91 6.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 34 92 6.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 36 93 6.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 37 94 6.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 39 95 6.1.7. Binding Update (BU) Message . . . . . . . . . . . 41 96 6.1.8. Binding Acknowledgement (BA) Message . . . . . . 45 97 6.1.9. Binding Error (BE) Message . . . . . . . . . . . 49 98 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 51 99 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 51 100 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 52 101 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 52 102 6.2.4. Unique Identifier . . . . . . . . . . . . . . . . 53 103 6.2.5. Alternate Care-of Address . . . . . . . . . . . . 53 104 6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 54 105 6.2.7. Binding Authorization Data . . . . . . . . . . . 54 106 6.3. Home Address Destination Option . . . . . . . . . . . . . 55 107 6.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 58 108 6.4.1. Routing Header Packet format . . . . . . . . . . 58 109 6.5. ICMP Home Agent Address Discovery Request Message . . . . 59 110 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 61 111 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 63 112 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 65 114 7. Modifications to IPv6 Neighbor Discovery 67 115 7.1. Modified Router Advertisement Message Format . . . . . . 67 116 7.2. Modified Prefix Information Option Format . . . . . . . . 68 117 7.3. New Advertisement Interval Option Format . . . . . . . . 70 118 7.4. New Home Agent Information Option Format . . . . . . . . 71 119 7.5. Changes to Sending Router Advertisements . . . . . . . . 73 120 7.6. Changes to Sending Router Solicitations . . . . . . . . . 74 122 8. Requirements for Types of IPv6 Nodes 75 123 8.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 75 124 8.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 75 125 8.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 76 126 8.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 77 128 9. Correspondent Node Operation 78 129 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 78 130 9.2. Receiving Packets from a Mobile Node . . . . . . . . . . 79 131 9.2.1. Processing Mobility Header (MH) Messages . . . . 79 132 9.2.2. Receiving Packets with Home Address Destination 133 Option . . . . . . . . . . . . . . . . . . 80 134 9.3. Return Routability Procedure . . . . . . . . . . . . . . 80 135 9.3.1. Receiving HoTI Messages . . . . . . . . . . . . . 81 136 9.3.2. Receiving CoTI Messages . . . . . . . . . . . . . 81 137 9.3.3. Sending HoT Messages . . . . . . . . . . . . . . 82 138 9.3.4. Sending CoT Messages . . . . . . . . . . . . . . 82 139 9.4. Processing Bindings . . . . . . . . . . . . . . . . . . . 82 140 9.4.1. Receiving Binding Updates . . . . . . . . . . . . 82 141 9.4.2. Requests to Cache a Binding . . . . . . . . . . . 84 142 9.4.3. Requests to Delete a Binding . . . . . . . . . . 84 143 9.4.4. Sending Binding Acknowledgements . . . . . . . . 85 144 9.4.5. Sending Binding Refresh Requests . . . . . . . . 86 145 9.4.6. Sending Binding Error Messages . . . . . . . . . 87 147 9.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 87 148 9.6. Sending Packets to a Mobile Node . . . . . . . . . . . . 88 149 9.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 89 151 10. Home Agent Operation 90 152 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 90 153 10.2. Primary Care-of Address Registration . . . . . . . . . . 91 154 10.3. Primary Care-of Address De-Registration . . . . . . . . . 94 155 10.4. Intercepting Packets for a Mobile Node . . . . . . . . . 95 156 10.5. Tunneling Intercepted Packets to a Mobile Node . . . . . 97 157 10.6. Handling Reverse Tunneled Packets from a Mobile Node . . 98 158 10.7. Protecting Return Routability Packets . . . . . . . . . . 99 159 10.8. Receiving Router Advertisement Messages . . . . . . . . . 99 160 10.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 101 161 10.9.1. Aggregate List of Home Network Prefixes . . . . . 102 162 10.9.2. Scheduling Prefix Deliveries to the Mobile Node . 104 163 10.9.3. Sending Advertisements to the Mobile Node . . . . 106 164 10.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 107 166 11. Mobile Node Operation 107 167 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 107 168 11.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 110 169 11.2.1. Sending Packets While Away from Home . . . . . . 110 170 11.2.2. Interaction with Outbound IPsec Processing . . . 112 171 11.2.3. Receiving Packets While Away from Home . . . . . 114 172 11.2.4. Routing Multicast Packets . . . . . . . . . . . . 116 173 11.3. Home Agent and Prefix Management . . . . . . . . . . . . 116 174 11.3.1. Receiving Local Router Advertisement Messages . . 116 175 11.3.2. Dynamic Home Agent Address Discovery . . . . . . 118 176 11.3.3. Sending Mobile Prefix Solicitations . . . . . . . 119 177 11.3.4. Receiving Mobile Prefix Advertisements . . . . . 120 178 11.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . 121 179 11.4.1. Movement Detection . . . . . . . . . . . . . . . 121 180 11.4.2. Forming New Care-of Addresses . . . . . . . . . . 124 181 11.4.3. Using Multiple Care-of Addresses . . . . . . . . 125 182 11.5. Return Routability Procedure . . . . . . . . . . . . . . 126 183 11.5.1. Sending Home and Care-of Test Init Messages . . . 126 184 11.5.2. Receiving Return Routability Messages . . . . . . 126 185 11.5.3. Retransmitting in the Return Routability Procedure 128 186 11.5.4. Rate Limiting for Return Routability Procedure . 128 187 11.6. Processing Bindings . . . . . . . . . . . . . . . . . . . 128 188 11.6.1. Sending Binding Updates to the Home Agent . . . . 128 189 11.6.2. Correspondent Binding Procedure . . . . . . . . . 130 190 11.6.3. Receiving Binding Acknowledgements . . . . . . . 133 191 11.6.4. Receiving Binding Refresh Requests . . . . . . . 134 192 11.6.5. Receiving Binding Error Messages . . . . . . . . 135 193 11.6.6. Forwarding from a Previous Care-of Address . . . 136 194 11.6.7. Returning Home . . . . . . . . . . . . . . . . . 137 195 11.6.8. Retransmitting Binding Updates . . . . . . . . . 139 196 11.6.9. Rate Limiting Binding Updates . . . . . . . . . . 140 197 11.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 140 199 12. Protocol Constants 141 201 13. IANA Considerations 142 203 14. Security Considerations 143 204 14.1. Security for the Tunneling to and from the Home Agent . . 143 205 14.2. Security for the Binding Updates to the Home Agent . . . 144 206 14.3. Security for the Binding Updates to the Correspondent 207 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 144 208 14.4. Security for the Home Address Destination Option . . . . 145 209 14.5. Firewall considerations . . . . . . . . . . . . . . . . . 145 211 Acknowledgements 146 213 References 147 215 A. State Machine for the Correspondent Binding Procedure 150 217 B. Changes from Previous Version of the Draft 159 218 B.1. Changes from Draft Version 16 . . . . . . . . . . . . . . 159 219 B.2. Changes from Draft Version 15 . . . . . . . . . . . . . . 161 220 B.3. Changes from Earlier Versions of the Draft . . . . . . . 162 222 C. Remote Home Address Configuration 164 224 D. Future Extensions 165 225 D.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 165 226 D.2. Triangular Routing and Unverified Home Addresses . . . . 166 227 D.3. New Authorization Methods beyond Return Routability . . . 166 229 Chairs' Addresses 167 231 Authors' Addresses 167 232 1. Introduction 234 This document specifies the operation of mobile computers using 235 Internet Protocol Version 6 (IPv6) [6]. Without specific support 236 for mobility in IPv6, packets destined to a mobile node (host or 237 router) would not be able to reach it while the mobile node is away 238 from its home link (the link on which its home IPv6 subnet prefix is 239 in use), since routing is based on the subnet prefix in a packet's 240 destination IP address. In order to continue communication in spite 241 of its movement, a mobile node could change its IP address each time 242 it moves to a new link, but the mobile node would then not be able 243 to maintain transport and higher-layer connections when it changes 244 location. Mobility support in IPv6 is particularly important, as 245 mobile computers are likely to account for a majority or at least a 246 substantial fraction of the population of the Internet during the 247 lifetime of IPv6. 249 The protocol defined in this document, known as Mobile IPv6, allows 250 a mobile node to move from one link to another without changing the 251 mobile node's IP address. A mobile node is always addressable by 252 its "home address", an IP address assigned to the mobile node within 253 its home subnet prefix on its home link. Packets may be routed to 254 the mobile node using this address regardless of the mobile node's 255 current point of attachment to the Internet, and the mobile node may 256 continue to communicate with other nodes (stationary or mobile) after 257 moving to a new link. The movement of a mobile node away from its 258 home link is thus transparent to transport and higher-layer protocols 259 and applications. 261 The Mobile IPv6 protocol is just as suitable for mobility across 262 homogeneous media as for mobility across heterogeneous media. For 263 example, Mobile IPv6 facilitates node movement from one Ethernet 264 segment to another as well as it facilitates node movement from an 265 Ethernet segment to a wireless LAN cell, with the mobile node's IP 266 address remaining unchanged in spite of such movement. 268 One can think of the Mobile IPv6 protocol as solving the 269 network-layer mobility management problem. Some mobility management 270 applications -- for example, handover among wireless transceivers, 271 each of which covers only a very small geographic area -- have been 272 solved using link-layer techniques. For example, in many current 273 wireless LAN products, link-layer mobility mechanisms allow a 274 "handover" of a mobile node from one cell to another, reestablishing 275 link-layer connectivity to the node in each new location. Within 276 the natural limitations imposed by link-management solutions, and as 277 long as such handover occurs only within cells of the mobile node's 278 home link, such link-layer mobility mechanisms MAY offer faster 279 convergence and lower overhead than Mobile IPv6. Extensions to the 280 Mobile IPv6 protocol have been proposed to support a more local, 281 hierarchical form of mobility management, but such extensions are 282 beyond the scope of this document. 284 The protocol specified in this document solves the problem of 285 transparently routing packets to and from mobile nodes while away 286 from home. However, it does not attempt to solve all general 287 problems related to the use of mobile computers or wireless networks. 288 In particular, this protocol does not attempt to solve: 290 - Handling links with partial reachability, or unidirectional 291 connectivity, such as are often found in wireless networks (but 292 see Section 11.4.1). 294 - Access control on a link being visited by a mobile node. 296 - Assistance for adaptive applications 298 - Mobile routers 300 - Service Discovery 302 - Distinguishing between packets lost due to bit errors vs. 303 network congestion 305 2. Comparison with Mobile IP for IPv4 307 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 308 natural combination of the experiences gained from the development 309 of Mobile IP support in IPv4 (Mobile IPv4) [25, 24, 26], together 310 with the opportunities provided by the design and deployment of a new 311 version of IP itself (IPv6) and the new protocol features offered 312 by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, 313 but the protocol is now fully integrated into IP and provides many 314 improvements over Mobile IPv4. This section summarizes the major 315 differences between Mobile IPv4 and Mobile IPv6: 317 - Support for what is known in Mobile IPv4 as "Route 318 Optimization" [27] is now built in as a fundamental part 319 of the protocol, rather than being added on as an optional 320 set of extensions that may not be supported by all nodes 321 as in Mobile IPv4. This integration of Route Optimization 322 functionality allows direct routing from any correspondent 323 node to any mobile node, without needing to pass through 324 the mobile node's home network and be forwarded by its home 325 agent, and thus eliminates the problem of "triangle routing" 326 present in the base Mobile IPv4 protocol [25]. The Mobile IPv4 327 "registration" functionality and the Mobile IPv4 Route 328 Optimization functionality are performed by a single protocol 329 rather than two separate (and different) protocols. 331 - Support is also integrated into Mobile IPv6 -- and into IPv6 332 itself -- for allowing Route Optimization to coexist efficiently 333 with routers that perform "ingress filtering" [7]. A mobile 334 node uses its care-of address as the Source Address in the 335 IP header of packets it sends, allowing the packets to pass 336 normally through ingress filtering routers. The home address 337 of the mobile node is carried in the packet in a Home Address 338 destination option, allowing the use of the care-of address in 339 the packet to be transparent above the IP layer. The ability to 340 correctly process a Home Address option in a received packet is 341 required in all IPv6 nodes, whether mobile or stationary, whether 342 host or router. 344 - The use of the care-of address as the Source Address in each 345 packet's IP header also simplifies routing of multicast packets 346 sent by a mobile node. With Mobile IPv4, the mobile node 347 had to tunnel multicast packets to its home agent in order to 348 transparently use its home address as the source of the multicast 349 packets. With Mobile IPv6, the use of the Home Address option 350 allows the home address to be used but still be compatible with 351 multicast routing that is based in part on the packet's Source 352 Address. 354 - There is no longer any need to deploy special routers as 355 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 356 mobile nodes make use of IPv6 features, such as Neighbor 357 Discovery [20] and Address Autoconfiguration [33], to operate in 358 any location away from home without any special support required 359 from the local router. 361 - The movement detection mechanism in Mobile IPv6 provides 362 bidirectional confirmation of a mobile node's ability to 363 communicate with its default router in its current location 364 (packets that the router sends are reaching the mobile node, and 365 packets that the mobile node sends are reaching the router). 366 This confirmation provides a detection of the "black hole" 367 situation that may exist in some wireless environments where the 368 link to the router does not work equally well in both directions, 369 such as when the mobile node has moved out of good wireless 370 transmission range from the router. The mobile node may then 371 attempt to find a new router and begin using a new care-of 372 address if its link to its current router is not working well. 373 In contrast, in Mobile IPv4, only the forward direction (packets 374 from the router are reaching the mobile node) is confirmed, 375 allowing the black hole condition to persist. 377 - Most packets sent to a mobile node while away from home in 378 Mobile IPv6 are sent using an IPv6 Routing header rather than IP 379 encapsulation, whereas Mobile IPv4 must use encapsulation for all 380 packets. The use of a Routing header requires less additional 381 header bytes to be added to the packet, reducing the overhead 382 of Mobile IP packet delivery. To avoid modifying the packet in 383 flight, however, packets intercepted and tunneled by a mobile 384 node's home agent in Mobile IPv6 must still use encapsulation for 385 delivery to the mobile node. 387 - While a mobile node is away from home, its home agent intercepts 388 any packets for the mobile node that arrive at the home network, 389 using IPv6 Neighbor Discovery [20] rather than ARP [29] as is 390 used in Mobile IPv4. The use of Neighbor Discovery improves 391 the robustness of the protocol (e.g., due to the Neighbor 392 Advertisement "override" bit) and decouples Mobile IP from any 393 particular link layer, unlike in ARP. 395 - The use of IPv6 encapsulation (and the Routing header) removes 396 the need in Mobile IPv6 to manage "tunnel soft state", which was 397 required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 398 to the definition of ICMP for IPv6, the use of tunnel soft state 399 is no longer required in IPv6 for correctly relaying ICMP error 400 messages from within the tunnel back to the original sender of 401 the packet. 403 - The dynamic home agent address discovery mechanism in Mobile IPv6 404 uses IPv6 anycast [11] and returns a single reply to the mobile 405 node, rather than the corresponding Mobile IPv4 mechanism that 406 uses IPv4 directed broadcast and returns a separate reply from 407 each home agent on the mobile node's home link. The Mobile IPv6 408 mechanism is more efficient and more reliable, since only one 409 packet has to be sent back to the mobile node. 411 - Mobile IPv6 defines an Advertisement Interval option for 412 Router Advertisements (equivalent to Agent Advertisements in 413 Mobile IPv4), allowing a mobile node to decide for itself how 414 many Router Advertisements (Agent Advertisements) it is willing 415 to miss before declaring its current router unreachable. 417 - The return routability procedure (see section 5.5) provides a 418 way to verify the that a mobile node is reachable at its claimed 419 home address and at its claimed care-of address. This allows 420 correspondent nodes to verify the authority of the Binding 421 Updates sent to it. Given that the return routability procedure 422 is light-weight and does not require participation in a security 423 infrastructure, it is expected that Route Optimization can 424 be deployed on a global scale between all mobile nodes and 425 correspondent nodes. 427 3. Terminology 429 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 430 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 431 document are to be interpreted as described in RFC 2119 [3]. 433 3.1. General Terms 435 IP 437 Internet Protocol Version 6 (IPv6). 439 node 441 A device that implements IP. 443 router 445 A node that forwards IP packets not explicitly addressed to 446 itself. 448 host 450 Any node that is not a router. 452 link 454 A communication facility or medium over which nodes can 455 communicate at the link layer, such as an Ethernet (simple or 456 bridged). A link is the layer immediately below IP. 458 interface 460 A node's attachment to a link. 462 subnet prefix 464 A bit string that consists of some number of initial bits of an 465 IP address. 467 interface identifier 469 A number used to identify a node's interface on a link. The 470 interface identifier is the remaining low-order bits in the 471 node's IP address after the subnet prefix. 473 link-layer address 475 A link-layer identifier for an interface, such as IEEE 802 476 addresses on Ethernet links. 478 packet 480 An IP header plus payload. 482 security association 484 A security object shared between two nodes which includes the 485 data mutually agreed on for operation of some cryptographic 486 algorithm (typically including a key). 488 security policy database 490 A database of rules that describe what security associations 491 should be applied for different kinds of packets. 493 destination option 495 Destination options are carried by the IPv6 Destination Options 496 extension header. Mobile IPv6 defines one new destination 497 option, the Home Address destination option. 499 3.2. Mobile IPv6 Terms 501 home address 503 An IP address assigned to a mobile node, used as the permanent 504 address of the mobile node. This address is within the mobile 505 node's home link. Standard IP routing mechanisms will deliver 506 packets destined for a mobile node's home address to its home 507 link. 509 home subnet prefix 511 The IP subnet prefix corresponding to a mobile node's home 512 address. 514 home link 516 The link on which a mobile node's home subnet prefix is 517 defined. 519 mobile node 521 A node that can change its point of attachment from one link to 522 another, while still being reachable via its home address. 524 movement 526 A change in a mobile node's point of attachment to the Internet 527 such that it is no longer connected to the same link as it was 528 previously. If a mobile node is not currently attached to its 529 home link, the mobile node is said to be "away from home". 531 correspondent node 533 A peer node with which a mobile node is communicating. The 534 correspondent node may be either mobile or stationary. 536 foreign subnet prefix 538 Any IP subnet prefix other than the mobile node's home subnet 539 prefix. 541 foreign link 543 Any link other than the mobile node's home link. 545 care-of address 547 An IP address associated with a mobile node while visiting a 548 foreign link; the subnet prefix of this IP address is a foreign 549 subnet prefix. Among the multiple care-of addresses that a 550 mobile node may have at any given time (e.g., with different 551 subnet prefixes), the one registered with the mobile node's 552 home agent is called its "primary" care-of address. 554 home agent 556 A router on a mobile node's home link with which the mobile 557 node has registered its current care-of address. While the 558 mobile node is away from home, the home agent intercepts 559 packets on the home link destined to the mobile node's home 560 address, encapsulates them, and tunnels them to the mobile 561 node's registered care-of address. 563 binding 565 The association of the home address of a mobile node with a 566 care-of address for that mobile node, along with the remaining 567 lifetime of that association. 569 binding procedure 571 A binding procedure is initiated by the mobile node to inform 572 either a correspondent node or the mobile node's home agent of 573 the current binding of the mobile node. 575 binding authorization 577 Binding procedure needs to be authorized to allow the recipient 578 to believe that the sender has the right to specify a new 579 binding. 581 return routability procedure 583 The return routability procedure authorizes binding procedures 584 by the use of a cryptographic cookie exchange. 586 correspondent binding procedure 588 A return routability procedure followed by a binding procedure, 589 run between the mobile node and a correspondent node. 591 home binding procedure 593 A binding procedure between the mobile node and its home agent, 594 authorized by the use of IPsec. 596 nonce 598 Nonces are random numbers used internally by the correspondent 599 node in the creation of cookies related to the return 600 routability procedure. The nonces are not specific to a mobile 601 node, and are kept secret within the correspondent node, only 602 used as one input in the creation of the cookies. 604 cookie 606 Cookies are numbers that are used by mobile nodes in the return 607 routability procedure. 609 care-of cookie 611 A cookie sent directly to the mobile node's claimed care-of 612 address from the correspondent node. 614 home cookie 616 A cookie sent to the mobile node's claimed home address from 617 the correspondent node. 619 mobile cookie 621 A cookie sent to the correspondent node from the mobile node, 622 and later returned to the mobile node. Mobile cookies are 623 produced randomly. 625 nonce index 627 The mobile node uses a particular set of cookies in the return 628 routability procedure. The cookies have been produced using a 629 particular set of nonces. A nonce index is used to indicate 630 which nonces have been used, without revealing the nonces 631 themselves. 633 binding key 635 a key used for authenticating binding cache management 636 messages. 638 binding security association 640 a security association established specifically for the purpose 641 of producing and verifying authentication data passed with a 642 Binding Authorization Data option. 644 4. Overview of Mobile IPv6 646 4.1. Basic Operation 648 A mobile node is always addressable at its home address, whether it 649 is currently attached to its home link or is away from home. While 650 a mobile node is at home, packets addressed to its home address are 651 routed to it using conventional Internet routing mechanisms in the 652 same way as if the node were stationary. Since the subnet prefix of 653 a mobile node's home address is one of the subnet prefixes of the 654 mobile node's home link, packets addressed to the mobile node will be 655 routed to its home link. 657 While a mobile node is attached to some foreign link away from home, 658 it is also addressable at one or more care-of addresses, in addition 659 to its home address. A care-of address is an IP address associated 660 with a mobile node while visiting a particular foreign link. The 661 subnet prefix of a mobile node's care-of address is one of the subnet 662 prefixes on the foreign link being visited by the mobile node; if 663 the mobile node is connected to this foreign link while using that 664 care-of address, packets addressed to this care-of address will be 665 routed to the mobile node in its location away from home. 667 The association between a mobile node's home address and care-of 668 address is known as a "binding" for the mobile node. A mobile node 669 typically acquires its care-of address through stateless [33] or 670 stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according 671 to the methods of IPv6 Neighbor Discovery [20]. Other methods 672 of acquiring a care-of address are also possible, such as static 673 pre-assignment by the owner or manager of a particular foreign 674 link, but details of such other methods are beyond the scope of 675 this document. The operation of the mobile node is specified in 676 Section 11. 678 While away from home, a mobile node registers one of its care-of 679 addresses with a router on its home link, requesting this router to 680 function as the "home agent" for the mobile node. The mobile node 681 performs this binding registration by sending a "Binding Update" 682 message to the home agent; the home agent then replies to the mobile 683 node by returning a "Binding Acknowledgement" message. The care-of 684 address associated with this binding registration is known as the 685 mobile node's "primary care-of address". The mobile node's home 686 agent thereafter uses proxy Neighbor Discovery to intercept any 687 IPv6 packets addressed to the mobile node's home address (or home 688 addresses) on the home link, and tunnels each intercepted packet 689 to the mobile node's primary care-of address. To tunnel each 690 intercepted packet, the home agent encapsulates the packet using IPv6 691 encapsulation [4], with the outer IPv6 header addressed to the mobile 692 node's primary care-of address. The operation of the home agent is 693 specified in Section 10. 695 The Binding Update and Binding Acknowledgement messages, together 696 with a "Binding Refresh Request" message, are also used to allow IPv6 697 nodes communicating with a mobile node are capable of dynamically 698 learning and caching the mobile node's binding. This happens 699 through the correspondent binding procedure which involves a return 700 routability test in order to authorize the establishment of the 701 binding, as specified in Sections 5.5.5 and 5.5.6. When sending a 702 packet to any IPv6 destination, a node checks its cached bindings 703 for an entry for the packet's destination address. If a cached 704 binding for this destination address is found, the node uses a new 705 type of IPv6 Routing header [6] (see section 6.4) to route the packet 706 to the mobile node by way of the care-of address indicated in this 707 binding. If, instead, the sending node has no cached binding for 708 this destination address, the node sends the packet normally (with 709 no Routing header), and the packet is subsequently intercepted and 710 tunneled by the mobile node's home agent as described above. Any 711 node communicating with a mobile node is referred to in this document 712 as a "correspondent node" of the mobile node, and may itself be 713 either a stationary node or a mobile node. The operation of the 714 correspondent node is specified in Section 9. 716 Mobile IPv6 also defines one additional IPv6 destination option. 717 When a mobile node sends a packet while away from home, it could 718 generally use a tunnel via the home agent to send this packet. 719 However, if the correspondent node in question has a binding for this 720 mobile node it can use deliver packets more directly. In this case 721 the mobile node can the Source Address in the packet's IPv6 header to 722 one of its current care-of addresses, and include a "Home Address" 723 destination option in the packet, giving the mobile node's home 724 address. Many routers implement security policies such as "ingress 725 filtering" [7] that do not allow forwarding of packets having a 726 Source Address that appears topologically incorrect. By using the 727 care-of address as the IPv6 header Source Address, the packet will 728 be able to pass normally through such routers, and ingress filtering 729 rules will still be able to locate the true topological source of 730 the packet in the same way as packets from non-mobile nodes. By 731 also including the Home Address destination option in each packet, 732 the sending mobile node can communicate its home address to the 733 correspondent node receiving this packet, allowing the use of the 734 care-of address to be transparent above the Mobile IPv6 support level 735 (e.g., at the transport layer). The inclusion of a Home Address 736 destination option in a packet affects only the correspondent node's 737 receipt of this single packet; no state is created or modified in 738 the correspondent node as a result of receiving a Home Address 739 destination option in a packet. 741 It is possible that while a mobile node is away from home, some nodes 742 on its home link may be reconfigured, such that the router that was 743 operating as the mobile node's home agent is replaced by a different 744 router serving this role. In this case, the mobile node may not 745 know the IP address of its own home agent. Mobile IPv6 provides a 746 mechanism, known as "dynamic home agent address discovery", that 747 allows a mobile node to dynamically discover the IP address of a 748 home agent on its home link with which it may register its (primary) 749 care-of address while away from home. The mobile node sends an ICMP 750 "Home Agent Address Discovery Request" message to the "Mobile IPv6 751 Home-Agents" anycast address for its own home subnet prefix [11] and 752 thus reaches one of the routers on its home link currently operating 753 as a home agent. This home agent then returns an ICMP "Home Agent 754 Address Discovery Reply" message to the mobile node, including a list 755 of home agents on the home link. This procedure is specified in 756 Sections 10.9 and 11.3.2. 758 When a mobile node moves from one care-of address to a new care-of 759 address on a new link, it is desirable for packets arriving at 760 the previous care-of address to be tunneled to the mobile node's 761 new care-of address. Since the purpose of a Binding Update is 762 to establish exactly this kind of tunneling, it can be used (at 763 least temporarily) for tunnels originating at the mobile node's 764 previous care-of address, in exactly the same way that it is used 765 for establishing tunnels from the mobile node's home address to the 766 mobile node's current care-of address. Section 11.6.6 describes the 767 use of the Binding Update for this purpose. 769 Section 11.4.3 discusses the reasons why it may be desirable for a 770 mobile node to use more than one care-of address at the same time. 771 However, a mobile node's primary care-of address is distinct among 772 these in that the home agent maintains only a single care-of address 773 registered for each home address belonging to a mobile node, and 774 always tunnels packets sent to a mobile node's home address and 775 intercepted from its home link to this mobile node's registered 776 primary care-of address. The home agent thus need not implement any 777 policy to determine the particular care-of address to which it will 778 tunnel each intercepted packet. The mobile node alone controls the 779 policy by which it selects the care-of addresses to register with its 780 home agent. 782 4.2. New IPv6 Protocols 784 Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header 785 (see Section 6.1). This Header is used to carry the following 786 messages: 788 Home Test Init 790 The Home Test Init message is used to initiate the return 791 routability procedure from the mobile node to a correspondent 792 node. This procedure ensures that subsequent Binding Updates 793 are properly authorized to redirect the traffic of a particular 794 home address. The Home Test Init message is described in 795 detail in Section 6.1.3. 797 Care-of Test Init 799 The Care-of Test Init message is used to initiate the 800 correspondent routability procedure, for a particular care-of 801 address. The Care-of Test Init message is described in detail 802 in Section 6.1.4. 804 Home Test 806 The Home Test message carries a cookie which the mobile node 807 needs before it can properly authorize itself for sending a 808 Binding Update. This message is sent in reply to the Home Test 809 Init message, and is described in detail in Section 6.1.5. 811 Care-of Test 813 The Care-of Test message carries another cookie which the 814 mobile node needs before it can properly authorize itself for 815 sending a Binding Update. This message is sent in reply to 816 the Care-of Test Init message, and is described in detail in 817 Section 6.1.6. 819 Binding Update 821 A Binding Update message is used by a mobile node to notify 822 a correspondent node or the mobile node's home agent of its 823 current binding. The Binding Update sent to the mobile node's 824 home agent to register its primary care-of address is marked 825 as a "home registration". The Binding Update message and its 826 specific authentication requirements are described in detail in 827 Section 6.1.7. 829 Binding Acknowledgement 831 A Binding Acknowledgement message is used to acknowledge 832 receipt of a Binding Update, if an acknowledgement was 833 requested in the Binding Update. The Binding Acknowledgement 834 message and its specific authentication requirements are 835 described in detail in Section 6.1.8. 837 Binding Refresh Request 839 A Binding Refresh Request message is used to request that 840 a mobile node send to the requesting node a Binding Update 841 containing the mobile node's current binding. This message 842 is typically used by a correspondent node to refresh a cached 843 binding for a mobile node, when the cached binding is in active 844 use but the binding's lifetime is close to expiration. The 845 Binding Refresh Request message is described in detail in 846 Section 6.1.2. 848 No authentication is required for the Binding Refresh Request 849 message. 851 Binding Error 853 The Binding Error message is used by the correspondent node to 854 signal an error related to mobility, such as an inappropriate 855 attempt to use the Home Address destination option without 856 an existing binding. This message is described in detail in 857 Section 6.1.9. 859 4.3. New IPv6 Destination Options 861 Mobile IPv6 defines a new IPv6 destination option, the Home Address 862 destination option. This option is used in a packet sent by a mobile 863 node to inform the recipient of that packet of the mobile node's home 864 address. For packets sent by a mobile node while away from home, 865 the mobile node generally uses one of its care-of addresses as the 866 Source Address in the packet's IPv6 header. By including a Home 867 Address option in the packet, the correspondent node receiving the 868 packet is able to substitute the mobile node's home address for this 869 care-of address when processing the packet, thus making the use of 870 the care-of address transparent to the correspondent node above the 871 Mobile IPv6 support level. If the IP header of a packet carrying 872 a Home Address option is covered by authentication, then the Home 873 Address option MUST also be covered by this authentication, but no 874 other authentication is required for the Home Address option. See 875 Sections 6.3 and 11.2.2 for additional details about requirements 876 for the calculation and verification of the authentication data. 877 The Home Address destination option is described in detail in 878 Section 6.3. 880 4.4. New IPv6 ICMP Messages 882 Mobile IPv6 also introduces four new ICMP message types, two for use 883 in the dynamic home agent address discovery mechanism, and two for 884 renumbering and mobile configuration mechanisms. As discussed in 885 general in Section 4.1, the following two new ICMP message types are 886 used for home agent address discovery: 888 Home Agent Address Discovery Request 890 The ICMP Home Agent Address Discovery Request message is used 891 by a mobile node to initiate the dynamic home agent address 892 discovery mechanism. When attempting a home registration, the 893 mobile node may use this mechanism to discover the address of 894 one or more routers currently operating as home agents on its 895 home link, with which it may register while away from home. 896 The Home Agent Address Discovery Request message is described 897 in detail in Section 6.5. 899 Home Agent Address Discovery Reply 901 The ICMP Home Agent Address Discovery Reply message is used by 902 a home agent to respond to a mobile node using the dynamic home 903 agent address discovery mechanism. When a home agent receives 904 a Home Agent Address Discovery Request message, it replies with 905 a Home Agent Address Discovery Reply message, giving a list 906 of the routers on the mobile node's home link serving as home 907 agents. The Home Agent Address Discovery Reply message is 908 described in detail in Section 6.6. 910 The next two message types are used for network renumbering 911 and address configuration on the mobile node, as described in 912 Section 10.9.1: 914 Mobile Prefix Solicitation 916 The ICMP Mobile Prefix Solicitation message is used by a mobile 917 node to request prefix information about the home subnet, in 918 order to retrieve prefixes that are served by home agents and 919 can be used to configure one or more home addresses, or to 920 refresh home addresses before the expiration of their validity. 921 This message is specified in Section 6.7. 923 Mobile Prefix Advertisement 925 The ICMP Mobile Prefix Advertisement is used by a home agent 926 to distribute information to a mobile node about prefixes on 927 the home link which are available for use by the mobile node 928 while away from home. This message may be sent as a response 929 to a Mobile Prefix Solicitation, or due to network renumbering 930 or other prefix changes. This message is specified in Section 931 Section 10.9.3. 933 4.5. Conceptual Data Structures 935 This document describes the Mobile IPv6 protocol in terms of the 936 following three conceptual data structures: 938 Binding Cache 940 A cache, maintained by each IPv6 node, of bindings for other 941 nodes. A separate Binding Cache is maintained by each IPv6 942 node for each of its IPv6 addresses. When sending a packet, 943 the Binding Cache is searched before the Neighbor Discovery 944 conceptual Destination Cache [20]. 946 The Binding Cache for any one of a node's IPv6 addresses may 947 contain at most one entry for each mobile node home address. 948 The contents of all of a node's Binding Cache entries are 949 cleared when it reboots. 951 Binding Cache entries are marked either as "home registration" 952 entries or "correspondent registration" entries. Home 953 registration entries are deleted when its binding lifetime 954 expires, while other entries may be replaced at any time 955 through a local cache replacement policy. 957 Binding Update List 959 A list, maintained by each mobile node, recording information 960 for each Binding Update sent by this mobile node, for which the 961 Lifetime sent in that Binding Update has not yet expired. The 962 Binding Update List includes all bindings sent by the mobile 963 node: those to correspondent nodes, those to the mobile node's 964 home agent, and those to a home agent on the link on which the 965 mobile node's previous care-of address is located. 967 Home Agents List 969 A list, maintained by each home agent and each mobile node, 970 recording information about each home agent from which this 971 node has received recent a Router Advertisement in which the 972 Home Agent (H) bit is set. The home agents list is thus 973 similar to the Default Router List conceptual data structure 974 maintained by each host for Neighbor Discovery [20]. 976 Each home agent maintains a separate Home Agents List for each 977 link on which it is serving as a home agent; this list is used 978 by a home agent in the dynamic home agent address discovery 979 mechanism. Each mobile node, while away from home, also 980 maintains a Home Agents List, to enable it to notify a home 981 agent on its previous link when it moves to a new link. 983 4.6. Binding Management 985 When a mobile node configures a new care-of address and decides to 986 use this new address as its primary care-of address, the mobile 987 node registers this new binding with its home agent by sending 988 the home agent a Binding Update. The mobile node indicates 989 that an acknowledgement is needed for this Binding Update and 990 continues to periodically retransmit it until acknowledged. The 991 home agent acknowledges the Binding Update by returning a Binding 992 Acknowledgement to the mobile node. 994 When a mobile node receives a packet tunneled to it from its home 995 agent, the mobile node uses that as an indication that the original 996 sending correspondent node has no Binding Cache entry for the mobile 997 node, since the correspondent node would otherwise have sent the 998 packet directly to the mobile node using a Routing header. The 999 mobile node SHOULD then start a correspondent binding procedure in 1000 order to establish a binding. This would allow the correspondent 1001 node to cache the mobile node's binding for routing future packets to 1002 it. 1004 A correspondent node with a Binding Cache entry for a mobile node may 1005 refresh this binding, for example if the binding's lifetime is near 1006 expiration, by sending a Binding Refresh Request to the mobile node. 1007 Normally, a correspondent node will only refresh a Binding Cache 1008 entry in this way if it is actively communicating with the mobile 1009 node and has indications, such as an open TCP connection to the 1010 mobile node, that it will continue this communication in the future. 1011 When a mobile node receives a Binding Refresh Request, it MAY reply 1012 by initiating a correspondent binding procedure. 1014 A mobile node may use more than one care-of address at the same 1015 time. Use of more than one care-of address by a mobile node may be 1016 useful, for example, to improve smooth handover when the mobile node 1017 moves from one wireless link to another. If each of these wireless 1018 links is connected to the Internet through a separate base station, 1019 such that the wireless transmission range from the two base stations 1020 overlap, the mobile node may be able to remain connected to both 1021 links while in the area of overlap. In this case, the mobile node 1022 could acquire a new care-of address on the new link before moving 1023 out of transmission range and disconnecting from the old link. The 1024 mobile node may thus still accept packets at its old care-of address 1025 while it works to update its home agent and correspondent nodes, 1026 notifying them of its new care-of address on the new link. 1028 Since correspondent nodes cache bindings, it is expected that 1029 correspondent nodes usually will route packets directly to the mobile 1030 node's care-of address, so that the home agent is rarely involved 1031 with packet transmission to the mobile node. This is important for 1032 scalability and reliability, and for minimizing overall network load. 1033 By caching the care-of address of a mobile node, direct delivery of 1034 packets can be achieved from the correspondent node to the mobile 1035 node. Routing packets directly to the mobile node's care-of address 1036 also eliminates congestion at the mobile node's home agent and home 1037 link. In addition, the impact of any possible failure of the home 1038 agent, the home link, or intervening networks leading to or from the 1039 home link is reduced, since these nodes and links are not involved in 1040 the delivery of most packets to the mobile node. 1042 5. Overview of Mobile IPv6 Security 1044 5.1. Threats 1046 Any mobility solution must protect itself against misuses of the 1047 mobility features. In Mobile IPv6, most of the potential threats 1048 are concerned with denial of service. Some of the threats also 1049 include potential for man-in-the-middle, hijacking, and impersonation 1050 attacks. The main threats this protocol protects against are as 1051 follows: 1053 1. Threats against Binding Updates sent to home agents and 1054 correspondent nodes. For instance, an attacker might claim that 1055 a certain mobile node is currently at a different location than 1056 it really is. If the home agent accepts the information sent to 1057 it as is, the mobile node might not get traffic destined to it, 1058 and other nodes might get traffic they did not want. 1060 Similarly, a malicious mobile node might use the home address of 1061 a victim node in a forged Binding Update to a correspondent node. 1062 If such Binding Updates were accepted, the communications between 1063 the correspondent node and the victim would be then be disrupted, 1064 because packets that the correspondent node intended to send to 1065 the victim would be sent to the wrong care-of address. This is 1066 a threat to confidentiality as well as availability, because an 1067 attacker might redirect packets meant for another node to itself 1068 in order to learn the content of those packets. 1070 A malicious mobile node might also send Binding Updates in 1071 which the care-of address is set to the address of a victim 1072 node or an address within a victim network. If such Binding 1073 Updates were accepted, the malicious mobile node could force the 1074 correspondent node into sending data to the victim node or the 1075 victim network; the correspondent node's replies to messages sent 1076 by the malicious mobile node will be sent to the victim host 1077 or network. This could be used to cause a distributed denial 1078 of service attack. Variations of this threat are described 1079 elsewhere [1][31]. 1081 A malicious node might also send a large number of invalid 1082 Binding Updates to a victim node. If each Binding Update takes a 1083 significant amount of resources (such as CPU) to process before 1084 it can be recognized either as valid or as invalid, then a denial 1085 of service attack can be caused by sending the correspondent node 1086 so many invalid Binding Updates that it has no resources left for 1087 other tasks. 1089 An attacker might also attempt to disrupt a mobile node's 1090 communications by replaying a Binding Update that the node had 1091 sent earlier. If the old Binding Update was accepted, packets 1092 destined for the mobile node would be sent to its old location 1093 and not its current location. 1095 2. Reflection attack threats against third partied with the help 1096 of Mobile IPv6 correspondent nodes that do not use appropriate 1097 security precautions. The Home Address destination option can be 1098 used to direct response traffic toward a node whose IP address 1099 appears in the option, without allowing ingress filtering to 1100 catch the forged "return address" [32] [23]. 1102 3. Threats where an attacker forges tunneled packets between the 1103 mobile node and the home agent, making it appear that the traffic 1104 is coming from the mobile node when it is not. 1106 4. Threats against IPv6 functionality used by Mobile IPv6, such as 1107 the Routing header. The generality of the regular Routing Header 1108 would allow circumvention of IP-address based rules in firewalls 1109 or reflection of traffic to other nodes, even if the usage that 1110 Mobile IPv6 requires is safe. 1112 5. The security mechanisms of Mobile IPv6 may also be attacked 1113 themselves, e.g. in order to force the participants to execute 1114 expensive cryptographic operations or allocate memory for the 1115 purpose of keeping state. 1117 5.2. Features 1119 This specification provides a number of security features. The main 1120 features are: 1122 - Protection of Binding Updates to home agents. 1124 - Protection of Binding Updates to correspondent nodes. 1126 - Protection against reflection attacks through the Home Address 1127 destination option. 1129 - Protection of tunnels between the mobile node and the home agent. 1131 - Preventing Routing Header vulnerabilities. 1133 - Preventing Denial-of-Service attacks to the Mobile IPv6 security 1134 mechanisms themselves. 1136 Protecting the Binding Updates to home agents and to arbitrary 1137 correspondent nodes require very different security solutions due 1138 to the different situations. Mobile nodes and home agents are 1139 expected to be naturally subject to the network administration of 1140 the home domain, and thus to have a strong security association to 1141 reliably authenticate the exchanged messages. With such a security 1142 arrangement, IPsec Encapsulating Security Payload (ESP) can be used 1143 to implement the necessary security features. See Section 5.4. 1145 It is expected that Mobile IPv6 will be used on a global basis 1146 between nodes belonging to different administrative domains. 1147 Building an authentication infrastructure to authenticate mobile 1148 nodes and correspondent nodes would be a very demanding task in this 1149 scale. Furthermore, traditional authentication infrastructure keep 1150 track of correct IP addresses for all hosts is either impossible or 1151 at least very hard. That is, it isn't sufficient to authenticate 1152 mobile nodes, authorization to claim right to use an address is 1153 needed. Thus, an "infrastructureless" approach is necessary. 1155 The chosen infrastructureless method verifies that the mobile 1156 node is "live" (that is, it responds to probes) at its home and 1157 care-of addresses by performing a cookie exchange with the nodes 1158 in question, and by requiring that the eventual Binding Update is 1159 cryptographically bound to the exchanged cookies. Some additional 1160 protection is provided by requiring the cookies be protected by 1161 ESP when exchanged between the mobile node and the correspondent 1162 node via the home agent. This method limits the vulnerabilities to 1163 those attackers who are on the path between the home agent and the 1164 correspondent node. As adversaries on this path would be able to 1165 cause also other types of attacks, this is seen as sufficient base 1166 security between mobile and correspondent nodes. 1168 Vulnerabilities relating to the use of correspondent nodes as 1169 reflectors via the Home Address destination option can be solved as 1170 follows: We ensure that the mobile node is authorized to use a given 1171 home address before this option can be used. Such authorization is 1172 already performed in the context of Route Optimization, and therefore 1173 this specification limits the use of the Home Address option to the 1174 situation where the correspondent node already has a binding cache 1175 entry for the given home address. 1177 Tunnels between the mobile node and the home agent can be 1178 protected by ensuring proper use of source addresses, and optional 1179 cryptographic protection. These procedures are discussed in 1180 Section 5.3. 1182 Potential abuses of the Routing Header can be prevented by using a 1183 Mobile IPv6 specific type of a Routing Header. This type provides 1184 the necessary functionality but does not open vulnerabilities. 1186 Denial-of-Service threats against Mobile IPv6 security mechanisms 1187 themselves concern mainly the Binding Update procedures with 1188 correspondent nodes. The protocol has been designed to limit the 1189 effects of such attacks, as will be described in Section 5.5.9. 1191 5.3. Tunnels to and from the Home Agents 1193 Mobile IPv6 tunneling -- as tunneling in general -- needs protection 1194 so that it isn't possible, e.g., for anyone to pose as the home agent 1195 and send traffic to the mobile node. To protect the tunnels to the 1196 mobile node, the mobile node verifies that the outer IP address 1197 corresponds to its home agent, to prevent attacks against the tunnel 1198 from other IP addresses. 1200 Tunnels from the mobile node to the home agent need protection 1201 so that it isn't possible for anyone to send traffic through the 1202 home agent, pose as the mobile node, and escape detection through 1203 traditional tracing mechanisms. 1205 Binding Updates sent to the home agents are secure. The home 1206 agent verifies that the outer IP address corresponds to the current 1207 location of the mobile node, to prevent attacks against the tunnel 1208 from other IP addresses. 1210 For tunneled traffic to and from the mobile node, encapsulating the 1211 traffic inside IPsec ESP offers an optional mechanism to protect 1212 the confidentiality and integrity of the traffic against on-path 1213 attackers. 1215 5.4. Binding Updates to Home Agents 1217 Signaling between the mobile node and the home agent requires message 1218 integrity, correct ordering and replay protection. 1220 In order to have this protection, the mobile node and the home agent 1221 must have a security association. IPsec Encapsulating Security 1222 Payload (ESP) can be used for integrity protection when a non-null 1223 authentication algorithm is applied. 1225 However, IPsec can easily provide replay protection only if dynamic 1226 security association establishment is used. This may not always be 1227 possible, and manual keying would be preferred in some cases. IPsec 1228 also does not guarantee correct ordering of packets, only that they 1229 have not been replayed. Because of this, Mobile IPv6 provides its 1230 own mechanism inside the Binding Update and Acknowledgement messages. 1232 A sequence number field is used to ensure correct ordering. If the 1233 mobile node reboots and forgets its current sequence number, the home 1234 agent uses the status value 141 (Sequence number out of window, see 1235 Section 6.1.8) to inform the mobile node of the use of an improper 1236 sequence number. 1238 Note that the the sequence number mechanism provides also a weak form 1239 of replay protection. However, if a home agent reboots and loses its 1240 state regarding the sequence numbers, replay attacks become possible. 1241 If the home agent is vulnerable to this, the use of a key management 1242 mechanism together with IPsec can be used to prevent replay attacks. 1244 A sliding window scheme is used for the sequence numbers. The 1245 protection against replays and reordering attacks without a key 1246 management mechanism works when the attacker remembers up to a 1247 maximum of 2**15 Binding Updates. 1249 In order to protect messages exchanged between the mobile node and 1250 the home agent with IPsec, appropriate security policy database 1251 entries must be created. We need to avoid the possibility that a 1252 mobile node could use its security association to send a Binding 1253 Update on behalf of another mobile node using the same home agent. 1254 In order to do this, the security policy database entries MUST 1255 unequivocally identify a single SA for any given home address and 1256 home agent. In order for the home address of the mobile node to be 1257 visible when the policy check is made, the mobile node MUST use the 1258 Home Address destination option in Binding Updates sent to the home 1259 agent. The home address in the Home Address destination option and 1260 the Binding Update message MUST be equal and MUST be checked by the 1261 home agent. 1263 5.5. Binding Updates to Correspondent Nodes 1265 Binding Updates to correspondent nodes are protected using the return 1266 routability procedure. The motivation for designing the return 1267 routability procedure was to have sufficient support for Mobile IP, 1268 without creating major new security problems. It was not our goal 1269 to protect against attacks that were already possible before the 1270 introduction of Mobile IP. This protocol does not defend against 1271 an attacker who can monitor the home agent to correspondent node 1272 path, as such attackers would in any case be able to mount an active 1273 attack against the mobile node when it is at its home location. The 1274 possibility of such attacks is not an impediment to the deployment of 1275 Mobile IP, because these attacks are possible regardless of whether 1276 Mobile IP is in use. 1278 This protocol also protects against denial of service attacks in 1279 which the attacker pretends to be a mobile, but uses the victim's 1280 address as the care of address, and so causes the correspondent node 1281 to send the victim traffic that it does not expect. For example, 1282 suppose that the correspondent node is a news site that will send a 1283 high-bandwidth stream of video to anyone who asks for it. Note that 1284 the use of flow-control protocols such as TCP does not necessarily 1285 defend against this type of attack, because the attacker can fake the 1286 acknowledgements. Even keeping TCP initial sequence numbers secret 1287 doesn't help, because the attacker can receive the first few segments 1288 (including the ISN) at its own address, and then redirect the stream 1289 to the victim's address. This protocol defends against these attacks 1290 by only completing if packets sent by the correspondent node to the 1291 care of address are received and processed by an entity that is 1292 willing to participate in the protocol. Normally, this will be the 1293 mobile node. 1295 For further information about the design rationale of the return 1296 routability procedure, see [1] [31] [22] [23]. 1298 The return routability procedure method uses the following 1299 principles: 1301 - A cookie exchange verifies that the mobile node is reachable at 1302 its addresses i.e. is at least able to transmit and receive 1303 traffic at its addresses. 1305 - The eventual Binding Update is protected cryptographically using 1306 the cookies. 1308 - Requiring that the cookies be protected by ESP when forwarded by 1309 the home agent to the mobile node. 1311 - The use of symmetric exchanges where responses are sent to the 1312 same address as the request was sent from, to avoid the use of 1313 this protocol in reflection attacks. 1315 - Correspondent nodes operate in a stateless manner until they 1316 receive a Binding Update that can be authorized. 1318 The return routability procedure can be broken by an attacker on the 1319 route between the home agent and the correspondent node, but not by 1320 attackers on the network the mobile node is currently at and not from 1321 elsewhere on the Internet. 1323 5.5.1. Node Keys 1325 Each correspondent node has a secret key, Kcn. This key is used by 1326 the correspondent node to accept only the use of cookies which it has 1327 created itself. This key does not need to be shared with any other 1328 entity, so no key distribution mechanism is needed for it. 1330 A correspondent node can generate a fresh Kcn each time that it boots 1331 to avoid the need for secure persistent storage for Kcn. Kcn can be 1332 either a fixed value or regularly updated. Procedures for updating 1333 Kcn are discussed later in Section 5.5.7. 1335 Kcn consists of 20 octets. 1337 5.5.2. Nonces 1339 Each correspondent node also generates a nonce at regular intervals, 1340 for example every few minutes. A correspondent node uses the same 1341 Kcn and nonce with all the mobiles it is in communication with, so 1342 that it does not need to generate and store a new nonce when a new 1343 mobile contacts it. Each nonce is identified by a nonce index. 1344 Nonce indices are 16-bit values that are e.g. incremented each time 1345 a new nonce is created. The index value is communicated in the 1346 protocol, so that if a nonce is replaced by new nonce during the run 1347 of a protocol, the correspondent node can distinguish messages that 1348 should be checked against the old nonce from messages that should be 1349 checked against the new nonce. Correspondent nodes keep both the 1350 current nonce and a small set of old nonces. Older values can be 1351 discarded, and messages using them will be rejected as replays. 1353 The specific nonce index values can not be used by mobile nodes to 1354 determine the validity of the nonce. Expected validity times for 1355 the nonces values and the procedures for updating them are discussed 1356 later in Section 5.5.7. 1358 Nonce is an octet string of any length. The recommended length is 16 1359 octets. 1361 5.5.3. Cookies 1363 Three different types of cookies are used in the protocol: 1365 - Mobile cookie is sent to the correspondent node from the mobile 1366 node, and later returned to the mobile node. Mobile cookies are 1367 produced randomly, and used to verify that the response matches 1368 the request, and to ensure that parties who have not seen the 1369 request can not spoof responses. 1371 - A home cookie sent to the mobile node from the correspondent node 1372 via the home agent. Home cookies are produced cryptographically 1373 from nonces. 1375 - A care-of cookie sent directly to the mobile node from the 1376 correspondent node. Home cookies are produced cryptographically 1377 from nonces. 1379 Mobile cookies are typically newly generated random values for each 1380 new request that needs them. They could also be changed periodically 1381 only. The policy to use new or old mobile cookies is purely a local 1382 matter for the mobile node. 1384 Home and care-of cookies are produced by the correspondent node, and 1385 they are based on the currently active secret keys and nonces of the 1386 correspondent node as well as the home or care-of address. Such a 1387 cookie is valid as long as both the secret key and the nonce used to 1388 create it are valid. 1390 5.5.4. Cryptographic Functions 1392 MAC_K(m) denotes a Message Authentication Code computed on message 1393 m with key K. In this specification, HMAC SHA1 function [15][21] is 1394 used to compute these codes. 1396 H(m) denotes a hash of message m. In this specification, SHA1 1397 function [21] is used to compute the hash. 1399 5.5.5. Return Routability Procedure 1401 The return routability signaling happens as follows: 1403 Mobile node Home agent Correspondent node 1404 | | 1405 | Home Test Init(HoTI) | 1406 | Src = home address, | 1407 | Dst = correspondent | | 1408 | Parameters: | | 1409 | - mobile cookie 1 | | 1410 |------------------------->|------------------------->| 1411 | | | 1412 | | 1413 | Care-of Test Init(CoTI) | 1414 | Src = care-of address | 1415 | Dst = correspondent | 1416 | Parameters: | 1417 | - mobile cookie 2 | 1418 |---------------------------------------------------->| 1419 | | 1420 | Home Test (HoT) | 1421 | Src = correspondent, | 1422 | Dst = home address | 1423 | Parameters: | 1424 | - mobile cookie 1 | 1425 | | - home cookie | 1426 | | - home nonce index | 1427 |<-------------------------|<-------------------------| 1428 | | | 1429 | | 1430 | Care-of Test(CoT) | 1431 | Src = correspondent, | 1432 | Dst = care-of address | 1433 | Parameters: | 1434 | - mobile cookie 2 | 1435 | - care-of cookie | 1436 | - care-of nonce index | 1437 |<----------------------------------------------------| 1438 | | 1440 The HoTI and CoTI messages are sent at the same time. The 1441 correspondent node returns the HoT and CoT messages as quickly as 1442 possible, and perhaps nearly simultaneously, requiring very little 1443 processing. The four messages form the return routability procedure. 1444 (After the return routability procedure, a binding will be created 1445 with a single request with an optional response.) Due to the 1446 simultaneous sending of messages, the return routability procedure 1447 completes in 1 roundtrip (and the whole process completes in 1.5 1448 roundtrips excluding the acknowledgement message). 1450 The four messages (HoTI, CoTI, HoT, and CoT) belonging to the return 1451 routability procedure are described in more detail below. The use of 1452 the results of the return routability procedure for authenticating a 1453 correspondent binding procedure is described in Section 5.5.6. 1455 HoTI 1457 Home Test Init Message: 1459 When a mobile nodes wants to perform route optimization it 1460 sends a HoTI message to the correspondent node in order to 1461 initiate the return routability verification for the Home 1462 Address. 1464 Src = home address 1465 Dst = correspondent 1466 Parameters: 1467 - mobile cookie 1 1469 This message conveys the mobile node's home address to the 1470 correspondent node. The mobile node also sends along mobile 1471 cookie C0 that the correspondent node must return later, 1472 along with its own cookie that it generates based on the home 1473 address. The HoTI message is reverse tunneled through the home 1474 agent. 1476 CoTI 1478 Care-of Test Init Message: 1480 When a mobile nodes wants to perform route optimization it 1481 sends a CoTI message to the correspondent node in order to 1482 initiate the return routability verification for the care-of 1483 Address. 1485 Src = care-of address 1486 Dst = correspondent 1487 Parameters: 1488 - mobile cookie 2 1490 The second message is sent in parallel with the first one. It 1491 conveys the mobile node's care-of address to the correspondent 1492 node. The mobile node also sends along mobile cookie C1 that 1493 the correspondent node must return later, along with its own 1494 cookie that it generates based on the care-of address. The 1495 CoTI message is sent directly to the correspondent node. 1497 HoT 1499 Home Test Message: 1501 This message is sent in response to a HoTI message. 1503 Src = correspondent 1504 Dst = home address 1505 Parameters: 1506 - mobile cookie 1 1507 - home cookie 1508 - home nonce index 1510 When the correspondent node receives the HoTI message, it 1511 generates a 16 octet home cookie as follows: 1513 home cookie = MAC_Kcn(home address | nonce) 1515 The cookie is sent in the message to the mobile node via the 1516 Home Agent; it is an assumption of the protocol that the home 1517 agent - mobile node route is secure. Home cookie also acts as 1518 a challenge to test that the mobile can receive messages sent 1519 to its home address. Kcn is used in the production of home 1520 cookie in order to allow the correspondent node to verify that 1521 the cookies used later really came from itself, without forcing 1522 the correspondent node to remember a list of all cookies it has 1523 handed out. 1525 Mobile cookie 1 from the mobile node is returned as well in the 1526 HoT message, to ensure that the message comes from someone on 1527 the path to the correspondent node. 1529 The home nonce index is carried along in the protocol to allow 1530 the correspondent node to later efficiently find the nonce 1531 value Ni that it used in creating this cookie. 1533 CoT 1535 Care-of Test Message: 1537 This message is sent in response to a CoTI message. 1539 Src = correspondent 1540 Dst = care-of address 1541 Parameters: 1542 - mobile cookie 2 1543 - care-of cookie 1544 - care-of nonce index 1546 The correspondent node also sends a challenge to the mobile's 1547 care-of address. When the correspondent node receives the CoTI 1548 message, it generates a 16 octet care-of cookie as follows: 1550 care-of cookie = MAC_Kcn(care-of address | nonce) 1552 The cookie is sent directly to the mobile node at its care-of 1553 address. Mobile cookie 2 from the mobile node is returned as 1554 well, to ensure that the message comes from someone on the path 1555 to the correspondent node. 1557 Again, an index is sent along the cookie in order to identify 1558 the used nonce. Note that home and care-of nonce indices are 1559 likely to be the same in HoT and CoT messages, except when 1560 the correspondent node changed its nonce value between the 1561 reception of HoTI and the CoTI messages. 1563 When the mobile node has received both the HoT and CoT messages, the 1564 return routability procedure is complete. As a result, the mobile 1565 node has the means to prove its authority to send a Binding Update 1566 to the correspondent node. The mobile node hashes together the 1567 challenges to form a 20 octet session key (Kbu): 1569 Kbu = H(home cookie | care-of cookie) 1571 Note that the correspondent node has not created any state at this 1572 point. It is unaware of the session key Kbu, though it can recreate 1573 Kbu if it is presented the right addresses and nonce indices. 1575 5.5.6. Applying Return Routability for Correspondent Bindings 1577 After the return routability procedure, the mobile node can proceed 1578 to perform a binding procedure with the correspondent node. An 1579 overview of the binding procedure is shown below. 1581 Mobile Node Correspondent node 1582 | | 1583 | 1. Binding Update | 1584 | Src = care-of address, Dst = correspondent | 1585 | Parameters: | 1586 | - home address | 1587 | - a MAC | 1588 | - home nonce index | 1589 | - care-of nonce index | 1590 | - sequence number | 1591 | - ... | 1592 |---------------------------------------------------->| 1593 | | 1594 | 2. Binding Acknowledgement | 1595 | (if requested) | 1596 | Src = correspondent, | 1597 | Dst = care-of address | 1598 | Parameters: | 1599 | - sequence number | 1600 | - ... | 1601 |<----------------------------------------------------| 1602 | | 1604 Message 1 actually creates a binding, and message 2 is optional. The 1605 correspondent binding procedure consists of the return routability 1606 procedure followed by the messages 1 and 2. 1608 1. 1610 Binding Update (BU) Message: 1612 The mobile node uses the created session key Kbu to authorize 1613 the Binding Update. 1615 Src = care-of address 1616 Dst = correspondent 1617 Parameters: 1618 - home address 1619 - MAC_Kbu(care-of address | correspondent node address | BU) 1620 - home nonce index 1621 - care-of nonce index 1622 - sequence number 1623 - ... 1625 The message contains home and care-of nonce indices, so that 1626 the correspondent node knows which nonces to use to recompute 1627 the session key. "BU" is the content of the Binding Update 1628 message, excluding (1) the IP header, (2) any extension 1629 headers between the IP header the Mobility Header, and (3) the 1630 Authenticator field inside the Binding Update. The result of 1631 the MAC_Kbu function is used as the Authenticator field in 1632 the Binding Update. A sequence number will be used to match 1633 an eventual acknowledgement with this message. The sequence 1634 numbers start from a random value, which offers a weak form 1635 of authentication also to the acknowledgement messages. The 1636 three dots represent all the remaining (not security related) 1637 information in the message. 1639 Once the correspondent node has verified the MAC, it can create 1640 a binding cache entry for the mobile. 1642 2. 1644 Binding Acknowledgement (BA) Message: 1646 The Binding Update is optionally acknowledged by the 1647 correspondent node. 1649 Src = correspondent 1650 Dst = care-of address 1651 Parameters: 1652 - sequence number 1653 - ... 1655 The Binding Acknowledgement is not authenticated in other ways 1656 than including the right sequence number in the reply. The 1657 three dots represent all the remaining (not security related) 1658 information in the message. 1660 5.5.7. Updating Node Keys and Nonces 1662 An update of Kcn can be done at the same time as an update of Ni, so 1663 that i identifies both the nonce and the key. Old Kcn values have to 1664 be therefore remembered as long as old nonce values. 1666 Before sending a Binding Update in Step 3, the mobile node has 1667 to wait for both the Home and Care-of Cookies to arrive. Due 1668 to resource limitations, rapid deletion of bindings, or reboots 1669 it can not be guaranteed that the cookies are still fresh and 1670 acceptable when the correspondent node uses them in the processing 1671 of the Binding Update. If the cookies have become too old, the 1672 correspondent node replies with an an error code in the Binding 1673 Acknowledgement. The mobile node can then retry the return 1674 routability procedure. However, it is recommended that correspondent 1675 nodes try to keep these cookies acceptable as long as possible and 1676 SHOULD NOT accept them beyond MAX_COOKIE_LIFE seconds. 1678 Given that the cookies are normally expected to be usable for 1679 some time, the mobile node MAY use them beyond a single run of the 1680 return routability procedure. A fast moving mobile node may reuse 1681 a recent Home Cookie from a correspondent node when moving to a new 1682 location, and just acquire a new Care-of Cookie to show routability 1683 in the new location. While this does not save roundtrips due to the 1684 parallel nature of the home and care-of return routability tests, the 1685 roundtrip through the home agent may be longer, and consequently this 1686 optimization is often useful. A mobile node that has multiple home 1687 addresses, may also use the same Care-of Cookie for Binding Updates 1688 concerning all of these addresses. 1690 5.5.8. Preventing Replay Attacks 1692 The return routability procedure also protects the participants 1693 against replayed Binding Updates. The attacker can't replay the 1694 same message due to the sequence number which is a part of the 1695 Binding Update, and the attacker can't modify the Binding Update 1696 since the MAC would not verify after that. Care must be taken when 1697 removing bindings at the correspondent node, however. If a binding 1698 is removed either due to garbage collection, request, or expiration 1699 and the nonce used in its creation is still valid, an attacker can 1700 replay the old Binding Update. This can be prevented by having the 1701 correspondent node change the nonce often enough to ensure that the 1702 nonces used when removed entries were created are no longer valid. 1703 If many such deletions occur the correspondent node can batch them 1704 together to avoid having to increment the nonce index too often. 1706 5.5.9. Preventing Denial-of-Service Attacks 1708 The return routability procedure has been designed with protection 1709 against resource exhaustion Denial-of-Service attacks. In these 1710 attacks the victim has only a limited amount of some resource (such 1711 as network bandwidth or CPU cycles), and the attack consumes some of 1712 this resource. This leaves the victim without enough resources to 1713 carry out other work. 1715 The correspondent nodes do not have to retain any state about 1716 individual mobile nodes until an authentic Binding Update arrives. 1717 This is achieved through the use of the nonces and Kcn that are not 1718 specific to individual mobile nodes. The cookies are specific, but 1719 they can be reconstructed based on the home and care-of address 1720 information that arrives with the Binding Update. This means that 1721 the correspondent nodes are safe against memory exhaustion attacks 1722 except where on-path attackers are concerned. Due to the use of 1723 symmetric cryptography, the correspondent nodes are relatively safe 1724 against CPU resource exhaustion attacks as well. 1726 Nevertheless, as [1] describes, there are situations in which it is 1727 impossible for the mobile and correspondent nodes to determine if 1728 they actually need a binding or whether they just have been fooled 1729 into believing so by an attacker. Therefore, it is necessary to 1730 consider situations where such attacks are being made. 1732 The binding updates that are used in Mobile IPv6 are only an 1733 optimization, albeit a very important optimization. A mobile node 1734 can communicate with a correspondent node even if the correspondent 1735 refuses to accept any of its binding updates. However, performance 1736 will suffer because packets from the correspondent node to the mobile 1737 node will be routed via the mobile's home agent rather than a more 1738 direct route. A correspondent node can protect itself against some 1739 of the resource exhaustion attacks by not processing binding updates 1740 when it is flooded with a large number of binding updates that fail 1741 the cryptographic integrity checks. If a correspondent node finds 1742 that it is spending more resources on checking bogus binding updates 1743 than it is likely to save by accepting genuine binding updates, then 1744 it MAY reject some or all Binding Updates without performing any 1745 cryptographic operations. 1747 Additional information needed to make this decision about responding 1748 to requests will usually originate in layers above IP. For example, 1749 TCP knows if the node has a queue of data that it is trying to send 1750 to a peer. A conformant implementation of the protocols in this 1751 specification is not required to make use of information from higher 1752 protocol layers, but implementations are likely to be able to manage 1753 resources more effectively by making use of such information. 1755 5.5.10. Correspondent Binding Procedure Extensibility 1757 As discussed in Appendix D.3, in the future there may be other 1758 mechanisms beyond the return routability procedure for authorizing 1759 mobile nodes to correspondent nodes. The nodes can use other methods 1760 based on future definition of flag values in the Reserved fields of 1761 HoTI, HoT, CoTI, CoT, and BU messages. Nodes need assurance against 1762 bidding down attacks in this selection by following the procedure 1763 described in Section 14.3. 1765 6. New IPv6 Protocols, Message Types, and Destination Option 1767 6.1. Mobility Header 1769 The Mobility Header is used by mobile nodes, correspondent nodes, and 1770 home agents in all messaging related to the creation and management 1771 of bindings. The Mobility Header is an IPv6 protocol. Rules 1772 regarding how it is sent and what addresses are used in the IPv6 1773 header are given separately in Sections 6.1.2 through 6.1.9, which 1774 describe the message types used in this protocol. 1776 6.1.1. Format 1778 The Mobility Header is identified by a Next Header value of 62 (XXX) 1779 in the immediately preceding header, and has the following format: 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 |Payload Proto | Header Len | MH Type | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Checksum | | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1786 | | 1787 . . 1788 . Message Data . 1789 . . 1790 | | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 Payload Proto 1795 8-bit selector. Identifies the type of header immediately 1796 following the Mobility Header. Uses the same values as the 1797 IPv4 Protocol field [10]. 1799 This field is intended to be used by a future specification 1800 of piggybacking binding messages on payload packets (see 1801 Section D.1). 1803 Implementations conforming to this specification SHOULD set the 1804 payload protocol type to NO_NXTHDR (59 decimal). 1806 Header Len 1808 8-bit unsigned integer. Length of the Mobility Header in units 1809 of 8 octets, including the the Payload Proto, MH Type, Header 1810 Len, Checksum, and Message Data fields. 1812 MH Type 1814 16-bit selector. Identifies the particular mobility message 1815 in question. Current values are specified in Sections 6.1.2 1816 to 6.1.9. An unrecognized MH Type field causes an error to be 1817 sent to the source. 1819 Checksum 1821 16-bit unsigned integer. This field contains the checksum 1822 of the Mobility Header. The checksum is the 16-bit one's 1823 complement of the one's complement sum of an octet string 1824 consisting of a "pseudo-header" followed by the entire 1825 Mobility Header starting with the Payload Proto field. The 1826 pseudo-header contains IPv6 header fields, as specified 1827 in Section 8.1 of [6]. The Next Header value used in the 1828 pseudo-header is 62 (XXX). For computing the checksum, the 1829 checksum field is set to zero. 1831 Message Data 1833 A variable length field containing the data specific to the 1834 indicated Mobility Header type. 1836 Mobile IPv6 also defines a number of "mobility options" for use 1837 within these messages; if included, any options MUST appear after the 1838 fixed portion of the message data specified in this document. The 1839 presence of such options will be indicated by the Header Len field 1840 within the message. When the Header Len is greater than the length 1841 required for the message specified here, the remaining octets are 1842 interpreted as mobility options options. The encoding and format of 1843 defined options are described in Section 6.2. 1845 Alignment requirements for the Mobility Header are same as for any 1846 IPv6 protocol Header. That is, they MUST be aligned on an 8-octet 1847 boundary. We also require that the Mobility Header length is a 1848 multiple of 8 octets. 1850 6.1.2. Binding Refresh Request (BRR) Message 1852 The Binding Refresh Request (BRR) message is used to request a 1853 mobile node's binding from the mobile node. A packet containing 1854 a Binding Refresh Request message is sent in the same way as any 1855 packet to a mobile node (Section 9.6). When a mobile node receives 1856 a packet containing a Binding Refresh Request message and there 1857 already exists a Binding Update List entry for the source of the 1858 Binding Refresh Request, it MAY start a return routability procedure 1859 (see Section 5.5) if it believes the amount of traffic with the 1860 correspondent justifies the use of Route Optimization. Note that 1861 the mobile node SHOULD NOT respond to Binding Refresh Requests from 1862 previously unknown correspondent nodes due to Denial-of-Service 1863 concerns. 1865 The Binding Refresh Request message uses the MH Type value 0. When 1866 this value is indicated in the MH Type field, the format of the 1867 Message Data field in the Mobility Header is as follows: 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Reserved | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | | 1873 . . 1874 . Mobility options . 1875 . . 1876 | | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 Reserved 1881 16-bit field reserved for future use. The value MUST be 1882 initialized to zero by the sender, and MUST be ignored by the 1883 receiver. 1885 Mobility options 1887 Variable-length field of such length that the complete Mobility 1888 Header is an integer multiple of 8 octets long. Contains one 1889 or more TLV-encoded mobility options. The encoding and format 1890 of defined options are described in Section 6.2. The receiver 1891 MUST ignore and skip any options which it does not understand. 1893 There MAY be additional information, associated with this 1894 Binding Refresh Request message, that need not be present in 1895 all Binding Requests sent. This use of mobility options also 1896 allows for future extensions to the format of the Binding 1897 Refresh Request message to be defined. The following options 1898 are valid in a Binding Refresh Request message: 1900 - Unique Identifier Option 1902 - Binding Authorization option 1904 The Header Length field in the Mobility Header for this message 1905 MUST be set to 1 (since unit is 8 octets) plus the total length of 1906 all mobility options present (also in 8 octet units). If no actual 1907 options are present in this message, no padding is necessary. 1909 6.1.3. Home Test Init (HoTI) Message 1911 The Home Test Init (HoTI) message is used to initiate the return 1912 routability procedure from the mobile node to a correspondent node 1913 (see Section 11.6.2). The purpose of this message is to test the 1914 reachability of the home address. This message is always sent with 1915 the Source Address set to the home address of the mobile node, 1916 Destination Address set to the correspondent node's address, and is 1917 tunneled through the home agent when the mobile node is away from 1918 home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between 1919 the home agent and the mobile node. This protection is guided by the 1920 IPsec Policy Data Base. (Note the protection of HoTI messages is 1921 different from the requirement to protect regular payload traffic, 1922 which MAY use such tunnels as well.) 1924 The HoTI message uses the MH Type value 1. When this value is 1925 indicated in the MH Type field, the format of the Message Data field 1926 in the Mobility Header is as follows: 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | Reserved | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | Mobile cookie | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | | 1934 . . 1935 . Mobility Options . 1936 . . 1937 | | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 Reserved 1942 16-bit field reserved for future use. This value MUST be 1943 initialized to zero by the sender, and MUST be ignored by the 1944 receiver. 1946 Mobile cookie 1948 32-bit field which contains a random value, mobile cookie 1, 1949 selected by the mobile node. 1951 Mobility options 1953 Variable-length field of such length that the complete Mobility 1954 Header is an integer multiple of 8 octets long. Contains one 1955 or more TLV-encoded mobility options. The receiver MUST ignore 1956 and skip any options which it does not understand. 1958 There MAY be additional information, associated with this 1959 message that need not be present in all HoTI messages. This 1960 use of mobility options also allows for future extensions to 1961 the format of the HoTI message to be defined. The encoding and 1962 format of defined options are described in Section 6.2. The 1963 following options are valid in a HoTI message: 1965 - Unique Identifier Option 1967 The Header Length field in the Mobility Header for this message 1968 MUST be set to 2 (since unit is 8 octets) plus the total length of 1969 all mobility options present (also in 8 octet units). If no actual 1970 options are present in this message, 4 bytes of padding is necessary. 1972 A packet that includes a HoTI message MUST NOT include a Home Address 1973 destination option. 1975 6.1.4. Care-of Test Init (CoTI) Message 1977 The Care-of Test Init (CoTI) message is used to initiate the return 1978 routability procedure from the mobile node to a correspondent node 1979 (see Section 11.6.2). The purpose of this message is to test the 1980 reachability of the care-of address. This message is always sent 1981 with the Source Address set to the care-of address of the mobile 1982 node, and is sent directly to the correspondent node. 1984 The CoTI message uses the MH Type value 2. When this value is 1985 indicated in the MH Type field, the format of the Message Data field 1986 in the Mobility Header is as follows: 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Reserved | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Mobile cookie | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | | 1994 . . 1995 . Mobility Options . 1996 . . 1997 | | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 Reserved 2002 16-bit field reserved for future use. The value MUST be 2003 initialized to zero by the sender, and MUST be ignored by the 2004 receiver. 2006 Mobile cookie 2008 32-bit field which contains a random value, mobile cookie 2, 2009 selected by the mobile node. 2011 Mobility options 2013 Variable-length field of such length that the complete Mobility 2014 Header is an integer multiple of 8 octets long. Contains one 2015 or more TLV-encoded mobility options. The receiver MUST ignore 2016 and skip any options which it does not understand. 2018 There MAY be additional information, associated with this 2019 message that need not be present in all CoTI messages. This 2020 use of mobility options also allows for future extensions to 2021 the format of the CoTI message to be defined. The encoding and 2022 format of defined options are described in Section 6.2. The 2023 following options are valid in a CoTI message: 2025 - Unique Identifier Option 2027 The Header Length field in the Mobility Header for this message 2028 MUST be set to 2 (since unit is 8 octets) plus the total length of 2029 all mobility options present (also in 8 octet units). If no actual 2030 options are present in this message, 4 bytes of padding is necessary. 2032 A packet that includes a CoTI message MUST NOT include a Home Address 2033 destination option. 2035 6.1.5. Home Test (HoT) Message 2037 The Home Test (HoT) message is a response to the HoTI message, and 2038 is sent from the correspondent node to the mobile node (see Section 2039 8.2). This message is always sent with the Destination Address set 2040 to the home address of the mobile node, Source Address set to the 2041 address of the correspondent node, and is tunneled through the home 2042 agent when the mobile node is away from home. Such tunneling SHOULD 2043 employ IPsec ESP in tunnel mode between the home agent and the mobile 2044 node. This protection is guided by the IPsec Policy Data Base. 2046 The HoT message uses the MH Type value 3. When this value is 2047 indicated in the MH Type field, the format of the Message Data field 2048 in the Mobility Header is as follows: 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | Reserved | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | Home Nonce Index | Reserved | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | Mobile cookie | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | | 2058 + + 2059 | Home Cookie (128 bits) | 2060 + + 2061 | | 2062 + + 2063 | | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | | 2066 . . 2067 . Mobility options . 2068 . . 2069 | | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 Reserved 2074 The two 16-bit fields are reserved for future use. These 2075 values MUST be initialized to zero by the sender, and MUST be 2076 ignored by the receiver. 2078 Home Nonce Index 2080 This field will be echoed back by the mobile node to the 2081 correspondent node in a subsequent binding update. Strictly 2082 speaking, this value is not necessary in the authentication, 2083 but allows the correspondent node to efficiently find the nonce 2084 value Ni that it used in creating the Home Cookie. Without 2085 this field, the correspondent node would have to search through 2086 all currently acceptable nonce values when testing for the 2087 correctness of the authenticator sent in a Binding Update. 2089 Mobile cookie 2091 32-bit field which contains mobile cookie 1, returned by the 2092 correspondent node. 2094 Home Cookie 2096 This field contains the home cookie in the return routability 2097 procedure; it is the first of two cookies which are to be 2098 processed to form a key which is then used to authenticate a 2099 binding update. 2101 Mobility options 2103 Variable-length field of such length that the complete Mobility 2104 Header is an integer multiple of 8 octets long. Contains one 2105 or more TLV-encoded mobility options. The receiver MUST ignore 2106 and skip any options which it does not understand. 2108 There MAY be additional information, associated with this 2109 message that need not be present in all HoT messages. Mobility 2110 options are used to carry that information. The encoding and 2111 format of defined options are described in Section 6.2. This 2112 use of mobility options also allows for future extensions 2113 to the format of the HoT message to be defined. This 2114 specification does not define any options valid for the HoT 2115 message. 2117 The Header Length field in the Mobility Header for this message 2118 MUST be set to 4 (since unit is 8 octets) plus the total length of 2119 all mobility options present (also in 8 octet units). If no actual 2120 options are present in this message, no padding is necessary. 2122 6.1.6. Care-of Test (CoT) Message 2124 The Care-of Test (CoT) message is a response to the CoTI message, and 2125 is sent from the correspondent node to the mobile node (see Section 2126 8.2). This message is always sent with the Source Address set to the 2127 address of the correspondent node, the Destination Address set to 2128 the care-of address of the mobile node, and is sent directly to the 2129 mobile node. 2131 The CoT message uses the MH Type value 4. When this value is 2132 indicated in the MH Type field, the format of the Message Data field 2133 in the Mobility Header is as follows: 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | Reserved | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | Care-of Nonce Index | Reserved | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Mobile cookie | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | | 2143 + + 2144 | Care-of Cookie (128 bits) | 2145 + + 2146 | | 2147 + + 2148 | | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | | 2151 . . 2152 . Mobility Options . 2153 . . 2154 | | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 Reserved 2159 The two 16-bit fields and the one 32-bit field are reserved for 2160 future use. These values MUST be initialized to zero by the 2161 sender, and MUST be ignored by the receiver. 2163 Care-of Nonce Index 2165 This field will be echoed back by the mobile node to the 2166 correspondent node in a subsequent binding update. It 2167 will allow the correspondent node to select the appropriate 2168 challenge values to authenticate the binding update. 2170 Mobile cookie 2172 32-bit field which contains the mobile cookie 2, returned by 2173 the correspondent node. 2175 Care-of Cookie 2177 This field contains the care-of cookie in the return 2178 routability procedure; it is the second of two cookies which 2179 are to be processed to form a key which is then used to 2180 authenticate a binding update. 2182 Mobility options 2184 Variable-length field of such length that the complete Mobility 2185 Header is an integer multiple of 8 octets long. Contains one 2186 or more TLV-encoded mobility options. The receiver MUST ignore 2187 and skip any options which it does not understand. 2189 There MAY be additional information, associated with this 2190 message that need not be present in all CoT messages. Mobility 2191 options are used to carry that information. The encoding and 2192 format of defined options are described in Section 6.2. This 2193 use of mobility options also allows for future extensions 2194 to the format of the CoT message to be defined. This 2195 specification does not define any options valid for the CoT 2196 message. 2198 The Header Length field in the Mobility Header for this message 2199 MUST be set to 4 (since unit is 8 octets) plus the total length of 2200 all mobility options present (also in 8 octet units). If no actual 2201 options are present in this message, no padding is necessary. 2203 6.1.7. Binding Update (BU) Message 2205 The Binding Update (BU) message is used by a mobile node to notify 2206 other nodes of a new care-of address for itself. A packet containing 2207 a Binding Update message is sent with the Source Address set to the 2208 care-of address of the mobile node and the Destination Address set to 2209 the correspondent node's address. 2211 The Binding Update message uses the MH Type value 5. When this value 2212 is indicated in the MH Type field, the format of the Message Data 2213 field in the Mobility Header is as follows: 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 |A|H|S|D| Reserved | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | Sequence # | Reserved | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | Lifetime | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | | 2223 + + 2224 | | 2225 + Home Address + 2226 | | 2227 + + 2228 | | 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | | 2231 . . 2232 . Mobility options . 2233 . . 2234 | | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 Acknowledge (A) 2239 The Acknowledge (A) bit is set by the sending mobile node to 2240 request a Binding Acknowledgement (Section 6.1.8) be returned 2241 upon receipt of the Binding Update. 2243 Home Registration (H) 2245 The Home Registration (H) bit is set by the sending mobile 2246 node to request that the receiving node should act as this 2247 node's home agent. The destination of the packet carrying this 2248 message MUST be that of a router sharing the same subnet prefix 2249 as the home address of the mobile node in the binding. 2251 Single Address Only (S) 2253 If the `S' bit is set, the mobile node requests that the home 2254 agent make no changes to any other Binding Cache entry except 2255 for the particular one containing the home address specified 2256 in the Home Address destination option. This disables home 2257 agent processing for other related addresses, as is described 2258 in Section 10.2. 2260 Duplicate Address Detection (D) 2262 The Duplicate Address Detection (D) bit is set by the sending 2263 mobile node to request that the receiving node (the mobile 2264 node's home agent) perform Duplicate Address Detection [33] 2265 on the mobile node's home link for the home address in this 2266 binding. This bit is only valid when the Home Registration (H) 2267 and Acknowledge (A) bits are also set, and MUST NOT be set 2268 otherwise. If the Duplicate Address Detection performed by 2269 the home agent fails, the Status field in the returned Binding 2270 Acknowledgement will be set to 138 (Duplicate Address Detection 2271 failed). 2273 Reserved 2275 This field is unused. It MUST be initialized to zero by the 2276 sender and MUST be ignored by the receiver. 2278 Sequence # 2280 A 16-bit number used by the receiving node to sequence Binding 2281 Updates and by the sending node to match a returned Binding 2282 Acknowledgement with this Binding Update. Each Binding Update 2283 sent by a mobile node MUST use a Sequence Number greater than 2284 the Sequence Number value sent in the previous Binding Update 2285 (if any) to the same destination address (modulo 2**16, as 2286 defined in Section 4.5). There is no requirement, however, 2287 that the Sequence Number value strictly increase by 1 with each 2288 new Binding Update sent or received, as long as the value stays 2289 within the window. A Binding Acknowledgement with Status field 2290 set to 141 (Sequence number out of window) will be returned 2291 if the value is outside the window. Both home agents and 2292 correspondent nodes use the sequence number also to prevent 2293 replay attacks. 2295 Lifetime 2297 32-bit unsigned integer. The number of seconds remaining 2298 before the binding MUST be considered expired. A value of all 2299 one bits (0xffffffff) indicates infinity. A value of zero 2300 indicates that the Binding Cache entry for the mobile node MUST 2301 be deleted. 2303 Bindings established with correspondent nodes using the return 2304 routability procedure MUST NOT exceed MAX_RR_BINDING_LIFE 2305 seconds. 2307 Home Address 2309 The home address of the mobile node associated with this 2310 Binding Update. 2312 Mobility options 2314 Variable-length field of such length that the complete Mobility 2315 Header is an integer multiple of 8 octets long. Contains one 2316 or more TLV-encoded mobility options. The encoding and format 2317 of defined options are described in Section 6.2. The receiver 2318 MUST ignore and skip any options which it does not understand. 2319 A Binding Update sent to a correspondent node MUST include the 2320 following options when the return routability procedure is used 2321 as the authorization method: 2323 - Nonce Indices option. This option contains information the 2324 correspondent node needs in order to find the challenge 2325 values Ni and Nj. 2327 - Binding Authorization Data option. This option contains 2328 a cryptographic hash value which is used to ensure that 2329 it has been sent by the same party who received the HoT 2330 and CoT messages. The authenticator covering a Binding 2331 Update MUST be 96 bits and computed over a string of octets 2332 containing the following fields of the IPv6 header and the 2333 Mobility Header, in order: 2335 * Care-of Address, in the Source Address field of the 2336 IPv6 header 2338 * The address of the correspondent node, in the 2339 Destination Address field of the IPv6 header. 2341 * The contents of the Mobility Header, excluding the 2342 Authenticator field (within the Binding Authorization 2343 Data mobility option) which is not included for the 2344 purposes of calculating the Authenticator. Options of 2345 the Mobility Header are included in the calculation. 2347 The actual authenticator calculation over a sequence of 2348 bits is described in Section 5.5. 2350 There MAY be additional information, associated with this 2351 Binding Update message, that need not be present in all Binding 2352 Updates sent. This use of mobility options also allows for 2353 future extensions to the format of the Binding Update message 2354 to be defined. The following options are valid in a Binding 2355 Update message: 2357 - Unique Identifier option 2359 - Binding Authorization Data option 2361 - Alternate Care-of Address option 2363 The Header Length field in the Mobility Header for this message 2364 MUST be set to 4 (since unit is 8 octets) plus the total length of 2365 all mobility options present (also in 8 octet units). If no actual 2366 options are present in this message, no padding is necessary. 2368 A Binding Update to the home agent MUST include the Home Address 2369 destination option in order to allow for the use of manually keyed 2370 IPsec in the protection of these messages. Note also that as 2371 described in Section 6.3, the Home Address destination option is not 2372 accepted by correspondent nodes that do not have an existing binding 2373 with the sender. 2375 When a packet contains both a Home Address destination option and a 2376 Binding Update message, the sender MUST use the same address in both. 2377 The receiver MUST check for equal values and MUST silently discard a 2378 packet that does not pass this test. 2380 The care-of address for the binding given in the Binding Update 2381 message is normally that which was received as the value in the 2382 Source Address field in the IPv6 header of the packet carrying the 2383 Binding Update message. However, a care-of address different from 2384 the Source Address MAY be specified by including an Alternate Care-of 2385 Address mobility option in the Binding Update message. When such 2386 message is sent to the correspondent node and the return routability 2387 procedure is used as the authorization method, the Care-of Test Init 2388 and Care-of Test messages MUST have been performed for the address in 2389 the Alternate Care-of Address option (not the Source Address). The 2390 contents of the Nonce Indices and the Authenticator mobility options 2391 MUST be based on information gained in this test. 2393 In any case, the care-of address MUST NOT be any IPv6 address 2394 which is prohibited for use within a Routing Header; thus multicast 2395 addresses, the unspecified address, loop-back address, and link-local 2396 addresses are excluded. Binding Updates indicating any such excluded 2397 care-of address MUST be silently discarded. 2399 The deletion of a binding can be indicated by setting the Lifetime 2400 field to 0 or by setting the care-of address as equal to the home 2401 address (the care-of address can be specified either in an Alternate 2402 Care-of Address mobility option in the Binding Update message, if 2403 present, or in the Source Address field in the packet's IPv6 header). 2405 6.1.8. Binding Acknowledgement (BA) Message 2407 The Binding Acknowledgement message is used to acknowledge receipt 2408 of a Binding Update message (Section 6.1.7). When a node receives 2409 a packet containing a Binding Update message, with this node being 2410 the destination of the packet, this node MUST return a Binding 2411 Acknowledgement to the mobile node, if the Acknowledge (A) bit 2412 is set in the the Binding Update. The Binding Acknowledgement 2413 message is sent to the Source Address of the Binding Update message 2414 which is being acknowledged. The Source Address of the Binding 2415 Acknowledgement is the Destination Address from the Binding Update. 2417 The Binding Acknowledgement message has the MH Type value 6. When 2418 this value is indicated in the MH Type field, the format of the 2419 Message Data field in the Mobility Header is as follows: 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | Status | Reserved | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | Sequence # | Reserved | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | Lifetime | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | Refresh | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | | 2431 . . 2432 . Mobility options . 2433 . . 2434 | | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 Reserved 2439 These fields are unused. They MUST be initialized to zero by 2440 the sender and MUST be ignored by the receiver. 2442 Status 2444 8-bit unsigned integer indicating the disposition of the 2445 Binding Update. Values of the Status field less than 128 2446 indicate that the Binding Update was accepted by the receiving 2447 node. The following such Status values are currently defined: 2449 0 2451 Binding Update accepted 2453 Values of the Status field greater than or equal to 128 2454 indicate that the Binding Update was rejected by the receiving 2455 node. The following such Status values are currently defined: 2457 128 2459 Reason unspecified 2461 130 2463 Administratively prohibited 2465 131 2467 Insufficient resources 2469 132 2471 Home registration not supported 2473 133 2475 Not home subnet 2477 137 2479 Not home agent for this mobile node 2481 138 2483 Duplicate Address Detection failed 2485 141 2487 Sequence number out of window 2489 142 2491 Route optimization unnecessary due to low traffic 2493 143 2495 Invalid authenticator 2497 144 2499 Expired Home Nonce Index 2501 145 2503 Expired Care-of Nonce Index 2505 Up-to-date values of the Status field are to be specified in 2506 the most recent "Assigned Numbers" [30]. 2508 Sequence # 2510 The Sequence Number in the Binding Acknowledgement is copied 2511 from the Sequence Number field in the Binding Update being 2512 acknowledged, for use by the mobile node in matching this 2513 Acknowledgement with an outstanding Binding Update. 2515 Lifetime 2517 The granted lifetime, in seconds, for which this node SHOULD 2518 retain the entry for this mobile node in its Binding Cache. 2519 Correspondent nodes should make an effort to honor the 2520 lifetimes, since an entry that was garbage collected too early 2521 might cause subsequent packets from the mobile node to be 2522 dropped, if they contained the Home Address destination option. 2523 While this situation is recoverable since an error message is 2524 sent to the mobile node, it causes an unnecessary break in the 2525 communications. 2527 Mobile nodes SHOULD send a new Binding Update well before the 2528 expiration of this period in order to extend the lifetime and 2529 not cause a disruption in communications. This is particularly 2530 necessary in order to prevent packets from being dropped due 2531 to the use of the Home Address destination option without an 2532 existing Binding Cache Entry, and the possibility of clock 2533 drift. 2535 If the node sending the Binding Acknowledgement is serving 2536 as the mobile node's home agent, the Lifetime period also 2537 indicates the period for which this node will continue this 2538 service; if the mobile node requires home agent service from 2539 this node beyond this period, the mobile node MUST send a new 2540 Binding Update to it before the expiration of this period (even 2541 if it is not changing its primary care-of address), in order 2542 to extend the lifetime. The value of this field is undefined 2543 if the Status field indicates that the Binding Update was 2544 rejected. 2546 Refresh 2548 The recommended interval, in seconds, at which the mobile 2549 node SHOULD send a new Binding Update to this node in order 2550 to "refresh" the mobile node's binding in this node's Binding 2551 Cache. This refreshing of the binding is useful in case the 2552 node fails and loses its cache state. The Refresh period is 2553 determined by the node sending the Binding Acknowledgement (the 2554 node caching the binding). If this node is serving as the 2555 mobile node's home agent, the Refresh value may be set, for 2556 example, based on whether the node stores its Binding Cache in 2557 volatile storage or in nonvolatile storage. 2559 If the node sending the Binding Acknowledgement is not 2560 serving as the mobile node's home agent, the Refresh period 2561 SHOULD be set equal to the Lifetime period in the Binding 2562 Acknowledgement; even if this node loses this cache entry due 2563 to a failure of the node, packets from it can still reach the 2564 mobile node through the mobile node's home agent, causing a new 2565 Binding Update to this node to allow it to recreate this cache 2566 entry. The value of this field is undefined if the Status 2567 field indicates that the Binding Update was rejected. 2569 Mobility options 2571 Variable-length field of such length that the complete Mobility 2572 Header is an integer multiple of 8 octets long. Contains one 2573 or more TLV-encoded mobility options. The encoding and format 2574 of defined options are described in Section 6.2. The receiver 2575 MUST ignore and skip any options which it does not understand. 2577 There MAY be additional information, associated with this 2578 Binding Acknowledgement message, that need not be present 2579 in all Binding Acknowledgements sent. This use of mobility 2580 options also allows for future extensions to the format of the 2581 Binding Acknowledgement message to be defined. The following 2582 options are valid for the Binding Acknowledgement message: 2584 - Binding Authorization Data option 2586 The Header Length field in the Mobility Header for this message 2587 MUST be set to 3 (since unit is 8 octets) plus the total length of 2588 all mobility options present (also in 8 octet units). If no actual 2589 options are present in this message, 4 bytes of Pad1 or PadN mobility 2590 options are needed to make the length of the message a multiple of 8. 2591 The Header Length field does include this padding. 2593 The Binding Acknowledgement is sent to the source address of the 2594 Binding Update message, regardless of whether the Binding Update 2595 succeeded or failed. No Routing Headers are added to the message. 2597 If the mobile node sends a sequence number which is not within the 2598 window of acceptable sequence numbers, then the home agent MUST send 2599 back a Binding Acknowledgement with status code 141, and the last 2600 accepted sequence number in the Sequence Number field of the Binding 2601 Acknowledgement message. 2603 6.1.9. Binding Error (BE) Message 2605 The Binding Error (BE) message is used by the correspondent node to 2606 signal an error related to mobility, such as an inappropriate attempt 2607 to use the Home Address destination option without an existing 2608 binding. A packet containing a Binding Error message is sent to the 2609 source address of the offending packet. For instance, in the case 2610 of the Home Address destination option error, the packet is the one 2611 that contained the Home Address destination option and therefore 2612 the Binding Error message is sent to the care-of address of the 2613 mobile node. The source address of the Binding Error message is the 2614 correspondent node's address. 2616 The Binding Error message uses the MH Type value 7. When this value 2617 is indicated in the MH Type field, the format of the Message Data 2618 field in the Mobility Header is as follows: 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 | Status | Reserved | 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 | | 2624 + + 2625 | | 2626 + Home Address + 2627 | | 2628 + + 2629 | | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 . . 2632 . Mobility Options . 2633 . . 2634 | | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 Status 2639 8-bit unsigned integer indicating the reason for this message. 2640 The following such Status values are currently defined: 2642 1 2644 Home Address destination option used without a binding 2646 2 2648 Received message had an unknown value for the MH Type field 2650 Reserved 2652 A 8-bit field reserved for future use. The value MUST be 2653 initialized to zero by the sender, and MUST be ignored by the 2654 receiver. 2656 Home Address 2658 The home address that was contained in the Home Address 2659 destination option. The mobile node uses this information to 2660 determine which binding does not exist, in cases where the 2661 mobile node has several home addresses. 2663 Mobility options 2665 Variable-length field of such length that the complete Mobility 2666 Header is an integer multiple of 8 octets long. Contains one 2667 or more TLV-encoded mobility options. The receiver MUST ignore 2668 and skip any options which it does not understand. 2670 There MAY be additional information, associated with this 2671 Binding Error message, that need not be present in all Binding 2672 Error messages sent. This use of mobility options also allows 2673 for future extensions to the format of the Binding Error 2674 message to be defined. The encoding and format of defined 2675 options are described in Section 6.2. This specification does 2676 not define any options valid for the Binding Error message. 2678 The Header Length field in the Mobility Header for this message 2679 MUST be set to 3 (since unit is 8 octets) plus the total length of 2680 all mobility options present (also in 8 octet units). If no actual 2681 options are present in this message, no padding is necessary. 2683 6.2. Mobility Options 2685 6.2.1. Format 2687 In order to allow optional fields that may not be needed in every use 2688 of any given Mobility Header, and to allow future extensions to the 2689 format of these messages to be defined, any of the Mobility Header 2690 messages defined in this document MAY include one or more mobility 2691 options. 2693 Such options are included in the data portion of the message itself, 2694 after the fixed portion of the message data specified in section 6.1. 2696 The presence of such options will be indicated by the Header Len of 2697 the Mobility Header. 2699 These options are encoded within the remaining space of the message 2700 data for that message, using a type-length-value (TLV) format as 2701 follows: 2703 0 1 2 3 2704 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 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 |Option Type | Option Len | Option Data... | 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 Option Type 2711 8-bit identifier of the type of mobility option. When 2712 processing a Mobility Header containing an option for which 2713 the Option Type value is not recognized by the receiver, 2714 the receiver MUST quietly ignore and skip over the option, 2715 correctly handling any remaining options in the message. 2717 Option Length 2719 8-bit unsigned integer. Length of this mobility option, in 2720 octets. The Option Len does not include the length of the 2721 Option Type and Option Len fields. 2723 Option Data 2725 A variable length field that contains data specific to the 2726 option. 2728 The following subsections specify the Option types which are 2729 currently defined for use in the Mobility Header. 2731 Implementations MUST silently ignore any mobility options that they 2732 do not understand. 2734 6.2.2. Pad1 2736 The Pad1 option does not have any alignment requirements. Its format 2737 is as follows: 2739 0 2740 0 1 2 3 4 5 6 7 2741 +-+-+-+-+-+-+-+-+ 2742 | 0 | 2743 +-+-+-+-+-+-+-+-+ 2745 NOTE! the format of the Pad1 option is a special case -- it has 2746 neither Option Len nor Option Data fields. 2748 The Pad1 option is used to insert one octet of padding in the 2749 Mobility Options area of a Mobility Header. If more than one octet 2750 of padding is required, the PadN option, described next, should be 2751 used rather than multiple Pad1 options. 2753 6.2.3. PadN 2755 The PadN option does not have any alignment requirements. Its format 2756 is as follows: 2758 0 1 2759 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2761 | 1 | Option Len | Option Data 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2764 The PadN option is used to insert two or more octets of padding in 2765 the Mobility Options area of a Mobility Header message. For N octets 2766 of padding, the Option Len field contains the value N, and the Option 2767 Data consists of N-2 zero-valued octets. Option data MUST be ignored 2768 by the receiver. 2770 6.2.4. Unique Identifier 2772 The Unique Identifier option has the alignment requirement of 2n. 2773 Its format is as follows: 2775 0 1 2 3 2776 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 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | 2 | 4 | Unique Identifier | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 The Unique Identifier option is valid only in Binding Refresh 2782 Request, HoTI, CoTI, and Binding Update messages. The Unique 2783 Identifier field contains a 16-bit value that serves to uniquely 2784 identify a Binding Request among those sent by this Source Address, 2785 and to allow the HoTI, CoTI, and Binding Update to identify the 2786 specific Binding Refresh Request to which it responds. This matching 2787 of Binding Updates to Binding Refresh Requests is required in the 2788 procedure for renumbering the home subnet while a mobile node is away 2789 from home (Section 10.9.1). 2791 6.2.5. Alternate Care-of Address 2793 The Alternate Care-of Address option has an alignment requirement of 2794 8n+6. Its format is as follows: 2796 0 1 2 3 2797 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 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | 3 | 18 | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 | | 2802 + + 2803 | | 2804 + Alternate Care-of Address + 2805 | | 2806 + + 2807 | | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 The Alternate Care-of Address option is valid only in Binding Update 2811 message. The Alternate Care-of Address field contains an address to 2812 use as the care-of address for the binding, rather than using the 2813 Source Address of the packet as the care-of address. 2815 6.2.6. Nonce Indices 2817 The Nonce Indices option has an alignment requirement of 2n. Its 2818 format is as follows: 2820 0 1 2 3 2821 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 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 | 4 | 6 | 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | Home Nonce Index | Care-of Nonce Index | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 The Nonce Indices option is valid only in the Binding Update message, 2829 and only when present together with an Binding Authorization Data 2830 option. 2832 The Home Nonce Index field tells the correspondent node that receives 2833 the message which of the challenge values (Ni) are to be used to 2834 authenticate the Binding Update. 2836 The Care-of Nonce Index field tells the correspondent node that 2837 receives the message which of the challenge values (Nj) are to be 2838 used to authenticate the Binding Update. 2840 6.2.7. Binding Authorization Data 2842 The Binding Authorization Data option has an alignment requirement of 2843 4n+2. Its format is as follows: 2845 0 1 2 3 2846 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 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 | 5 | 2 + Len | 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 | | 2851 + + 2852 | Authenticator | 2853 + + 2854 | | 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 The Binding Authorization Data option is valid only in the Binding 2858 Refresh Request, Binding Update, and Binding Acknowledgment messages. 2860 The Option Len field contains the value 2 + Len, where Len is the 2861 length of the authenticator in octets. 2863 The Authenticator field contains a cryptographic value which can be 2864 used to determine that the message in question comes from the right 2865 authority. Rules for calculating this value depend on the used 2866 authorization procedure. This specification gives the rules only for 2867 the return routability procedure. For this procedure, this option 2868 can only appear in a Binding Update message and rules for calculating 2869 the Authenticator value are described in Section 6.1.7. 2871 6.3. Home Address Destination Option 2873 The Home Address destination option is used in a packet sent by a 2874 mobile node while away from home, to inform the recipient of that 2875 packet of the mobile node's home address. For packets sent by a 2876 mobile node while away from home, the mobile node generally uses one 2877 of its care-of addresses as the Source Address in the packet's IPv6 2878 header. By including a Home Address option in the IPv6 Destination 2879 Options header of the packet, the correspondent node receiving the 2880 packet is able to substitute the mobile node's home address for 2881 this care-of address when processing the packet. This makes the 2882 use of the care-of address transparent to the correspondent node 2883 above the Mobile IPv6 support level. Note that multicast addresses, 2884 link-local addresses, loopback addresses, IPv4 mapped addresses, 2885 and the unspecified address, MUST NOT be used within a Home Address 2886 option. The Home Address Option MUST not appear more than once in 2887 any given packet, except inside the payload part of the packet if 2888 tunneling is involved. 2890 The Home Address option is encoded in type-length-value (TLV) format 2891 as follows: 2893 0 1 2 3 2894 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 2895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2896 | Option Type | Option Length | 2897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 | | 2899 + + 2900 | | 2901 + Home Address + 2902 | | 2903 + + 2904 | | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 Option Type 2909 201 = 0xC9 2911 Option Length 2913 8-bit unsigned integer. Length of the option, in octets, 2914 excluding the Option Type and Option Length fields. This field 2915 MUST be set to 16. 2917 Home Address 2919 The home address of the mobile node sending the packet. 2921 IPv6 requires that options appearing in a Hop-by-Hop Options 2922 header or Destination Options header be aligned in a packet so that 2923 multi-octet values within the Option Data field of each option fall 2924 on natural boundaries (i.e., fields of width n octets are placed at 2925 an integer multiple of n octets from the start of the header, for 2926 n = 1, 2, 4, or 8) [6]. The alignment requirement [6] for the Home 2927 Address option is 8n+6. 2929 The three highest-order bits of the Option Type are encoded to 2930 indicate specific processing of the option [6]. For the Home Address 2931 option, these three bits are set to 110, indicating that any IPv6 2932 node processing this option that does not recognize the Option Type 2933 must discard the packet and, only if the packet's Destination Address 2934 was not a multicast address, return an ICMP Parameter Problem, 2935 Code 2, message to the packet's Source Address; and that the data 2936 within the option cannot change en-route to the packet's final 2937 destination. 2939 A packet MUST NOT contain more than one Home Address option, except 2940 that an encapsulated packet [4] MAY contain a separate Home Address 2941 option associated with each encapsulating IP header. 2943 The Home Address option MUST be placed as follows: 2945 - After the Routing Header, if that header is present 2947 - Before the Fragment Header, if that header is present 2949 - Before the AH Header or ESP Header, if either one of those 2950 headers is present 2952 Due to the threat of reflection attacks through the use of this 2953 option, this specification requires that packets containing Home 2954 Address option MUST be dropped if there is no corresponding Binding 2955 Cache Entry for that home address with the currently registered 2956 care-of address matching the source address of the packet. If the 2957 packet is dropped, the correspondent nodes SHOULD send the Binding 2958 Error message to the source address of the packet that contained the 2959 Home Address option (see Section 6.1.9). The Status field in this 2960 message should be set to 1. These messages SHOULD be rate-limited. 2962 No additional authentication of the Home Address option is 2963 required, except that if the IPv6 header of a packet is covered 2964 by authentication, then that authentication MUST also cover the 2965 Home Address option; this coverage is achieved automatically by the 2966 definition of the Option Type code for the Home Address option, since 2967 it indicates that the data within the option cannot change en-route 2968 to the packet's final destination, and thus the option is included in 2969 the authentication computation. By requiring that any authentication 2970 of the IPv6 header also cover the Home Address option, the security 2971 of the Source Address field in the IPv6 header is not compromised by 2972 the presence of a Home Address option. Security issues related to 2973 the Home Address option are discussed further in Section 5. When 2974 attempting to verify authentication data in a packet that contains 2975 a Home Address option, the receiving node MUST make the calculation 2976 as if the care-of address were present in the Home Address option, 2977 and the home address were present in the source IPv6 address field 2978 of the IPv6 header. This conforms with the calculation specified in 2979 section 11.2.2. 2981 The inclusion of a Home Address destination option in a packet 2982 affects the receiving node's processing of only this single packet; 2983 no state is created or modified in the receiving node as a result 2984 of receiving a Home Address option in a packet. In particular, the 2985 presence of a Home Address option in a received packet MUST NOT alter 2986 the contents of the receiver's Binding Cache and MUST NOT cause any 2987 changes in the routing of subsequent packets sent by this receiving 2988 node. 2990 6.4. Routing Header type 2 2992 Mobile IPv6 uses a Routing header to carry the Home Address for 2993 packets sent from a correspondent node to a mobile node. The Care of 2994 Address of the mobile node is carried in the IPv6 destination field. 2996 This uses a different Routing header type than defined for "regular" 2997 IPv6 source routing, enabling firewalls to apply different rules 2998 to source routed packets than to MIPv6. This Routing header type 2999 (Type 2) is restricted to carry only one IPv6 address. All IPv6 3000 nodes which process this Routing header MUST verify that the address 3001 contained within is the node's own home address in order to prevent 3002 packets from being forwarded outside the node. 3004 6.4.1. Routing Header Packet format 3006 The Type 2 Routing header has the following format: 3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3009 | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 | Reserved | 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 | | 3014 + + 3015 | | 3016 + Home Address + 3017 | | 3018 + + 3019 | | 3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 Next Header 3024 8-bit selector. Identifies the type of header immediately 3025 following the Routing header. Uses the same values as the IPv4 3026 Protocol field [10]. 3028 Hdr Ext Len 3030 8-bit unsigned integer. Length of the Routing header in 3031 8-octet units, not including the first 8 octets. For the Type 3032 2 Routing header, Hdr Ext Len is always 2. 3034 Routing Type 3036 8-bit unsigned integer that contains the value 2. 3038 Segments Left 3040 8-bit unsigned integer. Number of route segments remaining; 3041 i.e., number of explicitly listed intermediate nodes still to 3042 be visited before reaching the final destination. Packets 3043 transmitted through an interface have Segments left is always 1 3044 in this type of Routing header. 3046 Reserved 3048 32-bit reserved field. Initialized to zero for transmission, 3049 and ignored on reception. 3051 Home Address 3053 The Home Address of the destination Mobile Node. 3055 The ordering rules for extension headers in an IPv6 packet are 3056 described in Section 4.1 of [6]. The new Routing header (Type 2) 3057 defined for Mobile IPv6 follows the same ordering as other routing 3058 headers. If more than one Routing header (e.g., both a Type 0 and a 3059 Type 2 Routing header are present), the Type 2 Routing header should 3060 follow all other Routing headers. Otherwise the order of routing 3061 headers is independent of their type and follows [6]. 3063 In addition, the general procedures defined by IPv6 for Routing 3064 headers suggest that a received Routing header MAY be automatically 3065 "reversed" to construct a Routing header for use in any response 3066 packets sent by upper-layer protocols, if the received packet is 3067 authenticated [6]. This MUST NOT be done automatically for Type 2 3068 Routing headers. 3070 6.5. ICMP Home Agent Address Discovery Request Message 3072 The ICMP Home Agent Address Discovery Request message is used by a 3073 mobile node to initiate the dynamic home agent address discovery 3074 mechanism, as described in Sections 10.9 and 11.3.2. The mobile 3075 node sends a Home Agent Address Discovery Request message to the 3076 "Mobile IPv6 Home-Agents" anycast address for its own home subnet 3077 prefix [11], and one of the home agents responds to the mobile node 3078 with a Home Agent Address Discovery Reply message, providing a list 3079 of the routers on the mobile node's home link serving as home agents. 3081 0 1 2 3 3082 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 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 | Type | Code | Checksum | 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 | Identifier | Reserved | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 Type 3090 150 3092 Code 3094 0 3096 Checksum 3098 The ICMP checksum [5]. 3100 Identifier 3102 An identifier to aid in matching Home Agent Address Discovery 3103 Reply messages to this Home Agent Address Discovery Request 3104 message. 3106 Reserved 3108 This field is unused. It MUST be initialized to zero by the 3109 sender and MUST be ignored by the receiver. 3111 The Source Address of the Home Agent Address Discovery Request 3112 message packet MUST be one of the mobile node's current care-of 3113 addresses. The home agent MUST then return the Home Agent Address 3114 Discovery Reply message directly to the Source Address chosen by the 3115 mobile node. Note that, at the time of performing this dynamic home 3116 agent address discovery, it is likely that the mobile node is not 3117 registered with any home agent within the specified anycast group. 3119 6.6. ICMP Home Agent Address Discovery Reply Message 3121 The ICMP Home Agent Address Discovery Reply message is used by 3122 a home agent to respond to a mobile node using the dynamic home 3123 agent address discovery mechanism, as described in Sections 10.9 3124 and 11.3.2. The mobile node sends a Home Agent Address Discovery 3125 Request message to the "Mobile IPv6 Home-Agents" anycast address 3126 for its own home subnet prefix [11], and one of the home agents 3127 responds to the mobile node with a Home Agent Address Discovery Reply 3128 message, providing a list of the routers on the mobile node's home 3129 link serving as home agents. 3131 0 1 2 3 3132 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 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 | Type | Code | Checksum | 3135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3136 | Identifier | | 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3138 | | 3139 + Reserved + 3140 | | 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3142 | | 3143 + + 3144 . . 3145 . Home Agent Addresses . 3146 . . 3147 + + 3148 | | 3149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3151 Type 3153 151 3155 Code 3157 0 3159 Checksum 3161 The ICMP checksum [5]. 3163 Identifier 3165 The identifier from the invoking Home Agent Address Discovery 3166 Request message. 3168 Reserved 3170 This field is unused. It MUST be initialized to zero by the 3171 sender and MUST be ignored by the receiver. 3173 Home Agent Addresses 3175 A list of addresses of home agents on the home link for the 3176 mobile node. The number of addresses present in the list is 3177 indicated by the remaining length of the IPv6 packet carrying 3178 the Home Agent Address Discovery Reply message. 3180 6.7. ICMP Mobile Prefix Solicitation Message Format 3182 The ICMP Mobile Prefix Solicitation Message is sent by a mobile node 3183 to its home agent while it is away from home. The purpose of the 3184 message is to solicit a Mobile Prefix Advertisement from the home 3185 agent, which will allow the mobile node to gather prefix information 3186 about its home network. This information can be used to configure 3187 home address(es) by stateless address autoconfiguration [33], 3188 or update address(es) according to changes in prefix information 3189 supplied by the home agent. 3191 The Mobile Prefix Solicitation is similar to the Router Solicitation 3192 used in Neighbor Discovery [20], except it is routed from the mobile 3193 node on the visited network to the home agent on the home network by 3194 usual unicast routing rules. 3196 0 1 2 3 3197 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 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 | Type | Code | Checksum | 3200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3201 | Reserved | 3202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 IP Fields: 3206 Source Address 3208 The mobile node's care-of address. 3210 Destination Address 3212 The address of the mobile node's home agent. This home agent 3213 must be on the link which the mobile node wishes to learn 3214 prefix information about. 3216 Hop Limit 3218 Set to an initial hop limit value, and this message is routed 3219 according to the rules of a typical unicast packet. A hop 3220 limit of 64 is currently suggested [30]. 3222 Authentication Header 3224 If a Security Association for the IP Authentication Header 3225 exists between the sender and the destination address, then the 3226 sender SHOULD include this header. [subject to change] 3228 ICMP Fields: 3230 Type 3232 152 3234 Code 3236 0 3238 Checksum 3240 The ICMP checksum [5]. 3242 Reserved 3244 This field is unused. It MUST be initialized to zero by the 3245 sender and MUST be ignored by the receiver. 3247 6.8. ICMP Mobile Prefix Advertisement Message Format 3249 A home agent will send a Mobile Prefix Advertisement message to a 3250 mobile node to distribute prefix information about the home link 3251 while the mobile node is traveling away from the home network. This 3252 will occur in response to a Mobile Prefix Solicitation with an 3253 Advertisement, or by an unsolicited Advertisement sent according to 3254 the rules in Section 10.9.1. 3256 0 1 2 3 3257 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 3258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3259 | Type | Code | Checksum | 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 | Options ... 3262 +-+-+-+-+-+-+-+-+-+-+-+- 3264 IP Fields: 3266 Source Address 3268 The home agent's address as the mobile node would expect to see 3269 it (i.e., same network prefix) 3271 Destination Address 3273 If this message is a response to a Mobile Prefix Solicitation, 3274 the Source Address field from that packet. For unsolicited 3275 messages, the mobile node's care-of address SHOULD be used, if 3276 it is currently registered with the home agent. Otherwise, the 3277 mobile node's home address SHOULD be used. 3279 Authentication Header 3281 An AH header MUST be included unless the mobile node has yet to 3282 configure a home address. 3284 ICMP Fields: 3286 Type 3288 153 3290 Code 3292 0 3294 Checksum 3296 The ICMP checksum [5]. 3298 Options: 3300 Prefix Information 3302 Each message contains one or more Prefix Information options. 3303 Each option carries the prefix(es) that the mobile node 3304 should use to configure its home address(es). Section 10.9.1 3305 describes which prefixes should be advertised to the mobile 3306 node. 3308 The Prefix Information option is defined in Section 4.6.2 3309 of [20], with modifications defined in Section 7.2 of this 3310 specification. The home agent MUST use this modified Prefix 3311 Information option to send the aggregate list of home network 3312 prefixes as defined in Section 10.9.1. 3314 The Mobile Prefix Advertisement sent by the home agent MAY include 3315 the Source Link-layer Address option defined in RFC 2461 [20], or the 3316 Advertisement Interval option specified in Section 7.3. 3318 Future versions of this protocol may define new option types. Mobile 3319 nodes MUST silently ignore any options they do not recognize and 3320 continue processing the message. 3322 7. Modifications to IPv6 Neighbor Discovery 3324 7.1. Modified Router Advertisement Message Format 3326 Mobile IPv6 modifies the format of the Router Advertisement 3327 message [20] by the addition of a single flag bit to indicate that 3328 the router sending the Advertisement message is serving as a home 3329 agent on this link. The format of the Router Advertisement message 3330 is as follows: 3332 0 1 2 3 3333 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 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | Type | Code | Checksum | 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | Reachable Time | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | Retrans Timer | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Options ... 3344 +-+-+-+-+-+-+-+-+-+-+-+- 3346 This format represents the following changes over that originally 3347 specified for Neighbor Discovery [20]: 3349 Home Agent (H) 3351 The Home Agent (H) bit is set in a Router Advertisement to 3352 indicate that the router sending this Router Advertisement is 3353 also functioning as a Mobile IP home agent on this link. 3355 Reserved 3357 Reduced from a 6-bit field to a 5-bit field to account for the 3358 addition of the Home Agent (H) bit. 3360 7.2. Modified Prefix Information Option Format 3362 Mobile IPv6 requires knowledge of a router's global address for two 3363 reasons: 3365 - To allow a home agent (a router) to learn the address of all 3366 other home agents on the link for which it is providing home 3367 agent service, for use in building its Home Agents List as 3368 part of the dynamic home agent address discovery mechanism 3369 (Sections 10.9 and 11.3.2). 3371 - To allow a mobile node to send a Binding Update to a router on 3372 the link on which its previous care-of address is located, for 3373 purposes of establishing forwarding from this previous care-of 3374 address to its new care-of address (Section 11.6.6). 3376 However, Neighbor Discovery [20] only advertises a router's 3377 link-local address, by requiring this address to be used as the IP 3378 Source Address of each Router Advertisement. 3380 Mobile IPv6 extends Neighbor Discovery to allow a router to easily 3381 and efficiently advertise its global address, by the addition of a 3382 single flag bit in the format of a Prefix Information option for 3383 use in Router Advertisement messages. The format of the Prefix 3384 Information option is as follows: 3386 0 1 2 3 3387 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 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 | Type | Length | Prefix Length |L|A|R|Reserved1| 3390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3391 | Valid Lifetime | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 | Preferred Lifetime | 3394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 | Reserved2 | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 | | 3398 + + 3399 | | 3400 + Prefix + 3401 | | 3402 + + 3403 | | 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3406 This format represents the following changes over that originally 3407 specified for Neighbor Discovery [20]: 3409 Router Address (R) 3411 1-bit router address flag. When set, indicates that the 3412 Prefix field, in addition to advertising the indicated prefix, 3413 contains a complete IP address assigned to the sending router. 3414 This router IP address has the same scope and conforms to the 3415 same lifetime values as the advertised prefix. This use of 3416 the Prefix field is compatible with its use in advertising 3417 the prefix itself, since prefix advertisement uses only the 3418 leading number Prefix bits specified by the Prefix Length 3419 field. Interpretation of this flag bit is thus independent 3420 of the processing required for the On-Link (L) and Autonomous 3421 Address-Configuration (A) flag bits. 3423 Reserved1 3425 Reduced from a 6-bit field to a 5-bit field to account for the 3426 addition of the Router Address (R) bit. 3428 In a solicited Router Advertisement, a home agent MUST, and all other 3429 routers SHOULD, include at least one Prefix Information option with 3430 the Router Address (R) bit set. Neighbor Discovery specifies that, 3431 if including all options in a Router Advertisement causes the size of 3432 the Advertisement to exceed the link MTU, multiple Advertisements can 3433 be sent, each containing a subset of the options [20]. In this case, 3434 at least one of these multiple Advertisements being sent instead 3435 of a single larger solicited Advertisement, MUST include a Prefix 3436 Information option with the Router Address (R) bit set. 3438 All routers SHOULD include at least one Prefix Information option 3439 with the Router Address (R) bit set, in each unsolicited multicast 3440 Router Advertisement that they send. If multiple Advertisements 3441 are being sent instead of a single larger unsolicited multicast 3442 Advertisement, at least one of these multiple Advertisements SHOULD 3443 include a Prefix Information option with the Router Address (R) bit 3444 set. 3446 7.3. New Advertisement Interval Option Format 3448 Mobile IPv6 defines a new Advertisement Interval option, used in 3449 Router Advertisement messages to advertise the interval at which the 3450 sending router sends unsolicited multicast Router Advertisements. 3451 The format of the Advertisement Interval option is as follows: 3453 0 1 2 3 3454 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 3455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 | Type | Length | Reserved | 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3458 | Advertisement Interval | 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 Type 3463 7 3465 Length 3467 8-bit unsigned integer. The length of the option (including 3468 the type and length fields) in units of 8 octets. The value of 3469 this field MUST be 1. 3471 Reserved 3473 This field is unused. It MUST be initialized to zero by the 3474 sender and MUST be ignored by the receiver. 3476 Advertisement Interval 3478 32-bit unsigned integer. The maximum time, in milliseconds, 3479 between successive unsolicited router Router Advertisement 3480 messages sent by this router on this network interface. Using 3481 the conceptual router configuration variables defined by 3482 Neighbor Discovery [20], this field MUST be equal to the value 3483 MaxRtrAdvInterval, expressed in milliseconds. 3485 Routers MAY include this option in their Router Advertisements. A 3486 mobile node receiving a Router Advertisement containing this option 3487 SHOULD utilize the specified Advertisement Interval for that router 3488 in its movement detection algorithm, as described in Section 11.4.1. 3490 This option MUST be silently ignored for other Neighbor Discovery 3491 messages. 3493 7.4. New Home Agent Information Option Format 3495 Mobile IPv6 defines a new Home Agent Information option, used in 3496 Router Advertisement messages sent by a home agent to advertise 3497 information specific to this router's functionality as a home agent. 3498 The format of the Home Agent Information option is as follows: 3500 0 1 2 3 3501 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 3502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3503 | Type | Length | Reserved | 3504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3505 | Home Agent Preference | Home Agent Lifetime | 3506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3508 Type 3510 8 3512 Length 3514 8-bit unsigned integer. The length of the option (including 3515 the type and length fields) in units of 8 octets. The value of 3516 this field MUST be 1. 3518 Reserved 3520 This field is unused. It MUST be initialized to zero by the 3521 sender and MUST be ignored by the receiver. 3523 Home Agent Preference 3525 16-bit signed, twos-complement integer. The preference for 3526 the home agent sending this Router Advertisement, for use in 3527 ordering the addresses returned to a mobile node in the Home 3528 Agent Addresses field of a Home Agent Address Discovery Reply 3529 message. Higher values mean more preferable. If this option 3530 is not included in a Router Advertisement in which the Home 3531 Agent (H) bit is set, the preference value for this home agent 3532 SHOULD be considered to be 0. Values greater than 0 indicate a 3533 home agent more preferable than this default value, and values 3534 less than 0 indicate a less preferable home agent. 3536 The manual configuration of the Home Agent Preference value 3537 is described in Section 8.3. In addition, the sending home 3538 agent MAY dynamically set the Home Agent Preference value, for 3539 example basing it on the number of mobile nodes it is currently 3540 serving or on its remaining resources for serving additional 3541 mobile nodes; such dynamic settings are beyond the scope of 3542 this document. Any such dynamic setting of the Home Agent 3543 Preference, however, MUST set the preference appropriately, 3544 relative to the default Home Agent Preference value of 0 that 3545 may be in use by some home agents on this link (i.e., a home 3546 agent not including a Home Agent Information option in its 3547 Router Advertisements will be considered to have a Home Agent 3548 Preference value of 0). 3550 Home Agent Lifetime 3552 16-bit unsigned integer. The lifetime associated with the 3553 home agent in units of seconds. The default value is the same 3554 as the Router Lifetime, as specified in the main body of the 3555 Router Advertisement message. The maximum value corresponds 3556 to 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 3557 Lifetime applies only to this router's usefulness as a home 3558 agent; it does not apply to information contained in other 3559 message fields or options. 3561 Home agents MAY include this option in their Router Advertisements. 3562 This option MUST NOT be included in a Router Advertisement in which 3563 the Home Agent (H) bit (see Section 7.1) is not set. If this option 3564 is not included in a Router Advertisement in which the Home Agent (H) 3565 bit is set, the lifetime for this home agent MUST be considered to 3566 be the same as the Router Lifetime in the Router Advertisement. 3567 If multiple Advertisements are being sent instead of a single 3568 larger unsolicited multicast Advertisement, all of the multiple 3569 Advertisements with the Router Address (R) bit set MUST include this 3570 option with the same contents, otherwise this option MUST be omitted 3571 from all Advertisements. 3573 This option MUST be silently ignored for other Neighbor Discovery 3574 messages. 3576 If both the Home Agent Preference and Home Agent Lifetime are set 3577 to their default values specified above, this option SHOULD NOT be 3578 included in the Router Advertisement messages sent by this home 3579 agent. 3581 7.5. Changes to Sending Router Advertisements 3583 The Neighbor Discovery protocol specification [20] limits routers to 3584 a minimum interval of 3 seconds between sending unsolicited multicast 3585 Router Advertisement messages from any given network interface 3586 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 3588 "Routers generate Router Advertisements frequently enough 3589 that hosts will learn of their presence within a few 3590 minutes, but not frequently enough to rely on an absence 3591 of advertisements to detect router failure; a separate 3592 Neighbor Unreachability Detection algorithm provides failure 3593 detection." 3595 This limitation, however, is not suitable to providing timely 3596 movement detection for mobile nodes. Mobile nodes detect their 3597 own movement by learning the presence of new routers as the mobile 3598 node moves into wireless transmission range of them (or physically 3599 connects to a new wired network), and by learning that previous 3600 routers are no longer reachable. Mobile nodes MUST be able to 3601 quickly detect when they move to a link served by a new router, so 3602 that they can acquire a new care-of address and send Binding Updates 3603 to register this care-of address with their home agent and to notify 3604 correspondent nodes as needed. 3606 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 3607 this limit such that routers MAY send unsolicited multicast Router 3608 Advertisements more frequently. In particular, on network interfaces 3609 where the router is expecting to provide service to visiting mobile 3610 nodes (e.g., wireless network interfaces), or on which it is serving 3611 as a home agent to one or more mobile nodes (who may return home and 3612 need to hear its Advertisements), the router SHOULD be configured 3613 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 3614 to allow sending of unsolicited multicast Router Advertisements more 3615 often. Recommended values for these limits are: 3617 - MinRtrAdvInterval 0.05 seconds 3619 - MaxRtrAdvInterval 1.5 seconds 3621 Use of these modified limits MUST be configurable, and specific 3622 knowledge of the type of network interface in use SHOULD be taken 3623 into account in configuring these limits for each network interface. 3625 When sending unsolicited multicast Router Advertisements more 3626 frequently than the standard limit on unsolicited multicast 3627 Advertisement frequency, the sending router need not include all 3628 options in each of these Advertisements, but it SHOULD include at 3629 least one Prefix Information option with the Router Address (R) bit 3630 set (Section 7.2) in each. 3632 7.6. Changes to Sending Router Solicitations 3634 In addition to the limit on routers sending unsolicited multicast 3635 Router Advertisement messages (Section 7.5), Neighbor Discovery 3636 defines limits on nodes sending Router Solicitation messages, such 3637 that a node SHOULD send no more than 3 Router Solicitations, and that 3638 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 3639 However, these limits prevent a mobile node from finding a new 3640 default router (and thus a new care-of address) quickly as it moves 3641 about. 3643 Mobile IPv6 relaxes this limit such that, while a mobile node is away 3644 from home, it MAY send Router Solicitations more frequently. The 3645 following limits for sending Router Solicitations are recommended for 3646 mobile nodes while away from home: 3648 - A mobile node that is not configured with any current care-of 3649 address (e.g., the mobile node has moved since its previous 3650 care-of address was configured), MAY send more than the defined 3651 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 3652 Solicitations. 3654 - The rate at which a mobile node sends Router Solicitations MUST 3655 be limited, although a mobile node MAY send Router Solicitations 3656 more frequently than the defined Neighbor Discovery limit of 3657 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 3658 be configurable, and specific knowledge of the type of network 3659 interface in use SHOULD be taken into account in configuring this 3660 limit for each network interface. A recommended minimum interval 3661 is 1 second. 3663 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 3664 a mobile node MUST reduce the rate at which it sends subsequent 3665 Router Solicitations. Subsequent Router Solicitations SHOULD 3666 be sent using a binary exponential backoff mechanism, doubling 3667 the interval between consecutive Router Solicitations, up to a 3668 maximum interval. The maximum interval MUST be configurable and 3669 SHOULD be chosen appropriately based on the characteristics of 3670 the type of network interface in use. 3672 - While still searching for a new default router and care-of 3673 address, a mobile node MUST NOT increase the rate at which it 3674 sends Router Solicitations unless it has received a positive 3675 indication (such as from lower network layers) that it has moved 3676 to a new link. After successfully acquiring a new care-of 3677 address, the mobile node SHOULD also increase the rate at which 3678 it will send Router Solicitations when it next begins searching 3679 for a new default router and care-of address. 3681 - A mobile node that is currently configured with a care-of address 3682 SHOULD NOT send Router Solicitations to the default router 3683 on it current link, until its movement detection algorithm 3684 (Section 11.4.1) determines that it has moved and that its 3685 current care-of address might no longer be valid. 3687 8. Requirements for Types of IPv6 Nodes 3689 Mobile IPv6 places some special requirements on the functions 3690 provided by different types of IPv6 nodes. This section summarizes 3691 those requirements, identifying the functionality each requirement 3692 is intended to support. Further details on this functionality is 3693 provided in the following sections. 3695 8.1. Requirements for All IPv6 Hosts and Routers 3697 Since any IPv6 node may at any time be a correspondent node of a 3698 mobile node, either sending a packet to a mobile node or receiving a 3699 packet from a mobile node, the following requirements apply to ALL 3700 IPv6 nodes (whether host or router, whether mobile or stationary): 3702 - Every IPv6 node MUST be able to process a Home Address option 3703 received in any IPv6 packet. 3705 - Every IPv6 node SHOULD be able to participate in a return 3706 routability procedure, process Binding Update messages, and to 3707 return a Binding Acknowledgement option if the Acknowledge (A) 3708 bit is set in the received Binding Update. 3710 - Every IPv6 node SHOULD be able to maintain a Binding Cache of the 3711 bindings received in accepted Binding Updates. 3713 8.2. Requirements for All IPv6 Routers 3715 The following requirements apply to all IPv6 routers, even those not 3716 serving as a home agent for Mobile IPv6: 3718 - Every IPv6 router SHOULD be able to send an Advertisement 3719 Interval option in each of its Router Advertisements, to aid 3720 movement detection by mobile nodes. The use of this option in 3721 Router Advertisements MUST be configurable. 3723 - Every IPv6 router SHOULD be able to support sending unsolicited 3724 multicast Router Advertisements at the faster rate described in 3725 Section 7.5. The use of this faster rate MUST be configurable. 3727 - Each router SHOULD include at least one prefix with the 'R' bit 3728 set and with its full IP address in its router advertisements. 3730 - Filtering routers SHOULD support different rules for Type 0 and 3731 Type 2 Routing headers so that filtering of source routed packets 3732 (Type 0) will not necessarily limit MIPv6 traffic via Type 2 3733 Routing headers. 3735 8.3. Requirements for IPv6 Home Agents 3737 In order for a mobile node to operate correctly while away from home, 3738 at least one IPv6 router on the mobile node's home link must function 3739 as a home agent for the mobile node. The following additional 3740 requirements apply to all IPv6 routers capable of serving as a home 3741 agent: 3743 - Every home agent MUST be able to maintain an entry in its Binding 3744 Cache for each mobile node for which it is serving as the home 3745 agent. Each such Binding Cache entry records the mobile node's 3746 binding with its primary care-of address and is marked as a "home 3747 registration". 3749 - Every home agent MUST be able to intercept packets (using proxy 3750 Neighbor Discovery) addressed to a mobile node for which it is 3751 currently serving as the home agent, on that mobile node's home 3752 link, while the mobile node is away from home. 3754 - Every home agent MUST be able to encapsulate such intercepted 3755 packets in order to tunnel them to the primary care-of address 3756 for the mobile node indicated in its binding in the home agent's 3757 Binding Cache. 3759 - Every home agent MUST support decapsulating reverse tunneled 3760 packets sent to it from a mobile node's home address. Every home 3761 agent MUST also check that the source address in the tunneled 3762 packets corresponds to the currently registered location of the 3763 mobile node. 3765 - Every home agent MUST be able to return a Binding Acknowledgement 3766 message in response to a Binding Update option received with the 3767 Acknowledge (A) bit set. 3769 - Every home agent MUST maintain a separate Home Agents List for 3770 each link on which it is serving as a home agent, as described in 3771 Section 4.5. 3773 - Every home agent MUST be able to accept packets addressed to 3774 the "Mobile IPv6 Home-Agents" anycast address for the subnet 3775 on which it is serving as a home agent [11], and MUST be 3776 able to participate in dynamic home agent address discovery 3777 (Section 10.9). 3779 - Every home agent SHOULD support a configuration mechanism to 3780 allow a system administrator to manually set the value to be sent 3781 by this home agent in the Home Agent Preference field of the Home 3782 Agent Information Option in Router Advertisements that it sends. 3784 - Every home agent SHOULD support sending ICMP Mobile 3785 Prefix Advertisements, and SHOULD respond to Mobile Prefix 3786 Solicitations. 3788 8.4. Requirements for IPv6 Mobile Nodes 3790 Finally, the following requirements apply to all IPv6 nodes capable 3791 of functioning as mobile nodes: 3793 - Every IPv6 mobile node MUST be able to perform IPv6 encapsulation 3794 and decapsulation [4]. 3796 - Every IPv6 mobile node MUST support the return routability 3797 procedure and sending Binding Update messages, as specified in 3798 Sections 11.6.1, 11.6.2, and 11.6.6; and MUST be able to receive 3799 and process Binding Acknowledgement messages, as specified in 3800 Section 11.6.3. 3802 - Every IPv6 mobile node MUST support use of the dynamic home agent 3803 address discovery mechanism, as described in Section 11.3.2. 3805 - Every IPv6 mobile node MUST maintain a Binding Update List in 3806 which it records the IP address of each other node to which it 3807 has sent a Binding Update, for which the Lifetime sent in that 3808 binding has not yet expired. 3810 - Every IPv6 mobile node MUST support receiving a Binding Refresh 3811 Request, by responding with a Binding Update message. 3813 - Every IPv6 mobile node MUST support sending packets containing a 3814 Home Address option. This option MUST be included in all packets 3815 sent to a correspondent node when the following three conditions 3816 apply: The correspondent node has a binding with this mobile 3817 node. The mobile node is away from home. The packet would 3818 otherwise have been sent with the mobile node's home address as 3819 the IP Source Address. 3821 - Every IPv6 mobile node MUST maintain a Home Agents List, as 3822 described in Section 4.5. 3824 - Every mobile node MUST support receiving Mobile Prefix 3825 Advertisements and reconfiguring its home address based on the 3826 prefix information contained therein. 3828 9. Correspondent Node Operation 3830 This section explains the special processing required for the return 3831 routability and binding procedures, as well as to manage the binding 3832 cache, handle ICMP messages and send packets to a mobile node. 3834 9.1. Conceptual Data Structures 3836 Each IPv6 node maintains a Binding Cache of bindings for other nodes. 3837 A separate Binding Cache SHOULD be maintained by each IPv6 node for 3838 each of its IPv6 addresses. The Binding Cache MAY be implemented in 3839 any manner consistent with the external behavior described in this 3840 document, for example by being combined with the node's Destination 3841 Cache as maintained by Neighbor Discovery [20]. When sending a 3842 packet, the Binding Cache is searched before the Neighbor Discovery 3843 conceptual Destination Cache [20] (i.e., any Binding Cache entry for 3844 this destination SHOULD take precedence over any Destination Cache 3845 entry for the same destination). 3847 Each Binding Cache entry conceptually contains the following fields: 3849 - The home address of the mobile node for which this is the Binding 3850 Cache entry. This field is used as the key for searching the 3851 Binding Cache for the destination address of a packet being sent. 3852 If the destination address of the packet matches the home address 3853 in the Binding Cache entry, this entry SHOULD be used in routing 3854 that packet. 3856 - The care-of address for the mobile node indicated by the home 3857 address field in this Binding Cache entry. If the destination 3858 address of a packet being routed by a node matches the home 3859 address in this entry, the packet SHOULD be routed to this 3860 care-of address, as described in Section 9.6, for packets 3861 originated by this node, or in Section 10.5, if this node is the 3862 mobile node's home agent and the packet was intercepted by it on 3863 the home link. 3865 - A lifetime value, indicating the remaining lifetime for this 3866 Binding Cache entry. The lifetime value is initialized from 3867 the Lifetime field in the Binding Update that created or last 3868 modified this Binding Cache entry. Once the lifetime of this 3869 entry expires, the entry MUST be deleted from the Binding Cache. 3871 - A flag indicating whether or not this Binding Cache entry is a 3872 "home registration" entry. 3874 - A flag indicating whether or not this Binding Cache entry 3875 represents a mobile node that should be advertised as a router in 3876 proxy Neighbor Advertisements sent by this node on its behalf. 3878 This flag is only valid if the Binding Cache entry indicates that 3879 this is a "home registration" entry. 3881 - The length of the routing prefix for the home address. This 3882 field is only valid if the "home registration" flag is set on 3883 this Binding Cache entry. 3885 - The maximum value of the Sequence Number field received in 3886 previous Binding Updates for this mobile node home address. 3887 The Sequence Number field is 16 bits long, and all comparisons 3888 between Sequence Number values MUST be performed modulo 2**16. 3889 For example, using an implementation in the C programming 3890 language, a Sequence Number value A is greater than another 3891 Sequence Number value B if ((short)((a) - (b)) > 0), if the 3892 "short" data type is a 16-bit signed integer. 3894 - Recent usage information for this Binding Cache entry, as needed 3895 to implement the cache replacement policy in use in the Binding 3896 Cache and to assist in determining whether a Binding Refresh 3897 Request should be sent when the lifetime of this entry nears 3898 expiration. 3900 Binding Cache entries not marked as "home registrations" MAY be 3901 replaced at any time by any reasonable local cache replacement policy 3902 but SHOULD NOT be unnecessarily deleted. The Binding Cache for any 3903 one of a node's IPv6 addresses may contain at most one entry for 3904 each mobile node home address. The contents of a node's Binding 3905 Cache MUST NOT be changed in response to a Home Address option in 3906 a received packet. The contents of all of a node's Binding Cache 3907 entries, for each of its IPv6 addresses, MUST be cleared when the 3908 node reboots. 3910 9.2. Receiving Packets from a Mobile Node 3912 Packets sent by a mobile node with either a Home Address destination 3913 option or a Mobility Header (or both) require special processing at 3914 the correspondent node as explained below. 3916 9.2.1. Processing Mobility Header (MH) Messages 3918 All IPv6 correspondent nodes MUST observe the following rules when 3919 processing Mobility Header messages: 3921 1. If an MH message of unknown type is received (Section 6.1, the 3922 correspondent node SHOULD issue a Binding Error message to the 3923 packet's Source Address with Status field set to 2. Finally, the 3924 correspondent node MUST discard the packet. 3926 2. If the "Next Header" field is not NO_NXTHDR (59 decimal), the 3927 packet MUST be silently discarded. 3929 3. The checksum must be verified as per Section 6.1. 3931 Subsequent checks depend on the particular Mobility Header message. 3932 There are two types of Mobility Header messages. The return 3933 routability procedure (Section 9.3) is used to verify liveness of the 3934 mobile node at both its home address as well as its care-of address. 3935 These liveness probes are used to secure binding updates. 3937 The other type of Mobility Header messages are directly concerned 3938 with managing bindings (Section 9.4). 3940 9.2.2. Receiving Packets with Home Address Destination Option 3942 Packets sent by a mobile node while away from home MAY include a Home 3943 Address destination option, if the correspondent node has a Binding 3944 Cache Entry for that home address. It MUST process the option in a 3945 manner consistent with exchanging the Home Address field from the 3946 Home Address option into the IPv6 header, replacing the original 3947 value of the Source Address field there. However, any actual 3948 modifications to the Source Address field in the packet's IPv6 header 3949 MUST be carried out in such a fashion that further processing of such 3950 a packet after all IPv6 options processing (e.g., at the transport 3951 layer) does not depend on that information to know that the original 3952 Source Address was a care-of address, or that the Home Address option 3953 was used in the packet. 3955 Since the sending mobile node uses its home address at the transport 3956 layer when sending such a packet, the use of the care-of address 3957 and Home Address option is transparent to both the mobile node and 3958 the correspondent node above the level of the Home Address option 3959 generation and processing. 3961 Packets containing Home Address Option MUST be dropped if there is 3962 no corresponding Binding Cache Entry for that home address. In this 3963 case, the correspondent nodes SHOULD send the Binding Error message 3964 to the source address of the packet that contained the Home Address 3965 Option (see Section 6.1.9). 3967 9.3. Return Routability Procedure 3969 A correspondent node engages in the return routability procedure in 3970 order to secure a subsequent Binding Update. This is a requirement 3971 in order to authorize the creation of new bindings as well as to 3972 refresh existing ones. In particular, these messages are used to 3973 establish the mobile node's liveness (responsiveness to packets) at 3974 both its care-of address as well as its home address. 3976 9.3.1. Receiving HoTI Messages 3978 The HoTI message initiates the return routability procedure from the 3979 mobile node's home address to the correspondent node. 3981 The correspondent node verifies the following: 3983 - MH Type field for this message is 1. 3985 - The Header Extension Length field MUST be greater than or equal 3986 to the length specified in Section 6.1.3. 3988 - The packet MUST NOT include a Home Address destination option. 3990 In preparation for sending the corresponding HoT Message, the 3991 correspondent node checks that it has the necessary material 3992 to engage in a return routability procedure, as specified in 3993 Section 5.5. For that procedure, the correspondent node MUST have a 3994 secret Kcn and a nonce Nj. If it does not have this material yet, 3995 it MUST produce it before continuing with the return routability 3996 procedure. 3998 Section 9.3.3 specifies further processing. 4000 9.3.2. Receiving CoTI Messages 4002 The CoTI message initiates the return routability procedure from the 4003 mobile node's care-of address location to the correspondent node. 4005 The correspondent node verifies the following: 4007 - MH Type field for this message is 2. 4009 - The Header Extension Length field MUST be greater than or equal 4010 to the length specified in Section 6.1.4. 4012 - The packet MUST NOT include a Home Address destination option. 4014 In preparation for sending the corresponding CoT Message, the 4015 correspondent node checks that it has the necessary material 4016 to engage in a return routability procedure, as specified in 4017 Section 5.5. For that procedure, the correspondent node MUST have a 4018 secret Kcn and a nonce Nl. If it does not have this material yet, 4019 it MUST produce it before continuing with the return routability 4020 procedure. 4022 Section 9.3.4 specifies further processing. 4024 9.3.3. Sending HoT Messages 4026 Unless already created, the correspondent node creates a "Home 4027 Cookie" and an associated "Home Nonce Index". It then creates a 4028 HoT message (Section 6.1.5) and sends it to the mobile node at the 4029 latter's home address. 4031 9.3.4. Sending CoT Messages 4033 Unless already created, the correspondent node creates a "Care-of 4034 Cookie" and an associated "Care-of Nonce Index". It then creates a 4035 CoT message (Section 6.1.6) and sends it to the mobile node at the 4036 latter's care-of address. 4038 9.4. Processing Bindings 4040 This section explains how the correspondent node processes the 4041 binding cache messages. These messages are: 4043 - Binding Update 4045 - Binding Refresh Request 4047 - Binding Acknowledgement 4049 - Binding Error 4051 9.4.1. Receiving Binding Updates 4053 Before accepting a Binding Update message, the receiving node MUST 4054 validate the Binding Update according to the following tests: 4056 - The packet MUST NOT contain a Home Address option. 4058 - The Header Len field in the Binding Update option is greater than 4059 or equal to the length specified in Section 6.1.7. 4061 - The Sequence Number field in the Binding Update message is 4062 greater than the Sequence Number received in the previous Binding 4063 Update for this home address, if any. As noted in Section 5.5, 4064 this Sequence Number comparison MUST be performed modulo 2**16. 4066 - The packet meets the specific authentication requirements for 4067 Binding Updates, defined in Section 5.5. 4069 When the return routability procedure is used as an authorization 4070 method, the following are also required: 4072 - The correspondent node MUST re-generate the Home Cookie and the 4073 Care-of Cookie from the information contained in the packet. 4074 It then generates the session key Kbu and uses it to verify 4075 the authenticator field in the Binding Update as specified in 4076 Section 6.1.7. Note that a care-of address different from the 4077 Source Address MAY have been specified by including an Alternate 4078 Care-of Address mobility option in the Binding Update message. 4079 When such message is received and the return routability 4080 procedure is used as an authorization method, the correspondent 4081 node MUST verify the authenticator by using the address within 4082 the Alternate Care-of Address in the calculations. 4084 - The Home and Care-of Nonce Index values in the Nonce Indices 4085 mobility option are recognized by the correspondent node. As 4086 described in Section 5.5, the correspondent node discards Nonce 4087 values that are too old. 4089 If the mobile node sends a sequence number which is not greater than 4090 the sequence number from the last successful Binding Update, then the 4091 receiving node MUST send back a Binding Acknowledgement with status 4092 code 141, and the last accepted sequence number in the Sequence 4093 Number field of the Binding Acknowledgement. 4095 If the mobile node sends a Home or Care-of Nonce Index value which is 4096 no longer recognized by the correspondent node, then the receiving 4097 node MUST send back a Binding Acknowledgement with status code 144 or 4098 145, respectively. 4100 Any Binding Update which fails to satisfy all of these tests for 4101 any reason other than insufficiency of the Sequence Number or Nonce 4102 Indices MUST be silently ignored, and the packet carrying the Binding 4103 Update MUST be discarded. 4105 In this section, the care-of address refers to the IPv6 address, 4106 which was originally located in the IPv6 header when the packet was 4107 transmitted by the mobile node. 4109 If the Binding Update is valid according to the tests above, then the 4110 Binding Update is processed further as follows: 4112 - If the Lifetime specified in the Binding Update is nonzero and 4113 the specified Care-of Address is not equal to the home address 4114 for the binding, then this is a request to cache a binding for 4115 the mobile node. If the Home Registration (H) bit is set in the 4116 Binding Update, the Binding Update is processed according to the 4117 procedure specified in Section 10.2; otherwise, it is processed 4118 according to the procedure specified in Section 9.4.2. 4120 - If the Lifetime specified in the Binding Update is zero or the 4121 specified Care-of Address matches the home address for the 4122 binding, then this is a request to delete the mobile node's 4123 cached binding. If the Home Registration (H) bit is set in the 4124 Binding Update, the Binding Update is processed according to the 4125 procedure specified in Section 10.3; otherwise, it is processed 4126 according to the procedure specified in Section 9.4.3. 4128 9.4.2. Requests to Cache a Binding 4130 When a node receives a Binding Update, it MUST validate it and 4131 determine the type of Binding Update according to the steps described 4132 in Section 9.4.1. This section describes the processing of a valid 4133 Binding Update that requests a node to cache a mobile node's binding, 4134 for which the Home Registration (H) bit is not set in the Binding 4135 Update. 4137 In this case, the receiving node SHOULD create a new entry in its 4138 Binding Cache for this mobile node, or update its existing Binding 4139 Cache entry for this mobile node, if such an entry already exists. 4140 The Binding Cache entry records the association between this home 4141 address and the care-of address for the binding. The lifetime for 4142 the Binding Cache entry is initialized from the Lifetime field 4143 specified in the Binding Update, although this lifetime MAY be 4144 reduced by the node caching the binding; the lifetime for the Binding 4145 Cache entry MUST NOT be greater than the Lifetime value specified in 4146 the Binding Update. Any Binding Cache entry MUST be deleted after 4147 the expiration its lifetime. 4149 The Sequence Number value received from a mobile node in a Binding 4150 Update is stored by a correspondent node in its Binding Cache entry 4151 for that mobile node. If the receiving correspondent node has no 4152 Binding Cache entry for the sending mobile node, it MUST accept any 4153 Sequence Number value in a received Binding Update from this mobile 4154 node. 4156 9.4.3. Requests to Delete a Binding 4158 When a node receives a Binding Update, it MUST validate it and 4159 determine the type of Binding Update according to the steps described 4160 in Section 9.4.1. This section describes the processing of a valid 4161 Binding Update that requests a node to delete a mobile node's binding 4162 from its Binding Cache, for which the Home Registration (H) bit is 4163 not set in the Binding Update. 4165 Any existing binding for the mobile node MUST be deleted. A Binding 4166 Cache entry for the mobile node MUST NOT be created in response to 4167 receiving the Binding Update. 4169 In order to prevent replayed binding updates after a binding cache 4170 entry has been deleted the correspondent node needs to make sure that 4171 the nonce indices used to create the binding are no longer valid. 4173 This applies whether the binding is deleted due to it timing out 4174 (lifetime expiry) or being deleted explicitly by the mobile node. 4176 If a binding cache entry is logically deleted and either the home 4177 nonce index or the care-of nonce index used to create (or last 4178 update) the binding are still valid, the correspondent node must 4179 behave as if it retains the state about the binding (including the 4180 sequence number) until at least one of the cookies has become too 4181 old. 4183 A possible way to implement this is to mark the binding cache entry 4184 so that it does not effect sending and receiving of packets, but 4185 so that it is found when a binding update is received. Another 4186 way is to mark the used nonces immediately too old. However, this 4187 method may cause some unnecessary failures and retries with ongoing 4188 return routability procedures with other mobile nodes. Furthermore, 4189 unless the mobile node has requested a Binding Acknowledgement, 4190 it is possible that this method may even cause an error in the 4191 return routability procedure procedure to go unnoticed, and data 4192 packets to be dropped through the use of the Home Address destination 4193 option without an existing binding. The effect is similar to packet 4194 loss during the return routability procedure, but may in certain 4195 circumstances significantly increase the problems. 4197 9.4.4. Sending Binding Acknowledgements 4199 When any node receives a packet containing a Binding Update message 4200 in which the Acknowledge (A) bit is set, it MUST return a Binding 4201 Acknowledgement message acknowledging receipt of the Binding Update. 4202 If the node accepts the Binding Update and creates or updates an 4203 entry in its Binding Cache for this binding, the Status field in the 4204 Binding Acknowledgement MUST be set to a value less than 128; if, on 4205 the other hand the Binding Update is accepted and the `A' bit is not 4206 set, the node SHOULD NOT send a Binding Acknowledgement. If the node 4207 rejects the Binding Update and does not create or update an entry for 4208 this binding, a Binding Acknowledgement MUST be sent even if the `A' 4209 bit was not set, and the Status field in the Binding Acknowledgement 4210 MUST be set to a value greater than or equal to 128. Specific values 4211 for the Status field are described in Section 6.1.8 and in the most 4212 recent "Assigned Numbers" [10]. 4214 The packet in which the Binding Acknowledgement is returned 4215 MUST meet the specific authentication requirements for Binding 4216 Acknowledgements, defined in Section 5.5. Furthermore, if the packet 4217 is to be sent to the mobile node at any address other than the mobile 4218 node's home address, it MUST be sent using a Routing header (even if 4219 the binding was rejected). The intermediate IP address, to which 4220 the packet will be delivered immediately before the home address, is 4221 determined as follows: 4223 - Whenever the Binding Update is accepted with a nonzero lifetime, 4224 the routing header will be constructed using the care-of address 4225 as described in Section 9.6. 4227 - Otherwise, if the Source IP Address of the packet containing 4228 the Binding Update, is legal for inclusion in a Routing Header, 4229 the routing header will be constructed using that IP address. 4230 Note that multicast addresses, link-local addresses, loopback 4231 addresses, IPv4 mapped addresses, and the unspecified address, 4232 MUST NOT be used within a Routing Header for the Binding 4233 Acknowledgement. 4235 Otherwise, if the Binding Update has a zero lifetime but the Source 4236 IP address is not allowable for use within the Routing Header, 4237 the Binding Acknowledgment MUST be sent to the mobile node's home 4238 address. 4240 9.4.5. Sending Binding Refresh Requests 4242 Entries in a node's Binding Cache MUST be deleted when their lifetime 4243 expires. If such an entry is still in active use in sending packets 4244 to a mobile node, the next packet sent to the mobile node will be 4245 routed normally to the mobile node's home link, where it will be 4246 intercepted and tunneled to the mobile node. The mobile node will 4247 then return a Binding Update to the sender, allowing it to create 4248 a new Binding Cache entry for sending future packets to the mobile 4249 node. Communication with the mobile node continues uninterrupted, 4250 but the forwarding of this packet through the mobile node's home 4251 agent creates additional overhead and latency in delivering packets 4252 to the mobile node. Such routing paths could, for instance, 4253 temporarily or permanently disrupt any negotiated Quality of Service 4254 reservations which had been made by the mobile node on its home 4255 network. 4257 If the sender knows that the Binding Cache entry is still in active 4258 use, it MAY send a Binding Refresh Request message to the mobile node 4259 in an attempt to avoid this overhead and latency due to deleting and 4260 recreating the Binding Cache entry. When the mobile node receives a 4261 packet from some sender containing a Binding Refresh Request option, 4262 it MAY start a return routability procedure, if necessary, before 4263 sending its current binding and a new lifetime in a new Binding 4264 Update. 4266 The correspondent node MAY retransmit Binding Refresh Request 4267 messages provided that rate limitation is applied. The correspondent 4268 node SHOULD stop retransmitting when it receive a Home Test Init 4269 message, as the mobile node is responsible for retransmissions during 4270 the return routability procedure. 4272 9.4.6. Sending Binding Error Messages 4274 If the correspondent node receives a packet with a Home Address 4275 destination option it MUST verify that it has a binding for that 4276 mobile node. Specifically, it MUST have a binding entry for the 4277 mobile node's home address (as obtained from the Home Address option) 4278 at the mobile node's care-of address (from the IP source address of 4279 the packet). If the correspondent node does not find such a binding 4280 entry, it MUST discard the packet and return a Binding Error message 4281 (Section 6.1.9). 4283 9.5. Cache Replacement Policy 4285 Conceptually, a node maintains a separate timer for each entry in its 4286 Binding Cache. When creating or updating a Binding Cache entry in 4287 response to a received and accepted Binding Update, the node sets the 4288 timer for this entry to the specified Lifetime period. Any entry in 4289 a node's Binding Cache MUST be deleted after the expiration of the 4290 Lifetime specified in the Binding Update from which the entry was 4291 created or last updated. 4293 Each node's Binding Cache will, by necessity, have a finite size. 4294 A node MAY use any reasonable local policy for managing the space 4295 within its Binding Cache, except that any entry marked as a "home 4296 registration" (Section 10.2) MUST NOT be deleted from the cache until 4297 the expiration of its lifetime period. When such "home registration" 4298 entries are deleted, the home agent MUST also cease intercepting 4299 packets on the mobile node's home link addressed to the mobile node 4300 (Section 10.4), just as if the mobile node had de-registered its 4301 primary care-of address (see Section 10.3). 4303 When attempting to add a new "home registration" entry in response 4304 to a Binding Update with the Home Registration (H) bit set, if no 4305 sufficient space can be found, the node MUST reject the Binding 4306 Update and MUST return a Binding Acknowledgement to the sending 4307 mobile node, in which the Status field is set to 131 (insufficient 4308 resources). When otherwise attempting to add a new entry to its 4309 Binding Cache, a node MAY, if needed, choose to drop any entry 4310 already in its Binding Cache, other than "home registration" 4311 entries, in order to make space for the new entry. For example, a 4312 "least-recently used" (LRU) strategy for cache entry replacement 4313 among entries not marked as "home registrations" is likely to 4314 work well unless the size of the Binding Cache is substantially 4315 insufficient. 4317 Any binding dropped from a node's Binding Cache due to lack of cache 4318 space will be rediscovered and a new cache entry created, if the 4319 binding is still in active use by the node for sending packets. If 4320 the node sends a packet to a destination for which it has dropped the 4321 entry from its Binding Cache, the packet will be routed normally, 4322 leading to the mobile node's home link. There, the packet will be 4323 intercepted by the mobile node's home agent and tunneled to the 4324 mobile node's current primary care-of address. This indirect routing 4325 to the mobile node through its home agent will result in the mobile 4326 node sending a Binding Update to this sending node when it receives 4327 the tunneled packet, allowing it to again add an entry for this 4328 destination mobile node to its Binding Cache. 4330 9.6. Sending Packets to a Mobile Node 4332 Before sending any packet, the sending node SHOULD examine its 4333 Binding Cache for an entry for the destination address to which the 4334 packet is being sent. If the sending node has a Binding Cache entry 4335 for this address, the sending node SHOULD use a Routing header to 4336 route the packet to this mobile node (the destination node) by way 4337 of the care-of address in the binding recorded in that Binding Cache 4338 entry. For example, assuming use of a Type 2 Routing header (see 4339 Section 6.4), if no other use of a Routing header is involved in 4340 the routing of this packet, the mobile node sets the fields in the 4341 packet's IPv6 header and Routing header as follows: 4343 - The Destination Address in the packet's IPv6 header is set to 4344 the mobile node's care-of address copied from the Binding Cache 4345 entry. 4347 - The Routing header is initialized to contain a single route 4348 segment, with an Address of the mobile node's home address (the 4349 original destination address to which the packet was being sent). 4351 Following the definition of a Type 2 Routing header 6.4, this packet 4352 will be routed to the mobile node's care-of address, where it will 4353 be delivered to the mobile node (the mobile node has associated the 4354 care-of address with its network interface). 4356 Note that following the above conceptual model in an implementation 4357 creates some additional requirements for path MTU discovery since the 4358 layer that decides the packet size (e.g., TCP and applications using 4359 UDP) needs to be aware of the size of the headers added by the IP 4360 layer on the sending node. 4362 If, instead, the sending node has no Binding Cache entry for the 4363 destination address to which the packet is being sent, the sending 4364 node simply sends the packet normally, with no Routing header. If 4365 the destination node is not a mobile node (or is a mobile node that 4366 is currently at home), the packet will be delivered directly to this 4367 node and processed normally by it. If, however, the destination node 4368 is a mobile node that is currently away from home, the packet will 4369 be intercepted by the mobile node's home agent and tunneled (using 4370 IPv6 encapsulation [4]) to the mobile node's current primary care-of 4371 address, as described in Section 10.5. The mobile node MAY then send 4372 a Binding Update to the sending node, as described in Section 11.6.2, 4373 allowing the sending node to create a Binding Cache entry for its use 4374 in sending subsequent packets to this mobile node. 4376 9.7. Receiving ICMP Error Messages 4378 When a correspondent node sends a packet to a mobile node, if the 4379 correspondent node has a Binding Cache entry for the destination 4380 address of the packet, then the correspondent node uses a Routing 4381 header to deliver the packet to the mobile node through the care-of 4382 address in the binding recorded in the Binding Cache entry. Any ICMP 4383 error message caused by the packet on its way to the mobile node will 4384 be returned normally to the correspondent node. 4386 On the other hand, if the correspondent node has no Binding Cache 4387 entry for the mobile node, the packet will be routed to the mobile 4388 node's home link. There, it will be intercepted by the mobile node's 4389 home agent, encapsulated, and tunneled to the mobile node's primary 4390 care-of address. Any ICMP error message caused by the packet on 4391 its way to the mobile node while in the tunnel, will be transmitted 4392 to the mobile node's home agent (the source of the tunnel). By 4393 the definition of IPv6 encapsulation [4], the home agent (as the 4394 encapsulating node) MUST relay certain ICMP error messages back 4395 to the original sender of the packet, which in this case is the 4396 correspondent node. 4398 Likewise, if a packet for a mobile node arrives at the mobile node's 4399 previous link and is intercepted there by a home agent for the mobile 4400 node's previous care-of address as described in Section 11.6.6 (e.g., 4401 the mobile node moved after the packet was sent), that home agent 4402 will encapsulate and tunnel the packet to the mobile node's new 4403 care-of address. As above, any ICMP error message caused by the 4404 packet while in this tunnel will be returned to that home agent (the 4405 source of the tunnel), which MUST relay certain ICMP error messages 4406 back to the correspondent node [4]. The relayed packet MUST NOT 4407 contain a routing header entry with the care-of address of the mobile 4408 node. 4410 Thus, in all cases, any meaningful ICMP error messages caused 4411 by packets from a correspondent node to a mobile node will be 4412 returned to the correspondent node. If the correspondent node 4413 receives persistent ICMP Destination Unreachable messages after 4414 sending packets to a mobile node based on an entry in its Binding 4415 Cache, the correspondent node SHOULD delete this Binding Cache 4416 entry. If the correspondent node subsequently transmits another 4417 packet to the mobile node, the packet will be routed to the mobile 4418 node's home link, intercepted by the mobile node's home agent, and 4419 tunneled to the mobile node's primary care-of address using IPv6 4420 encapsulation. The mobile node will then return a Binding Update to 4421 the correspondent node, allowing it to recreate a (correct) Binding 4422 Cache entry for the mobile node. 4424 10. Home Agent Operation 4426 10.1. Conceptual Data Structures 4428 Each home agent MUST maintain a Binding Cache and Home Agents List. 4430 The rules for maintaining a Binding Cache are same for home 4431 agents and correspondent nodes, and have already been described in 4432 Section 9.1. In addition, if an entry in a node's Binding Cache 4433 for which the node is serving as a home agent is marked as a "home 4434 registration" entry, it SHOULD NOT be deleted by the home agent until 4435 the expiration of its binding lifetime. 4437 The Home Agents List is maintained by each home agent (as well as 4438 each mobile node), recording information about each home agent from 4439 which this node has received a Router Advertisement in which the Home 4440 Agent (H) bit is set, for which the remaining lifetime for this list 4441 entry (defined below) has not yet expired. The home agents list is 4442 thus similar to the Default Router List conceptual data structure 4443 maintained by each host for Neighbor Discovery [20], although the 4444 Home Agents List MAY be implemented in any manner consistent with the 4445 external behavior described in this document. 4447 Each home agent maintains a separate Home Agents List for each link 4448 on which it is serving as a home agent; this list is used by a home 4449 agent in the dynamic home agent address discovery mechanism. Each 4450 mobile node, while away from home, also maintains a Home Agents 4451 List, to enable it to notify a home agent on its previous link when 4452 it moves to a new link; a mobile node MAY maintain a separate Home 4453 Agents List for each link to which it is (or has recently) connected, 4454 or it MAY maintain a single list for all links. Each Home Agents 4455 List entry conceptually contains the following fields: 4457 - The link-local IP address of a router on the link, that this 4458 node currently believes is operating as a home agent for that 4459 link. A new entry is created or an existing entry is updated 4460 in the Home Agents List in response to receipt of a valid 4461 Router Advertisement in which the Home Agent (H) bit is set. 4462 The link-local address of the home agent is learned through 4463 the Source Address of the Router Advertisements received from 4464 it [20]. 4466 - One or more global IP addresses for this home agent, learned 4467 through Prefix Information options with the Router Address (R) 4468 bit set, received in Router Advertisements from this link-local 4469 address. Global addresses for the router in a Home Agents List 4470 entry MUST be deleted once the prefix associated with that 4471 address is no longer valid [20]. 4473 Are there interactions with the new Router Advertisement 4474 stuff? 4476 - The remaining lifetime of this Home Agents List entry. If a Home 4477 Agent Information Option is present in a Router Advertisement 4478 received from a home agent, the lifetime of the Home Agents List 4479 entry representing that home agent is initialized from the Home 4480 Agent Lifetime field in the option; otherwise, the lifetime 4481 is initialized from the Router Lifetime field in the received 4482 Router Advertisement. The Home Agents List entry lifetime is 4483 decremented until it reaches zero, at which time this entry MUST 4484 be deleted from the Home Agents List. 4486 - The preference for this home agent; higher values indicate a more 4487 preferable home agent. The preference value is taken from the 4488 Home Agent Preference field (a signed, twos-complement integer) 4489 in the received Router Advertisement, if the Router Advertisement 4490 contains a Home Agent Information Option, and is otherwise set 4491 to the default value of 0. A home agent uses this preference 4492 in ordering the Home Agents List returned in an ICMP Home 4493 Agent Address Discovery message in response to a mobile node's 4494 initiation of dynamic home agent address discovery. A mobile 4495 node uses this preference in determining which of the home agents 4496 on its previous link to notify when it moves to a new link. 4498 Can we delete the preference stuff? Is anyone using it? 4500 10.2. Primary Care-of Address Registration 4502 When a node receives a Binding Update, it MUST validate it and 4503 determine the type of Binding Update according to the steps described 4504 in Section 9.4.1. This section describes the processing of a valid 4505 Binding Update that requests the receiving node to serve as its home 4506 agent, registering its primary care-of address. 4508 To begin processing the Binding Update, the home agent MUST perform 4509 the following sequence of tests: 4511 - If the node is not a router that implements home agent 4512 functionality, then the node MUST reject the Binding Update 4513 and MUST return a Binding Acknowledgement to the mobile node, 4514 in which the Status field is set to 132 (home registration not 4515 supported). 4517 - Else, if the home address for the binding (the Home Address field 4518 in the packet's Home Address option) is not an on-link IPv6 4519 address with respect to the home agent's current Prefix List, 4520 then the home agent MUST reject the Binding Update and SHOULD 4521 return a Binding Acknowledgement to the mobile node, in which the 4522 Status field is set to 133 (not home subnet). 4524 - Else, if the home agent chooses to reject the Binding Update for 4525 any other reason (e.g., insufficient resources to serve another 4526 mobile node as a home agent), then the home agent SHOULD return a 4527 Binding Acknowledgement to the mobile node, in which the Status 4528 field is set to an appropriate value to indicate the reason for 4529 the rejection. 4531 - A Home Address destination option MUST be present in the message, 4532 and the value of the Home Address field in this option MUST 4533 correspond to the Home Address field in the Binding Update. 4535 - Finally, if the Duplicate Address Detection (D) bit is set in 4536 the Binding Update, this home agent MUST perform Duplicate 4537 Address Detection [33] on the mobile node's home link for the 4538 link-local address associated with the home address in this 4539 binding, before returning the Binding Acknowledgement. This 4540 ensures that no other node on the home link can possibly use 4541 the mobile node's home address. The address used for Duplicate 4542 Address Detection SHOULD be the mobile node's link-local address. 4543 Normal processing for Duplicate Address Detection specifies that, 4544 in certain cases, the node SHOULD delay sending the initial 4545 Neighbor Solicitation message of Duplicate Address Detection by a 4546 random delay between 0 and MAX_RTR_SOLICITATION_DELAY [20, 33]; 4547 however, in this case, the home agent SHOULD NOT perform such a 4548 delay. If this Duplicate Address Detection fails, then the home 4549 agent MUST reject the Binding Update and MUST return a Binding 4550 Acknowledgement to the mobile node, in which the Status field is 4551 set to 138 (Duplicate Address Detection failed). When the home 4552 agent sends a successful Binding Acknowledgement to the mobile 4553 node, in response to a Binding Update with the `D' bit set, the 4554 home agent assures to the mobile node that its home address will 4555 continue to be kept unique by the home agent at least as long 4556 as the mobile node transmits Binding Updates with new care-of 4557 addresses for that home address. 4559 If the home agent does not reject the Binding Update, then it becomes 4560 or remains the home agent for the mobile node. The home agent MUST 4561 then create a new entry in its Binding Cache for this mobile node, 4562 or update its existing Binding Cache entry, if such an entry already 4563 exists. The home address of the mobile node is taken to be the 4564 value which, when the packet was originally received, was located 4565 in the Home Address field in the packet's Home Address option. The 4566 care-of address for this Binding Cache entry is taken to be the value 4567 which, when the packet was originally received, was located either in 4568 the Alternate Care-of Address option in the Binding Update option, 4569 if present, or from the Source Address field in the packet's IPv6 4570 header, otherwise. 4572 The home agent MUST mark this Binding Cache entry as a "home 4573 registration" to indicate that the node is serving as a home 4574 agent for this binding. Binding Cache entries marked as a "home 4575 registration" MUST be excluded from the normal cache replacement 4576 policy used for the Binding Cache (Section 9.5) and MUST NOT be 4577 removed from the Binding Cache until the expiration of the Lifetime 4578 period. 4580 If the `S' bit field in the Binding Update is zero, The home agent 4581 creates or updates Binding Cache entries for each of possibly 4582 several home addresses. The set of such home addresses is formed 4583 by replacing the routing prefix for the given home address with 4584 all other routing prefixes that are supported by the home agent 4585 processing the Binding Update. The home agent creates such a 4586 separate primary care-of address registration for each such home 4587 address. Note that the same considerations for Duplicate Address 4588 Detection apply for each affected home address. 4590 The lifetime of the Binding Cache entry depends on a number of 4591 factors: 4593 - The lifetime for the Binding Cache entry MUST NOT be greater 4594 than the remaining valid lifetime for the subnet prefix in the 4595 mobile node's home address specified with the Binding Update, 4596 and MUST NOT be greater than the Lifetime value specified in the 4597 Binding Update. The remaining valid lifetime for this prefix is 4598 determined by the home agent based on its own Prefix List entry 4599 for this prefix [20]. 4601 - , However, if the `S' bit field in the Binding Update is zero, 4602 the lifetime for the each Binding Cache entry MUST NOT be greater 4603 than the minimum remaining valid lifetime for all subnet prefixes 4604 on the mobile node's home link. If the value of the Lifetime 4605 field specified by the mobile node in its Binding Update is 4606 greater than this prefix lifetime, the home agent MUST decrease 4607 the binding lifetime to less than or equal to the prefix valid 4608 lifetime. 4610 - The home agent MAY further decrease the specified lifetime for 4611 the binding, for example based on a local policy. The resulting 4612 lifetime is stored by the home agent in the Binding Cache entry, 4613 and this Binding Cache entry MUST be deleted by the home agent 4614 after the expiration of this lifetime. 4616 Regardless of the setting of the 'A' bit in the Binding Update, the 4617 home agent MUST return a Binding Acknowledgement to the mobile node, 4618 constructed as follows: 4620 - The Status field MUST be set to a value 0, indicating success. 4622 - The Sequence Number field MUST be copied from the Sequence Number 4623 given in the Binding Update. 4625 - The Lifetime field MUST be set to the remaining lifetime for 4626 the binding as set by the home agent in its "home registration" 4627 Binding Cache entry for the mobile node, as described above. 4629 - The Refresh field MUST be set to a value less than or equal to 4630 the Lifetime value being returned in the Binding Update. If the 4631 home agent stores the Binding Cache entry in nonvolatile storage 4632 (that survives the crash or other failure of the home agent), 4633 then the Refresh field SHOULD be set to the same value as the 4634 Lifetime field; otherwise, the home agent MAY set the Refresh 4635 field to a value less than the Lifetime field, to indicate that 4636 the mobile node SHOULD attempt to refresh its home registration 4637 at the indicated shorter interval (although the home agent will 4638 still retain the registration for the Lifetime period, even if 4639 the mobile node does not refresh its registration within the 4640 Refresh period). 4642 In addition, the home agent MUST follow the procedure defined in 4643 Section 10.4 to intercept packets on the mobile node's home link 4644 addressed to the mobile node, while the home agent is serving as 4645 the home agent for this mobile node. The home agent MUST also be 4646 prepared to accept reverse tunneled packets from the new care-of 4647 address of the mobile node, as described in Section 10.6. Finally, 4648 the home agent MUST also propagate new home network prefixes, as 4649 described in Section 10.9.1. 4651 10.3. Primary Care-of Address De-Registration 4653 When a node receives a Binding Update, it MUST validate it and 4654 determine the type of Binding Update according to the steps described 4655 in Section 9.4.1. This section describes the processing of a valid 4656 Binding Update that requests the receiving node to no longer serve as 4657 its home agent, de-registering its primary care-of address. 4659 To begin processing the Binding Update, the home agent MUST perform 4660 the following test: 4662 - If the receiving node has no entry marked as a "home 4663 registration" in its Binding Cache for this mobile node, then 4664 this node MUST reject the Binding Update and SHOULD return a 4665 Binding Acknowledgement to the mobile node, in which the Status 4666 field is set to 137 (not home agent for this mobile node). 4668 If the home agent does not reject the Binding Update as described 4669 above, then it MUST delete any existing entry in its Binding Cache 4670 for this mobile node, and proceed as follows. 4672 The home agent MUST return a Binding Acknowledgement to the mobile 4673 node, constructed as follows: 4675 - The Status field MUST be set to a value 0, indicating success. 4677 - The Sequence Number field MUST be copied from the Sequence Number 4678 given in the Binding Update. 4680 - The Lifetime field MUST be set to zero. 4682 - The Refresh field MUST be set to zero. 4684 In addition, the home agent MUST stop intercepting packets on 4685 the mobile node's home link that are addressed to the mobile node 4686 (Section 10.4). 4688 The rules for selecting the Destination IP address (and possibly 4689 Routing Header construction) for the Binding Acknowledgement to the 4690 mobile node are the same as in section 9.4.4. 4692 10.4. Intercepting Packets for a Mobile Node 4694 While a node is serving as the home agent for mobile node (while the 4695 node has an entry in its Binding Cache for this mobile node that is 4696 marked as a "home registration"), this node MUST attempt to intercept 4697 packets on the mobile node's home link that are addressed to the 4698 mobile node, and MUST tunnel each intercepted packet to the mobile 4699 node using IPv6 encapsulation [4]. 4701 In order to intercept such packets on the home link, when a node 4702 begins serving as the home agent for some mobile node (it did not 4703 already have a Binding Cache entry for this mobile node marked as a 4704 "home registration"), then the home agent MUST multicast onto the 4705 home link a "gratuitous" Neighbor Advertisement message [20] on 4706 behalf of the mobile node. Specifically, the home agent performs the 4707 following steps: 4709 - The home agent examines the value of the `S' bit in the new "home 4710 registration" Binding Cache entry. If this bit is nonzero, 4711 the following step is carried out only for the individual home 4712 address specified for this binding. If, instead, this bit is 4713 zero, then the following step is carried out for each address 4714 for the mobile node formed from the interface identifier in 4715 the mobile node's home address in this binding (the remaining 4716 low-order bits in the address after the configured subnet 4717 prefix), together with each one of the subnet prefixes currently 4718 considered by the home agent to be on-link (including both the 4719 link-local and site-local prefix). 4721 - For each specific IP address for the mobile node determined 4722 in the first step above, the home agent sends a Neighbor 4723 Advertisement message [20] to the all-nodes multicast address 4724 on the home link, to advertise the home agent's own link-layer 4725 address for this IP address on behalf of the mobile node. 4727 All fields in each such Neighbor Advertisement message SHOULD be 4728 set in the same way they would be set by the mobile node itself 4729 if sending this Neighbor Advertisement while at home [20], with 4730 the following exceptions: 4732 * The Target Address in the Neighbor Advertisement message MUST 4733 be set to the specific IP address for the mobile node. 4735 * The Advertisement MUST include a Target Link-layer Address 4736 option specifying the home agent's link-layer address. 4738 * The Router (R) bit in the Advertisement MUST be set to zero. 4740 * The Solicited Flag (S) in the Advertisement MUST NOT be set, 4741 since it was not solicited by any Neighbor Solicitation 4742 message. 4744 * The Override Flag (O) in the Advertisement MUST be set, 4745 indicating that the Advertisement SHOULD override any 4746 existing Neighbor Cache entry at any node receiving it. 4748 Any node on the home link receiving one of the Neighbor Advertisement 4749 messages described above will thus update its Neighbor Cache to 4750 associate the mobile node's address with the home agent's link 4751 layer address, causing it to transmit any future packets for the 4752 mobile node normally destined to this address instead to the mobile 4753 node's home agent. Since multicasting on the local link (such as 4754 Ethernet) is typically not guaranteed to be reliable, the home 4755 agent MAY retransmit this Neighbor Advertisement message up to 4756 MAX_ADVERT_REXMIT times to increase its reliability. It is still 4757 possible that some nodes on the home link will not receive any of 4758 these Neighbor Advertisements, but these nodes will eventually be 4759 able to detect the link-layer address change for the mobile node's 4760 home address, through use of Neighbor Unreachability Detection [20]. 4762 While a node is serving as a home agent for some mobile node (it 4763 still has a "home registration" entry for this mobile node in its 4764 Binding Cache), the home agent uses IPv6 Neighbor Discovery [20] to 4765 intercept unicast packets on the home link addressed to the mobile 4766 node's home address. In order to intercept packets in this way, the 4767 home agent MUST act as a proxy for this mobile node, and reply to any 4768 received Neighbor Solicitation messages for it. When a home agent 4769 receives a Neighbor Solicitation message, it MUST check if the Target 4770 Address specified in the message matches the home address of any 4771 mobile node for which it has a Binding Cache entry marked as a "home 4772 registration". (Note that Binding Update messages with the `S' bit 4773 set to zero will result in multiple Binding Cache entries, so checks 4774 on all these entries necessarily include all possible home addresses 4775 for the mobile node). 4777 If such an entry exists in the home agent's Binding Cache, the home 4778 agent MUST reply to the Neighbor Solicitation message with a Neighbor 4779 Advertisement message, giving the home agent's own link-layer address 4780 as the link-layer address for the specified Target Address. In 4781 addition, the Router (R) bit in the Advertisement MUST be copied from 4782 the corresponding bit in the home agent's Binding Cache entry for the 4783 mobile node. Acting as a proxy in this way allows other nodes on 4784 the mobile node's home link to resolve the mobile node's IPv6 home 4785 address, and allows the home agent to defend these addresses on the 4786 home link for Duplicate Address Detection [20]. 4788 10.5. Tunneling Intercepted Packets to a Mobile Node 4790 For any packet sent to a mobile node from the mobile node's home 4791 agent (for which the home agent is the original sender of the 4792 packet), the home agent is operating as a correspondent node of 4793 the mobile node for this packet and the procedures described in 4794 Section 9.6 apply. The home agent (as a correspondent node) uses a 4795 Routing header to route the packet to the mobile node by way of the 4796 care-of address in the home agent's Binding Cache (the mobile node's 4797 primary care-of address, in this case). 4799 While the mobile node is away from home and this node is acting 4800 as the mobile node's home agent, the home agent intercepts any 4801 packets on the home link addressed to the mobile node's home address 4802 (including addresses formed from other on-link prefixes, if the 4803 Prefix Length field was nonzero in the Binding Update), as described 4804 in Section 10.4. The home agent cannot use a Routing header to 4805 forward these intercepted packets to the mobile node, since it cannot 4806 modify the packet in flight without invalidating any existing IPv6 4807 AH [12] or ESP [13] header present in the packet. 4809 In order to forward each intercepted packet to the mobile node, the 4810 home agent MUST tunnel the packet to the mobile node using IPv6 4811 encapsulation [4]; the tunnel entry point node is the home agent, 4812 and the tunnel exit point node is the primary care-of address as 4813 registered with the home agent. When a home agent encapsulates 4814 an intercepted packet for forwarding to the mobile node, the home 4815 agent sets the Source Address in the new tunnel IP header to the 4816 home agent's own IP address, and sets the Destination Address 4817 in the tunnel IP header to the mobile node's primary care-of 4818 address. When received by the mobile node (using its primary care-of 4819 address), normal processing of the tunnel header [4] will result in 4820 decapsulation and processing of the original packet by the mobile 4821 node. 4823 However, packets addressed to the mobile node's link-local address 4824 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 4825 be discarded, and the home agent SHOULD return an ICMP Destination 4826 Unreachable, Code 3, message to the packet's Source Address (unless 4827 this Source Address is a multicast address). Packets addressed to 4828 the mobile node's site-local address SHOULD be tunneled to the mobile 4829 node by default, but this behavior MUST be configurable to disable 4830 it; currently, the exact definition and semantics of a "site" and a 4831 site-local address are incompletely defined in IPv6, and this default 4832 behavior might change at some point in the future. 4834 Tunneling of multicast packets to a mobile node follows similar 4835 limitations to those defined above for unicast packets addressed to 4836 the mobile node's link-local and site-local addresses. Multicast 4837 packets addressed to a multicast address with link-local scope [9], 4838 to which the mobile node is subscribed, MUST NOT be tunneled 4839 to the mobile node; such packets SHOULD be silently discarded 4840 (after delivering to other local multicast recipients). Multicast 4841 packets addressed to a multicast address with scope larger 4842 than link-local but smaller than global (e.g., site-local and 4843 organization-local) [9], to which the mobile node is subscribed, 4844 SHOULD be tunneled to the mobile node by default, but this behavior 4845 MUST be configurable to disable it; this default behavior might 4846 change at some point in the future as the definition of these scopes 4847 become more completely defined in IPv6. 4849 10.6. Handling Reverse Tunneled Packets from a Mobile Node 4851 Unless a binding has been established between the mobile node and a 4852 correspondent node, traffic from the mobile node to the correspondent 4853 node goes through a reverse tunnel. This tunnel extends between the 4854 mobile node and the home agent. Home agents MUST support reverse 4855 tunneling as follows: 4857 - The tunneled traffic arrives to the home agent using IPv6 4858 encapsulation [4]. 4860 - The tunnel entry point is the primary care-of address as 4861 registered with the home agent and the tunnel exit point is the 4862 home agent. 4864 - When a home agent decapsulates a tunneled packet from the mobile 4865 node, the home agent verifies that the Source Address in the 4866 tunnel IP header is the mobile node's primary care-of address. 4868 Reverse tunneled packets MAY be discarded unless accompanied by a 4869 valid AH or ESP header, depending on the security policies used by 4870 the home agent. In any case, the home agent MUST check that the 4871 source address in the tunneled packets corresponds to the currently 4872 registered location of the mobile node, as otherwise any node in the 4873 Internet could send traffic through the home agent and escape ingress 4874 filtering limitations. 4876 The support for authenticated reverse tunneling allows the home agent 4877 to protect the home network and correspondent nodes from malicious 4878 nodes masquerading as a mobile node, even if they know the current 4879 location of the real mobile node. 4881 10.7. Protecting Return Routability Packets 4883 The return routability procedure described in Section 5 assumes that 4884 the confidentiality of the HoTI and HoT messages is protected as 4885 it is tunneled from the home agent to the mobile node. Therefore, 4886 the home agent MUST support IPsec ESP for the protection of packets 4887 belonging to the return routability procedure. Support for a 4888 non-null encryption transform MUST be available. In this case it 4889 isn't necessary to distinguish between different kinds of packets 4890 within the return routability procedure. 4892 The use of ESP for protection of the return routability procedure is 4893 optional and controlled by configuration of the IPsec security policy 4894 database both at the mobile node and at the home agent. 4896 As described earlier, the Binding Update and Binding Acknowledgement 4897 messages require protection between the home agent and the mobile 4898 node. These messages and the return routability messages employ 4899 the same protocol from the point of view of the security policy 4900 database, the Mobility Header. One way to set up the security policy 4901 database is to have one rule for the Mobility Header traffic between 4902 the mobile node and the home agent addresses, and an optional rule 4903 following it for Mobility Header traffic between the mobile node and 4904 any other address. 4906 10.8. Receiving Router Advertisement Messages 4908 For each link on which a router provides service as a home agent, 4909 the router maintains a Home Agents List recording information 4910 about all other home agents on that link. This list is used in 4911 the dynamic home agent address discovery mechanism, described in 4912 Section 10.9. The information for the list is learned through 4913 receipt of the periodic unsolicited multicast Router Advertisements, 4914 in a manner similar to the Default Router List conceptual data 4915 structure maintained by each host for Neighbor Discovery [20]. In 4916 the construction of the Home Agents List, the Router Advertisements 4917 are from each other home agent on the link, and the Home Agent (H) 4918 bit is set in them. 4920 On receipt of a valid Router Advertisement, as defined in the 4921 processing algorithm specified for Neighbor Discovery [20], the home 4922 agent performs the following steps, in addition to any steps already 4923 required of it by Neighbor Discovery: 4925 - If the Home Agent (H) bit in the Router Advertisement is not set, 4926 check to see if the sending node has an entry in the current Home 4927 Agents List. If it does, delete the corresponding entry. In any 4928 case all of the following steps are skipped. 4930 - Otherwise, extract the Source Address from the IP header of the 4931 Router Advertisement. This is the link-local IP address on this 4932 link of the home agent sending this Advertisement [20]. 4934 - Determine from the Router Advertisement the preference for this 4935 home agent. If the Router Advertisement contains a Home Agent 4936 Information Option, then the preference is taken from the Home 4937 Agent Preference field in the option; otherwise, the default 4938 preference of 0 MUST be used. 4940 - Determine from the Router Advertisement the lifetime for 4941 this home agent. If the Router Advertisement contains a Home 4942 Agent Information Option, then the lifetime is taken from 4943 the Home Agent Lifetime field in the option; otherwise, the 4944 lifetime specified by the Router Lifetime field in the Router 4945 Advertisement SHOULD be used. 4947 - If the link-local address of the home agent sending this 4948 Advertisement is already present in this home agent's Home 4949 Agents List and the received home agent lifetime value is zero, 4950 immediately delete this entry in the Home Agents List. 4952 - Otherwise, if the link-local address of the home agent sending 4953 this Advertisement is already present in the receiving home 4954 agent's Home Agents List, reset its lifetime and preference to 4955 the values determined above. 4957 - If the link-local address of the home agent sending this 4958 Advertisement, as determined above, is not already present in 4959 the Home Agents List maintained by the receiving home agent, and 4960 the lifetime for the sending home agent, as determined above, 4961 is non-zero, create a new entry in the list, and initialize its 4962 lifetime and preference to the values determined above. 4964 - If the Home Agents List entry for the link-local address of 4965 the home agent sending this Advertisement was not deleted as 4966 described above, determine any global address(es) of the home 4967 agent based on each Prefix Information option received in 4968 this Advertisement in which the Router Address (R) bit is set 4969 (Section 7.2). For each such global address determined from this 4970 Advertisement, add this global address to the list of global 4971 addresses for this home agent in this Home Agents List entry. 4973 A home agent SHOULD maintain an entry in its Home Agents List for 4974 each such valid home agent address until that entry's lifetime 4975 expires, after which time the entry MUST be deleted. 4977 10.9. Dynamic Home Agent Address Discovery 4979 A mobile node, while away from home, MAY use the dynamic home agent 4980 address discovery mechanism in section 11.3.2 to attempt to discover 4981 the address of one or more routers serving as home agents on its home 4982 link. This discovery might become necessary, for example, if some 4983 nodes on its home link have been reconfigured while the mobile node 4984 has been away from home, such that the router that was operating as 4985 the mobile node's home agent has been replaced by a different router 4986 serving this role. 4988 As described in Section 11.3.2, a mobile node attempts dynamic 4989 home agent address discovery by sending an ICMP Home Agent Address 4990 Discovery Request message to the "Mobile IPv6 Home-Agents" anycast 4991 address [11] for its home IP subnet prefix, using its care-of address 4992 as the Source Address of the packet. A home agent receiving such a 4993 Home Agent Address Discovery Request message that is serving this 4994 subnet (the home agent is configured with this anycast address on one 4995 of its network interfaces) SHOULD return an ICMP Home Agent Address 4996 Discovery Reply message to the mobile node (at its care-of address 4997 that was used as the Source Address of the Request message), with the 4998 Source Address of the Reply packet set to one of the global unicast 4999 addresses of the home agent. The Home Agent Addresses field in the 5000 Reply message is constructed as follows: 5002 - The Home Agent Addresses field SHOULD contain one global IP 5003 address for each home agent currently listed in this home 5004 agent's own Home Agents List (Section 4.5). However, if this 5005 home agent's own global IP address would be placed in the list 5006 (as described below) as the first entry in the list, then this 5007 home agent SHOULD NOT include its own address in the Home Agent 5008 Addresses field in the Reply message. Not placing this home 5009 agent's own IP address in the list will cause the receiving 5010 mobile node to consider this home agent as the most preferred 5011 home agent; otherwise, this home agent will be considered to be 5012 preferred in its order given by its place in the list returned. 5014 - The IP addresses in the Home Agent Addresses field SHOULD be 5015 listed in order of decreasing preference value, based either 5016 on the respective advertised preference from a Home Agent 5017 Information option or on the default preference of 0 if no 5018 preference is advertised (or on the configured home agent 5019 preference for this home agent itself). The home agent with 5020 the highest preference SHOULD be listed first in the Home Agent 5021 Addresses field, and the home agent with the lowest preference 5022 SHOULD be listed last. 5024 - Among home agents with equal preference, their IP addresses 5025 in the Home Agent Addresses field SHOULD be listed in an 5026 order randomized with respect to other home agents with equal 5027 preference, each time a Home Agent Address Discovery Reply 5028 message is returned by this home agent. 5030 - For each entry in this home agent's Home Agents List, if more 5031 than one global IP address is associated with this list entry, 5032 then one of these global IP addresses SHOULD be selected 5033 to include in the Home Agent Addresses field in the Reply 5034 message. As described in Section 4.5, one Home Agents List 5035 entry, identified by the home agent's link-local address, 5036 exists for each home agent on the link; associated with that 5037 list entry is one or more global IP addresses for this home 5038 agent, learned through Prefix Information options with the 5039 Router Address (R) bit is set, received in Router Advertisements 5040 from this link-local address. 5042 The selected global IP address for each home agent to include in 5043 forming the Home Agent Addresses field in the Reply message MUST 5044 be the global IP address of the respective home agent sharing a 5045 prefix with the Destination IP address of the Request message; 5046 if no such global IP address is known for some home agent, an 5047 entry for that home agent MUST NOT be included in the Home Agent 5048 Addresses field in the Reply message. 5050 - In order to avoid the possibility of the Reply message packet 5051 being fragmented (or rejected by an intermediate router with an 5052 ICMP Packet Too Big message [5]), if the resulting total packet 5053 size containing the complete list of home agents in the Home 5054 Agent Addresses field would exceed the minimum IPv6 MTU [6], the 5055 home agent SHOULD reduce the number of home agent IP addresses 5056 returned in the packet to the number of addresses that will fit 5057 without exceeding this limit. The home agent addresses returned 5058 in the packet SHOULD be those from the complete list with the 5059 highest preference. 5061 10.9.1. Aggregate List of Home Network Prefixes 5063 IPv6 provides mechanisms for node configuration when it turns on, 5064 and in renumbering a subnet, such as when a site switches to a new 5065 network service provider. These mechanisms are a part of Neighbor 5066 Discovery [20] and Address Autoconfiguration [33]. 5068 In renumbering, new prefixes and addresses can be introduced for the 5069 subnet and old ones can be deprecated and removed. These mechanisms 5070 are defined to work while all nodes using the old prefixes are at 5071 home, connected to the link using these prefixes. Mobile IPv6 5072 extends these mechanisms to work also with mobile nodes that are away 5073 from home when the renumbering takes place. 5075 Mobile IPv6 arranges to propagate relevant prefix information to the 5076 mobile node when it is away from home, so that it may be used in 5077 mobile node home address configuration, and in network renumbering. 5078 In this mechanism, mobile nodes away from home receive Mobile Prefix 5079 Advertisements messages with Prefix Information Options, which give 5080 the valid lifetime and preferred lifetime for available prefixes on 5081 the home link. 5083 To avoid possible security attacks from forged Mobile Prefix 5084 Advertisements all such Advertisements must be authenticated to the 5085 mobile node by its home agent using IPsec [14, 12, 13] if a security 5086 associate exists (i.e. unless the mobile node does not yet have a 5087 home address configured). 5089 A mobile node on a remote network SHOULD autoconfigure all of the 5090 global IP addresses, which it would autoconfigure if it were attached 5091 to its home network, from network prefixes representing network 5092 addresses that are served by home agents. Site-local addresses MAY 5093 be autoconfigured if the mobile node is roaming in a network on the 5094 same site as its home addresses. Site-local addresses and addresses 5095 not served by a home agent MUST NOT be autoconfigured, since they are 5096 unusable in the remote network. 5098 To support this, the home agent monitors prefixes advertised by 5099 itself and other home agents routers on the home link, and passes 5100 this aggregated list of relevant subnet prefixes on to the mobile 5101 node in Mobile Prefix Advertisements. 5103 The home agent SHOULD construct the aggregate list of home subnet 5104 prefixes as follows: 5106 - Copy prefix information defined in the home agent's AdvPrefixList 5107 on the home subnet's interfaces to the aggregate list. Also 5108 apply any changes made to the AdvPrefixList on the home agent to 5109 the aggregate list. 5111 - Check valid prefixes received in Router Advertisements 5112 from the home network for consistency with the home agent's 5113 AdvPrefixList, as specified in section 6.2.7 of RFC 2461 5114 (Neighbor Discovery [20]). Do not update the aggregate list with 5115 any information from received prefixes that fail this check. 5117 - Check Router Advertisements which contain an `H' bit (from other 5118 home agents) for valid prefixes that are not yet in the aggregate 5119 list, and if they are usable for autoconfiguration (`A' bit set, 5120 and prefix length is valid for address autoconfiguration on the 5121 home subnet) add them and preserve the `L' flag value. Clear the 5122 `R' flag and zero the interface-id portion of the prefix field 5123 to prevent mobile nodes from treating another router's interface 5124 address as belonging to the home agent. Treat the lifetimes 5125 of these prefixes as decrementing in real time, as defined in 5126 section 6.2.7 of RFC 2461 [20]. 5128 - Do not perform consistency checks on valid prefixes received in 5129 Router Advertisements on the home network that do not exist in 5130 the home agent's AdvPrefixList. Instead, if the prefixes already 5131 exist in the aggregate list, update the prefix lifetime fields in 5132 the aggregate list according to the rules specified for hosts in 5133 section 6.3.4 of RFC 2461 (Neighbor Discovery [20]) and section 5134 5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [33]). 5136 - If the L flag is set on valid prefixes received in a Router 5137 Advertisement, and that prefix already exists in the aggregate 5138 list, set the flag in the aggregate list. Ignore the flag if it 5139 is clear. 5141 - Delete prefixes from the aggregate list when their valid 5142 lifetimes expire. 5144 The home agent uses the information in the aggregate list to 5145 construct Mobile Prefix Advertisements. It may be possible to 5146 construct an aggregate list by combining information contained in the 5147 home agent's AdvPrefixList and its Home Agents List used for Dynamic 5148 Home Agent Address Discovery (Section 11.3.2). 5150 10.9.2. Scheduling Prefix Deliveries to the Mobile Node 5152 A home agent serving a mobile node will schedule the delivery of new 5153 prefix information to that mobile node when any of the following 5154 conditions occur: 5156 MUST: 5158 - The valid or preferred lifetime or the state of the flags changes 5159 for the prefix of the mobile node's registered home address. 5161 - The mobile node requests the information with a Mobile Prefix 5162 Solicitation (see section 11.3.3). 5164 MAY: 5166 - A new prefix is added to the aggregate list. 5168 - The valid or preferred lifetime or the state of the flags changes 5169 for a prefix which is not used in any binding cache entry for 5170 this mobile node. 5172 The home agent uses the following algorithm to determine when to send 5173 prefix information to the mobile node. 5175 - If the mobile node has not received the prefix information within 5176 the last HomeRtrAdvInterval seconds, then transmit the prefix 5177 information. This MAY be done according to a periodically 5178 scheduled transmission. 5180 - If a mobile node sends a solicitation, answer right away. 5182 - If a prefix in the aggregate list that matches the mobile node's 5183 home registration is added, or if its information changes in 5184 any way that does not cause the mobile node's address to go 5185 deprecated, ensure that a transmission is scheduled (as described 5186 below), and calculate RAND_ADV_DELAY in order to randomize the 5187 time at which the transmission is scheduled. 5189 - If a home registration expires, cancel any scheduled 5190 advertisements to the mobile node. 5192 Assume that the home agent already has scheduled the transmission of 5193 a Router Advertisement to the mobile node. New information should 5194 be added to the existing scheduled transmission, if the freshly 5195 calculated RAND_ADV_DELAY would cause another transmission before 5196 the expiration of the Preferred Lifetime of the mobile node's home 5197 address derived from the prefix whose advertisement information has 5198 changed. In this case, the home agent does not perform the following 5199 algorithm to schedule an advertisement to the mobile node. 5201 Otherwise, the home agent uses the following algorithm to compute 5202 a fresh value for RAND_ADV_DELAY, the offset from the current time 5203 for the scheduled transmission. If there is already a scheduled 5204 transmission, add the data from the existing scheduled transmission 5205 to the newly scheduled transmission, deleting the previously 5206 scheduled transmission event. 5208 RAND_ADV_DELAY is the offset from the current time to be used 5209 to schedule the necessary advertisement to the mobile node. The 5210 computation is expected to alleviate bursts of advertisements when 5211 prefix information changes. In addition, a home agent MAY further 5212 reduce the rate of packet transmission by further delaying individual 5213 advertisements, if needed to avoid overwhelming local network 5214 resources. 5216 Calculate the newly advertised Preferred Lifetime as follows. 5217 MAX_SCHEDULE_DELAY == min (MAX_PFX_ADV_DELAY, Preferred Lifetime) 5219 Then compute RAND_ADV_DELAY == 5220 MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) 5222 The home agent SHOULD periodically continue to retransmit an 5223 unsolicited Advertisement to the mobile node, until it is 5224 acknowledged by the receipt from the mobile node of a Binding Update 5225 matching the Binding Refresh Request in the packet (i.e., with 5226 matching Unique Identifier mobility option). The home agent MUST 5227 wait PREFIX_ADV_TIMEOUT before the first retransmission, and double 5228 the retransmission wait time for every succeeding retransmission, up 5229 until a maximum of PREFIX_ADV_RETRIES attempts. If the mobile node's 5230 bindings expire before the matching Binding Update has been received, 5231 then the home agent MUST NOT attempt any more retransmissions, even 5232 if not all PREFIX_ADV_RETRIES have been retransmitted. After another 5233 Binding Update is received from the mobile node, and if the mobile 5234 node has not returned to the home network in the meantime, the home 5235 agent SHOULD begin the process again of transmitting the unsolicited 5236 Advertisement. 5238 A Binding Update matches a Binding Refresh Request if it specifies 5239 a binding for the mobile node to which the Binding Refresh Request 5240 was sent and contains a Unique Identifier mobility option matching 5241 the unique identifier sent in the Unique Identifier option in the 5242 Binding Refresh Request. In the solicited case, the mobile node will 5243 retransmit solicitations until one is received; thus, the home agent 5244 SHOULD NOT retransmit the responding advertisement. 5246 If while the home agent is still retransmitting a Mobile Prefix 5247 Advertisement to the mobile node, another condition as described 5248 above occurs on the home link causing another Prefix Advertisement to 5249 be sent to the mobile node, the home agent SHOULD combine any Prefix 5250 Information options in the unacknowledged Mobile Prefix Advertisement 5251 into the new Advertisement, discard the old Advertisement, and then 5252 begin retransmitting the new one. according to the algorithm in 5253 section 10.9.2. The home agent MUST generate a new unique identifier 5254 for use in the Unique Identifier Option in the Binding Refresh 5255 Request tunneled with the new Mobile Prefix Advertisement. 5257 10.9.3. Sending Advertisements to the Mobile Node 5259 When sending a Mobile Prefix Advertisement to the mobile node, the 5260 home agent MUST construct the packet as follows: 5262 - The Source Address in the packet's IPv6 header MUST be set to 5263 the home agent's IP address to which the mobile node addressed 5264 its current home registration, or its default global home agent 5265 address if no binding exists. 5267 - If a security association exists with the mobile node's address, 5268 the packet MUST be protected by IPsec [14, 12, 13] to guard 5269 against malicious Mobile Prefix Advertisements. The IPsec 5270 protection MUST provide sender authentication, data integrity 5271 protection, and replay protection, covering the Mobile Prefix 5272 Advertisement. 5274 - A separate Binding Refresh Request message MUST be sent in 5275 addition to the advertisement, if this is the first advertisement 5276 for a home registration, or if there was a change in prefix 5277 information since the last acknowledged advertisement was sent to 5278 the mobile node for the home registration. The Binding Refresh 5279 Request message MUST include a Unique Identifier mobility option 5280 (Section 6.2.4), with the unique identifier in the option data 5281 set to a value different than that in any other Binding Refresh 5282 Request sent recently by this home agent. It is assumed that 5283 this requirement can be met by maintaining a simple 16-bit 5284 "wrap-around" counter to generate unique identifiers for Binding 5285 Refresh Requests that contain a Unique Identifier option, 5286 incremented each time a Binding Refresh Request containing a 5287 Unique Identifier option is sent. 5289 - If the advertisement was solicited, it should be destined 5290 (and authenticated, if possible) to the source address of 5291 the solicitation. If it was triggered by prefix changes or 5292 renumbering, the advertisement's destination will be the mobile 5293 node's home address in the binding which triggered the rule. 5295 - The packet MUST be sent as any other unicast IPv6 packet. If a 5296 care-of address is used, the packet will be delivered directly. 5297 If a binding exists, the home agent will send the packet with 5298 a routing header containing the care-of address, as any other 5299 packet sent to the mobile node originated by the home agent 5300 (rather than using IPv6 encapsulation, as would be used by the 5301 home agent for intercepted packets). 5303 10.9.4. Lifetimes for Changed Prefixes 5305 As described in Section 10.2, the lifetime returned by the home agent 5306 in a Binding Acknowledgement MUST be no greater than the remaining 5307 valid lifetime for the subnet prefix in the mobile node's home 5308 address. This limit on the binding lifetime serves to prohibit use 5309 of a mobile node's home address after it becomes invalid. 5311 11. Mobile Node Operation 5313 11.1. Conceptual Data Structures 5315 Each mobile node MUST maintain a Binding Update List and Home Agents 5316 List. 5318 The rules for maintaining a Home Agents List are same for home agents 5319 and correspondent nodes, and have been described in Section 10.1. 5321 The Binding Update List records information for each Binding Update 5322 sent by this mobile node, for which the Lifetime sent in that Binding 5323 Update has not yet expired. The Binding Update List includes all 5324 bindings sent by the mobile node: those to correspondent nodes, 5325 those to the mobile node's home agent, and those to a home agent 5326 on the link on which the mobile node's previous care-of address is 5327 located. It also contains Binding Updates which are waiting for 5328 the completion of the return routability procedure before they can 5329 be sent. However, for multiple Binding Updates sent to the same 5330 destination address, the Binding Update List contains only the most 5331 recent Binding Update (i.e., with the greatest Sequence Number value) 5332 sent to that destination. The Binding Update List MAY be implemented 5333 in any manner consistent with the external behavior described in this 5334 document. 5336 Each Binding Update List entry conceptually contains the following 5337 fields: 5339 - The IP address of the node to which a Binding Update was sent. 5340 If the Binding Update was successfully received by that node 5341 (e.g., not lost by the network), a Binding Cache entry may have 5342 been created or updated based on this Binding Update. The 5343 Binding Cache entry may still exist, if that node has not deleted 5344 the entry before its expiration (e.g., to reclaim space in its 5345 Binding Cache for other entries). 5347 - The home address for which that Binding Update was sent. This 5348 will be one of the following: 5350 * one the mobile node's home addresses for typical Binding 5351 Updates (Sections 11.6.1 and 11.6.2), or 5353 * the mobile node's previous care-of address for Binding 5354 Updates sent to establish forwarding from the mobile node's 5355 previous location (Section 11.6.6). 5357 - The care-of address sent in that Binding Update. This value 5358 is necessary for the mobile node to determine if it has sent a 5359 Binding Update giving its new care-of address to this destination 5360 after changing its care-of address. 5362 - The initial value of the Lifetime field sent in that Binding 5363 Update. 5365 - The remaining lifetime of that binding. This lifetime is 5366 initialized from the Lifetime value sent in the Binding Update 5367 and is decremented until it reaches zero, at which time this 5368 entry MUST be deleted from the Binding Update List. 5370 - The maximum value of the Sequence Number field sent in previous 5371 Binding Updates to this destination. The Sequence Number field 5372 is 16 bits long, and all comparisons between Sequence Number 5373 values MUST be performed modulo 2**16. For example, using an 5374 implementation in the C programming language, a Sequence Number 5375 value A is greater than another Sequence Number value B if 5376 ((short)((a) - (b)) > 0), if the "short" data type is a 16-bit 5377 signed integer. 5379 - The time at which a Binding Update was last sent to this 5380 destination, as needed to implement the rate limiting restriction 5381 for sending Binding Updates. 5383 - The state of any retransmissions needed for this Binding Update, 5384 if the Acknowledge (A) bit was set in this Binding Update. This 5385 state includes the time remaining until the next retransmission 5386 attempt for the Binding Update, and the current state of the 5387 exponential back-off mechanism for retransmissions. 5389 - A flag that, when set, indicates that future Binding Updates 5390 should not be sent to this destination. The mobile node sets 5391 this flag in the Binding Update List entry when it receives an 5392 ICMP Parameter Problem, Code 1, error message in response to 5393 a return routability message or Binding Update sent to that 5394 destination, as described in Section 11.7. 5396 The Binding Update list also conceptually contains data related to 5397 running the return routability procedure. This data is relevant only 5398 for Binding Updates sent to correspondent nodes. 5400 - The time at which a Home Test Init or Care-of Test Init message 5401 was last sent to this destination, as needed to implement the 5402 rate limiting restriction for the return routability procedure. 5404 - The state of any retransmissions needed for this return 5405 routability procedure. This state includes the time remaining 5406 until the next retransmission attempt and the current state of 5407 the exponential back-off mechanism for retransmissions. 5409 - Mobile cookie values used the Home Test Init and Care-of Test 5410 Init messages. 5412 - Home and care-of cookies received from the correspondent node. 5414 - Home and care-of nonce indices received from the correspondent 5415 node. 5417 - The time at which each of the cookies was received from this 5418 correspondent node, as needed to implement cookie reuse while 5419 moving. 5421 11.2. Packet Processing 5423 11.2.1. Sending Packets While Away from Home 5425 While a mobile node is away from home, it continues to use its home 5426 address, as well as also using one or more care-of addresses. When 5427 sending a packet while away from home, a mobile node MAY choose among 5428 these in selecting the address that it will use as the source of the 5429 packet, as follows: 5431 - From the point of view of protocol layers and applications 5432 above Mobile IP (e.g., transport protocols), the mobile node 5433 will generally use its home address as the source of the packet 5434 for most packets, even while away from home, since Mobile IP 5435 is designed to make mobility transparent to such software. 5436 For packets sent that are part of transport-level connections 5437 established while the mobile node was at home, the mobile node 5438 MUST use its home address. Likewise, for packets sent that are 5439 part of transport-level connections that the mobile node may 5440 still be using after moving to a new location, the mobile node 5441 SHOULD use its home address in this way. When sending such 5442 packets, the delivery method depends on whether a binding exists 5443 with the correspondent node. If a binding exists, the mobile 5444 node SHOULD send the packets directly to the correspondent node. 5445 Otherwise, if a binding does not exist, the mobile node MUST use 5446 reverse tunneling. Detailed operation for both of these cases is 5447 described later in this section. 5449 - For short-term communication, particularly for communication that 5450 may easily be retried if it fails, the mobile node MAY choose 5451 to directly use one of its care-of addresses as the source of 5452 the packet, thus not requiring the use of a Home Address option 5453 in the packet. An example of this type of communication might 5454 be DNS queries sent by the mobile node [17, 18]. Using the 5455 mobile node's care-of address as the source for such queries will 5456 generally have a lower overhead than using the mobile node's 5457 home address, since no extra options need be used in either the 5458 query or its reply, and all packets can be routed normally, 5459 directly between their source and destination without relying 5460 on Mobile IP. If the mobile node has no particular knowledge 5461 that the communication being sent fits within this general type 5462 of communication, however, the mobile node SHOULD NOT use its 5463 care-of address as the source of the packet in this way. 5465 For packets sent by a mobile node while it is at home, no special 5466 Mobile IP processing is required for sending this packet. Likewise, 5467 if the mobile node uses any address other than its home address as 5468 the source of a packet sent while away from home (from the point of 5469 view of higher protocol layers or applications, as described above), 5470 no special Mobile IP processing is required for sending that packet. 5472 In each case, the packet is simply addressed and transmitted in the 5473 same way as any normal IPv6 packet. 5475 For each other packet sent by the mobile node (i.e., packets 5476 sent while away from home, using the mobile node's home address 5477 as the source, from the point of view of higher protocol layers 5478 and applications), special Mobile IP processing of the packet is 5479 required. This can be done in two ways, as described above. These 5480 ways are: 5482 direct delivery 5484 This is manner of delivering packets does not require going 5485 through the home network, and typically will enable faster and 5486 more reliable transmission. A mobile node SHOULD arrange to 5487 supply the home address in a Home Address option, and allowing 5488 the IPv6 header's Source Address field to be set to one of the 5489 mobile node's care-of addresses; the correspondent node will 5490 then use the address supplied in the Home Address option to 5491 serve the function traditionally done by the Source IP address 5492 in the IPv6 header. the mobile node's home address is then 5493 supplied to higher protocol layers and applications. 5495 Specifically: 5497 - Construct the packet using the mobile node's home address 5498 as the packet's Source Address, in the same way as if the 5499 mobile node were at home. This preserves the transparency 5500 of Mobile IP to higher protocol layers (e.g., TCP). 5502 - Insert a Home Address option into the packet, with the Home 5503 Address field copied from the original value of the Source 5504 Address field in the packet. 5506 - Change the Source Address field in the packet's IPv6 header 5507 to one of the mobile node's care-of addresses. This will 5508 typically be the mobile node's current primary care-of 5509 address, but MUST be a care-of address with a subnet prefix 5510 that is on-link on the network interface on which the 5511 mobile node will transmit the packet. 5513 By using the care-of address as the Source Address in the IPv6 5514 header, with the mobile node's home address instead in the Home 5515 Address option, the packet will be able to safely pass through 5516 any router implementing ingress filtering [7]. 5518 reverse tunneling 5520 This is the mechanism which tunnels the packets via the home 5521 agent. It isn't as efficient as the above mechanism, but is 5522 needed if there is no binding yet with the correspondent node. 5523 Specifically: 5525 - The packet is sent to the home agent using IPv6 5526 encapsulation [4]. 5528 - The Source Address in the tunnel packet is the primary 5529 care-of address as registered with the home agent. 5531 - The Destination Address in the tunnel packet is the home 5532 agent's address. 5534 Reverse tunneled packets MAY be protected using a AH or ESP 5535 header, depending on the security policies used by the home 5536 agent. The support for encrypted reverse tunneling allows 5537 mobile nodes to defeat certain kinds of traffic analysis, and 5538 provides a mechanism by which routers on the home network can 5539 distinguish authorized traffic from other possibly malicious 5540 traffic. 5542 11.2.2. Interaction with Outbound IPsec Processing 5544 This section sketches the interaction between outbound Mobile 5545 IP processing and outbound IP Security (IPsec) processing for 5546 packets sent by a mobile node while away from home. Any specific 5547 implementation MAY use algorithms and data structures other than 5548 those suggested here, but its processing MUST be consistent with the 5549 effect of the operation described here and with the relevant IPsec 5550 specifications. In the steps described below, it is assumed that 5551 IPsec is being used in transport mode [14] and that the mobile node 5552 is using its home address as the source for the packet (from the 5553 point of view of higher protocol layers or applications, as described 5554 in Section 11.2.1): 5556 - The packet is created by higher layer protocols and applications 5557 (e.g., by TCP) as if the mobile node were at home and Mobile IP 5558 were not being used. Mobile IP is transparent to such higher 5559 layers. 5561 - As part of outbound packet processing in IP, the packet is 5562 compared against the IPsec security policy database to determine 5563 what processing is required for the packet [14]. 5565 - If IPsec processing is required, the packet is either mapped to 5566 an existing Security Association (or SA bundle), or a new SA (or 5567 SA bundle) is created for the packet, according to the procedures 5568 defined for IPsec. 5570 - Since the mobile node is away from home, the mobile is either 5571 using reverse tunneling or route optimization to reach the 5572 correspondent node. 5574 If reverse tunneling is used, the packet is constructed in the 5575 normal manner and then tunneled through the home agent. 5577 If route optimization is in use, the mobile node inserts a Home 5578 Address destination option into the packet, replacing the Source 5579 Address in the packet's IP header with a care-of address suitable 5580 for the link on which the packet is being sent, as described in 5581 Section 11.2.1. The Destination Options header in which the Home 5582 Address destination option is inserted MUST appear in the packet 5583 after the Routing Header, if present, and before the AH [12] (or 5584 ESP [13]) header, so that the Home Address destination option is 5585 processed by the destination node before the AH or ESP header is 5586 processed. 5588 Finally, once the packet is fully assembled, the necessary IPsec 5589 authentication (and encryption, if required) processing is 5590 performed on the packet, initializing the Authentication Data 5591 in the AH or ESP header. The AH authentication data MUST be 5592 calculated as if the following were true: 5594 * the IPv6 source address in the IPv6 header contains the 5595 mobile node's home address, 5597 * the Home Address field of the Home Address destination option 5598 (section 6.3) contains the new care-of address. 5600 - This allows, but does not require, the receiver of the packet 5601 containing a Home Address destination option to exchange the 5602 two fields of the incoming packet, simplifying processing for 5603 all subsequent packet headers. The mechanics of implementation 5604 do not absolutely require such an exchange to occur; other 5605 implementation strategies may be more appropriate, as long as the 5606 result of the authentication calculation remains the same. 5608 In addition, when using any automated key management protocol [14] 5609 (such as IKE [8]) to create a new SA (or SA bundle) while away from 5610 home, a mobile node MUST take special care in its processing of the 5611 key management protocol. Otherwise, other nodes with which the 5612 mobile node must communicate as part of the automated key management 5613 protocol processing may be unable to correctly deliver packets to 5614 the mobile node if they and/or the mobile node's home agent do 5615 not then have a current Binding Cache entry for the mobile node. 5616 For the default case of using IKE as the automated key management 5617 protocol [8][14], such problems can be avoided by the following 5618 requirements on the use of IKE by a mobile node while away from home: 5620 - The mobile node MUST use its care-of address as the Source 5621 Address of all packets it sends as part of the key management 5622 protocol (without use of Mobile IP for these packets, as 5623 suggested in Section 11.2.1). 5625 - In addition, for all security associations bound to the mobile 5626 node's home address established by way of IKE, the mobile node 5627 MUST include an ISAKMP Identification Payload [16] in the IKE 5628 exchange, giving the mobile node's home address as the initiator 5629 of the Security Association [28]. 5631 11.2.3. Receiving Packets While Away from Home 5633 While away from home, a mobile node will receive packets addressed to 5634 its home address, by one of three methods: 5636 - Packets sent by a correspondent node that does not have a 5637 Binding Cache entry for the mobile node, will be sent by the 5638 correspondent node in the same way as any normal IP packet. Such 5639 packets will then be intercepted by the mobile node's home agent, 5640 encapsulated using IPv6 encapsulation [4], and tunneled to the 5641 mobile node's primary care-of address. 5643 - Packets sent by a correspondent node that has a Binding Cache 5644 entry for the mobile node that contains the mobile node's current 5645 care-of address, will be sent by the correspondent node using 5646 a type 2 Routing header. The packet will be addressed to the 5647 mobile node's care-of address, with the final hop in the Routing 5648 header directing the packet to the mobile node's home address; 5649 the processing of this last hop of the Routing header is entirely 5650 internal to the mobile node, since the care-of address and home 5651 address are both addresses within the mobile node. 5653 - Packets sent by a correspondent node that has a Binding 5654 Cache entry for the mobile node that contains an out-of-date 5655 care-of address for the mobile node, will also be sent by the 5656 correspondent node using a type 2 Routing header, as described 5657 above. If the mobile node sent a Binding Update to a home agent 5658 on the link on which its previous care-of address is located 5659 (Section 11.6.6), and if this home agent is still serving as 5660 a home agent for the mobile node's previous care-of address, 5661 then such a packet will be intercepted by this home agent, 5662 encapsulated using IPv6 encapsulation [4], and tunneled to the 5663 mobile node's new care-of address (registered with this home 5664 agent). 5666 For packets received by the first of these methods, the mobile node 5667 MUST check that the IPv6 source address of the tunnel packet is the 5668 IP address of its home agent. 5670 For packets received by either the first or last of these three 5671 methods, the mobile node SHOULD send a Binding Update to the original 5672 sender of the packet, as described in Section 11.6.2, subject to 5673 the rate limiting defined in Section 11.6.9. The mobile node MUST 5674 also process the received packet in the manner defined for IPv6 5675 encapsulation [4], which will result in the encapsulated (inner) 5676 packet being processed normally by upper-layer protocols within the 5677 mobile node, as if it had been addressed (only) to the mobile node's 5678 home address. 5680 For packets received by the second method above (using a Type 2 5681 Routing header), the following rules will result in the packet being 5682 processed normally by upper-layer protocols within the mobile node, 5683 as if it had been addressed to the mobile node's home address. 5685 A node receiving a packet addressed to itself (i.e., one of the 5686 node's addresses is in the IPv6 destination field) follows the next 5687 header chain of headers and processes them. When it encounters 5688 a Type 2 Routing header during this processing it performs the 5689 following checks. If any of these checks fail the node MUST silently 5690 discard the packet. 5692 - The length field in the RH is exactly 2. 5694 - The segments left field in the RH is either 0 or 1. 5696 - The Home Address field in the RH is one of the node's home 5697 addresses, if the segments left field was 1. 5699 Once the above checks have been performed, the node swaps the IPv6 5700 destination field with the Home Address field in the RH, decrements 5701 segments left, and resubmits the packet to IP for processing the 5702 next header. Conceptually this follows the same model as in RFC 5703 2460. However, in the case of Type 2 Routing header this can be 5704 simplified since it is known that the packet will not be forwarded to 5705 a different node. 5707 The definition of AH requires the sender to calculate the AH 5708 integrity check value of a routing header in a way as it appears in 5709 the receiver after it has processed the header. Since IPsec headers 5710 follow the Routing Header, any IPsec processing will operate on 5711 the packet with the home address in the IP destination field and 5712 segments left being zero. Thus, the AH calculations at the sender 5713 and receiver will have an identical view of the packet. 5715 / 5717 11.2.4. Routing Multicast Packets 5719 A mobile node that is connected to its home link functions in the 5720 same way as any other (stationary) node. Thus, when it is at home, 5721 a mobile node functions identically to other multicast senders and 5722 receivers. This section therefore describes the behavior of a mobile 5723 node that is not on its home link. 5725 In order to receive packets sent to some multicast group, a mobile 5726 node must join that multicast group. One method by which a mobile 5727 node MAY join the group is via a (local) multicast router on the 5728 foreign link being visited. The mobile node SHOULD use one of its 5729 care-of addresses that shares a subnet prefix with the multicast 5730 router, as the source IPv6 address of its multicast group membership 5731 control messages. If the multicast applications depend on the 5732 address of the joining node, the mobile node MAY establish a binding 5733 with the router and use the Home Address destination option in the 5734 sent control messages. 5736 Alternatively, a mobile node MAY join multicast groups via a 5737 bi-directional tunnel to its home agent. The mobile node tunnels its 5738 multicast group membership control packets to its home agent, and the 5739 home agent forwards multicast packets down the tunnel to the mobile 5740 node. 5742 A mobile node that wishes to send packets to a multicast group 5743 also has two options: (1) send directly on the foreign link being 5744 visited; or (2) send via a tunnel to its home agent. Because 5745 multicast routing in general depends upon the Source Address used in 5746 the IPv6 header of the multicast packet, a mobile node that tunnels a 5747 multicast packet to its home agent MUST use its home address as the 5748 IPv6 Source Address of the inner multicast packet. 5750 11.3. Home Agent and Prefix Management 5752 11.3.1. Receiving Local Router Advertisement Messages 5754 Each mobile node maintains a Home Agents List recording information 5755 about all home agents from which it receives a Router Advertisement, 5756 for which the home agent lifetime indicated in that Router 5757 Advertisement has not yet expired. This list is used by the mobile 5758 node to enable it to send a Binding Update to the global unicast 5759 address of a home agent on its previous link when it moves to a new 5760 link, as described in Section 11.6.6. On receipt of a valid Router 5761 Advertisement, as defined in the processing algorithm specified for 5762 Neighbor Discovery [20], the mobile node performs the following 5763 steps, in addition to any steps already required of it by Neighbor 5764 Discovery. 5766 - If the Home Agent (H) bit in the Router Advertisement is not set, 5767 and the sending node currently has an entry in the node's Home 5768 Agents List, delete the corresponding entry. Subsequently, skip 5769 all of the following steps. 5771 - Otherwise, extract the Source Address from the IP header of the 5772 Router Advertisement. This is the link-local IP address on this 5773 link of the home agent sending this Advertisement [20]. 5775 - Determine from the Router Advertisement the preference for this 5776 home agent. If the Router Advertisement contains a Home Agent 5777 Information Option, then the preference is taken from the Home 5778 Agent Preference field in the option; otherwise, the default 5779 preference of 0 MUST be used. 5781 - Determine from the Router Advertisement the lifetime for 5782 this home agent. If the Router Advertisement contains a Home 5783 Agent Information Option, then the lifetime is taken from 5784 the Home Agent Lifetime field in the option; otherwise, the 5785 lifetime specified by the Router Lifetime field in the Router 5786 Advertisement SHOULD be used. 5788 - If the link-local address of the home agent sending this 5789 Advertisement is already present in this mobile node's Home 5790 Agents List and the received home agent lifetime value is zero, 5791 immediately delete this entry in the Home Agents List. 5793 - Otherwise, if the link-local address of the home agent sending 5794 this Advertisement is already present in the receiving mobile 5795 node's Home Agents List, reset its lifetime and preference to the 5796 values determined above. 5798 - If the link-local address of the home agent sending this 5799 Advertisement, as determined above, is not already present in the 5800 Home Agents List maintained by the receiving mobile node, and 5801 the lifetime for the sending home agent, as determined above, 5802 is non-zero, create a new entry in the list, and initialize its 5803 lifetime and preference to the values determined above. 5805 - If the Home Agents List entry for the link-local address of 5806 the home agent sending this Advertisement was not deleted as 5807 described above, determine any global address(es) of the home 5808 agent based on each Prefix Information option received in 5809 this Advertisement in which the Router Address (R) bit is set 5810 (Section 7.2). For each such global address determined from this 5811 Advertisement, add this global address to the list of global 5812 addresses for this home agent in this Home Agents List entry. 5814 A mobile node SHOULD maintain an entry in its Home Agents List for 5815 each such valid home agent address until that entry's lifetime 5816 expires, after which time the entry MUST be deleted. 5818 11.3.2. Dynamic Home Agent Address Discovery 5820 Sometimes, when the mobile node needs to send a Binding Update to its 5821 home agent to register its new primary care-of address, as described 5822 in Section 11.6.1, the mobile node may not know the address of any 5823 router on its home link that can serve as a home agent for it. For 5824 example, some nodes on its home link may have been reconfigured while 5825 the mobile node has been away from home, such that the router that 5826 was operating as the mobile node's home agent has been replaced by a 5827 different router serving this role. 5829 In this case, the mobile node MAY attempt to discover the address of 5830 a suitable home agent on its home link. To do so, the mobile node 5831 sends an ICMP Home Agent Address Discovery Request message to the 5832 "Mobile IPv6 Home-Agents" anycast address [11] for its home subnet 5833 prefix. As described in Section 10.9, the home agent on its home 5834 link that receives this Request message will return an ICMP Home 5835 Agent Address Discovery Reply message, giving this home agent's own 5836 global unicast IP address along with a list of the global unicast IP 5837 address of each other home agent operating on the home link. 5839 The mobile node, upon receiving this Home Agent Address Discovery 5840 Reply message, MAY then send its home registration Binding Update to 5841 the home agent address given as the IP Source Address of the packet 5842 carrying the Reply message or to any of the unicast IP addresses 5843 listed in the Home Agent Addresses field in the Reply. For example, 5844 if necessary, the mobile node MAY attempt its home registration 5845 with each of these home agents, in turn, by sending each a Binding 5846 Update and waiting for the matching Binding Acknowledgement, until 5847 its registration is accepted by one of these home agents. In trying 5848 each of the returned home agent addresses, the mobile node SHOULD try 5849 each in the order listed in the Home Agent Addresses field in the 5850 received Home Agent Address Discovery Reply message. If the home 5851 agent identified by the Source Address field in the IP header of the 5852 packet carrying the Home Agent Address Discovery Reply message is 5853 not listed in the Home Agent Addresses field in the Reply, it SHOULD 5854 be tried before the first address given in the list; otherwise, it 5855 SHOULD be tried in its listed order. 5857 If the mobile node has a current registration with some home agent 5858 on its home link (the Lifetime for that registration has not yet 5859 expired), then the mobile node MUST attempt any new registration 5860 first with that home agent. If that registration attempt fails 5861 (e.g., times out or is rejected), the mobile node SHOULD then 5862 reattempt this registration with another home agent on its home link. 5863 If the mobile node knows of no other suitable home agent, then it MAY 5864 attempt the dynamic home agent address discovery mechanism described 5865 above. 5867 If, after a mobile node transmits a Home Agent Address Discovery 5868 Request message to the Home Agents Anycast address, it does not 5869 receive a corresponding Home Agent Address Discovery Reply message 5870 within INITIAL_DHAAD_TIMEOUT seconds, the mobile node MAY retransmit 5871 the same Request message to the same anycast address. This 5872 retransmission MAY be repeated up to a maximum of DHAAD_RETRIES 5873 attempts. Each retransmission MUST be delayed by twice the time 5874 interval of the previous retransmission. 5876 11.3.3. Sending Mobile Prefix Solicitations 5878 When a mobile node has a home address that is about to become 5879 invalid, it sends a Mobile Prefix Solicitation to its home agent 5880 in an attempt to acquire fresh routing prefix information. The 5881 new information also enables the mobile node to participate in 5882 renumbering operations affecting the home network, as described in 5883 section 10.9.1. 5885 The mobile node SHOULD send a Solicitation to the home agent when 5886 its home address will become invalid within MaxRtrAdvInterval 5887 seconds, where this value is acquired in a previous Mobile Prefix 5888 Advertisement from the home agent. If no such value is known, the 5889 value MAX_PFX_ADV_DELAY seconds is used instead (see section 12). 5891 If the mobile node does not have a valid home address available for 5892 use as the IP source address, it MAY use its care-of address, but 5893 there will not be a security association between the home agent 5894 and the care-of address for the corresponding Advertisement to be 5895 authenticated. 5897 This solicitation follows the same retransmission rules specified for 5898 Router Solicitations [20], except that the initial retransmission 5899 interval is specified to be INITIAL_SOLICIT_TIMER (see section 12). 5901 As described in Section 11.6.2, Binding Updates sent by the mobile 5902 node to other nodes MUST use a lifetime no greater than the remaining 5903 lifetime of its home registration of its primary care-of address. 5904 The mobile node SHOULD further limit the lifetimes that it sends on 5905 any Binding Updates to be within the remaining preferred lifetime 5906 (see Section 10.9.2) for the prefix in its home address. 5908 When the lifetime for a changed prefix decreases, and the change 5909 would cause cached bindings at correspondent nodes in the Binding 5910 Update List to be stored past the newly shortened lifetime, the 5911 mobile node MUST issue a Binding Update to all such correspondent 5912 nodes. 5914 These limits on the binding lifetime serve to prohibit use of a 5915 mobile node's home address after it becomes invalid. 5917 11.3.4. Receiving Mobile Prefix Advertisements 5919 Section 10.9.1 describes the operation of a home agent to support 5920 boot time configuration and renumbering a mobile node's home subnet 5921 while the mobile node is away from home. The home agent sends Mobile 5922 Prefix Advertisement messages to the mobile node while away from 5923 home, giving "important" Prefix Information options that describe 5924 changes in the prefixes in use on the mobile node's home link. 5926 When a mobile node receives a Mobile Prefix Advertisement, it MUST 5927 validate it according to the following tests: 5929 - The Source Address of the IP packet carrying the Mobile Prefix 5930 Advertisement is the same as the home agent address to which the 5931 mobile node last sent an accepted "home registration" Binding 5932 Update to register its primary care-of address. Otherwise, if 5933 no such registrations have been made, it SHOULD be the mobile 5934 node's stored home agent address, if one exists. Otherwise, if 5935 the mobile node has not yet discovered its home agent's address, 5936 it MUST NOT accept Mobile Prefix Advertisements. 5938 - The packet MUST be protected by IPsec [14, 12, 13] to guard 5939 against malicious prefix advertisements, if a security 5940 association exists (i.e. unless the mobile node does not yet 5941 have a home address configured). The IPsec protection MUST 5942 provide sender authentication, data integrity protection, and 5943 replay protection, covering the advertisement. 5945 Any received Mobile Prefix Advertisement not meeting all of these 5946 tests MUST be silently discarded. 5948 If a received Mobile Prefix Advertisement is not discarded according 5949 to the tests listed above, the mobile node MUST process the Prefix 5950 Information Options as if they arrived in a Router Advertisement 5951 on the mobile node's home link [20]. Such processing may result 5952 in the mobile node configuring a new home address, although due 5953 to separation between preferred lifetime and valid lifetime, such 5954 changes should not affect most communication by the mobile node, in 5955 the same way as for nodes that are at home. 5957 If the advertisement contains a Binding Refresh Request option, the 5958 mobile node SHOULD return a Binding Update, which will be viewed by 5959 the home agent as an acknowledgement of the corresponding Mobile 5960 Prefix Advertisement, which it can cease transmitting. 5962 In addition, if processing of this Advertisement resulted in the 5963 mobile node configuring a new home address, and if the method used 5964 for this new home address configuration would require the mobile node 5965 to perform Duplicate Address Detection [33] for the new address if 5966 the mobile node were located at home, then the mobile node MUST set 5967 the Duplicate Address Detection (D) bit in this Binding Update to 5968 its home agent, to request the home agent to perform this Duplicate 5969 Address Detection on behalf of the mobile node. 5971 11.4. Movement 5973 11.4.1. Movement Detection 5975 A mobile node MAY use any combination of mechanisms available to it 5976 to detect when it has moved from one link to another. The primary 5977 movement detection mechanism for Mobile IPv6 defined here uses the 5978 facilities of IPv6 Neighbor Discovery, including Router Discovery and 5979 Neighbor Unreachability Detection, although the mobile node SHOULD 5980 supplement this mechanism with other information whenever it is 5981 available to the mobile node (e.g., from lower protocol layers). The 5982 description here is based on the conceptual model of the organization 5983 and data structures defined by Neighbor Discovery [20]. 5985 Mobile nodes SHOULD use Router Discovery to discover new routers and 5986 on-link subnet prefixes; a mobile node MAY send Router Solicitation 5987 messages, or MAY wait for unsolicited (periodic) multicast Router 5988 Advertisement messages, as specified for Router Discovery [20]. 5989 Based on received Router Advertisement messages, a mobile node (in 5990 the same way as any other node) maintains an entry in its Default 5991 Router List for each router, and an entry in its Prefix List for each 5992 subnet prefix, that it currently considers to be on-link. Each entry 5993 in these lists has an associated invalidation timer value (extracted 5994 from the Router Advertisement and Prefix Information options) used to 5995 expire the entry when it becomes invalid. 5997 While away from home, a mobile node typically selects one router 5998 from its Default Router List to use as its default router, and one 5999 subnet prefix advertised by that router from its Prefix List to use 6000 as the subnet prefix in its primary care-of address. A mobile node 6001 MAY also have associated additional care-of addresses, using other 6002 subnet prefixes from its Prefix List. The method by which a mobile 6003 node selects and forms a care-of address from the available subnet 6004 prefixes is described in Section 11.4.2. The mobile node registers 6005 its primary care-of address with its home agent, as described in 6006 Section 11.6.1. 6008 While a mobile node is away from home and using some router as its 6009 default router, it is important for the mobile node to be able to 6010 quickly detect when that router becomes unreachable, so that it 6011 can switch to a new default router and (if needed, according to 6012 prefix advertisement) to a new primary care-of address. Since some 6013 links (notably wireless) do not necessarily work equally well in 6014 both directions, it is likewise important for the mobile node to 6015 detect when it becomes unreachable for packets sent from its default 6016 router, so that the mobile node can take steps to ensure that any 6017 correspondent nodes attempting to communicate with it can still reach 6018 it through some other route. 6020 To detect when its default router becomes unreachable, a mobile 6021 node SHOULD use Neighbor Unreachability Detection. As specified in 6022 Neighbor Discovery [20], while the mobile node is actively sending 6023 packets to (or through) its default router, the mobile node can 6024 detect that the router (as its neighbor) is still reachable either 6025 through indications from upper layer protocols on the mobile node 6026 that a connection is making "forward progress" (e.g., receipt of TCP 6027 acknowledgements for new data transmitted), or through receipt of a 6028 Neighbor Advertisement message from its default router in response 6029 to an explicit Neighbor Solicitation messages to it. Note that 6030 although this mechanism detects that the mobile node's default router 6031 has become unreachable to the mobile node only while the mobile node 6032 is actively sending packets to it, this is the only time that this 6033 direction of reachability confirmation is needed. Confirmation 6034 that the mobile node is still reachable from the router is handled 6035 separately, as described below. 6037 For a mobile node to detect when it has become unreachable from its 6038 default router, the mobile node cannot efficiently rely on Neighbor 6039 Unreachability Detection alone, since the network overhead would be 6040 prohibitively high in many cases for a mobile node to continually 6041 probe its default router with Neighbor Solicitation messages even 6042 when it is not otherwise actively sending packets to it. Instead, 6043 when a mobile node receives any IPv6 packets from its current default 6044 router at all, irrespective of the source IPv6 address, it SHOULD use 6045 that as an indication that it is still reachable from the router. 6047 Since the router SHOULD be sending periodic unsolicited multicast 6048 Router Advertisement messages, the mobile node will have frequent 6049 opportunity to check if it is still reachable from its default 6050 router, even in the absence of other packets to it from the router. 6051 If Router Advertisements that the mobile node receives include 6052 an Advertisement Interval option, the mobile node MAY use its 6053 Advertisement Interval field as an indication of the frequency with 6054 which it SHOULD expect to continue to receive future Advertisements 6055 from that router. This field specifies the minimum rate (the maximum 6056 amount of time between successive Advertisements) that the mobile 6057 node SHOULD expect. If this amount of time elapses without the 6058 mobile node receiving any Advertisement from this router, the mobile 6059 node can be sure that at least one Advertisement sent by the router 6060 has been lost. It is thus possible for the mobile node to implement 6061 its own policy for determining the number of Advertisements from 6062 its current default router it is willing to tolerate losing before 6063 deciding to switch to a different router from which it may currently 6064 be correctly receiving Advertisements. 6066 On some types of network interfaces, the mobile node MAY also 6067 supplement this monitoring of Router Advertisements, by setting its 6068 network interface into "promiscuous" receive mode, so that it is able 6069 to receive all packets on the link, including those not addressed to 6070 it at the link layer (i.e., disabling link-level address filtering). 6071 The mobile node will then be able to detect any packets sent by the 6072 router, in order to detect reachability from the router. This use of 6073 promiscuous mode may be useful on very low bandwidth (e.g., wireless) 6074 links, but its use MUST be configurable on the mobile node since it 6075 is likely to consume additional energy resources. 6077 If the above means do not provide indication that the mobile node 6078 is still reachable from its current default router (for instance, 6079 the mobile node receives no packets from the router for a period 6080 of time), then the mobile node SHOULD attempt to actively probe 6081 the router with Neighbor Solicitation messages, even if it is not 6082 otherwise actively sending packets to the router. If it receives a 6083 solicited Neighbor Advertisement message in response from the router, 6084 then the mobile node can deduce that it is still reachable. It is 6085 expected that the mobile node will in most cases be able to determine 6086 its reachability from the router by listening for packets from the 6087 router as described above, and thus, such extra Neighbor Solicitation 6088 probes should rarely be necessary. 6090 With some types of networks, indications about link-layer mobility 6091 might be obtained from lower-layer protocol or device driver software 6092 within the mobile node. However, all link-layer mobility indications 6093 from lower layers do not necessarily indicate a movement of the 6094 mobile node to a new link, such that the mobile node would need to 6095 switch to a new default router and primary care-of address. For 6096 example, movement of a mobile node from one cell to another in many 6097 wireless LANs can be made transparent to the IP level through use of 6098 a link-layer "roaming" protocol, as long as the different wireless 6099 LAN cells all operate as part of the same IP link with the same 6100 subnet prefix. Upon lower-layer indication of link-layer mobility, 6101 the mobile node MAY send Router Solicitation messages to determine if 6102 additional on-link subnet prefixes are available on its new link. 6104 Such lower-layer information might also be useful to a mobile node in 6105 deciding to switch its primary care-of address to one of the other 6106 care-of addresses it has formed from the on-link subnet prefixes 6107 currently available through different routers from which the mobile 6108 node is reachable. For example, a mobile node MAY use signal 6109 strength or signal quality information (with suitable hysteresis) for 6110 its link with the available routers to decide when to switch to a new 6111 primary care-of address using that router rather than its current 6112 default router (and current primary care-of address). Even though 6113 the mobile node's current default router may still be reachable in 6114 terms of Neighbor Unreachability Detection, the mobile node MAY use 6115 such lower-layer information to determine that switching to a new 6116 default router would provide a better connection. 6118 11.4.2. Forming New Care-of Addresses 6120 After detecting that it has moved from one link to another (i.e., its 6121 current default router has become unreachable and it has discovered 6122 a new default router), a mobile node SHOULD form a new primary 6123 care-of address using one of the on-link subnet prefixes advertised 6124 by the new router. A mobile node MAY form a new primary care-of 6125 address at any time, except that it MUST NOT do so too frequently. 6126 Specifically, a mobile node MUST NOT send a Binding Update about a 6127 new care-of address to its home agent (which is required to register 6128 the new address as its primary care-of address) more often than once 6129 per MAX_UPDATE_RATE seconds. 6131 In addition, after discovering a new on-link subnet prefix, a mobile 6132 node MAY form a new (non-primary) care-of address using that subnet 6133 prefix, even when it has not switched to a new default router. A 6134 mobile node can have only one primary care-of address at a time 6135 (which is registered with its home agent), but it MAY have an 6136 additional care-of address for any or all of the prefixes on its 6137 current link. Furthermore, since a wireless network interface may 6138 actually allow a mobile node to be reachable on more than one link at 6139 a time (i.e., within wireless transmitter range of routers on more 6140 than one separate link), a mobile node MAY have care-of addresses 6141 on more than one link at a time. The use of more than one care-of 6142 address at a time is described in Section 11.4.3. 6144 As described in Section 4, in order to form a new care-of address, 6145 a mobile node MAY use either stateless [33] or stateful (e.g., 6146 DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to 6147 send packets as part of the method of address autoconfiguration, 6148 it MUST use an IPv6 link-local address rather than its own IPv6 6149 home address as the Source Address in the IPv6 header of each such 6150 autoconfiguration packet. 6152 In some cases, a mobile node may already know a (constant) IPv6 6153 address that has been assigned to it for its use only while 6154 visiting a specific foreign link. For example, a mobile node may be 6155 statically configured with an IPv6 address assigned by the system 6156 administrator of some foreign link, for its use while visiting that 6157 link. If so, rather than using Address Autoconfiguration to form a 6158 new care-of address using this subnet prefix, the mobile node MAY use 6159 its own pre-assigned address as its care-of address on this link. 6161 After forming a new care-of address, a mobile node MAY perform 6162 Duplicate Address Detection [33] on that new address to confirm its 6163 uniqueness. However, doing so represents a trade-off between safety 6164 (ensuring that the new address is not used if it is a duplicate 6165 address) and overhead (performing Duplicate Address Detection 6166 requires the sending of one or more additional packets over what 6167 may be, for example, a slow wireless link through which the mobile 6168 node is connected). Performing Duplicate Address Detection also in 6169 general would cause a delay before the mobile node could use the 6170 new care-of address, possibly causing the mobile node to be unable 6171 to continue communication with correspondent nodes for some period 6172 of time. For these reasons, a mobile node, after forming a new 6173 care-of address, MAY begin using the new care-of address without 6174 performing Duplicate Address Detection. Furthermore, the mobile node 6175 MAY continue using the address without performing Duplicate Address 6176 Detection, although it SHOULD in most cases (e.g., unless network 6177 bandwidth or battery consumption for communication is of primary 6178 concern) begin Duplicate Address Detection asynchronously when it 6179 begins use of the address, allowing the Duplicate Address Detection 6180 procedure to complete in parallel with normal communication using the 6181 address. 6183 In addition, normal processing for Duplicate Address Detection 6184 specifies that, in certain cases, the node SHOULD delay sending the 6185 initial Neighbor Solicitation message of Duplicate Address Detection 6186 by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [20, 33]; 6187 however, in this case, the mobile node SHOULD NOT perform such a 6188 delay in its use of Duplicate Address Detection, unless the mobile 6189 node is initializing after rebooting. 6191 11.4.3. Using Multiple Care-of Addresses 6193 As described in Section 11.4.2, a mobile node MAY use more than one 6194 care-of address at a time. Particularly in the case of many wireless 6195 networks, a mobile node effectively might be reachable through 6196 multiple links at the same time (e.g., with overlapping wireless 6197 cells), on which different on-link subnet prefixes may exist. A 6198 mobile node SHOULD select a primary care-of address from among those 6199 care-of addresses it has formed using any of these subnet prefixes, 6200 based on the movement detection mechanism in use, as described in 6201 Section 11.4.1. When the mobile node selects a new primary care-of 6202 address, it MUST register it with its home agent by sending it a 6203 Binding Update with the Home Registration (H) and Acknowledge (A) 6204 bits set, as described in Section 11.6.1. 6206 To assist with smooth handovers, a mobile node SHOULD retain 6207 its previous primary care-of address as a (non-primary) care-of 6208 address, and SHOULD still accept packets at this address, even after 6209 registering its new primary care-of address with its home agent. 6210 This is reasonable, since the mobile node could only receive packets 6211 at its previous primary care-of address if it were indeed still 6212 connected to that link. If the previous primary care-of address was 6213 allocated using stateful Address Autoconfiguration [2], the mobile 6214 node may not wish to release the address immediately upon switching 6215 to a new primary care-of address. 6217 11.5. Return Routability Procedure 6219 This section defines the rules that the mobile node must follow 6220 when performing the return routability procedure. Appendix A 6221 specifies also a (non-normative) state-machine that describes the 6222 same procedure. Section 11.6.2 describes the rules when the return 6223 routability procedure needs to be initiated. 6225 11.5.1. Sending Home and Care-of Test Init Messages 6227 A mobile node that initiates a return routability procedure MUST 6228 send (in parallel) a Home Test Init message and a Care-of Test Init 6229 messages. A Home Test Init message MUST be created as described 6230 in Section 6.1.3. A Care-of Test Init message MUST be created as 6231 described in Section 6.1.4. 6233 When sending a Home Test Init or Care-of Test Init message the mobile 6234 node MUST record in its Binding Update List the following fields from 6235 the messages: 6237 - The IP address of the node to which the message was sent. 6239 - The home address for which the binding is desired. This value 6240 will appear in the Source Address field of the Home Test Init 6241 message. 6243 - The time at which each of these messages was sent. 6245 - The mobile cookie used in the messages. 6247 11.5.2. Receiving Return Routability Messages 6249 Upon receiving a packet carrying a Home Test message, a mobile node 6250 MUST validate the packet according to the following tests: 6252 - The Header Len field in the Mobility Header is greater than or 6253 equal to the length specified in Section 6.1.5. 6255 - The Source Address of the packet belongs to a correspondent 6256 node for which the mobile node has a Binding Update List entry 6257 with a state indicating that return routability procedure is in 6258 progress. 6260 - The Binding Update List indicates that no home cookie has been 6261 received yet. 6263 - The Destination Address of the packet has the home address of the 6264 mobile node, and the packet has been received in a tunnel from 6265 the home agent. 6267 - The Mobile Cookie field in the message matches the value stored 6268 in the Binding Update List. 6270 Any Home Test message not satisfying all of these tests MUST be 6271 silently ignored. Otherwise, the mobile node MUST record the Home 6272 Nonce Index and Home Cookie in the Binding Update List. If the 6273 Binding Update List entry does not have a Care-of Cookie, the mobile 6274 node SHOULD continue waiting for additional messages. 6276 Upon receiving a packet carrying a Care-of Test message, a mobile 6277 node MUST validate the packet according to the following tests: 6279 - The Header Len field in the Mobility Header is greater than or 6280 equal to the length specified in Section 6.1.6. 6282 - The Source Address of the packet belongs to a correspondent 6283 node for which the mobile node has a Binding Update List entry 6284 with a state indicating that return routability procedure is in 6285 progress. 6287 - The Binding Update List indicates that no care-of cookie has been 6288 received yet. 6290 - The Destination Address of the packet is the current care-of 6291 address of the mobile node. 6293 - The Mobile Cookie field in the message matches the value stored 6294 in the Binding Update List. 6296 Any Care-of Test message not satisfying all of these tests MUST be 6297 silently ignored. Otherwise, the mobile node MUST record the Care-of 6298 Nonce Index and Care-of Cookie in the Binding Update List. If the 6299 Binding Update List entry does not have a Home Cookie, the mobile 6300 node SHOULD continue waiting for additional messages. 6302 If after receiving either the Home Test or the Care-of Test message 6303 and performing the above actions, the Binding Update List entry 6304 has both the Home and the Care-of Cookies, the return routability 6305 procedure is complete. The mobile node SHOULD then proceed with 6306 sending a Binding Update message as described in Section 11.6.2. 6308 Correspondent nodes from the time before this specification was 6309 published may not not support the Mobility Header protocol. These 6310 nodes will respond to Home Test Init and Care-of Test Init messages 6311 with an ICMP Parameter Problem code 1. The mobile node SHOULD 6312 take such messages as an indication that the correspondent node 6313 can not provide route optimization, and revert back to the use of 6314 bidirectional routing. 6316 11.5.3. Retransmitting in the Return Routability Procedure 6318 The mobile node is responsible for retransmissions in the return 6319 routability procedure. 6321 When the mobile node sends a Home Test Init or Care-of Test Init 6322 message, it has to determine a value for the initial retransmission 6323 timer. It should use the specified value of INITIAL_BINDACK_TIMEOUT 6324 for this initial retransmission timer. 6326 If, after sending either a Home Test Init or Care-of Test Init 6327 message and the mobile node fails to receive a valid, matching 6328 Home Test or Care-of Test message within the selected initial 6329 retransmission interval, the mobile node SHOULD retransmit 6330 the original message, until a valid answer is received. The 6331 retransmissions by the mobile node MUST use an exponential 6332 back-off process, in which the timeout period is doubled upon each 6333 retransmission until either the node receives a valid response or the 6334 timeout period reaches the value MAX_BINDACK_TIMEOUT. 6336 11.5.4. Rate Limiting for Return Routability Procedure 6338 A mobile node MUST NOT send Home Test Init or Care-of Test 6339 Init messages to any individual node more often than once per 6340 MAX_UPDATE_RATE seconds. After sending MAX_FAST_UPDATES consecutive 6341 messages to a particular node with the same care-of address, the 6342 mobile node SHOULD reduce its rate of sending these messages to that 6343 node, to the rate of SLOW_UPDATE_RATE per second. The mobile node 6344 MAY continue to send these messages at this slower rate indefinitely, 6345 in hopes that the node will eventually be able to complete the return 6346 routability procedure. 6348 11.6. Processing Bindings 6350 11.6.1. Sending Binding Updates to the Home Agent 6352 After deciding to change its primary care-of address as described in 6353 Sections 11.4.1 and 11.4.2, a mobile node MUST register this care-of 6354 address with its home agent in order to make this its primary care-of 6355 address. To do so, the mobile node sends a packet to its home agent 6356 containing a Binding Update message, with the packet constructed as 6357 follows: 6359 - The Home Registration (H) bit MUST be set in the Binding Update. 6361 - The Acknowledge (A) bit MUST be set in the Binding Update. 6363 - The packet MUST contain a Home Address destination option, giving 6364 the mobile node's home address for the binding. 6366 - The care-of address for the binding MUST be used as the Source 6367 Address in the packet's IPv6 header, unless an Alternate Care-of 6368 Address mobility option is included in the Binding Update 6369 message. 6371 - The `S' bit is set to the zero to request the mobile node's home 6372 agent to serve as a home agent for all home addresses for the 6373 mobile node based on all on-link subnet prefixes on the home 6374 link; this is the default behavior. If the mobile node desires 6375 that only a single home address should be affected by this 6376 Binding Update, the `S' bit can be set to 1. 6378 - The value specified in the Lifetime field SHOULD be less than 6379 or equal to the remaining lifetime of the home address and the 6380 care-of address specified for the binding. 6382 The Acknowledge (A) bit in the Binding Update requests the home agent 6383 to return a Binding Acknowledgement in response to this Binding 6384 Update. As described in Section 6.1.8, the mobile node SHOULD 6385 retransmit this Binding Update to its home agent until it receives 6386 a matching Binding Acknowledgement. Once reaching a retransmission 6387 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart 6388 the process of delivering the Binding Update, but trying instead the 6389 next home agent from its Home Agents List (see Section 11.3.2). If 6390 there is only one home agent in the Home Agents List, the mobile node 6391 instead SHOULD continue to periodically retransmit the Binding Update 6392 at this rate until acknowledged (or until it begins attempting to 6393 register a different primary care-of address). See Section 11.6.8 6394 for information about retransmitting Binding Updates. 6396 Depending on the value of the Single Address Only (S) bit in the 6397 Binding Update, the home agent is requested to serve either a single 6398 home address or all home home addresses for the mobile node. Until 6399 the lifetime of this registration expires, the home agent considers 6400 itself the home agent for each such home address of the mobile node. 6401 As the set of on-link subnet prefixes on the home link changes over 6402 time, the home agent changes the set of home addresses for this 6403 mobile node for which it is serving as the home agent. 6405 Each Binding Update MUST be authenticated as coming from the right 6406 mobile node, as defined in Section 5.4. The mobile node MUST use a 6407 Home Address destination option in Binding Updates sent to the home 6408 agent in order to allow the IPsec policies to be matched with the 6409 right home address. The home address in the Home Address destination 6410 option and the Binding Update message MUST be equal (and this will be 6411 checked by the home agent). 6413 When sending a Binding Update to its home agent, the mobile node MUST 6414 also create or update the corresponding Binding Update List entry, as 6415 specified in Section 11.6.2. 6417 The last Sequence Number value sent to the home agent in a Binding 6418 Update is stored by the mobile node. If the sending mobile node has 6419 no knowledge of the right Sequence Number value, it may start at any 6420 value. If the home agent rejects the value, it sends back a Binding 6421 Acknowledgement with status code 141, and the last accepted sequence 6422 number in the Sequence Number field of the Binding Acknowledgement. 6423 The mobile node MUST store this information and use the next Sequence 6424 Number value for the next Binding Update it sends. 6426 If the mobile node has additional home addresses using a different 6427 interface identifier, then the mobile node SHOULD send an additional 6428 packet containing a Binding Update to its home agent to register the 6429 care-of address for each such other home address (or set of home 6430 addresses sharing an interface identifier). 6432 While the mobile node is away from home, it relies on the home agent 6433 to participate in Duplicate Address Detection (DAD) to defend its 6434 home address against stateless autoconfiguration performed by another 6435 node. Therefore, the mobile node SHOULD set the Duplicate Address 6436 Detection (D) bit based on any requirements for DAD that would apply 6437 to the mobile node if it were at home [20][33]. If the mobile 6438 node's recent Binding Update was accepted by the home agent, and the 6439 lifetime for that Binding Update has not yet expired, the mobile node 6440 SHOULD NOT set the `D' bit in the new Binding Update; the home agent 6441 will already be defending the home address(es) of the mobile node and 6442 does not need to perform DAD again. 6444 The home agent will only perform DAD for the mobile node's home 6445 address when the mobile node has supplied a valid binding between 6446 its home address and a care-of address. If some time elapses during 6447 which the mobile node has no binding at the home agent, it might 6448 be possible for another node to autoconfigure the mobile node's 6449 home address. Therefore, the mobile node MUST treat creation of 6450 a new binding with the home agent using an existing home address 6451 the same as creation of a new home address. In the unlikely event 6452 that the mobile node's home address is autoconfigured as the IPv6 6453 address of another network node on the home network, the home agent 6454 will reply to the mobile node's subsequent Binding Update with a 6455 Binding Acknowledgement containing a Status of 138, Duplicate Address 6456 Detection failed. In this case, the mobile node MUST NOT attempt to 6457 re-use the same home address. It SHOULD continue to register care-of 6458 addresses for its other home addresses, if any. The mobile node MAY 6459 also attempt to acquire a new home address to replace the one for 6460 which Status 138 was received, for instance by using the techniques 6461 described in Appendix B. 6463 11.6.2. Correspondent Binding Procedure 6465 When the mobile node is assured that its home address is valid, it 6466 MAY at any time initiate a correspondent binding procedure with 6467 the purpose of allowing the correspondent node to cache the mobile 6468 node's current care-of address. The mobile node is responsible for 6469 the initiation and completion of this procedure, as well as any 6470 retransmissions that may be needed (subject to the rate limiting 6471 defined in Section 11.6.9). 6473 This section defines the rules that the mobile node must follow 6474 when performing the correspondent binding procedure. Appendix A 6475 specifies also a (non-normative) state-machine that describes the 6476 same procedure. 6478 The mobile node can be assured that its home address is still valid, 6479 for example, by the home agent's use the 'D' bit of Binding Updates 6480 (see Section 10.2). In any Binding Update sent by a mobile node, 6481 the care-of address (either the Source Address in the packet's IPv6 6482 header or the Care-of Address in the Alternate Care-of Address 6483 mobility option of the Binding Update) MUST be set to one of the 6484 care-of addresses currently in use by the mobile node or to the 6485 mobile node's home address. A mobile node MAY set the care-of 6486 address differently for sending Binding Updates to different 6487 correspondent nodes. 6489 A mobile node MAY choose to keep its location private from 6490 certain correspondent nodes, and thus need not initiate the 6491 return routability procedure, or send new Binding Updates to those 6492 correspondents. A mobile node MAY also send a Binding Update to 6493 such a correspondent node to instruct it to delete any existing 6494 binding for the mobile node from its Binding Cache, as described in 6495 Section 6.1.7. However, all Binding Updates to the correspondent 6496 node require the successful completion of the return routability 6497 procedure first, as no other IPv6 nodes are authorized to send 6498 Binding Updates on behalf of a mobile node. 6500 If set to one of the mobile node's current care-of addresses (the 6501 care-of address given MAY differ from the mobile node's primary 6502 care-of address), the Binding Update requests the correspondent node 6503 to create or update an entry for the mobile node in the correspondent 6504 node's Binding Cache in order to record this care-of address for use 6505 in sending future packets to the mobile node. In this case, the 6506 value specified in the Lifetime field sent in the Binding Update 6507 SHOULD be less than or equal to the remaining lifetime of the home 6508 address and the care-of address specified for the binding. 6510 If, instead, the care-of address is set to the mobile node's home 6511 address, the Binding Update requests the correspondent node to delete 6512 any existing Binding Cache entry that it has for the mobile node. 6514 When a mobile node sends a Binding Update to its home agent 6515 to register a new primary care-of address (as described in 6516 Section 11.6.1), the mobile node SHOULD also start a return 6517 routability procedure to each other node for which an entry exists 6518 in the mobile node's Binding Update List, as detailed below. Upon 6519 successful return routability procedure, a Binding Update message is 6520 sent. Thus, other relevant nodes are generally kept updated about 6521 the mobile node's binding and can send packets directly to the mobile 6522 node using the mobile node's current care-of address. 6524 The mobile node, however, need not initiate these actions immediately 6525 after configuring a new care-of address. For example, the mobile 6526 node MAY delay initiating the return routability procedure to any 6527 correspondent node for a short period of time, if it isn't certain 6528 that there's traffic to the correspondent node. This is particularly 6529 useful if the mobile node anticipates that it is not going to stay 6530 long in this location. 6532 In addition, when a mobile node receives a packet for which the 6533 mobile node can deduce that the original sender of the packet either 6534 has no Binding Cache entry for the mobile node, or a stale entry 6535 for the mobile node in its Binding Cache, the mobile node SHOULD 6536 initiate a return routability procedure with the sender, in order to 6537 finally update the sender's Binding Cache with the current care-of 6538 address (subject to the rate limiting defined in Section 11.6.9). 6539 In particular, the mobile node SHOULD initiate a return routability 6540 procedure in response to receiving a packet that meets all of the 6541 following tests: 6543 - The packet was tunneled using IPv6 encapsulation. 6545 - The Destination Address in the tunnel (outer) IPv6 header is 6546 equal to any of the mobile node's care-of addresses. 6548 - The Destination Address in the original (inner) IPv6 header 6549 is equal to one of the mobile node's home addresses; or this 6550 Destination Address is equal to one of the mobile node's previous 6551 care-of addresses for which the mobile node has an entry in its 6552 Binding Update List, representing an unexpired Binding Update 6553 sent to a home agent on the link on which its previous care-of 6554 address is located (Section 11.6.6). 6556 - The Source Address in the tunnel (outer) IPv6 header differs from 6557 the Source Address in the original (inner) IPv6 header. 6559 The destination address to which the procedure should be initiated to 6560 in response to receiving a packet meeting all of the above tests is 6561 the Source Address in the original (inner) IPv6 header of the packet. 6562 The home address for which this Binding Update is sent should be the 6563 Destination Address of the original (inner) packet. 6565 Binding Updates sent to correspondent nodes are not generally 6566 required to be acknowledged. However, if the mobile node wants 6567 to be sure that its new care-of address has been entered into a 6568 correspondent node's Binding Cache, the mobile node MAY request an 6569 acknowledgement by setting the Acknowledge (A) bit in the Binding 6570 Update. In this case, however, the mobile node SHOULD NOT continue 6571 to retransmit the Binding Update once the retransmission timeout 6572 period has reached MAX_BINDACK_TIMEOUT. 6574 The mobile node SHOULD create a Binding Update message as follows: 6576 - The Source Address of the IPv6 header MUST contain the current 6577 care-of address of the mobile node. 6579 - The Destination Address of the IPv6 header MUST contain the 6580 address of the correspondent node. 6582 - The Mobility Header is constructed according to rules in 6583 Section 6.1.7, including the authenticator field which is 6584 calculated based on the received Home and Care-of Cookies. 6586 The last Sequence Number value sent to a destination in a Binding 6587 Update is stored by the mobile node in its Binding Update List entry 6588 for that destination. If the sending mobile node has no Binding 6589 Update List entry, the Sequence Number SHOULD start at a random 6590 value. The mobile node MUST NOT use the same Sequence Number in two 6591 different Binding Updates to the same correspondent node, even if the 6592 Binding Updates provide different care-of addresses. 6594 11.6.3. Receiving Binding Acknowledgements 6596 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 6597 node MUST validate the packet according to the following tests: 6599 - The packet meets the authentication requirements for Binding 6600 Acknowledgements, defined in Sections 6.1.8 and 5. That is, 6601 if the Binding Update was sent to the home agent, underlying 6602 IPsec protection is used. If the Binding Update was sent to the 6603 correspondent node, the authenticator field MUST be present and 6604 have a valid value. 6606 - The Header Len field in the Binding Acknowledgement message is 6607 greater than or equal to the length specified in Section 6.1.8. 6609 - The Sequence Number field matches the Sequence Number sent by the 6610 mobile node to this destination address in an outstanding Binding 6611 Update. 6613 Any Binding Acknowledgement not satisfying all of these tests MUST be 6614 silently ignored. 6616 When a mobile node receives a packet carrying a valid Binding 6617 Acknowledgement, the mobile node MUST examine the Status field as 6618 follows: 6620 - If the Status field indicates that the Binding Update was 6621 accepted (the Status field is less than 128), then the mobile 6622 node MUST update the corresponding entry in its Binding Update 6623 List to indicate that the Binding Update has been acknowledged; 6624 the mobile node MUST then stop retransmitting the Binding Update. 6625 In addition, if the value specified in the Lifetime field in the 6626 Binding Acknowledgement is less than the Lifetime value sent 6627 in the Binding Update being acknowledged, then the mobile node 6628 MUST subtract the difference between these two Lifetime values 6629 from the remaining lifetime for the binding as maintained in the 6630 corresponding Binding Update List entry (with a minimum value 6631 for the Binding Update List entry lifetime of 0). That is, if 6632 the Lifetime value sent in the Binding Update was L_update, the 6633 Lifetime value received in the Binding Acknowledgement was L_ack, 6634 and the current remaining lifetime of the Binding Update List 6635 entry is L_remain, then the new value for the remaining lifetime 6636 of the Binding Update List entry should be 6638 max((L_remain - (L_update - L_ack)), 0) 6640 where max(X, Y) is the maximum of X and Y. The effect of this 6641 step is to correctly manage the mobile node's view of the 6642 binding's remaining lifetime (as maintained in the corresponding 6643 Binding Update List entry) so that it correctly counts down from 6644 the Lifetime value given in the Binding Acknowledgement, but with 6645 the timer countdown beginning at the time that the Binding Update 6646 was sent. 6648 - If the Status field indicates that the Binding Update was 6649 rejected (the Status field is greater than or equal to 128), then 6650 the mobile node MUST delete the corresponding Binding Update List 6651 entry, and it MUST also stop retransmitting the Binding Update. 6652 Optionally, the mobile node MAY then take steps to correct the 6653 cause of the error and retransmit the Binding Update (with a new 6654 Sequence Number value), subject to the rate limiting restriction 6655 specified in Section 11.6.9. 6657 11.6.4. Receiving Binding Refresh Requests 6659 When a mobile node receives a packet containing a Binding Refresh 6660 Request message and there already exists a Binding Update List 6661 entry for the source of the Binding Refresh Request, it MAY start 6662 a return routability procedure (see Section 5) if it believes 6663 the amount of traffic with the correspondent justifies the use of 6664 Route Optimization. Note that the mobile node SHOULD NOT respond 6665 Binding Requests from previously unknown correspondent nodes due to 6666 Denial-of-Service concerns. 6668 If the return routability procedure completes successfully, a 6669 Binding Update message SHOULD be sent as described in Section 11.6.2. 6671 The Lifetime field in this Binding Update SHOULD be set to a new 6672 lifetime, extending any current lifetime remaining from a previous 6673 Binding Update sent to this node (as indicated in any existing 6674 Binding Update List entry for this node), and lifetime SHOULD 6675 again be less than or equal to the remaining lifetime of the home 6676 registration and the care-of address specified for the binding. When 6677 sending this Binding Update, the mobile node MUST update its Binding 6678 Update List in the same way as for any other Binding Update sent by 6679 the mobile node. 6681 Note, however, that the mobile node MAY choose to delete its binding 6682 from the sender of the Binding Refresh Request. In this case, the 6683 mobile node instead SHOULD return a Binding Update to the sender, in 6684 which the Lifetime field is set to zero and the care-of address is 6685 set to the mobile node's home address. 6687 If the Binding Refresh Request for which the Binding Update is being 6688 returned contains a Unique Identifier mobility option, the resulting 6689 Home Test Init, Care-of Test Init, and Update messages MUST also 6690 include a Unique Identifier mobility option. The unique identifier 6691 in the Option Data field of the Unique Identifier mobility option 6692 MUST be copied from the unique identifier carried in the Binding 6693 Refresh Request. 6695 11.6.5. Receiving Binding Error Messages 6697 When a mobile node receives a packet containing a Binding Error 6698 message, it should first check if the mobile node has a Binding 6699 Update List entry for the the source of the Binding Error message. 6700 If the mobile node does not have such entry, it MUST ignore the 6701 message. This is necessary to prevent a waste of resources on e.g. 6702 return routability procedure due to spoofed Binding Error messages. 6704 Otherwise, if the message Status field was 1 (Home Address 6705 destination option used without a binding), the mobile node should 6706 perform one of the following two actions: 6708 - If the mobile node does have a Binding Update List entry but 6709 has recent upper layer progress information that indicates 6710 communications with the correspondent node are progressing, it 6711 MAY ignore the message. This can be done in order to limit the 6712 damage that spoofed Binding Error messages can cause to ongoing 6713 communications. 6715 - If the mobile node does have a Binding Update List entry but 6716 no upper layer progress information, it MUST remove the entry 6717 and route further communications through the home agent. It 6718 MAY also optionally start a return routability procedure (see 6719 Section 5.5). 6721 If the message Status field was 2 (received message had an unknown 6722 value for the MH Type field), the mobile node should perform one of 6723 the following two actions: 6725 - If the mobile node is not expecting an acknowledgement or 6726 response from the correspondent node, the mobile node SHOULD 6727 ignore this message. 6729 - Otherwise, the mobile node SHOULD cease the use of any extensions 6730 to this specification. If no extensions had been used, the 6731 mobile node should cease the attempt to use Route Optimization. 6733 11.6.6. Forwarding from a Previous Care-of Address 6735 When a mobile node connects to a new link and forms a new care-of 6736 address, it MAY establish forwarding of packets from a previous 6737 care-of address to this new care-of address. To do so, the mobile 6738 node sends a Binding Update to any home agent on the link on which 6739 the previous care-of address is located, indicating this previous 6740 care-of address as the home address for the binding, and giving its 6741 new care-of address as the binding's care-of address. Such packet 6742 forwarding allows packets destined to the mobile node from nodes that 6743 have not yet learned the mobile node's new care-of address, to be 6744 forwarded to the mobile node rather than being lost once the mobile 6745 node is no longer reachable at this previous care-of address. 6747 This Binding Update is sent to a home agent, albeit a temporary 6748 one. Nevertheless, the authentication requirements for Binding 6749 Updates from a mobile node to its home agent apply, as specified in 6750 Section 11.6.1. This means that the mobile node MUST employ IPsec 6751 ESP as specified further below. 6753 In constructing this Binding Update, the mobile node utilizes the 6754 following specific steps: 6756 - The Home Address field in the Home Address destination option 6757 in the packet carrying the Binding Update MUST be set to the 6758 previous care-of address for which packet forwarding is being 6759 established. 6761 - The care-of address for the new binding MUST be set to the new 6762 care-of address to which packets destined to the previous care-of 6763 address are to be forwarded. Normally, this care-of address for 6764 the binding is specified by setting the Source Address of the 6765 packet carrying the Binding Update, to this address. However, 6766 the mobile node MAY instead include an Alternate Care-of Address 6767 mobility option in the Binding Update message, with its Alternate 6768 Care-of Address field set to the care-of address for the binding. 6770 - The Home Registration (H) bit MUST also be set in this Binding 6771 Update, to request this home agent to temporarily act as a home 6772 agent for this previous care-of address. 6774 This home agent will thus tunnel packets for the mobile node (packets 6775 destined to its specified previous care-of address) to its new 6776 care-of address. All of the procedures defined for home agent 6777 operation MUST be followed by this home agent for this registration. 6778 Note that this home agent does not necessarily know (and need not 6779 know) the mobile node's (permanent) home address as part of this 6780 registration. 6782 The packet carrying the Binding Update MUST be addressed to 6783 this home agent's global unicast address. Normally, this global 6784 unicast address is learned by the mobile node based on the Router 6785 Advertisements received by the mobile node (Section 7.2) while 6786 attached to the link on which this previous care-of address and this 6787 home agent are located; the mobile node obtains this home agent 6788 address from its Home Agents List (Section 4.4). Alternatively, 6789 the mobile node MAY use dynamic home agent address discovery 6790 (Section 10.9) to discover the global unicast address of a home agent 6791 on this previous link, but it SHOULD use an address from its Home 6792 Agents List if available for the prefix it used to form this previous 6793 care-of address. 6795 As with any packet containing a Binding Update (see Section 6.1.7), 6796 the Binding Update packet to this home agent MUST meet the 6797 authentication requirements for Binding Updates, defined in 6798 Section 5.4. Each Binding Update MUST be authenticated as coming 6799 from the right mobile node. This means that the mobile node and the 6800 home agent MUST have a security association that employs IPsec ESP 6801 for protecting the Mobility Header with a non-null authentication 6802 algorithm. The mobile node MUST use a Home Address destination 6803 option in Binding Updates sent to the home agent in order to allow 6804 the IPsec policies to be matched with the right home address. The 6805 home address in the Home Address destination option and the Binding 6806 Update message MUST be equal (and this will be checked by the home 6807 agent), that is, it MUST be the mobile node's previous care-of 6808 address for which forwarding is being established. 6810 11.6.7. Returning Home 6812 A mobile node detects that it has returned to its home link through 6813 the movement detection algorithm in use (Section 11.4.1), when the 6814 mobile node detects that its home subnet prefix is again on-link. 6815 The mobile node SHOULD then send a Binding Update to its home agent, 6816 to instruct its home agent to no longer intercept or tunnel packets 6817 for it. In this Binding Update, the mobile node MUST set the care-of 6818 address for the binding (the Source Address field in the packet's 6819 IPv6 header) to the mobile node's own home address. As with other 6820 Binding Updates sent to register with its home agent, the mobile 6821 node MUST set the Acknowledge (A) and Home Registration (H) bits, 6822 and SHOULD retransmit the Binding Update until a matching Binding 6823 Acknowledgement is received. 6825 When sending this Binding Update to its home agent, the mobile 6826 node must be careful in how it uses Neighbor Solicitation [20] (if 6827 needed) to learn the home agent's link-layer address, since the home 6828 agent will be currently configured to defend the mobile node's home 6829 address for Duplicate Address Detection. In particular, a Neighbor 6830 Solicitation from the mobile node using its home address as the 6831 Source Address would be detected by the home agent as a duplicate 6832 address. In many cases, Neighbor Solicitation by the mobile node 6833 for the home agent's address will not be necessary, since the mobile 6834 node may have already learned the home agent's link-layer address, 6835 for example from a Source Link-Layer Address option in the Router 6836 Advertisement from which it learned that its home address was on-link 6837 and that the mobile node had thus returned home. If the mobile node 6838 does Neighbor Solicitation to learn the home agent's link-layer 6839 address, in this special case of the mobile node returning home, the 6840 mobile node MUST unicast the packet, and in addition set the Source 6841 Address of this Neighbor Solicitation to the unspecified address 6842 (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home 6843 agent will be able to distinguish from a similar packet that would 6844 only be used for DAD. The home agent will send a multicast Neighbor 6845 Advertisement back to the mobile node with the Solicited flag ('S') 6846 set to zero. The mobile node SHOULD accept this advertisement, and 6847 set the state of the Neighbor Cache entry for the home agent to 6848 REACHABLE. 6850 The mobile node then sends its Binding Update using the home agent's 6851 link-layer address, instructing its home agent to no longer serve 6852 as a home agent for it. By processing this Binding Update, the 6853 home agent will cease defending the mobile node's home address for 6854 Duplicate Address Detection and will no longer respond to Neighbor 6855 Solicitations for the mobile node's home address. The mobile node 6856 is then the only node on the link receiving packets at the mobile 6857 node's home address. In addition, when returning home prior to the 6858 expiration of a current binding for its home address, and configuring 6859 its home address on its network interface on its home link, the 6860 mobile node MUST NOT perform Duplicate Address Detection on its own 6861 home address, in order to avoid confusion or conflict with its home 6862 agent's use of the same address. If the mobile node returns home 6863 after the bindings for all of its care-of addresses have expired, 6864 then it SHOULD perform DAD. 6866 After the Mobile Node sends the Binding Update, the Home Agent MUST 6867 remove the Proxy Neighbor Cache entry for the Mobile Node and MAY 6868 learn its link-layer address based on the link-layer packet or cached 6869 information, or if that is not available, it SHOULD send a Neighbor 6870 Solicitation with the target address equal to the Binding Update's 6871 source IP address. The Mobile Node MUST then reply with a unicast 6872 Neighbor Advertisement to the Home Agent with its link-layer address. 6873 While the Mobile Node is waiting for a Binding Acknowledgement, it 6874 MUST NOT respond to any Neighbor Solicitations for its Home Address 6875 other than those originating from the IP address to which it sent the 6876 Binding Update. 6878 After receiving the Binding Acknowledgement for its Binding Update 6879 to its home agent, the mobile node MUST multicast onto the home 6880 link (to the all-nodes multicast address) a Neighbor Advertisement 6881 message [20], to advertise the mobile node's own link-layer address 6882 for its own home address. The Target Address in this Neighbor 6883 Advertisement message MUST be set to the mobile node's home address, 6884 and the Advertisement MUST include a Target Link-layer Address option 6885 specifying the mobile node's link-layer address. The mobile node 6886 MUST multicast such a Neighbor Advertisement message for each of its 6887 home addresses, as defined by the current on-link prefixes, including 6888 its link-local address and site-local address. The Solicited 6889 Flag (S) in these Advertisements MUST NOT be set, since they were 6890 not solicited by any Neighbor Solicitation message. The Override 6891 Flag (O) in these Advertisements MUST be set, indicating that the 6892 Advertisements SHOULD override any existing Neighbor Cache entries at 6893 any node receiving them. 6895 Since multicasting on the local link (such as Ethernet) is typically 6896 not guaranteed to be reliable, the mobile node MAY retransmit these 6897 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 6898 increase their reliability. It is still possible that some nodes on 6899 the home link will not receive any of these Neighbor Advertisements, 6900 but these nodes will eventually be able to recover through use of 6901 Neighbor Unreachability Detection [20]. 6903 11.6.8. Retransmitting Binding Updates 6905 The mobile node is responsible for retransmissions in the binding 6906 procedure. 6908 When the mobile node sends a Binding Update message, it has to 6909 determine a value for the initial retransmission timer. If the 6910 mobile node is changing or updating an existing binding at the home 6911 agent, it should use the specified value of INITIAL_BINDACK_TIMEOUT 6912 for this initial retransmission timer. If on the other hand the 6913 mobile node does not have an existing binding at the home agent, it 6914 SHOULD use a value for the initial retransmission timer that is at 6915 least 1.5 times longer than (RetransTimer * DupAddrDetectTransmits). 6916 This value is likely to be substantially longer than the otherwise 6917 specified value of INITIAL_BINDACK_TIMEOUT that would be used by the 6918 mobile node. This longer retransmission interval will allow the the 6919 home agent to complete the DAD procedure which is mandated in this 6920 case, as detailed in Section 11.6.1. 6922 If, after sending a Binding Update in which the care-of address has 6923 changed and the Acknowledge (A) bit is set, a mobile node fails 6924 to receive a valid, matching Binding Acknowledgement within the 6925 selected initial retransmission interval, the mobile node SHOULD 6926 retransmit the Binding Update, until a Binding Acknowledgement is 6927 received. Such a retransmitted Binding Update MUST use a Sequence 6928 Number value greater than that used for the previous transmission of 6929 this Binding Update. The retransmissions by the mobile node MUST 6930 use an exponential back-off process, in which the timeout period 6931 is doubled upon each retransmission until either the node receives 6932 a Binding Acknowledgement or the timeout period reaches the value 6933 MAX_BINDACK_TIMEOUT. 6935 11.6.9. Rate Limiting Binding Updates 6937 A mobile node MUST NOT send Binding Update messages for the 6938 same binding to any individual node more often than once per 6939 MAX_UPDATE_RATE seconds. After sending MAX_FAST_UPDATES consecutive 6940 messages to a particular node with the same care-of address, the 6941 mobile node SHOULD reduce its rate of sending these messages to that 6942 node, to the rate of SLOW_UPDATE_RATE per second. The mobile node 6943 MAY continue to send these messages at this slower rate indefinitely, 6944 in hopes that the node will eventually be able to process a Binding 6945 Update, and begin to route its packets directly to the mobile node at 6946 its new care-of address. 6948 11.7. Receiving ICMP Error Messages 6950 Any node receiving a Mobility header that does not recognize the 6951 protocol SHOULD return an ICMP Parameter Problem, Code 1, message 6952 to the sender of the packet. If a node performing the return 6953 routability procedure or sending a Binding Update receives such an 6954 ICMP error message in response, it SHOULD record in its Binding 6955 Update List that future Binding Updates SHOULD NOT be sent to this 6956 destination. 6958 Correspondent nodes who have participated in the return routability 6959 procedure MUST implement the ability to correctly process received 6960 packets containing a Home Address option. Therefore, correctly 6961 implemented correspondent nodes should always be able to recognize 6962 Home Address options. If a mobile node receives an ICMP Parameter 6963 Problem, Code 2, message from some node indicating the that the Home 6964 Address option, the mobile node SHOULD log the error and then discard 6965 the ICMP message. 6967 12. Protocol Constants 6969 HomeRtrAdvInterval 3,600 seconds 6970 DHAAD_RETRIES 3 retransmissions 6971 INITIAL_BINDACK_TIMEOUT 1 second 6972 INITIAL_DHAAD_TIMEOUT 2 seconds 6973 INITIAL_SOLICIT_TIMER 2 seconds 6974 MAX_ADVERT_REXMIT 3 transmissions 6975 MAX_BINDACK_TIMEOUT 256 seconds 6976 MAX_COOKIE_LIFE 240 seconds 6977 MAX_FAST_UPDATES 5 transmissions 6978 MAX_PFX_ADV_DELAY 1,000 seconds 6979 MAX_RR_BINDING_LIFE 300 seconds 6980 MAX_UPDATE_RATE once per second 6981 PREFIX_ADV_RETRIES 3 retransmissions 6982 PREFIX_ADV_TIMEOUT 5 seconds 6983 SLOW_UPDATE_RATE once per 10 second interval 6985 13. IANA Considerations 6987 This document defines a new IPv6 protocol, the Mobility Header, 6988 described in Section 6.1. This protocol must be assigned a protocol 6989 number. The MH Type field in the Mobility Header is used to indicate 6990 a particular type of a message. The current message types are 6991 described in Sections 6.1.2 through 6.1.9, and include the following: 6993 0 Binding Refresh Request 6995 1 Home Test Init 6997 2 Care-of Test Init 6999 3 Home Test 7001 4 Care-of Test 7003 5 Binding Update 7005 6 Binding Acknowledgement 7007 7 Binding Error 7009 Future values of the MH Type can be allocated using standards 7010 action [19]. 7012 Furthermore, each Mobility Header message may contain mobility 7013 options as described in Section 6.2. The current mobility options 7014 are defined in Sections 6.2.2 through 6.2.5, and include the 7015 following: 7017 0 Pad1 7019 1 PadN 7021 2 Unique Identifier 7023 3 Alternate Care-of Address 7025 4 Nonce Indices 7027 5 Authorization Data 7029 Future values of the Option Type can be allocated using standards 7030 action [19]. 7032 This document also defines a new IPv6 destination option, the Home 7033 Address option, described in Section 6.3. This option must be 7034 assigned an Option Type value. 7036 This document also defines a new IPv6 Type 2 Routing Header, 7037 described in Section 6.4. The value 2 must be allocated by IANA when 7038 this specification becomes an RFC. 7040 In addition, this document defines four ICMP message types, two used 7041 as part of the dynamic home agent address discovery mechanism and 7042 two used in lieu of router solicitations and advertisements when the 7043 mobile node is away from the home link: 7045 - The Home Agent Address Discovery Request message, described in 7046 Section 6.5; 7048 - The Home Agent Address Discovery Reply message, described in 7049 Section 6.6; 7051 - The Mobile Prefix Solicitation message, described in Section 6.7; 7052 and 7054 - The Mobile Prefix Advertisement message, described in 7055 Section 6.8. 7057 This document also defines two new Neighbor Discovery [20] options, 7058 which must be assigned Option Type values within the option numbering 7059 space for Neighbor Discovery messages: 7061 - The Advertisement Interval option, described in Section 7.3; and 7063 - The Home Agent Information option, described in Section 7.4. 7065 14. Security Considerations 7067 14.1. Security for the Tunneling to and from the Home Agent 7069 Binding updates to the home agents are secure. When receiving 7070 tunneled traffic the home agent verifies the outer IP address 7071 corresponds to the current location of the mobile node. This 7072 prevents attacks where the attacker is controlled by ingress 7073 filtering, as well as attacks where the attacker does not know the 7074 current care-of address of the mobile node. Attackers who know the 7075 care-of address and are not controlled by ingress filtering could 7076 still send traffic through the home agent. This includes attackers 7077 on the same local link as the mobile node is currently on. But such 7078 attackers could also send spoofed packets without using a tunnel. 7080 It is possible to use IPsec ESP to protect payload packets tunneled 7081 to the mobile node and back. While this specification does not 7082 mandate the use of ESP, its use is recommended to protect the payload 7083 communications against attackers on the path between the home agent 7084 and the current location of the mobile node. 7086 When site local home address are used, reverse tunneling can be used 7087 to send site local traffic from another location. Administrators 7088 should be aware of this when allowing such home addresses. In 7089 particular, the outer IP address check described above is not 7090 sufficient against all attackers and the use of encrypted tunnels is 7091 particularly useful for this kind of home addresses. 7093 14.2. Security for the Binding Updates to the Home Agent 7095 The use of IPsec ESP to protect Mobility Header messages between 7096 the mobile node and the home agent protects the integrity of the 7097 Binding Updates and Binding Acknowledgements. Sequence numbers with 7098 the Mobile IPv6 messages ensure correct ordering (see Section 5.4). 7099 However, if a home agent reboots and loses its state regarding the 7100 sequence numbers, replay attacks become possible. If the home agent 7101 is vulnerable to this, the use of a key management mechanism together 7102 with IPsec can be used to prevent replay attacks. 7104 14.3. Security for the Binding Updates to the Correspondent Nodes 7106 The use of home address and care-of-address based return routability 7107 tests prevents any off-path attacks beyond those that are already 7108 possible in basic IPv6 [23]. 7110 Protection against attackers on the home agent link and the 7111 correspondent node link, as well as on the path between, are 7112 roughly similar to the situation in existing IPv6 as well. However, 7113 one difference is that in basic IPv6 an on-path attacker must be 7114 constantly present on the link or the path (e.g., in order to perform 7115 a man-in-the-middle attack), whereas with Mobile IPv6 an attacker 7116 can leave an existing binding behind, even after it is no longer on 7117 the link or on the path [23]. For this reason, this specification 7118 limits the validity of bindings authorized by return routability to 7119 a maximum of MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE seconds after the 7120 last routability check has been performed. 7122 The path between the home agent and a correspondent node is typically 7123 easiest to attack on the links at either end, in particular if these 7124 links are publicly accessible wireless LANs. Attacks against the 7125 routers or switches on the path are typically harder to accomplish. 7126 Thus, the weakest points are typically on the links at either end, 7127 and their mechanisms for layer 2 security or IPv6 Neighbour and 7128 Router Discovery. If these were secured using some new technology in 7129 the future, this could make the key establishment mechanism specified 7130 in this document to be an easier route for attackers to use. For 7131 this reason, this specification should have a protection mechanism 7132 for selecting between return routability and potential other future 7133 mechanisms. 7135 14.4. Security for the Home Address Destination Option 7137 The use of the Home Address destination option allows packets sent by 7138 a mobile node to pass normally through routers implementing ingress 7139 filtering [7]. Since the care-of address used in the Source Address 7140 field of the packet's IPv6 header is topologically correct for the 7141 sending location of the mobile node, ingress filtering can trace the 7142 location of the mobile node in the same way as can be done with any 7143 sender when ingress filtering is in use. As this location does not 7144 survive in replies sent by the correspondent node, this document 7145 restricts the use of the Home Address option to those situations 7146 where a binding has been established with the participation of the 7147 node at the home address. This prevents reflection attacks through 7148 the use of the Home Address option. 7150 No special authentication of the Home Address option is required 7151 beyond the above, except that if the IPv6 header of a packet is 7152 covered by authentication, then that authentication MUST also cover 7153 the Home Address option; this coverage is achieved automatically by 7154 the definition of the Option Type code for the Home Address option 7155 (Section 6.3), since it indicates that the option is included in the 7156 authentication computation. Thus, even when authentication is used 7157 in the IPv6 header, the security of the Source Address field in the 7158 IPv6 header is not compromised by the presence of a Home Address 7159 option. Without authentication of the packet, then any field in the 7160 IPv6 header, including the Source Address field, and any other parts 7161 of the packet, including the Home Address option, can be forged or 7162 modified in transit. In this case, the contents of the Home Address 7163 option is no more suspect than any other part of the packet. 7165 14.5. Firewall considerations 7167 The definition of Routing Header 2 in Section 6.4 and the associated 7168 processing rules have been chosen so that the header can not be used 7169 for what is traditionally viewed as source routing. In particular, 7170 the IPv6 destination and the Home Address in the routing header will 7171 always have to be assigned to the same node otherwise the packet will 7172 be dropped. 7174 This means that the typical security concerns for source routing 7175 including the automatic reversal of unauthenticated source routes 7176 (which is an issue for IPv4 but not for IPv6 source routing) and the 7177 ability to use source routing to "jump" between nodes inside, as well 7178 as outside a firewall, are not at play. 7180 In essence the semantics of the type 2 routing header is the same as 7181 a special form of IP-in-IP tunneling where the inner and outer source 7182 addresses are the same. 7184 This implies that a device which implements filtering of packets 7185 should be able to distinguish between a Type 2 Routing header and 7186 other Routing headers, as required in section 8.2. This is necessary 7187 in order to allow Mobile IPv6 traffic while still having the option 7188 to filter out other uses of Routing headers. 7190 Acknowledgements 7192 We would like to thank the members of the Mobile IP and IPng Working 7193 Groups for their comments and suggestions on this work. We would 7194 particularly like to thank (in alphabetical order) Fred Baker 7195 (Cisco), Josh Broch (Carnegie Mellon University), Robert Chalmers 7196 (University of California, Santa Barbara), Noel Chiappa (MIT), 7197 Vijay Devarapalli (Nokia Research Center), Rich Draves (Microsoft 7198 Research), Francis Dupont (ENST Bretagne), Thomas Eklund (Xelerated), 7199 Jun-Ichiro Itojun Hagino (IIJ Research Laboratory), Krishna Kumar 7200 (IBM Research), T.J. Kniveton (Nokia Research), Jiwoong Lee (KTF), 7201 Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), Erik Nordmark (Sun 7202 Microsystems), Simon Nybroe (Ericsson Telebit), David Oran (Cisco), 7203 Lars Henrik Petander (HUT), Basavaraj Patil (Nokia), Ken Powell 7204 (Compaq), Phil Roberts (Motorola), Patrice Romand (Bull S.A.), 7205 Jeff Schiller (MIT) Tom Soderlund (Nokia Research), Hesham Soliman 7206 (Ericsson), Jim Solomon (RedBack Networks), Tapio Suihko (Technical 7207 Research Center of Finland), Benny Van Houdt (University of Antwerp), 7208 Jon-Olov Vatn (KTH), Alper Yegin (Sun Microsystems), and Xinhua Zhao 7209 (Stanford University) for their detailed reviews of earlier versions 7210 of this document. Their suggestions have helped to improve both the 7211 design and presentation of the protocol. 7213 We would also like to thank the participants in the Mobile IPv6 7214 testing event held at Nancy, France, September 15-17, 1999, for 7215 their valuable feedback as a result of interoperability testing 7216 of four Mobile IPv6 implementations coming from four different 7217 organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC 7218 (FreeBSD), and INRIA (FreeBSD). Further, we would like to thank the 7219 feedback from the implementors who participated in the Mobile IPv6 7220 interoperability testing at Connectathons 2000, 2001, and 2002 7221 in San Jose, California. Similarly, we would like to thank the 7222 participants at the ETSI interoperability testing at ETSI, in Sophia 7223 Antipolis, France, during October 2-6, 2000, including teams from 7224 Compaq, Ericsson, INRIA, Nokia, and Technical University of Helsinki. 7226 Lastly, we must express our appreciation for the significant 7227 contributions made by members of the Mobile IPv6 Security Design 7228 Team, including (in alphabetical order) Gabriel Montenegro, Erik 7229 Nordmark, and Pekka Nikander, who have contributed volumes of text to 7230 this specification. 7232 References 7234 [1] Tuomas Aura and Jari Arkko. MIPv6 BU Attacks and Defenses. 7235 Internet Draft draft-aura-mipv6-bu-attacks-01.txt (Work In 7236 Progress), IETF, February 2002. 7238 [2] J. Bound, C. Perkins, M. Carney, and R. Droms. Dynamic Host 7239 Configuration Protocol for IPv6 (DHCPv6) (work in progress). 7240 Internet Draft, Internet Engineering Task Force, January 2001. 7242 [3] S. Bradner. Key words for use in RFCs to Indicate Requirement 7243 Levels. Request for Comments (Best Current Practice) 2119, 7244 Internet Engineering Task Force, March 1997. 7246 [4] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 7247 Specification. Request for Comments (Proposed Standard) 2473, 7248 Internet Engineering Task Force, December 1998. 7250 [5] A. Conta and S. Deering. Internet Control Message Protocol 7251 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 7252 Specification. Request for Comments (Draft Standard) 2463, 7253 Internet Engineering Task Force, December 1998. 7255 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 7256 Specification. Request for Comments (Draft Standard) 2460, 7257 Internet Engineering Task Force, December 1998. 7259 [7] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating 7260 Denial of Service Attacks which employ IP Source Address 7261 Spoofing. Request for Comments (Informational) 2267, Internet 7262 Engineering Task Force, January 1998. 7264 [8] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). 7265 Request for Comments (Proposed Standard) 2409, Internet 7266 Engineering Task Force, November 1998. 7268 [9] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 7269 Request for Comments (Proposed Standard) 2373, Internet 7270 Engineering Task Force, July 1998. 7272 [10] Editor J. Reynolds. Assigned Numbers: RFC 1700 is Replaced by 7273 an On-line Database. Request for Comments (Informational) 3232, 7274 Internet Engineering Task Force, January 2002. 7276 [11] D. Johnson and S. Deering. Reserved IPv6 Subnet Anycast 7277 Addresses. Request for Comments (Proposed Standard) 2526, 7278 Internet Engineering Task Force, March 1999. 7280 [12] S. Kent and R. Atkinson. IP Authentication Header. Request for 7281 Comments (Proposed Standard) 2402, Internet Engineering Task 7282 Force, November 1998. 7284 [13] S. Kent and R. Atkinson. IP Encapsulating Security Payload 7285 (ESP). Request for Comments (Proposed Standard) 2406, Internet 7286 Engineering Task Force, November 1998. 7288 [14] S. Kent and R. Atkinson. Security Architecture for the Internet 7289 Protocol. Request for Comments (Proposed Standard) 2401, 7290 Internet Engineering Task Force, November 1998. 7292 [15] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 7293 for Message Authentication. Request for Comments 7294 (Informational) 2104, Internet Engineering Task Force, 7295 February 1997. 7297 [16] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet 7298 Security Association and Key Management Protocol (ISAKMP). 7299 Request for Comments (Proposed Standard) 2408, Internet 7300 Engineering Task Force, November 1998. 7302 [17] P. V. Mockapetris. Domain names - concepts and facilities. 7303 Request for Comments (Standard) 1034, Internet Engineering Task 7304 Force, November 1987. 7306 [18] P. V. Mockapetris. Domain names - implementation and 7307 specification. Request for Comments (Standard) 1035, Internet 7308 Engineering Task Force, November 1987. 7310 [19] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 7311 Considerations Section in RFCs. Request for Comments (Best 7312 Current Practice) 2434, Internet Engineering Task Force, October 7313 1998. 7315 [20] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 7316 IP Version 6 (IPv6). Request for Comments (Draft Standard) 7317 2461, Internet Engineering Task Force, December 1998. 7319 [21] NIST. Secure Hash Standard. FIPS PUB 180-1, April 1995. 7321 [22] Erik Nordmark. Securing MIPv6 BUs using return routability 7322 (BU3WAY). Internet Draft draft-nordmark-mobileip-bu3way-00.txt 7323 (Work In Progress), IETF, November 2001. 7325 [23] Erik Nordmark, Gabriel Montenegro, Pekka Nikander, and Jari 7326 Arkko. Mobile IPv6 Security Design Rationale. To appear, 2002. 7328 [24] C. Perkins. IP Encapsulation within IP. Request for Comments 7329 (Proposed Standard) 2003, Internet Engineering Task Force, 7330 October 1996. 7332 [25] C. Perkins. IP Mobility Support. Request for Comments 7333 (Proposed Standard) 2002, Internet Engineering Task Force, 7334 October 1996. 7336 [26] C. Perkins. Minimal Encapsulation within IP. Request for 7337 Comments (Proposed Standard) 2004, Internet Engineering Task 7338 Force, October 1996. 7340 [27] C. Perkins and D. Johnson. Route Optimization in Mobile IP 7341 (work in progress). Internet Draft, Internet Engineering Task 7342 Force. 7343 draft-ietf-mobileip-optim-11.txt, September 2001. 7345 [28] D. Piper. The Internet IP Security Domain of Interpretation for 7346 ISAKMP. Request for Comments (Proposed Standard) 2407, Internet 7347 Engineering Task Force, November 1998. 7349 [29] D. C. Plummer. Ethernet Address Resolution Protocol: Or 7350 converting network protocol addresses to 48.bit Ethernet address 7351 for transmission on Ethernet hardware. Request for Comments 7352 (Standard) 826, Internet Engineering Task Force, November 1982. 7354 [30] J. Reynolds and J. Postel. Assigned Numbers. Request for 7355 Comments (Standard) 1700, Internet Engineering Task Force, 7356 October 1994. 7358 [31] Michael Roe, Greg O'Shea, Tuomas Aura, and Jari Arkko. 7359 Authentication of Mobile IPv6 Binding Updates and 7360 Acknowledgments. Internet Draft draft-roe-mobileip-updateauth-02.txt 7361 (Work In Progress), IETF, February 2002. 7363 [32] Pekka Savola. Security of IPv6 Routing Header and Home Address 7364 Options. Internet Draft draft-savola-ipv6-rh-ha-security-01.txt 7365 (Work In Progress), IETF, November 2001. 7367 [33] S. Thomson and T. Narten. IPv6 Stateless Address 7368 Autoconfiguration. Request for Comments (Draft Standard) 2462, 7369 Internet Engineering Task Force, December 1998. 7371 A. State Machine for the Correspondent Binding Procedure 7373 Home agents and correspondent nodes are stateless until a binding is 7374 actually established. 7376 The mobile node, however, is responsible for initiating the 7377 correspondent binding procedure, keeping track of its state, handle 7378 retransmissions and failures, and completing the procedure. 7380 Section 11.6.2 defines the normative rules that the mobile node 7381 must follow when performing the correspondent procedure. This 7382 appendix specifies an additional, non-normative, state-machine that 7383 illustrates the behaviour of the mobile node. 7385 The mobile node will keep the following states in its Binding List: 7387 - Idle: This is an abstract state that refers to the situation 7388 that the correspondent node in question does not appear in 7389 the Binding List. In this state, all RR and binding related 7390 messaging is silently ignored. 7392 - WaitHC: In this state, the mobile node has sent the Home Test 7393 Init and CoT Init messages, and is waiting for the Home Test and 7394 CoT messages to come back. It will also be necessary to keep 7395 state of retransmissions for both. 7397 - WaitH: In this state, the mobile node has a recent Care-of Cookie 7398 and is only waiting for the Home Test message to arrive. 7400 - WaitC: In this state, the mobile node has a recent Home Cookie 7401 and is only waiting for the CoT message to arrive. 7403 - WaitA: In this state, the mobile node has sent a Binding Update, 7404 and is only waiting for the Binding Acknowledgement message to 7405 arrive. 7407 - WaitD: In this state, the mobile node has sent a de-registration 7408 Binding Update, and is only waiting for the Binding 7409 Acknowledgement message to arrive. 7411 - WaitDH: In this state, the mobile node intends to send a 7412 de-registration Binding Update later but is first waiting for a 7413 home cookie before this can be done. Note that if the mobile 7414 node is at home, it can use a home cookie also as care-of cookie. 7416 - Bound: In this state, the mobile node has established a binding 7417 with the correspondent node. 7419 The following events are possible: 7421 - Route Optimization desired. This is a decision taken by 7422 the mobile node based on observing traffic to and from the 7423 correspondent node. 7425 - Route Optimization not needed. This is another decision taken by 7426 the mobile node, perhaps due to running out of resources or lack 7427 of sufficient traffic to justify route optimization with this 7428 particular correspondent node. Another reason for not needing 7429 Route Optimization any more is that the mobile node has returned 7430 home. 7432 - Movement. 7434 - Valid BRR received. A valid Binding Refresh Request message has 7435 been received. 7437 - Valid HoT received. A valid Home Test message has been received. 7439 - Valid CoT received. A valid Care-of Test message has been 7440 received. 7442 - Valid BA received. A valid Binding Acknowledgement message has 7443 been received. 7445 - Valid BE received. A valid Binding Error message has been 7446 received. 7448 - ICMP Parameter Problem Code 1 received. This can happen if the 7449 peer does not support this specification. 7451 - Invalid BRR received. 7453 - Invalid HoT received. 7455 - Invalid CoT received. 7457 - Invalid BA received. 7459 - Invalid BE received. 7461 - Retransmission needed. A timer is set to expire when a 7462 retransmission of a packet needs to be made. 7464 - Retransmission failed. A timer is set to expire when all 7465 retransmissions have failed. 7467 The following additional conditions are also used: 7469 - Acknowledgements are required. This is a local configuration on 7470 the mobile node side, and indicates whether acknowledgements are 7471 required to binding updates. 7473 - Home cookie too old. A cookie is too old if it has been received 7474 MIN_COOKIE_LIFE or over seconds ago. 7476 - Care-of cookie too old. 7478 - Reason to believe forward progress is being made. Upper layer 7479 protocols such as TCP may provide hints to the IP layer regarding 7480 the successfullness of the recent communications. 7482 - Tests of the Status values received in a BE or BA message. 7484 - Binding lifetime left. The remaining lifetime field of a Binding 7485 Update List entry tells whether the binding currently registered 7486 at the correspondent node still has some lifetime left, even if 7487 we are trying to create a new one. This has relevance when an 7488 attempt at re-binding is aborted for some reason. 7490 The state machine for the mobile node is as follows: 7492 State Event Action New State 7493 -------------------------------------------------------------- 7495 Idle Route Optimization desired Send HoTI, WaitHC 7496 Send CoTI, 7497 Start retrans- 7498 mission and 7499 failure timers 7501 Idle Valid HoT received (None) Idle 7503 Idle Valid CoT received (None) Idle 7505 Idle Valid BA received (None) Idle 7507 Idle Valid BRR received (None) Idle 7509 Idle ICMP Parameter Problem Code 1 (None) Idle 7510 received 7512 Idle Valid BE received and (None) Idle 7513 status = 1 7515 Idle Valid BE received and (None) Idle 7516 status = 2 7518 Idle Movement (None) Idle 7520 State Event Action New State 7521 -------------------------------------------------------------- 7522 WaitHC Valid HoT received Store cookie WaitC 7523 and nonce 7524 index 7526 WaitHC Valid CoT received Store cookie WaitH 7527 and nonce 7528 index 7530 WaitHC Valid BA received (None) WaitHC 7532 WaitHC Valid BRR received (None) WaitHC 7534 WaitHC Retransmission needed Send HoTI, WaitHC 7535 Send CoTI, 7536 Start timer 7537 TRetr 7539 WaitHC Valid BE received and (None) WaitHC 7540 status = 1 7542 WaitHC Valid BE received and Stop timers Idle 7543 status = 2 7545 WaitHC Movement Send CoTI, WaitHC 7546 Restart 7547 retransmission 7548 and failure 7549 timers 7551 WaitHC Route Optimization not needed (None) WaitHC 7553 WaitHC ICMP Parameter Problem Code 1 Stop timers Idle 7554 received 7556 State Event Action New State 7557 -------------------------------------------------------------- 7559 WaitH Valid HoT received and Store cookie WaitA 7560 acknowledgements required and nonce 7561 index, 7562 Send BU, 7563 Start retrans- 7564 mission timer 7566 WaitH Valid HoT received and Store cookie Bound 7567 acknowledgements not required and nonce 7568 index, 7569 Send BU, 7570 Stop timers 7572 WaitH Valid CoT received (None) WaitH 7573 WaitH Valid BA received (None) WaitH 7575 WaitH Valid BRR received (None) WaitH 7577 WaitH Retransmission needed Send HoTI, WaitH 7578 Start retrans- 7579 mission timer 7581 WaitH Valid BE received and (None) WaitH 7582 status = 1 7584 WaitH Valid BE received and Stop timers Idle 7585 status = 2 7587 WaitH Movement Send CoTI, WaitH 7588 Restart 7589 retransmission 7590 and failure 7591 timers 7593 WaitH Route Optimization not needed (None) WaitH 7595 WaitH ICMP Parameter Problem Code 1 (None) WaitH 7596 received 7598 State Event Action New State 7599 -------------------------------------------------------------- 7601 WaitC Valid CoT received and Store cookie WaitA 7602 acknowledgements required and nonce 7603 index, 7604 Send BU, 7605 Start retrans- 7606 mission timers 7608 WaitC Valid CoT received Store cookie Bound 7609 and acknowledgements not and nonce 7610 required index, 7611 Send BU, 7612 Stop timers 7614 WaitC Valid HoT received (None) WaitC 7616 WaitC Valid BA received (None) WaitC 7618 WaitC Valid BRR received (None) WaitC 7620 WaitC Valid BE received and (None) WaitC 7621 status = 1 7623 WaitC Valid BE received and Stop timers Idle 7624 status = 2 7626 WaitC Retransmission needed Send CoTI, WaitC 7627 Start retrans- 7628 mission timer 7630 WaitC Movement Send CoTI, WaitC 7631 Restart 7632 retransmission 7633 and failure 7634 timers 7636 WaitC Route Optimization not needed (None) WaitC 7638 WaitC ICMP Parameter Problem Code 1 (None) WaitC 7639 received 7641 State Event Action New State 7642 -------------------------------------------------------------- 7644 WaitA Valid BA received and Stop timers Bound 7645 status < 128 7647 WaitA Valid BA received and Set sequence#, WaitA 7648 status = 141 Send BU, 7649 Restart 7650 retransmission 7651 and failure 7652 timers 7654 WaitA Valid BA received and Send HoTI, WaitHC 7655 status = 144 or 145 Send CoTI, 7656 Restart 7657 retransmission 7658 and failure 7659 timers 7661 WaitA Valid BA received and Stop timers Idle 7662 status anything else 7664 WaitA Valid HoT received (None) WaitA 7666 WaitA Valid CoT received (None) WaitA 7668 WaitA Valid BRR received (None) WaitA 7670 WaitA Retransmission needed Send BU, WaitA 7671 Start retrans- 7672 mission timer 7674 WaitA Valid BE received and (None) WaitA 7675 status = 1 7677 WaitA Valid BE received and Stop timers Idle 7678 status = 2 7680 WaitA Movement Send CoTI, WaitC 7681 Restart 7682 retransmission 7683 and failure 7684 timers 7686 WaitA Route Optimization not needed (None) WaitA 7688 WaitA ICMP Parameter Problem Code 1 (None) WaitA 7689 received 7691 State Event Action New State 7692 -------------------------------------------------------------- 7694 WaitD Valid BA received and Stop timers Idle 7695 status < 128 7697 WaitD Valid BA received and Set sequence#, WaitD 7698 status = 141 Send BU, 7699 Restart 7700 retransmission 7701 and failure 7702 timers 7704 WaitD Valid BA received and Send HoTI, WaitDH 7705 status = 144 or 145 Restart 7706 retransmission 7707 and failure 7708 timers 7710 WaitD Valid BA received and Stop timers Idle 7711 status anything else 7713 WaitD Valid HoT received (None) WaitD 7715 WaitD Valid CoT received (None) WaitD 7717 WaitD Valid BRR received (None) WaitD 7719 WaitD Retransmission needed Send BU, WaitD 7720 Start retrans- 7721 mission timer 7723 WaitD Valid BE received Stop timers Idle 7724 WaitD Movement (None) WaitD 7726 WaitD Route Optimization Desired Send HoTI, WaitHC 7727 Send CoTI, 7728 Restart 7729 retransmission 7730 and failure 7731 timers 7733 WaitD ICMP Parameter Problem Code 1 (None) WaitD 7734 received 7736 State Event Action New State 7737 -------------------------------------------------------------- 7739 WaitDH Valid HoT received and Send BU, WaitD 7740 acknowledgements required Restart 7741 retransmission 7742 and failure 7743 timers 7745 WaitDH Valid HoT received and Send BU, Idle 7746 acknowledgements not Stop timers 7747 required 7749 WaitDH Valid CoT received (None) WaitDH 7751 WaitDH Valid BA received (None) WaitDH 7753 WaitDH Valid BRR received (None) WaitDH 7755 WaitDH Retransmission needed Send HoTI, WaitDH 7756 Start retrans- 7757 mission timer 7759 WaitDH Valid BE received Stop timers Idle 7761 WaitDH Movement (none) WaitDH 7763 WaitDH Route Optimization Desired Send HoTI, WaitHC 7764 Send CoTI, 7765 Restart 7766 retransmission 7767 and failure 7768 timers 7770 WaitDH ICMP Parameter Problem Code 1 (None) WaitDH 7771 received 7773 State Event Action New State 7774 -------------------------------------------------------------- 7775 Bound Valid BRR received Send HoTI, WaitHC 7776 Send CoTI, 7777 Start retrans- 7778 mission timers 7780 Bound Valid HoT received (None) Bound 7782 Bound Valid CoT received (None) Bound 7784 Bound Valid BA received (None) Bound 7786 Bound Route Optimization not Send BU Idle 7787 needed and home cookie not 7788 too old and acknowledgements 7789 not required 7791 Bound Route Optimization not Send BU, WaitD 7792 needed and home cookie not Start retrans- 7793 too old and acknowledgements mission and 7794 required failure timers 7796 Bound Route Optimization not Send HoTI, WaitDH 7797 needed and home cookie too Start retrans- 7798 old mission and 7799 failure timers 7801 Bound ICMP Parameter Problem Code 1 (None) Bound 7802 received 7804 Bound Movement and home cookie Send CoTI, WaitC 7805 not too old Start retrans- 7806 mission and 7807 failure timers 7809 Bound Movement and home cookie Send HoTI, WaitHC 7810 too old Send CoTI, 7811 Start retrans- 7812 mission and 7813 failure timers 7815 Bound Valid BE received and (None) Bound 7816 status = 1 and reason to 7817 believe forward progress 7818 is being made 7820 Bound Valid BE received and Send HoTI, WaitHC 7821 status = 1 and no reason to Send CoTI, 7822 believe forward progress Start retrans- 7823 is being made mission and 7824 failure timers 7826 Bound Valid BE received and (None) Bound 7827 status = 2 7829 Bound ICMP Parameter Problem Code 1 (None) Bound 7830 received 7832 State Event Action New State 7833 -------------------------------------------------------------- 7835 (Any) Retransmission failed Stop retrans- Idle 7836 mission timer 7838 (Any) Invalid BRR received (No change) 7840 (Any) Invalid HoT received (No change) 7842 (Any) Invalid CoT received (No change) 7844 (Any) Invalid BA received (No change) 7846 (Any) Invalid BE received (No change) 7848 (Any) Invalid MH Type received Send BE with (No change) 7849 status 2 7851 B. Changes from Previous Version of the Draft 7853 This appendix briefly lists some of the major changes in this 7854 draft relative to the previous version of this same draft, 7855 draft-ietf-mobileip-ipv6-15.txt: 7857 B.1. Changes from Draft Version 16 7859 - The "rest" of the document has been updated to correspond to the 7860 new packet formats and messages. 7862 - Correspondent node operation has been updated to include the new 7863 security mechanisms. 7865 - Procedures for reverse tunneling have been described for both 7866 home agents and mobile nodes, and these requirements have been 7867 take in account in Section 8. 7869 - Terminology has been aligned throughout the document. Parameters 7870 are now mobility options. Binding Request is Binding Refresh 7871 Request. Capitalization of the terms has been aligned throughout 7872 the document. 7874 - Overview section is now shorter, security issues are discussed 7875 elsewhere and data structures are fully described later. 7877 - Parts of the mobile node requirements under Section 10.9 were 7878 moved to Section 11.3.3. 7880 - A mechanism for Binding Acknowledgement authorization has been 7881 clarified. 7883 - Alignment rules, minimum lengths, and packet formats of Mobility 7884 Header message have been updated. 7886 - Discussion on the use of Type 0 Routing header in addition to 7887 Type 2 Routing header has been removed from the correspondent 7888 node operation section, and we now rely only on the ordering 7889 requirements specified by the Routing Header Type 2 description. 7891 - Type 2 Routing header rules have been rewritten to allow for 7892 Segments Left to be 0. Explanation on how AH works with Routing 7893 header has been clarified. Much of the text has been moved 7894 to the Mobile Node Operation and Correspondent Node Operation 7895 sections. 7897 - The concept of "persistent" ICMP messages is no longer referred 7898 to by a MUST keyword in Section 9.7. 7900 - References to the "Router (R)" bit have been changed to "Router 7901 Address (R)" bit. 7903 - The Home Agent Information option now has to appear on all Prefix 7904 Advertisements, or on none of them. 7906 - Sub-options have been removed. 7908 - The Dynamic Home Agent Address Discovery procedures have been 7909 updated to not use piggybacking. Binding Refresh Requests 7910 are still sent during these procedures in certain cases, 7911 however. the Unique Identifier mobility option has been used 7912 to synchronize BRR and BU instead of the sequence number. The 7913 scheduling of the prefix deliveries has been changed to send new 7914 information even when the current binding is close to expiring. 7916 - Section 11.7 now uses ICMP Parameter Problem Code 1 instead of 2. 7918 - Sections 11.3.4 and 10.9 now agree that IPsec need not be used 7919 for the first advertisement. 7921 - The rules regarding addresses for receiving and sending multicast 7922 traffic and control messages have been clarified for mobile 7923 nodes. 7925 - The Binding Missing message has been renamed to Binding Error. 7927 - Eliminated the use of symbols in the description of the return 7928 routability procedure. 7930 - Wrote a new description of the return routability procedure. 7932 B.2. Changes from Draft Version 15 7934 - A binding update authorization mechanism suitable for use 7935 between previously unknown peers in the global Internet has been 7936 incorporated to the specification. As a result, Sections 5, 6.1, 7937 14 and others have been substantially revised. 7939 - A new IPv6 protocol has replaced IPv6 Destination Options for 7940 some of the MIPv6 signaling. This was done in order to enable 7941 the use of standard IPsec for the protection of binding updates 7942 between the mobile node and the home agent, the protection 7943 of return routability packets as they are forwarded to the 7944 mobile node from the home agent, and possibly in the future the 7945 protection of binding updates themselves to the correspondent 7946 nodes. This has resulted in substantial modifications in 7947 Section 6. 7949 - The use of the Home Address destination option has been 7950 restricted to the situation where a binding already exists. This 7951 has been done in order to limit distributed Denial-of-Service 7952 attacks through reflections attacks that employ the Home Address 7953 Option. 7955 - A new Binding Missing message has been added to signal the mobile 7956 node that it has used the Home Address destination option when 7957 the correspondent node has no existing binding to the node. 7959 - The Authorization Data mobility option has been made a part of 7960 the Binding Update and Acknowledgement messages, and is now 7961 calculated in the specific manner required by the authorization 7962 mechanism (return routability). 7964 - Sequence number length for Binding Update messages has been 7965 increased to 32 bits to protect home registrations against replay 7966 attacks. 7968 - Mobile IPv6 uses now Routing Header type 2 instead of the 7969 general type 0, in order to limit potential dangers that 7970 general capabilities offers type 0 and to ensure that firewall 7971 administrators want to allow the type of Routing Header that 7972 Mobile IPv6 uses through. 7974 - Requirements for all IPv6 routers have also been updated in order 7975 to describe the considerations relating to the new Routing Header 7976 type. 7978 - Processing rules for mobile nodes, correspondent nodes, and to 7979 some extent home agents have been substantially modified in order 7980 to explain the new authorization scheme. 7982 - Piggybacking is no longer possible due to the use of a new IPv6 7983 protocol and not a destination option. (However, a separate 7984 extension to this specification will allow piggybacking and takes 7985 in account the necessary IPsec policy considerations to avoid 7986 problems.) 7988 - The security considerations in Section 14 have been revised to 7989 describe the threats that this specification protects against as 7990 well as any residual threats. 7992 B.3. Changes from Earlier Versions of the Draft 7994 - Strengthened mandates for mobile nodes so that now a mobile node 7995 MUST support decapsulation and processing for routing headers 7996 (section 11.2.3). 7998 - Enabled ESP to be a valid way to secure reverse tunneled packets 7999 (section 10.6). 8001 - Removed mandate that mobile node select a default router, and 8002 instead described it as typical behavior (section 11.4.1). 8003 Also made it clear that picking a new default router does not 8004 automatically mean picking a new primary care-of address. 8006 - Modified mandated behavior from Home Agent upon reception of a 8007 `D' bit in a Binding Update. The home agent only has to make 8008 sure that DAD has been run, and that no other node on the home 8009 network could be using the mobile node's link-local address. 8011 - Added provisional ICMP numbers for the new message types, which 8012 may be reassigned by IANA, but which will be useful for testing 8013 purposes. 8015 - Removed the Mobile Router Prefix Length Sub-Option 8017 - Removed the Prefix Length field from the Binding Update, and 8018 references to error number 136. 8020 - Added the `S' bit so that the home agent can be instructed to 8021 *override* its default behavior. That is, with the `S' bit 8022 set, the home agent will not attempt to be helpful by changing 8023 multiple Binding Cache entries, for multiple routing prefixes, 8024 after receiving only one Binding Update. 8026 - Reworded the specification so that the Home Agent now has to 8027 perform Duplicate Address Detection for the mobile node's address 8028 on all the prefixes for which the router is performing home agent 8029 service. 8031 - Removed the section about Mobile Routers 8033 - Added the Authentication Data Sub-option; reorganized the section 8034 about computing authentication data. 8036 - Specified that the Home Agent lifetime is by default the same as 8037 the Router lifetime, in a Router Advertisement. 8039 - Specified that Binding Updates with zero lifetime and the 'A' bit 8040 set should cause a Binding Acknowledgement to be sent back to the 8041 Source IP address of the Binding Update. 8043 - Qualified the allowable times when a mobile node can send a 8044 Binding Update to a correspondent node 8046 - Added text allowing the correspondent node to extend an existing 8047 Routing Header by also including the care-of address as the entry 8048 of a routing header to be visited immediately before the home 8049 address. In this way, for instance, the mobile node can be an 8050 intermediate node of a path along the way to some other node. 8052 - Removed the Home Address field from the Home Agent Address 8053 Discovery Request Message. 8055 - Noted that ICMP Unreachable forms a potential mechanism by which 8056 a malicious node can cause a correspondent node to delete a valid 8057 entry from its Binding Cache. 8059 - Specified that, when a router stops offering home agent services 8060 by turning off the 'H' flag, the mobile node has to delete the 8061 corresponding entry from its Home Agent list. 8063 - Clarified language about how the aggregate list of prefixes is 8064 built by the home agent, to include only prefixes with the 'H' 8065 bit set. 8067 - Specified a new error status (141) to handle cases for sequence 8068 number mismatches (e.g., when a mobile node reboots). 8070 - Moved this section to the appendix, and reorganized other 8071 appendix sections. 8073 - Reorganized some related sections to be adjacent to each other. 8075 - Changed the Prefix Length of the Binding Update to be 7-bit only, 8076 in order to reserve more flag bits for the future. 8078 - Changed the Sequence Number of the Binding Update and Binding 8079 Acknowledgement to be 8-bit only. 8081 - Inserted specification that, after returning home and sending a 8082 Neighbor Solicitation to the home agent, a mobile node should 8083 accept any Neighbor Advertisement from the home agent as an 8084 indication that the home agent is REACHABLE. 8086 - Inserted new terminology for binding key and binding security 8087 association in anticipation of eliminating the use of AH 8089 - Eliminated use of AH for authenticating Binding Update, and for 8090 authenticating Binding Acknowledgement 8092 - Specified that all correspondent nodes MUST implement a base 8093 protocol for establishing a Binding Key; this has become the 8094 return routability procedure in this document. 8096 - Added the following protocol constants: 8098 INITIAL_SOLICIT_TIMER: XXX 8100 - Created new ICMP messages for Mobile Prefix Solicitations and 8101 Advertisements (see sections 6.7 and 6.8). 8103 - Changed Network Renumbering (Section 10.9.1) to encompass mobile 8104 node configuration issues, remove unspecified address usage, 8105 simplify rules for prefix maintenance and sending, and use new 8106 ICMP message types noted above. 8108 - Added a paragraph to Returning Home (section 11.6.7) to describe 8109 how the Home Agent discovers the mobile node's link-layer address 8111 - Reworded parts of Appendix C as needed. 8113 - Added the Mobile Router Prefix Length Sub-Option along with text 8114 describing what a Mobile Router should do with it. 8116 C. Remote Home Address Configuration 8118 The method for initializing a mobile node's home addresses on 8119 power-up or after an extended period of being disconnected from 8120 the network is beyond the scope of this specification. Whatever 8121 procedure is used should result in the mobile node having the same 8122 stateless or stateful (e.g., DHCPv6) home address autoconfiguration 8123 information it would have if it were attached to the home network. 8124 Due to the possibility that the home network could be renumbered 8125 while the mobile node is disconnected, a robust mobile node would not 8126 rely solely on storing these addresses locally. 8128 Such a mobile node could initialize by using the following procedure: 8130 1. Generate a care-of address using stateless or stateful 8131 autoconfiguration. 8133 2. Query DNS for the home network's mobile agent anycast address. 8135 3. Send a Home Agent Address Discovery Request message to the home 8136 network. 8138 4. Receive Home Agent Address Discovery Reply message. 8140 5. Select the most preferred home agent and establish a security 8141 association between the mobile node's current care-of address and 8142 the home agent for temporary use during initialization only. 8144 6. Send a Home Prefix Solicitation message with the Request All 8145 Prefixes flag set to the home agent from the mobile node's 8146 care-of address. 8148 7. Receive a Home Prefix Advertisement message from the home agent, 8149 follow stateless address autoconfiguration rules to configure 8150 home addresses for prefixes received. 8152 8. Create a security association between the mobile node's home 8153 address and the home agent. 8155 9. Send a binding update(s) to the home agent to register the mobile 8156 node's home addresses. 8158 10. Receive binding acknowledgement(s) then begin normal 8159 communications. 8161 D. Future Extensions 8163 D.1. Piggybacking 8165 This document does not specify how to piggyback payload packets on 8166 the binding related messages. However, it is envisioned that this 8167 can be specified in a separate document when currently discussed 8168 issues such as the interaction between piggybacking and IPsec are 8169 fully resolved (see also Section D.3). 8171 The idea is to use the Flag field in the HoTI message so that the 8172 mobile node can indicate that it supports the receipt of piggybacked 8173 messages, use the Flag field in the HoT message for the correspondent 8174 node to indicate that it can support the receipt of piggybacked 8175 messages, and then carry the piggybacked payload after the MH header 8176 by specifying a payload protocol type other than NO_NXTHDR (59). 8178 Until such a separate specification exists implementations conforming 8179 to this specification MUST set the payload protocol type to NO_NXTHDR 8180 (59 decimal). 8182 D.2. Triangular Routing and Unverified Home Addresses 8184 Due to the concerns about opening reflection attacks with the Home 8185 Address destination option, this specification requires that this 8186 option must be verified against the binding cache, i.e., there must 8187 be a binding cache entry for the Home Address and Care-of Address. 8189 Future extensions may be specified that allow the use of unverified 8190 Home Address destination options in ways that do not introduce 8191 security issues. 8193 D.3. New Authorization Methods beyond Return Routability 8195 While the return routability procedure provides a good level 8196 of security, there exists methods that have even higher levels 8197 of security. Secondly, as discussed in Section 14.3, future 8198 enhancements of IPv6 security may cause a need to improve also the 8199 security of the return routability procedure. The question is then 8200 what is the method to securely agree on the use of another method, 8201 while still allowing return routability procedure for some hosts 8202 during a transition period. In some cases, a third party can help to 8203 make this selection. But in general infrastructureless methods have 8204 little information beyond the exchanged messages and their contents. 8205 For these reasons, the final version of this specification requires 8206 a protection mechanism for selecting between the return routability 8207 procedure and potential other future mechanisms (see Section 14.3) 8208 but this isn't ready yet. 8210 Using IPsec as the sole method for authorizing Binding Updates 8211 to correspondent nodes is also possible. The protection of the 8212 Mobility Header for this purpose is easy, though one must ensure 8213 that the IPsec SA was created with appropriate authorization to use 8214 the home address referenced in the Binding Update. For instance, 8215 a certificate used by IKE to create the security association might 8216 contain the home address. A future specification may specify how 8217 this is done. 8219 Chairs' Addresses 8221 The Working Group can be contacted via its current chairs: 8223 Basavaraj Patil Phil Roberts 8224 Nokia Corporation Megisto Corp. 8225 6000 Connection Drive Suite 120 8226 M/S M8-540 20251 Century Blvd 8227 Irving, TX 75039 Germantown MD 20874 8228 USA USA 8229 Phone: +1 972-894-6709 Phone: +1 847-202-9314 8230 Fax : +1 972-894-5349 Email: PRoberts@MEGISTO.com 8231 EMail: Raj.Patil@nokia.com 8233 Authors' Addresses 8235 Questions about this document can also be directed to the authors: 8237 David B. Johnson Charles Perkins 8238 Rice University Nokia Research Center 8239 Dept. of Computer Science, MS 132 8240 6100 Main Street 313 Fairchild Drive 8241 Houston, TX 77005-1892 Mountain View, CA 94043 8242 USA USA 8244 Phone: +1 713 348-3063 Phone: +1 650 625-2986 8245 Fax: +1 713 348-5930 Fax: +1 650 625-2502 8246 E-mail: dbj@cs.rice.edu E-mail: charliep@iprg.nokia.com 8248 Jari Arkko 8249 Ericsson 8250 Jorvas 02420 8251 Finland 8253 Phone: +358 40 5079256 8254 E-mail: jari.arkko@ericsson.com