idnits 2.17.1 draft-ietf-mobileip-ipv6-16.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances 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 44: '...cluding one that MUST be supported in ...' RFC 2119 keyword, line 250: '...r mobility mechanisms MAY offer faster...' RFC 2119 keyword, line 560: '... A home registration MUST be protected...' RFC 2119 keyword, line 561: '... Binding Updates MUST be protected wit...' RFC 2119 keyword, line 571: '... registration MUST be protected wit...' (575 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (22 March 2002) is 8070 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: Non-RFC (?) normative reference: ref. '27' ** Obsolete normative reference: RFC 2407 (ref. '28') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 793 (ref. '31') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '32') (Obsoleted by RFC 3232) -- Possible downref: Normative reference to a draft: ref. '33' == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-01 -- Possible downref: Normative reference to a draft: ref. '34' ** Obsolete normative reference: RFC 2462 (ref. '35') (Obsoleted by RFC 4862) Summary: 23 errors (**), 0 flaws (~~), 2 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 22 March 2002 7 Mobility Support in IPv6 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note 17 that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents, valid for a maximum of six 21 months, and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 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 with 41 its care-of address, and to then send any packets destined for the 42 mobile node directly to it at this care-of address. To support this 43 operation, Mobile IPv6 defines four new IPv6 destination options, 44 including one that MUST be supported in packets received by any node, 45 whether mobile or stationary. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Comparison with Mobile IP for IPv4 3 57 3. Terminology 6 58 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 61 4. Overview of Mobile IPv6 8 62 4.1. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 8 63 4.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10 64 4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 13 65 4.4. Alignment Requirements for New Destination Options . . . 13 66 4.5. Security Design . . . . . . . . . . . . . . . . . . . . . 14 67 4.5.1. Security Threats . . . . . . . . . . . . . . . . 14 68 4.5.2. Security Features . . . . . . . . . . . . . . . . 15 69 4.5.3. Securing Tunnels to and from the Home Agents . . 17 70 4.5.4. Securing Binding Updates to Home Agents . . . . . 17 71 4.5.5. Securing Binding Updates to Correspondent Nodes . 18 72 4.5.6. Preventing Denial-of-Service Attacks . . . . . . 22 73 4.5.7. Design Rationale . . . . . . . . . . . . . . . . 23 74 4.6. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 24 75 4.7. Conceptual Data Structures . . . . . . . . . . . . . . . 25 76 4.8. Binding Management . . . . . . . . . . . . . . . . . . . 30 78 5. New IPv6 Destination Options and Message Types 31 79 5.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 31 80 5.1.1. Format . . . . . . . . . . . . . . . . . . . . . 32 81 5.1.2. Binding Request (BR) Message . . . . . . . . . . 33 82 5.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 34 83 5.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 35 84 5.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 36 85 5.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 38 86 5.1.7. Binding Update (BU) Message . . . . . . . . . . . 40 87 5.1.8. Binding Acknowledgement (BA) Message . . . . . . 44 88 5.1.9. Binding Missing (BM) Message . . . . . . . . . . 49 89 5.2. Mobility Header Parameters . . . . . . . . . . . . . . . 51 90 5.2.1. Format . . . . . . . . . . . . . . . . . . . . . 51 91 5.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 52 92 5.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 52 93 5.2.4. Unique Identifier . . . . . . . . . . . . . . . . 53 94 5.2.5. Alternate Care-of Address . . . . . . . . . . . . 53 95 5.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 54 96 5.2.7. Authentication Data . . . . . . . . . . . . . . . 54 97 5.3. Home Address Option . . . . . . . . . . . . . . . . . . . 55 98 5.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 58 99 5.4.1. Routing Header Packet format . . . . . . . . . . 58 100 5.4.2. Sending RH type 2 . . . . . . . . . . . . . . . . 59 101 5.4.3. Verification by receiver . . . . . . . . . . . . 60 102 5.4.4. Extension header ordering . . . . . . . . . . . . 60 103 5.4.5. Reversing type 2 routing headers . . . . . . . . 60 104 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 61 105 5.5.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . 62 106 5.5.2. PadN . . . . . . . . . . . . . . . . . . . . . . 62 107 5.6. ICMP Home Agent Address Discovery Request Message . . . . 63 108 5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 64 109 5.8. ICMP Mobile Prefix Solicitation Message Format . . . . . 66 110 5.9. ICMP Mobile Prefix Advertisement Message Format . . . . . 68 112 6. Modifications to IPv6 Neighbor Discovery 70 113 6.1. Modified Router Advertisement Message Format . . . . . . 70 114 6.2. Modified Prefix Information Option Format . . . . . . . . 71 115 6.3. New Advertisement Interval Option Format . . . . . . . . 73 116 6.4. New Home Agent Information Option Format . . . . . . . . 74 117 6.5. Changes to Sending Router Advertisements . . . . . . . . 76 118 6.6. Changes to Sending Router Solicitations . . . . . . . . . 77 120 7. Requirements for Types of IPv6 Nodes 79 121 7.1. Requirements for All IPv6 Routers . . . . . . . . . . . . 79 122 7.2. Requirements for IPv6 Home Agents . . . . . . . . . . . . 79 123 7.3. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 80 125 8. Correspondent Node Operation 82 126 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 82 127 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 82 128 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 83 129 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 84 130 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 84 131 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 85 132 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 85 133 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 86 134 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 87 136 9. Home Agent Operation 89 137 9.1. Primary Care-of Address Registration . . . . . . . . . . 89 138 9.2. Primary Care-of Address De-Registration . . . . . . . . . 92 139 9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 92 140 9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 94 141 9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 96 142 9.6. Protecting Return Routability Packets . . . . . . . . . . 96 143 9.7. Home Prefix Propagation . . . . . . . . . . . . . . . . . 96 144 9.8. Receiving Router Advertisement Messages . . . . . . . . . 97 145 9.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 98 146 9.9.1. Aggregate List of Home Network Prefixes . . . . . 100 147 9.9.2. Scheduling Prefix Deliveries to the Mobile Node . 101 148 9.9.3. Sending Advertisements to the Mobile Node . . . . 103 149 9.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 105 151 10. Mobile Node Operation 105 152 10.1. Sending Packets While Away from Home . . . . . . . . . . 105 153 10.2. Interaction with Outbound IPsec Processing . . . . . . . 107 154 10.3. Receiving Packets While Away from Home . . . . . . . . . 108 155 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 109 156 10.5. Receiving Local Router Advertisement Messages . . . . . . 112 157 10.6. Forming New Care-of Addresses . . . . . . . . . . . . . . 114 158 10.7. Sending Binding Updates to the Home Agent . . . . . . . . 115 159 10.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 117 160 10.9. Sending Binding Updates to Correspondent Nodes . . . . . 118 161 10.10. Receiving RR Messages . . . . . . . . . . . . . . . . . . 121 162 10.11. Establishing Forwarding from a Previous Care-of Address . 122 163 10.12. Retransmitting Binding Updates . . . . . . . . . . . . . 123 164 10.13. Rate Limiting for Sending Binding Updates . . . . . . . . 124 165 10.14. Receiving Binding Acknowledgements . . . . . . . . . . . 124 166 10.15. Receiving Binding Requests . . . . . . . . . . . . . . . 125 167 10.16. Receiving ICMP Error Messages . . . . . . . . . . . . . . 126 168 10.17. Receiving ICMP Error Messages . . . . . . . . . . . . . . 126 169 10.18. Sending Mobile Prefix Solicitations . . . . . . . . . . . 126 170 10.19. Receiving Mobile Prefix Advertisements . . . . . . . . . 127 171 10.20. Using Multiple Care-of Addresses . . . . . . . . . . . . 128 172 10.21. Routing Multicast Packets . . . . . . . . . . . . . . . . 128 173 10.22. Returning Home . . . . . . . . . . . . . . . . . . . . . 129 175 11. Protocol Constants 131 176 12. Future Extensions 132 177 12.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 132 178 12.2. Triangular Routing and Unverified HAOs . . . . . . . . . 132 179 12.3. New Authorization Methods beyond RR . . . . . . . . . . . 132 181 13. IANA Considerations 133 183 14. Security Considerations 134 184 14.1. Security for the Tunneling to and from the Home Agent . . 134 185 14.2. Security for the Binding Updates to the Home Agent . . . 135 186 14.3. Security for the Binding Updates to the Correspondent 187 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 135 188 14.4. Security for the Home Address Option . . . . . . . . . . 135 189 14.5. Firewall considerations . . . . . . . . . . . . . . . . . 136 191 Acknowledgements 137 193 References 138 195 A. Changes from Previous Version of the Draft 140 196 A.1. Changes from Draft Version ...-15 . . . . . . . . . . . . 140 197 A.2. Changes from Previous Versions of the Draft . . . . . . . 142 199 B. Remote Home Address Configuration 144 201 Chairs' Addresses 145 203 Authors' Addresses 146 204 1. Introduction 206 This document specifies the operation of mobile computers using 207 Internet Protocol Version 6 (IPv6) [6]. Without specific support 208 for mobility in IPv6, packets destined to a mobile node (host or 209 router) would not be able to reach it while the mobile node is away 210 from its home link (the link on which its home IPv6 subnet prefix is 211 in use), since routing is based on the subnet prefix in a packet's 212 destination IP address. In order to continue communication in spite 213 of its movement, a mobile node could change its IP address each time 214 it moves to a new link, but the mobile node would then not be able 215 to maintain transport and higher-layer connections when it changes 216 location. Mobility support in IPv6 is particularly important, as 217 mobile computers are likely to account for a majority or at least a 218 substantial fraction of the population of the Internet during the 219 lifetime of IPv6. 221 The protocol operation defined here, known as Mobile IPv6, allows a 222 mobile node to move from one link to another without changing the 223 mobile node's IP address. A mobile node is always addressable by 224 its "home address", an IP address assigned to the mobile node within 225 its home subnet prefix on its home link. Packets may be routed to 226 the mobile node using this address regardless of the mobile node's 227 current point of attachment to the Internet, and the mobile node may 228 continue to communicate with other nodes (stationary or mobile) after 229 moving to a new link. The movement of a mobile node away from its 230 home link is thus transparent to transport and higher-layer protocols 231 and applications. 233 The Mobile IPv6 protocol is just as suitable for mobility across 234 homogeneous media as for mobility across heterogeneous media. For 235 example, Mobile IPv6 facilitates node movement from one Ethernet 236 segment to another as well as it facilitates node movement from an 237 Ethernet segment to a wireless LAN cell, with the mobile node's IP 238 address remaining unchanged in spite of such movement. 240 One can think of the Mobile IPv6 protocol as solving the 241 network-layer mobility management problem. Some mobility management 242 applications -- for example, handover among wireless transceivers, 243 each of which covers only a very small geographic area -- have been 244 solved using link-layer techniques. For example, in many current 245 wireless LAN products, link-layer mobility mechanisms allow a 246 "handover" of a mobile node from one cell to another, reestablishing 247 link-layer connectivity to the node in each new location. Within 248 the natural limitations imposed by link-management solutions, and as 249 long as such handover occurs only within cells of the mobile node's 250 home link, such link-layer mobility mechanisms MAY offer faster 251 convergence and lower overhead than Mobile IPv6. Extensions to the 252 Mobile IPv6 protocol have been proposed to support a more local, 253 hierarchical form of mobility management, but such extensions are 254 beyond the scope of this document. 256 The protocol specified in this document solves the problem of 257 transparently routing packets to and from mobile nodes while away 258 from home. However, it does not attempt to solve all general 259 problems related to the use of mobile computers or wireless networks. 260 In particular, this protocol does not attempt to solve: 262 - Handling links with partial reachability, or unidirectional 263 connectivity, such as are often found in wireless networks. Some 264 aspects of this problem are addressed by the movement detection 265 procedure described in Section 10.4, but no attempt has been made 266 to fully solve this problem in its general form. Most aspects of 267 this problem can be solved by the workaround of restricting such 268 networks to only one router per link, although there are still 269 possible hidden terminal problems when two nodes on the same 270 link (on opposite sides of the router) attempt to communicate 271 directly. 273 - Access control on a link being visited by a mobile node. This 274 is a general problem any time an unauthenticated node is allowed 275 to connect to any link layer. It is independent of whether the 276 connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP 277 address on the link. 279 2. Comparison with Mobile IP for IPv4 281 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 282 natural combination of the experiences gained from the development 283 of Mobile IP support in IPv4 (Mobile IPv4) [25, 24, 26], together 284 with the opportunities provided by the design and deployment of a new 285 version of IP itself (IPv6) and the new protocol features offered 286 by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, 287 but the protocol is now fully integrated into IP and provides many 288 improvements over Mobile IPv4. This section summarizes the major 289 differences between Mobile IPv4 and Mobile IPv6: 291 - Support for what is known in Mobile IPv4 as "Route 292 Optimization" [27] is now built in as a fundamental part 293 of the protocol, rather than being added on as an optional 294 set of extensions that may not be supported by all nodes 295 as in Mobile IPv4. This integration of Route Optimization 296 functionality allows direct routing from any correspondent 297 node to any mobile node, without needing to pass through 298 the mobile node's home network and be forwarded by its home 299 agent, and thus eliminates the problem of "triangle routing" 300 present in the base Mobile IPv4 protocol [25]. The Mobile IPv4 301 "registration" functionality and the Mobile IPv4 Route 302 Optimization functionality are performed by a single protocol 303 rather than two separate (and different) protocols. 305 - Support is also integrated into Mobile IPv6 -- and into IPv6 306 itself -- for allowing mobile nodes and Mobile IP to coexist 307 efficiently with routers that perform "ingress filtering" [7]. A 308 mobile node now uses its care-of address as the Source Address in 309 the IP header of packets it sends, allowing the packets to pass 310 normally through ingress filtering routers. The home address 311 of the mobile node is carried in the packet in a Home Address 312 destination option, allowing the use of the care-of address in 313 the packet to be transparent above the IP layer. The ability 314 to correctly process a Home Address option in a received packet 315 is required in all IPv6 nodes, whether mobile nor stationary, 316 whether host or router. 318 - The use of IPv6 destination options allows all Mobile IPv6 319 control traffic to be piggybacked on any existing IPv6 packets, 320 whereas in Mobile IPv4 and its Route Optimization extensions, 321 separate UDP packets were required for each control message. 323 - The use of the care-of address as the Source Address in each 324 packet's IP header also simplifies routing of multicast packets 325 sent by a mobile node. With Mobile IPv4, the mobile node 326 had to tunnel multicast packets to its home agent in order to 327 transparently use its home address as the source of the multicast 328 packets. With Mobile IPv6, the use of the Home Address option 329 allows the home address to be used but still be compatible with 330 multicast routing that is based in part on the packet's Source 331 Address. 333 - There is no longer any need to deploy special routers as 334 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 335 mobile nodes make use of IPv6 features, such as Neighbor 336 Discovery [20] and Address Autoconfiguration [35], to operate in 337 any location away from home without any special support required 338 from its local router. 340 - The movement detection mechanism in Mobile IPv6 provides 341 bidirectional confirmation of a mobile node's ability to 342 communicate with its default router in its current location 343 (packets that the router sends are reaching the mobile node, and 344 packets that the mobile node sends are reaching the router). 345 This confirmation provides a detection of the "black hole" 346 situation that may exist in some wireless environments where the 347 link to the router does not work equally well in both directions, 348 such as when the mobile node has moved out of good wireless 349 transmission range from the router. The mobile node may then 350 attempt to find a new router and begin using a new care-of 351 address if its link to its current router is not working well. 352 In contrast, in Mobile IPv4, only the forward direction (packets 353 from the router are reaching the mobile node) is confirmed, 354 allowing the black hole condition to persist. 356 - Most packets sent to a mobile node while away from home in 357 Mobile IPv6 are sent using an IPv6 Routing header rather than IP 358 encapsulation, whereas Mobile IPv4 must use encapsulation for all 359 packets. The use of a Routing header requires less additional 360 header bytes to be added to the packet, reducing the overhead 361 of Mobile IP packet delivery. To avoid modifying the packet in 362 flight, however, packets intercepted and tunneled by a mobile 363 node's home agent in Mobile IPv6 must still use encapsulation for 364 delivery to the mobile node. 366 - While a mobile node is away from home, its home agent intercepts 367 any packets for the mobile node that arrive at the home network, 368 using IPv6 Neighbor Discovery [20] rather than ARP [29] as is 369 used in Mobile IPv4. The use of Neighbor Discovery improves 370 the robustness of the protocol (e.g., due to the Neighbor 371 Advertisement "override" bit) and simplifies implementation 372 of Mobile IP due to the ability to not be concerned with any 373 particular link layer as is required in ARP. 375 - The use of IPv6 encapsulation (and the Routing header) removes 376 the need in Mobile IPv6 to manage "tunnel soft state", which was 377 required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 378 to the definition of ICMP for IPv6, the use of tunnel soft state 379 is no longer required in IPv6 for correctly relaying ICMP error 380 messages from within the tunnel back to the original sender of 381 the packet. 383 - The dynamic home agent address discovery mechanism in Mobile IPv6 384 uses IPv6 anycast [11] and returns a single reply to the mobile 385 node, rather than the corresponding Mobile IPv4 mechanism that 386 used IPv4 directed broadcast and returned a separate reply from 387 each home agent on the mobile node's home link. The Mobile IPv6 388 mechanism is more efficient and more reliable, since only one 389 packet need be sent back to the mobile node. The mobile node is 390 less likely to lose one of the replies because no "implosion" of 391 replies is required by the protocol. 393 - Mobile IPv6 defines an Advertisement Interval option on 394 Router Advertisements (equivalent to Agent Advertisements in 395 Mobile IPv4), allowing a mobile node to decide for itself how 396 many Router Advertisements (Agent Advertisements) it is willing 397 to miss before declaring its current router unreachable. 399 3. Terminology 401 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 402 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 403 document are to be interpreted as described in RFC 2119 [3]. 405 3.1. General Terms 407 IP Internet Protocol Version 6 (IPv6). 409 node A device that implements IP. 411 router A node that forwards IP packets not explicitly 412 addressed to itself. 414 host Any node that is not a router. 416 link A communication facility or medium over which nodes 417 can communicate at the link layer, such as an 418 Ethernet (simple or bridged). A link is the layer 419 immediately below IP. 421 interface A node's attachment to a link. 423 subnet prefix 424 A bit string that consists of some number of initial 425 bits of an IP address. 427 interface identifier 428 A number used to identify a node's interface on a 429 link. The interface identifier is the remaining 430 low-order bits in the node's IP address after the 431 subnet prefix. 433 link-layer address 434 A link-layer identifier for an interface, such as 435 IEEE 802 addresses on Ethernet links. 437 packet An IP header plus payload. 439 Security Association 440 a security object shared between two nodes which 441 includes the data mutually agreed on for operation 442 of some cryptographic algorithm (typically including 443 a key, as defined above). 445 Security Policy Database (SPD) 446 A database of security associations selectable by 447 rulesets (policies) that determine the packets for 448 which each security association is to be applied. 450 3.2. Mobile IPv6 Terms 452 home address An IP address assigned to a mobile node within its 453 home link. 455 home subnet prefix 456 The IP subnet prefix corresponding to a mobile 457 node's home address. 459 home link The link on which a mobile node's home subnet prefix 460 is defined. Standard IP routing mechanisms will 461 deliver packets destined for a mobile node's home 462 address to its home link. 464 mobile node A node that can change its point of attachment from 465 one link to another, while still being reachable via 466 its home address. 468 movement A change in a mobile node's point of attachment to 469 the Internet such that it is no longer connected to 470 the same link as it was previously. If a mobile 471 node is not currently attached to its home link, the 472 mobile node is said to be "away from home". 474 correspondent node 475 A peer node with which a mobile node is 476 communicating. The correspondent node may be either 477 mobile or stationary. 479 foreign subnet prefix 480 Any IP subnet prefix other than the mobile node's 481 home subnet prefix. 483 foreign link Any link other than the mobile node's home link. 485 home agent A router on a mobile node's home link with which 486 the mobile node has registered its current care-of 487 address. While the mobile node is away from home, 488 the home agent intercepts packets on the home 489 link destined to the mobile node's home address, 490 encapsulates them, and tunnels them to the mobile 491 node's registered care-of address. 493 care-of address 494 An IP address associated with a mobile node while 495 visiting a foreign link; the subnet prefix of this 496 IP address is a foreign subnet prefix. Among the 497 multiple care-of addresses that a mobile node 498 may have at a time (e.g., with different subnet 499 prefixes), the one registered with the mobile node's 500 home agent is called its "primary" care-of address. 502 binding The association of the home address of a mobile node 503 with a care-of address for that mobile node, along 504 with the remaining lifetime of that association. 506 Binding Key 507 a key used for authenticating Binding Update 508 messages. 510 Binding Security Association (BSA) 511 a security association established specifically 512 for the purpose of producing and verifying 513 authentication data passed with a Binding Update 514 destination option. 516 4. Overview of Mobile IPv6 518 4.1. New IPv6 Protocols 520 As mentioned in Section 4.2, Mobile IPv6 defines a new IPv6 protocol, 521 the Mobility Header. This protocol is used to carry the following 522 messages: 524 Home Test Init 526 The Home Test Init message is used to initiate the Return 527 Routability procedure from the mobile node to a correspondent 528 node. This procedure ensures that subsequence Binding Updates 529 are properly authorized to redirect the traffic of a particular 530 home address. The Home Test Init message is described in 531 detail in Section 5.1.3. 533 Care-of Test Init 535 The Care-of Test Init message is also used to initiate the 536 Return Routability procedure, for a particular care-of address. 537 The Care-of Test Init message is described in detail in 538 Section 5.1.4. 540 Home Test 542 The Home Test message carries a cookie which the mobile node 543 needs before it can properly authorize itself for sending a 544 Binding Update. This message is an answer to the Home Test 545 Init message, and is described in detail in Section 5.1.5. 547 Care-of Test 549 The Care-of Test message carries a cookie which the mobile node 550 needs before it can properly authorize itself for sending a 551 Binding Update. This message is an answer to the Care-of Test 552 Init message, and is described in detail in Section 5.1.6. 554 Binding Update 556 A Binding Update message is used by a mobile node to notify 557 a correspondent node or the mobile node's home agent of its 558 current binding. The Binding Update sent to the mobile node's 559 home agent to register its primary care-of address is marked as 560 a "home registration". A home registration MUST be protected 561 with IPsec, while other Binding Updates MUST be protected with 562 an authenticator as described in Section 4.5. The Binding 563 Update message and its specific authentication requirements are 564 described in detail in Section 5.1.7. 566 Binding Acknowledgement 568 A Binding Acknowledgement message is used to acknowledge 569 receipt of a Binding Update, if an acknowledgement was 570 requested in the Binding Update. An acknowledgement of a home 571 registration MUST be protected with IPsec, while other Binding 572 Update acknowledgements MUST be protected with an authenticator 573 as described in Section 4.5. The Binding Acknowledgement 574 message and its specific authentication requirements are 575 described in detail in Section 5.1.8. 577 Binding Request 579 A Binding Request message is used to request a mobile node 580 to send to the requesting node a Binding Update containing 581 the mobile node's current binding. This message is typically 582 used by a correspondent node to refresh a cached binding for a 583 mobile node, when the cached binding is in active use but the 584 binding's lifetime is close to expiration. No authentication 585 is required for the Binding Request message. The Binding 586 Request message is described in detail in Section 5.1.2. 588 Binding Missing 590 The Binding Missing message is used by the correspondent node 591 to signal an inappropriate attempt to use the Home Address 592 Option without an existing binding. This message is described 593 in detail in Section 5.1.9. 595 Mobile IPv6 also defines a number of "parameters" for use within 596 these messages; if included, any parameters MUST appear after the 597 fixed portion of the option data specified in this document. The 598 presence of such parameters will be indicated by the Header Len 599 field within the message. When the Header Len is greater than the 600 length required for the message specified here, the remaining octets 601 are interpreted as parameters. The encoding and format of defined 602 parameters are described in Section 5.2. 604 Alignment requirements for the Mobility Header are same as for any 605 IPv6 protocol, i.e. they MUST be aligned on an 8-octet boundary. 606 We also require that the Mobility Header length is a multiple of 8 607 octets. 609 4.2. Basic Operation 611 A mobile node is always addressable by its home address, whether it 612 is currently attached to its home link or is away from home. While 613 a mobile node is at home, packets addressed to its home address are 614 routed to it using conventional Internet routing mechanisms in the 615 same way as if the node were never mobile. Since the subnet prefix 616 of a mobile node's home address is the subnet prefix (or one of the 617 subnet prefixes) on the mobile node's home link (it is the mobile 618 node's home subnet prefix), packets addressed to it will be routed to 619 its home link. 621 While a mobile node is attached to some foreign link away from home, 622 it is also addressable by one or more care-of addresses, in addition 623 to its home address. A care-of address is an IP address associated 624 with a mobile node while visiting a particular foreign link. The 625 subnet prefix of a mobile node's care-of address is the subnet prefix 626 (or one of the subnet prefixes) on the foreign link being visited by 627 the mobile node; if the mobile node is connected to this foreign link 628 while using that care-of address, packets addressed to this care-of 629 address will be routed to the mobile node in its location away from 630 home. 632 The association between a mobile node's home address and care-of 633 address is known as a "binding" for the mobile node. A mobile node 634 typically acquires its care-of address through stateless [35] or 635 stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according 636 to the methods of IPv6 Neighbor Discovery [20]. Other methods 637 of acquiring a care-of address are also possible, such as static 638 pre-assignment by the owner or manager of a particular foreign link, 639 but details of such other methods are beyond the scope of this 640 document. 642 While away from home, a mobile node registers one of its care-of 643 addresses with a router on its home link, requesting this router 644 to function as the "home agent" for the mobile node. This binding 645 registration is done by the mobile node sending to the home agent 646 a packet containing a "Binding Update" destination option; the 647 home agent then replies to the mobile node by returning a packet 648 containing a "Binding Acknowledgement" destination option. The 649 care-of address in this binding registered with its home agent is 650 known as the mobile node's "primary care-of address". The mobile 651 node's home agent thereafter uses proxy Neighbor Discovery to 652 intercept any IPv6 packets addressed to the mobile node's home 653 address (or home addresses) on the home link, and tunnels each 654 intercepted packet to the mobile node's primary care-of address. 655 To tunnel each intercepted packet, the home agent encapsulates the 656 packet using IPv6 encapsulation [4], with the outer IPv6 header 657 addressed to the mobile node's primary care-of address. 659 When a mobile node moves from one care-of address to a new care-of 660 address on a new link, it is desirable for packets arriving at the 661 previous care-of address to be tunneled to the mobile node's care-of 662 address. Since the purpose of a Binding Update is to establish 663 exactly this kind of tunneling, it is specified to be used (at 664 least temporarily) for tunnels originating at the mobile node's 665 previous care-of address, in exactly the same way that it is used 666 for establishing tunnels from the mobile node's home address to the 667 mobile node's current care-of address. Section 10.11 describes the 668 use of the Binding Update for this purpose. 670 Section 10.20 discusses the reasons why it may be desirable for 671 a mobile node to use more than one care-of address at the same 672 time. However, a mobile node's primary care-of address is distinct 673 among these in that the home agent maintains only a single care-of 674 address registered for each mobile node, and always tunnels a mobile 675 node's packets intercepted from its home link to this mobile node's 676 registered primary care-of address. The home agent thus need not 677 implement any policy to determine the particular care-of address to 678 which it will tunnel each intercepted packet. The mobile node alone 679 controls the policy by which it selects the care-of addresses to 680 register with its home agent. 682 It is possible that while a mobile node is away from home, some nodes 683 on its home link may be reconfigured, such that the router that was 684 operating as the mobile node's home agent is replaced by a different 685 router serving this role. In this case, the mobile node may not 686 know the IP address of its own home agent. Mobile IPv6 provides a 687 mechanism, known as "dynamic home agent address discovery", that 688 allows a mobile node to dynamically discover the IP address of a 689 home agent on its home link with which it may register its (primary) 690 care-of address while away from home. The mobile node sends an ICMP 691 "Home Agent Address Discovery Request" message to the "Mobile IPv6 692 Home-Agents" anycast address for its own home subnet prefix [11] and 693 thus reaches one of the (possibly many) routers on its home link 694 currently operating as a home agent. This home agent then returns an 695 ICMP "Home Agent Address Discovery Reply" message to the mobile node, 696 including a list of home agents on the home link. This list of home 697 agents is maintained by each home agent on the home link through use 698 of the Home Agent (H) bit in each home agent's periodic unsolicited 699 multicast Router Advertisements. 701 The Binding Update and Binding Acknowledgement destination options, 702 together with a "Binding Request" destination option, are also used 703 to allow IPv6 nodes communicating with a mobile node, to dynamically 704 learn and cache the mobile node's binding. When sending a packet 705 to any IPv6 destination, a node checks its cached bindings for an 706 entry for the packet's destination address. If a cached binding for 707 this destination address is found, the node uses an IPv6 Routing 708 header [6] (instead of IPv6 encapsulation) to route the packet to 709 the mobile node by way of the care-of address indicated in this 710 binding. If, instead, the sending node has no cached binding for 711 this destination address, the node sends the packet normally (with 712 no Routing header), and the packet is subsequently intercepted and 713 tunneled by the mobile node's home agent as described above. Any 714 node communicating with a mobile node is referred to in this document 715 as a "correspondent node" of the mobile node, and may itself be 716 either a stationary node or a mobile node. 718 Since a Binding Update, Binding Acknowledgement, and Binding Request 719 are each represented in a packet as an IPv6 destination option [6], 720 they may be included in any IPv6 packet. Any of these options can be 721 sent in either of two ways: 723 - the messages can be included within any IPv6 packet carrying any 724 payload such as TCP [31] or UDP [30]. 726 - the messages can be sent as a separate IPv6 packet containing 727 no payload. In this case, the Next Header field in the last 728 extension header in the packet is set to the value 59, to 729 indicate "No Next Header" [6]. 731 Mobile IPv6 also defines one additional IPv6 destination option. 732 When a mobile node sends a packet while away from home, it will 733 generally set the Source Address in the packet's IPv6 header to one 734 of its current care-of addresses, and will also include a "Home 735 Address" destination option in the packet, giving the mobile node's 736 home address. Many routers implement security policies such as 737 "ingress filtering" [7] that do not allow forwarding of packets 738 that have a Source Address which appears topologically incorrect. 739 By using the care-of address as the IPv6 header Source Address, 740 the packet will be able to pass normally through such routers, 741 yet ingress filtering rules will still be able to locate the true 742 topological source of the packet in the same way as packets from 743 non-mobile nodes. By also including the Home Address option in each 744 packet, the sending mobile node can communicate its home address to 745 the correspondent node receiving this packet, allowing the use of 746 the care-of address to be transparent above the Mobile IPv6 support 747 level (e.g., at the transport layer). The inclusion of a Home 748 Address option in a packet affects only the correspondent node's 749 receipt of this single packet; no state is created or modified in the 750 correspondent node as a result of receiving a Home Address option in 751 a packet. 753 4.3. New IPv6 Destination Options 755 As mentioned in Section 4.2, the following new IPv6 destination 756 option is defined for Mobile IPv6: 758 Home Address 760 A Home Address option is used in a packet sent by a mobile 761 node to inform the recipient of that packet of the mobile 762 node's home address. For packets sent by a mobile node while 763 away from home, the mobile node generally uses one of its 764 care-of addresses as the Source Address in the packet's IPv6 765 header. By including a Home Address option in the packet, the 766 correspondent node receiving the packet is able to substitute 767 the mobile node's home address for this care-of address when 768 processing the packet, thus making the use of the care-of 769 address transparent to the correspondent node. If the IP 770 header of a packet carrying a Home Address option is covered 771 by authentication, then the Home Address option MUST also be 772 covered by this authentication, but no other authentication 773 is required for the Home Address option. See sections 10.2 774 and 5.3 for additional details about requirements for the 775 calculation and verification of the authentication data. The 776 Home Address option is described in detail in Section 5.3. 778 Mobile IPv6 also defines a number of "sub-options" for use within 779 destination options. If included, any sub-options MUST appear after 780 the fixed portion of the option data specified in this document. The 781 presence of such sub-options will be indicated by the Option Length 782 field within the option. When the Option Length is greater than the 783 length required for the option specified here, the remaining octets 784 are interpreted as sub-options. The encoding and format of defined 785 sub-options are described in Section 5.5. 787 4.4. Alignment Requirements for New Destination Options 789 IPv6 requires that options appearing in a Hop-by-Hop Options 790 header or Destination Options header be aligned in a packet so that 791 multi-octet values within the Option Data field of each option fall 792 on natural boundaries (i.e., fields of width n octets are placed 793 at an integer multiple of n octets from the start of the header, 794 for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar 795 alignment requirements, so that multi-octet values within the 796 Sub-Option Data field of each sub-option fall on natural boundaries. 797 The alignment requirement of an option or sub-option is specified in 798 this document using the standard notation used elsewhere for IPv6 799 alignment requirements [6]. Specifically, the notation xn+y means 800 that the Option Type or Sub-Option Type field must fall at an integer 801 multiple of x octets from the start of the header, plus y octets. 802 For example: 804 2n means any 2-octet offset from the start of the header. 806 8n+2 means any 8-octet offset from the start of the header, 807 plus 2 octets. 809 4.5. Security Design 811 4.5.1. Security Threats 813 The MIPv6 protocol needs to protect itself against the following main 814 threats: 816 1. Threats against Binding Updates sent to home agents: a attacker 817 might claim that a certain mobile node is currently at a 818 different location than it really is. If the home agent accepts 819 the information sent to it as is, the mobile node might not get 820 traffic destined to it, and other nodes might get traffic they 821 didn't want. 823 2. Threats against route optimization with correspondent nodes: 824 A malicious mobile node might lie about its home address. A 825 malicious mobile node might send a correspondent node binding 826 updates in which the home address is set to the address of 827 another node, the victim. If the correspondent node accepted 828 this forged binding update, then communications between the 829 correspondent node and the victim would be disrupted, because 830 packets that the correspondent node intended to send to the 831 victim would be sent to the wrong care-of address. This is a 832 threat to confidentiality as well as availability, because an 833 attacker might redirect packets meant for another node to itself 834 in order to learn the content of those packets. 836 A malicious mobile node might lie about its care-of address. A 837 malicious mobile node might send a correspondent node binding 838 updates in which the care-of address is set to the address of 839 a victim node or an address within a victim network. If the 840 correspondent node accepted this forged binding update, then the 841 malicious mobile could trick the correspondent into sending data 842 to the victim node or the victim network; the correspondent's 843 replies to messages sent by the malicious mobile will be sent 844 to the victim host or network. This could be used to cause a 845 distributed denial of service attack; the malicious mobile could 846 trick a large number of servers so that they all send a large 847 amount of data to the same victim node or network. Several 848 variations of this threat are described elsewhere [1][33]. 850 A malicious node might also send a large number of invalid 851 binding updates to a victim correspondent node. If each invalid 852 binding update took a significant amount of resources (such as 853 CPU) to process before it could be recognized as invalid, then it 854 might be possible to cause a denial of service attack by sending 855 the correspondent so may invalid binding updates that it has no 856 resources left for other tasks. 858 An attacker might also replay an old binding update. An attacker 859 might attempt to disrupt a mobile node's communications by 860 replaying a binding update that the node had sent earlier. If 861 the old binding update was accepted, packets destined for the 862 mobile node would be sent to its old location and not its current 863 location. 865 3. Threats where MIPv6 correspondent node functionality is used 866 to launch reflection attacks against other parties [34] [23]. 867 The Home Address Option can be used to direct response traffic 868 against a node whose IP address appears in the option, without 869 giving a possibility for ingress filtering to catch the forged 870 "return address". 872 4. Threats where the tunnels between the mobile node and the home 873 agent are attacked to make it appear like the mobile node is 874 sending traffic while it is not. 876 5. Threats where IPv6 Routing Header -- which is employed in 877 MIPv6 -- is used to circumvent IP-address based rules in 878 firewalls or to reflect traffic from other nodes. The generality 879 of the Routing Header allows the kind of usage that opens 880 vulnerabilities, even if the usage that MIPv6 needs is safe. 882 6. The security mechanisms of MIPv6 may also be attacked themselves, 883 e.g. in order to force the participants to execute expensive 884 cryptographic operations or allocate memory for the purpose of 885 keeping state. 887 Most of the above threats are concerned with denial of service. Some 888 of the threats also open up possibilities for man-in-the-middle, 889 hijacking, and impersonation attacks. 891 4.5.2. Security Features 893 This specification provides a number of security features. The main 894 features are: 896 - Protection of Binding Updates to home agents. 898 - Protection of Binding Updates to correspondent nodes. 900 - Protection against reflection attacks through the Home Address 901 Option. 903 - Protection of tunnels between the mobile node and the home agent. 905 - Preventing Routing Header vulnerabilities. 907 - Preventing Denial-of-Service attacks to the MIPv6 security 908 mechanisms themselves. 910 Protecting the Binding Updates to home agents and to correspondent 911 nodes require very different security solutions due to the different 912 situations. Mobile nodes and home agents know each other, and can 913 thus have a strong security association to reliably authenticate 914 the exchanged messages. In this environment, IPsec Encapsulating 915 Security Payload (ESP) can be used to implement the necessary 916 security features. See Section 4.5.5. 918 The protection of Binding Updates to correspondents is a much harder 919 problem for the traditional strong authentication approach. It is 920 expected that MIPv6 will be used on a global basis between nodes 921 belonging under different administrative domains, hence building 922 an authentication infrastructure to authenticate mobile nodes 923 and correspondent nodes would be a very demanding task. Thus, an 924 infrastructureless approach is necessary. Furthermore, making a 925 traditional authentication infrastructure keep track of correct 926 IP addresses for all hosts is either impossible or at least very 927 hard. That is, it isn't sufficient to authenticate mobile nodes, 928 authorization to claim right to use an address is needed. 930 A different approach is therefore necessary. The chosen method 931 verifies that the mobile node is ``live'' (that is, it responds to 932 probes) at its home and care-of addresses by performing a cookie 933 exchange with the addresses, and by requiring that the eventual 934 binding update is cryptographically bound to the sent cookies. 935 Some additional protection is provided by requiring the cookies be 936 protected by ESP when forwarded by the Home Agent to the mobile node. 937 This method limits the vulnerabilities to those attackers who are 938 on the path between the Home Agent and the correspondent node. As 939 adversaries on this path would be able to cause also other types of 940 attacks, this is seen as sufficient base security between mobile and 941 correspondent nodes. 943 Vulnerabilities relating to the use of correspondent nodes as 944 reflectors via the Home Address Option can be solved as follows. We 945 ensure that the mobile node is authorized to use a given home address 946 before HAO can be used. Such authorization is already performed in 947 the context of Route Optimization, and therefore this specification 948 limits the use of the HAO to the situation where the correspondent 949 node already has a binding cache entry for the given home address. 951 Tunnels between the mobile node and the home agent can be 952 protected by ensuring proper use of source addresses, and optional 953 cryptographic protection. These procedures are discussed in 954 Section 4.5.3. 956 Vulnerabilities related to the Routing Header can be prevented by 957 using a MIPv6 specific type of a Routing Header. This type provides 958 the necessary functionality but does not open vulnerabilities. 960 Denial-of-Service threats against MIPv6 security mechanisms 961 themselves concern mainly the Binding Update procedures with 962 correspondent nodes. The protocol has been designed to limit the 963 effects of such attacks, as will be described in Section 4.5.6. 965 4.5.3. Securing Tunnels to and from the Home Agents 967 Tunnels between the mobile node and the home agent need protection 968 so that it isn't possible for anyone to send traffic through the 969 home agent, pose as the mobile node, and escape detection through 970 traditional tracing mechanisms. 972 If Binding Updates sent to the home agents are secure, and the home 973 agent verifies the outer IP address corresponds to the current 974 location of the mobile node, this prevents attacks against the tunnel 975 from other IP addresses. This prevents attacks where the attacker 976 is controlled by ingress filtering, as well as attacks where the 977 attacker does not know the current care-of address of the mobile 978 node. Attackers who know the care-of address are not controlled by 979 ingress filtering could still send traffic through the home agent, 980 but they could also send spoofed packets without using a tunnel. 982 Encapsulating the tunneled traffic inside IPsec ESP offers an 983 optional mechanism to protect the confidentiality and integrity of 984 the traffic against on-path attackers. 986 4.5.4. Securing Binding Updates to Home Agents 988 Signaling between the mobile node and the home agent requires message 989 integrity, correct ordering and replay protection. 991 In order to have this protection, the mobile node and the home agent 992 must have a security association. IPsec Encapsulating Security 993 Payload (ESP) can be used to for integrity protection when a non-null 994 authentication algorithm is applied. 996 However, IPsec can provide replay protection only when dynamic 997 security association establishment is used. This may not always be 998 possible, and manual keying would be preferred in some cases. IPsec 999 also does not guarantee correct ordering of packets, only that they 1000 have not been replayed. Because of this, Mobile IPv6 does not rely 1001 on IPsec replay protection and provides its own mechanism inside the 1002 Binding Update and Acknowledgement messages. A sequence number field 1003 is used to ensure correct ordering and to prevent replay protection. 1004 Both the mobile node and the home agent MUST use non-volatile memory 1005 to store the sequence number so that a reboot does not prevent the 1006 acceptance of new Binding Updates. 1008 A sliding window scheme is used for the sequence numbers. Therefore 1009 the protection against replays and reordering attacks works when 1010 the attacker remembers up to a maximum of 2^31 Binding Updates. 1011 The mobile node and the home agent MAY agree on a new key for the 1012 security association before this many Binding Updates have been sent 1013 if this is an issue. 1015 Note that while the required non-volatile memory is an additional 1016 burden in particular for the mobile node, the use of sequence numbers 1017 reduces the number of roundtrips necessary for the update procedure 1018 compared to other schemes that would not have required non-volatile 1019 memory. Note also that implementations do not necessarily have to 1020 write the non-volatile memory every time they send a Binding Update, 1021 if they always write a somewhat larger sequence number to the memory 1022 and only update the memory again once the used sequence numbers go 1023 beyond this larger number. For instance, if the sequence number 1024 starts at 0, the value 100 can be written to the memory so that 1025 the next write can be done when the sequence numbers from 0 to 99 1026 have been used. This reduces the need for frequent updates to the 1027 non-volatile memory, which improves performance and may be necessary 1028 in some cases to lengthen the lifetime of the used memory components. 1030 In order to protect messages exchanged between the mobile node and 1031 the home agent with IPsec, appropriate Security Policy Database (SPD) 1032 entries must be created. We need to avoid the possibility that a 1033 mobile node could use its security association to send a Binding 1034 Update on behalf of another mobile node using the same home agent. 1035 In order to do this, the SPD entries MUST unequivocally identify a 1036 single SA for any given home address and home agent. In order for 1037 the home address of the mobile node to be visible when the policy 1038 check is made, the mobile node MUST use the Home Address Option in 1039 Binding Updates sent to the home agent. The home address in the Home 1040 Address Option and the Binding Update message MUST be equal and MUST 1041 be checked by the home agent. 1043 4.5.5. Securing Binding Updates to Correspondent Nodes 1045 Binding Updates to correspondent nodes are protected using the Return 1046 Routability (RR) method. This method uses the following principles: 1048 - A cookie exchange verifies that the mobile node is ``live'' at 1049 its addresses, or is at least able to receive traffic on them. 1051 - Protecting the eventual binding update cryptographically using 1052 the cookies. 1054 - Requiring that the cookies be protected by ESP when forwarded by 1055 the Home Agent to the mobile node. 1057 - The use of symmetric exchanges were responses are sent to the 1058 same address as the request was sent from, to avoid the use of 1059 this protocol in reflection attacks. 1061 - Stateless operation at correspondent nodes until they receive the 1062 a binding update that can be authorized. 1064 The RR protocol can be broken by an attacker on the route between the 1065 home agent and the correspondent node, but not by attackers on the 1066 network the mobile node is currently at and not from elsewhere on the 1067 Internet. 1069 Each correspondent node has a secret key, Kcn. This key does not 1070 need to be shared with any other entity, so no key distribution 1071 mechanism is needed for it. Each correspondent node also generates 1072 a nonce, Nj, at regular intervals, for example every few minutes. A 1073 correspondent node uses the same Kcn and Nj with all the mobiles it 1074 is in communication with, so that it does not need to generate and 1075 store a new Nj when a new mobile contacts it. Each value of Nj is 1076 identified by the subscript j. This subscript is communicated in the 1077 protocol, so that if Nj is replaced by N(j+1) part way through a run 1078 of a protocol, the correspondent can distinguish messages that should 1079 be checked against the old nonce from messages that should be checked 1080 against the new nonce. Correspondent nodes keep both the current 1081 value of Nj and a small set of previous values N(j-1), N(j-2), ... 1082 Older values can be discarded, and messages using them will can be 1083 rejected as replays. 1085 Kcn can be either a fixed value or regularly updated. An update 1086 of Kcn can be done at the same time as an update of Nj, so that j 1087 identifies both the nonce and the key. A correspondent node can 1088 generate a fresh Kcn each time that it boots to avoid the need for 1089 secure persistent storage for Kcn. 1091 The RR signaling happens as follows: 1093 1. MN(HoA) -> CN: HoTI(HoA) 1094 2. MN(CoA) -> CN: CoTI(CoA) 1095 3. CN -> MN(HoA): HoT(K0, j) 1096 4. CN -> MN(CoA): CoT(K1, l) 1097 5. MN(CoA) -> CN: BU(HoA, CoA, MAC, j, l) 1098 6. CN -> MN(CoA): BA(MAC) 1099 7. CN -> MN(HoA): BR(MAC) 1101 Messages 1 and 2 are sent simultaneously, as are messages 3 and 1102 4. Message 5 actually creates a binding, and messages 6 and 7 are 1103 optional. The messages are described in more detail below: 1105 1. HoTI (Home Test Init) Message: 1107 When a mobile nodes wants to perform route optimization it sends 1108 a HoTI message to the correspondent node in order to initiate the 1109 return routability verification for the Home Address. 1111 MN(HoA) -> CN: HoA 1113 This message tells the mobile node's home address to the 1114 correspondent node. The address is used later to create a 1115 cookie. This message is reverse tunneled through the Home Agent. 1117 2. CoTI (Care-of Test Init) Message: 1119 When a mobile nodes wants to perform route optimization it sends 1120 a CoTI message to the correspondent node in order to initiate the 1121 return routability verification for the care-of Address. 1123 MN(CoA) -> CN: CoA 1125 The second message is sent in parallel with the first one. It 1126 tells the correspondent node the mobile node's care-of address, 1127 which is later used to create a cookie. This message is sent 1128 directly to the correspondent node. 1130 3. HoT (Home Test) Message: 1132 This message is sent in response to a HoTI message. 1134 CN -> MN(HoA): K0, j 1136 When the correspondent node receives the HoTI message, it 1137 generates a cookie K0 as follows: 1139 K0 = MAC_Kcn(HoA | Nj | 0) 1141 The cookie and the value j are sent to the mobile node via the 1142 Home Agent; it is an assumption of the protocol that the home 1143 agent - mobile node route is secure. K0 also acts as a challenge 1144 to test that the mobile can receive messages sent to its home 1145 address. 1147 The index j is carried along in the protocol to allow the CN 1148 to later efficiently find the nonce value Nj that it used in 1149 creating this cookie. 1151 The notation used here is as follows. MAC_K(m) denotes a 1152 message authentication code computed on message m with key K. 1153 H(m) denotes a hash of message m. HMAC SHA1 function [15][21] 1154 is used to compute the message authentication code, and SHA1 1155 function [21] is used to compute the hash. The final ``0'' 1156 inside the MAC function is a 32-bit integer used to distinguish 1157 home and care-of cookies from each other. 1159 4. CoT (Care-of Test) Message: 1161 This message is sent in response to a CoTI message. 1163 CN -> MN(CoA): K1, i 1165 The correspondent also sends a challenge to the mobile's care-of 1166 address. When the correspondent node receives the CoTI message, 1167 it generates a cookie K1 as follows: 1169 K1 = MAC_Kcn(CoA | Ni | 1) 1171 The cookie and the value i are sent directly the mobile node. 1172 The final 1 inside the MAC function is a 32-bit integer, again 1173 used for distinguishing home and care-of cookies from each other. 1175 Again, an index is sent along the cookie in order to identify 1176 the used nonce Ni. Note that i and j are likely to be the same 1177 in HoT and CoT messages, except when nonce values happen to have 1178 changed between the reception of HoT and the CoT messages. 1180 5. BU (Binding Update) Message: 1182 When the MN has received both the HoT and CoT is has the cookies 1183 necessary to send the Binding Update. 1185 MN(CoA) -> CN: BU, HoA, CoA, 1186 MAC_Kbu(CoA | HoA | BU | 0), 1187 j, i 1189 The mobile node hashes together the challenges and to form a 1190 session key (Kbu), and then uses this session key to authenticate 1191 a binding update: 1193 Kbu = H(K0 | K1) 1195 The message contains j and i, so that the correspondent knows 1196 which value of Nj and Ni to use to recompute the session key. 1197 "BU" is the content of the BU message. Once the correspondent 1198 node has verified the MAC, it can create a binding cache entry 1199 for the mobile. 1201 6. BA (Binding Acknowledgement) Message: 1203 The Binding Update is optionally acknowledged by the 1204 correspondent node. 1206 CN -> MN(CoA): BA, 1207 MAC_Kbu(CoA | HoA | BA | 0), 1209 The correspondent node uses the same key (Kbu) to authenticate a 1210 binding acknowledgement. "BA" is the content of the BA message. 1212 7. BR (Binding Request) Message: 1214 The correspondent node can optionally request a binding to be 1215 refreshed using the Binding Request message. This message can be 1216 authenticated using the same Kbu that was created earlier. 1218 CN -> MN(HoA): BR, 1219 MAC_Kbu(HoA | BR | 0), 1221 "BR" is the content of the BR message. 1223 This protocol also protects the participants against replayed binding 1224 updates. The attacker can't replay the same message due to the 1225 sequence number which is a part of the MIPv6 binding update itself, 1226 and the attacker can't modify the binding update since the MAC would 1227 not verify after that. Care must be taken when removing bindings 1228 at the correspondent node, however. If a binding is removed either 1229 due to garbage collection, request, or expiration and the nonce 1230 used in its creation is still valid, an attacker can replay the old 1231 binding update. This can be prevented by having the correspondent 1232 node change the nonce often enough to ensure that the nonces used 1233 when removed entries were created are no longer valid. If many such 1234 deletions occur the correspondent can batch them together to avoid 1235 having to increment the nonce index too often. 1237 4.5.6. Preventing Denial-of-Service Attacks 1239 The RR protocol has been designed with protection against resource 1240 exhaustion Denial-of-Service attacks. In these attacks the victim 1241 has only a limited amount of some resource (such as network bandwidth 1242 or CPU cycles), and the attack consumes some of this resource. This 1243 leaves the victim without enough resources to carry out other work. 1245 The correspondent nodes do not have to retain any state about 1246 individual mobile nodes until an authentic binding update arrives. 1247 This is achieved through the use of the nonces and Kcn that are 1248 not specific to individual mobile nodes. Yet the cookies are 1249 specific, but they can be reconstructed based on the CoA and HoA 1250 information that arrives with the binding update. This means that 1251 the correspondent nodes are safe against memory exhaustion attacks 1252 except where on-path attackers are concerned. Due to the use of 1253 symmetric cryptography, the correspondent nodes are relatively safe 1254 against CPU resource exhaustion attacks as well. 1256 Nevertheless, as [1] describes, there are situations it is impossible 1257 for the mobile and correspondent nodes to determine if they actually 1258 need a binding or whether they just have been fooled into believing 1259 so by an attacker. Therefore, it is necessary to treat situations 1260 where such attacks are being made. 1262 The binding updates that are used in mobile IPv6 are only an 1263 optimization. A mobile node can communicate with a correspondent 1264 node even if the correspondent refuses to accept any of its binding 1265 updates. However, performance will suffer because packets from the 1266 correspondent to the mobile will be routed via the mobile's home 1267 agent rather than a more direct route. A correspondent can protect 1268 itself against some of the resource exhaustion attacks by stopping 1269 processing binding updates when it is flooded with a large number of 1270 binding updates that fail the cryptographic integrity checks. If a 1271 correspondent finds that it is spending more resources on checking 1272 bogus binding updates than it is likely to save by accepting genuine 1273 binding updates, then it can decide to reject all binding updates 1274 without performing any cryptographic operations. 1276 Additional information needed to make this decisions about responding 1277 to requests will usually originate in layers above IP. For example, 1278 TCP knows if the node has a queue of data that it is trying to send 1279 to a peer. It is possible to produce a conforming implementation of 1280 the protocols in this memo without making use of information from 1281 higher protocol layers, but implementations MAY be able to manage 1282 resources more effectively by making use of such information. 1284 4.5.7. Design Rationale 1286 The motivation for designing the RR protocol was to have sufficient 1287 support for mobile IP, without creating major new security problems. 1288 A protocol was needed against the new vulnerabilities introduced by 1289 IP mobility. It was not our goal to protect against attacks that 1290 were already possible before the introduction of IP mobility. This 1291 protocol does not defend against an attacker who can monitor the home 1292 agent to correspondent node path, as such attackers would in any case 1293 be able to mount an active attack against the mobile node when it 1294 is at its home location. The possibility of such attacks is not an 1295 impediment to the deployment of mobile IP, because these attacks are 1296 possible irrespective of whether mobile IP is in use or not. 1298 This protocol also protects against denial of service attacks in 1299 which the attacker pretends to be a mobile, but uses the victim's 1300 address as the care of address, and so causes the correspondent 1301 to send the victim traffic that it does not want. For example, 1302 suppose that the correspondent is a news site that will send a 1303 high-bandwidth stream of video to anyone who asks for it. Note that 1304 the use of flow-control protocols such as TCP does not necessarily 1305 defend against this type of attack, because the attacker can fake the 1306 acknowledgements. Even keeping TCP initial sequence numbers secret 1307 doesn't help, because the attacker can receive the first few segments 1308 (including the ISN) at its own address, and then redirect the stream 1309 to the victim's address. This protocol defends against these attacks 1310 by only completing if packets sent by the correspondent to the care 1311 of address are received and processed by an entity that is willing to 1312 participate in the protocol. Normally, this will be the mobile node. 1314 For further information about the design of RR and other protocols, 1315 see [1] [33] [22] [23]. 1317 4.6. New IPv6 ICMP Messages 1319 Mobile IPv6 also introduces four new ICMP message types, two for use 1320 in the dynamic home agent address discovery mechanism, and two for 1321 renumbering and mobile configuration mechanisms. As discussed in 1322 general in Section 4.2, the following two new ICMP message types are 1323 used for home agent address discovery: 1325 Home Agent Address Discovery Request 1327 The ICMP Home Agent Address Discovery Request message is used 1328 by a mobile node to initiate the dynamic home agent address 1329 discovery mechanism. When attempting a home registration, the 1330 mobile node may use this mechanism to discover the address of 1331 one or more routers currently operating as home agents on its 1332 home link, with which it may register while away from home. 1333 The Home Agent Address Discovery Request message is described 1334 in detail in Section 5.6. 1336 Home Agent Address Discovery Reply 1338 The ICMP Home Agent Address Discovery Reply message is used by 1339 a home agent to respond to a mobile node using the dynamic home 1340 agent address discovery mechanism. When a home agent receives 1341 a Home Agent Address Discovery Request message, it replies with 1342 a Home Agent Address Discovery Reply message, giving a list 1343 of the routers on the mobile node's home link serving as home 1344 agents. The Home Agent Address Discovery Reply message is 1345 described in detail in Section 5.7. 1347 The next two message types are used for network renumbering 1348 and address configuration on the mobile node, as described in 1349 Section 9.7: 1351 Mobile Prefix Solicitation 1353 The ICMP Mobile Prefix Solicitation message is used by a mobile 1354 node to request prefix information about the home subnet, in 1355 order to retrieve prefixes that are served by home agents and 1356 can be used to configure one or more home addresses, or to 1357 refresh home addresses before the expiration of their validity. 1358 This message is specified in Section 5.8. 1360 Mobile Prefix Advertisement 1362 The ICMP Mobile Prefix Advertisement is used by a home agent to 1363 distribute information to a mobile node about prefixes on the 1364 home link which are available for use by the mobile node while 1365 away from home. This message may be sent as a response to a 1366 Mobile Prefix Solicitation, or due to network renumbering or 1367 other prefix changes as specified in Section 9.9.3 1369 4.7. Conceptual Data Structures 1371 This document describes the Mobile IPv6 protocol in terms of the 1372 following three conceptual data structures: 1374 Binding Cache 1376 A cache, maintained by each IPv6 node, of bindings for other 1377 nodes. A separate Binding Cache SHOULD be maintained by each 1378 IPv6 node for each of its IPv6 addresses. The Binding Cache 1379 MAY be implemented in any manner consistent with the external 1380 behavior described in this document, for example by being 1381 combined with the node's Destination Cache as maintained by 1382 Neighbor Discovery [20]. When sending a packet, the Binding 1383 Cache is searched before the Neighbor Discovery conceptual 1384 Destination Cache [20] (i.e., any Binding Cache entry for this 1385 destination SHOULD take precedence over any Destination Cache 1386 entry for the same destination). Each Binding Cache entry 1387 conceptually contains the following fields: 1389 - The home address of the mobile node for which this is the 1390 Binding Cache entry. This field is used as the key for 1391 searching the Binding Cache for the destination address of 1392 a packet being sent. If the destination address of the 1393 packet matches the home address in the Binding Cache entry, 1394 this entry SHOULD be used in routing that packet. 1396 - The care-of address for the mobile node indicated by 1397 the home address field in this Binding Cache entry. If 1398 the destination address of a packet being routed by a 1399 node matches the home address in this entry, the packet 1400 SHOULD be routed to this care-of address, as described in 1401 Section 8.9, for packets originated by this node, or in 1402 Section 9.4, if this node is the mobile node's home agent 1403 and the packet was intercepted by it on the home link. 1405 - A lifetime value, indicating the remaining lifetime 1406 for this Binding Cache entry. The lifetime value is 1407 initialized from the Lifetime field in the Binding Update 1408 that created or last modified this Binding Cache entry. 1409 Once the lifetime on this entry expires, the entry MUST be 1410 deleted from the Binding Cache. 1412 - A flag indicating whether or not this Binding Cache entry 1413 is a "home registration" entry. 1415 - A flag indicating whether or not this Binding Cache entry 1416 represents a mobile node that should be advertised as a 1417 router in proxy Neighbor Advertisements sent by this node 1418 on its behalf. This flag is only valid if the Binding 1419 Cache entry indicates that this is a "home registration" 1420 entry. 1422 - The length of the routing prefix for the home address. 1423 This field is only valid if the "home registration" flag is 1424 set on this Binding Cache entry. 1426 - The maximum value of the Sequence Number field received 1427 in previous Binding Updates for this mobile node home 1428 address. The Sequence Number field is 8 bits long, 1429 and all comparisons between Sequence Number values 1430 MUST be performed modulo 2**8. For example, using an 1431 implementation in the C programming language, a Sequence 1432 Number value A is greater than another Sequence Number 1433 value B if ((char)((a) - (b)) > 0), if the "int" data type 1434 is a 8-bit signed integer. 1436 - Recent usage information for this Binding Cache entry, as 1437 needed to implement the cache replacement policy in use in 1438 the Binding Cache and to assist in determining whether a 1439 Binding Request should be sent when the lifetime on this 1440 entry nears expiration. 1442 - The Binding Security Association (BSA) to be be used when 1443 authenticating Binding Updates that are received for this 1444 Binding Cache entry. 1446 - The Binding Security Association (BSA) to be be used when 1447 calculating authentication data for inclusion in Binding 1448 Acknowledgements in response to Binding Updates that are 1449 received for this Binding Cache entry. 1451 An entry in a node's Binding Cache for which the node is 1452 serving as a home agent is marked as a "home registration" 1453 entry and SHOULD NOT be deleted by the home agent until the 1454 expiration of its binding lifetime. Other Binding Cache 1455 entries MAY be replaced at any time by any reasonable local 1456 cache replacement policy but SHOULD NOT be unnecessarily 1457 deleted. The Binding Cache for any one of a node's IPv6 1458 addresses may contain at most one entry for each mobile node 1459 home address. The contents of a node's Binding Cache MUST NOT 1460 be changed in response to a Home Address option in a received 1461 packet. The contents of all of a node's Binding Cache entries, 1462 for each of its IPv6 addresses, must be cleared when the node 1463 reboots. 1465 Binding Update List 1467 A list, maintained by each mobile node, recording information 1468 for each Binding Update sent by this mobile node, for which the 1469 Lifetime sent in that Binding Update has not yet expired. The 1470 Binding Update List includes all bindings sent by the mobile 1471 node: those to correspondent nodes, those to the mobile node's 1472 home agent, and those to a home agent on the link on which the 1473 mobile node's previous care-of address is located. However, 1474 for multiple Binding Updates sent to the same destination 1475 address, the Binding Update List contains only the most recent 1476 Binding Update (i.e., with the greatest Sequence Number value) 1477 sent to that destination. The Binding Update List MAY be 1478 implemented in any manner consistent with the external behavior 1479 described in this document. Each Binding Update List entry 1480 conceptually contains the following fields: 1482 - The IP address of the node to which a Binding Update was 1483 sent. That node might still have a Binding Cache entry 1484 created or updated from this Binding Update, if the Binding 1485 Update was successfully received by that node (e.g., not 1486 lost by the network) and if that node has not deleted the 1487 entry before its expiration (e.g., to reclaim space in its 1488 Binding Cache for other entries). 1490 - The home address for which that Binding Update was sent. 1491 This will be one of the following: 1493 * the mobile node's home addresses for typical Binding 1494 Updates (Sections 10.7 and 10.9), or 1496 * the mobile node's previous care-of address for Binding 1497 Updates sent to establish forwarding from the mobile 1498 node's previous care-of address by a home agent from 1499 this previous care-of address (Section 10.11). 1501 - The care-of address sent in that Binding Update. This 1502 value is necessary for the mobile node to determine if it 1503 has sent a Binding Update giving its new care-of address to 1504 this destination after changing its care-of address. 1506 - The initial value of the Lifetime field sent in that 1507 Binding Update. 1509 - The remaining lifetime of that binding. This lifetime is 1510 initialized from the Lifetime value sent in the Binding 1511 Update and is decremented until it reaches zero, at which 1512 time this entry MUST be deleted from the Binding Update 1513 List. 1515 - The maximum value of the Sequence Number field sent in 1516 previous Binding Updates to this destination. The Sequence 1517 Number field is 8 bits long, and all comparisons between 1518 Sequence Number values MUST be performed modulo 2**8. For 1519 example, using an implementation in the C programming 1520 language, a Sequence Number value A is greater than another 1521 Sequence Number value B if ((char)((a) - (b)) > 0), if the 1522 "char" data type is a 8-bit signed integer. 1524 - The time at which a Binding Update was last sent to this 1525 destination, as needed to implement the rate limiting 1526 restriction for sending Binding Updates. 1528 - The state of any retransmissions needed for this Binding 1529 Update, if the Acknowledge (A) bit was set in this Binding 1530 Update. This state includes the time remaining until the 1531 next retransmission attempt for the Binding Update, and the 1532 current state of the exponential back-off mechanism for 1533 retransmissions. 1535 - A flag that, when set, indicates that future Binding 1536 Updates should not be sent to this destination. The 1537 mobile node sets this flag in the Binding Update List 1538 entry when it receives an ICMP Parameter Problem, Code 2, 1539 error message in response to a Binding Update sent to that 1540 destination, as described in Section 10.17. 1542 Home Agents List 1544 A list, maintained by each home agent and each mobile node, 1545 recording information about each home agent from which this 1546 node has received a Router Advertisement in which the Home 1547 Agent (H) bit is set, for which the remaining lifetime for 1548 this list entry (defined below) has not yet expired. The 1549 home agents list is thus similar to the Default Router 1550 List conceptual data structure maintained by each host for 1551 Neighbor Discovery [20], although the Home Agents List MAY be 1552 implemented in any manner consistent with the external behavior 1553 described in this document. 1555 Each home agent maintains a separate Home Agents List for 1556 each link on which it is serving as a home agent; this list 1557 is used by a home agent in the dynamic home agent address 1558 discovery mechanism. Each mobile node, while away from home, 1559 also maintains a Home Agents List, to enable it to notify a 1560 home agent on its previous link when it moves to a new link; a 1561 mobile node MAY maintain a separate Home Agents List for each 1562 link to which it is (or has recently) connected, or it MAY 1563 maintain a single list for all links. Each Home Agents List 1564 entry conceptually contains the following fields: 1566 - The link-local IP address of a router on the link, that 1567 this node currently believes is operating as a home agent 1568 for that link. A new entry is created or an existing 1569 entry is updated in the Home Agents List in response to 1570 receipt of a valid Router Advertisement in which the Home 1571 Agent (H) bit is set. The link-local address of the home 1572 agent is learned through the Source Address of the Router 1573 Advertisements received from it [20]. 1575 - One or more global IP addresses for this home agent, 1576 learned through Prefix Information options with 1577 the Router Address (R) bit set, received in Router 1578 Advertisements from this link-local address. Global 1579 addresses for the router in a Home Agents List entry MUST 1580 be deleted once the prefix associated with that address is 1581 no longer valid [20]. 1583 Are there interactions with the new Router 1584 Advertisement stuff? 1586 - The remaining lifetime of this Home Agents List entry. If 1587 a Home Agent Information Option is present in a Router 1588 Advertisement received from a home agent, the lifetime of 1589 the Home Agents List entry representing that home agent 1590 is initialized from the Home Agent Lifetime field in the 1591 option; otherwise, the lifetime is initialized from the 1592 Router Lifetime field in the received Router Advertisement. 1593 The Home Agents List entry lifetime is decremented until it 1594 reaches zero, at which time this entry MUST be deleted from 1595 the Home Agents List. 1597 - The preference for this home agent; higher values 1598 indicate a more preferable home agent. The preference 1599 value is taken from the Home Agent Preference field (a 1600 signed, twos-complement integer) in the received Router 1601 Advertisement, if the Router Advertisement contains a Home 1602 Agent Information Option, and is otherwise set to the 1603 default value of 0. A home agent uses this preference in 1604 ordering the Home Agents List returned in an ICMP Home 1605 Agent Address Discovery message in response to a mobile 1606 node's initiation of dynamic home agent address discovery. 1607 A mobile node uses this preference in determining which 1608 of the home agents on its previous link to notify when it 1609 moves to a new link. 1611 Can we delete the preference stuff? Is anyone using 1612 it? 1614 4.8. Binding Management 1616 When a mobile node configures a new care-of address and decides to 1617 use this new address as its primary care-of address, the mobile 1618 node registers this new binding with its home agent by sending 1619 the home agent a Binding Update. The mobile node indicates 1620 that an acknowledgement is needed for this Binding Update and 1621 continues to periodically retransmit it until acknowledged. The 1622 home agent acknowledges the Binding Update by returning a Binding 1623 Acknowledgement to the mobile node. 1625 When a mobile node receives a packet tunneled to it from its home 1626 agent, the mobile node uses that as an indication that the original 1627 sending correspondent node has no Binding Cache entry for the mobile 1628 node, since the correspondent node would otherwise have sent the 1629 packet directly to the mobile node using a Routing header. If the 1630 mobile node has a Binding Security Association (BSA) with that 1631 correspondent node, the mobile node thus returns a Binding Update 1632 to the correspondent node, allowing it to cache the mobile node's 1633 binding for routing future packets to it. Although the mobile node 1634 may request an acknowledgement for this Binding Update, it need not, 1635 since subsequent packets from the correspondent node will continue 1636 to be intercepted and tunneled by the mobile node's home agent, 1637 effectively causing any needed Binding Update retransmission. 1639 If the mobile node receives such a tunneled packet but does not have 1640 a BSA with the correspondent node, the mobile node SHOULD initiate 1641 the process of establishing the necessary security association by 1642 following the procedures outlined in Section 4.5 1644 A correspondent node with a Binding Cache entry for a mobile node 1645 may refresh this binding, for example if the binding's lifetime 1646 is near expiration, by sending a Binding Request to the mobile 1647 node. Normally, a correspondent node will only refresh a Binding 1648 Cache entry in this way if it is actively communicating with the 1649 mobile node and has indications, such as an open TCP connection to 1650 the mobile node, that it will continue this communication in the 1651 future. When a mobile node receives a Binding Request, it replies by 1652 returning a Binding Update to the node sending the Binding Request. 1654 A mobile node may use more than one care-of address at the same time, 1655 although only one care-of address may be registered for it at its 1656 home agent as its primary care-of address. The mobile node's home 1657 agent will tunnel all intercepted packets for the mobile node to its 1658 (single) registered primary care-of address, but the mobile node 1659 will accept packets that it receives at any of its current care-of 1660 addresses. Use of more than one care-of address by a mobile node 1661 may be useful, for example, to improve smooth handover when the 1662 mobile node moves from one wireless link to another. If each of 1663 these wireless links is connected to the Internet through a separate 1664 base station, such that the wireless transmission range from the 1665 two base stations overlap, the mobile node may be able to remain 1666 connected to both links while in the area of overlap. In this case, 1667 the mobile node could acquire a new care-of address on the new link 1668 before moving out of transmission range and disconnecting from the 1669 old link. The mobile node may thus still accept packets at its 1670 old care-of address while it works to update its home agent and 1671 correspondent nodes, notifying them of its new care-of address on the 1672 new link. 1674 Since correspondent nodes cache bindings, it is expected that 1675 correspondent nodes usually will route packets directly to the mobile 1676 node's care-of address, so that the home agent is rarely involved 1677 with packet transmission to the mobile node. This is essential for 1678 scalability and reliability, and for minimizing overall network load. 1679 By caching the care-of address of a mobile node, optimal routing of 1680 packets can be achieved from the correspondent node to the mobile 1681 node. Routing packets directly to the mobile node's care-of address 1682 also eliminates congestion at the mobile node's home agent and home 1683 link. In addition, the impact of any possible failure of the home 1684 agent, the home link, or intervening networks leading to or from the 1685 home link is reduced, since these nodes and links are not involved in 1686 the delivery of most packets to the mobile node. 1688 5. New IPv6 Destination Options and Message Types 1690 5.1. Mobility Header 1692 The Mobility Header is used by mobile nodes, correspondent nodes, and 1693 home agents in all messaging related to the creation and management 1694 of bindings. The Mobility Header is an IPv6 protocol. Rules 1695 regarding how it is sent and what addresses are used in the IPv6 1696 header are given separately in Sections 5.1.2 to 5.1.9. Mobile nodes 1697 MUST use reverse tunneling to send Mobility Header messages when the 1698 source address is set to the home address of the mobile node. 1700 5.1.1. Format 1702 The Mobility Header is identified by a Next Header value of 62 (XXX) 1703 in the immediately preceding header, and has the following format: 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 |Payload Proto | Header Len | MH Type | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Checksum | | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1710 | | 1711 . . 1712 . Message Data . 1713 . . 1714 | | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 Payload Proto 1719 8-bit selector. Identifies the type of header immediately 1720 following the Mobility Header. Uses the same values as the 1721 IPv4 Protocol field [10]. 1723 This field is intended to be used by a future specification 1724 of piggybacking binding messages on payload packets (see 1725 Section 12.1). 1727 Thus implementations conforming to this specification MUST set 1728 the payload protocol type to NO_NXTHDR (59 decimal). 1730 Header Len 1732 8-bit unsigned integer. Length of the Mobility Header in units 1733 of 8 octets, including the the Payload Proto, MH Type, Header 1734 Len, Checksum, and Message Data fields. 1736 MH Type 1738 16-bit selector. Identifies the particular mobility message in 1739 question. Legal values are defined in Sections 5.1.2 to 5.1.8. 1740 An unrecognized MH Type field SHOULD cause an error to be sent 1741 to the source. 1743 Checksum 1745 16-bit unsigned integer. This field contains the checksum 1746 of the Mobility Header. The checksum is the 16-bit one's 1747 complement of the one's complement sum of the entire Mobility 1748 Header starting with the Payload Proto field, prepended with a 1749 "pseudo-header" of IPv6 header fields, as specified in [IPv6, 1750 section 8.1]. The Next Header value used in the pseudo-header 1751 is 62 (XXX). For computing the checksum, the checksum field is 1752 set to zero. 1754 Message Data 1756 A variable length field containing the data specific to the 1757 indicated Mobility Header type. 1759 5.1.2. Binding Request (BR) Message 1761 The Binding Request (BR) message is used to request a mobile node's 1762 binding from the mobile node. A packet containing a Binding Request 1763 message is sent in the same way as any packet to a mobile node 1764 (Section 8.9). When a mobile node receives a packet containing a 1765 Binding Request message and there already exists a Binding Update 1766 List entry for the source of the Binding Request, it MAY start 1767 a Return Routability Procedure (see Section 4.5) if it believes 1768 the amount of traffic with the correspondent justifies the use of 1769 Route Optimization. Note that the mobile node SHOULD NOT respond 1770 Binding Requests from previously unknown correspondent nodes due to 1771 Denial-of-Service concerns. 1773 The Binding Request message uses the MH Type value 0. When this 1774 value is indicated in the MH Type field, the format of the Message 1775 Data field in the Mobility Header is as follows: 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Reserved | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | | 1781 . . 1782 . Parameters . 1783 . . 1784 | | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 Reserved 1789 16-bit field reserved for future flags. These flag bits are 1790 reserved for future use, and MUST be initialized to zero by the 1791 sender, and MUST be ignored by the receiver. 1793 Parameters 1795 Variable-length field, of length such that the complete 1796 Mobility Header is an integer multiple of 8 octets long. 1797 Contains one or more TLV-encoded parameters. The receiver MUST 1798 ignore and skip any parameters which it does not understand. A 1799 Binding Request MUST include the following parameter: 1801 - Authentication Data parameter. This parameter contains a 1802 cryptographic hash value which is used to ensure that it 1803 has been sent by the correspondent node. The authenticator 1804 covering a Binding Acknowledgement MUST be computed over 1805 a bitstring containing the following fields of the IPv6 1806 header and the Mobility Header, in order: 1808 * The Home Address of the mobile node, from the 1809 Destination Address field of the IPv6 header. 1811 * The address of the correspondent node, from the Source 1812 Address field of the IPv6 header. 1814 * The contents of the Mobility Header, excluding the 1815 Authenticator field (inside the Authentication Data 1816 parameter) which is included as zeroes for the purposes 1817 of calculating the Authenticator. 1819 * Four bytes of zero. This is included for a potential 1820 future extension. 1822 The actual authenticator calculation over sequence of bits 1823 is described in Section 4.5. 1825 There MAY be additional information, associated with this 1826 Binding Request message, that need not be present in all 1827 Binding Requests sent. This use of MH parameters also allows 1828 for future extensions to the format of the Binding Request 1829 message to be defined. The encoding and format of defined 1830 parameters are described in Section 5.2. The following 1831 parameters are valid in a Binding Request message: 1833 - Unique Identifier Parameter 1835 If no actual parameters are present in this message, no padding is 1836 necessary. 1838 5.1.3. Home Test Init (HoTI) Message 1840 The Home Test Init (HoTI) message is used to initiate the Return 1841 Routability procedure from the mobile node to a correspondent node 1842 (see Section 10.9). This message is always sent with the Source 1843 Address set to the home address of the mobile node, Destination 1844 Address set to the correspondent node's address, and is tunneled 1845 through the home agent when the mobile node is away from home. 1847 The HoTI message uses the MH Type value 1. When this value is 1848 indicated in the MH Type field, the format of the Message Data field 1849 in the Mobility Header is as follows: 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | Flags | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | | 1855 . . 1856 . Parameters . 1857 . . 1858 | | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 Flags 1863 16-bit field reserved for future flags. These flag bits are 1864 reserved for future use, and MUST be initialized to zero by the 1865 sender, and MUST be ignored by the receiver. 1867 Parameters 1869 Variable-length field, of length such that the complete 1870 Mobility Header is an integer multiple of 8 octets long. 1871 Contains one or more TLV-encoded parameters. The receiver MUST 1872 ignore and skip any parameters which it does not understand. 1874 There MAY be additional information, associated with this 1875 message that need not be present in all HoTI messages. This 1876 use of MH parameters also allows for future extensions to the 1877 format of the HoTI message to be defined. The encoding and 1878 format of defined parameters are described in Section 5.2. The 1879 following parameters are valid in a HoTI message: 1881 - Unique Identifier Parameter 1883 If no actual parameters are present in this message, 4 bytes of Pad1 1884 or PadN parameters are needed to make the length of the message a 1885 multiple of 8. 1887 The HoTI message SHOULD be protected by an IPsec policy that employs 1888 ESP between the home agent and the mobile node. 1890 A packet that includes a HoTI message MUST NOT include a Home Address 1891 option. 1893 5.1.4. Care-of Test Init (CoTI) Message 1895 The Care-of Test Init (CoTI) message is used to initiate the Return 1896 Routability procedure from the mobile node to a correspondent node 1897 (see Section 10.9). This message is always sent with the Source 1898 Address set to the care-of address of the mobile node, and is sent 1899 directly to the correspondent node. 1901 The CoTI message uses the MH Type value 2. When this value is 1902 indicated in the MH Type field, the format of the Message Data field 1903 in the Mobility Header is as follows: 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Reserved | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | | 1909 . . 1910 . Parameters . 1911 . . 1912 | | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 Reserved 1917 16-bit field reserved for future flags. These flag bits are 1918 reserved for future use, and MUST be initialized to zero by the 1919 sender, and MUST be ignored by the receiver. 1921 Parameters 1923 Variable-length field, of length such that the complete 1924 Mobility Header is an integer multiple of 8 octets long. 1925 Contains one or more TLV-encoded parameters. The receiver MUST 1926 ignore and skip any parameters which it does not understand. 1928 There MAY be additional information, associated with this 1929 message that need not be present in all CoTI messages. This 1930 use of MH parameters also allows for future extensions to the 1931 format of the CoTI message to be defined. The encoding and 1932 format of defined parameters are described in Section 5.2. The 1933 following parameters are valid in a CoTI message: 1935 - Unique Identifier Parameter 1937 If no actual parameters are present in this message, no padding is 1938 necessary. 1940 A packet that includes a CoTI message MUST NOT include a Home Address 1941 option. 1943 5.1.5. Home Test (HoT) Message 1945 The Home Test (HoT) message is an answer to the HoTI message, and 1946 is sent from the correspondent node to the mobile node (see Section 1947 8.2). This message is always sent with the Destination Address set 1948 to the home address of the mobile node, Source Address set to the 1949 address of the correspondent node, and is tunneled through the home 1950 agent when the mobile node is away from home. 1952 The HoT message uses the MH Type value 3. When this value is 1953 indicated in the MH Type field, the format of the Message Data field 1954 in the Mobility Header is as follows: 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Reserved | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1959 | Home Nonce Index | | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | | 1962 + + 1963 | Home Cookie (128 bits) | 1964 + + 1965 | | 1966 + + 1967 | | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | | 1970 . . 1971 . Parameters . 1972 . . 1973 | | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 Reserved 1978 32-bit field reserved for future flags. These flag bits are 1979 reserved for future use, and MUST be set to zero, otherwise an 1980 error MUST be returned to the sender. 1982 Home Nonce Index 1984 This field will be echoed back by the mobile node to the 1985 correspondent node in a subsequent binding update. It 1986 will allow the correspondent node to select the appropriate 1987 challenge values to authenticate the binding update. 1989 Home Cookie 1991 This field contains the cookie K0 in the Return Routability 1992 Procedure; it is the first of two cookies which are to be 1993 processed to form a key which is then used to authenticate a 1994 binding update. 1996 Parameters 1998 Variable-length field, of length such that the complete 1999 Mobility Header is an integer multiple of 8 octets long. 2000 Contains one or more TLV-encoded parameters. The receiver MUST 2001 ignore and skip any parameters which it does not understand. 2003 There MAY be additional information, associated with this 2004 message that need not be present in all HoT messages. MH 2005 parameters are used to carry that information. The encoding 2006 and format of defined parameters are described in Section 5.2. 2007 This use of MH parameters also allows for future extensions 2008 to the format of the HoT message to be defined. This 2009 specification does not define any optional parameters for the 2010 HoT message. 2012 If no actual parameters are present in this message, 4 bytes of Pad1 2013 or PadN parameters are needed to make the length of the message a 2014 multiple of 8. 2016 The HoT message SHOULD be protected by an IPsec policy that employs 2017 ESP between the home agent and the mobile node, in order to prevent 2018 attackets e.g. on the same link as the MN to receive the Home 2019 Cookie. 2021 5.1.6. Care-of Test (CoT) Message 2023 The Care-of Test (CoT) message is an answer to the CoTI message, and 2024 is sent from the correspondent node to the mobile node (see Section 2025 8.2). This message is always sent with the Source Address set to the 2026 address of the correspondent node, the Destination Address set to 2027 the care-of address of the mobile node, and is sent directly to the 2028 mobile node. 2030 The CoT message uses the MH Type value 4. When this value is 2031 indicated in the MH Type field, the format of the Message Data field 2032 in the Mobility Header is as follows: 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Reserved | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2037 | Care-of Nonce Index | | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | | 2040 + + 2041 | Care-of Cookie (128 bits) | 2042 + + 2043 | | 2044 + + 2045 | | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | | 2048 . . 2049 . Parameters . 2050 . . 2051 | | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 Reserved 2056 32-bit field reserved for future flags. These flag bits are 2057 reserved for future use, and MUST be set to zero, otherwise an 2058 error MUST be returned to the sender. 2060 Care-of Nonce Index 2062 This field will be echoed back by the mobile node to the 2063 correspondent node in a subsequent binding update. It 2064 will allow the correspondent node to select the appropriate 2065 challenge values to authenticate the binding update. 2067 Care-of Cookie 2069 This field contains the cookie K1 in the Return Routability 2070 Procedure; it is the second of two cookies which are to be 2071 processed to form a key which is then used to authenticate a 2072 binding update. 2074 Parameters 2076 Variable-length field, of length such that the complete 2077 Mobility Header is an integer multiple of 8 octets long. 2078 Contains one or more TLV-encoded parameters. The receiver MUST 2079 ignore and skip any parameters which it does not understand. 2081 There MAY be additional information, associated with this 2082 message that need not be present in all CoT messages. MH 2083 parameters are used to carry that information. The encoding 2084 and format of defined parameters are described in Section 5.2. 2085 This use of MH parameters also allows for future extensions 2086 to the format of the CoT message to be defined. This 2087 specification does not define any optional parameters for the 2088 CoT message. 2090 If no actual parameters are present in this message, 4 bytes of Pad1 2091 or PadN parameters are needed to make the length of the message a 2092 multiple of 8. 2094 5.1.7. Binding Update (BU) Message 2096 The Binding Update (BU) message is used by a mobile node to notify 2097 other nodes of a new care-of address for itself. A packet containing 2098 a Binding Update message is sent with the Source Address set to the 2099 care-of address of the mobile node and the Destination Address set to 2100 the correspondent node's address. 2102 The Binding Update message uses the MH Type value 5. When this value 2103 is indicated in the MH Type field, the format of the Message Data 2104 field in the Mobility Header is as follows: 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 |A|H|S|D| Reserved | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Sequence # | Reserved | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Lifetime | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | | 2114 + + 2115 | | 2116 + Home Address + 2117 | | 2118 + + 2119 | | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | | 2122 . . 2123 . Parameters . 2124 . . 2125 | | 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 Acknowledge (A) 2129 The Acknowledge (A) bit is set by the sending mobile node to 2130 request a Binding Acknowledgement (Section 5.1.8) be returned 2131 upon receipt of the Binding Update. 2133 Home Registration (H) 2135 The Home Registration (H) bit is set by the sending mobile node 2136 to request the receiving node to act as this node's home agent. 2137 The destination of the packet carrying this message MUST be 2138 that of a router sharing the same subnet prefix as the home 2139 address of the mobile node in the binding (given by the Home 2140 Address field in the Home Address option in the packet). 2142 Single Address Only (S) 2144 If the `S' bit is set, the mobile node requests that the home 2145 agent make no changes to any other Binding Cache entry except 2146 for the particular one containing the home address specified in 2147 the Home Address option. This disables home agent processing 2148 for other related addresses, as is described in Section 9.1. 2150 Duplicate Address Detection (D) 2152 The Duplicate Address Detection (D) bit is set by the sending 2153 mobile node to request the receiving node (the mobile node's 2154 home agent) to perform Duplicate Address Detection [35] on 2155 the mobile node's home link for the home address in this 2156 binding. This bit is only valid when the Home Registration (H) 2157 and Acknowledge (A) bits are also set, and MUST NOT be set 2158 otherwise. If the Duplicate Address Detection performed by 2159 the home agent fails, the Status field in the returned Binding 2160 Acknowledgement will be set to 138 (Duplicate Address Detection 2161 failed). 2163 Reserved 2165 This field is unused. It MUST be initialized to zero by the 2166 sender and MUST be ignored by the receiver. 2168 Sequence # 2170 A 16-bit number used by the receiving node to sequence Binding 2171 Updates and by the sending node to match a returned Binding 2172 Acknowledgement with this Binding Update. Each Binding Update 2173 sent by a mobile node MUST use a Sequence Number greater than 2174 the Sequence Number value sent in the previous Binding Update 2175 (if any) to the same destination address (modulo 2**16, as 2176 defined in Section 4.7). There is no requirement, however, 2177 that the Sequence Number value strictly increase by 1 with each 2178 new Binding Update sent or received. Both home agents and 2179 correspondent nodes use the sequence number also to prevent 2180 replay attacks. 2182 Lifetime 2184 32-bit unsigned integer. The number of seconds remaining 2185 before the binding MUST be considered expired. A value of all 2186 one bits (0xffffffff) indicates infinity. A value of zero 2187 indicates that the Binding Cache entry for the mobile node MUST 2188 be deleted. 2190 Home Address 2192 This field tells the correspondent node the home address of the 2193 mobile node. 2195 Parameters 2197 Variable-length field, of length such that the complete 2198 Mobility Header is an integer multiple of 8 octets long. 2199 Contains one or more TLV-encoded parameters. The receiver MUST 2200 ignore and skip any parameters which it does not understand. A 2201 Binding Update sent to a correspondent node MUST include the 2202 following parameters: 2204 - Nonce Indices parameter. This parameter contains 2205 information the correspondent node needs in order to find 2206 the challenge values Nj and Ni. 2208 - Authentication Data parameter. This parameter contains a 2209 cryptographic hash value which is used to ensure that it 2210 has been sent by the same party who received the HoT and 2211 CoT messages. The authenticator covering a Binding Update 2212 MUST be computed over a bitstring containing the following 2213 fields of the IPv6 header and the Mobility Header, in 2214 order: 2216 * Care-of Address, in the Source Address field of the 2217 IPv6 header 2219 * The address of the correspondent node, in the 2220 Destination Address field of the IPv6 header. 2222 * The contents of the Mobility Header, excluding the 2223 Authenticator field (within the Authentication Data 2224 parameter) which is included as zeroes for the purposes 2225 of calculating the Authenticator. Parameters of the 2226 Mobility Header are included in the calculation. 2228 * Four bytes of zero. 2230 The actual authenticator calculation over sequence of bits 2231 is described in Section 4.5. 2233 There MAY be additional information, associated with this 2234 Binding Update message, that need not be present in all Binding 2235 Updates sent. This use of MH parameters also allows for future 2236 extensions to the format of the Binding Update message to be 2237 defined. The encoding and format of defined parameters are 2238 described in Section 5.2. The following parameters are valid 2239 in a Binding Update message: 2241 - Unique Identifier Parameter 2243 - Alternate Care-of Address Parameter 2245 If no actual parameters are present in this message, 4 bytes of Pad1 2246 or PadN parameters are needed to make the length of the message a 2247 multiple of 8. 2249 A Binding Update message to the correspondent node MUST NOT include 2250 the Home Address option in order to avoid reflection attacks 2251 described in Section 4.5. A Binding Update to the home agent MUST 2252 include the Home Address option in order to allow for the use of 2253 manually keyed IPsec in the protection of these messages. 2255 When a packet contains both a Home Address Option and a Binding 2256 Update message, the sender MUST use the same address in both. The 2257 receiver MUST check for the equal values and MUST silently discard a 2258 packet that does not pass this test. 2260 The home address of the mobile node in the binding given in the 2261 Binding Update message is that which was received as the value of the 2262 Home Address field in the Home Address option in the packet. 2264 The care-of address for the binding given in the Binding Update 2265 message is normally that which was received as the value in the 2266 Source Address field in the IPv6 header of the packet carrying the 2267 Binding Update message. However, a care-of address different from 2268 the Source Address MAY be specified by including an Alternate Care-of 2269 Address parameter in the Binding Update message. In any case, the 2270 care-of address MUST NOT be any IPv6 address which is prohibited 2271 for use within a Routing Header; thus multicast addresses, the 2272 unspecified address, loop-back address, and link-local addresses 2273 are excluded. Binding Updates indicating any such excluded care-of 2274 address MUST be silently discarded. 2276 If the care-of address for the binding (specified either in an 2277 Alternate Care-of Address parameter in the Binding Update message, if 2278 present, or in the Source Address field in the packet's IPv6 header) 2279 is equal to the home address of the mobile node, the Binding Update 2280 message indicates that any existing binding for the mobile node MUST 2281 be deleted. Likewise, if the Lifetime field in the Binding parameter 2282 is equal to 0, the Binding Update message indicates that any existing 2283 binding for the mobile node MUST be deleted. In each of these cases, 2284 a Binding Cache entry for the mobile node MUST NOT be created in 2285 response to receiving the Binding Update. 2287 When the care-of address is NOT equal to the home address, 2288 what if we just delete that particular care-of address? 2290 The last Sequence Number value sent to a destination in a Binding 2291 parameter is stored by the mobile node in its Binding Update List 2292 entry for that destination; the last Sequence Number value received 2293 from a mobile node in a Binding Update is stored by a correspondent 2294 node in its Binding Cache entry for that mobile node. Thus, the 2295 mobile node's and the correspondent node's knowledge of the last 2296 sequence number expire at the same time. If the sending mobile node 2297 has no Binding Update List entry, the Sequence Number may start at 2298 any value; if the receiving correspondent node has no Binding Cache 2299 entry for the sending mobile node, it MUST accept any Sequence Number 2300 value in a received Binding Update from this mobile node. The mobile 2301 node MUST NOT use the same Sequence Number in two different Binding 2302 Updates to the same correspondent node, even if the Binding Updates 2303 provide different care-of addresses. 2305 5.1.8. Binding Acknowledgement (BA) Message 2307 The Binding Acknowledgement message is used to acknowledge receipt 2308 of a Binding Update message (Section 5.1.7). When a node receives 2309 a packet containing a Binding Update message, with this node being 2310 the destination of the packet, this node MUST return a Binding 2311 Acknowledgement to the mobile node, if the Acknowledge (A) bit is 2312 set in the Binding Parameter carried in the Binding Update. The 2313 Binding Acknowledgement message is sent to the Source Address of the 2314 Binding Update message it is an answer to, with the source being the 2315 Destination Address from the Binding Update. 2317 The Binding Acknowledgement message has the MH Type value 6. When 2318 this value is indicated in the MH Type field, the format of the 2319 Message Data field in the Mobility Header is as follows: 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | Reserved | 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 | Status | Reserved | Sequence # | 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 | Lifetime | 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | Refresh | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | | 2331 . . 2332 . Parameters . 2333 . . 2334 | | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 Reserved 2339 These fields are unused. They MUST be initialized to zero by 2340 the sender and MUST be ignored by the receiver. 2342 Status 2344 8-bit unsigned integer indicating the disposition of the 2345 Binding Update. Values of the Status field less than 128 2346 indicate that the Binding Update was accepted by the receiving 2347 node. The following such Status values are currently defined: 2349 0 2351 Binding Update accepted 2353 Values of the Status field greater than or equal to 128 2354 indicate that the Binding Update was rejected by the receiving 2355 node. The following such Status values are currently defined: 2357 128 2359 Reason unspecified 2361 130 2363 Administratively prohibited 2365 131 2367 Insufficient resources 2369 132 2371 Home registration not supported 2373 133 2375 Not home subnet 2377 137 2379 Not home agent for this mobile node 2381 138 2383 Duplicate Address Detection failed 2385 141 2387 Sequence number out of window 2389 142 2391 Route optimization unnecessary due to low traffic 2393 143 2395 Invalid authenticator 2397 144 2399 Too old Home Nonce Index 2401 145 2403 Too old Care-of Nonce Index 2405 Up-to-date values of the Status field are to be specified in 2406 the most recent "Assigned Numbers" [32]. 2408 Sequence # 2410 The Sequence Number in the Binding Acknowledgement is copied 2411 from the Sequence Number field in the Binding Update being 2412 acknowledged, for use by the mobile node in matching this 2413 Acknowledgement with an outstanding Binding Update. 2415 Lifetime 2417 The granted lifetime, in seconds, for which this node will 2418 SHOULD retain the entry for this mobile node in its Binding 2419 Cache. Correspondent nodes should make an effort to honor 2420 the lifetimes, since an entry that was garbage collected too 2421 early might cause subsequent packets from the mobile node to 2422 be dropped, if they contained the Home Address Option. While 2423 this situation is recoverable since an error message is sent 2424 to the mobile node, it causes an unnecessary break in the 2425 communications. 2427 Correspondent nodes SHOULD also retain a BCE entry for the 2428 purposes of accepting Home Address Options somewhat longer than 2429 they keep on using the entry for Route Optimization of outgoing 2430 packets. This helps to avoid dropped packets, particularly 2431 when clock drift can be a problem. 2433 If the node sending the Binding Acknowledgement is serving 2434 as the mobile node's home agent, the Lifetime period also 2435 indicates the period for which this node will continue this 2436 service; if the mobile node requires home agent service from 2437 this node beyond this period, the mobile node MUST send a new 2438 Binding Update to it before the expiration of this period (even 2439 if it is not changing its primary care-of address), in order 2440 to extend the lifetime. The value of this field is undefined 2441 if the Status field indicates that the Binding Update was 2442 rejected. 2444 Refresh 2446 The recommended interval, in seconds, at which the mobile 2447 node SHOULD send a new Binding Update to this node in order 2448 to "refresh" the mobile node's binding in this node's Binding 2449 Cache. This refreshing of the binding is useful in case the 2450 node fails and loses its cache state. The Refresh period is 2451 determined by the node sending the Binding Acknowledgement (the 2452 node caching the binding). If this node is serving as the 2453 mobile node's home agent, the Refresh value may be set, for 2454 example, based on whether the node stores its Binding Cache 2455 in volatile storage or in nonvolatile storage. Note that as 2456 discussed in Section 4.5.4, home agents need to keep at least 2457 some information about sequence numbers in non-volatile memory. 2459 If the node sending the Binding Acknowledgement is not 2460 serving as the mobile node's home agent, the Refresh period 2461 SHOULD be set equal to the Lifetime period in the Binding 2462 Acknowledgement; even if this node loses this cache entry due 2463 to a failure of the node, packets from it can still reach the 2464 mobile node through the mobile node's home agent, causing a new 2465 Binding Update to this node to allow it to recreate this cache 2466 entry. The value of this field is undefined if the Status 2467 field indicates that the Binding Update was rejected. 2469 Parameters 2471 Variable-length field, of length such that the complete 2472 Mobility Header is an integer multiple of 8 octets long. 2473 Contains one or more TLV-encoded parameters. The receiver MUST 2474 ignore and skip any parameters which it does not understand. 2475 A Binding Acknowledgement sent by a correspondent node MUST 2476 include the following parameter: 2478 - Authentication Data parameter. This parameter contains a 2479 cryptographic hash value which is used to ensure that it 2480 has been sent by the correspondent node. The authenticator 2481 covering a Binding Acknowledgement MUST be computed over 2482 a bitstring containing the following fields of the IPv6 2483 header and the Mobility Header, in order: 2485 * Care-of Address, in the Destination Address field of 2486 the IPv6 header 2488 * The address of the correspondent node, in the Source 2489 Address field of the IPv6 header. 2491 * The contents of the Mobility Header, excluding the 2492 Authenticator field (inside the Authentication Data 2493 parameter) which is included as zeroes for the purposes 2494 of calculating the Authenticator. 2496 * Four bytes of zero. 2498 The actual authenticator calculation over sequence of bits 2499 is described in Section 4.5. 2501 There MAY be additional information, associated with this 2502 Binding Acknowledgement message, that need not be present in 2503 all Binding Acknowledgements sent. This use of MH parameters 2504 also allows for future extensions to the format of the Binding 2505 Acknowledgement message to be defined. The encoding and format 2506 of defined parameters are described in Section 5.2. This 2507 specification does not define any parameters valid for the 2508 Binding Acknowledgement message. 2510 If no actual parameters are present in this message, no padding is 2511 needed. 2513 The Binding Acknowledgement is sent to the source address of the 2514 Binding Update message, regardless of whether the Binding Update 2515 succeeded or failed. No Routing Headers are inserted to the message. 2517 If the mobile node sends a sequence number which is not within the 2518 window of acceptable sequence numbers, then the home agent MUST send 2519 back a Binding Acknowledgement with status code 141, and the last 2520 accepted sequence number in the Sequence Number field of the Binding 2521 Ack Parameter. 2523 5.1.9. Binding Missing (BM) Message 2525 The Binding Missing (BM) message is used by the correspondent node 2526 to signal an inappropriate attempt to use the Home Address Option 2527 without an existing binding. A packet containing a Binding Missing 2528 message is sent to the source address of the packet that contained 2529 the Home Address Option i.e. to the care-of address of the mobile 2530 node. The source address of the Binding Missing message is the 2531 correspondent node's address. 2533 When a mobile node receives a packet containing a Binding Missing 2534 message, it should perform one of the following three actions: 2536 - If the mobile node does not have a Binding Update List entry for 2537 the source of the Binding Missing message, it MUST ignore the 2538 message. This is necessary to prevent loss of resources spent on 2539 the Route Optimization signaling due to spoofed Binding Missing 2540 messages. 2542 - If the mobile node does have a Binding Update List entry but 2543 has recent upper layer progress information that indicates 2544 communications with the correspondent node are progressing, it 2545 MAY ignore the message. This can be done in order to limit the 2546 damage that spoofed Binding Missing messages can cause to ongoing 2547 communications. 2549 - If the mobile node does have a Binding Update List entry but 2550 no upper layer progress information, it MUST remove the entry 2551 and route further communications through the home agent. It 2552 may also optionally start a Return Routability Procedure (see 2553 Section 4.5). 2555 The Binding Missing message uses the MH Type value 7. When this 2556 value is indicated in the MH Type field, the format of the Message 2557 Data field in the Mobility Header is as follows: 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Reserved | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | | 2563 + + 2564 | | 2565 + Home Address + 2566 | | 2567 + + 2568 | | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 | | 2571 . . 2572 . Parameters . 2573 . . 2574 | | 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 Reserved 2579 16-bit field reserved for future flags. These flag bits are 2580 reserved for future use, and MUST be initialized to zero by the 2581 sender, and MUST be ignored by the receiver. 2583 Home Address 2585 The home address that was contained in the Home Address Option. 2586 The mobile node uses this information to determine which 2587 binding does not exist, if there mobile node has several home 2588 addresses. 2590 Parameters 2592 Variable-length field, of length such that the complete 2593 Mobility Header is an integer multiple of 8 octets long. 2594 Contains one or more TLV-encoded parameters. The receiver MUST 2595 ignore and skip any parameters which it does not understand. 2597 There MAY be additional information, associated with this 2598 Binding Missing message, that need not be present in all 2599 Binding Missings sent. This use of MH parameters also allows 2600 for future extensions to the format of the Binding Missing 2601 message to be defined. The encoding and format of defined 2602 parameters are described in Section 5.2. This specification 2603 does not define any parameters for the Binding Missing message. 2605 If no actual parameters are present in this message, no padding is 2606 needed. 2608 5.2. Mobility Header Parameters 2610 5.2.1. Format 2612 In order to allow optional fields that may not be needed in every use 2613 of any given Mobility Header, and to allow future extensions to the 2614 format of these messages to be defined, any of the Mobility Header 2615 messages defined in this document MAY include one or more parameters. 2617 Such parameters are included in the data portion of the message 2618 itself, after the fixed portion of the message data specified in 2619 section 5.1. 2621 The presence of such parameters will be indicated by the Header Len 2622 of the Mobility Header. 2624 These parameters are encoded within the remaining space of the 2625 message data for that message, using a type-length-value (TLV) format 2626 as follows: 2628 0 1 2 3 2629 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 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 |Parameter Type | Parameter Len | Parameter Data... 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 Parameter Type 2636 8-bit identifier of the type of parameter. When processing a 2637 Mobility Header containing a parameter for which the Parameter 2638 Type value is not recognized by the receiver, the receiver MUST 2639 quietly ignore and skip over the parameter, correctly handling 2640 any remaining sub-options in the option. 2642 Parameter Length 2644 8-bit unsigned integer. Length of the Parameter Data field 2645 of this parameter, in octets. The Parameter Len includes the 2646 length of the Parameter Type and Parameter Len fields. 2648 Parameter Data 2650 Variable-length field. Parameter -Type-specific data. 2652 Parameters MUST be aligned on an 8-byte boundary, and have a length 2653 which is a multiple of 8. 2655 The following subsections specify the Parameter types which are 2656 currently defined for use in the Mobility Header. 2658 Implementations MUST silently ignore any parameters that they do not 2659 understand. 2661 5.2.2. Pad1 2663 Pad1 Parameter (alignment requirement: none) 2665 0 2666 0 1 2 3 4 5 6 7 2667 +-+-+-+-+-+-+-+-+ 2668 | 0 | 2669 +-+-+-+-+-+-+-+-+ 2671 NOTE! the format of the Pad1 parameter is a special case -- it has 2672 neither Parameter Len nor Parameter Data fields. 2674 The Pad1 parameter is used to insert one octet of padding into the 2675 Parameters area of a Mobility Header. If more than one octet of 2676 padding is required, the PadN parameter, described next, should be 2677 used, rather than multiple Pad1 parameters. 2679 5.2.3. PadN 2681 PadN Parameter (alignment requirement: none) 2683 0 1 2684 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2686 | 1 | Parameter Len | Parameter Data 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2689 The PadN parameter is used to insert two or more octets of padding 2690 into the Parameters area of some Mobility Header message. For N 2691 octets of padding, the Parameter Len field contains the value N, and 2692 the Parameter Data consists of N-2 zero-valued octets. Parameter 2693 data MUST be ignored by the receiver. 2695 5.2.4. Unique Identifier 2697 Unique Identifier parameter (alignment requirement: 2n) 2699 0 1 2 3 2700 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 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | 2 | 4 | Unique Identifier | 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 The Unique Identifier parameter is valid only in Binding Request and 2706 Binding Update messages. The Unique Identifier field contains a 2707 16-bit value that serves to uniquely identify a Binding Request among 2708 those sent by this Source Address, and to allow the Binding Update 2709 to identify the specific Binding Request to which it responds. This 2710 matching of Binding Updates to Binding Requests is required in the 2711 procedure for renumbering the home subnet while a mobile node is away 2712 from home (Section 9.7). 2714 5.2.5. Alternate Care-of Address 2716 Alternate Care-of Address parameter (alignment requirement: 8n+6) 2718 0 1 2 3 2719 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 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | 3 | 18 | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | | 2724 + + 2725 | | 2726 + Alternate Care-of Address + 2727 | | 2728 + + 2729 | | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 The Alternate Care-of Address parameter is valid only in Binding 2733 Update message. The Alternate Care-of Address field contains an 2734 address to use as the care-of address for the binding, rather than 2735 using the Source Address of the packet as the care-of address. 2737 5.2.6. Nonce Indices 2739 Nonce Indices parameter (alignment requirement: 8n+6) 2741 0 1 2 3 2742 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 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | 4 | 6 | 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 | Home Nonce Index | Care-of Nonce Index | 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 The Nonce Indices parameter is valid only in the Binding Update 2750 message, and only when present together with an Authentication Data 2751 parameter. 2753 The Home Nonce Index field tells the correspondent node that receives 2754 the message which of the challenge values (Nj) are to be used to 2755 authenticate the Binding Update. 2757 The Care-of Nonce Index field tells the correspondent node that 2758 receives the message which of the challenge values (Ni) are to be 2759 used to authenticate the Binding Update. 2761 5.2.7. Authentication Data 2763 Authentication Data parameter (alignment requirement: 8n+6) 2765 0 1 2 3 2766 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 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | 5 | 18 | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | SPI | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | | 2773 + + 2774 | Authenticator | 2775 + + 2776 | | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 The Authentication Data parameter is valid only in the Binding 2780 Request, Binding Update, and Binding Acknowledgment messages. 2782 The Security Parameters Index (SPI) field contains an arbitrary 2783 32-bit value that uniquely identifies the used security association. 2784 This document specifies only one legal value for the SPI field. This 2785 value, 0, signifies that no security association is present and the 2786 cryptographic context MUST be established temporarily only for the 2787 duration of processing this message. Messages that contain other 2788 values of the SPI field SHOULD be silently discarded. 2790 The Authenticator field contains a 96-bit cryptographic hash 2791 value. Rules for calculating this value are different for different 2792 messages, and are described in Sections 5.1.2, 5.1.7 and 5.1.8. 2794 5.3. Home Address Option 2796 The Home Address destination option is used in a packet sent by a 2797 mobile node while away from home, to inform the recipient of that 2798 packet of the mobile node's home address. For packets sent by a 2799 mobile node while away from home, the mobile node generally uses one 2800 of its care-of addresses as the Source Address in the packet's IPv6 2801 header. By including a Home Address option in the IPv6 Destination 2802 Options header of the packet, the correspondent node receiving the 2803 packet is able to substitute the mobile node's home address for this 2804 care-of address when processing the packet. This makes the use of 2805 the care-of address transparent to the correspondent node. Note 2806 that multicast addresses, link-local addresses, loopback addresses, 2807 IPv4 mapped addresses, and the unspecified address, MUST NOT be used 2808 within a Home Address option. 2810 The Home Address option is encoded in type-length-value (TLV) format 2811 as follows: 2813 0 1 2 3 2814 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 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 | Option Type | Option Length | 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2818 | | 2819 + + 2820 | | 2821 + Home Address + 2822 | | 2823 + + 2824 | | 2825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2826 | Sub-Options... 2827 +-+-+-+-+-+-+-+-+-+-+-+- 2829 Option Type 2831 201 = 0xC9 2833 Option Length 2835 8-bit unsigned integer. Length of the option, in octets, 2836 excluding the Option Type and Option Length fields. This field 2837 MUST be set to 16 plus the total length of all sub-options 2838 present, including their Sub-Option Type and Sub-Option Len 2839 fields. 2841 Home Address 2843 The home address of the mobile node sending the packet. 2845 Sub-Options 2847 Additional information, associated with this Home Address 2848 option, that need not be present in all Home Address options 2849 sent. This use of sub-options also allows for future 2850 extensions to the format of the Home Address option to be 2851 defined. Currently, no valid sub-options are defined for use 2852 in a Home Address option. 2854 The alignment requirement [6] for the Home Address option is 8n+6. 2856 The inclusion of a Home Address option in a packet affects the 2857 receiving node's processing of only this single packet; no state is 2858 created or modified in the receiving node as a result of receiving a 2859 Home Address option in a packet. In particular, the presence of a 2860 Home Address option in a received packet MUST NOT alter the contents 2861 of the receiver's Binding Cache and MUST NOT cause any changes in the 2862 routing of subsequent packets sent by this receiving node. 2864 The Home Address option MUST be placed as follows: 2866 - After the Routing Header, if that header is present 2868 - Before the Fragment Header, if that header is present 2870 - Before the AH Header or ESP Header, if either one of those 2871 headers is present 2873 Due to the threat of reflection attacks through the use of this 2874 option, this specification requires that packets containing Home 2875 Address Option MUST be dropped if there is no corresponding Binding 2876 Cache Entry for that home address with the currently registered 2877 care-of address matching the source address of the packet. If the 2878 packet is dropped, the correspondent nodes SHOULD send the Binding 2879 Missing message to the source address of the packet that contained 2880 the Home Address Option (see Section 5.1.9). These messages SHOULD 2881 be rate-limited. 2883 No additional authentication of the Home Address option is 2884 required, except that if the IPv6 header of a packet is covered 2885 by authentication, then that authentication MUST also cover the 2886 Home Address option; this coverage is achieved automatically by the 2887 definition of the Option Type code for the Home Address option, since 2888 it indicates that the data within the option cannot change en-route 2889 to the packet's final destination, and thus the option is included in 2890 the authentication computation. By requiring that any authentication 2891 of the IPv6 header also cover the Home Address option, the security 2892 of the Source Address field in the IPv6 header is not compromised by 2893 the presence of a Home Address option. Security issues related to 2894 the Home Address option are discussed further in Section 4.5. When 2895 attempting to verify authentication data in a packet that contains 2896 a Home Address option, the receiving node MUST make the calculation 2897 as if the care-of address were present in the Home Address option, 2898 and the home address were present in the source IPv6 address field 2899 of the IPv6 header. This conforms with the calculation specified in 2900 section 10.2. 2902 A packet MUST NOT contain more than one Home Address option, except 2903 that an encapsulated packet [4] MAY contain a separate Home Address 2904 option associated with each encapsulating IP header. 2906 The three highest-order bits of the Option Type are encoded to 2907 indicate specific processing of the option [6]. For the Home Address 2908 option, these three bits are set to 110, indicating that any IPv6 2909 node processing this option that does not recognize the Option Type 2910 must discard the packet and, only if the packet's Destination Address 2911 was not a multicast address, return an ICMP Parameter Problem, 2912 Code 2, message to the packet's Source Address; and that the data 2913 within the option cannot change en-route to the packet's final 2914 destination. 2916 5.4. Routing Header type 2 2918 Mobile IPv6 uses a routing header to carry the Home Address for 2919 packets sent from a correspondent node to a mobile node, which the 2920 Care of Address of the MN is carried in the IPv6 destination field. 2922 This uses a different routing header type than what is defined 2923 for ``regular'' IPv6 source routing to make it possible for e.g., 2924 firewalls to have different rules for source routing versus MIPv6. 2925 This routing header type (type 2) is restricted to only carry one 2926 IPv6 address and all IPv6 nodes which process it MUST verify that the 2927 address contained in the routing header is the home address of the 2928 node in order to prevent packets with this routing header type to be 2929 forwarded after decrementing the segments left field. 2931 5.4.1. Routing Header Packet format 2933 The Type 2 Routing header has the following format: 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2936 | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| 2937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2938 | Reserved | 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2940 | | 2941 + + 2942 | | 2943 + Home Address + 2944 | | 2945 + + 2946 | | 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 Next Header 2951 8-bit selector. Identifies the type of header immediately 2952 following the Routing header. Uses the same values as the IPv4 2953 Protocol field [10]. 2955 Hdr Ext Len 2957 8-bit unsigned integer. Length of the Routing header in 2958 8-octet units, not including the first 8 octets. For the Type 2959 2 Routing header, Hdr Ext Len is always 2. 2961 Routing Type 2963 2. 2965 Segments Left 2967 8-bit unsigned integer. Number of route segments remaining, 2968 i.e., number of explicitly listed intermediate nodes still to 2969 be visited before reaching the final destination. For the type 2970 2 routing header, Segments left is always 1. 2972 Reserved 2974 32-bit reserved field. Initialized to zero for transmission; 2975 ignored on reception. 2977 Home Address 2979 The Home Address of the destination Mobile Node. 2981 5.4.2. Sending RH type 2 2983 A correspondent node sends packets with a routing header based on the 2984 content of the binding cache. Conceptually this is done by the IP 2985 layer inspecting the binding cache and if there is an entry for the 2986 destination address (the Home Address) then the IP layer inserts a 2987 routing header of type 2 based on the ordering rules below and moves 2988 the Home Address to the Home Address field in the RH and places the 2989 Care of Address in the IPv6 destination field. 2991 Note that following the above conceptually model in an implementation 2992 creates some additional requirements for path MTU discovery since the 2993 packetization layer (e.g., TCP and applications using UDP) need to be 2994 aware of the size of the headers added by the IP layer on the sending 2995 node. 2997 The IP layer will insert the routing header before performing IPsec 2998 processing. The IPsec Security Policy Database will be consulted 2999 based on the IP source address and the final IP destination (which 3000 will be in the routing header). The definition of AH ensures that 3001 the AH calculation is done on the packet in the form it will have on 3002 the receiver after advancing the routing header. 3004 5.4.3. Verification by receiver 3006 A node receiving a packet addressed to itself (i.e., one of the 3007 node's addresses is in the IPv6 destination field) follows the next 3008 header chain of headers and processes them. When it encounters a 3009 routing header of type 2 during this processing it performs the 3010 following checks. If any of these checks fail the node MUST silently 3011 discard the packet. 3013 - The node is a mobile node. 3015 - The length field in the RH is exactly 2 3017 - The segments left field in the RH is exactly 1 3019 - The Home Address field in the RH is (one of) the node's Home 3020 Address(es) 3022 Once the above checks have been performed the routing header 3023 processing. Conceptually this follows the same model as in RFC 2460 3024 i.e. swap the IPv6 destination field with the Home Address field 3025 in the RH, decrement segments left, and resubmit the packet to IP 3026 for processing the next header. However, in the case of RH type 2 3027 this can be simplified since it is known that the packet will not be 3028 forwarded to a different node. 3030 Since IPsec headers follow the Routing Header any IPsec processing 3031 will operate on the packet with the HoA in the IP destination field 3032 and segments left being zero. Thus AH will see the packet in the 3033 same "shape" as the AH calculation on the sender. 3035 5.4.4. Extension header ordering 3037 Section 4.1 in RFC 2460 lists the extension header ordering. The 3038 introduction of Routing Header type 2 potentially allows there to be 3039 multiple routing headers in a single packet. If this is the case 3040 the Routing Header type 2 should follow any Routing header of other 3041 type but otherwise the order constraints for routing headers is 3042 independent of their type and follows RFC 2460. 3044 5.4.5. Reversing type 2 routing headers 3046 In addition, the general procedures defined by IPv6 for Routing 3047 headers suggest that a received Routing header MAY be automatically 3048 "reversed" to construct a Routing header for use in any response 3049 packets sent by upper-layer protocols, if the received packet 3050 is authenticated [6]. This MUST NOT be done to type 2 routing 3051 headers. 3053 5.5. Mobile IPv6 Destination Option Sub-Options 3055 In order to allow future extensions to the format of MIPv6 3056 destination options, any of the Mobile IPv6 destination options 3057 defined in this document MAY include one or more sub-options. 3059 Such sub-options are included in the data portion of the destination 3060 option itself, after the fixed portion of the option data specified 3061 for that particular destination option (Section 5.3). The presence 3062 of such sub-options will be indicated by the Option Length field. 3063 When the Option Length is greater than the standard length defined 3064 for that destination option, the remaining octets are interpreted as 3065 sub-options. 3067 These sub-options are encoded within the remaining space of the 3068 option data for that option, using a type-length-value (TLV) format 3069 as follows: 3071 0 1 2 3 3072 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 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 |Sub-Option Type| Sub-Option Len| Sub-Option Data... 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 Sub-Option Type 3079 8-bit identifier of the type of sub-option. When processing 3080 a Mobile IPv6 destination option containing a sub-option for 3081 which the Sub-Option Type value is not recognized by the 3082 receiver, the receiver SHOULD quietly ignore and skip over the 3083 sub-option, correctly handling any remaining sub-options in the 3084 option. 3086 Sub-Option Length 3088 8-bit unsigned integer. Length of the Sub-Option Data field 3089 of this sub-option, in octets. The Sub-Option Len does not 3090 include the length of the Sub-Option Type and Sub-Option Len 3091 fields. 3093 Sub-Option Data 3095 Variable-length field. Sub-Option-Type-specific data. 3097 As with IPv6 options appearing in a Hop-by-Hop Options header 3098 or Destination Options header [6], individual sub-options within 3099 a Mobile IPv6 destination option may have specific alignment 3100 requirements, to ensure that multi-octet values within Sub-Option 3101 Data fields fall on natural boundaries. The alignment requirement 3102 of each sub-option is specified as part of the definition of each 3103 sub-option below. 3105 Each section above defining the Mobile IPv6 destination options 3106 specifies which of the defined sub-options is valid for that 3107 destination option. In addition, there are two padding sub-options, 3108 Pad1 and PadN (defined below), which are used when necessary to align 3109 subsequent sub-options. The Pad1 and PadN sub-options are valid for 3110 all Mobile IPv6 destination options. Unlike the padding options 3111 used in Hop-by-Hop Options header or Destination Options header [6], 3112 there is no requirement for padding the total size of any Mobile IPv6 3113 destination option to a multiple of 8 octets in length, and the 3114 Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All 3115 Mobile IPv6 sub-options defined in this document MUST be recognized 3116 by all Mobile IPv6 implementations. 3118 5.5.1. Pad1 3120 Pad1 Sub-Option (alignment requirement: none) 3122 0 3123 0 1 2 3 4 5 6 7 3124 +-+-+-+-+-+-+-+-+ 3125 | 0 | 3126 +-+-+-+-+-+-+-+-+ 3128 NOTE! the format of the Pad1 sub-option is a special 3129 case -- it has neither Sub-Option Len nor Sub-Option Data 3130 fields. 3132 The Pad1 sub-option is used to insert one octet of padding 3133 into the Sub-Options area of a Mobile IPv6 option. If more 3134 than one octet of padding is required, the PadN sub-option, 3135 described next, should be used, rather than multiple Pad1 3136 sub-options. 3138 5.5.2. PadN 3140 PadN Sub-Option (alignment requirement: none) 3142 0 1 3143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 3145 | 1 | Sub-Option Len| Sub-Option Data 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 3148 The PadN sub-option is used to insert two or more octets of 3149 padding into the Sub-Options area of a Mobile IPv6 option. 3150 For N octets of padding, the Sub-Option Len field contains 3151 the value N-2, and the Sub-Option Data consists of N-2 3152 zero-valued octets. 3154 5.6. ICMP Home Agent Address Discovery Request Message 3156 The ICMP Home Agent Address Discovery Request message is used by a 3157 mobile node to initiate the dynamic home agent address discovery 3158 mechanism, as described in Sections 9.9 and 10.8. The mobile 3159 node sends a Home Agent Address Discovery Request message to the 3160 "Mobile IPv6 Home-Agents" anycast address for its own home subnet 3161 prefix [11], and one of the home agents there responds to the mobile 3162 node with a Home Agent Address Discovery Reply message giving a list 3163 of the routers on the mobile node's home link serving as home agents. 3165 0 1 2 3 3166 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 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | Type | Code | Checksum | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | Identifier | Reserved | 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 Type 3175 150 3177 Code 3179 0 3181 Checksum 3183 The ICMP checksum [5]. 3185 Identifier 3187 An identifier to aid in matching Home Agent Address Discovery 3188 Reply messages to this Home Agent Address Discovery Request 3189 message. 3191 Reserved 3193 This field is unused. It MUST be initialized to zero by the 3194 sender and MUST be ignored by the receiver. 3196 The Source Address of the Home Agent Address Discovery Request 3197 message packet MUST be one of the mobile node's current care-of 3198 addresses. The home agent then MUST return the Home Agent Address 3199 Discovery Reply message directly to the Source Address chosen by 3200 the mobile node Note that, at the time of performing this dynamic 3201 home agent address discovery, it is likely that the mobile node not 3202 registered with any home agent within the specified anycast group. 3204 5.7. ICMP Home Agent Address Discovery Reply Message 3206 The ICMP Home Agent Address Discovery Reply message is used by a 3207 home agent to respond to a mobile node using the dynamic home agent 3208 address discovery mechanism, as described in Sections 9.9 and 10.8. 3209 The mobile node sends a Home Agent Address Discovery Request message 3210 to the "Mobile IPv6 Home-Agents" anycast address for its own home 3211 subnet prefix [11], and one of the home agents there responds to the 3212 mobile node with a Home Agent Address Discovery Reply message giving 3213 a list of the routers on the mobile node's home link serving as home 3214 agents. 3216 0 1 2 3 3217 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 3218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 | Type | Code | Checksum | 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 | Identifier | | 3222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3223 | | 3224 + Reserved + 3225 | | 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | | 3228 + + 3229 . . 3230 . Home Agent Addresses . 3231 . . 3232 + + 3233 | | 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3236 Type 3238 151 3240 Code 3242 0 3244 Checksum 3246 The ICMP checksum [5]. 3248 Identifier 3250 The identifier from the invoking Home Agent Address Discovery 3251 Request message. 3253 Reserved 3255 This field is unused. It MUST be initialized to zero by the 3256 sender and MUST be ignored by the receiver. 3258 Home Agent Addresses 3260 A list of addresses of home agents on the home link for the 3261 mobile node. The number of addresses present in the list is 3262 indicated by the remaining length of the IPv6 packet carrying 3263 the Home Agent Address Discovery Reply message. 3265 5.8. ICMP Mobile Prefix Solicitation Message Format 3267 The ICMP Mobile Prefix Solicitation Message is sent by a mobile node 3268 to its home agent while it is away from home. The purpose of the 3269 message is to solicit a Mobile Prefix Advertisement from the home 3270 agent, which will allow the mobile node to gather prefix information 3271 about its home network. This information can be used to configure 3272 home address(es) by stateless address autoconfiguration [35], 3273 or update address(es) according to changes in prefix information 3274 supplied by the home agent. 3276 The Mobile Prefix Solicitation is similar to the Router Solicitation 3277 used in Neighbor Discovery [20], except it is routed from the mobile 3278 node on the visited network to the home agent on the home network by 3279 usual unicast routing rules. 3281 0 1 2 3 3282 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 3283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3284 | Type | Code | Checksum | 3285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 | Reserved | 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3289 IP Fields: 3291 Source Address 3293 The mobile node's care-of address. 3295 Destination Address 3297 The address of the mobile node's home agent. This home agent 3298 must be on the link which the mobile node wishes to learn 3299 prefix information about. 3301 Hop Limit 3303 Set to an initial hop limit value, and this message is routed 3304 according to the rules of a typical unicast packet. A hop 3305 limit of 64 is currently suggested [32]. 3307 Authentication Header 3309 If a Security Association for the IP Authentication Header 3310 exists between the sender and the destination address, then the 3311 sender SHOULD include this header. [subject to change] 3313 ICMP Fields: 3315 Type 3317 152 3319 Code 3321 0 3323 Checksum 3325 The ICMP checksum [5]. 3327 Reserved 3329 This field is unused. It MUST be initialized to zero by the 3330 sender and MUST be ignored by the receiver. 3332 5.9. ICMP Mobile Prefix Advertisement Message Format 3334 A home agent will send a Mobile Prefix Advertisement message to a 3335 mobile node to distribute prefix information about the home link 3336 while the mobile node is traveling away from the home network. This 3337 will occur in response to a Mobile Prefix Solicitation with an 3338 Advertisement, or by an unsolicited Advertisement sent according to 3339 the rules in Section 5.9. 3341 0 1 2 3 3342 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 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 | Type | Code | Checksum | 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3346 | Options ... 3347 +-+-+-+-+-+-+-+-+-+-+-+- 3349 IP Fields: 3351 Source Address 3352 The home agent's address as the mobile node would 3353 expect to see it (i.e. same prefix) 3355 Destination Address 3356 If this message is a response to a Mobile Prefix 3357 Solicitation, the Source Address field from that 3358 packet. For unsolicited messages, the mobile node's 3359 care-of address SHOULD be used, if it is currently 3360 registered with the home agent. Otherwise, the 3361 mobile node's home address SHOULD be used. 3363 Authentication Header 3364 This header MUST be sent, unless the mobile node 3365 has not yet configured, and is using its care-of 3366 address. [subject to change] 3368 ICMP Fields: 3370 Type 3372 153 3374 Code 3376 0 3378 Checksum 3380 The ICMP checksum [5]. 3382 Options: 3384 Prefix Information 3386 Each message contains one or more Prefix Information options, 3387 which contain the prefix(es) the mobile node should configure 3388 its home address(es) with. Section 9.7 describes which 3389 prefixes should be advertised to the mobile node. 3391 The Prefix Information option is defined in Section 4.6.2 3392 of [20], with modifications defined in Section 6.2 of this 3393 specification. The home agent MUST use this modified Prefix 3394 Information option to send the aggregate list of home network 3395 prefixes as defined in Section 9.9.1. 3397 The Mobile Prefix Advertisement sent by the home agent MAY include 3398 the Source Link-layer Address option defined in RFC 2461 [20], or the 3399 Advertisement Interval option specified in Section 6.3. 3401 Future versions of this protocol may define new option types. Home 3402 Agents MUST silently ignore any options they do not recognize and 3403 continue processing the message. 3405 6. Modifications to IPv6 Neighbor Discovery 3407 6.1. Modified Router Advertisement Message Format 3409 Mobile IPv6 modifies the format of the Router Advertisement 3410 message [20] by the addition of a single flag bit to indicate that 3411 the router sending the Advertisement message is serving as a home 3412 agent on this link. The format of the Router Advertisement message 3413 is as follows: 3415 0 1 2 3 3416 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 3417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3418 | Type | Code | Checksum | 3419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3420 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 3421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 | Reachable Time | 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 | Retrans Timer | 3425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3426 | Options ... 3427 +-+-+-+-+-+-+-+-+-+-+-+- 3429 This format represents the following changes over that originally 3430 specified for Neighbor Discovery [20]: 3432 Home Agent (H) 3434 The Home Agent (H) bit is set in a Router Advertisement to 3435 indicate that the router sending this Router Advertisement is 3436 also functioning as a Mobile IP home agent on this link. 3438 Reserved 3440 Reduced from a 6-bit field to a 5-bit field to account for the 3441 addition of the Home Agent (H) bit. 3443 6.2. Modified Prefix Information Option Format 3445 Mobile IPv6 requires knowledge of a router's global address for two 3446 reasons: 3448 - To allow a home agent (a router) to learn the address of all 3449 other home agents on the link for which it is providing home 3450 agent service, for use in building its Home Agents List as 3451 part of the dynamic home agent address discovery mechanism 3452 (Sections 9.9 and 10.8). 3454 - To allow a mobile node to send a Binding Update to a router on 3455 the link on which its previous care-of address is located, for 3456 purposes of establishing forwarding from this previous care-of 3457 address to its new care-of address (Section 10.11). 3459 However, Neighbor Discovery [20] only advertises a router's 3460 link-local address, by requiring this address to be used as the IP 3461 Source Address of each Router Advertisement. 3463 Mobile IPv6 extends Neighbor Discovery to allow a router to easily 3464 and efficiently advertise its global address, by the addition of a 3465 single flag bit in the format of a Prefix Information option for 3466 use in Router Advertisement messages. The format of the Prefix 3467 Information option is as follows: 3469 0 1 2 3 3470 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 3471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3472 | Type | Length | Prefix Length |L|A|R|Reserved1| 3473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3474 | Valid Lifetime | 3475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3476 | Preferred Lifetime | 3477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3478 | Reserved2 | 3479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3480 | | 3481 + + 3482 | | 3483 + Prefix + 3484 | | 3485 + + 3486 | | 3487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3489 This format represents the following changes over that originally 3490 specified for Neighbor Discovery [20]: 3492 Router Address (R) 3494 1-bit router address flag. When set, indicates that the 3495 Prefix field, in addition to advertising the indicated prefix, 3496 contains a complete IP address assigned to the sending router. 3497 This router IP address has the same scope and conforms to the 3498 same lifetime values as the advertised prefix. This use of 3499 the Prefix field is compatible with its use in advertising 3500 the prefix itself, since prefix advertisement uses only the 3501 leading number Prefix bits specified by the Prefix Length 3502 field. Interpretation of this flag bit is thus independent 3503 of the processing required for the On-Link (L) and Autonomous 3504 Address-Configuration (A) flag bits. 3506 Reserved1 3508 Reduced from a 6-bit field to a 5-bit field to account for the 3509 addition of the Router Address (R) bit. 3511 In a solicited Router Advertisement, a home agent MUST, and all other 3512 routers SHOULD, include at least one Prefix Information option with 3513 the Router Address (R) bit set. Neighbor Discovery specifies that, 3514 if including all options in a Router Advertisement causes the size of 3515 the Advertisement to exceed the link MTU, multiple Advertisements can 3516 be sent, each containing a subset of the options [20]. In this case, 3517 at least one of these multiple Advertisements being sent instead 3518 of a single larger solicited Advertisement, MUST include a Prefix 3519 Information option with the Router Address (R) bit set. 3521 All routers SHOULD include at least one Prefix Information option 3522 with the Router Address (R) bit set, in each unsolicited multicast 3523 Router Advertisement that they send. If multiple Advertisements 3524 are being sent instead of a single larger unsolicited multicast 3525 Advertisement, at least one of these multiple Advertisements SHOULD 3526 include a Prefix Information option with the Router Address (R) bit 3527 set. 3529 6.3. New Advertisement Interval Option Format 3531 Mobile IPv6 defines a new Advertisement Interval option, used in 3532 Router Advertisement messages to advertise the interval at which the 3533 sending router sends unsolicited multicast Router Advertisements. 3534 The format of the Advertisement Interval option is as follows: 3536 0 1 2 3 3537 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 3538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3539 | Type | Length | Reserved | 3540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3541 | Advertisement Interval | 3542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3544 Type 3546 7 3548 Length 3550 8-bit unsigned integer. The length of the option (including 3551 the type and length fields) in units of 8 octets. The value of 3552 this field MUST be 1. 3554 Reserved 3556 This field is unused. It MUST be initialized to zero by the 3557 sender and MUST be ignored by the receiver. 3559 Advertisement Interval 3561 32-bit unsigned integer. The maximum time, in milliseconds, 3562 between successive unsolicited router Router Advertisement 3563 messages sent by this router on this network interface. Using 3564 the conceptual router configuration variables defined by 3565 Neighbor Discovery [20], this field MUST be equal to the value 3566 MaxRtrAdvInterval, expressed in milliseconds. 3568 Routers MAY include this option in their Router Advertisements. A 3569 mobile node receiving a Router Advertisement containing this option 3570 SHOULD utilize the specified Advertisement Interval for that router 3571 in its movement detection algorithm, as described in Section 10.4. 3573 This option MUST be silently ignored for other Neighbor Discovery 3574 messages. 3576 6.4. New Home Agent Information Option Format 3578 Mobile IPv6 defines a new Home Agent Information option, used in 3579 Router Advertisement messages sent by a home agent to advertise 3580 information specific to this router's functionality as a home agent. 3581 The format of the Home Agent Information option is as follows: 3583 0 1 2 3 3584 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 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3586 | Type | Length | Reserved | 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3588 | Home Agent Preference | Home Agent Lifetime | 3589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3591 Type 3593 8 3595 Length 3597 8-bit unsigned integer. The length of the option (including 3598 the type and length fields) in units of 8 octets. The value of 3599 this field MUST be 1. 3601 Reserved 3603 This field is unused. It MUST be initialized to zero by the 3604 sender and MUST be ignored by the receiver. 3606 Home Agent Preference 3608 16-bit signed, twos-complement integer. The preference for 3609 the home agent sending this Router Advertisement, for use in 3610 ordering the addresses returned to a mobile node in the Home 3611 Agent Addresses field of a Home Agent Address Discovery Reply 3612 message. Higher values mean more preferable. If this option 3613 is not included in a Router Advertisement in which the Home 3614 Agent (H) bit is set, the preference value for this home agent 3615 SHOULD be considered to be 0. Values greater than 0 indicate a 3616 home agent more preferable than this default value, and values 3617 less than 0 indicate a less preferable home agent. 3619 The manual configuration of the Home Agent Preference value 3620 is described in Section 7.2. In addition, the sending home 3621 agent MAY dynamically set the Home Agent Preference value, for 3622 example basing it on the number of mobile nodes it is currently 3623 serving or on its remaining resources for serving additional 3624 mobile nodes; such dynamic settings are beyond the scope of 3625 this document. Any such dynamic setting of the Home Agent 3626 Preference, however, MUST set the preference appropriately, 3627 relative to the default Home Agent Preference value of 0 that 3628 may be in use by some home agents on this link (i.e., a home 3629 agent not including a Home Agent Information option in its 3630 Router Advertisements will be considered to have a Home Agent 3631 Preference value of 0). 3633 Home Agent Lifetime 3635 16-bit unsigned integer. The lifetime associated with the 3636 home agent in units of seconds. The default value is the same 3637 as the Router Lifetime, as specified in the main body of the 3638 Router Advertisement message. The maximum value corresponds 3639 to 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 3640 Lifetime applies only to this router's usefulness as a home 3641 agent; it does not apply to information contained in other 3642 message fields or options. 3644 Home agents MAY include this option in their Router Advertisements. 3645 This option MUST NOT be included in a Router Advertisement in which 3646 the Home Agent (H) bit (see Section 6.1) is not set. If this option 3647 is not included in a Router Advertisement in which the Home Agent (H) 3648 bit is set, the lifetime for this home agent MUST be considered to be 3649 the same as the Router Lifetime in the Router Advertisement. 3651 This option MUST be silently ignored for other Neighbor Discovery 3652 messages. 3654 If both the Home Agent Preference and Home Agent Lifetime are set 3655 to their default values specified above, this option SHOULD NOT be 3656 included in the Router Advertisement messages sent by this home 3657 agent. 3659 6.5. Changes to Sending Router Advertisements 3661 The Neighbor Discovery protocol specification [20] limits routers to 3662 a minimum interval of 3 seconds between sending unsolicited multicast 3663 Router Advertisement messages from any given network interface 3664 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 3666 "Routers generate Router Advertisements frequently enough 3667 that hosts will learn of their presence within a few 3668 minutes, but not frequently enough to rely on an absence 3669 of advertisements to detect router failure; a separate 3670 Neighbor Unreachability Detection algorithm provides failure 3671 detection." 3673 This limitation, however, is not suitable to providing timely 3674 movement detection for mobile nodes. Mobile nodes detect their 3675 own movement by learning the presence of new routers as the mobile 3676 node moves into wireless transmission range of them (or physically 3677 connects to a new wired network), and by learning that previous 3678 routers are no longer reachable. Mobile nodes MUST be able to 3679 quickly detect when they move to a link served by a new router, so 3680 that they can acquire a new care-of address and send Binding Updates 3681 to register this care-of address with their home agent and to notify 3682 correspondent nodes as needed. 3684 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 3685 this limit such that routers MAY send unsolicited multicast Router 3686 Advertisements more frequently. In particular, on network interfaces 3687 where the router is expecting to provide service to visiting mobile 3688 nodes (e.g., wireless network interfaces), or on which it is serving 3689 as a home agent to one or more mobile nodes (who may return home and 3690 need to hear its Advertisements), the router SHOULD be configured 3691 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 3692 to allow sending of unsolicited multicast Router Advertisements more 3693 often. Recommended values for these limits are: 3695 - MinRtrAdvInterval 0.05 seconds 3697 - MaxRtrAdvInterval 1.5 seconds 3699 Use of these modified limits MUST be configurable, and specific 3700 knowledge of the type of network interface in use SHOULD be taken 3701 into account in configuring these limits for each network interface. 3703 When sending unsolicited multicast Router Advertisements more 3704 frequently than the standard limit on unsolicited multicast 3705 Advertisement frequency, the sending router need not include all 3706 options in each of these Advertisements, but it SHOULD include at 3707 least one Prefix Information option with the Router Address (R) bit 3708 set (Section 6.2) in each. 3710 6.6. Changes to Sending Router Solicitations 3712 In addition to the limit on routers sending unsolicited multicast 3713 Router Advertisement messages (Section 6.5), Neighbor Discovery 3714 defines limits on nodes sending Router Solicitation messages, such 3715 that a node SHOULD send no more than 3 Router Solicitations, and that 3716 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 3717 However, these limits prevent a mobile node from finding a new 3718 default router (and thus a new care-of address) quickly as it moves 3719 about. 3721 Mobile IPv6 relaxes this limit such that, while a mobile node is away 3722 from home, it MAY send Router Solicitations more frequently. The 3723 following limits for sending Router Solicitations are recommended for 3724 mobile nodes while away from home: 3726 - A mobile node that is not configured with any current care-of 3727 address (e.g., the mobile node has moved since its previous 3728 care-of address was configured), MAY send more than the defined 3729 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 3730 Solicitations. 3732 - The rate at which a mobile node sends Router Solicitations MUST 3733 be limited, although a mobile node MAY send Router Solicitations 3734 more frequently than the defined Neighbor Discovery limit of 3735 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 3736 be configurable, and specific knowledge of the type of network 3737 interface in use SHOULD be taken into account in configuring this 3738 limit for each network interface. A recommended minimum interval 3739 is 1 second. 3741 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 3742 a mobile node MUST reduce the rate at which it sends subsequent 3743 Router Solicitations. Subsequent Router Solicitations SHOULD 3744 be sent using a binary exponential backoff mechanism, doubling 3745 the interval between consecutive Router Solicitations, up to a 3746 maximum interval. The maximum interval MUST be configurable and 3747 SHOULD be chosen appropriately based on the characteristics of 3748 the type of network interface in use. 3750 - While still searching for a new default router and care-of 3751 address, a mobile node MUST NOT increase the rate at which it 3752 sends Router Solicitations unless it has received a positive 3753 indication (such as from lower network layers) that it has moved 3754 to a new link. After successfully acquiring a new care-of 3755 address, the mobile node SHOULD also increase the rate at which 3756 it will send Router Solicitations when it next begins searching 3757 for a new default router and care-of address. 3759 - A mobile node that is currently configured with a care-of address 3760 SHOULD NOT send Router Solicitations to the default router 3761 on it current link, until its movement detection algorithm 3762 (Section 10.4) determines that it has moved and that its current 3763 care-of address might no longer be valid. 3765 7. Requirements for Types of IPv6 Nodes 3767 Mobile IPv6 places some special requirements on the functions 3768 provided by different types of IPv6 nodes. This section summarizes 3769 those requirements, identifying the functionality each requirement 3770 is intended to support. Further details on this functionality is 3771 provided in the following sections. 3773 7.1. Requirements for All IPv6 Routers 3775 The following requirements apply to all IPv6 routers, even those not 3776 serving as a home agent for Mobile IPv6: 3778 - Every IPv6 router SHOULD be able to send an Advertisement 3779 Interval option in each of its Router Advertisements, to aid 3780 movement detection by mobile nodes. The use of this option in 3781 Router Advertisements MUST be configurable. 3783 - Every IPv6 router SHOULD be able to support sending unsolicited 3784 multicast Router Advertisements at the faster rate described in 3785 Section 6.5. The use of this faster rate MUST be configurable. 3787 - Each router SHOULD include at least one prefix with the 'R' bit 3788 set and with its full IP address in its router advertisements. 3790 - Filtering routers SHOULD be able to have different rules for 3791 routing header type 2 than for other routing headers so that 3792 type 2 can be allowed in order to allow Mobile IPv6 traffic 3793 while still having the option to filter out other use of routing 3794 headers. 3796 7.2. Requirements for IPv6 Home Agents 3798 In order for a mobile node to operate correctly while away from home, 3799 at least one IPv6 router on the mobile node's home link must function 3800 as a home agent for the mobile node. The following additional 3801 requirements apply to all IPv6 routers capable of serving as a home 3802 agent: 3804 - Every home agent MUST be able to maintain an entry in its Binding 3805 Cache for each mobile node for which it is serving as the home 3806 agent. Each such Binding Cache entry records the mobile node's 3807 binding with its primary care-of address and is marked as a "home 3808 registration". 3810 - Every home agent MUST be able to intercept packets (using proxy 3811 Neighbor Discovery) addressed to a mobile node for which it is 3812 currently serving as the home agent, on that mobile node's home 3813 link, while the mobile node is away from home. 3815 - Every home agent MUST be able to encapsulate such intercepted 3816 packets in order to tunnel them to the primary care-of address 3817 for the mobile node indicated in its binding in the home agent's 3818 Binding Cache. 3820 - Every home agent MUST be able to return a Binding Acknowledgement 3821 option in response to a Binding Update option received with the 3822 Acknowledge (A) bit set. 3824 - Every home agent MUST maintain a separate Home Agents List for 3825 each link on which it is serving as a home agent, as described in 3826 Section 4.7. 3828 - Every home agent MUST be able to accept packets addressed to 3829 the "Mobile IPv6 Home-Agents" anycast address for the subnet 3830 on which it is serving as a home agent [11], and MUST be 3831 able to participate in dynamic home agent address discovery 3832 (Section 9.9). 3834 - Every home agent SHOULD support a configuration mechanism to 3835 allow a system administrator to manually set the value to be sent 3836 by this home agent in the Home Agent Preference field of the Home 3837 Agent Information Option in Router Advertisements that it sends. 3839 - Every home agent SHOULD support sending ICMP Mobile 3840 Prefix Advertisements, and SHOULD respond to Mobile Prefix 3841 Solicitations. 3843 7.3. Requirements for IPv6 Mobile Nodes 3845 Finally, the following requirements apply to all IPv6 nodes capable 3846 of functioning as mobile nodes: 3848 - Every IPv6 mobile node MUST be able to perform IPv6 3849 decapsulation [4]. 3851 - Every IPv6 mobile node MUST support sending Binding Update 3852 options, as specified in Sections 10.7, 10.9, and 10.11; and MUST 3853 be able to receive and process Binding Acknowledgement options, 3854 as specified in Section 10.14. 3856 - Every IPv6 mobile node MUST support use of the dynamic home agent 3857 address discovery mechanism, as described in Section 10.8. 3859 - Every IPv6 mobile node MUST maintain a Binding Update List in 3860 which it records the IP address of each other node to which it 3861 has sent a Binding Update, for which the Lifetime sent in that 3862 binding has not yet expired. 3864 - Every IPv6 mobile node MUST support receiving a Binding Request 3865 option, by responding with a Binding Update option. 3867 - Every IPv6 mobile node MUST support sending packets containing a 3868 Home Address option; this option MUST be included in all packets 3869 sent while away from home, if the packet would otherwise have 3870 been sent with the mobile node's home address as the IP Source 3871 Address. 3873 - Every IPv6 mobile node MUST maintain a Home Agents List, as 3874 described in Section 4.7. 3876 - Every mobile node MUST support receiving Mobile Prefix 3877 Advertisements and reconfiguring its home address based on the 3878 prefix information contained therein. 3880 8. Correspondent Node Operation 3882 A correspondent node is any node communicating with a mobile node. 3883 The correspondent node, itself, may be stationary or mobile, and may 3884 possibly also be functioning as a home agent for Mobile IPv6. The 3885 procedures in this section thus apply to all IPv6 nodes. 3887 8.1. Receiving Packets from a Mobile Node 3889 Packets sent by a mobile node while away from home generally include 3890 a Home Address option. When any node receives a packet containing 3891 a Home Address option, it MUST process the option in a manner 3892 consistent with exchanging the Home Address field from the Home 3893 Address option into the IPv6 header, replacing the original value of 3894 the Source Address field there. However, any actual modifications to 3895 the Source Address field in the packet's IPv6 header MUST be carried 3896 out in such a fashion that further processing of such a packet after 3897 all IPv6 options processing (e.g., at the transport layer) does not 3898 need to know that the original Source Address was a care-of address, 3899 or that the Home Address option was used in the packet. 3901 Since the sending mobile node uses its home address at the transport 3902 layer when sending such a packet, the use of the care-of address 3903 and Home Address option is transparent to both the mobile node and 3904 the correspondent node above the level of the Home Address option 3905 generation and processing. 3907 8.2. Receiving Binding Updates 3909 Before accepting a Binding Update option received in any packet, the 3910 receiving node MUST validate the Binding Update according to the 3911 following tests: 3913 - The packet meets the specific authentication requirements for 3914 Binding Updates, defined in Section 4.5. 3916 - The packet MUST contain a Home Address option. 3918 - The Option Length field in the Binding Update option is greater 3919 than or equal to the length specified in Section 5.1.7. 3921 - The Sequence Number field in the Binding Update option is greater 3922 than the Sequence Number received in the previous Binding Update 3923 for this home address, if any. As noted in Section 4.7, this 3924 Sequence Number comparison MUST be performed modulo 2**8. 3926 If the mobile node sends a sequence number which is not greater than 3927 the sequence number from the last successful Binding Update, then the 3928 receiving node MUST send back a Binding Acknowledgement with status 3929 code 141, and the last accepted sequence number in the Sequence 3930 Number field of the Binding Acknowledgement. 3932 Any Binding Update which fails to satisfy all of these tests for any 3933 other reason (than insufficiency of the Sequence Number) MUST be 3934 silently ignored, and the packet carrying the Binding Update MUST be 3935 discarded. 3937 In this section, the care-of address refers to the IPv6 address, 3938 which was originally located in the IPv6 header when the packet was 3939 transmitted by the mobile node. 3941 If the Binding Update is valid according to the tests above, then the 3942 Binding Update is processed further as follows: 3944 - If the Lifetime specified in the Binding Update is nonzero and 3945 the specified Care-of Address is not equal to the home address 3946 for the binding, then this is a request to cache a binding for 3947 the mobile node. If the Home Registration (H) bit is set in the 3948 Binding Update, the Binding Update is processed according to the 3949 procedure specified in Section 9.1; otherwise, it is processed 3950 according to the procedure specified in Section 8.3. 3952 - If the Lifetime specified in the Binding Update is zero or the 3953 specified Care-of Address matches the home address for the 3954 binding, then this is a request to delete the mobile node's 3955 cached binding. If the Home Registration (H) bit is set in the 3956 Binding Update, the Binding Update is processed according to the 3957 procedure specified in Section 9.2; otherwise, it is processed 3958 according to the procedure specified in Section 8.4. 3960 8.3. Requests to Cache a Binding 3962 When a node receives a Binding Update, it MUST validate it and 3963 determine the type of Binding Update according to the steps described 3964 in Section 8.2. This section describes the processing of a valid 3965 Binding Update that requests a node to cache a mobile node's binding, 3966 for which the Home Registration (H) bit is not set in the Binding 3967 Update. 3969 In this case, the receiving node SHOULD create a new entry in its 3970 Binding Cache for this mobile node (or update its existing Binding 3971 Cache entry for this mobile node, if such an entry already exists). 3972 The new Binding Cache entry records the association between this 3973 home address and the care-of address for the binding. The lifetime 3974 for the Binding Cache entry is initialized from the Lifetime field 3975 specified in the Binding Update, although this lifetime MAY be 3976 reduced by the node caching the binding; the lifetime for the Binding 3977 Cache entry MUST NOT be greater than the Lifetime value specified in 3978 the Binding Update. Any Binding Cache entry MUST be deleted after 3979 the expiration of this lifetime in the Binding Cache entry. 3981 8.4. Requests to Delete a Binding 3983 When a node receives a Binding Update, it MUST validate it and 3984 determine the type of Binding Update according to the steps described 3985 in Section 8.2. This section describes the processing of a valid 3986 Binding Update that requests a node to delete a mobile node's binding 3987 from its Binding Cache, for which the Home Registration (H) bit is 3988 not set in the Binding Update. In this case, the receiving node MUST 3989 delete any existing entry in its Binding Cache for this mobile node. 3991 8.5. Sending Binding Acknowledgements 3993 When any node receives a packet containing a Binding Update option 3994 in which the Acknowledge (A) bit is set, it MUST return a Binding 3995 Acknowledgement option acknowledging receipt of the Binding Update. 3996 If the node accepts the Binding Update and creates or updates 3997 an entry in its Binding Cache for this binding, and the `A' bit 3998 was set in the Binding Update, the Status field in the Binding 3999 Acknowledgement MUST be set to a value less than 128; if, on the 4000 other hand the Binding Update is accepted and the `A' bit is not set, 4001 the node SHOULD NOT send a Binding Acknowledgement. If the node 4002 rejects the Binding Update and does not create or update an entry for 4003 this binding, a Binding Acknowledgement MUST be sent even if the `A' 4004 bit was not sent, and the Status field in the Binding Acknowledgement 4005 MUST be set to a value greater than or equal to 128. Specific values 4006 for the Status field are described in Section 5.1.8 and in the most 4007 recent "Assigned Numbers" [10]. 4009 The packet in which the Binding Acknowledgement is returned 4010 MUST meet the specific authentication requirements for Binding 4011 Acknowledgements, defined in Section 4.5. Furthermore, if the packet 4012 is to be sent to the mobile node at any address other than the mobile 4013 node's home address, it MUST be sent using a Routing header (even if 4014 the binding was rejected). The intermediate IP address, to which 4015 the packet will be delivered immediately before the home address, is 4016 determined as follows: 4018 - Whenever the Binding Update is accepted with a nonzero lifetime, 4019 the routing header will be constructed using the care-of address 4020 as described in Section 8.9. 4022 - Otherwise, if the Source IP Address of the packet containing 4023 the Binding Update, is legal for inclusion in a Routing Header, 4024 the routing header will be constructed using that IP address. 4025 Note that multicast addresses, link-local addresses, loopback 4026 addresses, IPv4 mapped addresses, and the unspecified address, 4027 MUST NOT be used within a Routing Header for the Binding 4028 Acknowledgement. 4030 - Otherwise, if the Binding Update has a zero lifetime but the 4031 Source IP address is not allowable for use within the Routing 4032 Header, the Binding Acknowledgment MUST be sent to the mobile 4033 node's home address. 4035 In response to a Binding Update, a node MAY send a Binding 4036 Acknowledgement even when the 'A' bit is not set in the Binding 4037 Update. This would happen, for instance, if a mobile node attempted 4038 to send a Binding Update with the 'H' bit set to a correspondent 4039 node. 4041 8.6. Sending Binding Requests 4043 Entries in a node's Binding Cache MUST be deleted when their lifetime 4044 expires. If such an entry is still in active use in sending packets 4045 to a mobile node, the next packet sent to the mobile node will be 4046 routed normally to the mobile node's home link, where it will be 4047 intercepted and tunneled to the mobile node. The mobile node will 4048 then return a Binding Update to the sender, allowing it to create 4049 a new Binding Cache entry for sending future packets to the mobile 4050 node. Communication with the mobile node continues uninterrupted, 4051 but the forwarding of this packet through the mobile node's home 4052 agent creates additional overhead and latency in delivering packets 4053 to the mobile node. Such routing paths could, for instance, 4054 temporarily or permanently disrupt any negotiated Quality of Service 4055 reservations which had been made by the mobile node on its home 4056 network. 4058 If the sender knows that the Binding Cache entry is still in active 4059 use, it MAY send a Binding Request option to the mobile node in 4060 an attempt to avoid this overhead and latency due to deleting and 4061 recreating the Binding Cache entry. Since a Binding Request is a 4062 destination option, it may, for example, be included in any packet 4063 already being sent to the mobile node, such as a packet that is part 4064 of ongoing TCP communication with the mobile node. When the mobile 4065 node receives a packet from some sender containing a Binding Request 4066 option, it returns a Binding Update option to that sender, giving its 4067 current binding and a new lifetime. 4069 8.7. Cache Replacement Policy 4071 Conceptually, a node maintains a separate timer for each entry in its 4072 Binding Cache. When creating or updating a Binding Cache entry in 4073 response to a received and accepted Binding Update, the node sets the 4074 timer for this entry to the specified Lifetime period. Any entry in 4075 a node's Binding Cache MUST be deleted after the expiration of the 4076 Lifetime specified in the Binding Update from which the entry was 4077 created or last updated. 4079 Each node's Binding Cache will, by necessity, have a finite size. 4080 A node MAY use any reasonable local policy for managing the space 4081 within its Binding Cache, except that any entry marked as a "home 4082 registration" (Section 9.1) MUST NOT be deleted from the cache 4083 until the expiration of its lifetime period. When such a "home 4084 registration" entry is deleted, in addition the home agent MUST also 4085 cease intercepting packets on the mobile node's home link addressed 4086 to the mobile node (Section 9.3), just as if the mobile node had 4087 deregistered its primary care-of address (see Section 9.2). 4089 When attempting to add a new "home registration" entry in response 4090 to a Binding Update with the Home Registration (H) bit set, if 4091 insufficient space exists (and sufficient space cannot be reclaimed) 4092 in the node's Binding Cache, the node MUST reject the Binding 4093 Update and SHOULD return a Binding Acknowledgement to the sending 4094 mobile node, in which the Status field is set to 131 (insufficient 4095 resources). When otherwise attempting to add a new entry to its 4096 Binding Cache, a node MAY, if needed, choose to drop any entry 4097 already in its Binding Cache, other than a "home registration" 4098 entry, in order to make space for the new entry. For example, a 4099 "least-recently used" (LRU) strategy for cache entry replacement 4100 among entries not marked as a "home registration" is likely to 4101 work well unless the size of the Binding Cache is substantially 4102 insufficient. 4104 Any binding dropped from a node's Binding Cache due to lack of cache 4105 space will be rediscovered and a new cache entry created, if the 4106 binding is still in active use by the node for sending packets. If 4107 the node sends a packet to a destination for which it has dropped the 4108 entry from its Binding Cache, the packet will be routed normally, 4109 leading to the mobile node's home link. There, the packet will be 4110 intercepted by the mobile node's home agent and tunneled to the 4111 mobile node's current primary care-of address. As when a Binding 4112 Cache entry is initially created, this indirect routing to the mobile 4113 node through its home agent will result in the mobile node sending 4114 a Binding Update to this sending node when it receives the tunneled 4115 packet, allowing it to add an entry again for this destination mobile 4116 node to its Binding Cache. 4118 8.8. Receiving ICMP Error Messages 4120 When a correspondent node sends a packet to a mobile node, if the 4121 correspondent node has a Binding Cache entry for the destination 4122 address of the packet, then the correspondent node uses a Routing 4123 header to deliver the packet to the mobile node through the care-of 4124 address in the binding recorded in the Binding Cache entry. Any ICMP 4125 error message caused by the packet on its way to the mobile node will 4126 be returned normally to the correspondent node. 4128 On the other hand, if the correspondent node has no Binding Cache 4129 entry for the mobile node, the packet will be routed to the mobile 4130 node's home link. There, it will be intercepted by the mobile node's 4131 home agent, encapsulated, and tunneled to the mobile node's primary 4132 care-of address. Any ICMP error message caused by the packet on 4133 its way to the mobile node while in the tunnel, will be transmitted 4134 to the mobile node's home agent (the source of the tunnel). By 4135 the definition of IPv6 encapsulation [4], the home agent (as the 4136 encapsulating node) MUST relay certain ICMP error messages back 4137 to the original sender of the packet, which in this case is the 4138 correspondent node. 4140 Likewise, if a packet for a mobile node arrives at the mobile node's 4141 previous link and is intercepted there by a home agent for the mobile 4142 node's previous care-of address as described in Section 10.11 (e.g., 4143 the mobile node moved after the packet was sent), that home agent 4144 will encapsulate and tunnel the packet to the mobile node's new 4145 care-of address. As above, any ICMP error message caused by the 4146 packet while in this tunnel will be returned to that home agent (the 4147 source of the tunnel), which MUST relay certain ICMP error messages 4148 back to the correspondent node [4]. The relayed packet MUST NOT 4149 contain a routing header entry with the care-of address of the mobile 4150 node. 4152 Thus, in all cases, any meaningful ICMP error messages caused 4153 by packets from a correspondent node to a mobile node will be 4154 returned to the correspondent node. If the correspondent node 4155 receives persistent ICMP Destination Unreachable messages after 4156 sending packets to a mobile node based on an entry in its Binding 4157 Cache, the correspondent node MUST delete this Binding Cache 4158 entry. If the correspondent node subsequently transmits another 4159 packet to the mobile node, the packet will be routed to the mobile 4160 node's home link, intercepted by the mobile node's home agent, and 4161 tunneled to the mobile node's primary care-of address using IPv6 4162 encapsulation. The mobile node will then return a Binding Update to 4163 the correspondent node, allowing it to recreate a (correct) Binding 4164 Cache entry for the mobile node. 4166 8.9. Sending Packets to a Mobile Node 4168 Before sending any packet, the sending node SHOULD examine its 4169 Binding Cache for an entry for the destination address to which the 4170 packet is being sent. If the sending node has a Binding Cache entry 4171 for this address, the sending node SHOULD use a Routing header to 4172 route the packet to this mobile node (the destination node) by way 4173 of the care-of address in the binding recorded in that Binding Cache 4174 entry. For example, assuming use of a Type 0 Routing header [6], if 4175 no other use of a Routing header is involved in the routing of this 4176 packet, the mobile node sets the fields in the packet's IPv6 header 4177 and Routing header as follows: 4179 - The Destination Address in the packet's IPv6 header is set to 4180 the mobile node's care-of address copied from the Binding Cache 4181 entry. 4183 - The Routing header is initialized to contain a single route 4184 segment, with an Address of the mobile node's home address (the 4185 original destination address to which the packet was being sent). 4187 Following the definition of a Type 0 Routing header [6], this packet 4188 will be routed to the mobile node's care-of address, where it will 4189 be delivered to the mobile node (the mobile node has associated the 4190 care-of address with its network interface). Normal processing of 4191 the Routing header by the mobile node will then proceed as follows: 4193 - The mobile node swaps the Destination Address in the packet's 4194 IPv6 header and the Address specified in the Routing header. 4195 This results in the packet's IP Destination Address being set to 4196 the mobile node's home address. 4198 - The mobile node then resubmits the packet to its IPv6 module for 4199 further processing, "looping back" the packet inside the mobile 4200 node. Since the mobile node recognizes its own home address as 4201 one of its current IP addresses, the packet is processed further 4202 within the mobile node, in the same way then as if the mobile 4203 node was at home. 4205 If, instead, the sending node has no Binding Cache entry for the 4206 destination address to which the packet is being sent, the sending 4207 node simply sends the packet normally, with no Routing header. If 4208 the destination node is not a mobile node (or is a mobile node that 4209 is currently at home), the packet will be delivered directly to this 4210 node and processed normally by it. If, however, the destination node 4211 is a mobile node that is currently away from home, the packet will 4212 be intercepted by the mobile node's home agent and tunneled (using 4213 IPv6 encapsulation [4]) to the mobile node's current primary care-of 4214 address, as described in Section 9.4. The mobile node will then send 4215 a Binding Update to the sending node, as described in Section 10.9, 4216 allowing the sending node to create a Binding Cache entry for its use 4217 in sending subsequent packets to this mobile node. 4219 It is possible that a correspondent node, having no knowledge 4220 of the mobile node's care-of address, would still (for reasons 4221 unspecified here but not necessarily related to mobility) attempt 4222 to deliver a packet, either to or by way of the mobile node's home 4223 address, by using a routing header. If the correspondent node 4224 subsequently accepts a Binding Update and creates a Binding Cache 4225 entry for the mobile node, then afterwards, the routing header used 4226 by the corresponding node which includes the mobile node's home 4227 address SHOULD also include the mobile node's care-of address. The 4228 correspondent node SHOULD put the mobile node's care-of address as 4229 the intermediate node address immediately preceding the mobile node's 4230 home address. When the care-of address is the first intermediate 4231 node address, this implies that the care-of address is to be placed 4232 in the Destination Address of the IPv6 header, and the mobile 4233 node's home address is the first entry in the type 0 routing header. 4234 Otherwise, the correspondent node MUST insert the mobile node's 4235 care-of address immediately before the home address entry in the 4236 routing header. 4238 9. Home Agent Operation 4240 9.1. Primary Care-of Address Registration 4242 When a node receives a Binding Update, it MUST validate it and 4243 determine the type of Binding Update according to the steps described 4244 in Section 8.2. This section describes the processing of a valid 4245 Binding Update that requests the receiving node to serve as its home 4246 agent, registering its primary care-of address. 4248 To begin processing the Binding Update, the home agent MUST perform 4249 the following sequence of tests: 4251 - If the node is not a router that implements home agent 4252 functionality, then the node MUST reject the Binding Update and 4253 SHOULD return a Binding Acknowledgement to the mobile node, in 4254 which the Status field is set to 132 (home registration not 4255 supported). 4257 - Else, if the home address for the binding (the Home Address field 4258 in the packet's Home Address option) is not an on-link IPv6 4259 address with respect to the home agent's current Prefix List, 4260 then the home agent MUST reject the Binding Update and SHOULD 4261 return a Binding Acknowledgement to the mobile node, in which the 4262 Status field is set to 133 (not home subnet). 4264 - Else, if the home agent chooses to reject the Binding Update for 4265 any other reason (e.g., insufficient resources to serve another 4266 mobile node as a home agent), then the home agent SHOULD return a 4267 Binding Acknowledgement to the mobile node, in which the Status 4268 field is set to an appropriate value to indicate the reason for 4269 the rejection. 4271 - Finally, if the Duplicate Address Detection (D) bit is set in 4272 the Binding Update, this home agent MUST ensure that Duplicate 4273 Address Detection [35] has been performed on the mobile node's 4274 home link for the link-local address associated with the home 4275 address in this binding, and thus to ensure that no other node 4276 on the home link can possibly use the mobile node's home address 4277 (before returning the Binding Acknowledgement). The address 4278 used for Duplicate Address Detection SHOULD be the mobile node's 4279 link-local address. Normal processing for Duplicate Address 4280 Detection specifies that, in certain cases, the node SHOULD 4281 delay sending the initial Neighbor Solicitation message of 4282 Duplicate Address Detection by a random delay between 0 and 4283 MAX_RTR_SOLICITATION_DELAY [20, 35]; however, in this case, the 4284 home agent SHOULD NOT perform such a delay. If this Duplicate 4285 Address Detection fails, then the home agent MUST reject the 4286 Binding Update and SHOULD return a Binding Acknowledgement 4287 to the mobile node, in which the Status field is set to 138 4288 (Duplicate Address Detection failed). When the home agent sends 4289 a successful Binding Acknowledgement to the mobile node, in 4290 response to a Binding Update with the `D' bit set, the home agent 4291 assures to the mobile node that its home address will continue to 4292 be valid at least as long as the mobile node transmits Binding 4293 Updates with new care-of addresses for that home address. 4295 If the home agent does not reject the Binding Update, then it becomes 4296 or remains the home agent for the mobile node. The home agent MUST 4297 then create a new entry in its Binding Cache for this mobile node (or 4298 update its existing Binding Cache entry for this mobile node, if such 4299 an entry already exists). The home address of the mobile node is 4300 taken to be the value which, when the packet was originally received, 4301 was located in the Home Address field in the packet's Home Address 4302 option. The care-of address for this Binding Cache entry is taken 4303 to be the value which, when the packet was originally received, was 4304 located either in the Alternate Care-of Address sub-option in the 4305 Binding Update option, if present, or from the Source Address field 4306 in the packet's IPv6 header, otherwise. 4308 The home agent MUST mark this Binding Cache entry as a "home 4309 registration" to indicate that the node is serving as a home 4310 agent for this binding. Binding Cache entries marked as a "home 4311 registration" MUST be excluded from the normal cache replacement 4312 policy used for the Binding Cache (Section 8.7) and MUST NOT be 4313 removed from the Binding Cache until the expiration of the Lifetime 4314 period. 4316 The lifetime for the Binding Cache entry MUST NOT be greater than the 4317 remaining valid lifetime for the subnet prefix in the mobile node's 4318 home address specified with the Binding Update, and MUST NOT be 4319 greater than the Lifetime value specified in the Binding Update. The 4320 remaining valid lifetime for this prefix is determined by the home 4321 agent based on its own Prefix List entry for this prefix [20]. 4323 If the `S' bit field in the Binding Update is zero, The Home Agent 4324 creates or updates Binding Cache entries for each of possible 4325 several home addresses. The set of such home addresses is formed 4326 by replacing the routing prefix for the given home address with 4327 all other routing prefixes that are supported by the home agent 4328 processing the Binding Update. The Home Agent creates such a 4329 separate primary care-of address registration for each such home 4330 address. Note that the same considerations for Duplicate Address 4331 Detection apply for each affected home address. The lifetime for 4332 the each Binding Cache entry MUST NOT be greater than the minimum 4333 remaining valid lifetime for all subnet prefixes on the mobile 4334 node's home link. If the value of the Lifetime field specified by 4335 the mobile node in its Binding Update is greater than this prefix 4336 lifetime, the home agent MUST decrease the binding lifetime to less 4337 than or equal to the prefix valid lifetime. The home agent MAY 4338 further decrease the specified lifetime for the binding, for example 4339 based on a local policy. The resulting lifetime is stored by the 4340 home agent in the Binding Cache entry, and this Binding Cache entry 4341 MUST be deleted by the home agent after the expiration of this 4342 lifetime. 4344 Regardless of the setting of the 'A' bit in the Binding Update, the 4345 home agent MUST return a Binding Acknowledgement to the mobile node, 4346 constructed as follows: 4348 - The Status field MUST be set to a value indicating success; this 4349 value MUST be less than 128. The only currently defined success 4350 Status value is 0, indicating simply that the Binding Update was 4351 accepted. 4353 - The Sequence Number field MUST be copied from the Sequence Number 4354 given in the Binding Update. 4356 - The Lifetime field MUST be set to the remaining lifetime for 4357 the binding as set by the home agent in its "home registration" 4358 Binding Cache entry for the mobile node, as described above. 4360 - The Refresh field MUST be set to a value less than or equal to 4361 the Lifetime value being returned in the Binding Update. If the 4362 home agent stores the Binding Cache entry in nonvolatile storage 4363 (that survives the crash or other failure of the home agent), 4364 then the Refresh field SHOULD be set to the same value as the 4365 Lifetime field; otherwise, the home agent MAY set the Refresh 4366 field to a value less than the Lifetime field, to indicate that 4367 the mobile node SHOULD attempt to refresh its home registration 4368 at the indicated shorter interval (although the home agent will 4369 still retain the registration for the Lifetime period, even if 4370 the mobile node does not refresh its registration within the 4371 Refresh period). 4373 In addition, the home agent MUST follow the procedure defined in 4374 Section 9.3 to intercept packets on the mobile node's home link 4375 addressed to the mobile node, while the home agent is serving as the 4376 home agent for this mobile node. 4378 9.2. Primary Care-of Address De-Registration 4380 When a node receives a Binding Update, it MUST validate it and 4381 determine the type of Binding Update according to the steps described 4382 in Section 8.2. This section describes the processing of a valid 4383 Binding Update that requests the receiving node to no longer serve as 4384 its home agent, de-registering its primary care-of address. 4386 To begin processing the Binding Update, the home agent MUST perform 4387 the following test: 4389 - If the receiving node has no entry in its Binding Cache for this 4390 mobile node that is marked as a "home registration", then this 4391 node MUST reject the Binding Update and SHOULD return a Binding 4392 Acknowledgement to the mobile node, in which the Status field is 4393 set to 137 (not home agent for this mobile node). 4395 If the home agent does not reject the Binding Update as described 4396 above, then it MUST delete any existing entry in its Binding Cache 4397 for this mobile node, and proceed as follows. 4399 The home agent MUST return a Binding Acknowledgement to the mobile 4400 node, constructed as follows: 4402 - The Status field MUST be set to a value indicating success (the 4403 value MUST be less than 128). The only currently defined success 4404 Status value is 0, indicating simply that the Binding Update was 4405 accepted. 4407 - The Sequence Number field MUST be copied from the Sequence Number 4408 given in the Binding Update. 4410 - The Lifetime field MUST be set to zero. 4412 - The Refresh field MUST be set to zero. 4414 In addition, the home agent MUST stop intercepting packets on the 4415 mobile node's home link addressed to the mobile node (Section 9.3). 4417 The rules for selecting the Destination IP address (and possibly 4418 Routing Header construction) for the Binding Acknowledgement to the 4419 mobile node are the same as in section 8.5. 4421 9.3. Intercepting Packets for a Mobile Node 4423 While a node is serving as the home agent for mobile node (while the 4424 node has an entry in its Binding Cache for this mobile node that is 4425 marked as a "home registration"), this node MUST attempt to intercept 4426 packets on the mobile node's home link addressed to the mobile node, 4427 and MUST tunnel each intercepted packet to the mobile node using 4428 using IPv6 encapsulation [4]. 4430 In order to intercept such packets on the home link, when a node 4431 begins serving as the home agent for some mobile node (it did not 4432 already have a Binding Cache entry for this mobile node marked as a 4433 "home registration"), then the home agent MUST multicast onto the 4434 home link a "gratuitous" Neighbor Advertisement message [20] on 4435 behalf of the mobile node. Specifically, the home agent performs the 4436 following steps: 4438 - The home agent examines the value of the `S' bit in the new "home 4439 registration" Binding Cache entry. If this bit is nonzero, 4440 the following step is carried out only for the individual home 4441 address specified for this binding. If, instead, this bit is 4442 zero, then the following step is carried out for each address 4443 for the mobile node formed from the interface identifier in 4444 the mobile node's home address in this binding (the remaining 4445 low-order bits in the address after the configured subnet 4446 prefix), together with each one of the subnet prefixes currently 4447 considered by the home agent to be on-link (including both the 4448 link-local and site-local prefix). 4450 - For each specific IP address for the mobile node determined 4451 in the first step above, the home agent multicasts onto the 4452 home link (to the all-nodes multicast address) a Neighbor 4453 Advertisement message [20] on behalf of the mobile node, to 4454 advertise the home agent's own link-layer address for this IP 4455 address. 4457 All fields in each such Neighbor Advertisement message SHOULD be 4458 set in the same way they would be set by the mobile node itself 4459 if sending this Neighbor Advertisement while at home [20], with 4460 the following exceptions: 4462 * The Target Address in the Neighbor Advertisement message MUST 4463 be set to the specific IP address for the mobile node. 4465 * The Advertisement MUST include a Target Link-layer Address 4466 option specifying the home agent's link-layer address. 4468 * The Router (R) bit in the Advertisement MUST be copied from 4469 the corresponding bit in the home agent's Binding Cache entry 4470 for the mobile node. 4472 * The Solicited Flag (S) in the Advertisement MUST NOT be set, 4473 since it was not solicited by any Neighbor Solicitation 4474 message. 4476 * The Override Flag (O) in the Advertisement MUST be set, 4477 indicating that the Advertisement SHOULD override any 4478 existing Neighbor Cache entry at any node receiving it. 4480 Any node on the home link receiving one of the Neighbor Advertisement 4481 messages described above will thus update its Neighbor Cache to 4482 associate the mobile node's address with the home agent's link 4483 layer address, causing it to transmit any future packets for the 4484 mobile node normally destined to this address instead to the mobile 4485 node's home agent. Since multicasts on the local link (such as 4486 Ethernet) are typically not guaranteed to be reliable, the home 4487 agent MAY retransmit this Neighbor Advertisement message up to 4488 MAX_ADVERT_REXMIT times to increase its reliability. It is still 4489 possible that some nodes on the home link will not receive any of 4490 these Neighbor Advertisements, but these nodes will eventually be 4491 able to detect the link-layer address change for the mobile node's 4492 home address, through use of Neighbor Unreachability Detection [20]. 4494 While a node is serving as a home agent for some mobile node (it 4495 still has a "home registration" entry for this mobile node in its 4496 Binding Cache), the home agent uses IPv6 Neighbor Discovery [20] to 4497 intercept unicast packets on the home link addressed to the mobile 4498 node's home address. In order to intercept packets in this way, 4499 the home agent MUST act as a proxy for this mobile node, and reply 4500 to any received Neighbor Solicitation messages for it. When a home 4501 agent receives a Neighbor Solicitation message, it MUST check if the 4502 Target Address specified in the message matches the home address 4503 of any mobile node for which it has a Binding Cache entry marked 4504 as a "home registration". This check MUST include all possible 4505 home addresses for the mobile node, based on the subnet prefixes 4506 currently considered to be on-link by the home agent (including the 4507 corresponding link-local address and site-local address), if the 4508 Prefix Length in the Binding Cache entry for this mobile node (from 4509 the Binding Update that created this Cache entry) is nonzero. 4511 If such an entry exists in the home agent's Binding Cache, the home 4512 agent MUST reply to the Neighbor Solicitation message with a Neighbor 4513 Advertisement message, giving the home agent's own link-layer address 4514 as the link-layer address for the specified Target Address. In 4515 addition, the Router (R) bit in the Advertisement MUST be copied from 4516 the corresponding bit in the home agent's Binding Cache entry for the 4517 mobile node. Acting as a proxy in this way allows other nodes on 4518 the mobile node's home link to resolve the mobile node's IPv6 home 4519 address, and allows the home agent to defend these addresses on the 4520 home link for Duplicate Address Detection [20]. 4522 9.4. Tunneling Intercepted Packets to a Mobile Node 4524 For any packet sent to a mobile node from the mobile node's home 4525 agent (for which the home agent is the original sender of the 4526 packet), the home agent is operating as a correspondent node of 4527 the mobile node for this packet and the procedures described in 4528 Section 8.9 apply. The home agent (as a correspondent node) uses a 4529 Routing header to route the packet to the mobile node by way of the 4530 care-of address in the home agent's Binding Cache (the mobile node's 4531 primary care-of address, in this case). 4533 While the mobile node is away from home and this node is acting 4534 as the mobile node's home agent, the home agent intercepts any 4535 packets on the home link addressed to the mobile node's home address 4536 (including addresses formed from other on-link prefixes, if the 4537 Prefix Length field was nonzero in the Binding Update), as described 4538 in Section 9.3. The home agent cannot use a Routing header to 4539 forward these intercepted packets to the mobile node, since it cannot 4540 modify the packet in flight without invalidating any existing IPv6 4541 AH [12] or ESP [13] header present in the packet. 4543 In order to forward each intercepted packet to the mobile node, the 4544 home agent MUST tunnel the packet to the mobile node using IPv6 4545 encapsulation [4]; the tunnel entry point node is the home agent, 4546 and the tunnel exit point node is the primary care-of address as 4547 registered with the home agent. When a home agent encapsulates 4548 an intercepted packet for forwarding to the mobile node, the home 4549 agent sets the Source Address in the prepended tunnel IP header to 4550 the home agent's own IP address, and sets the Destination Address 4551 in the tunnel IP header to the mobile node's primary care-of 4552 address. When received by the mobile node (using its primary care-of 4553 address), normal processing of the tunnel header [4] will result in 4554 decapsulation and processing of the original packet by the mobile 4555 node. 4557 However, packets addressed to the mobile node's link-local address 4558 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 4559 be discarded, and the home agent SHOULD return an ICMP Destination 4560 Unreachable, Code 3, message to the packet's Source Address (unless 4561 this Source Address is a multicast address). Packets addressed to 4562 the mobile node's site-local address SHOULD be tunneled to the mobile 4563 node by default, but this behavior MUST be configurable to disable 4564 it; currently, the exact definition and semantics of a "site" and a 4565 site-local address are incompletely defined in IPv6, and this default 4566 behavior might change at some point in the future. 4568 Tunneling of multicast packets to a mobile node follows similar 4569 limitations to those defined above for unicast packets addressed to 4570 the mobile node's link-local and site-local addresses. Multicast 4571 packets addressed to a multicast address with link-local scope [9], 4572 to which the mobile node is subscribed, MUST NOT be tunneled 4573 to the mobile node; such packets SHOULD be silently discarded 4574 (after delivering to other local multicast recipients). Multicast 4575 packets addressed to a multicast address with scope larger 4576 than link-local but smaller than global (e.g., site-local and 4577 organization-local) [9], to which the mobile node is subscribed, 4578 SHOULD be tunneled to the mobile node by default, but this behavior 4579 MUST be configurable to disable it; this default behavior might 4580 change at some point in the future as the definition of these scopes 4581 become more completely defined in IPv6. 4583 9.5. Handling Reverse Tunneled Packets from a Mobile Node 4585 A home agent MUST support decapsulating reverse tunneled packets 4586 sent to it from a mobile node's home address. Such reverse tunneled 4587 packets MAY be discarded unless accompanied by a valid AH or ESP 4588 header. This support for reverse tunneling allows mobile nodes to 4589 defeat certain kinds of traffic analysis. Requiring IPsec headers 4590 on reverse tunneled packets allows the home agent to protect the 4591 home network against unwarranted intrusions by malicious nodes 4592 masquerading as a mobile node with a home address on the network 4593 served by the home agent. 4595 9.6. Protecting Return Routability Packets 4597 The Return Routability procedure described in Section 4.5 assumes 4598 that the confidentiality of the HoT message is protected as it is 4599 tunneled from the home agent to the mobile node. Therefore, the home 4600 agent MUST protect these packets using IPsec ESP with a non-null 4601 encryption transform. It is also useful, but not required to protect 4602 other RR related messages. 4604 As described earlier, the Binding Update and Binding Acknowledgement 4605 messages already need protection even if they are not tunneled. As 4606 these messages employ the Mobility Header in a similar manner to 4607 the RR messages, it is sufficient to set up IPsec Security Policy 4608 Database in a manner that protects all traffic to the mobile node 4609 and back with IPsec ESP if the protocol in the packet is Mobility 4610 Header. 4612 9.7. Home Prefix Propagation 4614 IPv6 provides mechanisms as part of Neighbor Discovery [20] and 4615 Address Autoconfiguration [35] to aid in mobile node configuration 4616 when a mobile node turns on, and in renumbering a subnet, such as 4617 when a site switches to a new network service provider. 4619 In renumbering, new prefixes and addresses can be introduced for the 4620 subnet and old ones can be deprecated and removed. These mechanisms 4621 are defined to work while all nodes using the old prefixes are at 4622 home, connected to the link using these prefixes. Mobile IPv6 4623 extends these mechanisms for the case in which one or more mobile 4624 nodes using the old prefixes are away from home and registered at the 4625 home agent while the renumbering takes place. 4627 In the IPv6 renumbering mechanism, nodes on the visited link receive 4628 Mobile Prefix Advertisements messages with Prefix Information 4629 Options, which give the valid lifetime and preferred lifetime for 4630 available prefixes on the link [20]. 4632 Mobile IPv6 arranges to propagate relevant prefix information 4633 to the mobile node when it is away from home, so that it may be 4634 used in mobile node home address configuration, and in network 4635 renumbering. To avoid possible security attacks from forged Mobile 4636 Prefix Advertisements all such Advertisements must be authenticated 4637 to the mobile node by its home agent using IPsec [14, 12, 13] if a 4638 security associate exists (i.e. unless the mobile node does not yet 4639 have a home address configured). 4641 9.8. Receiving Router Advertisement Messages 4643 For each link on which a router provides service as a home agent, the 4644 router maintains a Home Agents List recording information about all 4645 other home agents on that link. This list is used in the dynamic 4646 home agent address discovery mechanism, described in Section 9.9. 4647 The information for the list is learned through receipt of the 4648 periodic unsolicited multicast Router Advertisements from each other 4649 home agent on the link, in which the Home Agent (H) bit is set, in a 4650 manner similar to the Default Router List conceptual data structure 4651 maintained by each host for Neighbor Discovery [20]. 4653 On receipt of a valid Router Advertisement, as defined in the 4654 processing algorithm specified for Neighbor Discovery [20], the home 4655 agent performs the following steps, in addition to any steps already 4656 required of it by Neighbor Discovery: 4658 - If the Home Agent (H) bit in the Router Advertisement is not set, 4659 skip all of the following steps. 4661 - If the Home Agent (H) bit in the Router Advertisement is not set, 4662 and the sending node has an entry in the current Home Agents 4663 List, delete the corresponding entry. Subsequently, skip all of 4664 the following steps. 4666 - Otherwise, extract the Source Address from the IP header of the 4667 Router Advertisement. This is the link-local IP address on this 4668 link of the home agent sending this Advertisement [20]. 4670 - Determine from the Router Advertisement the preference for this 4671 home agent. If the Router Advertisement contains a Home Agent 4672 Information Option, then the preference is taken from the Home 4673 Agent Preference field in the option; otherwise, the default 4674 preference of 0 MUST be used. 4676 - Determine from the Router Advertisement the lifetime for 4677 this home agent. If the Router Advertisement contains a Home 4678 Agent Information Option, then the lifetime is taken from 4679 the Home Agent Lifetime field in the option; otherwise, the 4680 lifetime specified by the Router Lifetime field in the Router 4681 Advertisement SHOULD be used. 4683 - If the link-local address of the home agent sending this 4684 Advertisement is already present in this home agent's Home 4685 Agents List and the received home agent lifetime value is zero, 4686 immediately delete this entry in the Home Agents List. 4688 - Otherwise, if the link-local address of the home agent sending 4689 this Advertisement is already present in the receiving home 4690 agent's Home Agents List, reset its lifetime and preference to 4691 the values determined above. 4693 - If the link-local address of the home agent sending this 4694 Advertisement, as determined above, is not already present in 4695 the Home Agents List maintained by the receiving home agent, and 4696 the lifetime for the sending home agent, as determined above, 4697 is non-zero, create a new entry in the list, and initialize its 4698 lifetime and preference to the values determined above. 4700 - If the Home Agents List entry for the link-local address of 4701 the home agent sending this Advertisement was not deleted as 4702 described above, determine any global address(es) of the home 4703 agent based on each Prefix Information option received in 4704 this Advertisement in which the Router Address (R) bit is set 4705 (Section 6.2). For each such global address determined from this 4706 Advertisement, add this global address to the list of global 4707 addresses for this home agent in this Home Agents List entry. 4709 A home agent SHOULD maintain an entry in its Home Agents List for 4710 each such valid home agent address until that entry's lifetime 4711 expires, after which time the entry MUST be deleted. 4713 9.9. Dynamic Home Agent Address Discovery 4715 A mobile node, while away from home, MAY use the dynamic home agent 4716 address discovery mechanism in section 10.8 to attempt to discover 4717 the address of one or more routers serving as home agents on its home 4718 link. This discovery might become necessary, for example, if some 4719 nodes on its home link have been reconfigured while the mobile node 4720 has been away from home, such that the router that was operating as 4721 the mobile node's home agent has been replaced by a different router 4722 serving this role. 4724 As described in Section 10.8, a mobile node attempts dynamic home 4725 agent address discovery by sending an ICMP Home Agent Address 4726 Discovery Request message to the "Mobile IPv6 Home-Agents" anycast 4727 address [11] for its home IP subnet prefix, using its care-of address 4728 as the Source Address of the packet. A home agent receiving such a 4729 Home Agent Address Discovery Request message that is serving this 4730 subnet (the home agent is configured with this anycast address on one 4731 of its network interfaces) SHOULD return an ICMP Home Agent Address 4732 Discovery Reply message to the mobile node (at its care-of address 4733 that was used as the Source Address of the Request message), with the 4734 Source Address of the Reply packet set to one of the global unicast 4735 addresses of the home agent. The Home Agent Addresses field in the 4736 Reply message is constructed as follows: 4738 - The Home Agent Addresses field SHOULD contain one global IP 4739 address for each home agent currently listed in this home 4740 agent's own Home Agents List (Section 4.7). However, if this 4741 home agent's own global IP address would be placed in the list 4742 (as described below) as the first entry in the list, then this 4743 home agent SHOULD NOT include its own address in the Home Agent 4744 Addresses field in the Reply message. Not placing this home 4745 agent's own IP address in the list will cause the receiving 4746 mobile node to consider this home agent as the most preferred 4747 home agent; otherwise, this home agent will be considered to be 4748 preferred in its order given by its place in the list returned. 4750 - The IP addresses in the Home Agent Addresses field SHOULD be 4751 listed in order of decreasing preference value, based either 4752 on the respective advertised preference from a Home Agent 4753 Information option or on the default preference of 0 if no 4754 preference is advertised (or on the configured home agent 4755 preference for this home agent itself). The home agent with 4756 the highest preference SHOULD be listed first in the Home Agent 4757 Addresses field, and the home agent with the lowest preference 4758 SHOULD be listed last. 4760 - Among home agents with equal preference, their IP addresses 4761 in the Home Agent Addresses field SHOULD be listed in an 4762 order randomized with respect to other home agents with equal 4763 preference, each time a Home Agent Address Discovery Reply 4764 message is returned by this home agent. 4766 - For each entry in this home agent's Home Agents List, if more 4767 than one global IP address is associated with this list entry, 4768 then one of these global IP addresses SHOULD be selected 4769 to include in the Home Agent Addresses field in the Reply 4770 message. As described in Section 4.7, one Home Agents List 4771 entry, identified by the home agent's link-local address, 4772 exists for each home agent on the link; associated with that 4773 list entry is one or more global IP addresses for this home 4774 agent, learned through Prefix Information options with the 4775 Router Address (R) bit is set, received in Router Advertisements 4776 from this link-local address. 4778 The selected global IP address for each home agent to include in 4779 forming the Home Agent Addresses field in the Reply message MUST 4780 be the global IP address of the respective home agent sharing a 4781 prefix with the Destination IP address of the Request message; 4782 if no such global IP address is known for some home agent, an 4783 entry for that home agent MUST NOT be included in the Home Agent 4784 Addresses field in the Reply message. 4786 - In order to avoid the possibility of the Reply message packet 4787 being fragmented (or rejected by an intermediate router with an 4788 ICMP Packet Too Big message [5]), if the resulting total packet 4789 size containing the complete list of home agents in the Home 4790 Agent Addresses field would exceed the minimum IPv6 MTU [6], the 4791 home agent SHOULD reduce the number of home agent IP addresses 4792 returned in the packet to the number of addresses that will fit 4793 without exceeding this limit. The home agent addresses returned 4794 in the packet SHOULD be those from the complete list with the 4795 highest preference. 4797 9.9.1. Aggregate List of Home Network Prefixes 4799 A mobile node on a remote network SHOULD autoconfigure all of the 4800 global IP addresses, which it would autoconfigure if it were attached 4801 to its home network, from network prefixes representing network 4802 addresses that are served by home agents. Site-local addresses MAY 4803 be autoconfigured if the mobile node is roaming in a network on the 4804 same site as its home addresses. Site-local addresses and addresses 4805 not served by a home agent MUST NOT be autoconfigured, since they are 4806 unusable in the remote network. 4808 To support this, the home agent monitors prefixes advertised by 4809 itself and other home agents routers on the home link, and passes 4810 this aggregated list of relevant subnet prefixes on to the mobile 4811 node in Mobile Prefix Advertisements. 4813 The home agent SHOULD construct the aggregate list of home subnet 4814 prefixes as follows: 4816 - Copy prefix information defined in the home agent's AdvPrefixList 4817 on the home subnet's interfaces to the aggregate list. Also 4818 apply any changes made to the AdvPrefixList on the home agent to 4819 the aggregate list. 4821 - Check valid prefixes received in Router Advertisements 4822 from the home network for consistency with the home agent's 4823 AdvPrefixList, as specified in section 6.2.7 of RFC 2461 4824 (Neighbor Discovery [20]). Do not update the aggregate list with 4825 any information from received prefixes that fail this check. 4827 - Check Router Advertisements which contain an `H' bit (from other 4828 home agents) for valid prefixes that are not yet in the aggregate 4829 list, and if they are usable for autoconfiguration (`A' bit set, 4830 and prefix length is valid for address autoconfiguration on the 4831 home subnet) add them and preserve the `L' flag value. Clear the 4832 `R' flag and zero the interface-id portion of the prefix field 4833 to prevent mobile nodes from treating another router's interface 4834 address as belonging to the home agent. Treat the lifetimes 4835 of these prefixes as decrementing in real time, as defined in 4836 section 6.2.7 of RFC 2461 [20]. 4838 - Do not perform consistency checks on valid prefixes received in 4839 Router Advertisements on the home network that do not exist in 4840 the home agent's AdvPrefixList. Instead, if the prefixes already 4841 exist in the aggregate list, update the prefix lifetime fields in 4842 the aggregate list according to the rules specified for hosts in 4843 section 6.3.4 of RFC 2461 (Neighbor Discovery [20]) and section 4844 5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [35]). 4846 - If the L flag is set on valid prefixes received in a Router 4847 Advertisement, and that prefix already exists in the aggregate 4848 list, set the flag in the aggregate list. Ignore the flag if it 4849 is clear. 4851 - Delete prefixes from the aggregate list when their valid 4852 lifetimes expire. 4854 The home agent uses the information in the aggregate list to 4855 construct Mobile Prefix Advertisements, possibly including Binding 4856 Acknowledgement or Binding Request destination options, for delivery 4857 to a mobile node for which it is maintaining a current binding. 4858 It may be possible to construct an aggregate list by combining 4859 information contained in the home agent's AdvPrefixList and its 4860 Home Agents List used for Dynamic Home Agent Address Discovery 4861 (Section 10.8). 4863 9.9.2. Scheduling Prefix Deliveries to the Mobile Node 4865 A home agent serving a mobile node will schedule the delivery of new 4866 prefix information to that mobile node when any of the following 4867 conditions occur: 4869 MUST: 4871 - The valid or preferred lifetime or the state of the flags changes 4872 for the prefix of the mobile node's registered home address 4873 changes 4875 - The mobile node requests the information with a Router 4876 Solicitation (see section 10.18). 4878 MAY: 4880 - A new prefix is added to the aggregate list 4882 - The valid or preferred lifetime or the state of the flags changes 4883 for a prefix which is not used in any binding cache entry for 4884 this mobile node 4886 The home agent uses the following algorithm to determine when to send 4887 prefix information to the mobile node. 4889 - If the mobile node has not received the prefix information within 4890 the last HomeRtrAdvInterval seconds, then transmit the prefix 4891 information. This MAY be done according to a periodically 4892 scheduled transmission. 4894 - If a mobile node sends a solicitation, answer right away. 4896 - If a prefix in the aggregate list that matches the mobile 4897 node's home registration is added, or if its information changes 4898 in any way that does not cause the mobile node's address to 4899 go deprecated, ensure that a transmission is scheduled, and 4900 calculate RAND_ADV_DELAY in order to randomize the time at which 4901 the transmission is scheduled. 4903 - If there are any unacknowledged changes to prefix information 4904 when a Binding Update arrives for the home registration, send 4905 a Mobile Prefix Advertisement to the mobile node immediately. 4906 The Mobile Prefix Advertisement SHOULD have the Binding 4907 Acknowledgement as a Destination Option. If an advertisement 4908 was previously scheduled for the mobile node, cancel that 4909 advertisement. 4911 - If a home registration expires, cancel any scheduled 4912 advertisements to the mobile node. 4914 If the home agent already has scheduled the transmission of a Router 4915 Advertisement to the mobile node, and if the freshly calculated 4916 RAND_ADV_DELAY would cause another transmission BEFORE the Preferred 4917 Lifetime of the mobile node's home address derived from the prefix 4918 whose advertisement information has changed, then add the new 4919 information to be transmitted to the existing scheduled transmission. 4920 In this case, the home agent does not perform the following algorithm 4921 to schedule an advertisement to the mobile node. 4923 Otherwise, the home agent uses the following algorithm to compute 4924 a fresh value for RAND_ADV_DELAY, the offset from the current time 4925 for the scheduled transmission. If there is already a scheduled 4926 transmission, add the data from the existing scheduled transmission 4927 to the newly scheduled transmission, deleting the previously 4928 scheduled transmission event. 4930 If the mobile node's binding expires before the Preferred Lifetime, 4931 then return. The mobile node will get the revised information with 4932 its next Binding Acknowledgement. Otherwise, continue with the 4933 following computation. 4934 MAX_SCHEDULE_DELAY == min (MAX_PFX_ADV_DELAY, Preferred Lifetime) 4935 for the newly advertised Preferred Lifetime. 4937 Then compute RAND_ADV_DELAY == 4938 MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) 4940 RAND_ADV_DELAY is the offset from the current time to be used 4941 to schedule the necessary advertisement to the mobile node. The 4942 computation is expected to alleviate bursts of advertisements when 4943 prefix information changes. In addition, a home agent MAY further 4944 reduce the rate of packet transmission by further delaying individual 4945 advertisements, if needed to avoid overwhelming local network 4946 resources. 4948 9.9.3. Sending Advertisements to the Mobile Node 4950 When sending a Mobile Prefix Advertisement to the mobile node, the 4951 home agent MUST construct the packet as follows: 4953 - The Source Address in the packet's IPv6 header MUST be set to 4954 the home agent's IP address to which the mobile node addressed 4955 its current home registration, or its default global home agent 4956 address if no binding exists. 4958 - If a security association exists with the mobile node's address, 4959 the packet MUST be protected by IPsec [14, 12, 13] to guard 4960 against malicious Mobile Prefix Advertisements. The IPsec 4961 protection MUST provide sender authentication, data integrity 4962 protection, and replay protection, covering the Mobile Prefix 4963 Advertisement. 4965 - The advertisement MUST include a Binding Request destination 4966 option if this is the first advertisement for a home 4967 registration, or if there was a change in prefix information 4968 since the last acknowledged advertisement was sent to the mobile 4969 node for the home registration. The Binding Request destination 4970 option MUST include a Unique Identifier Sub-Option (Section 5.5), 4971 with the unique identifier in the sub-option data set to a value 4972 different than that in any other Binding Request sent recently by 4973 this home agent. It is assumed that this requirement can be met 4974 by maintaining a simple 16-bit "wrap-around" counter to generate 4975 unique identifiers for Binding Requests that contain a Unique 4976 Identifier Sub-Option, incremented each time a Binding Request 4977 containing a Unique Identifier Sub-Option is sent. 4979 - If the advertisement was solicited, it should be destined 4980 (and authenticated, if possible) to the source address of 4981 the solicitation. If it was triggered by prefix changes or 4982 renumbering, the advertisement's destination will be the mobile 4983 node's home address in the binding which triggered the rule. 4985 - The packet MUST be sent as any other unicast IPv6 packet. If a 4986 care-of address is used, the packet will be delivered directly. 4987 If a binding exists, the home agent will send the packet with 4988 a routing header containing the care-of address, as any other 4989 packet sent to the mobile node originated by the home agent 4990 (rather than using IPv6 encapsulation, as would be used by the 4991 home agent for intercepted packets). 4993 The home agent SHOULD periodically continue to retransmit an 4994 unsolicited Advertisement to the mobile node, until it is 4995 acknowledged by the receipt from the mobile node of a Binding Update 4996 matching the Binding Request in the packet (i.e., with matching 4997 Sequence Number). The home agent MUST wait PREFIX_ADV_TIMEOUT 4998 before the first retransmission, and double the retransmission wait 4999 time for every succeeding retransmission, up until a maximum of 5000 PREFIX_ADV_RETRIES attempts. If the mobile node's bindings expire 5001 before the matching Binding Update has been received, then the home 5002 agent MUST NOT attempt any more retransmissions, even if not all 5003 PREFIX_ADV_RETRIES have been retransmitted. After another Binding 5004 Update is received from the mobile node, and if the mobile node has 5005 not returned to the home network in the meantime, the home agent 5006 SHOULD begin the process again of transmitting the unsolicited 5007 Advertisement. 5009 A Binding Update matches a Binding Request if it specifies a 5010 binding for the mobile node to which the Binding Request was sent 5011 and contains a Unique Identifier Sub-Option matching the unique 5012 identifier sent in the Unique Identifier Sub-Option in the Binding 5013 Request. In the solicited case, the mobile node will retransmit 5014 solicitations until one is received; thus, the home agent SHOULD NOT 5015 retransmit the responding advertisement. 5017 If while the home agent is still retransmitting a Mobile Prefix 5018 Advertisement to the mobile node, another condition as described 5019 above occurs on the home link causing another Prefix Advertisement to 5020 be sent to the mobile node, the home agent SHOULD combine any Prefix 5021 Information options in the unacknowledged Mobile Prefix Advertisement 5022 into the new Advertisement, discard the old Advertisement, and then 5023 begin retransmitting the new one. according to the algorithm in 5024 section 9.9.2. The home agent MUST generate a new unique identifier 5025 for use in the Unique Identifier Sub-Option in the Binding Request 5026 tunneled with the new Mobile Prefix Advertisement. 5028 9.9.4. Lifetimes for Changed Prefixes 5030 As described in Section 9.1, the lifetime returned by the home 5031 agent in a Binding Acknowledgement MUST be no greater than the 5032 remaining valid lifetime for the subnet prefix in the mobile node's 5033 home address. Furthermore, as described in Section 10.9, Binding 5034 Updates sent by the mobile node to other nodes MUST use a lifetime no 5035 greater than the remaining lifetime of its home registration of its 5036 primary care-of address. These limits on the binding lifetime serve 5037 to prohibit use of a mobile node's home address after it becomes 5038 invalid. The mobile node SHOULD further limit the lifetimes that it 5039 sends on any Binding Updates to be within the remaining preferred 5040 lifetime for the prefix in its home address. 5042 When the lifetime for a changed prefix decreases, and the change 5043 would cause cached bindings at correspondent nodes in the Binding 5044 Update List to be stored past the newly shortened lifetime, the 5045 mobile node MUST issue a Binding Update to all such correspondent 5046 nodes. 5048 10. Mobile Node Operation 5050 10.1. Sending Packets While Away from Home 5052 While a mobile node is away from home, it continues to use its home 5053 address as well as also using one or more care-of addresses. When 5054 sending a packet while away from home, a mobile node MAY choose among 5055 these in selecting the address that it will use as the source of the 5056 packet, as follows: 5058 - From the point of view of protocol layers and applications above 5059 Mobile IP (e.g., transport protocols), the mobile node will 5060 generally use its home address as the source of the packet for 5061 most packets, even while away from home, since Mobile IP is 5062 designed to make mobility transparent to such software. Doing 5063 so also makes the node's mobility---and the fact that it is 5064 currently away from home---transparent to the correspondent nodes 5065 with which it communicates. For packets sent that are part of 5066 transport-level connections established while the mobile node 5067 was at home, the mobile node MUST use its home address in this 5068 way. Likewise, for packets sent that are part of transport-level 5069 connections that the mobile node may still be using after moving 5070 to a new location, the mobile node SHOULD use its home address 5071 in this way. When sending such packets, Mobile IP will modify 5072 the packet to move the home address into a Home Address option 5073 and will set the IPv6 header's Source Address field to one of 5074 the mobile node's care-of addresses; these modifications to 5075 the packet are then reversed in the node receiving the packet, 5076 restoring the mobile node's home address to be the packet's 5077 Source Address before processing by higher protocol layers and 5078 applications. 5080 - For short-term communication, particularly for communication that 5081 may easily be retried if it fails, the mobile node MAY choose 5082 to directly use one of its care-of addresses as the source of 5083 the packet, thus not requiring the use of a Home Address option 5084 in the packet. An example of this type of communication might 5085 be DNS queries sent by the mobile node [17, 18]. Using the 5086 mobile node's care-of address as the source for such queries will 5087 generally have a lower overhead than using the mobile node's 5088 home address, since no extra options need be used in either the 5089 query or its reply, and all packets can be routed normally, 5090 directly between their source and destination without relying 5091 on Mobile IP. If the mobile node has no particular knowledge 5092 that the communication being sent fits within this general type 5093 of communication, however, the mobile node SHOULD NOT use its 5094 care-of address as the source of the packet in this way. 5096 For packets sent by a mobile node while it is at home, no special 5097 Mobile IP processing is required for sending this packet. Likewise, 5098 if the mobile node uses any address other than its home address as 5099 the source of a packet sent while away from home (from the point of 5100 view of higher protocol layers or applications, as described above), 5101 no special Mobile IP processing is required for sending that packet. 5102 In each case, the packet is simply addressed and transmitted in the 5103 same way as any normal IPv6 packet. 5105 For each other packet sent by the mobile node (i.e., packets sent 5106 while away from home, using the mobile node's home address as 5107 the source, from the point of view of higher protocol layers and 5108 applications), special Mobile IP processing of the packet is required 5109 for the insertion of the Home Address option. Specifically: 5111 - Construct the packet using the mobile node's home address as the 5112 packet's Source Address, in the same way as if the mobile node 5113 were at home. This preserves the transparency of Mobile IP to 5114 higher protocol layers (e.g., to TCP). 5116 - Insert a Home Address option into the packet, with the Home 5117 Address field copied from the original value of the Source 5118 Address field in the packet. 5120 - Change the Source Address field in the packet's IPv6 header to 5121 one of the mobile node's care-of addresses. This will typically 5122 be the mobile node's current primary care-of address, but MUST 5123 be a care-of address with a subnet prefix that is on-link on the 5124 network interface on which the mobile node will transmit the 5125 packet. 5127 By using the care-of address as the Source Address in the IPv6 5128 header, with the mobile node's home address instead in the Home 5129 Address option, the packet will be able to safely pass through any 5130 router implementing ingress filtering [7]. 5132 10.2. Interaction with Outbound IPsec Processing 5134 This section sketches the interaction between outbound Mobile 5135 IP processing and outbound IP Security (IPsec) processing for 5136 packets sent by a mobile node while away from home. Any specific 5137 implementation MAY use algorithms and data structures other than 5138 those suggested here, but its processing MUST be consistent with the 5139 effect of the operation described here and with the relevant IPsec 5140 specifications. In the steps described below, it is assumed that 5141 IPsec is being used in transport mode [14] and that the mobile node 5142 is using its home address as the source for the packet (from the 5143 point of view of higher protocol layers or applications, as described 5144 in Section 10.1): 5146 - The packet is created by higher layer protocols and applications 5147 (e.g., by TCP) as if the mobile node were at home and Mobile IP 5148 were not being used. Mobile IP is transparent to such higher 5149 layers. 5151 - As part of outbound packet processing in IP, the packet is 5152 compared against the IPsec Security Policy Database (SPD) to 5153 determine what processing is required for the packet [14]. 5155 - If IPsec processing is required, the packet is either mapped to 5156 an existing Security Association (or SA bundle), or a new SA (or 5157 SA bundle) is created for the packet, according to the procedures 5158 defined for IPsec. 5160 - Since the mobile node is away from home, the mobile is either 5161 using reverse tunneling or route optimization to reach the 5162 correspondent node. 5164 If reverse tunneling is used, the packet is constructed in the 5165 normal manner and then tunneled through through the home agent. 5167 If route optimization is in use, the mobile node inserts a Home 5168 Address option into the packet, replacing the Source Address 5169 in the packet's IP header with a care-of address suitable for 5170 the link on which the packet is being sent, as described in 5171 Section 10.1. The Destination Options header in which the Home 5172 Address option is inserted MUST appear in the packet after the 5173 Routing Header, if present, and before the AH [12] (or ESP [13]) 5174 header, so that the Home Address option is processed by the 5175 destination node before the AH or ESP header is processed. 5177 Finally, once the packet is fully assembled, the necessary IPsec 5178 authentication (and encryption, if required) processing is 5179 performed on the packet, initializing the Authentication Data 5180 in the AH or ESP header. The AH authentication data MUST be 5181 calculated as if the following were true: 5183 * the IPv6 source address in the IPv6 header contains the 5184 mobile node's home address, 5186 * the Home Address field of the Home Address destination option 5187 (section 5.3) contains the new care-of address. 5189 - This allows, but does not require, the receiver of the 5190 packet containing a Home Address Option to exchange the two 5191 fields of the incoming packet, simplifying processing for all 5192 subsequent packet headers. The mechanics of implementation 5193 do not absolutely require such an exchange to occur; other 5194 implementation strategies may be more appropriate, as long as the 5195 result of the authentication calculation remain the same. 5197 In addition, when using any automated key management protocol [14] 5198 (such as IKE [8]) to create any new SA (or SA bundle) while away 5199 from home, a mobile node MUST take special care in its processing of 5200 the key management protocol. Otherwise, other nodes with which the 5201 mobile node must communicate as part of the automated key management 5202 protocol processing may be unable to correctly deliver packets to 5203 the mobile node if they and/or the mobile node's home agent do 5204 not then have a current Binding Cache entry for the mobile node. 5205 For the default case of using IKE as the automated key management 5206 protocol [8][14], such problems can be avoided by the following 5207 requirements on the use of IKE by a mobile node while away from home: 5209 - The mobile node MUST use its care-of address as the Source 5210 Address of all packets it sends as part of the key management 5211 protocol (without use of Mobile IP for these packets, as 5212 suggested in Section 10.1). 5214 - In addition, for all security associations bound to the mobile 5215 node's home address established by way of IKE, the mobile node 5216 MUST include an ISAKMP Identification Payload [16] in the IKE 5217 exchange, giving the mobile node's home address as the initiator 5218 of the Security Association [28]. 5220 10.3. Receiving Packets While Away from Home 5222 While away from home, a mobile node will receive packets addressed to 5223 its home address, by one of three methods: 5225 - Packets sent by a correspondent node that does not have a 5226 Binding Cache entry for the mobile node, will be sent by the 5227 correspondent node in the same way as any normal IP packet. Such 5228 packets will then be intercepted by the mobile node's home agent, 5229 encapsulated using IPv6 encapsulation [4], and tunneled to the 5230 mobile node's primary care-of address. 5232 - Packets sent by a correspondent node that has a Binding Cache 5233 entry for the mobile node that contains the mobile node's current 5234 care-of address, will be sent by the correspondent node using 5235 a Routing header. The packet will be addressed to the mobile 5236 node's care-of address, with the final hop in the Routing header 5237 directing the packet to the mobile node's home address; the 5238 processing of this last hop of the Routing header is entirely 5239 internal to the mobile node, since the care-of address and home 5240 address are both addresses within the mobile node. 5242 - Packets sent by a correspondent node that has a Binding Cache 5243 entry for the mobile node that contains an out-of-date care-of 5244 address for the mobile node, will be sent by the correspondent 5245 node using a Routing header, as described above. If the mobile 5246 node sent a Binding Update to a home agent on the link on which 5247 its previous care-of address is located (Section 10.11), and 5248 if this home agent is still serving as a home agent for the 5249 mobile node's previous care-of address, then such a packet will 5250 be intercepted by this home agent, encapsulated using IPv6 5251 encapsulation [4], and tunneled to the mobile node's new care-of 5252 address (registered with this home agent). 5254 For packets received by either the first or last of these three 5255 methods, the mobile node SHOULD send a Binding Update to the original 5256 sender of the packet, as described in Section 10.9, subject to 5257 the rate limiting defined in Section 10.13. The mobile node MUST 5258 also process the received packet in the manner defined for IPv6 5259 encapsulation [4], which will result in the encapsulated (inner) 5260 packet being processed normally by upper-layer protocols within the 5261 mobile node, as if it had been addressed (only) to the mobile node's 5262 home address. 5264 For packets received by the second method above (using a Routing 5265 header), the mobile node MUST process the received packet in 5266 the manner defined for the type of IPv6 Routing header used (see 5267 Section 5.4), which will result in the packet being processed 5268 normally by upper-layer protocols within the mobile node, as if it 5269 had been addressed (only) to the mobile node's home address. 5271 10.4. Movement Detection 5273 A mobile node MAY use any combination of mechanisms available to it 5274 to detect when it has moved from one link to another. The primary 5275 movement detection mechanism for Mobile IPv6 defined here uses the 5276 facilities of IPv6 Neighbor Discovery, including Router Discovery and 5277 Neighbor Unreachability Detection, although the mobile node SHOULD 5278 supplement this mechanism with other information whenever it is 5279 available to the mobile node (e.g., from lower protocol layers). The 5280 description here is based on the conceptual model of the organization 5281 and data structures defined by Neighbor Discovery [20]. 5283 Mobile nodes SHOULD use Router Discovery to discover new routers and 5284 on-link subnet prefixes; a mobile node MAY send Router Solicitation 5285 messages, or MAY wait for unsolicited (periodic) multicast Router 5286 Advertisement messages, as specified for Router Discovery [20]. 5287 Based on received Router Advertisement messages, a mobile node (in 5288 the same way as any other node) maintains an entry in its Default 5289 Router List for each router, and an entry in its Prefix List for each 5290 subnet prefix, that it currently considers to be on-link. Each entry 5291 in these lists has an associated invalidation timer value (extracted 5292 from the Router Advertisement and Prefix Information options) used to 5293 expire the entry when it becomes invalid. 5295 While away from home, a mobile node typically selects one router 5296 from its Default Router List to use as its default router, and one 5297 subnet prefix advertised by that router from its Prefix List to use 5298 as the subnet prefix in its primary care-of address. A mobile node 5299 MAY also have associated additional care-of addresses, using other 5300 subnet prefixes from its Prefix List. The method by which a mobile 5301 node selects and forms a care-of address from the available subnet 5302 prefixes is described in Section 10.6. The mobile node registers 5303 its primary care-of address with its home agent, as described in 5304 Section 10.7. 5306 While a mobile node is away from home and using some router as its 5307 default router, it is important for the mobile node to be able to 5308 quickly detect when that router becomes unreachable, so that it 5309 can switch to a new default router and (if needed, according to 5310 prefix advertisement) to a new primary care-of address. Since some 5311 links (notably wireless) do not necessarily work equally well in 5312 both directions, it is likewise important for the mobile node to 5313 detect when it becomes unreachable for packets sent from its default 5314 router, so that the mobile node can take steps to ensure that any 5315 correspondent nodes attempting to communicate with it can still reach 5316 it through some other route. 5318 To detect when its default router becomes unreachable, a mobile 5319 node SHOULD use Neighbor Unreachability Detection. As specified in 5320 Neighbor Discovery [20], while the mobile node is actively sending 5321 packets to (or through) its default router, the mobile node can 5322 detect that the router (as its neighbor) is still reachable either 5323 through indications from upper layer protocols on the mobile node 5324 that a connection is making "forward progress" (e.g., receipt of TCP 5325 acknowledgements for new data transmitted), or through receipt of a 5326 Neighbor Advertisement message from its default router in response 5327 to an explicit Neighbor Solicitation messages to it. Note that 5328 although this mechanism detects that the mobile node's default router 5329 has become unreachable to the mobile node only while the mobile node 5330 is actively sending packets to it, this is the only time that this 5331 direction of reachability confirmation is needed. Confirmation 5332 that the mobile node is still reachable from the router is handled 5333 separately, as described below. 5335 For a mobile node to detect when it has become unreachable from its 5336 default router, the mobile node cannot efficiently rely on Neighbor 5337 Unreachability Detection alone, since the network overhead would be 5338 prohibitively high in many cases for a mobile node to continually 5339 probe its default router with Neighbor Solicitation messages even 5340 when it is not otherwise actively sending packets to it. Instead, 5341 when a mobile node receives any IPv6 packets from its current default 5342 router at all, irrespective of the source IPv6 address, it SHOULD use 5343 that as an indication that it is still reachable from the router. 5345 Since the router SHOULD be sending periodic unsolicited multicast 5346 Router Advertisement messages, the mobile node will have frequent 5347 opportunity to check if it is still reachable from its default 5348 router, even in the absence of other packets to it from the router. 5349 If Router Advertisements that the mobile node receives include 5350 an Advertisement Interval option, the mobile node MAY use its 5351 Advertisement Interval field as an indication of the frequency with 5352 which it SHOULD expect to continue to receive future Advertisements 5353 from that router. This field specifies the minimum rate (the maximum 5354 amount of time between successive Advertisements) that the mobile 5355 node SHOULD expect. If this amount of time elapses without the 5356 mobile node receiving any Advertisement from this router, the mobile 5357 node can be sure that at least one Advertisement sent by the router 5358 has been lost. It is thus possible for the mobile node to implement 5359 its own policy for determining the number of Advertisements from 5360 its current default router it is willing to tolerate losing before 5361 deciding to switch to a different router from which it may currently 5362 be correctly receiving Advertisements. 5364 On some types of network interfaces, the mobile node MAY also 5365 supplement this monitoring of Router Advertisements, by setting its 5366 network interface into "promiscuous" receive mode, so that it is able 5367 to receive all packets on the link, including those not link-level 5368 addressed to it (i.e., disabling link-level address filtering). The 5369 mobile node will then be able to detect any packets sent by the 5370 router, in order to detect reachability from the router. This use of 5371 promiscuous mode may be useful on very low bandwidth (e.g., wireless) 5372 links, but its use MUST be configurable on the mobile node since it 5373 is likely to consume additional energy resources. 5375 If the above means do not provide indication that the mobile node 5376 is still reachable from its current default router (for instance, 5377 the mobile node receives no packets from the router for a period 5378 of time), then the mobile node SHOULD attempt to actively probe 5379 the router with Neighbor Solicitation messages, even if it is not 5380 otherwise actively sending packets to the router. If it receives a 5381 solicited Neighbor Advertisement message in response from the router, 5382 then the mobile node can deduce that it is still reachable. It is 5383 expected that the mobile node will in most cases be able to determine 5384 its reachability from the router by listening for packets from the 5385 router as described above, and thus, such extra Neighbor Solicitation 5386 probes should rarely be necessary. 5388 With some types of networks, indications about link-layer mobility 5389 might be obtained from lower-layer protocol or device driver software 5390 within the mobile node. However, all link-layer mobility indications 5391 from lower layers do not necessarily indicate a movement of the 5392 mobile node to a new link, such that the mobile node would need to 5393 switch to a new default router and primary care-of address. For 5394 example, movement of a mobile node from one cell to another in many 5395 wireless LANs can be made transparent to the IP level through use of 5396 a link-layer "roaming" protocol, as long as the different wireless 5397 LAN cells all operate as part of the same IP link with the same 5398 subnet prefix. Upon lower-layer indication of link-layer mobility, 5399 the mobile node MAY send Router Solicitation messages to determine if 5400 additional on-link subnet prefixes are available on its new link. 5402 Such lower-layer information might also be useful to a mobile node in 5403 deciding to switch its primary care-of address to one of the other 5404 care-of addresses it has formed from the on-link subnet prefixes 5405 currently available through different routers from which the mobile 5406 node is reachable. For example, a mobile node MAY use signal 5407 strength or signal quality information (with suitable hysteresis) for 5408 its link with the available routers to decide when to switch to a new 5409 primary care-of address using that router rather than its current 5410 default router (and current primary care-of address). Even though 5411 the mobile node's current default router may still be reachable in 5412 terms of Neighbor Unreachability Detection, the mobile node MAY use 5413 such lower-layer information to determine that switching to a new 5414 default router would provide a better connection. 5416 10.5. Receiving Local Router Advertisement Messages 5418 Each mobile node maintains a Home Agents List recording information 5419 about all home agents from which it receives a Router Advertisement, 5420 for which the home agent lifetime indicated in that Router 5421 Advertisement has not yet expired. This list is used by the mobile 5422 node to enable it to send a Binding Update to the global unicast 5423 address of a home agent on its previous link when it moves to a new 5424 link, as described in Section 10.11. On receipt of a valid Router 5425 Advertisement, as defined in the processing algorithm specified for 5426 Neighbor Discovery [20], the mobile node performs the following 5427 steps, in addition to any steps already required of it by Neighbor 5428 Discovery. 5430 - If the Home Agent (H) bit in the Router Advertisement is not set, 5431 and the sending node currently has an entry in the node's Home 5432 Agents List, delete the corresponding entry. Subsequently, skip 5433 all of the following steps. 5435 - Otherwise, extract the Source Address from the IP header of the 5436 Router Advertisement. This is the link-local IP address on this 5437 link of the home agent sending this Advertisement [20]. 5439 - Determine from the Router Advertisement the preference for this 5440 home agent. If the Router Advertisement contains a Home Agent 5441 Information Option, then the preference is taken from the Home 5442 Agent Preference field in the option; otherwise, the default 5443 preference of 0 MUST be used. 5445 - Determine from the Router Advertisement the lifetime for 5446 this home agent. If the Router Advertisement contains a Home 5447 Agent Information Option, then the lifetime is taken from 5448 the Home Agent Lifetime field in the option; otherwise, the 5449 lifetime specified by the Router Lifetime field in the Router 5450 Advertisement SHOULD be used. 5452 - If the link-local address of the home agent sending this 5453 Advertisement is already present in this mobile node's Home 5454 Agents List and the received home agent lifetime value is zero, 5455 immediately delete this entry in the Home Agents List. 5457 - Otherwise, if the link-local address of the home agent sending 5458 this Advertisement is already present in the receiving mobile 5459 node's Home Agents List, reset its lifetime and preference to the 5460 values determined above. 5462 - If the link-local address of the home agent sending this 5463 Advertisement, as determined above, is not already present in the 5464 Home Agents List maintained by the receiving mobile node, and 5465 the lifetime for the sending home agent, as determined above, 5466 is non-zero, create a new entry in the list, and initialize its 5467 lifetime and preference to the values determined above. 5469 - If the Home Agents List entry for the link-local address of 5470 the home agent sending this Advertisement was not deleted as 5471 described above, determine any global address(es) of the home 5472 agent based on each Prefix Information option received in 5473 this Advertisement in which the Router Address (R) bit is set 5474 (Section 6.2). For each such global address determined from this 5475 Advertisement, add this global address to the list of global 5476 addresses for this home agent in this Home Agents List entry. 5478 A mobile node SHOULD maintain an entry in its Home Agents List for 5479 each such valid home agent address until that entry's lifetime 5480 expires, after which time the entry MUST be deleted. 5482 10.6. Forming New Care-of Addresses 5484 After detecting that it has moved from one link to another (i.e., its 5485 current default router has become unreachable and it has discovered 5486 a new default router), a mobile node SHOULD form a new primary 5487 care-of address using one of the on-link subnet prefixes advertised 5488 by the new router. A mobile node MAY form a new primary care-of 5489 address at any time, except that it MUST NOT do so too frequently. 5490 Specifically, a mobile node MUST NOT send a Binding Update about a 5491 new care-of address to its home agent (which is required to register 5492 the new address as its primary care-of address) more often than once 5493 per MAX_UPDATE_RATE seconds. 5495 In addition, after discovering a new on-link subnet prefix, a mobile 5496 node MAY form a new (non-primary) care-of address using that subnet 5497 prefix, even when it has not switched to a new default router. A 5498 mobile node can have only one primary care-of address at a time 5499 (which is registered with its home agent), but it MAY have an 5500 additional care-of address for any or all of the prefixes on its 5501 current link. Furthermore, since a wireless network interface may 5502 actually allow a mobile node to be reachable on more than one link at 5503 a time (i.e., within wireless transmitter range of routers on more 5504 than one separate link), a mobile node MAY have care-of addresses 5505 on more than one link at a time. The use of more than one care-of 5506 address at a time is described in Section 10.20. 5508 As described in Section 4, in order to form a new care-of address, 5509 a mobile node MAY use either stateless [35] or stateful (e.g., 5510 DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to 5511 send packets as part of the method of address autoconfiguration, 5512 it MUST use an IPv6 link-local address rather than its own IPv6 5513 home address as the Source Address in the IPv6 header of each such 5514 autoconfiguration packet. 5516 In some cases, a mobile node may already know a (constant) IPv6 5517 address that has been assigned to it for its use only while 5518 visiting a specific foreign link. For example, a mobile node may be 5519 statically configured with an IPv6 address assigned by the system 5520 administrator of some foreign link, for its use while visiting that 5521 link. If so, rather than using Address Autoconfiguration to form a 5522 new care-of address using this subnet prefix, the mobile node MAY use 5523 its own pre-assigned address as its care-of address on this link. 5525 After forming a new care-of address, a mobile node MAY perform 5526 Duplicate Address Detection [35] on that new address to confirm its 5527 uniqueness. However, doing so represents a tradeoff between safety 5528 (ensuring that the new address is not used if it is a duplicate 5529 address) and overhead (performing Duplicate Address Detection 5530 requires the sending of one or more additional packets over what 5531 may be, for example, a slow wireless link through which the mobile 5532 node is connected). Performing Duplicate Address Detection also in 5533 general would cause a delay before the mobile node could use the 5534 new care-of address, possibly causing the mobile node to be unable 5535 to continue communication with correspondent nodes for some period 5536 of time. For these reasons, a mobile node, after forming a new 5537 care-of address, MAY begin using the new care-of address without 5538 performing Duplicate Address Detection. Furthermore, the mobile node 5539 MAY continue using the address without performing Duplicate Address 5540 Detection, although it SHOULD in most cases (e.g., unless network 5541 bandwidth or battery consumption for communication is of primary 5542 concern) begin Duplicate Address Detection asynchronously when it 5543 begins use of the address, allowing the Duplicate Address Detection 5544 procedure to complete in parallel with normal communication using the 5545 address. 5547 In addition, normal processing for Duplicate Address Detection 5548 specifies that, in certain cases, the node SHOULD delay sending the 5549 initial Neighbor Solicitation message of Duplicate Address Detection 5550 by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [20, 35]; 5551 however, in this case, the mobile node SHOULD NOT perform such a 5552 delay in its use of Duplicate Address Detection, unless the mobile 5553 node is initializing after rebooting. 5555 10.7. Sending Binding Updates to the Home Agent 5557 After deciding to change its primary care-of address as described 5558 in Sections 10.4 and 10.6, a mobile node MUST register this care-of 5559 address with its home agent in order to make this its primary care-of 5560 address. To do so, the mobile node sends a packet to its home agent 5561 containing a Binding Update option, with the packet constructed as 5562 follows: 5564 - The Home Registration (H) bit MUST be set in the Binding Update. 5566 - The Acknowledge (A) bit MUST be set in the Binding Update. 5568 - The packet MUST contain a Home Address option, giving the mobile 5569 node's home address for the binding. 5571 - The care-of address for the binding MUST be used as the Source 5572 Address in the packet's IPv6 header, unless an Alternate Care-of 5573 Address sub-option is included in the Binding Update option. 5575 - The `S' bit is set to the zero to request the mobile node's home 5576 agent to serve as a home agent for all home addresses for the 5577 mobile node based on all on-link subnet prefixes on the home 5578 link; this is the default behavior. If the mobile node desires 5579 that only a single home address should be affected by this 5580 Binding Update, the `S' bit can be set to 1. 5582 - The value specified in the Lifetime field SHOULD be less than 5583 or equal to the remaining lifetime of the home address and the 5584 care-of address specified for the binding. 5586 The Acknowledge (A) bit in the Binding Update requests the home agent 5587 to return a Binding Acknowledgement in response to this Binding 5588 Update. As described in Section 5.1.8, the mobile node SHOULD 5589 retransmit this Binding Update to its home agent until it receives 5590 a matching Binding Acknowledgement. Once reaching a retransmission 5591 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart 5592 the process of delivering the Binding Update, but trying instead the 5593 next Home Agent from its Home Agent list (see section 10.8). If 5594 there is only one home agent in the Home Agent list, the mobile node 5595 instead SHOULD continue to periodically retransmit the Binding Update 5596 at this rate until acknowledged (or until it begins attempting to 5597 register a different primary care-of address). See section 10.12 for 5598 information about retransmitting Binding Updates. 5600 The Prefix Length field in the Binding Update allows the mobile node 5601 to request its home agent to serve all home addresses for the mobile 5602 node, as indicated by the interface identifier in the mobile node's 5603 home address (the remaining low-order bits after the indicated subnet 5604 prefix), together with each on-link subnet prefix on the home link. 5605 Until the lifetime of this registration expires, the home agent 5606 considers itself the home agent for each such home address of the 5607 mobile node. As the set of on-link subnet prefixes on the home link 5608 changes over time, the home agent changes the set of home addresses 5609 for this mobile node for which it is serving as the home agent. 5611 When sending a Binding Update to its home agent, the mobile node MUST 5612 also create or update the corresponding Binding Update List entry, as 5613 specified in Section 10.9. 5615 If the mobile node has additional home addresses using a different 5616 interface identifier, then the mobile node SHOULD send an additional 5617 packet containing a Binding Update to its home agent to register the 5618 care-of address for each such other home address (or set of home 5619 addresses sharing an interface identifier). These additional Binding 5620 Updates MUST each be sent as a separate packet. Each care-of address 5621 MUST be authenticated within the Binding Update as coming from the 5622 home address being associated with the care-of address, as defined in 5623 Section 4.5. 5625 While the mobile node is away from home, it relies on the home agent 5626 to participate in Duplicate Address Detection (DAD) to defend its 5627 home address against stateless autoconfiguration performed by another 5628 node. Therefore, the mobile node SHOULD set the Duplicate Address 5629 Detection (D) bit based on any requirements for DAD that would apply 5630 to the mobile node if it were at home [20, 35]. If the mobile 5631 node's recent Binding Update was accepted by the home agent, and the 5632 lifetime for that Binding Update has not yet expired, the mobile node 5633 SHOULD NOT set the `D' bit in the new Binding Update; the home agent 5634 will already be defending the home address(es) of the mobile node and 5635 does not need to perform DAD again. 5637 The home agent will only perform DAD for the mobile node's home 5638 address when the mobile node has supplied a valid binding between 5639 its home address and a care-of address. If some time elapses during 5640 which the mobile node has no binding at the home agent, it might be 5641 possible for another node to autoconfigure the mobile node's home 5642 address. Therefore, the mobile node MUST treat creation of a new 5643 binding with the home agent using an existing home address the same 5644 as creation of a new home address. In the unlikely event that the 5645 mobile node's home address is autoconfigured as the IPv6 address 5646 of another network node on the home network, the home agent will 5647 reply to the mobile node's subsequent Binding Update with a Binding 5648 Acknowledgement showing Status 138, Duplicate Address Detection 5649 failed. In this case, the mobile node MUST NOT attempt to re-use 5650 the same home address. It SHOULD continue to register care-of 5651 addresses for its other home addresses, if any. The mobile node MAY 5652 also attempt to acquire a new home address to replace the one for 5653 which Status 138 was received, for instance by using the techniques 5654 described in appendix B. 5656 10.8. Dynamic Home Agent Address Discovery 5658 Sometimes, when the mobile node needs to send a Binding Update to its 5659 home agent to register its new primary care-of address, as described 5660 in Section 10.7, the mobile node may not know the address of any 5661 router on its home link that can serve as a home agent for it. For 5662 example, some nodes on its home link may have been reconfigured while 5663 the mobile node has been away from home, such that the router that 5664 was operating as the mobile node's home agent has been replaced by a 5665 different router serving this role. 5667 In this case, the mobile node MAY attempt to discovery the address of 5668 a suitable home agent on its home link. To do so, the mobile node 5669 sends an ICMP Home Agent Address Discovery Request message to the 5670 "Mobile IPv6 Home-Agents" anycast address [11] for its home subnet 5671 prefix. This packet MUST NOT contain a Home Address option and must 5672 be sent using the mobile node's care-of address as the Source Address 5673 in the packet's IP header (the packet is sent from the care-of 5674 address, not using Mobile IP). As described in Section 9.9, the home 5675 agent on its home link that receives this Request message will return 5676 an ICMP Home Agent Address Discovery Reply message, giving this home 5677 agent's own global unicast IP address along with a list of the global 5678 unicast IP address of each other home agent operating on the home 5679 link. 5681 The mobile node, upon receiving this Home Agent Address Discovery 5682 Reply message, MAY then send its home registration Binding Update to 5683 the home agent address given as the IP Source Address of the packet 5684 carrying the Reply message or to any of the unicast IP addresses 5685 listed in the Home Agent Addresses field in the Reply. For example, 5686 if necessary, the mobile node MAY attempt its home registration 5687 with each of these home agents, in turn, by sending each a Binding 5688 Update and waiting for the matching Binding Acknowledgement, until 5689 its registration is accepted by one of these home agents. In trying 5690 each of the returned home agent addresses, the mobile node SHOULD try 5691 each in the order listed in the Home Agent Addresses field in the 5692 received Home Agent Address Discovery Reply message. If the home 5693 agent identified by the Source Address field in the IP header of the 5694 packet carrying the Home Agent Address Discovery Reply message is 5695 not listed in the Home Agent Addresses field in the Reply, it SHOULD 5696 be tried before the first address given in the list; otherwise, it 5697 SHOULD be tried in its listed order. 5699 If the mobile node has a current registration with some home agent 5700 on its home link (the Lifetime for that registration has not yet 5701 expired), then the mobile node MUST attempt any new registration 5702 first with that home agent. If that registration attempt fails 5703 (e.g., times out or is rejected), the mobile node SHOULD then 5704 reattempt this registration with another home agent on its home link. 5705 If the mobile node knows of no other suitable home agent, then it MAY 5706 attempt the dynamic home agent address discovery mechanism described 5707 above. 5709 If, after a mobile node transmits a Home Agent Address Discovery 5710 Request message to the Home Agents Anycast address, it does not 5711 receive a corresponding Home Agent Address Discovery Reply message 5712 within INITIAL_DHAAD_TIMEOUT seconds, the mobile node MAY retransmit 5713 the same Request message to the same anycast address. This 5714 retransmission MAY be repeated up to a maximum of DHAAD_RETRIES 5715 attempts. Each retransmission MUST be delayed by twice the time 5716 interval of the previous retransmission. 5718 10.9. Sending Binding Updates to Correspondent Nodes 5720 When the mobile node is assured that its home address is valid, 5721 it MAY send a Binding Update to any correspondent node at any 5722 time to allow the correspondent node to cache the mobile node's 5723 current care-of address (subject to the rate limiting defined in 5724 Section 10.13). See for example the home agent's use the 'D' bit 5725 of Binding Updates (in section 9.1) for how the mobile node can be 5726 assured that its home address is still valid. In any Binding Update 5727 sent by a mobile node, the care-of address (either the Source Address 5728 in the packet's IPv6 header or the Care-of Address in the Alternate 5729 Care-of Address Sub-Option of the Binding Update) MUST be set to one 5730 of the care-of addresses currently in use by the mobile node or to 5731 the mobile node's home address. 5733 A mobile node MAY choose to keep its location private from certain 5734 correspondent nodes, and thus need not send new Binding Updates to 5735 those correspondents. A mobile node MAY also send a Binding Update 5736 to such a correspondent node to instruct it to delete any existing 5737 binding for the mobile node from its Binding Cache, as described in 5738 Section 5.1.7. No other IPv6 nodes are authorized to send Binding 5739 Updates on behalf of a mobile node. 5741 If set to one of the mobile node's current care-of addresses (the 5742 care-of address given MAY differ from the mobile node's primary 5743 care-of address), the Binding Update requests the correspondent node 5744 to create or update an entry for the mobile node in the correspondent 5745 node's Binding Cache to record this care-of address for use in 5746 sending future packets to the mobile node. In this case, the value 5747 specified in the Lifetime field sent in the Binding Update SHOULD be 5748 less than or equal to the remaining lifetime of the home address and 5749 the care-of address specified for the binding. 5751 If, instead, the care-of address is set to the mobile node's home 5752 address, the Binding Update requests the correspondent node to delete 5753 any existing Binding Cache entry that it has for the mobile node. 5754 A mobile node MAY set the care-of address differently for sending 5755 Binding Updates to different correspondent nodes. 5757 When sending any Binding Update, the mobile node MUST record in its 5758 Binding Update List the following fields from the Binding Update: 5760 - The IP address of the node to which the Binding Update was sent. 5762 - The home address for which the Binding Update was sent (the value 5763 in the Home Address option in the packet carrying the Binding 5764 Update). 5766 - The initial lifetime of the binding, initialized from the 5767 Lifetime field sent in the Binding Update. 5769 - The remaining lifetime of the binding, also initialized from 5770 the Lifetime field sent in the Binding Update. This remaining 5771 lifetime value counts down and may also be reduced when the 5772 matching Binding Acknowledgement is received, based on the 5773 Lifetime value specified in that Binding Acknowledgement, as 5774 described in Section 10.14. When the remaining lifetime reaches 5775 zero, the Binding Update List entry MUST be deleted. 5777 The mobile node MUST retain in its Binding Update List information 5778 about all Binding Updates sent, for which the lifetime of the binding 5779 has not yet expired. However, when sending a Binding Update, if an 5780 entry already exists in the mobile node's Binding Update List for 5781 an earlier Binding Update sent to that same destination node, the 5782 existing Binding Update List entry is updated to reflect the new 5783 Binding Update rather than creating a new Binding Update List entry. 5785 When a mobile node sends a Binding Update to its home agent 5786 to register a new primary care-of address (as described in 5787 Section 10.7), the mobile node SHOULD also send a Binding Update 5788 to each other node for which an entry exists in the mobile node's 5789 Binding Update List, as detailed below. Thus, other relevant nodes 5790 are generally kept updated about the mobile node's binding and can 5791 send packets directly to the mobile node using the mobile node's 5792 current care-of address. 5794 The mobile node, however, need not send these Binding Updates 5795 immediately after configuring a new care-of address. For example, 5796 since the Binding Update is a destination option and can be included 5797 in any packet sent by a mobile node, the mobile node MAY delay 5798 sending a new Binding Update to any correspondent node for a 5799 short period of time, in hopes that the needed Binding Update 5800 can be included in some packet that the mobile node sends to that 5801 correspondent node for some other reason (for example, as part of 5802 some TCP connection in use). In this case, when sending a packet 5803 to some correspondent node, the mobile node SHOULD check in its 5804 Binding Update List to determine if a new Binding Update to this 5805 correspondent node is needed, and SHOULD include the new Binding 5806 Update in this packet as necessary. 5808 In addition, when a mobile node receives a packet for which the 5809 mobile node can deduce that the original sender of the packet either 5810 has no Binding Cache entry for the mobile node, or a stale entry 5811 for the mobile node in its Binding Cache, the mobile node SHOULD 5812 return a Binding Update to the sender giving its current care-of 5813 address (subject to the rate limiting defined in Section 10.13). 5814 In particular, the mobile node SHOULD return a Binding Update in 5815 response to receiving a packet that meets all of the following tests: 5817 - The packet was tunneled using IPv6 encapsulation. 5819 - The Destination Address in the tunnel (outer) IPv6 header is 5820 equal to any of the mobile node's care-of addresses. 5822 - The Destination Address in the original (inner) IPv6 header 5823 is equal to one of the mobile node's home addresses; or this 5824 Destination Address is equal to one of the mobile node's previous 5825 care-of addresses for which the mobile node has an entry in its 5826 Binding Update List, representing an unexpired Binding Update 5827 sent to a home agent on the link on which its previous care-of 5828 address is located (Section 10.11). 5830 - The Source Address in the tunnel (outer) IPv6 header differs from 5831 the Source Address in the original (inner) IPv6 header. 5833 The destination address to which the Binding Update should be sent 5834 in response to receiving a packet meeting all of the above tests is 5835 the Source Address in the original (inner) IPv6 header of the packet. 5837 The home address for which this Binding Update is sent should be the 5838 Destination Address of the original (inner) packet. 5840 Binding Updates sent to correspondent nodes are not generally 5841 required to be acknowledged. However, if the mobile node wants 5842 to be sure that its new care-of address has been entered into a 5843 correspondent node's Binding Cache, the mobile node MAY request an 5844 acknowledgement by setting the Acknowledge (A) bit in the Binding 5845 Update. In this case, however, the mobile node SHOULD NOT continue 5846 to retransmit the Binding Update once the retransmission timeout 5847 period has reached MAX_BINDACK_TIMEOUT. 5849 10.10. Receiving RR Messages 5851 Upon receiving a packet carrying a HoT message, a mobile node MUST 5852 validate the packet according to the following tests: 5854 - The Header Len field in the Mobility Header is greater than or 5855 equal to the length specified in Section 5.1.5. 5857 - The Source Address of the packet belongs to a correspondent node 5858 that the mobile node wishes to use Route Optimization with. 5860 - The Source Address of the packet belongs to a correspondent 5861 node for which the mobile node has a Binding Update List entry 5862 with a state indicating that Return Routability procedure is in 5863 progress. 5865 - The Destination Address of the packet has the home address of the 5866 mobile node, and the packet has been received in a tunnel from 5867 the home agenet. 5869 Any HoT not satisfying all of these tests MUST be silently ignored. 5870 Otherwise, the mobile node MUST record the Home Nonce Index and Home 5871 Cookie in the Binding Update List. If the Binding Update List entry 5872 does not have a Care-of Cookie, the mobile node SHOULD continue 5873 waiting for additional messages. 5875 Upon receiving a packet carrying a CoT message, a mobile node MUST 5876 validate the packet according to the following tests: 5878 - The Header Len field in the Mobility Header is greater than or 5879 equal to the length specified in Section 5.1.5. 5881 - The Source Address of the packet belongs to a correspondent node 5882 that the mobile node wishes to use Route Optimization with. 5884 - The Source Address of the packet belongs to a correspondent 5885 node for which the mobile node has a Binding Update List entry 5886 with a state indicating that Return Routability procedure is in 5887 progress. 5889 - The Destination Address of the packet is the current care-of 5890 address of the mobile node. 5892 Any CoT not satisfying all of these tests MUST be silently ignored. 5893 Otherwise, the mobile node MUST record the Care-of Nonce Index and 5894 Care-of Cookie in the Binding Update List. If the Binding Update 5895 List entry does not have a Home Cookie, the mobile node SHOULD 5896 continue waiting for additional messages. 5898 If after receiving either the HoT or the CoT message and performing 5899 the above actions, the Binding Update List entry has both the Home 5900 and the Care-of Cookies, the mobile node SHOULD send a Binding Update 5901 message as described in Section 10.9. 5903 10.11. Establishing Forwarding from a Previous Care-of Address 5905 When a mobile node connects to a new link and forms a new care-of 5906 address, it MAY establish forwarding of packets from a previous 5907 care-of address to this new care-of address. To do so, the mobile 5908 node sends a Binding Update to any home agent on the link on which 5909 the previous care-of address is located, indicating this previous 5910 care-of address as the home address for the binding, and giving its 5911 new care-of address as the binding's care-of address. Such packet 5912 forwarding allows packets destined to the mobile node from nodes that 5913 have not yet learned the mobile node's new care-of address, to be 5914 forwarded to the mobile node rather than being lost once the mobile 5915 node is no longer reachable at this previous care-of address. 5917 In constructing this Binding Update, the mobile node utilizes the 5918 following specific steps: 5920 - The Home Address field in the Home Address option in the packet 5921 carrying the Binding Update MUST be set to the previous care-of 5922 address for which packet forwarding is being established. 5924 - The care-of address for the new binding MUST be set to the new 5925 care-of address to which packets destined to the previous care-of 5926 address are to be forwarded. Normally, this care-of address for 5927 the binding is specified by setting the Source Address of the 5928 packet carrying the Binding Update, to this address. However, 5929 the mobile node MAY instead include an Alternate Care-of Address 5930 sub-option in the Binding Update option, with its Alternate 5931 Care-of Address field set to the care-of address for the binding. 5933 - The Home Registration (H) bit MUST also be set in this Binding 5934 Update, to request this home agent to temporarily act as a home 5935 agent for this previous care-of address. 5937 This home agent will thus tunnel packets for the mobile node (packets 5938 destined to its specified previous care-of address) to its new 5939 care-of address. All of the procedures defined for home agent 5940 operation MUST be followed by this home agent for this registration. 5941 Note that this home agent does not necessarily know (and need not 5942 know) the mobile node's (permanent) home address as part of this 5943 registration. 5945 The packet carrying the Binding Update MUST be addressed to 5946 this home agent's global unicast address. Normally, this global 5947 unicast address is learned by the mobile node based on the Router 5948 Advertisements received by the mobile node (Section 6.2) while 5949 attached to the link on which this previous care-of address and this 5950 home agent are located; the mobile node obtains this home agent 5951 address from its Home Agents List (Section 4.7). Alternatively, 5952 the mobile node MAY use dynamic home agent address discovery 5953 (Section 10.8) to discover the global unicast address of a home agent 5954 on this previous link, but it SHOULD use an address from its Home 5955 Agents List if available for the prefix it used to form this previous 5956 care-of address. 5958 As with any packet containing a Binding Update (see section 5.1.7), 5959 the Binding Update packet to this home agent MUST meet the 5960 authentication requirements for Binding Updates, defined in 5961 Section 4.5. 5963 10.12. Retransmitting Binding Updates 5965 When the mobile node sends a Binding Update, it has to determine 5966 a value for the initial retransmission timer. If the mobile node 5967 is changing or updating an existing binding at the home agent, it 5968 should use the specified value of INITIAL_BINDACK_TIMEOUT for this 5969 initial retransmission timer. If on the other hand the mobile node 5970 does not have an existing binding at the home agent, it SHOULD use a 5971 value for the initial retransmission timer that is at least 1.5 times 5972 longer than (RetransTimer * DupAddrDetectTransmits). This value is 5973 likely to be substantially longer than the otherwise specified value 5974 of INITIAL_BINDACK_TIMEOUT that would be used by the mobile node. 5975 This longer retransmission interval will allow the the home agent 5976 to complete the DAD procedure which is mandated in this case, as 5977 detailed in section 10.7. 5979 If, after sending a Binding Update in which the care-of address has 5980 changed and the Acknowledge (A) bit is set, a mobile node fails 5981 to receive a valid, matching Binding Acknowledgement within the 5982 selected initial retransmission interval, the mobile node SHOULD 5983 retransmit the Binding Update, until a Binding Acknowledgement is 5984 received. Such a retransmitted Binding Update MUST use a Sequence 5985 Number value greater than that used for the previous transmission of 5986 this Binding Update. The retransmissions by the mobile node MUST 5987 use an exponential back-off process, in which the timeout period 5988 is doubled upon each retransmission until either the node receives 5989 a Binding Acknowledgement or the timeout period reaches the value 5990 MAX_BINDACK_TIMEOUT. 5992 10.13. Rate Limiting for Sending Binding Updates 5994 A mobile node MUST NOT send Binding Updates about the same binding to 5995 any individual node more often than once per MAX_UPDATE_RATE seconds. 5996 After sending MAX_FAST_UPDATES consecutive Binding Updates to a 5997 particular node with the same care-of address, the mobile node SHOULD 5998 reduce its rate of sending Binding Updates to that node, to the rate 5999 of SLOW_UPDATE_RATE per second. The mobile node MAY continue to send 6000 Binding Updates at this slower rate indefinitely, in hopes that the 6001 node will eventually be able to process a Binding Update and begin 6002 to route its packets directly to the mobile node at its new care-of 6003 address. 6005 10.14. Receiving Binding Acknowledgements 6007 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 6008 node MUST validate the packet according to the following tests: 6010 - The packet meets the authentication requirements for Binding 6011 Acknowledgements, defined in Section 4.5. 6013 - The Option Length field in the Binding Acknowledgement option is 6014 greater than or equal to the length specified in Section 5.1.8. 6016 - The Sequence Number field matches the Sequence Number sent by the 6017 mobile node to this destination address in an outstanding Binding 6018 Update. 6020 Any Binding Acknowledgement not satisfying all of these tests MUST be 6021 silently ignored, although the remainder of the packet (i.e., other 6022 options, extension headers, or payload) SHOULD be processed normally 6023 according to any procedure defined for that part of the packet. 6025 When a mobile node receives a packet carrying a valid Binding 6026 Acknowledgement, the mobile node MUST examine the Status field as 6027 follows: 6029 - If the Status field indicates that the Binding Update was 6030 accepted (the Status field is less than 128), then the mobile 6031 node MUST update the corresponding entry in its Binding Update 6032 List to indicate that the Binding Update has been acknowledged; 6033 the mobile node MUST then stop retransmitting the Binding Update. 6034 In addition, if the value specified in the Lifetime field in the 6035 Binding Acknowledgement is less than the Lifetime value sent 6036 in the Binding Update being acknowledged, then the mobile node 6037 MUST subtract the difference between these two Lifetime values 6038 from the remaining lifetime for the binding as maintained in the 6039 corresponding Binding Update List entry (with a minimum value 6040 for the Binding Update List entry lifetime of 0). That is, if 6041 the Lifetime value sent in the Binding Update was L_update, the 6042 Lifetime value received in the Binding Acknowledgement was L_ack, 6043 and the current remaining lifetime of the Binding Update List 6044 entry is L_remain, then the new value for the remaining lifetime 6045 of the Binding Update List entry should be 6047 max((L_remain - (L_update - L_ack)), 0) 6049 where max(X, Y) is the maximum of X and Y. The effect of this 6050 step is to correctly manage the mobile node's view of the 6051 binding's remaining lifetime (as maintained in the corresponding 6052 Binding Update List entry) so that it correctly counts down from 6053 the Lifetime value given in the Binding Acknowledgement, but with 6054 the timer countdown beginning at the time that the Binding Update 6055 was sent. 6057 - If the Status field indicates that the Binding Update was 6058 rejected (the Status field is greater than or equal to 128), then 6059 the mobile node MUST delete the corresponding Binding Update List 6060 entry, and it MUST also stop retransmitting the Binding Update. 6061 Optionally, the mobile node MAY then take steps to correct the 6062 cause of the error and retransmit the Binding Update (with a new 6063 Sequence Number value), subject to the rate limiting restriction 6064 specified in Section 10.13. 6066 10.15. Receiving Binding Requests 6068 When a mobile node receives a packet containing a Binding Request, 6069 it SHOULD return to the sender a packet containing a Binding Update. 6070 The Lifetime field in this Binding Update SHOULD be set to a new 6071 lifetime, extending any current lifetime remaining from a previous 6072 Binding Update sent to this node (as indicated in any existing 6073 Binding Update List entry for this node), except that this lifetime 6074 MUST NOT exceed the remaining lifetime for the mobile node's primary 6075 care-of address registration at its home agent. When sending this 6076 Binding Update, the mobile node MUST update its Binding Update List 6077 in the same way as for any other Binding Update sent by the mobile 6078 node. 6080 Note, however, that the mobile node MAY choose to keep its current 6081 binding private from the sender of the Binding Request. In this 6082 case, the mobile node instead SHOULD return a Binding Update to the 6083 sender, in which the Lifetime field is set to zero and the care-of 6084 address is set to the mobile node's home address. 6086 If the Binding Request for which the Binding Update is being returned 6087 contains a Unique Identifier Sub-Option, the Binding Update MUST also 6088 include a Unique Identifier Sub-Option. The unique identifier in the 6089 Sub-Option Data field of the Unique Identifier Sub-Option MUST be 6090 copied from the unique identifier carried in the Binding Request. 6092 10.16. Receiving ICMP Error Messages 6094 10.17. Receiving ICMP Error Messages 6096 The Option Type value for a Binding Update option specifies that 6097 any node receiving this option that does not recognize the Option 6098 Type SHOULD return an ICMP Parameter Problem, Code 2, message to 6099 the sender of the packet containing the Binding Update option. If 6100 a node sending a Binding Update receives such an ICMP error message 6101 in response, it SHOULD record in its Binding Update List that future 6102 Binding Updates SHOULD NOT be sent to this destination. 6104 Likewise, although ALL IPv6 nodes (whether host or router, whether 6105 mobile or stationary) MUST implement the ability to correctly process 6106 received packets containing a Home Address option, all Option Type 6107 values in IPv6 include a specification of the behavior that a node 6108 receiving a packet containing this option performs if it does not 6109 implement receipt of that type of option. For the Home Address 6110 option, the Option Type value specifies that any node receiving 6111 this option that does not recognize the Option Type SHOULD return 6112 an ICMP Parameter Problem, Code 2, message to the sender of the 6113 packet containing the Home Address option. If a mobile node receives 6114 such an ICMP error message from some node indicating that it does 6115 not recognize the mobile node's Home Address option, the mobile 6116 node SHOULD log the error and then discard the ICMP message; this 6117 error message indicates that the node to which the original packet 6118 was addressed (the node returning the ICMP error message) does not 6119 correctly implement this required part of the IPv6 protocol. 6121 10.18. Sending Mobile Prefix Solicitations 6123 When a mobile node has a home address that is about to become 6124 invalid, it sends a Mobile Prefix Solicitation to its home agent 6125 in an attempt to acquire fresh routing prefix information. The 6126 new information also enables the mobile node to participate in 6127 renumbering operations affecting the home network, as described in 6128 section 9.7. 6130 The mobile node SHOULD send a Solicitation to the home agent when 6131 its home address will become invalid within MaxRtrAdvInterval 6132 seconds, where this value is acquired in a previous Mobile Prefix 6133 Advertisement from the home agent. If no such value is known, the 6134 value MAX_PFX_ADV_DELAY seconds is used instead (see section 11). 6136 If the mobile node does not have a valid home address available for 6137 use as the IP source address, it MAY use its care-of address (but 6138 there will not be a security association between the Home Agent 6139 and the care-of address for the corresponding Advertisement to be 6140 authenticated). 6142 This solicitation follows the same retransmission rules specified for 6143 Router Solicitations [20], except that the initial retransmission 6144 interval is specified to be INITIAL_SOLICIT_TIMER (see section 11). 6146 10.19. Receiving Mobile Prefix Advertisements 6148 Section 9.7 describes the operation of a home agent to support boot 6149 time configuration and renumbering a mobile node's home subnet while 6150 the mobile node is away from home. The home agent sends Mobile 6151 Prefix Advertisement messages to the mobile node while away from 6152 home, giving "important" Prefix Information options that describe 6153 changes in the prefixes in use on the mobile node's home link. 6155 When a mobile node receives a Mobile Prefix Advertisement, it MUST 6156 validate it according to the following tests: 6158 - The Source Address of the IP packet carrying the Mobile Prefix 6159 Advertisement is the same as the home agent address to which the 6160 mobile node last sent an accepted "home registration" Binding 6161 Update to register its primary care-of address. Otherwise, if 6162 no such registrations have been made, it SHOULD be the mobile 6163 node's stored home agent address, if one exists. Otherwise, if 6164 the mobile node has not yet discovered its home agent's address, 6165 it MUST NOT accept Mobile Prefix Advertisements. 6167 - The packet MUST be protected by IPsec [14, 12, 13] to guard 6168 against malicious prefix advertisements. The IPsec protection 6169 MUST provide sender authentication, data integrity protection, 6170 and replay protection, covering the advertisement. 6172 Any received Mobile Prefix Advertisement not meeting all of these 6173 tests MUST be silently discarded. 6175 If a received Mobile Prefix Advertisement is not discarded according 6176 to the tests listed above, the mobile node MUST process the Prefix 6177 Information Options as if they arrived in a Router Advertisement 6178 on the mobile node's home link [20]. Such processing may result 6179 in the mobile node configuring a new home address, although due 6180 to separation between preferred lifetime and valid lifetime, such 6181 changes should not affect most communication by the mobile node, in 6182 the same way as for nodes that are at home. 6184 If the advertisement contains a Binding Request option, the mobile 6185 node SHOULD return a Binding Update, which will be viewed by the 6186 home agent as an acknowledgement of the corresponding Mobile Prefix 6187 Advertisement, which it can cease transmitting. 6189 In addition, if processing of this Advertisement resulted in the 6190 mobile node configuring a new home address, and if the method used 6191 for this new home address configuration would require the mobile node 6192 to perform Duplicate Address Detection [35] for the new address if 6193 the mobile node were located at home, then the mobile node MUST set 6194 the Duplicate Address Detection (D) bit in this Binding Update to 6195 its home agent, to request the home agent to perform this Duplicate 6196 Address Detection on behalf of the mobile node. 6198 10.20. Using Multiple Care-of Addresses 6200 As described in Section 10.6, a mobile node MAY use more than one 6201 care-of address at a time. Particularly in the case of many wireless 6202 networks, a mobile node effectively might be reachable through 6203 multiple links at the same time (e.g., with overlapping wireless 6204 cells), on which different on-link subnet prefixes may exist. A 6205 mobile node SHOULD select a primary care-of address from among those 6206 care-of addresses it has formed using any of these subnet prefixes, 6207 based on the movement detection mechanism in use, as described in 6208 Section 10.4. When the mobile node selects a new primary care-of 6209 address, it MUST register it with its home agent by sending it a 6210 Binding Update with the Home Registration (H) and Acknowledge (A) 6211 bits set, as described in Section 10.7. 6213 To assist with smooth handovers, a mobile node SHOULD retain 6214 its previous primary care-of address as a (non-primary) care-of 6215 address, and SHOULD still accept packets at this address, even after 6216 registering its new primary care-of address with its home agent. 6217 This is reasonable, since the mobile node could only receive packets 6218 at its previous primary care-of address if it were indeed still 6219 connected to that link. If the previous primary care-of address was 6220 allocated using stateful Address Autoconfiguration [2], the mobile 6221 node may not wish to release the address immediately upon switching 6222 to a new primary care-of address. 6224 10.21. Routing Multicast Packets 6226 A mobile node that is connected to its home link functions in the 6227 same way as any other (stationary) node. Thus, when it is at home, 6228 a mobile node functions identically to other multicast senders and 6229 receivers. This section therefore describes the behavior of a mobile 6230 node that is not on its home link. 6232 In order to receive packets sent to some multicast group, a mobile 6233 node must join that multicast group. One method by which a mobile 6234 node MAY join the group is via a (local) multicast router on the 6235 foreign link being visited. The mobile node SHOULD use one of its 6236 care-of addresses that shares a subnet prefix with the multicast 6237 router, as the source IPv6 address of its multicast group membership 6238 control messages. The mobile node MUST insert a Home Address 6239 destination option in such outgoing multicast packets, so that any 6240 multicast applications that depend on the address of the sending node 6241 will correctly use the mobile node's home address for that value. 6243 Alternatively, a mobile node MAY join multicast groups via a 6244 bi-directional tunnel to its home agent. The mobile node tunnels its 6245 multicast group membership control packets to its home agent, and the 6246 home agent forwards multicast packets down the tunnel to the mobile 6247 node. 6249 A mobile node that wishes to send packets to a multicast group 6250 also has two options: (1) send directly on the foreign link being 6251 visited; or (2) send via a tunnel to its home agent. Because 6252 multicast routing in general depends upon the Source Address used in 6253 the IPv6 header of the multicast packet, a mobile node that tunnels a 6254 multicast packet to its home agent MUST use its home address as the 6255 IPv6 Source Address of the inner multicast packet. 6257 10.22. Returning Home 6259 A mobile node detects that it has returned to its home link through 6260 the movement detection algorithm in use (Section 10.4), when the 6261 mobile node detects that its home subnet prefix is again on-link. 6262 The mobile node SHOULD then send a Binding Update to its home agent, 6263 to instruct its home agent to no longer intercept or tunnel packets 6264 for it. In this Binding Update, the mobile node MUST set the care-of 6265 address for the binding (the Source Address field in the packet's 6266 IPv6 header) to the mobile node's own home address. As with other 6267 Binding Updates sent to register with its home agent, the mobile 6268 node MUST set the Acknowledge (A) and Home Registration (H) bits, 6269 and SHOULD retransmit the Binding Update until a matching Binding 6270 Acknowledgement is received. 6272 When sending this Binding Update to its home agent, the mobile 6273 node must be careful in how it uses Neighbor Solicitation [20] (if 6274 needed) to learn the home agent's link-layer address, since the home 6275 agent will be currently configured to defend the mobile node's home 6276 address for Duplicate Address Detection. In particular, a Neighbor 6277 Solicitation from the mobile node using its home address as the 6278 Source Address would be detected by the home agent as a duplicate 6279 address. In many cases, Neighbor Solicitation by the mobile node 6280 for the home agent's address will not be necessary, since the mobile 6281 node may have already learned the home agent's link-layer address, 6282 for example from a Source Link-Layer Address option in the Router 6283 Advertisement from which it learned that its home address was on-link 6284 and that the mobile node had thus returned home. If the mobile node 6285 does Neighbor Solicitation to learn the home agent's link-layer 6286 address, in this special case of the mobile node returning home, the 6287 mobile node MUST unicast the packet, and in addition set the Source 6288 Address of this Neighbor Solicitation to the unspecified address 6289 (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home 6290 agent will be able to distinguish from a similar packet that would 6291 only be used for DAD. The home agent will send a multicast Neighbor 6292 Advertisement back to the mobile node with the Solicited flag ('S') 6293 set to zero. The mobile node SHOULD accept this advertisement, and 6294 set the state of the Neighbor Cache entry for the home agent to 6295 REACHABLE. 6297 The mobile node then sends its Binding Update using the home agent's 6298 link-layer address, instructing its home agent to no longer serve 6299 as a home agent for it. By processing this Binding Update, the 6300 home agent will cease defending the mobile node's home address for 6301 Duplicate Address Detection and will no longer respond to Neighbor 6302 Solicitations for the mobile node's home address. The mobile node 6303 is then the only node on the link receiving packets at the mobile 6304 node's home address. In addition, when returning home prior to the 6305 expiration of a current binding for its home address, and configuring 6306 its home address on its network interface on its home link, the 6307 mobile node MUST NOT perform Duplicate Address Detection on its own 6308 home address, in order to avoid confusion or conflict with its home 6309 agent's use of the same address. If the mobile node returns home 6310 after the bindings for all of its care-of addresses have expired, 6311 then it SHOULD perform DAD. 6313 After the Mobile Node sends the Binding Update, the Home Agent MUST 6314 remove the Proxy Neighbor Cache entry for the Mobile Node and MAY 6315 learn its link-layer address based on the link-layer packet or cached 6316 information, or if that is not available, it SHOULD send a Neighbor 6317 Solicitation with the target address equal to the Binding Update's 6318 source IP address. The Mobile Node MUST then reply with a unicast 6319 Neighbor Advertisement to the Home Agent with its link-layer address. 6320 While the Mobile Node is waiting for a Binding Acknowledgement, it 6321 MUST NOT respond to any Neighbor Solicitations for its Home Address 6322 other than those originating from the IP address to which it sent the 6323 Binding Update. 6325 After receiving the Binding Acknowledgement for its Binding Update 6326 to its home agent, the mobile node MUST multicast onto the home 6327 link (to the all-nodes multicast address) a Neighbor Advertisement 6328 message [20], to advertise the mobile node's own link-layer address 6329 for its own home address. The Target Address in this Neighbor 6330 Advertisement message MUST be set to the mobile node's home address, 6331 and the Advertisement MUST include a Target Link-layer Address option 6332 specifying the mobile node's link-layer address. The mobile node 6333 MUST multicast such a Neighbor Advertisement message for each of its 6334 home addresses, as defined by the current on-link prefixes, including 6335 its link-local address and site-local address. The Solicited 6336 Flag (S) in these Advertisements MUST NOT be set, since they were 6337 not solicited by any Neighbor Solicitation message. The Override 6338 Flag (O) in these Advertisements MUST be set, indicating that the 6339 Advertisements SHOULD override any existing Neighbor Cache entries at 6340 any node receiving them. 6342 Since multicasts on the local link (such as Ethernet) are typically 6343 not guaranteed to be reliable, the mobile node MAY retransmit these 6344 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 6345 increase their reliability. It is still possible that some nodes on 6346 the home link will not receive any of these Neighbor Advertisements, 6347 but these nodes will eventually be able to recover through use of 6348 Neighbor Unreachability Detection [20]. 6350 11. Protocol Constants 6352 HomeRtrAdvInterval 3,600 seconds 6353 DHAAD_RETRIES 3 retransmissions 6354 INITIAL_BINDACK_TIMEOUT 1 second 6355 INITIAL_DHAAD_TIMEOUT 2 seconds 6356 INITIAL_SOLICIT_TIMER 2 seconds 6357 MAX_BINDACK_TIMEOUT 256 seconds 6358 MAX_UPDATE_RATE once per second 6359 MAX_FAST_UPDATES 5 transmissions 6360 MAX_ADVERT_REXMIT 3 transmissions 6361 MAX_PFX_ADV_DELAY 1,000 seconds 6362 PREFIX_ADV_RETRIES 3 retransmissions 6363 PREFIX_ADV_TIMEOUT 5 seconds 6364 SLOW_UPDATE_RATE once per 10 second interval 6366 12. Future Extensions 6368 12.1. Piggybacking 6370 This document does not specify how to piggyback payload on the 6371 binding related messages. However, it is envision that this can be 6372 specified in a separate document when currently discussed issues such 6373 as the interaction between piggybacking and IPsec are fully resolved 6374 (see also Section 12.3). 6376 The idea is to use the Flag field in the HoTI message so that the MN 6377 can indicate that it supports the receipt of piggybacked messages, 6378 use the Flag field in the HoT message for the CN to indicate that 6379 it can support the receipt of piggybacked messages, and then carry 6380 the piggybacked payload after the MH header by specifying a payload 6381 protocol type other than NO_NXTHDR (59). 6383 Until such a separate specification exists implementations conforming 6384 to this specification MUST set the payload protocol type to NO_NXTHDR 6385 (59 decimal). 6387 12.2. Triangular Routing and Unverified HAOs 6389 Due to the concerns about opening up reflection attacks with the home 6390 address option this specification requires that this option must be 6391 verified against the binding cache i.e. there must be a binding 6392 cache entry for the Home Address and Care-of Address. 6394 Future extensions may be specified that allow the use of unverified 6395 home address options in ways that do not introduce security issues. 6397 12.3. New Authorization Methods beyond RR 6399 While the RR method provides a good level of security, there exists 6400 methods that have even higher level of security. Secondly, as 6401 discussed in Section 14.3, future enhancements of IPv6 security may 6402 cause a need to improve also the security of RR. The question is then 6403 what is the method to securely agree on the use of another method, 6404 while still allowing RR for some hosts during a transition period. 6405 In some cases, a third party can help to make this selection. But 6406 in general infrastructureless methods have little information beyond 6407 the exchanged messages and their contents. For these reasons, this 6408 specification requires a protection mechanism for selecting between 6409 RR and potential other future mechanisms (see Section ??). This 6410 isn't 6412 Using IPsec as the sole method for authorizing Binding Updates 6413 to correspondent nodes is also possible. The protection of the 6414 Mobility Header for this purpose is easy, though one must ensure 6415 that the IPsec SA was created with appropriate authorization to use 6416 the home address referenced in the Binding Update. For instance, 6417 a certificate used by IKE to create the security association might 6418 contain the home address. A future specification may specify how 6419 this is done. 6421 13. IANA Considerations 6423 This document defines a new IPv6 protocol, the Mobility Header, 6424 described in Section 5.1. This protocol must be assigned a protocol 6425 number. The MH Type field in the Mobility Header is used to indicate 6426 a particular type of a message. The current message types are 6427 described in Sections 5.1.2 to 5.1.9, and include the following: 6429 0 Binding Request 6431 1 HoA Test Init 6433 2 CoA Test Init 6435 3 HoA Test 6437 4 CoA Test 6439 5 Binding Update 6441 6 Binding Acknowledgement 6443 7 Binding Missing 6445 Future values of the MH Type can be allocated using standards 6446 action [19]. 6448 Furthermore, each Mobility Header message may contain parameters as 6449 described in Section 5.2. The current parameters are defined in 6450 Sections 5.2.2 to 5.2.5, and include the following: 6452 0 Pad1 6454 1 PadN 6456 2 Unique Identifier 6458 3 Alternate Care-of Address 6460 Future values of the Parameter Type can be allocated using standards 6461 action [19]. 6463 This document also defines a new IPv6 destination option, the 6464 Home Address option, described in Section 5.3. This option must 6465 be assigned an Option Type value. This destination option may 6466 also contain sub-options as described in Section 5.5. The current 6467 sub-options are specified in Sections 5.5.1 to 5.5.2, and include the 6468 following: 6470 0 Pad1 sub-option 6472 1 PadN sub-option 6474 This document also defines a new IPv6 Routing Header type, 2, 6475 described in Section 5.4. The value 2 is allocated by IANA when this 6476 specification becomes an RFC. 6478 In addition, this document defines four ICMP message types, two used 6479 as part of the dynamic home agent address discovery mechanism and 6480 two used in lieu of router solicitations and advertisements when the 6481 mobile node is away from the home link: 6483 - The Home Agent Address Discovery Request message, described in 6484 Section 5.6; 6486 - The Home Agent Address Discovery Reply message, described in 6487 Section 5.7; 6489 - The Mobile Prefix Solicitation message, described in Section 5.8; 6490 and 6492 - The Mobile Prefix Advertisement message, described in 6493 Section 5.9. 6495 This document also defines two new Neighbor Discovery [20] options, 6496 which must be assigned Option Type values within the option numbering 6497 space for Neighbor Discovery messages: 6499 - The Advertisement Interval option, described in Section 6.3; and 6501 - The Home Agent Information option, described in Section 6.4. 6503 14. Security Considerations 6505 14.1. Security for the Tunneling to and from the Home Agent 6507 The use of IPsec ESP to protects payload packets tunneled to the 6508 mobile node from the home agent and reverse tunneled back to the 6509 home agent. While this specification does not mandate the use of 6510 ESP, it is highly recommended due to unauthenticated tunnels opening 6511 a flexible reflection device to attackers, even if Mobile IPv6 6512 signaling such as Binding Updates are not affected. 6514 14.2. Security for the Binding Updates to the Home Agent 6516 The use of IPsec ESP to protect Mobility Header messages between the 6517 mobile node and the home agent protects the integrity of the Binding 6518 Updates and Binding Acknowledgements. If manually keyed IPsec is 6519 used, it does not, however, protect against Binding Update replays. 6520 Replay protection is provided by the application layer sequence 6521 number described in Section 4.5.4. 6523 14.3. Security for the Binding Updates to the Correspondent Nodes 6525 The introduction of home address and care-of-address based return 6526 routability (RR) tests prevent any off-path attacks beyond those that 6527 are already possible in basic IPv6 [23]. 6529 Protection against attackers on the home agent link and the 6530 correspondent node link, as well as on the path between, are 6531 roughly similar to the situation in existing IPv6 as well. However, 6532 one difference is that in basic IPv6 an on-path attacker must be 6533 constantly present on the link or the path (in order to perform e.g. 6534 a man-in-the-middle attack), whereas with Mobile IPv6 an attacker can 6535 leave an existing binding behind, even after it is no longer on the 6536 link or on the path [23]. For this reason, this specification limits 6537 the validity of RR authorized bindings to a maximum of five minutes 6538 after the last RR check has been performed. 6540 In practice the easiest attacks on the path between the Home Agent 6541 and a correspondent node is when multi-access links exist at either 6542 node; a correspondent node on a public access wireless LAN would be 6543 a good example. There are attacks that can be launched on routers 6544 or switches on the path as well but those seem to be harder in many 6545 cases. Thus, the weakest places are typically in layer 2 security as 6546 well in IPv6 Neighbour and Router discovery on multi-access links. 6547 If these were secured using some new technology in the future, this 6548 would make Mobile IPv6 an easier route for attackers to use. For 6549 this reason, this specification requires a protection mechanism for 6550 selecting between RR and potential other future mechanisms (see 6551 Section ??). 6553 14.4. Security for the Home Address Option 6555 The use of the Home Address option allows packets sent by a mobile 6556 node to pass normally through routers implementing ingress filtering 6557 [7]. Since the care-of address used in the Source Address field of 6558 the packet's IPv6 header is topologically correct for the sending 6559 location of the mobile node, ingress filtering can trace the 6560 location of the mobile node in the same way as can be done with any 6561 sender when ingress filtering is in use. As this location does not 6562 survive in the answers sent by the correspondent node, this document 6563 restricts the use of the Home Address Option to those situations 6564 where a binding has been established, and the home address has agreed 6565 to the participation in the binding. This prevents reflection 6566 attacks through the use of the Home Address Option. 6568 No special authentication of the Home Address option is required 6569 beyond the above, except that if the IPv6 header of a packet is 6570 covered by authentication, then that authentication MUST also cover 6571 the Home Address option; this coverage is achieved automatically by 6572 the definition of the Option Type code for the Home Address option 6573 (Section 5.3), since it indicates that the option is included in the 6574 authentication computation. Thus, even when authentication is used 6575 in the IPv6 header, the security of the Source Address field in the 6576 IPv6 header is not compromised by the presence of a Home Address 6577 option. Without authentication of the packet, then any field in the 6578 IPv6 header, including the Source Address field, and any other parts 6579 of the packet, including the Home Address option, can be forged or 6580 modified in transit. In this case, the contents of the Home Address 6581 option is no more suspect than any other part of the packet. 6583 A node receiving a packet that includes a Home Address option MAY 6584 implement the processing of this option by physically exchanging the 6585 Home Address option field with the source IPv6 address in the IPv6 6586 header. 6588 14.5. Firewall considerations 6590 The definition of Routing Header 2 in Section 5.4 and the associated 6591 processing rules have been chosen so that the header can not be used 6592 for what is traditionally viewed as source routing. In particular, 6593 the IPv6 destination and the Home Address in the routing header will 6594 always have to be assigned to the same node otherwise the packet will 6595 be dropped. 6597 This means that the typical security concerns for source routing 6598 including the automatic reversal of unauthenticated source routes 6599 (which is an issue for IPv4 but not for IPv6 source routing) and the 6600 ability to use source routing to "jump" between nodes inside as well 6601 as outside a firewall, are not at play. 6603 In essence the semantics of the type 2 routing header is the same as 6604 a special form of IP-in-IP tunneling where the inner and outer source 6605 addresses are the same. 6607 This implies that device which implement filtering of packets should 6608 be able to distinguish routing header type 2 from other routing 6609 headers, as required in section 7.1. This is necessary in order to 6610 allow Mobile IPv6 traffic while still having the option to filter out 6611 other use of routing headers. 6613 Acknowledgements 6615 We would like to thank the members of the Mobile IP and IPng Working 6616 Groups for their comments and suggestions on this work. We would 6617 particularly like to thank (in alphabetical order) Fred Baker 6618 (Cisco), Josh Broch (Carnegie Mellon University), Robert Chalmers 6619 (University of California at Santa Barbara), Noel Chiappa (MIT), 6620 Vijay Devarapalli (Nokia Research Center), Rich Draves (Microsoft 6621 Research), Francis Dupont (ENST Bretagne), Thomas Eklund (Xelerated), 6622 Jun-Ichiro Itojun Hagino (IIJ Research Laboratory), Krishna Kumar 6623 (IBM Research), T.J. Kniveton (Nokia Research), Jiwoong Lee (KTF), 6624 Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), Erik Nordmark (Sun 6625 Microsystems), Simon Nybroe (Ericsson Telebit), David Oran (Cisco), 6626 Lars Henrik Petander (HUT), Basavaraj Patil (Nokia), Ken Powell 6627 (Compaq), Phil Roberts (Motorola), Patrice Romand (Bull S.A.), 6628 Jeff Schiller (MIT) Tom Soderlund (Nokia Research), Hesham Soliman 6629 (Ericsson), Jim Solomon (RedBack Networks), Tapio Suihko (Technical 6630 Research Center of Finland), Benny Van Houdt (University of Antwerp), 6631 Jon-Olov Vatn (KTH), Alper Yegin (Sun Microsystems), and Xinhua Zhao 6632 (Stanford University) for their detailed reviews of earlier versions 6633 of this document. Their suggestions have helped to improve both the 6634 design and presentation of the protocol. 6636 We would also like to thank the participants in the Mobile IPv6 6637 testing event held at Nancy, France, September 15-17, 1999, for 6638 their valuable feedback as a result of interoperability testing 6639 of four Mobile IPv6 implementations coming from four different 6640 organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC 6641 (FreeBSD), and INRIA (FreeBSD). Further, we would like to thank the 6642 feedback from the implementors who participated in the Mobile IPv6 6643 interoperability testing at Connectathon 2000 in San Jose, 6644 California, March 6-9, 2000. Similarly, we would like to thank the 6645 participants at the ETSI interoperability testing at ETSI, in Sophia 6646 Antipolis, France, during October 2-6, 2000, including teams from 6647 Compaq, Ericsson, INRIA, Nokia, and Technical University of Helsinki. 6649 Lastly, we must express our appreciation for the significant 6650 contributions made by the Mobile IPv6 Security Design Team, including 6651 (in alphabetical order) Jari Arkko, Gabriel Montenegro, Erik 6652 Nordmark, and Pekka Nikander, who have contributed volumes of text to 6653 this specification. 6655 References 6657 [1] Tuomas Aura and Jari Arkko. MIPv6 BU Attacks and Defenses. 6658 Internet Draft draft-aura-mipv6-bu-attacks-01.txt (Work In 6659 Progress), IETF, February 2002. 6661 [2] Jim Bound and Charles Perkins. Dynamic Host Configuration 6662 Protocol for IPv6 (DHCPv6), February 1999. Work in progress. 6664 [3] S. Bradner. Key words for use in RFCs to Indicate Requirement 6665 Levels. Request for Comments (Best Current Practice) 2119, 6666 Internet Engineering Task Force, March 1997. 6668 [4] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 6669 Specification. Request for Comments (Proposed Standard) 2473, 6670 Internet Engineering Task Force, December 1998. 6672 [5] A. Conta and S. Deering. Internet Control Message Protocol 6673 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 6674 Specification. Request for Comments (Draft Standard) 2463, 6675 Internet Engineering Task Force, December 1998. 6677 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 6678 Specification. Request for Comments (Draft Standard) 2460, 6679 Internet Engineering Task Force, December 1998. 6681 [7] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating 6682 Denial of Service Attacks which employ IP Source Address 6683 Spoofing. Request for Comments (Informational) 2267, Internet 6684 Engineering Task Force, January 1998. 6686 [8] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). 6687 Request for Comments (Proposed Standard) 2409, Internet 6688 Engineering Task Force, November 1998. 6690 [9] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 6691 Request for Comments (Proposed Standard) 2373, Internet 6692 Engineering Task Force, July 1998. 6694 [10] Editor J. Reynolds. Assigned Numbers: RFC 1700 is Replaced by 6695 an On-line Database. Request for Comments (Informational) 3232, 6696 Internet Engineering Task Force, January 2002. 6698 [11] D. Johnson and S. Deering. Reserved IPv6 Subnet Anycast 6699 Addresses. Request for Comments (Proposed Standard) 2526, 6700 Internet Engineering Task Force, March 1999. 6702 [12] S. Kent and R. Atkinson. IP Authentication Header. Request for 6703 Comments (Proposed Standard) 2402, Internet Engineering Task 6704 Force, November 1998. 6706 [13] S. Kent and R. Atkinson. IP Encapsulating Security Payload 6707 (ESP). Request for Comments (Proposed Standard) 2406, Internet 6708 Engineering Task Force, November 1998. 6710 [14] S. Kent and R. Atkinson. Security Architecture for the Internet 6711 Protocol. Request for Comments (Proposed Standard) 2401, 6712 Internet Engineering Task Force, November 1998. 6714 [15] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 6715 for Message Authentication. Request for Comments 6716 (Informational) 2104, Internet Engineering Task Force, 6717 February 1997. 6719 [16] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet 6720 Security Association and Key Management Protocol (ISAKMP). 6721 Request for Comments (Proposed Standard) 2408, Internet 6722 Engineering Task Force, November 1998. 6724 [17] P. V. Mockapetris. Domain names - concepts and facilities. 6725 Request for Comments (Standard) 1034, Internet Engineering Task 6726 Force, November 1987. 6728 [18] P. V. Mockapetris. Domain names - implementation and 6729 specification. Request for Comments (Standard) 1035, Internet 6730 Engineering Task Force, November 1987. 6732 [19] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 6733 Considerations Section in RFCs. Request for Comments (Best 6734 Current Practice) 2434, Internet Engineering Task Force, October 6735 1998. 6737 [20] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 6738 IP Version 6 (IPv6). Request for Comments (Draft Standard) 6739 2461, Internet Engineering Task Force, December 1998. 6741 [21] NIST. Secure Hash Standard. FIPS PUB 180-1, April 1995. 6743 [22] Erik Nordmark. Securing MIPv6 BUs using return routability 6744 (BU3WAY). Internet Draft draft-nordmark-mobileip-bu3way-00.txt 6745 (Work In Progress), IETF, November 2001. 6747 [23] Erik Nordmark, Gabriel Montenegro, Pekka Nikander, and Jari 6748 Arkko. Mobile IPv6 Security Design Rationale. To appear, 2002. 6750 [24] C. Perkins. IP Encapsulation within IP. Request for Comments 6751 (Proposed Standard) 2003, Internet Engineering Task Force, 6752 October 1996. 6754 [25] C. Perkins. IP Mobility Support. Request for Comments 6755 (Proposed Standard) 2002, Internet Engineering Task Force, 6756 October 1996. 6758 [26] C. Perkins. Minimal Encapsulation within IP. Request for 6759 Comments (Proposed Standard) 2004, Internet Engineering Task 6760 Force, October 1996. 6762 [27] Charles Perkins and David B. Johnson. Route Optimization in 6763 Mobile IP, February 1999. Work in progress. 6765 [28] D. Piper. The Internet IP Security Domain of Interpretation for 6766 ISAKMP. Request for Comments (Proposed Standard) 2407, Internet 6767 Engineering Task Force, November 1998. 6769 [29] D. C. Plummer. Ethernet Address Resolution Protocol: Or 6770 converting network protocol addresses to 48.bit Ethernet address 6771 for transmission on Ethernet hardware. Request for Comments 6772 (Standard) 826, Internet Engineering Task Force, November 1982. 6774 [30] J. Postel. User Datagram Protocol. Request for Comments 6775 (Standard) 768, Internet Engineering Task Force, August 1980. 6777 [31] J. Postel. Transmission Control Protocol. Request for Comments 6778 (Standard) 793, Internet Engineering Task Force, September 1981. 6780 [32] J. Reynolds and J. Postel. Assigned Numbers. Request for 6781 Comments (Standard) 1700, Internet Engineering Task Force, 6782 October 1994. 6784 [33] Michael Roe, Greg O'Shea, Tuomas Aura, and Jari Arkko. 6785 Authentication of Mobile IPv6 Binding Updates and 6786 Acknowledgments. Internet Draft draft-roe-mobileip-updateauth-02.txt 6787 (Work In Progress), IETF, February 2002. 6789 [34] Pekka Savola. Security of IPv6 Routing Header and Home Address 6790 Options. Internet Draft draft-savola-ipv6-rh-ha-security-01.txt 6791 (Work In Progress), IETF, November 2001. 6793 [35] S. Thomson and T. Narten. IPv6 Stateless Address 6794 Autoconfiguration. Request for Comments (Draft Standard) 2462, 6795 Internet Engineering Task Force, December 1998. 6797 A. Changes from Previous Version of the Draft 6799 This appendix briefly lists some of the major changes in this 6800 draft relative to the previous version of this same draft, 6801 draft-ietf-mobileip-ipv6-15.txt: 6803 A.1. Changes from Draft Version ...-15 6805 - A binding update authorization mechanism suitable for use 6806 between previously unknown peers in the global Internet has been 6807 incorporated to the specification. As a result, Sections 4.5, 6808 5.1, 14 and others have been substantially revised. 6810 - A new IPv6 protocol has replaced IPv6 Destination Options for 6811 some of the MIPv6 signaling. This was done in order to enable 6812 the use of standard IPsec for the protection of binding updates 6813 between the mobile node and the home agent, the protection of 6814 RR packets as they are forwarded to the mobile node from the 6815 home agent, and possibly in the future the protection of binding 6816 updates themselves to the correspondent nodes. This has resulted 6817 in substantial modifications in Section 5. 6819 - The use of the Home Address Option has been restricted to the 6820 situation where a binding already exists. This has been done 6821 in order to limit distributed Denial-of-Service attacks through 6822 reflections attacks that employ the Home Address Option. 6824 - A new Binding Missing message has been added to signal the 6825 mobile node that it has used the Home Address Option when the 6826 correspondent node has no existing binding to the node. 6828 - The Authentication Data suboption has been made a part of 6829 the Binding Update and Acknowledgement messages, and is now 6830 calculated in the specific manner required by the authorization 6831 mechanism (RR). 6833 - Sequence number length for Binding Update messages has been 6834 increased to 32 bits to protect home registrations against replay 6835 attacks. 6837 - Mobile IPv6 uses now Routing Header type 2 instead of the 6838 general type 0, in order to limit potential dangers that 6839 general capabilities offers type 0 and to ensure that firewall 6840 administrators want to allow the type of Routing Header that 6841 Mobile IPv6 uses through. 6843 - Requirements for all IPv6 routers have also been updated in order 6844 to describe the considerations relating to the new Routing Header 6845 type. 6847 - Processing rules for mobile nodes, correspondent nodes, and to 6848 some extent home agents have been substantially modified in order 6849 to explain the new authorization scheme. 6851 - Piggybacking is no longer possible due to the use of a new IPv6 6852 protocol and not a Destination Option. (However, a separate 6853 extension to this specification will allow piggybacking and takes 6854 in account the necessary IPsec policy considerations to avoid 6855 problems.) 6857 - The security considerations in Section 14 have been revised to 6858 describe the threats that this specification protects against as 6859 well as any residual threats. 6861 A.2. Changes from Previous Versions of the Draft 6863 - Strengthened mandates for mobile nodes so that now a mobile node 6864 MUST support decapsulation and processing for routing headers 6865 (section 10.3). 6867 - Enabled ESP to be a valid way to secure reverse tunneled packets 6868 (section 9.5). 6870 - Removed mandate that mobile node select a default router, 6871 and instead described it as typical behavior (section 10.4). 6872 Also made it clear that picking a new default router does not 6873 automatically mean picking a new primary care-of address. 6875 - Modified mandated behavior from Home Agent upon reception of a 6876 `D' bit in a Binding Update. The home agent only has to make 6877 sure that DAD has been run, and that no other node on the home 6878 network could be using the mobile node's link-local address. 6880 - Added provisional ICMP numbers for the new message types, which 6881 may be reassigned by IANA, but which will be useful for testing 6882 purposes. 6884 - Removed the Mobile Router Prefix Length Sub-Option 6886 - Removed the Prefix Length field from the Binding Update, and 6887 references to error number 136. 6889 - Added the `S' bit so that the home agent can be instructed to 6890 *override* its default behavior. That is, with the `S' bit 6891 set, the home agent will not attempt to be helpful by changing 6892 multiple Binding Cache entries, for multiple routing prefixes, 6893 after receiving only one Binding Update. 6895 - Reworded the specification so that the Home Agent now has to 6896 perform Duplicate Address Detection for the mobile node's address 6897 on all the prefixes for which the router is performing home agent 6898 service. 6900 - Removed the section about Mobile Routers 6902 - Added the Authentication Data Sub-option; reorganized the section 6903 about computing authentication data. 6905 - Specified that the Home Agent lifetime is by default the same as 6906 the Router lifetime, in a Router Advertisement. 6908 - Specified that Binding Updates with zero lifetime and the 'A' bit 6909 set should cause a Binding Acknowledgement to be sent back to the 6910 Source IP address of the Binding Update. 6912 - Qualified the allowable times when a mobile node can send a 6913 Binding Update to a correspondent node 6915 - Added text allowing the correspondent node to extend an existing 6916 Routing Header by also including the care-of address as the entry 6917 of a routing header to be visited immediately before the home 6918 address. In this way, for instance, the mobile node can be an 6919 intermediate node of a path along the way to some other node. 6921 - Removed the Home Address field from the Home Agent Address 6922 Discovery Request Message. 6924 - Noted that ICMP Unreachable forms a potential mechanism by which 6925 a malicious node can cause a correspondent node to delete a valid 6926 entry from its Binding Cache. 6928 - Specified that, when a router stops offering home agent services 6929 by turning off the 'H' flag, the mobile node has to delete the 6930 corresponding entry from its Home Agent list. 6932 - Clarified language about how the aggregate list of prefixes is 6933 built by the home agent, to include only prefixes with the 'H' 6934 bit set. 6936 - Specified a new error status (141) to handle cases for sequence 6937 number mismatches (e.g., when a mobile node reboots). 6939 - Moved this section to the appendix, and reorganized other 6940 appendix sections. 6942 - Reorganized some related sections to be adjacent to each other. 6944 - Changed the Prefix Length of the Binding Update to be 7-bit only, 6945 in order to reserve more flag bits for the future. 6947 - Changed the Sequence Number of the Binding Update and Binding 6948 Acknowledgement to be 8-bit only. 6950 - Inserted specification that, after returning home and sending a 6951 Neighbor Solicitation to the home agent, a mobile node should 6952 accept any Neighbor Advertisement from the home agent as an 6953 indication that the home agent is REACHABLE. 6955 - Inserted new terminology for Binding Key and Binding Security 6956 Association (BSA) in anticipation of eliminating the use of AH 6958 - Eliminated use of AH for authenticating Binding Update, and for 6959 authenticating Binding Acknowledgement 6961 - Specified that all correspondent nodes MUST implement a base 6962 protocol for establishing a Binding Key; this has become the 6963 Return Routability protocol in this document. 6965 - Added the following protocol constants: 6967 INITIAL_SOLICIT_TIMER: 6969 - Created new ICMP messages for Mobile Prefix Solicitations and 6970 Advertisements (see sections 5.8 and 5.9). 6972 - Changed Network Renumbering (Section 9.7) to encompass mobile 6973 node configuration issues, remove unspecified address usage, 6974 simplify rules for prefix maintenance and sending, and use new 6975 ICMP message types noted above. 6977 - Added a paragraph to Returning Home (section 10.22) to describe 6978 how the Home Agent discovers the mobile node's link-layer address 6980 - Reworded parts of appendix B as needed. 6982 - Added the Mobile Router Prefix Length Sub-Option (section 5.5), 6983 along with text describing what a Mobile Router should do with 6984 it. 6986 B. Remote Home Address Configuration 6988 The method for initializing a mobile node's home addresses on 6989 power-up or after an extended period of being disconnected from 6990 the network is beyond the scope of this specification. Whatever 6991 procedure is used should result in the mobile node having the same 6992 stateless or stateful (e.g., DHCPv6) home address autoconfiguration 6993 information it would have if it were attached to the home network. 6994 Due to the possibility that the home network could be renumbered 6995 while the mobile node is disconnected, a robust mobile node would not 6996 rely solely on storing these addresses locally. 6998 Such a mobile node could initialize by using the following procedure: 7000 1. Generate a care-of address using stateless or stateful 7001 autoconfiguration. 7003 2. Query DNS for the home network's mobile agent anycast address. 7005 3. Send a Home Agent Address Discovery Request message to the home 7006 network. 7008 4. Receive Home Agent Address Discovery Reply message. 7010 5. Select the most preferred home agent and establish a security 7011 association between the mobile node's current care-of address and 7012 the home agent for temporary use during initialization only. 7014 6. Send a Home Prefix Solicitation message with the Request All 7015 Prefixes flag set to the home agent from the mobile node's 7016 care-of address. 7018 7. Receive a Home Prefix Advertisement message from the home agent, 7019 follow stateless address autoconfiguration rules to configure 7020 home addresses for prefixes received. 7022 8. Create a security association between the mobile node's home 7023 address and the home agent. 7025 9. Send a binding update(s) to the home agent to register the mobile 7026 node's home addresses. 7028 10. Receive binding acknowledgement(s) then begin normal 7029 communications. 7031 Chairs' Addresses 7033 The Working Group can be contacted via its current chairs: 7035 Basavaraj Patil Phil Roberts 7036 Nokia Corporation Megisto Corp. 7037 6000 Connection Drive Suite 120 7038 M/S M8-540 20251 Century Blvd 7039 Irving, TX 75039 Germantown MD 20874 7040 USA USA 7041 Phone: +1 972-894-6709 Phone: +1 847-202-9314 7042 Fax : +1 972-894-5349 Email: PRoberts@MEGISTO.com 7043 EMail: Raj.Patil@nokia.com 7045 Authors' Addresses 7047 QuestionsDaboutathisvdocumenticandalsoBbe.directedJtoothehauthors:nson 7049 Rice University Charles Perkins 7050 Department of Computer Science, Nokia 7051 MS 132 313 Fairchild Drive 7052 6100 Main Street Mountain View, CA 94043 7053 Houston, TX 77005-1892 USA 7054 USA Phone: +1 650 625-2986 7056 Phone: +1 713 348-3063 Fax: +1 650 625-2502 7057 Fax: +1 713 348-5930 E-mail: charliep@iprg.nokia.com 7058 E-mail: dbj@cs.rice.edu