idnits 2.17.1 draft-ietf-mobileip-ipv6-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 785: '... the site. The mobile node SHOULD use...' RFC 2119 keyword, line 787: '...afe to do so. Thus, a mobile node MAY...' RFC 2119 keyword, line 794: '... it SHOULD be selected for use with ...' RFC 2119 keyword, line 800: '...son, home agents SHOULD NOT be multi-s...' RFC 2119 keyword, line 802: '... addresses SHOULD NOT be multi-sited...' (641 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - The Binding Authorization Data mobility option, if present, MUST be the last option and MUST not have trailing padding. -- 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 (29 Oct 2002) is 7849 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) ** Obsolete normative reference: RFC 1750 (ref. '1') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '5') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '6') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '8') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '9') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (ref. '11') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '12') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '13') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '14') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (ref. '17') (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '18') -- Possible downref: Non-RFC (?) normative reference: ref. '19' ** Obsolete normative reference: RFC 2002 (ref. '20') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2267 (ref. '23') (Obsoleted by RFC 2827) -- Possible downref: Non-RFC (?) normative reference: ref. '24' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '25') ** Obsolete normative reference: RFC 1883 (ref. '26') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '32' -- Possible downref: Non-RFC (?) normative reference: ref. '33' -- Possible downref: Non-RFC (?) normative reference: ref. '34' -- Possible downref: Non-RFC (?) normative reference: ref. '35' Summary: 24 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 E. Perkins 4 Nokia Research Center 5 Jari Arkko 6 Ericsson 7 29 Oct 2002 9 Mobility Support in IPv6 10 12 Status of This Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note 19 that other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents, valid for a maximum of six 23 months, and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document specifies the operation of the IPv6 Internet with 34 mobile computers. Each mobile node is always identified by its 35 home address, regardless of its current point of attachment to the 36 Internet. While situated away from its home, a mobile node is also 37 associated with a care-of address, which provides information about 38 the mobile node's current location. IPv6 packets addressed to a 39 mobile node's home address are transparently routed to its care-of 40 address. The protocol enables IPv6 nodes to cache the binding of 41 a mobile node's home address with its care-of address, and to then 42 send any packets destined for the mobile node directly to it at this 43 care-of address. To support this operation, Mobile IPv6 defines a 44 new IPv6 protocol and a new destination option. All IPv6 nodes, 45 whether mobile or stationary can communicate with mobile nodes. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Comparison with Mobile IP for IPv4 2 57 3. Terminology 3 58 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 5 61 4. Overview of Mobile IPv6 7 62 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 9 64 4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 10 65 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 10 66 4.5. Conceptual Data Structure Terminology . . . . . . . . . . 11 67 4.6. Site-Local Addressability . . . . . . . . . . . . . . . . 11 69 5. Overview of Mobile IPv6 Security 12 70 5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 12 71 5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 13 72 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . 13 73 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . 13 74 5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . 14 75 5.2.4. Cryptographic Functions . . . . . . . . . . . . . 15 76 5.2.5. Return Routability Procedure . . . . . . . . . . 15 77 5.2.6. Authorizing Binding Management Messages . . . . . 19 78 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . 20 79 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . 22 80 5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 22 81 5.4. Prefix Discovery . . . . . . . . . . . . . . . . . . . . 22 82 5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 22 84 6. New IPv6 Protocol, Message Types, and Destination Option 23 85 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 23 86 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 23 87 6.1.2. Binding Refresh Request Message . . . . . . . . . 25 88 6.1.3. Home Test Init Message . . . . . . . . . . . . . 26 89 6.1.4. Care-of Test Init Message . . . . . . . . . . . . 27 90 6.1.5. Home Test Message . . . . . . . . . . . . . . . . 28 91 6.1.6. Care-of Test Message . . . . . . . . . . . . . . 29 92 6.1.7. Binding Update Message . . . . . . . . . . . . . 31 93 6.1.8. Binding Acknowledgement Message . . . . . . . . . 33 94 6.1.9. Binding Error Message . . . . . . . . . . . . . . 35 96 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 36 97 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 37 98 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 37 99 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 38 100 6.2.4. Alternate Care-of Address . . . . . . . . . . . . 38 101 6.2.5. Nonce Indices . . . . . . . . . . . . . . . . . . 39 102 6.2.6. Binding Authorization Data . . . . . . . . . . . 39 103 6.2.7. Binding Refresh Advice . . . . . . . . . . . . . 40 104 6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 41 105 6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 43 106 6.4.1. Format . . . . . . . . . . . . . . . . . . . . . 43 107 6.5. ICMP Home Agent Address Discovery Request Message . . . . 44 108 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 46 109 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 47 110 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 49 112 7. Modifications to IPv6 Neighbor Discovery 51 113 7.1. Modified Router Advertisement Message Format . . . . . . 51 114 7.2. Modified Prefix Information Option Format . . . . . . . . 52 115 7.3. New Advertisement Interval Option Format . . . . . . . . 54 116 7.4. New Home Agent Information Option Format . . . . . . . . 55 117 7.5. Changes to Sending Router Advertisements . . . . . . . . 57 118 7.6. Changes to Sending Router Solicitations . . . . . . . . . 59 119 7.7. Changes to Duplicate Address Detection . . . . . . . . . 60 121 8. Requirements for Types of IPv6 Nodes 60 122 8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 61 123 8.2. IPv6 Nodes with Support for Route Optimization . . . . . 61 124 8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 62 125 8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 62 126 8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 63 128 9. Correspondent Node Operation 65 129 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 65 130 9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 66 131 9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 66 132 9.3.1. Receiving Packets with Home Address Destination 133 Option . . . . . . . . . . . . . . . . . . 66 134 9.3.2. Sending Packets to a Mobile Node . . . . . . . . 67 135 9.3.3. Sending Binding Error Messages . . . . . . . . . 68 136 9.3.4. Receiving ICMP Error Messages . . . . . . . . . . 69 137 9.4. Return Routability Procedure . . . . . . . . . . . . . . 69 138 9.4.1. Receiving Home Test Init Messages . . . . . . . . 69 139 9.4.2. Receiving Care-of Test Init Messages . . . . . . 70 140 9.4.3. Sending Home Test Messages . . . . . . . . . . . 70 141 9.4.4. Sending Care-of Test Messages . . . . . . . . . . 70 142 9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 70 143 9.5.1. Receiving Binding Updates . . . . . . . . . . . . 71 144 9.5.2. Requests to Cache a Binding . . . . . . . . . . . 73 145 9.5.3. Requests to Delete a Binding . . . . . . . . . . 74 146 9.5.4. Sending Binding Acknowledgements . . . . . . . . 74 147 9.5.5. Sending Binding Refresh Requests . . . . . . . . 75 148 9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 75 150 10. Home Agent Operation 76 151 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 76 152 10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 77 153 10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 77 154 10.3.1. Primary Care-of Address Registration . . . . . . 77 155 10.3.2. Primary Care-of Address De-Registration . . . . . 81 156 10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 82 157 10.4.1. Intercepting Packets for a Mobile Node . . . . . 82 158 10.4.2. Tunneling Intercepted Packets to a Mobile Node . 83 159 10.4.3. Handling Reverse Tunneled Packets from a Mobile 160 Node . . . . . . . . . . . . . . . . . . . 85 161 10.4.4. Protecting Return Routability Packets . . . . . . 85 162 10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 86 163 10.5.1. Receiving Router Advertisement Messages . . . . . 86 164 10.6. Sending Prefix Information to the Mobile Node . . . . . . 89 165 10.6.1. Aggregate List of Home Network Prefixes . . . . . 89 166 10.6.2. Scheduling Prefix Deliveries to the Mobile Node . 90 167 10.6.3. Sending Advertisements to the Mobile Node . . . . 92 168 10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . 92 170 11. Mobile Node Operation 93 171 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 93 172 11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 94 173 11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 95 174 11.3.1. Sending Packets While Away from Home . . . . . . 95 175 11.3.2. Interaction with Outbound IPsec Processing . . . 97 176 11.3.3. Receiving Packets While Away from Home . . . . . 99 177 11.3.4. Receiving ICMP Error Messages . . . . . . . . . . 100 178 11.3.5. Routing Multicast Packets . . . . . . . . . . . . 101 179 11.4. Home Agent and Prefix Management . . . . . . . . . . . . 102 180 11.4.1. Dynamic Home Agent Address Discovery . . . . . . 102 181 11.4.2. Sending Mobile Prefix Solicitations . . . . . . . 103 182 11.4.3. Receiving Mobile Prefix Advertisements . . . . . 104 183 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 105 184 11.5.1. Movement Detection . . . . . . . . . . . . . . . 105 185 11.5.2. Forming New Care-of Addresses . . . . . . . . . . 107 186 11.5.3. Using Multiple Care-of Addresses . . . . . . . . 109 187 11.5.4. Returning Home . . . . . . . . . . . . . . . . . 109 188 11.6. Return Routability Procedure . . . . . . . . . . . . . . 111 189 11.6.1. Sending Home and Care-of Test Init Messages . . . 111 190 11.6.2. Receiving Return Routability Messages . . . . . . 112 191 11.6.3. Protecting Return Routability Packets . . . . . . 113 192 11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 114 193 11.7.1. Sending Binding Updates to the Home Agent . . . . 114 194 11.7.2. Correspondent Binding Procedure . . . . . . . . . 116 195 11.7.3. Receiving Binding Acknowledgements . . . . . . . 119 196 11.7.4. Receiving Binding Refresh Requests . . . . . . . 121 197 11.7.5. Receiving Binding Error Messages . . . . . . . . 121 199 11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 122 201 12. Protocol Constants 123 203 13. IANA Considerations 124 205 14. Security Considerations 125 206 14.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 125 207 14.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 127 208 14.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 128 209 14.4. Binding Updates to Correspondent Nodes . . . . . . . . . 130 210 14.4.1. Overview . . . . . . . . . . . . . . . . . . . . 130 211 14.4.2. Offered Protection . . . . . . . . . . . . . . . 131 212 14.4.3. Comparison to Regular IPv6 Communications . . . . 131 213 14.4.4. Return Routability Replays . . . . . . . . . . . 133 214 14.4.5. Return Routability Denial-of-Service . . . . . . 133 215 14.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 134 216 14.6. Prefix Discovery . . . . . . . . . . . . . . . . . . . . 135 217 14.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 135 218 14.8. Home Address Option . . . . . . . . . . . . . . . . . . . 135 219 14.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 136 221 Contributors 137 223 Acknowledgements 137 225 References 139 227 A. Changes from Previous Version of the Draft 142 228 A.1. Changes from Draft Version 18 . . . . . . . . . . . . . . 142 230 B. Future Extensions 146 231 B.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 146 232 B.2. Triangular Routing and Unverified Home Addresses . . . . 146 233 B.3. New Authorization Methods beyond Return Routability . . . 146 234 B.4. Security and Dynamically Generated Home Addresses . . . . 147 235 B.5. Remote Home Address Configuration . . . . . . . . . . . . 147 237 Chairs' Addresses 149 239 Authors' Addresses 149 240 1. Introduction 242 This document specifies how the IPv6 Internet operates with mobile 243 computers. Without specific support for mobility in IPv6 [11], 244 packets destined to a mobile node would not be able to reach it while 245 the mobile node is away from its home link. In order to continue 246 communication in spite of its movement, a mobile node could change 247 its IP address each time it moves to a new link, but the mobile 248 node would then not be able to maintain transport and higher-layer 249 connections when it changes location. Mobility support in IPv6 is 250 particularly important, as mobile computers are likely to account for 251 a majority or at least a substantial fraction of the population of 252 the Internet during the lifetime of IPv6. 254 The protocol defined in this document, known as Mobile IPv6, allows 255 a mobile node to move from one link to another without changing the 256 mobile node's "home address". Packets may be routed to the mobile 257 node using this address regardless of the mobile node's current point 258 of attachment to the Internet. The mobile node may also continue 259 to communicate with other nodes (stationary or mobile) after moving 260 to a new link. The movement of a mobile node away from its home 261 link is thus transparent to transport and higher-layer protocols and 262 applications. 264 The Mobile IPv6 protocol is just as suitable for mobility across 265 homogeneous media as for mobility across heterogeneous media. For 266 example, Mobile IPv6 facilitates node movement from one Ethernet 267 segment to another as well as it facilitates node movement from an 268 Ethernet segment to a wireless LAN cell, with the mobile node's IP 269 address remaining unchanged in spite of such movement. 271 One can think of the Mobile IPv6 protocol as solving the 272 network-layer mobility management problem. Some mobility management 273 applications -- for example, handover among wireless transceivers, 274 each of which covers only a very small geographic area -- have been 275 solved using link-layer techniques. For example, in many current 276 wireless LAN products, link-layer mobility mechanisms allow a 277 "handover" of a mobile node from one cell to another, re-establishing 278 link-layer connectivity to the node in each new location. 280 Mobile IPv6 does not attempt to solve all general problems related 281 to the use of mobile computers or wireless networks. In particular, 282 this protocol does not attempt to solve: 284 - Handling links with partial reachability, or unidirectional 285 connectivity, such as are often found in wireless networks (but 286 see Section 11.5.1). 288 - Access control on a link being visited by a mobile node. 290 - Local or hierarchical forms of mobility management (similar to 291 many current link-layer mobility management solutions). 293 - Assistance for adaptive applications 295 - Mobile routers 297 - Service Discovery 299 - Distinguishing between packets lost due to bit errors vs. 300 network congestion 302 2. Comparison with Mobile IP for IPv4 304 The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both 305 from the experiences gained from the development of Mobile IP support 306 in IPv4 (Mobile IPv4) [20, 21, 22], and from the opportunities 307 provided by IPv6. Mobile IPv6 thus shares many features with 308 Mobile IPv4, but is integrated into IPv6 and offers many other 309 improvements. This section summarizes the major differences between 310 Mobile IPv4 and Mobile IPv6: 312 - There is no need to deploy special routers as "foreign agents", 313 as in Mobile IPv4. Mobile IPv6 operates in any location without 314 any special support required from the local router. 316 - Support for route optimization is a fundamental part of the 317 protocol, rather than a nonstandard set of extensions. 319 - Mobile IPv6 route optimization can operate securely even without 320 pre-arranged security associations. It is expected that route 321 optimization can be deployed on a global scale between all mobile 322 nodes and correspondent nodes. 324 - Support is also integrated into Mobile IPv6 for allowing route 325 optimization to coexist efficiently with routers that perform 326 "ingress filtering" [23]. 328 - In Mobile IPv6, the mobile node does not have to tunnel multicast 329 packets to its home agent. 331 - The movement detection mechanism in Mobile IPv6 provides 332 bidirectional confirmation of a mobile node's ability to 333 communicate with its default router in its current location. 335 - Most packets sent to a mobile node while away from home in 336 Mobile IPv6 are sent using an IPv6 routing header rather than IP 337 encapsulation, reducing the amount of resulting overhead compared 338 to Mobile IPv4. 340 - Mobile IPv6 is decoupled from any particular link layer, as it 341 uses IPv6 Neighbor Discovery [12] instead of ARP. This also 342 improves the robustness of the protocol. 344 - The use of IPv6 encapsulation (and the routing header) removes 345 the need in Mobile IPv6 to manage "tunnel soft state". 347 - The dynamic home agent address discovery mechanism in Mobile IPv6 348 returns a single reply to the mobile node. The directed 349 broadcast approach used in IPv4 returns separate replies from 350 each home agent. 352 3. Terminology 354 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 355 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 356 document are to be interpreted as described in RFC 2119 [2]. 358 3.1. General Terms 360 IP Internet Protocol Version 6 (IPv6). 362 node A device that implements IP. 364 router A node that forwards IP packets not explicitly 365 addressed to itself. 367 unicast routable address 368 An identifier for a single interface such that 369 a packet sent to it from another IPv6 subnet is 370 delivered to the interface identified by that 371 address. Accordingly, a unicast routable address must 372 have either a global or site-local scope (but not 373 link-local). 375 host Any node that is not a router. 377 link A communication facility or medium over which nodes 378 can communicate at the link layer, such as an Ethernet 379 (simple or bridged). A link is the layer immediately 380 below IP. 382 interface A node's attachment to a link. 384 subnet prefix 385 A bit string that consists of some number of initial 386 bits of an IP address. 388 interface identifier 389 A number used to identify a node's interface on a 390 link. The interface identifier is the remaining 391 low-order bits in the node's IP address after the 392 subnet prefix. 394 link-layer address 395 A link-layer identifier for an interface, such as 396 IEEE 802 addresses on Ethernet links. 398 packet An IP header plus payload. 400 security association 401 A security object shared between two nodes which 402 includes the data mutually agreed on for operation of 403 some cryptographic algorithm (typically including a 404 key). 406 security policy database 407 A database of rules that describe what security 408 associations should be applied for different kinds of 409 packets. 411 destination option 412 Destination options are carried by the IPv6 413 Destination Options extension header. Destination 414 options include optional information that need 415 be examined only by the IPv6 node given as the 416 destination address in the IPv6 header, not by other 417 intermediate routing nodes. Mobile IPv6 defines one 418 new destination option, the Home Address destination 419 option (see Section 6.3). 421 routing header 422 A routing header may be present as an IPv6 header 423 extension, and indicates that the payload has to be 424 delivered to a destination IPv6 address in some way 425 that is different from what would be carried out by 426 standard Internet routing. In this document, use of 427 the term "routing header" typically refers to use of a 428 type 2 routing header, as specified in Section 6.4. 430 '|' (concatenation) 431 Some formulas in this specification use the symbol '|' 432 indicate bytewise concatenation, as in A | B. This 433 concatenation requires that all of the bytes of the 434 datum A appear first in the result, followed by all of 435 the bytes of the datum B. 437 First (size, input) 438 Some formulas in this specification use a functional 439 form "First (size, input)" to indicate truncation of 440 the "input" data so that only the first "size" bits 441 remain to be used. 443 3.2. Mobile IPv6 Terms 445 home address 446 A unicast routable address assigned to a mobile node, 447 used as the permanent address of the mobile node. This 448 address is within the mobile node's home link. Standard 449 IP routing mechanisms will deliver packets destined for 450 a mobile node's home address to its home link. 452 home subnet prefix 453 The IP subnet prefix corresponding to a mobile node's 454 home address. 456 home link The link on which a mobile node's home subnet prefix is 457 defined. 459 mobile node 460 A node that can change its point of attachment from one 461 link to another, while still being reachable via its 462 home address. 464 movement A change in a mobile node's point of attachment to the 465 Internet such that it is no longer connected to the same 466 link as it was previously. If a mobile node is not 467 currently attached to its home link, the mobile node is 468 said to be "away from home". 470 correspondent node 471 A peer node with which a mobile node is communicating. 472 The correspondent node may be either mobile or 473 stationary. 475 foreign subnet prefix 476 Any IP subnet prefix other than the mobile node's home 477 subnet prefix. 479 foreign link 480 Any link other than the mobile node's home link. 482 care-of address 483 A unicast routable address associated with a mobile 484 node while visiting a foreign link; the subnet prefix 485 of this IP address is a foreign subnet prefix. Among 486 the multiple care-of addresses that a mobile node may 487 have at any given time (e.g., with different subnet 488 prefixes), the one registered with the mobile node's 489 home agent is called its "primary" care-of address. 491 home agent 492 A router on a mobile node's home link with which the 493 mobile node has registered its current care-of address. 494 While the mobile node is away from home, the home agent 495 intercepts packets on the home link destined to the 496 mobile node's home address, encapsulates them, and 497 tunnels them to the mobile node's registered care-of 498 address. 500 binding The association of the home address of a mobile node 501 with a care-of address for that mobile node, along with 502 the remaining lifetime of that association. 504 registration 505 The process during which a mobile node sends a Binding 506 Update to its home agent or a correspondent node, 507 causing a binding for the mobile node to be registered. 509 mobility message 510 A message containing a Mobility Header (see 511 Section 6.1). 513 binding procedure 514 A binding procedure is initiated by the mobile node to 515 inform either a correspondent node or the mobile node's 516 home agent of the current binding of the mobile node. 518 binding authorization 519 Binding procedure needs to be authorized to allow the 520 recipient to believe that the sender has the right to 521 specify a new binding. 523 return routability procedure 524 The return routability procedure authorizes binding 525 procedures by the use of a cryptographic token exchange. 527 correspondent binding procedure 528 A return routability procedure followed by a 529 binding procedure, run between the mobile node and a 530 correspondent node. 532 home binding procedure 533 A binding procedure between the mobile node and its home 534 agent, authorized by the use of IPsec. 536 nonce Nonces are random numbers used internally by the 537 correspondent node in the creation of keygen tokens 538 related to the return routability procedure. The nonces 539 are not specific to a mobile node, and are kept secret 540 within the correspondent node. 542 nonce index 543 A nonce index is used to indicate which nonces have 544 been used when creating keygen token values, without 545 revealing the nonces themselves. 547 cookie A cookie is a random number used by a mobile nodes to 548 prevent spoofing by a bogus correspondent node in the 549 return routability procedure. 551 care-of init cookie 552 A cookie sent to the correspondent node in the Care-of 553 Test Init message, to be returned in the Care-of Test 554 message. 556 home init cookie 557 A cookie sent to the correspondent node in the Home Test 558 Init message, to be returned in the Home Test message. 560 keygen token 561 A keygen token is a number supplied by a correspondent 562 node in the return routability procedure to enable the 563 mobile node to compute the necessary binding management 564 key for authorizing a Binding Update. 566 care-of keygen token 567 A keygen token sent by the correspondent node in the 568 Care-of Test message. 570 home keygen token 571 A keygen token sent by the correspondent node in the 572 Home Test message. 574 binding management key (Kbm) 575 A binding management key (Kbm) is a key used for 576 authorizing a binding cache management message (e.g., 577 Binding Update or Binding Acknowledgement). Return 578 routability provides a way to create a binding 579 management key. 581 4. Overview of Mobile IPv6 583 4.1. Basic Operation 585 A mobile node is always expected to be addressable at its home 586 address, whether it is currently attached to its home link or is 587 away from home. The "home address" is an IP address assigned to the 588 mobile node within its home subnet prefix on its home link. While 589 a mobile node is at home, packets addressed to its home address are 590 routed to the mobile node's home link, using conventional Internet 591 routing mechanisms. 593 While a mobile node is attached to some foreign link away from home, 594 it is also addressable at one or more care-of addresses. A care-of 595 address is an IP address associated with a mobile node that has the 596 subnet prefix of a particular foreign link. The mobile node can 597 acquire its care-of address through conventional IPv6 stateless or 598 stateful auto-configuration mechanisms. As long as the mobile node 599 stays in this location, packets addressed to this care-of address 600 will be routed to the mobile node. The mobile node may also accept 601 packets from several care-of addresses, such as when it is moving but 602 still reachable at the previous link. 604 The association between a mobile node's home address and care-of 605 address is known as a "binding" for the mobile node. While away 606 from home, a mobile node registers its primary care-of address with 607 a router on its home link, requesting this router to function as the 608 "home agent" for the mobile node. The mobile node performs this 609 binding registration by sending a "Binding Update" message to the 610 home agent. The home agent replies to the mobile node by returning a 611 "Binding Acknowledgement" message. The operation of the mobile node 612 and the home agent is specified in Sections 11 and 10, respectively. 614 Any node communicating with a mobile node is referred to in this 615 document as a "correspondent node" of the mobile node, and may itself 616 be either a stationary node or a mobile node. Mobile nodes can 617 provide information about their current location to correspondent 618 nodes. This happens through the correspondent binding procedure. As 619 a part of this procedure, a return routability test is performed in 620 order to authorize the establishment of the binding. The operation 621 of the correspondent node is specified in Section 9. 623 There are two possible modes for communications between the mobile 624 node and a correspondent node. The first mode, bidirectional 625 tunneling, does not require Mobile IPv6 support from the 626 correspondent node and is available even if the mobile node has not 627 registered its current binding with the correspondent node. Packets 628 from the correspondent node are routed to the home agent and then 629 tunneled to the mobile node. Packets to the correspondent node are 630 tunneled from the mobile node to the home agent ("reverse tunneled") 631 and then routed normally from the home network to the correspondent 632 node. In this mode, the home agent uses proxy Neighbor Discovery 633 to intercept any IPv6 packets addressed to the mobile node's home 634 address (or home addresses) on the home link. Each intercepted 635 packet is tunneled to the mobile node's primary care-of address. 636 This tunneling is performed using IPv6 encapsulation [15]. 638 The second mode, "route optimization", requires the mobile node to 639 register its current binding at the correspondent node. Packets 640 from the correspondent node can be routed directly to the care-of 641 address of the mobile node. When sending a packet to any IPv6 642 destination, the correspondent node checks its cached bindings for 643 an entry for the packet's destination address. If a cached binding 644 for this destination address is found, the node uses a new type of 645 IPv6 routing header [11] (see Section 6.4) to route the packet to the 646 mobile node by way of the care-of address indicated in this binding. 648 Routing packets directly to the mobile node's care-of address allows 649 the shortest communications path to be used. It also eliminates 650 congestion at the mobile node's home agent and home link. In 651 addition, the impact of any possible failure of the home agent or 652 networks on the path to or from it is reduced. 654 When routing packets directly to the mobile node, the correspondent 655 node sets the Destination Address in the IPv6 header to the care-of 656 address of the mobile node. A new type of IPv6 routing header (see 657 Section 6.4) is also added to the packet to carry the desired home 658 address. Similarly, the mobile node sets the Source Address in 659 the packet's IPv6 header to its current care-of addresses. The 660 mobile node adds a new IPv6 "Home Address" destination option (see 661 Section 6.3) to carry its home address. The inclusion of home 662 addresses in these packets makes the use of the care-of address 663 transparent above the network layer (e.g., at the transport layer). 665 Mobile IPv6 also provides support for multiple home agents, and the 666 reconfiguration of the home network. In these cases, the mobile 667 node may not know the IP address of its own home agent, and even 668 the home subnet prefixes may change over time. A mechanism, known 669 as "dynamic home agent address discovery" allows a mobile node to 670 dynamically discover the IP address of a home agent on its home link, 671 even when the mobile node is away from home. Mobile nodes can also 672 learn new information about home subnet prefixes through the "prefix 673 discovery" mechanism. These mechanisms are described in Sections 6.5 674 through 6.8. 676 4.2. New IPv6 Protocol 678 Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header 679 (see Section 6.1). This Header is used to carry the following 680 messages: 682 Home Test Init 683 Home Test 684 Care-of Test Init 685 Care-of Test 686 These four messages are used to initiate the return 687 routability procedure from the mobile node to a 688 correspondent node. This ensures authorization of 689 subsequent Binding Updates, as described in Section 5.2.5. 691 The format of the messages are defined in Sections 6.1.3 692 through 6.1.6. 694 Binding Update 695 A Binding Update is used by a mobile node to notify a 696 correspondent node or the mobile node's home agent of its 697 current binding. The Binding Update sent to the mobile 698 node's home agent to register its primary care-of address is 699 marked as a "home registration". The Binding Update message 700 is described in detail in Section 6.1.7. 702 Binding Acknowledgement 703 A Binding Acknowledgement is used to acknowledge receipt of 704 a Binding Update, if an acknowledgement was requested in the 705 Binding Update. The Binding Acknowledgement is described in 706 detail in Section 6.1.8. 708 Binding Refresh Request 709 A Binding Refresh Request is used to request a mobile node 710 to re-establish its binding with the correspondent node. 711 This message is typically used when the cached binding 712 is in active use but the binding's lifetime is close to 713 expiration. The correspondent node may use, for instance, 714 recent traffic and open transport layer connections as an 715 indication of active use. The Binding Refresh Request is 716 described in detail in Section 6.1.2. 718 Binding Error 719 The Binding Error is used by the correspondent node 720 to signal an error related to mobility, such as an 721 inappropriate attempt to use the Home Address destination 722 option without an existing binding. This message is 723 described in detail in Section 6.1.9. 725 4.3. New IPv6 Destination Option 727 Mobile IPv6 defines a new IPv6 destination option, the Home 728 Address destination option. This option is described in detail in 729 Section 6.3. 731 4.4. New IPv6 ICMP Messages 733 Mobile IPv6 also introduces four new ICMP message types, two for use 734 in the dynamic home agent address discovery mechanism, and two for 735 renumbering and mobile configuration mechanisms. As described in 736 Sections 10.5 and 11.4.1, the following two new ICMP message types 737 are used for home agent address discovery: 739 - Home Agent Address Discovery Request, described in Section 6.5. 741 - Home Agent Address Discovery Reply, described in Section 6.6. 743 The next two message types are used for network renumbering 744 and address configuration on the mobile node, as described in 745 Section 10.6: 747 - Mobile Prefix Solicitation, described in Section 6.7. 749 - Mobile Prefix Advertisement, described in Section 6.8. 751 4.5. Conceptual Data Structure Terminology 753 This document describes the Mobile IPv6 protocol in terms of the 754 following conceptual data structures: 756 Binding Cache 758 A cache of bindings for other nodes. This cache is maintained 759 by home agents and correspondent nodes. The cache contains 760 both "correspondent registration" entries (see Section 9.1) and 761 "home registration" entries (see Section 10.1). 763 Binding Update List 765 This list is maintained by each mobile node. The list has an 766 item for every binding that the mobile node has or is trying 767 to establish with a specific other node. Both correspondent 768 and home registrations are included in this list. Entries from 769 the list are deleted as the Lifetime sent in the Binding Update 770 expires. See Section 11.1. 772 Home Agents List 774 Home agents need to know which other home agents are on the 775 same link. This information is stored in the Home Agents List, 776 as described in more detail in Section 10.1. The list is used 777 for informing mobile nodes during dynamic home agent address 778 discovery. 780 4.6. Site-Local Addressability 782 Mobile nodes are free to move from site to site, but the use of 783 site-local addresses must be carefully managed. When a mobile node 784 or home agent address is site-local, then packets that use those 785 address need to stay within the site. The mobile node SHOULD use 786 such addresses only when it somehow has a guarantee - for instance, 787 by configuration - that it is safe to do so. Thus, a mobile node MAY 788 use a site-local home address for roaming within a site, but not for 789 roaming to another site. This is true even though the mobile node 790 may be able to obtain a globally addressable care-of address at the 791 new site. 793 If a mobile node or home agent has a global IPv6 address available, 794 it SHOULD be selected for use with Mobile IP signaling, in order to 795 make the greatest chance for success in case the mobile node might 796 move to a different site. 798 Operations affecting multi-sited IPv6 nodes are not completely 799 understood, especially when mobility management is involved. For 800 this reason, home agents SHOULD NOT be multi-sited. Similarly, 801 a mobile node that uses site-local home, care-of, or home agent 802 addresses SHOULD NOT be multi-sited. 804 5. Overview of Mobile IPv6 Security 806 This specification provides a number of security features. These 807 include the protection of Binding Updates both to home agents and 808 correspondent nodes, and the protection of tunnels, home address 809 information, and routing instructions in data packets. 811 Binding Updates are protected by the use of IPsec extension headers, 812 or by the use of the Binding Authorization Data option. This option 813 employs a binding management key, Kbm, which can be established 814 through the return routability procedure. 816 5.1. Binding Updates to Home Agents 818 The mobile node and the home agent must have a security association 819 to protect this signaling. Authentication Header (AH) or 820 Encapsulating Security Payload (ESP) MUST be used. For ESP, a 821 non-null authentication algorithm MUST be applied. 823 In order to protect messages exchanged between the mobile node and 824 the home agent with IPsec, appropriate security policy database 825 entries must be created. A mobile node must be prevented from 826 using its security association to send a Binding Update on behalf 827 of another mobile node using the same home agent. This MUST be 828 achieved by checking that the given home address has been used with 829 the right security association. Such a check can be provided in 830 IPsec processing, by having the security policy database entries 831 unequivocally identify a single security association for any given 832 home address and home agent. The check may also be provided as 833 a part of Mobile IPv6 processing, if information about the used 834 security association is available in there. In any case, it is 835 necessary that the home address of the mobile node is visible in 836 the Binding Updates and Acknowledgements. The home address is used 837 in these packets as a source or destination, or in the Home Address 838 Destination option or the type 2 routing header. 840 As with all IPsec security associations in this specification, manual 841 configuration of security associations MUST be supported. Automatic 842 key management with IKE [9] MAY be supported. When dynamic keying 843 is used, either the security policy database entries or the MIPv6 844 processing MUST unequivocally identify the IKE phase 1 credentials 845 which can be used to create security associations for a particular 846 home address. 848 Reference [24] is an informative description and example of using 849 IPsec to protect the communications between the mobile node and the 850 home agent. 852 5.2. Binding Updates to Correspondent Nodes 854 Binding Updates to correspondent nodes can be protected by using 855 a binding management key, Kbm. Kbm may be established using data 856 exchanged during the return routability procedure. The data exchange 857 is accomplished by use of node keys, nonces, cookies, tokens, and 858 certain cryptographic functions. Section 5.2.5 outlines the basic 859 return routability procedure. Section 5.2.6 shows how the results 860 of this procedure are used to authorize a Binding Update to a 861 correspondent node. Finally, Sections 5.2.7 and 5.2.8 discuss some 862 additional issues. 864 5.2.1. Node Keys 866 Each correspondent node has a secret key, Kcn, called the "node key", 867 which it uses to produce the keygen tokens sent to the mobile nodes. 868 The node key MUST be a random number, 20 octets in length. The node 869 key allows the correspondent node to verify that the keygen tokens 870 used by the mobile node in authorizing a Binding Update are indeed 871 its own. This key MUST NOT be shared with any other entity. 873 A correspondent node MAY generate a fresh node key at any time; 874 this avoid the need for secure persistent key storage. Procedures 875 for optionally updating the node key are discussed later in 876 Section 5.2.7. 878 5.2.2. Nonces 880 Each correspondent node also generates nonces at regular 881 intervals. The nonces should be generated by using a random number 882 generator that is known to have good randomness properties [1]. 883 A correspondent node may use the same Kcn and nonce with all the 884 mobiles it is in communication with. 886 Each nonce is identified by a nonce index. When a new nonce is 887 generated, it must be associated with a new nonce index; this may be 888 done, for example, by incrementing the value of the previous nonce 889 index, if the nonce index is used as an array pointer into a linear 890 array of nonces. However, there is no requirement that nonces be 891 stored that way, or that the values of subsequent nonce indices 892 have any particular relationship to each other. The index value 893 is communicated in the protocol, so that if a nonce is replaced by 894 new nonce during the run of a protocol, the correspondent node can 895 distinguish messages that should be checked against the old nonce 896 from messages that should be checked against the new nonce. Strictly 897 speaking, indices are not necessary in the authentication, but allow 898 the correspondent node to efficiently find the nonce value that it 899 used in creating a keygen token. 901 Correspondent nodes keep both the current nonce and a small set of 902 valid previous nonces whose lifetime has not yet expired. Expired 903 values MUST be discarded, and messages using stale or unknown indices 904 will be rejected. 906 The specific nonce index values cannot be used by mobile nodes to 907 determine the validity of the nonce. Expected validity times for 908 the nonces values and the procedures for updating them are discussed 909 later in Section 5.2.7. 911 A nonce is an octet string of any length. The recommended length is 912 64 bits. 914 5.2.3. Cookies and Tokens 916 The return routability address test procedure uses cookies and keygen 917 tokens as opaque values within the test init and test messages, 918 respectively. 920 - The "home init cookie" and "care-of init cookie" are 64 bit 921 values sent to the correspondent node from the mobile node, and 922 later returned to the mobile node. The home init cookie is sent 923 in the Home Test Init message, and returned in the Home Test 924 message. The care-of init cookie is sent in the Care-of Test 925 Init message, and returned in the Care-of Test message. 927 - The "home keygen token" and "care-of keygen token" are 64-bit 928 values sent by the correspondent node to the mobile node via the 929 home agent (via the Home Test message) and the care-of address 930 (by the Care-of Test message), respectively. 932 The mobile node should use a newly generated random number for each 933 request that carries a home init or care-of init cookie. The cookies 934 are used to verify that the Home Test or Care-of Test message matches 935 the Home Test Init or Care-of Test Init message, respectively. These 936 cookies also serve to ensure that parties who have not seen the 937 request cannot spoof responses. 939 Home and care-of keygen tokens are produced by the correspondent node 940 based on its currently active secret key (Kcn) and nonces, as well as 941 the home or care-of address (respectively). A keygen token is valid 942 as long as both the secret key (Kcn) and the nonce used to create it 943 are valid. 945 5.2.4. Cryptographic Functions 947 In this specification, the function used to compute hash values is 948 SHA1 [19]. Message Authentication Codes (MACs) are computed using 949 HMAC_SHA1 [25, 19]. HMAC_SHA1(K,m) denotes such a MAC computed on 950 message m with key K. 952 5.2.5. Return Routability Procedure 954 The Return Routability Procedure enables the correspondent node to 955 obtain some reasonable assurance that the mobile node is in fact 956 addressable at its claimed care-of address as well as at its home 957 address. Only with this assurance is the correspondent node able to 958 accept Binding Updates from the mobile node which would then instruct 959 the correspondent node to direct that mobile node's data traffic to 960 its claimed care-of address. 962 This is done by testing whether packets addressed to the two claimed 963 addresses are routed to the mobile node. The mobile node can pass 964 the test only if it is able to supply proof that it received certain 965 data (the "keygen tokens") which the correspondent node sends to 966 those addresses. These data are combined by the mobile node into a 967 binding management key, denoted Kbm. 969 Figure 1 shows the message flow for the return routability 970 procedures. 972 The Home and Care-of Test Init messages are sent at the same time. 973 The procedure requires very little processing at the correspondent 974 node, and the Home and Care-of Test messages can be returned quickly, 975 perhaps nearly simultaneously. These four messages form the return 976 routability procedure. 978 Home Test Init 980 A mobile node sends a Home Test Init message to the 981 correspondent node to acquire the home keygen token. The 982 contents of the message can be summarized as follows: 984 Source Address = home address 986 Mobile node Home agent Correspondent node 987 | | 988 | Home Test Init (HoTI) | | 989 |------------------------->|------------------------->| 990 | | | 991 | Care-of Test Init (CoTI) | 992 |---------------------------------------------------->| 993 | | 994 | | Home Test (HoT) | 995 |<-------------------------|<-------------------------| 996 | | | 997 | Care-of Test (CoT) | 998 |<----------------------------------------------------| 999 | | 1001 Figure 1: Message Flow for Return Routability Address Testing 1003 Destination Address = correspondent 1004 Parameters: 1005 - home init cookie 1007 The Home Test Init message conveys the mobile node's home 1008 address to the correspondent node. The mobile node also sends 1009 along a home init cookie that the correspondent node must 1010 return later. The Home Test Init message is reverse tunneled 1011 through the home agent. The mobile node remembers these cookie 1012 values to obtain some assurance that its protocol messages are 1013 being processed by the desired correspondent node. 1015 Care-of Test Init 1017 The mobile node sends a Care-of Test Init message to the 1018 correspondent node to acquire the care-of keygen token. The 1019 contents of this message can be summarized as follows: 1021 Source Address = care-of address 1022 Destination Address = correspondent 1023 Parameters: 1024 - care-of init cookie 1026 The Care-of Test Init message conveys the mobile node's care-of 1027 address to the correspondent node. The mobile node also sends 1028 along a care-of init cookie that the correspondent node must 1029 return later. The Care-of Test Init message is sent directly 1030 to the correspondent node. 1032 Home Test 1034 The Home Test message is sent in response to a Home Test Init 1035 message. The contents of the message are: 1037 Source Address = correspondent 1038 Destination Address = home address 1039 Parameters: 1040 - home init cookie 1041 - home keygen token 1042 - home nonce index 1044 When the correspondent node receives the Home Test Init 1045 message, it generates a home keygen token as follows: 1047 home keygen token := 1048 First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) 1050 where | denotes concatenation. The final "0" inside the 1051 HMAC_SHA1 function is a single zero octet, used to distinguish 1052 home and care-of cookies from each other. 1054 The home keygen token is formed from the first 64 bits of 1055 the MAC. The home keygen token tests that the mobile can 1056 receive messages sent to its home address. Kcn is used in 1057 the production of home keygen token in order to allow the 1058 correspondent node to verify that it generated the home and 1059 care-of nonces, without forcing the correspondent node to 1060 remember a list of all tokens it has handed out. 1062 The Home Test message is sent to the mobile node via the home 1063 network, where it is presumed that the home agent will tunnel 1064 the message to the mobile node. This means that the mobile 1065 node needs to already have sent a Binding Update to the home 1066 agent, so that the home agent will have received and authorized 1067 the new care-of address for the mobile node before the return 1068 routability procedure. For improved security, it is important 1069 that the data passed between the home agent and the mobile node 1070 be immune from inspection and passive attack. Such protection 1071 can be gained by encrypting the home keygen token as it is 1072 tunneled from the home agent to the mobile node. 1074 The home init cookie from the mobile node is returned in the 1075 Home Test message, to ensure that the message comes from a node 1076 on the route between the home agent and the correspondent node. 1078 The home nonce index is delivered to the mobile node to later 1079 allow the correspondent node to efficiently find the nonce 1080 value that it used in creating the home keygen token. 1082 Care-of Test 1084 This message is sent in response to a Care-of Test Init 1085 message. The contents of the message are: 1087 Source Address = correspondent 1088 Destination Address = care-of address 1089 Parameters: 1090 - care-of init cookie 1091 - care-of keygen token 1092 - care-of nonce index 1094 The correspondent node sends a challenge also to the mobile's 1095 care-of address. When the correspondent node receives the 1096 Care-of Test Init message, it generates a care-of keygen token 1097 as follows: 1099 care-of keygen token := 1100 First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1))) 1102 Here, the final "1" inside the HMAC_SHA1 function is a single 1103 octet containing the hex value 0x01, and is used to distinguish 1104 home and care-of cookies from each other. The keygen token is 1105 formed from the first 64 bits of the MAC, and sent directly 1106 to the mobile node at its care-of address. The care-of init 1107 cookie from the from Care-of Test Init message is returned to 1108 ensure that the message comes from a node on the route to the 1109 correspondent node. 1111 The care-of nonce index is provided to identify the nonce used 1112 for the care-of keygen token. The home and care-of nonce 1113 indices MAY be the same, or different, in the Home and Care-of 1114 Test messages. 1116 When the mobile node has received both the Home and Care-of Test 1117 messages, the return routability procedure is complete. As a result 1118 of the procedure, the mobile node has the data it needs to send a 1119 Binding Update to the correspondent node. The mobile node hashes the 1120 tokens together to form a 20 octet binding key Kbm: 1122 Kbm = SHA1 (home keygen token | care-of keygen token) 1124 A Binding Update may also be used to delete a previously established 1125 binding by setting the care-of address equal to the home address 1126 (Section 6.1.7). In this case, the care-of keygen token is not used. 1127 Instead, the binding management key is generated as follows: 1129 Kbm = SHA1(home keygen token) 1131 Note that the correspondent node does not create any state specific 1132 to the mobile node, until it receives the Binding Update from that 1133 mobile node. The correspondent node does not maintain the value for 1134 the binding management key Kbm; it creates Kbm when given the nonce 1135 indices and the mobile node's addresses. 1137 5.2.6. Authorizing Binding Management Messages 1139 After the mobile node has created the binding management key (Kbm), 1140 it can supply a verifiable Binding Update to the correspondent 1141 node. This section provides an overview of this binding procedure. 1142 Figure 2 shows the message flow. The Binding Update creates a 1143 binding, and the Binding Acknowledgement is optional. 1145 Mobile node Correspondent node 1146 | | 1147 | Binding Update (BU) | 1148 |---------------------------------------------->| 1149 | (MAC, seq#, nonce indices, care-of address) | 1150 | | 1151 | | 1152 | Binding Acknowledgement (BA) (if sent) | 1153 |<----------------------------------------------| 1154 | (MAC, seq#, status) | 1156 Figure 2: Message Flow for Establishing Binding at 1157 the Correspondent Node 1159 Binding Update 1161 To authorize a Binding Update, the mobile node creates a 1162 binding management key Kbm from the keygen tokens as described 1163 in the previous section. The contents of the Binding Update 1164 include the following: 1166 Source Address = care-of address 1167 Destination Address = correspondent 1168 Parameters: 1169 - home address (within the Home Address destination 1170 option or in the Source Address) 1171 - sequence number (within the Binding Update message 1172 header) 1173 - home nonce index (within the Nonce Indices option) 1174 - care-of nonce index (within the Nonce Indices option) 1175 - HMAC_SHA1 (Kbm, (care-of address | CN address | BU)) 1177 The Binding Update may contain a Nonce Indices option, 1178 indicating to the correspondent node which home and care-of 1179 nonces to use to recompute Kbm, the binding management key. 1181 The MAC is computed as described in Section 6.2.6, using the 1182 correspondent node's address as the destination address and the 1183 Binding Update message itself as the Mobility Header Data. 1185 Once the correspondent node has verified the MAC, it can create 1186 a Binding Cache entry for the mobile. 1188 Binding Acknowledgement 1190 The Binding Update is optionally acknowledged by the 1191 correspondent node. The contents of the message are as 1192 follows: 1194 Source Address = correspondent 1195 Destination Address = care-of address 1196 Parameters: 1197 - sequence number (within the Binding Update message 1198 header) 1199 - HMAC_SHA1 (Kbm, (care-of address | CN address | BA)) 1201 The Binding Acknowledgement contains the same sequence number 1202 as the Binding Update. The MAC is computed as described in 1203 Section 6.2.6, using the correspondent node's address as the 1204 destination address and the message itself as the Mobility 1205 Header Data. 1207 Bindings established with correspondent nodes using keys created 1208 by way of the return routability procedure MUST NOT exceed 1209 MAX_RR_BINDING_LIFE seconds (see Section 12). 1211 The value in the Source Address field in the IPv6 header carrying the 1212 Binding Update is normally also the care-of address which is used in 1213 the binding. However, a different care-of address MAY be specified 1214 by including an Alternate Care-of Address mobility option in the 1215 Binding Update (see Section 6.2.4). When such a message is sent to 1216 the correspondent node and the return routability procedure is used 1217 as the authorization method, the Care-of Test Init and Care-of Test 1218 messages MUST have been performed for the address in the Alternate 1219 Care-of Address option (not the Source Address). The nonce indices 1220 and MAC value MUST be based on information gained in this test. 1222 The care-of address may be set equal to the home address in order to 1223 delete a previously established binding In this case, generation of 1224 the binding management key depends exclusively on the home keygen 1225 token (Section 5.2.5). 1227 5.2.7. Updating Node Keys and Nonces 1229 Correspondent nodes generate nonces at regular intervals. It 1230 is recommended to keep each nonce (identified by a nonce index) 1231 acceptable for at least MAX_TOKEN_LIFE seconds (see Section 12) 1232 after it has been first used in constructing a return routability 1233 message response. However, the correspondent node MUST NOT accept 1234 nonces beyond MAX_NONCE_LIFE seconds (see Section 12) after the first 1235 use. As the difference between these two constants is 30 seconds, 1236 a convenient way to enforce the above lifetimes is to generate a 1237 new nonce every 30 seconds. The node can then continue to accept 1238 tokens that have been based on the last 8 (MAX_NONCE_LIFE / 30) 1239 nonces. This results in tokens being acceptable MAX_TOKEN_LIFE 1240 to MAX_NONCE_LIFE seconds after they have been sent to the mobile 1241 node, depending on whether the token was sent at the beginning or 1242 end of the first 30 second period. Note that the correspondent 1243 node may also attempt to generate new nonces on demand, or only if 1244 the old nonces have been used. This is possible, as long as the 1245 correspondent node keeps track of how long time ago the nonces were 1246 used for the first time, and does not generate new nonces on every 1247 return routability request. 1249 Due to resource limitations, rapid deletion of bindings, or reboots 1250 the correspondent node may not in all cases recognize the nonces 1251 that the tokens were based on. If a nonce index is unrecognized, 1252 the correspondent node replies with an an error code in the 1253 Binding Acknowledgement (either 136, 137, or 138 as discussed 1254 in Section 6.1.8). The mobile node can then retry the return 1255 routability procedure. 1257 An update of Kcn SHOULD be done at the same time as an update of a 1258 nonce, so that nonce indices can identify both the nonce and the key. 1259 Old Kcn values have to be therefore remembered as long as old nonce 1260 values. 1262 Given that the tokens are normally expected to be usable for 1263 MAX_TOKEN_LIFE seconds, the mobile node MAY use them beyond a single 1264 run of the return routability procedure until MAX_TOKEN_LIFE expires. 1265 After this the mobile node SHOULD NOT use the tokens. A fast moving 1266 mobile node may reuse a recent home keygen token from a correspondent 1267 node when moving to a new location, and just acquire a new care-of 1268 keygen token to show routability in the new location. 1270 While this does not save the number of round-trips due to the 1271 simultaneous processing of home and care-of return routability tests, 1272 there are fewer messages being exchanged, and a potentially long 1273 round-trip through the home agent is avoided. Consequently, this 1274 optimization is often useful. A mobile node that has multiple home 1275 addresses, may also use the same care-of keygen token for Binding 1276 Updates concerning all of these addresses. 1278 5.2.8. Preventing Replay Attacks 1280 The return routability procedure also protects the participants 1281 against replayed Binding Updates through the use of the sequence 1282 number and a MAC. Care must be taken when removing bindings at 1283 the correspondent node, however. Correspondent nodes must retain 1284 bindings and the associated sequence number information at least as 1285 long as the nonces used in the authorization of the binding are still 1286 valid. The correspondent node can, for instance, change the nonce 1287 often enough to ensure that the nonces used when removed entries 1288 were created are no longer valid. If many such deletions occur 1289 the correspondent node can batch them together to avoid having to 1290 increment the nonce index too often. 1292 5.3. Dynamic Home Agent Address Discovery 1294 No security is required for dynamic home agent address discovery. 1296 5.4. Prefix Discovery 1298 The mobile node and the home agent must have a security association 1299 to protect prefix discovery. IPsec AH or ESP SHOULD be supported and 1300 used for integrity protection. For ESP, a non-null authentication 1301 algorithm MUST be applied. 1303 5.5. Payload Packets 1305 Payload packets exchanged with mobile nodes can be protected in the 1306 usual manner, in the same way as stationary hosts can protect them. 1307 However, Mobile IPv6 introduces the Home Address destination option, 1308 a routing header, and tunneling headers in the payload packets. In 1309 the following we define the security measures taken to protect these, 1310 and to prevent their use in attacks against other parties. 1312 This specification limits the use of the Home Address destination 1313 option to the situation where the correspondent node already has a 1314 Binding Cache entry for the given home address. This avoids the use 1315 of the Home Address option in attacks described in Section 14.1. 1317 Mobile IPv6 uses a Mobile IPv6 specific type of a routing header. 1318 This type provides the necessary functionality but does not open 1319 vulnerabilities discussed in Section 14.1. 1321 Tunnels between the mobile node and the home agent are protected by 1322 ensuring proper use of source addresses, and optional cryptographic 1323 protection. The mobile node verifies that the outer IP address 1324 corresponds to its home agent. The home agent verifies that the 1325 outer IP address corresponds to the current location of the mobile 1326 node (Binding Updates sent to the home agents are secure). These 1327 measures protect the tunnels against vulnerabilities discussed in 1328 Section 14.1. 1330 For traffic tunneled via the home agent, additional IPsec AH or ESP 1331 encapsulation MAY be supported and used. 1333 6. New IPv6 Protocol, Message Types, and Destination Option 1335 6.1. Mobility Header 1337 The Mobility Header is an extension header used by mobile nodes, 1338 correspondent nodes, and home agents in all messaging related to 1339 the creation and management of bindings. The subsections within 1340 this section describe the message types that may be sent using the 1341 Mobility Header. 1343 6.1.1. Format 1345 The Mobility Header is identified by a Next Header value of TBD in the immediately preceding header, and has the 1347 following format: 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Payload Proto | Header Len | MH Type | Reserved | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Checksum | | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1354 | | 1355 . . 1356 . Message Data . 1357 . . 1358 | | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 Payload Proto 1363 8-bit selector. Identifies the type of header immediately 1364 following the Mobility Header. Uses the same values as the 1365 IPv6 Next Header field [11]. 1367 This field is intended to be used by a future specification 1368 of piggybacking binding messages on payload packets (see 1369 Section B.1). 1371 Implementations conforming to this specification SHOULD set the 1372 payload protocol type to IPPROTO_NONE (59 decimal). 1374 Header Len 1376 8-bit unsigned integer, representing the length of the Mobility 1377 Header in units of 8 octets, excluding the first 8 octets. 1379 The length of the Mobility Header MUST be a multiple of 8 1380 octets. 1382 MH Type 1384 8-bit selector. Identifies the particular mobility message 1385 in question. Current values are specified in Sections 6.1.2 1386 to 6.1.9. An unrecognized MH Type field causes an error 1387 indication to be sent. 1389 Reserved 1391 8-bit field reserved for future use. The value MUST be 1392 initialized to zero by the sender, and MUST be ignored by the 1393 receiver. 1395 Checksum 1397 16-bit unsigned integer. This field contains the checksum of 1398 the Mobility Header. The checksum is calculated from the octet 1399 string consisting of a "pseudo-header" followed by the entire 1400 Mobility Header starting with the Payload Proto field. The 1401 checksum is the 16-bit one's complement of the one's complement 1402 sum of this string. 1404 The pseudo-header contains IPv6 header fields, as specified 1405 in Section 8.1 of [11]. The Next Header value used in the 1406 pseudo-header is TBD . The addresses 1407 used in the pseudo-header are the addresses that appear in 1408 the Source and Destination Address fields in the IPv6 packet 1409 carrying the Mobility Header. 1411 Note that the procedures described in Section 11.3.1 apply 1412 even for the Mobility Header. If a mobility message has a 1413 Home Address destination option, then the checksum calculation 1414 uses the home address in this option as the value of the IPv6 1415 Source Address field. The type 2 routing header is treated as 1416 explained in [26]. 1418 The Mobility Header is considered as the upper layer protocol 1419 for the purposes of calculating the pseudo-header. The 1420 Upper-Layer Packet Length field in the pseudo-header MUST be 1421 set to the total length of the Mobility Header. 1423 For computing the checksum, the checksum field is set to zero. 1425 Message Data 1427 A variable length field containing the data specific to the 1428 indicated Mobility Header type. 1430 Mobile IPv6 also defines a number of "mobility options" for use 1431 within these messages; if included, any options MUST appear after the 1432 fixed portion of the message data specified in this document. The 1433 presence of such options will be indicated by the Header Len field 1434 within the message. When the Header Len value is greater than the 1435 length required for the message specified here, the remaining octets 1436 are interpreted as mobility options. These options include padding 1437 options that can be used to ensure that other options are aligned 1438 properly, and that the total length of the message is divisible 1439 by 8. The encoding and format of defined options are described in 1440 Section 6.2. 1442 Alignment requirements for the Mobility Header are the same as for 1443 any IPv6 protocol Header. That is, they MUST be aligned on an 1444 8-octet boundary. 1446 6.1.2. Binding Refresh Request Message 1448 The Binding Refresh Request (BRR) message is used to request a 1449 mobile node's binding from the mobile node. It is sent according to 1450 the rules in Section 9.5.5. When a mobile node receives a packet 1451 containing a Binding Refresh Request message it processes the message 1452 according to the rules in Section 11.7.4. 1454 The Binding Refresh Request message uses the MH Type value 0. When 1455 this value is indicated in the MH Type field, the format of the 1456 Message Data field in the Mobility Header is as follows: 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Reserved | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | | 1462 . . 1463 . Mobility options . 1464 . . 1465 | | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 Reserved 1470 16-bit field reserved for future use. The value MUST be 1471 initialized to zero by the sender, and MUST be ignored by the 1472 receiver. 1474 Mobility Options 1476 Variable-length field of such length that the complete Mobility 1477 Header is an integer multiple of 8 octets long. Contains one 1478 or more TLV-encoded mobility options. The encoding and format 1479 of defined options are described in Section 6.2. The receiver 1480 MUST ignore and skip any options which it does not understand. 1482 There MAY be additional information, associated with this 1483 Binding Refresh Request message, that need not be present in 1484 all Binding Refresh Request messages sent. Mobility options 1485 allow future extensions to the format of the Binding Refresh 1486 Request message to be defined. This specification does not 1487 define any options valid for the Binding Refresh Request 1488 message. 1490 If no actual options are present in this message, no padding is 1491 necessary and the Header Len field will be set to 0. 1493 6.1.3. Home Test Init Message 1495 A mobile node uses the Home Test Init (HoTI) message to initiate the 1496 return routability procedure and request a home keygen token from a 1497 correspondent node (see Section 11.6.1). The Home Test Init message 1498 uses the MH Type value 1. When this value is indicated in the MH 1499 Type field, the format of the Message Data field in the Mobility 1500 Header is as follows: 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Reserved | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | | 1506 + Home Init Cookie + 1507 | | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | | 1510 . . 1511 . Mobility Options . 1512 . . 1513 | | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 Reserved 1518 16-bit field reserved for future use. This value MUST be 1519 initialized to zero by the sender, and MUST be ignored by the 1520 receiver. 1522 Home Init Cookie 1524 64-bit field which contains a random value, the home init 1525 cookie. 1527 Mobility Options 1529 Variable-length field of such length that the complete Mobility 1530 Header is an integer multiple of 8 octets long. Contains 1531 one or more TLV-encoded mobility options. The receiver MUST 1532 ignore and skip any options which it does not understand. This 1533 specification does not define any options valid for the Home 1534 Test Init message. 1536 If no actual options are present in this message, no padding is 1537 necessary and the Header Len field will be set to 1. 1539 This message is tunneled through the home agent when the mobile node 1540 is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel 1541 mode between the home agent and the mobile node. This protection 1542 is indicated by the IPsec policy data base. The protection of Home 1543 Test Init messages is unrelated to the requirement to protect regular 1544 payload traffic, which MAY use such tunnels as well. 1546 6.1.4. Care-of Test Init Message 1548 A mobile node uses the Care-of Test Init (CoTI) message to initiate 1549 the return routability procedure and request a care-of keygen token 1550 from a correspondent node (see Section 11.6.1). The Care-of Test 1551 Init message uses the MH Type value 2. When this value is indicated 1552 in the MH Type field, the format of the Message Data field in the 1553 Mobility Header is as follows: 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Reserved | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | | 1559 + Care-of Init Cookie + 1560 | | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | | 1563 . . 1564 . Mobility Options . 1565 . . 1566 | | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 Reserved 1570 16-bit field reserved for future use. The value MUST be 1571 initialized to zero by the sender, and MUST be ignored by the 1572 receiver. 1574 Care-of Init Cookie 1576 64-bit field which contains a random value, the care-of init 1577 cookie. 1579 Mobility Options 1581 Variable-length field of such length that the complete Mobility 1582 Header is an integer multiple of 8 octets long. Contains 1583 one or more TLV-encoded mobility options. The receiver MUST 1584 ignore and skip any options which it does not understand. This 1585 specification does not define any options valid for the Care-of 1586 Test Init message. 1588 If no actual options are present in this message, no padding is 1589 necessary and the Header Len field will be set to 1. 1591 6.1.5. Home Test Message 1593 The Home Test (HoT) message is a response to the Home Test Init 1594 message, and is sent from the correspondent node to the mobile node 1595 (see Section 5.2.5). The Home Test message uses the MH Type value 3. 1596 When this value is indicated in the MH Type field, the format of the 1597 Message Data field in the Mobility Header is as follows: 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Home Nonce Index | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | | 1603 + Home Init Cookie + 1604 | | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | | 1607 + Home Keygen Nonce + 1608 | | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | | 1611 . . 1612 . Mobility options . 1613 . . 1614 | | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 Home Nonce Index 1618 This field will be echoed back by the mobile node to the 1619 correspondent node in a subsequent Binding Update. 1621 Home Init Cookie 1623 64-bit field which contains the home init cookie. 1625 Home Keygen Nonce 1627 This field contains the 64 bit home keygen token used in the 1628 return routability procedure. 1630 Mobility Options 1632 Variable-length field of such length that the complete Mobility 1633 Header is an integer multiple of 8 octets long. Contains 1634 one or more TLV-encoded mobility options. The receiver MUST 1635 ignore and skip any options which it does not understand. This 1636 specification does not define any options valid for the Home 1637 Test message. 1639 If no actual options are present in this message, no padding is 1640 necessary and the Header Len field will be set to 2. 1642 6.1.6. Care-of Test Message 1644 The Care-of Test (CoT) message is a response to the Care-of Test 1645 Init message, and is sent from the correspondent node to the mobile 1646 node (see Section 11.6.2). The Care-of Test message uses the MH 1647 Type value 4. When this value is indicated in the MH Type field, 1648 the format of the Message Data field in the Mobility Header is as 1649 follows: 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | Care-of Nonce Index | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | | 1655 + Care-of Init Cookie + 1656 | | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | | 1659 + Care-of Keygen Nonce + 1660 | | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | | 1663 . . 1664 . Mobility Options . 1665 . . 1666 | | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 Care-of Nonce Index 1671 This value will be echoed back by the mobile node to the 1672 correspondent node in a subsequent Binding Update. 1674 Care-of Init Cookie 1676 64-bit field which contains the care-of init cookie. 1678 Care-of Keygen Nonce 1680 This field contains the 64 bit care-of keygen token used in the 1681 return routability procedure. 1683 Mobility Options 1685 Variable-length field of such length that the complete Mobility 1686 Header is an integer multiple of 8 octets long. Contains 1687 one or more TLV-encoded mobility options. The receiver MUST 1688 ignore and skip any options which it does not understand. This 1689 specification does not define any options valid for the Care-of 1690 Test message. 1692 If no actual options are present in this message, no padding is 1693 necessary and the Header Len field will be set to 2. 1695 6.1.7. Binding Update Message 1697 The Binding Update (BU) message is used by a mobile node to notify 1698 other nodes of a new care-of address for itself. Binding Updates are 1699 sent as described in Section 11.7.1 and 11.7.2. 1701 The Binding Update uses the MH Type value 5. When this value is 1702 indicated in the MH Type field, the format of the Message Data field 1703 in the Mobility Header is as follows: 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Sequence # | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 |A|H|S|D|L| Reserved | Lifetime | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | | 1711 . . 1712 . Mobility options . 1713 . . 1714 | | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 Acknowledge (A) 1719 The Acknowledge (A) bit is set by the sending mobile node to 1720 request a Binding Acknowledgement (Section 6.1.8) be returned 1721 upon receipt of the Binding Update. 1723 Home Registration (H) 1725 The Home Registration (H) bit is set by the sending mobile 1726 node to request that the receiving node should act as this 1727 node's home agent. The destination of the packet carrying this 1728 message MUST be that of a router sharing the same subnet prefix 1729 as the home address of the mobile node in the binding. 1731 Single Address Only (S) 1733 If this bit is set, the mobile node requests that the home 1734 agent make no changes to any other Binding Cache entry except 1735 for the particular one containing the home address specified 1736 in the Home Address destination option. This disables home 1737 agent processing for other related addresses, as is described 1738 in Section 10.3.1. 1740 Duplicate Address Detection (D) 1742 The Duplicate Address Detection (D) bit is set by the sending 1743 mobile node to request that the receiving node (the mobile 1744 node's home agent) perform Duplicate Address Detection [13] 1745 on the mobile node's home link for the home address in this 1746 binding. This bit is only valid when the Home Registration (H) 1747 and Acknowledge (A) bits are also set, and MUST NOT be set 1748 otherwise. 1750 Link-Local Address Compatibility (L) 1752 The Link-Local Address Compatibility (L) bit is set when the 1753 home address reported by the mobile node has the same interface 1754 identifier (IID) as the mobile node's link-local address. 1756 Reserved 1758 These fields are unused. They MUST be initialized to zero by 1759 the sender and MUST be ignored by the receiver. 1761 Sequence # 1763 A 16-bit number used by the receiving node to sequence Binding 1764 Updates and by the sending node to match a returned Binding 1765 Acknowledgement with this Binding Update. 1767 Lifetime 1769 16-bit unsigned integer. The number of time units remaining 1770 before the binding MUST be considered expired. A value of 1771 all one bits (0xffff) indicates infinity. A value of zero 1772 indicates that the Binding Cache entry for the mobile node MUST 1773 be deleted. One time unit is 4 seconds. 1775 Mobility Options 1777 Variable-length field of such length that the complete Mobility 1778 Header is an integer multiple of 8 octets long. Contains one 1779 or more TLV-encoded mobility options. The encoding and format 1780 of defined options are described in Section 6.2. The receiver 1781 MUST ignore and skip any options which it does not understand. 1783 The following options are valid in a Binding Update: 1785 - Binding Authorization Data option 1787 - Nonce Indices option. 1789 - Alternate Care-of Address option 1791 If no options are present in this message, 4 bytes of padding is 1792 necessary and the Header Len field will be set to 1. 1794 The care-of address MUST be a unicast routable address. Binding 1795 Updates for a care-of address which is not a unicast routable address 1796 MUST be silently discarded. 1798 The deletion of a binding can be indicated by setting the Lifetime 1799 field to 0 or by setting the care-of address equal to the home 1800 address. In either case, generation of the binding management 1801 key depends exclusively on the home keygen token (Section 5.2.5). 1802 Correspondent nodes SHOULD NOT expire the Binding Cache entry before 1803 the lifetime expires, if any application hosted by the correspondent 1804 node is still likely to require communication with the mobile node. 1805 A Binding Cache entry that is deallocated prematurely might cause 1806 subsequent packets to be dropped from the mobile node, if they 1807 contain the Home Address destination option. This situation is 1808 recoverable, since an Binding Error message is sent to the mobile 1809 node (see Section 6.1.9); however, it causes unnecessary delay in the 1810 communications. 1812 6.1.8. Binding Acknowledgement Message 1814 The Binding Acknowledgement is used to acknowledge receipt of a 1815 Binding Update (Section 6.1.7). This packet is sent as described in 1816 Sections 9.5.4 and 10.3.1. 1818 The Binding Acknowledgement has the MH Type value 6. When this value 1819 is indicated in the MH Type field, the format of the Message Data 1820 field in the Mobility Header is as follows: 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Status | Reserved | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Sequence # | Lifetime | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | | 1828 . . 1829 . Mobility options . 1830 . . 1831 | | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 Reserved 1836 These fields are unused. They MUST be initialized to zero by 1837 the sender and MUST be ignored by the receiver. 1839 Status 1841 8-bit unsigned integer indicating the disposition of the 1842 Binding Update. Values of the Status field less than 128 1843 indicate that the Binding Update was accepted by the receiving 1844 node. Values greater than or equal to 128 indicate that 1845 the Binding Update was rejected by the receiving node. The 1846 following Status values are currently defined: 1848 0 Binding Update accepted 1849 128 Reason unspecified 1850 129 Administratively prohibited 1851 130 Insufficient resources 1852 131 Home registration not supported 1853 132 Not home subnet 1854 133 Not home agent for this mobile node 1855 134 Duplicate Address Detection failed 1856 135 Sequence number out of window 1857 136 Expired home nonce index 1858 137 Expired care-of nonce index 1859 138 Expired nonces 1861 Up-to-date values of the Status field are to be specified in 1862 the IANA registry of assigned numbers [18]. 1864 Sequence # 1866 The Sequence Number in the Binding Acknowledgement is 1867 copied from the Sequence Number field in the Binding Update. 1868 It is used by the mobile node in matching this Binding 1869 Acknowledgement with an outstanding Binding Update. 1871 Lifetime 1873 The granted lifetime, in time units of 4 seconds, for which 1874 this node SHOULD retain the entry for this mobile node in its 1875 Binding Cache. A value of all one bits (0xffff) indicates 1876 infinity. 1878 The value of this field is undefined if the Status field 1879 indicates that the Binding Update was rejected. 1881 Mobility Options 1883 Variable-length field of such length that the complete Mobility 1884 Header is an integer multiple of 8 octets long. Contains one 1885 or more TLV-encoded mobility options. The encoding and format 1886 of defined options are described in Section 6.2. The receiver 1887 MUST ignore and skip any options which it does not understand. 1889 There MAY be additional information, associated with this 1890 Binding Acknowledgement, that need not be present in all 1891 Binding Acknowledgements sent. Mobility options allow future 1892 extensions to the format of the Binding Acknowledgement to 1893 be defined. The following options are valid for the Binding 1894 Acknowledgement: 1896 - Binding Authorization Data option 1898 - Binding Refresh Advice option 1900 If no options are present in this message, 4 bytes of padding is 1901 necessary and the Header Len field will be set to 1. 1903 6.1.9. Binding Error Message 1905 The Binding Error (BE) message is used by the correspondent node to 1906 signal an error related to mobility, such as an inappropriate attempt 1907 to use the Home Address destination option without an existing 1908 binding; see Section 9.3.3 for details. 1910 The Binding Error message uses the MH Type value 7. When this value 1911 is indicated in the MH Type field, the format of the Message Data 1912 field in the Mobility Header is as follows: 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | Status | Reserved | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | | 1918 + + 1919 | | 1920 + Home Address + 1921 | | 1922 + + 1923 | | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 . . 1926 . Mobility Options . 1927 . . 1928 | | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 Status 1933 8-bit unsigned integer indicating the reason for this message. 1934 The following values are currently defined: 1936 1 Unknown binding for Home Address destination option 1937 2 Unrecognized MH Type value 1939 Reserved 1941 A 8-bit field reserved for future use. The value MUST be 1942 initialized to zero by the sender, and MUST be ignored by the 1943 receiver. 1945 Home Address 1947 The home address that was contained in the Home Address 1948 destination option. The mobile node uses this information to 1949 determine which binding does not exist, in cases where the 1950 mobile node has several home addresses. 1952 Mobility Options 1954 Variable-length field of such length that the complete Mobility 1955 Header is an integer multiple of 8 octets long. Contains one 1956 or more TLV-encoded mobility options. The receiver MUST ignore 1957 and skip any options which it does not understand. 1959 There MAY be additional information, associated with this 1960 Binding Error message, that need not be present in all Binding 1961 Error messages sent. Mobility options allow future extensions 1962 to the format of the format of the Binding Error message to 1963 be defined. The encoding and format of defined options are 1964 described in Section 6.2. This specification does not define 1965 any options valid for the Binding Error message. 1967 If no actual options are present in this message, no padding is 1968 necessary and the Header Len field will be set to 2. 1970 6.2. Mobility Options 1972 Mobility messages can include one or more mobility options. This 1973 allows optional fields that may not be needed in every use of a 1974 particular Mobility Header, as well as future extensions to the 1975 format of the messages. Such options are included in the Message 1976 Data field of the message itself, after the fixed portion of the 1977 message data specified in the message subsections of Section 6.1. 1979 The presence of such options will be indicated by the Header Len of 1980 the Mobility Header. If included, the Binding Authorization Data 1981 option (Section 6.2.6) MUST be the last option and MUST NOT have 1982 trailing padding. Otherwise, options can be placed in any order. 1984 6.2.1. Format 1986 Mobility options are encoded within the remaining space of the 1987 Message Data field of a mobility message, using a type-length-value 1988 (TLV) format as follows: 1990 0 1 2 3 1991 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 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Option Type | Option Length | Option Data... 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 Option Type 1998 8-bit identifier of the type of mobility option. When 1999 processing a Mobility Header containing an option for which 2000 the Option Type value is not recognized by the receiver, 2001 the receiver MUST quietly ignore and skip over the option, 2002 correctly handling any remaining options in the message. 2004 Option Length 2006 8-bit unsigned integer, representing the length in octets of 2007 the mobility option, not including the Option Type and Option 2008 Length fields. 2010 Option Data 2012 A variable length field that contains data specific to the 2013 option. 2015 The following subsections specify the Option types which are 2016 currently defined for use in the Mobility Header. 2018 Implementations MUST silently ignore any mobility options that they 2019 do not understand. 2021 6.2.2. Pad1 2023 The Pad1 option does not have any alignment requirements. Its format 2024 is as follows: 2026 0 2027 0 1 2 3 4 5 6 7 2028 +-+-+-+-+-+-+-+-+ 2029 | Type = 0 | 2030 +-+-+-+-+-+-+-+-+ 2032 NOTE! the format of the Pad1 option is a special case - it has 2033 neither Option Length nor Option Data fields. 2035 The Pad1 option is used to insert one octet of padding in the 2036 Mobility Options area of a Mobility Header. If more than one octet 2037 of padding is required, the PadN option, described next, should be 2038 used rather than multiple Pad1 options. 2040 6.2.3. PadN 2042 The PadN option does not have any alignment requirements. Its format 2043 is as follows: 2045 0 1 2046 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2048 | Type = 1 | Option Length | Option Data 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2051 The PadN option is used to insert two or more octets of padding in 2052 the Mobility Options area of a mobility message. For N octets of 2053 padding, the Option Length field contains the value N-2, and the 2054 Option Data consists of N-2 zero-valued octets. Option data MUST be 2055 ignored by the receiver. 2057 6.2.4. Alternate Care-of Address 2059 The Alternate Care-of Address option has an alignment requirement of 2060 8n+6. Its format is as follows: 2062 0 1 2 3 2063 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 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Type = 3 | Length = 16 | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | | 2068 + + 2069 | | 2070 + Alternate Care-of Address + 2071 | | 2072 + + 2073 | | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 The Alternate Care-of Address option is valid only in Binding Update. 2077 The Alternate Care-of Address field contains an address to use as the 2078 care-of address for the binding, rather than using the Source Address 2079 of the packet as the care-of address. 2081 6.2.5. Nonce Indices 2083 The Nonce Indices option has an alignment requirement of 2n. Its 2084 format is as follows: 2086 0 1 2 3 2087 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 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 | Type = 4 | Length = 4 | 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | Home Nonce Index | Care-of Nonce Index | 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 The Nonce Indices option is valid only in the Binding Update message, 2095 and only when present together with an Binding Authorization Data 2096 option. 2098 The Home Nonce Index field tells the correspondent node that receives 2099 the message which of its stored random nonce values is to be used to 2100 produce the home keygen token to authorize the Binding Update. 2102 The Care-of Nonce Index field tells the correspondent node that 2103 receives the message which of its stored random nonce values is to 2104 be used to produce the care-of keygen token to authorize the Binding 2105 Update. 2107 6.2.6. Binding Authorization Data 2109 The Binding Authorization Data option has an alignment requirement of 2110 8n+2. Its format is as follows: 2112 0 1 2 3 2113 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 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | Type = 5 | Option Length | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | | 2118 + + 2119 | Authenticator | 2120 + + 2121 | | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 The Binding Authorization Data option is valid in the Binding Update 2125 and Binding Acknowledgment. 2127 The Option Length field contains the length of the authenticator in 2128 octets. 2130 The Authenticator field contains a cryptographic value which can be 2131 used to determine that the message in question comes from the right 2132 authority. Rules for calculating this value depend on the used 2133 authorization procedure. 2135 For the return routability procedure, this option can appear in the 2136 Binding Update and Binding Acknowledgements. Rules for calculating 2137 the Authenticator value are the following: 2139 Mobility Data = care-of address | final dest | Mobility Header Data 2140 Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) 2142 Where | denotes concatenation and "final dest" is the IPv6 address 2143 of the final destination of the packet. "Mobility Header Data" is 2144 the content of the Mobility Header, excluding the Authenticator 2145 field itself. The Authenticator value is calculated as if the 2146 Checksum field in the Mobility Header was zero. The Checksum in the 2147 transmitted packet is still calculated in the usual manner, with 2148 the calculated Authenticator being a part of the packet protected 2149 by the Checksum. Kbm is the binding management key, which is 2150 typically created using nonces provided by the correspondent node 2151 (see Section 9.4). 2153 The first 96 bits from the MAC result are used as the Authenticator 2154 field. Note that, if the message is sent to a destination which is 2155 itself mobile, the "final dest" address may not be the address found 2156 in the Destination Address field of the IPv6 header; instead the 2157 address of the true destination (e.g., its home address) should be 2158 used. 2160 6.2.7. Binding Refresh Advice 2162 The Binding Refresh Advice option has an alignment requirement of 2n. 2163 Its format is as follows: 2165 0 1 2 3 2166 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 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Type = 6 | Length = 2 | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Refresh Interval | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 The Binding Refresh Advice option is only valid in the Binding 2174 Acknowledgement, and only on Binding Acknowledgements sent from 2175 the mobile node's home agent in reply to a home registration. The 2176 Refresh Interval is measured in units of four seconds, and indicates 2177 how long before the mobile node SHOULD send a new home registration 2178 to the home agent. The Refresh Interval MUST be set to indicate 2179 a smaller time interval than the Lifetime value of the Binding 2180 Acknowledgement. 2182 6.3. Home Address Option 2184 The Home Address option is carried by the Destination Option 2185 extension header (Next Header value = 60). It is used in a packet 2186 sent by a mobile node while away from home, to inform the recipient 2187 of the mobile node's home address. 2189 The Home Address option is encoded in type-length-value (TLV) format 2190 as follows: 2192 0 1 2 3 2193 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 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | Next Header | Header Ext Len | Option Type | Option Length | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | | 2198 + + 2199 | | 2200 + Home Address + 2201 | | 2202 + + 2203 | | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 Option Type 2208 201 = 0xC9 2210 Option Length 2212 8-bit unsigned integer. Length of the option, in octets, 2213 excluding the Option Type and Option Length fields. This field 2214 MUST be set to 16. 2216 Home Address 2218 The home address of the mobile node sending the packet. This 2219 address MUST be a unicast routable address. 2221 IPv6 requires that options appearing in a Hop-by-Hop Options 2222 header or Destination Options header be aligned in a packet so that 2223 multi-octet values within the Option Data field of each option fall 2224 on natural boundaries (i.e., fields of width n octets are placed at 2225 an integer multiple of n octets from the start of the header, for 2226 n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Home 2227 Address option is 8n+6. 2229 The three highest-order bits of the Option Type field are encoded 2230 to indicate specific processing of the option [11]; for the Home 2231 Address option, these three bits are set to 110. This indicates the 2232 following processing requirements: 2234 - Any IPv6 node that does not recognize the Option Type must 2235 discard the packet. 2237 - If the packet's Destination Address was not a multicast address, 2238 return an ICMP Parameter Problem, Code 2, message to the packet's 2239 Source Address; otherwise, for multicast addresses, the ICMP 2240 message MUST NOT be sent. 2242 - The data within the option cannot change en-route to the packet's 2243 final destination. 2245 The Home Address option MUST be placed as follows: 2247 - After the routing header, if that header is present 2249 - Before the Fragment Header, if that header is present 2251 - Before the AH Header or ESP Header, if either one of those 2252 headers is present 2254 For each IPv6 packet header, the Home Address Option MUST NOT appear 2255 more than once. However, an encapsulated packet [15] MAY contain a 2256 separate Home Address option associated with each encapsulating IP 2257 header. 2259 The inclusion of a Home Address destination option in a packet 2260 affects the receiving node's processing of only this single packet. 2261 No state is created or modified in the receiving node as a result 2262 of receiving a Home Address option in a packet. In particular, the 2263 presence of a Home Address option in a received packet MUST NOT alter 2264 the contents of the receiver's Binding Cache and MUST NOT cause any 2265 changes in the routing of subsequent packets sent by this receiving 2266 node. 2268 6.4. Type 2 Routing Header 2270 Mobile IPv6 defines a new routing header variant, the type 2 2271 routing header, to allow the packet to be routed directly from a 2272 correspondent to the mobile node's care-of address. The mobile 2273 node's care-of address is inserted into the IPv6 Destination Address 2274 field. Once the packet arrives at the care-of address, the mobile 2275 node retrieves its home address from the routing header, and this is 2276 used as the final destination address for the packet. 2278 The new routing header uses a different type than defined for 2279 "regular" IPv6 source routing, enabling firewalls to apply different 2280 rules to source routed packets than to Mobile IPv6. This routing 2281 header type (type 2) is restricted to carry only one IPv6 address. 2282 All IPv6 nodes which process this routing header MUST verify that 2283 the address contained within is the node's own home address in 2284 order to prevent packets from being forwarded outside the node. 2285 The IP address contained in the routing header, since it is the 2286 mobile node's home address, MUST be a unicast routable address. 2287 Furthermore, if the scope of the home address is smaller than the 2288 scope of the care-of address, the mobile node MUST discard the packet 2289 (see Section 4.6). 2291 6.4.1. Format 2293 The type 2 routing header has the following format: 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | Reserved | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | | 2301 + + 2302 | | 2303 + Home Address + 2304 | | 2305 + + 2306 | | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 Next Header 2311 8-bit selector. Identifies the type of header immediately 2312 following the routing header. Uses the same values as the IPv6 2313 Next Header field [11]. 2315 Hdr Ext Len 2317 2 (8-bit unsigned integer); length of the routing header in 2318 8-octet units, not including the first 8 octets 2320 Routing Type 2322 2 (8-bit unsigned integer). 2324 Segments Left 2326 1 (8-bit unsigned integer). 2328 Reserved 2330 32-bit reserved field. Initialized to zero for transmission, 2331 and ignored on reception. 2333 Home Address 2335 The Home Address of the destination Mobile Node. 2337 For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments 2338 Left value describes the number of route segments remaining; i.e., 2339 number of explicitly listed intermediate nodes still to be visited 2340 before reaching the final destination. Segments Left MUST be 1. The 2341 ordering rules for extension headers in an IPv6 packet are described 2342 in Section 4.1 of [11]. The type 2 routing header defined for Mobile 2343 IPv6 follows the same ordering as other routing headers. If both a 2344 Type 0 and a type 2 routing header are present, the type 2 routing 2345 header should follow the other routing header. 2347 In addition, the general procedures defined by IPv6 for routing 2348 headers suggest that a received routing header MAY be automatically 2349 "reversed" to construct a routing header for use in any response 2350 packets sent by upper-layer protocols, if the received packet is 2351 authenticated [6]. This MUST NOT be done automatically for type 2 2352 routing headers. 2354 6.5. ICMP Home Agent Address Discovery Request Message 2356 The ICMP Home Agent Address Discovery Request message is used by a 2357 mobile node to initiate the dynamic home agent address discovery 2358 mechanism, as described in Section 11.4.1. The mobile node sends 2359 the Home Agent Address Discovery Request message to the Mobile IPv6 2360 Home-Agents anycast address for its own home subnet prefix [16]. 2362 0 1 2 3 2363 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 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | Type | Code | Checksum | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 | Identifier | Reserved | 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 Type 2372 150 2374 Code 2376 0 2378 Checksum 2380 The ICMP checksum [14]. 2382 Identifier 2384 An identifier to aid in matching Home Agent Address Discovery 2385 Reply messages to this Home Agent Address Discovery Request 2386 message. 2388 Reserved 2390 This field is unused. It MUST be initialized to zero by the 2391 sender and MUST be ignored by the receiver. 2393 The Source Address of the Home Agent Address Discovery Request 2394 message packet MUST be one of the mobile node's current care-of 2395 addresses. The home agent MUST then return the Home Agent Address 2396 Discovery Reply message directly to the Source Address chosen by the 2397 mobile node. Note that, at the time of performing this dynamic home 2398 agent address discovery procedure, it is likely that the mobile node 2399 is not registered with any home agent within the specified anycast 2400 group. 2402 6.6. ICMP Home Agent Address Discovery Reply Message 2404 The ICMP Home Agent Address Discovery Reply message is used by a home 2405 agent to respond to a mobile node that uses the dynamic home agent 2406 address discovery mechanism, as described in Section 10.5. 2408 0 1 2 3 2409 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 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 | Type | Code | Checksum | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | Identifier | Reserved | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | | 2416 + + 2417 . . 2418 . Home Agent Addresses . 2419 . . 2420 + + 2421 | | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 Type 2426 151 2428 Code 2430 0 2432 Checksum 2434 The ICMP checksum [14]. 2436 Identifier 2438 The identifier from the invoking Home Agent Address Discovery 2439 Request message. 2441 Reserved 2443 This field is unused. It MUST be initialized to zero by the 2444 sender and MUST be ignored by the receiver. 2446 Home Agent Addresses 2448 A list of addresses of home agents on the home link for the 2449 mobile node. The number of addresses present in the list is 2450 indicated by the remaining length of the IPv6 packet carrying 2451 the Home Agent Address Discovery Reply message. 2453 6.7. ICMP Mobile Prefix Solicitation Message Format 2455 The ICMP Mobile Prefix Solicitation Message is sent by a mobile 2456 node to its home agent while it is away from home. The purpose 2457 of the message is to solicit a Mobile Prefix Advertisement from 2458 the home agent, which will allow the mobile node to gather prefix 2459 information about its home network. This information can be used to 2460 configure and update home address(es) according to changes in prefix 2461 information supplied by the home agent. 2463 0 1 2 3 2464 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 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | Type | Code | Checksum | 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | Identifier | Reserved | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 IP Fields: 2473 Source Address 2475 The mobile node's care-of address. 2477 Destination Address 2479 The address of the mobile node's home agent. This home agent 2480 must be on the link which the mobile node wishes to learn 2481 prefix information about. 2483 Hop Limit 2485 Set to an initial hop limit value, similarly to any other 2486 unicast packet sent by the mobile node. 2488 Destination Option: 2490 A Home Address destination option MUST be included. 2492 AH or ESP header: 2494 IPsec headers SHOULD be supported and used as described in 2495 Section 5.4. 2497 ICMP Fields: 2499 Type 2501 152 2503 Code 2505 0 2507 Checksum 2509 The ICMP checksum [14]. 2511 Identifier 2513 An identifier to aid in matching a future Mobile Prefix 2514 Advertisement to this Mobile Prefix Solicitation. 2516 Reserved 2518 This field is unused. It MUST be initialized to zero by the 2519 sender and MUST be ignored by the receiver. 2521 6.8. ICMP Mobile Prefix Advertisement Message Format 2523 A home agent will send a Mobile Prefix Advertisement to a mobile 2524 node to distribute prefix information about the home link while the 2525 mobile node is traveling away from the home network. This will occur 2526 in response to a Mobile Prefix Solicitation with an Advertisement, 2527 or by an unsolicited Advertisement sent according to the rules in 2528 Section 10.6. 2530 0 1 2 3 2531 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 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2533 | Type | Code | Checksum | 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 | Identifier | Options ... 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 IP Fields: 2540 Source Address 2541 The home agent's address as the mobile node would 2542 expect to see it (i.e., same network prefix) 2544 Destination Address 2545 If this message is a response to a Mobile Prefix 2546 Solicitation, this field contains the Source Address 2547 field from that packet. For unsolicited messages, 2548 the mobile node's care-of address SHOULD be used. 2549 Note that unsolicited messages can only be sent if 2550 the mobile node is currently registered with the 2551 home agent. 2553 Routing header: 2555 A type 2 routing header MUST be included. 2557 AH or ESP header: 2559 IPsec headers SHOULD be supported and used as described in 2560 Section 5.4. 2562 ICMP Fields: 2564 Type 2566 153 2568 Code 2570 0 2572 Checksum 2574 The ICMP checksum [14]. 2576 Identifier 2578 An identifier to aid in matching this Mobile Prefix 2579 Advertisement to a previous Mobile Prefix Solicitation. 2581 Options: 2583 Prefix Information 2585 Each message contains one or more Prefix Information options. 2586 Each option carries the prefix(es) that the mobile node should 2587 use to configure its home address(es). Section 10.6 describes 2588 which prefixes should be advertised to the mobile node. 2590 The Prefix Information option is defined in Section 4.6.2 2591 of [12], with modifications defined in Section 7.2 of this 2592 specification. The home agent MUST use this modified Prefix 2593 Information option to send the aggregate list of home network 2594 prefixes as defined in Section 10.6.1. 2596 The Mobile Prefix Advertisement sent by the home agent MAY include 2597 the Source Link-layer Address option defined in RFC 2461 [12], or the 2598 Advertisement Interval option specified in Section 7.3. 2600 Future versions of this protocol may define new option types. Mobile 2601 nodes MUST silently ignore any options they do not recognize and 2602 continue processing the message. 2604 If the Advertisement is sent in response to a Mobile Prefix 2605 Solicitation, the home agent MUST copy the Identifier value from that 2606 message into the Identifier field of the Advertisement. 2608 The home agent MUST NOT send more than one Mobile Prefix 2609 Advertisement message per second to any mobile node. 2611 7. Modifications to IPv6 Neighbor Discovery 2613 7.1. Modified Router Advertisement Message Format 2615 Mobile IPv6 modifies the format of the Router Advertisement 2616 message [12] by the addition of a single flag bit to indicate that 2617 the router sending the Advertisement message is serving as a home 2618 agent on this link. The format of the Router Advertisement message 2619 is as follows: 2621 0 1 2 3 2622 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 2623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 | Type | Code | Checksum | 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | Reachable Time | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 | Retrans Timer | 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 | Options ... 2633 +-+-+-+-+-+-+-+-+-+-+-+- 2635 This format represents the following changes over that originally 2636 specified for Neighbor Discovery [12]: 2638 Home Agent (H) 2640 The Home Agent (H) bit is set in a Router Advertisement to 2641 indicate that the router sending this Router Advertisement is 2642 also functioning as a Mobile IPv6 home agent on this link. 2644 Reserved 2646 Reduced from a 6-bit field to a 5-bit field to account for the 2647 addition of the above bit. 2649 7.2. Modified Prefix Information Option Format 2651 Mobile IPv6 requires knowledge of a router's global address in 2652 building a Home Agents List as part of the dynamic home agent address 2653 discovery mechanism (Sections 10.5 and 11.4.1). 2655 However, Neighbor Discovery [12] only advertises a router's 2656 link-local address, by requiring this address to be used as the IP 2657 Source Address of each Router Advertisement. 2659 Mobile IPv6 extends Neighbor Discovery to allow a router to advertise 2660 its global address, by the addition of a single flag bit in the 2661 format of a Prefix Information option for use in Router Advertisement 2662 messages. The format of the Prefix Information option is as follows: 2664 0 1 2 3 2665 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 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | Type | Length | Prefix Length |L|A|R|Reserved1| 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 | Valid Lifetime | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | Preferred Lifetime | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | Reserved2 | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | | 2676 + + 2677 | | 2678 + Prefix + 2679 | | 2680 + + 2681 | | 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 This format represents the following changes over that originally 2685 specified for Neighbor Discovery [12]: 2687 Router Address (R) 2689 1-bit router address flag. When set, indicates that the 2690 Prefix field, in addition to advertising the indicated prefix, 2691 contains a complete IP address assigned to the sending router. 2692 This router IP address has the same scope and conforms to the 2693 same lifetime values as the advertised prefix. This use of 2694 the Prefix field is compatible with its use in advertising 2695 the prefix itself, since Prefix Advertisement uses only the 2696 leading number Prefix bits specified by the Prefix Length 2697 field. Interpretation of this flag bit is thus independent 2698 of the processing required for the On-Link (L) and Autonomous 2699 Address-Configuration (A) flag bits. 2701 Reserved1 2703 Reduced from a 6-bit field to a 5-bit field to account for the 2704 addition of the above bit. 2706 In a Router Advertisement, a home agent MUST, and all other routers 2707 MAY, include at least one Prefix Information option with the Router 2708 Address (R) bit set. Neighbor Discovery specifies that, if including 2709 all options in a Router Advertisement causes the size of the 2710 Advertisement to exceed the link MTU, multiple Advertisements can be 2711 sent, each containing a subset of the options [12]. In this case, at 2712 least one (not all) of these multiple Advertisements being sent needs 2713 to satisfy the above requirement. 2715 7.3. New Advertisement Interval Option Format 2717 Mobile IPv6 defines a new Advertisement Interval option, used in 2718 Router Advertisement messages to advertise the interval at which the 2719 sending router sends unsolicited multicast Router Advertisements. 2720 The format of the Advertisement Interval option is as follows: 2722 0 1 2 3 2723 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 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Type | Length | Reserved | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Advertisement Interval | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 Type 2732 7 2734 Length 2736 8-bit unsigned integer. The length of the option (including 2737 the type and length fields) in units of 8 octets. The value of 2738 this field MUST be 1. 2740 Reserved 2742 This field is unused. It MUST be initialized to zero by the 2743 sender and MUST be ignored by the receiver. 2745 Advertisement Interval 2747 32-bit unsigned integer. The maximum time, in milliseconds, 2748 between successive unsolicited router Router Advertisement 2749 messages sent by this router on this network interface. Using 2750 the conceptual router configuration variables defined by 2751 Neighbor Discovery [12], this field MUST be equal to the value 2752 MaxRtrAdvInterval, expressed in milliseconds. 2754 Routers MAY include this option in their Router Advertisements. A 2755 mobile node receiving a Router Advertisement containing this option 2756 SHOULD utilize the specified Advertisement Interval for that router 2757 in its movement detection algorithm, as described in Section 11.5.1. 2759 This option MUST be silently ignored for other Neighbor Discovery 2760 messages. 2762 7.4. New Home Agent Information Option Format 2764 Mobile IPv6 defines a new Home Agent Information option, used in 2765 Router Advertisements sent by a home agent to advertise information 2766 specific to this router's functionality as a home agent. The format 2767 of the Home Agent Information option is as follows: 2769 0 1 2 3 2770 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 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | Type | Length | Reserved | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | Home Agent Preference | Home Agent Lifetime | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 Type 2779 8 2781 Length 2783 8-bit unsigned integer. The length of the option (including 2784 the type and length fields) in units of 8 octets. The value of 2785 this field MUST be 1. 2787 Reserved 2789 This field is unused. It MUST be initialized to zero by the 2790 sender and MUST be ignored by the receiver. 2792 Home Agent Preference 2794 16-bit signed, two's complement integer. The preference for 2795 the home agent sending this Router Advertisement, for use in 2796 ordering the addresses returned to a mobile node in the Home 2797 Agent Addresses field of a Home Agent Address Discovery Reply 2798 message. Higher values mean more preferable. If this option 2799 is not included in a Router Advertisement in which the Home 2800 Agent (H) bit is set, the preference value for this home agent 2801 SHOULD be considered to be 0. Values greater than 0 indicate a 2802 home agent more preferable than this default value, and values 2803 less than 0 indicate a less preferable home agent. 2805 The manual configuration of the Home Agent Preference value 2806 is described in Section 8.4. In addition, the sending home 2807 agent MAY dynamically set the Home Agent Preference value, for 2808 example basing it on the number of mobile nodes it is currently 2809 serving or on its remaining resources for serving additional 2810 mobile nodes; such dynamic settings are beyond the scope of 2811 this document. Any such dynamic setting of the Home Agent 2812 Preference, however, MUST set the preference appropriately, 2813 relative to the default Home Agent Preference value of 0 that 2814 may be in use by some home agents on this link (i.e., a home 2815 agent not including a Home Agent Information option in its 2816 Router Advertisements will be considered to have a Home Agent 2817 Preference value of 0). 2819 Home Agent Lifetime 2821 16-bit unsigned integer. The lifetime associated with the 2822 home agent in units of seconds. The default value is the same 2823 as the Router Lifetime, as specified in the main body of the 2824 Router Advertisement. The maximum value corresponds to 18.2 2825 hours. A value of 0 MUST NOT be used. The Home Agent Lifetime 2826 applies only to this router's usefulness as a home agent; it 2827 does not apply to information contained in other message fields 2828 or options. 2830 Home agents MAY include this option in their Router Advertisements. 2831 This option MUST NOT be included in a Router Advertisement in which 2832 the Home Agent (H) bit (see Section 7.1) is not set. If this option 2833 is not included in a Router Advertisement in which the Home Agent (H) 2834 bit is set, the lifetime for this home agent MUST be considered to 2835 be the same as the Router Lifetime in the Router Advertisement. 2836 If multiple Advertisements are being sent instead of a single 2837 larger unsolicited multicast Advertisement, all of the multiple 2838 Advertisements with the Router Address (R) bit set MUST include this 2839 option with the same contents, otherwise this option MUST be omitted 2840 from all Advertisements. 2842 This option MUST be silently ignored for other Neighbor Discovery 2843 messages. 2845 If both the Home Agent Preference and Home Agent Lifetime are set 2846 to their default values specified above, this option SHOULD NOT be 2847 included in the Router Advertisement messages sent by this home 2848 agent. 2850 7.5. Changes to Sending Router Advertisements 2852 The Neighbor Discovery protocol specification [12] limits routers to 2853 a minimum interval of 3 seconds between sending unsolicited multicast 2854 Router Advertisement messages from any given network interface 2855 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 2857 "Routers generate Router Advertisements frequently enough 2858 that hosts will learn of their presence within a few 2859 minutes, but not frequently enough to rely on an absence 2860 of advertisements to detect router failure; a separate 2861 Neighbor Unreachability Detection algorithm provides failure 2862 detection." 2864 This limitation, however, is not suitable to providing timely 2865 movement detection for mobile nodes. Mobile nodes detect their 2866 own movement by learning the presence of new routers as the mobile 2867 node moves into wireless transmission range of them (or physically 2868 connects to a new wired network), and by learning that previous 2869 routers are no longer reachable. Mobile nodes MUST be able to 2870 quickly detect when they move to a link served by a new router, so 2871 that they can acquire a new care-of address and send Binding Updates 2872 to register this care-of address with their home agent and to notify 2873 correspondent nodes as needed. 2875 Mobile IPv6 relaxes this limit such that routers MAY send unsolicited 2876 multicast Router Advertisements more frequently. This is important 2877 on network interfaces where the router is expecting to provide 2878 service to visiting mobile nodes (e.g., wireless network interfaces), 2879 or on which it is serving as a home agent to one or more mobile 2880 nodes (who may return home and need to hear its Advertisements). 2881 Such routers SHOULD be configured with a smaller MinRtrAdvInterval 2882 value and MaxRtrAdvInterval value, to allow sending of unsolicited 2883 multicast Router Advertisements more often. Recommended values for 2884 these limits are: 2886 - MinRtrAdvInterval 0.05 seconds 2888 - MaxRtrAdvInterval 1.5 seconds 2890 Use of these modified limits MUST be configurable, and specific 2891 knowledge of the type of network interface in use SHOULD be taken 2892 into account in configuring these limits for each network interface. 2893 Note that multicast Router Advertisements are not always required 2894 in certain wireless networks that have limited bandwidth. Mobility 2895 detection or link changes in such networks may be done at lower 2896 layers. Router advertisements in such networks SHOULD be sent only 2897 when solicited. In such networks it SHOULD be possible to disable 2898 unsolicited multicast Router Advertisements on specific interfaces. 2899 The MaxRtrAdvInterval in such a case can be set to some high value. 2901 When sending unsolicited multicast Router Advertisements more 2902 frequently than the standard limit on unsolicited multicast 2903 Advertisement frequency, the sending router need not include all 2904 options in each of these Advertisements, but it SHOULD include at 2905 least one Prefix Information option with the Router Address (R) bit 2906 set (Section 7.2) in each. 2908 7.6. Changes to Sending Router Solicitations 2910 In addition to the limit on routers sending unsolicited multicast 2911 Router Advertisement messages (Section 7.5), Neighbor Discovery 2912 defines limits on nodes sending Router Solicitation messages, such 2913 that a node SHOULD send no more than 3 Router Solicitations, and that 2914 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 2915 However, these limits prevent a mobile node from finding a new 2916 default router (and thus a new care-of address) quickly as it moves 2917 about. 2919 Mobile IPv6 relaxes this limit such that, while a mobile node is away 2920 from home, it MAY send Router Solicitations more frequently. The 2921 following limits for sending Router Solicitations are recommended for 2922 mobile nodes while away from home: 2924 - A mobile node that is not configured with any current care-of 2925 address (e.g., the mobile node has moved since its previous 2926 care-of address was configured), MAY send more than the defined 2927 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 2928 Solicitations. 2930 - The rate at which a mobile node sends Router Solicitations MUST 2931 be limited, although a mobile node MAY send Router Solicitations 2932 more frequently than the defined Neighbor Discovery limit of 2933 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 2934 be configurable, and specific knowledge of the type of network 2935 interface in use SHOULD be taken into account in configuring this 2936 limit for each network interface. A recommended minimum interval 2937 is 1 second. 2939 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 2940 a mobile node MUST reduce the rate at which it sends subsequent 2941 Router Solicitations. Subsequent Router Solicitations SHOULD 2942 be sent using a binary exponential back-off mechanism, doubling 2943 the interval between consecutive Router Solicitations, up to a 2944 maximum interval. The maximum interval MUST be configurable and 2945 SHOULD be chosen appropriately based on the characteristics of 2946 the type of network interface in use. 2948 - While still searching for a new default router and care-of 2949 address, a mobile node MUST NOT increase the rate at which it 2950 sends Router Solicitations unless it has received a positive 2951 indication (such as from lower network layers) that it has moved 2952 to a new link. After successfully acquiring a new care-of 2953 address, the mobile node SHOULD also increase the rate at which 2954 it will send Router Solicitations when it next begins searching 2955 for a new default router and care-of address. 2957 - A mobile node that is currently configured with a care-of address 2958 SHOULD NOT send Router Solicitations to the default router 2959 on its current link, until its movement detection algorithm 2960 (Section 11.5.1) determines that it has moved and that its 2961 current care-of address might no longer be valid. 2963 7.7. Changes to Duplicate Address Detection 2965 Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to 2966 stop using the address and wait for reconfiguration. In addition, if 2967 the failed address was a link-local address formed from an interface 2968 identifier, the interface should be disabled. 2970 Mobile IPv6 extends this behavior as follows. Upon failing Duplicate 2971 Address Detection while away from home, the mobile node SHOULD stop 2972 using the address on this interface until the mobile node moves to 2973 another link. The mobile node SHOULD NOT wait for reconfiguration or 2974 disable the interface. 2976 The mobile node MUST NOT discard the home address based on a failure 2977 of a link-local address with the same interface identifier. Instead, 2978 the mobile node SHOULD generate a new random interface identifier and 2979 use it for assigning itself a new link-local address. In order to do 2980 this, the mobile node applies to the link-local address the procedure 2981 described in [17] for global addresses. At most 5 consecutive 2982 attempts SHOULD be performed to generate such addresses and test 2983 them through Duplicate Address Detection. If after these attempts 2984 no unique address was found, the mobile node SHOULD log a system 2985 error and give up attempting to find a link-local address on that 2986 interface, until the node moves to a new link. 2988 8. Requirements for Types of IPv6 Nodes 2990 Mobile IPv6 places some special requirements on the functions 2991 provided by different types of IPv6 nodes. This section summarizes 2992 those requirements, identifying the functionality each requirement is 2993 intended to support. 2995 The requirements are set for the following groups of nodes: 2997 - All IPv6 nodes. 2999 - All IPv6 nodes with support for route optimization. 3001 - All IPv6 routers. 3003 - All Mobile IPv6 home agents. 3005 - All Mobile IPv6 mobile nodes. 3007 It is outside the scope of this specification to specify which 3008 of these groups are mandatory in IPv6. We only describe what is 3009 mandatory for a node that supports, for instance, route optimization. 3010 Other specifications are expected to define the extent of IPv6. 3012 8.1. All IPv6 Nodes 3014 Any IPv6 node may at any time be a correspondent node of a mobile 3015 node, either sending a packet to a mobile node or receiving a packet 3016 from a mobile node. There are no Mobile IPv6 specific requirements 3017 for such nodes, and standard IPv6 techniques are sufficient. 3019 8.2. IPv6 Nodes with Support for Route Optimization 3021 Nodes that implement route optimization are a subset of all IPv6 3022 nodes on the Internet. The ability of a correspondent node to 3023 participate in route optimization is essential for the efficient 3024 operation of the IPv6 Internet, beneficial for robustness and 3025 reduction of jitter and latency, and necessary to avoid congestion 3026 in the home network. The following requirements apply to all 3027 correspondent nodes that support route optimization: 3029 - The node MUST be able validate a Home Address option using an 3030 existing Binding Cache entry, as described in Section 9.3.1. 3032 - The node MUST be able to insert a type 2 routing header 3033 into packets to be sent to a mobile node, as described in 3034 Section 9.3.2. 3036 - Unless the correspondent node is also acting as a mobile node, it 3037 MUST ignore type 2 routing headers and drop all packets that it 3038 has received with such headers. 3040 - The node SHOULD be able to interpret ICMP messages as described 3041 in Section 9.3.4. 3043 - The node MUST be able to send Binding Error messages as described 3044 in Section 9.3.3. 3046 - The node MUST be able to process Mobility Headers as described in 3047 Section 9.2. 3049 - The node MUST be able to participate in a return routability 3050 procedure (Section 9.4). 3052 - The node MUST be able to process Binding Update messages 3053 (Section 9.5). 3055 - The node MUST be able to return a Binding Acknowledgement 3056 (Section 9.5.4). 3058 - The node MUST be able to maintain a Binding Cache of the 3059 bindings received in accepted Binding Updates, as described in 3060 Sections 9.1 and 9.6. 3062 8.3. All IPv6 Routers 3064 All IPv6 routers, even those not serving as a home agent for 3065 Mobile IPv6, have an effect on how well mobile nodes can communicate: 3067 - Every IPv6 router SHOULD be able to send an Advertisement 3068 Interval option (Section 7.3) in each of its Router 3069 Advertisements [12], to aid movement detection by mobile nodes 3070 (as in Section 11.5.1). The use of this option in Router 3071 Advertisements MUST be configurable. 3073 - Every IPv6 router SHOULD be able to support sending unsolicited 3074 multicast Router Advertisements at the faster rate described in 3075 Section 7.5. The use of this faster rate MUST be configurable. 3077 - Each router SHOULD include at least one prefix with the Router 3078 Address (R) bit set and with its full IP address in its Router 3079 Advertisements (as described in Section 7.2). 3081 - Filtering routers SHOULD support different rules for type 0 3082 and type 2 routing headers (see Section 6.4) so that filtering 3083 of source routed packets (type 0) will not necessarily limit 3084 Mobile IPv6 traffic which is delivered via type 2 routing 3085 headers. 3087 8.4. IPv6 Home Agents 3089 In order for a mobile node to operate correctly while away from home, 3090 at least one IPv6 router on the mobile node's home link must function 3091 as a home agent for the mobile node. The following additional 3092 requirements apply to all IPv6 routers that serve as a home agent: 3094 - Every home agent MUST be able to maintain an entry in its Binding 3095 Cache for each mobile node for which it is serving as the home 3096 agent (Sections 10.1 and 10.3.1). 3098 - Every home agent MUST be able to intercept packets (using 3099 proxy Neighbor Discovery [12]) addressed to a mobile node for 3100 which it is currently serving as the home agent, on that mobile 3101 node's home link, while the mobile node is away from home 3102 (Section 10.4.1). 3104 - Every home agent MUST be able to encapsulate [15] such 3105 intercepted packets in order to tunnel them to the primary 3106 care-of address for the mobile node indicated in its binding in 3107 the home agent's Binding Cache (Section 10.4.2). 3109 - Every home agent MUST support decapsulating [15] reverse tunneled 3110 packets sent to it from a mobile node's home address. Every home 3111 agent MUST also check that the source address in the tunneled 3112 packets corresponds to the currently registered location of the 3113 mobile node (Section 10.4.3). 3115 - The node MUST be able to process Mobility Headers as described in 3116 Section 10.2. 3118 - Every home agent MUST be able to return a Binding Acknowledgement 3119 in response to a Binding Update (Section 10.3.1). 3121 - Every home agent MUST maintain a separate Home Agents List for 3122 each link on which it is serving as a home agent, as described in 3123 Sections 10.1 and 10.5.1. 3125 - Every home agent MUST be able to accept packets addressed to 3126 the Mobile IPv6 Home-Agents anycast address for the subnet 3127 on which it is serving as a home agent [16], and MUST be 3128 able to participate in dynamic home agent address discovery 3129 (Section 10.5). 3131 - Every home agent SHOULD support a configuration mechanism to 3132 allow a system administrator to manually set the value to be sent 3133 by this home agent in the Home Agent Preference field of the Home 3134 Agent Information Option in Router Advertisements that it sends 3135 (Section 7.4). 3137 - Every home agent SHOULD support sending ICMP Mobile Prefix 3138 Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix 3139 Solicitations (Section 6.7). This behavior MUST be configurable, 3140 so that home agents can be configured to avoid sending such 3141 Prefix Advertisements according to the needs of the network 3142 administration in the home domain. 3144 - Every home agent MUST support IPsec ESP for protection of packets 3145 belonging to the return routability procedure (Section 10.4.4). 3147 8.5. IPv6 Mobile Nodes 3149 Finally, the following requirements apply to all IPv6 nodes capable 3150 of functioning as mobile nodes: 3152 - The node MUST maintain a Binding Update List (Section 11.1). 3154 - The node MUST support sending packets containing a Home 3155 Address option (Section 11.3.1), and follow the required IPsec 3156 interaction (Section 11.3.2). 3158 - The node MUST be able to perform IPv6 encapsulation and 3159 decapsulation [15]. 3161 - The node MUST be able to process type 2 routing header as defined 3162 in Sections 6.4 and 11.3.3. 3164 - The node MUST support receiving a Binding Error message 3165 (Section 11.7.5). 3167 - The node SHOULD support receiving ICMP errors (Section 11.3.4). 3169 - The node MUST support movement detection, care-of address 3170 formation, and returning home (Section 11.5). 3172 - The node MUST be able to process Mobility Headers as described in 3173 Section 11.2. 3175 - The node MUST support the return routability procedure 3176 (Section 11.6). 3178 - The node MUST be able to send Binding Updates, as specified in 3179 Sections 11.7.1 and 11.7.2. 3181 - The node MUST be able to receive and process Binding 3182 Acknowledgements, as specified in Section 11.7.3. 3184 - The node MUST support receiving a Binding Refresh Request 3185 (Section 6.1.2), by responding with a Binding Update. 3187 - The node MUST support receiving Mobile Prefix Advertisements 3188 (Section 11.4.3) and reconfiguring its home address based on the 3189 prefix information contained therein. 3191 - The node SHOULD support use of the dynamic home agent address 3192 discovery mechanism, as described in Section 11.4.1. 3194 9. Correspondent Node Operation 3196 9.1. Conceptual Data Structures 3198 IPv6 nodes with route optimization support maintain a Binding Cache 3199 of bindings for other nodes. A separate Binding Cache SHOULD be 3200 maintained by each IPv6 node for each of its IPv6 addresses. The 3201 Binding Cache MAY be implemented in any manner consistent with the 3202 external behavior described in this document, for example by being 3203 combined with the node's Destination Cache as maintained by Neighbor 3204 Discovery [12]. When sending a packet, the Binding Cache is searched 3205 before the Neighbor Discovery conceptual Destination Cache [12]. 3206 That is, any Binding Cache entry for this destination SHOULD take 3207 precedence over any Destination Cache entry for the same destination. 3209 Each Binding Cache entry conceptually contains the following fields: 3211 - The home address of the mobile node for which this is the Binding 3212 Cache entry. This field is used as the key for searching the 3213 Binding Cache for the destination address of a packet being sent. 3214 If the destination address of the packet matches the home address 3215 in the Binding Cache entry, this entry SHOULD be used in routing 3216 that packet. 3218 - The care-of address for the mobile node indicated by the home 3219 address field in this Binding Cache entry. If the destination 3220 address of a packet being routed by a node matches the home 3221 address in this entry, the packet SHOULD be routed to this 3222 care-of address. This is described in Section 9.3.2 for packets 3223 originated by this node. 3225 - A lifetime value, indicating the remaining lifetime for this 3226 Binding Cache entry. The lifetime value is initialized from 3227 the Lifetime field in the Binding Update that created or last 3228 modified this Binding Cache entry. Once the lifetime of this 3229 entry expires, the entry MUST be deleted from the Binding Cache. 3231 - A flag indicating whether or not this Binding Cache entry is a 3232 home registration entry. 3234 - The maximum value of the Sequence Number field received in 3235 previous Binding Updates for this mobile node home address. The 3236 Sequence Number field is 16 bits long. Sequence Number values 3237 MUST be compared modulo 2**16 as explained in Section 9.5.1. 3239 - Usage information for this Binding Cache entry. This is needed 3240 to implement the cache replacement policy in use in the Binding 3241 Cache. Recent use of a cache entry also serves as an indication 3242 that a Binding Refresh Request should be sent when the lifetime 3243 of this entry nears expiration. 3245 Binding Cache entries not marked as home registrations MAY be 3246 replaced at any time by any reasonable local cache replacement policy 3247 but SHOULD NOT be unnecessarily deleted. The Binding Cache for any 3248 one of a node's IPv6 addresses may contain at most one entry for 3249 each mobile node home address. The contents of a node's Binding 3250 Cache MUST NOT be changed in response to a Home Address option in a 3251 received packet. 3253 9.2. Processing Mobility Headers 3255 Mobility Header processing MUST observe the following rules: 3257 1. The MH Type field MUST have a known value (Section 6.1.1). 3258 Otherwise, the node MUST discard the message and SHOULD issue a 3259 Binding Error message as described in Section 9.3.3, with Status 3260 field set to 2 (unrecognized MH Type value). 3262 2. The Payload Proto field MUST be IPPROTO_NONE (59 decimal). 3263 Otherwise, the node MUST silently discard the message. 3265 3. The checksum must be verified as per Section 6.1. Otherwise, the 3266 node MUST silently discard the message. 3268 Subsequent checks depend on the particular Mobility Header, as 3269 specified in Sections 9.4 and 9.5. 3271 9.3. Packet Processing 3273 This section describes how the correspondent node sends packets to 3274 the mobile node, and receives packets from it. 3276 9.3.1. Receiving Packets with Home Address Destination Option 3278 If the correspondent node has a Binding Cache entry for the home 3279 address of a mobile node, packets sent by the mobile node MAY include 3280 a Home Address destination option. 3282 Packets containing a Home Address option MUST be dropped if the given 3283 home address is not a unicast routable address. 3285 Packets containing a Home Address option MUST also be dropped if 3286 there is no corresponding Binding Cache entry for the given home 3287 address. A corresponding Binding Cache entry MUST have the currently 3288 registered care-of address equal to the source address of the packet. 3289 These tests MUST NOT be done for packets that contain a Binding 3290 Update and a Home Address option. 3292 If the packet is dropped due the above tests, the correspondent node 3293 SHOULD send the Binding Error message as described in Section 9.3.3. 3294 The Status field in this message should be set to 1 (unknown binding 3295 for Home Address destination option). 3297 The correspondent node MUST process the option in a manner consistent 3298 with exchanging the Home Address field from the Home Address option 3299 into the IPv6 header and replacing the original value of the Source 3300 Address field there. After all IPv6 options have been processed, it 3301 MUST be possible to process the packet without the knowledge that it 3302 came originally from a care-of address or that a Home Address option 3303 was used. 3305 No additional authentication of the Home Address option is 3306 required, except that if the IPv6 header of a packet is covered 3307 by authentication, then that authentication MUST also cover the 3308 Home Address option; this coverage is achieved automatically by the 3309 definition of the Option Type code for the Home Address option, since 3310 it indicates that the data within the option cannot change en-route 3311 to the packet's final destination, and thus the option is included in 3312 the authentication computation. By requiring that any authentication 3313 of the IPv6 header also cover the Home Address option, the security 3314 of the Source Address field in the IPv6 header is not compromised by 3315 the presence of a Home Address option. When attempting to verify 3316 authentication data in a packet that contains a Home Address option, 3317 the receiving node MUST make the calculation as if the care-of 3318 address were present in the Home Address option, and the home address 3319 were present in the source IPv6 address field of the IPv6 header. 3320 This conforms with the calculation specified in Section 11.3.2. 3322 9.3.2. Sending Packets to a Mobile Node 3324 Before sending any packet, the sending node SHOULD examine its 3325 Binding Cache for an entry for the destination address to which the 3326 packet is being sent. If the sending node has a Binding Cache entry 3327 for this address, the sending node SHOULD use a type 2 routing header 3328 to route the packet to this mobile node (the destination node) by way 3329 of its care-of address. Assuming there are no additional routing 3330 headers in this packet beyond those needed by Mobile IPv6, the mobile 3331 node sets the fields in the packet's IPv6 header and routing header 3332 as follows: 3334 - The Destination Address in the packet's IPv6 header is set to the 3335 mobile node's home address (the original destination address to 3336 which the packet was being sent). 3338 - The routing header is initialized to contain a single route 3339 segment, containing the mobile node's care-of address copied from 3340 the Binding Cache entry. The Segments Left field is, however, 3341 temporarily set to zero. 3343 The IP layer will insert the routing header before performing IPsec 3344 processing. The IPsec Security Policy Database will be consulted 3345 based on the IP source address and the destination address (which 3346 will be the mobile node's home address). Once all IPsec processing 3347 has been performed, the node swaps the IPv6 destination field with 3348 the Home Address field in the routing header, sets the Segments Left 3349 field to one, and sends the packet. This ensures the AH calculation 3350 is done on the packet in the form it will have on the receiver after 3351 advancing the routing header. 3353 Following the definition of a type 2 routing header in Section 6.4, 3354 this packet will be routed to the mobile node's care-of address, 3355 where it will be delivered to the mobile node (the mobile node has 3356 associated the care-of address with its network interface). 3358 Note that following the above conceptual model in an implementation 3359 creates some additional requirements for path MTU discovery since the 3360 layer that decides the packet size (e.g., TCP and applications using 3361 UDP) needs to be aware of the size of the headers added by the IP 3362 layer on the sending node. 3364 If, instead, the sending node has no Binding Cache entry for the 3365 destination address to which the packet is being sent, the sending 3366 node simply sends the packet normally, with no routing header. If 3367 the destination node is not a mobile node (or is a mobile node that 3368 is currently at home), the packet will be delivered directly to this 3369 node and processed normally by it. If, however, the destination node 3370 is a mobile node that is currently away from home, the packet will 3371 be intercepted by the mobile node's home agent and tunneled to the 3372 mobile node's current primary care-of address. 3374 9.3.3. Sending Binding Error Messages 3376 Sections 9.2 and 9.3.1 describe error conditions that lead to a need 3377 to send a Binding Error message. 3379 A Binding Error message is sent to the address that appeared in the 3380 IPv6 Source Address field of the offending packet. If the Source 3381 Address field does not contain a unicast address, the Binding Error 3382 message MUST NOT be sent. 3384 The Home Address field in the Binding Error message MUST be copied 3385 from the Home Address field in the Home Address destination option of 3386 the offending packet, or set to the unspecified address if no such 3387 option appeared in the packet. 3389 Binding Error messages are subject to rate limiting in the same 3390 manner as is done for ICMPv6 messages [14]. 3392 9.3.4. Receiving ICMP Error Messages 3394 When the correspondent node has a Binding Cache entry for a mobile 3395 node, all traffic destined to the mobile node goes directly to the 3396 current care-of address of the mobile node using a routing header. 3397 Any ICMP error message caused by packets on their way to the care-of 3398 address will be returned in the normal manner to the correspondent 3399 node. 3401 On the other hand, if the correspondent node has no Binding Cache 3402 entry for the mobile node, the packet will be routed through the 3403 mobile node's home link. Any ICMP error message caused by the 3404 packet on its way to the mobile node while in the tunnel, will be 3405 transmitted to the mobile node's home agent. By the definition of 3406 IPv6 encapsulation [15], the home agent MUST relay certain ICMP error 3407 messages back to the original sender of the packet, which in this 3408 case is the correspondent node. 3410 Thus, in all cases, any meaningful ICMP error messages caused by 3411 packets from a correspondent node to a mobile node will be returned 3412 to the correspondent node. If the correspondent node receives 3413 persistent ICMP Destination Unreachable messages after sending 3414 packets to a mobile node based on an entry in its Binding Cache, the 3415 correspondent node SHOULD delete this Binding Cache entry. 3417 9.4. Return Routability Procedure 3419 This subsection specifies actions taken by a correspondent node 3420 during the return routability procedure. 3422 9.4.1. Receiving Home Test Init Messages 3424 Upon receiving a Home Test Init message, the correspondent node 3425 verifies the following: 3427 - The Header Len field in the Mobility Header MUST NOT be less than 3428 the length specified in Section 6.1.3. 3430 - The packet MUST NOT include a Home Address destination option. 3432 Any packet carrying a Home Test Init message which fails to satisfy 3433 all of these tests MUST be silently ignored. 3435 Otherwise, in preparation for sending the corresponding Home Test 3436 Message, the correspondent node checks that it has the necessary 3437 material to engage in a return routability procedure, as specified 3438 in Section 5.2. The correspondent node MUST have a secret Kcn and 3439 a nonce. If it does not have this material yet, it MUST produce it 3440 before continuing with the return routability procedure. 3442 Section 9.4.3 specifies further processing. 3444 9.4.2. Receiving Care-of Test Init Messages 3446 Upon receiving a Care-of Test Init message, the correspondent node 3447 verifies the following: 3449 - The Header Len field in the Mobility Header MUST NOT be less than 3450 the length specified in Section 6.1.4. 3452 - The packet MUST NOT include a Home Address destination option. 3454 Any packet carrying a Care-of Test Init message which fails to 3455 satisfy all of these tests MUST be silently ignored. 3457 Otherwise, in preparation for sending the corresponding Care-of Test 3458 Message, the correspondent node checks that it has the necessary 3459 material to engage in a return routability procedure in the manner 3460 described in Section 9.4.1. 3462 Section 9.4.4 specifies further processing. 3464 9.4.3. Sending Home Test Messages 3466 The correspondent node creates a home keygen token and uses the 3467 current nonce index as the Home Nonce Index. It then creates a Home 3468 Test message (Section 6.1.5) and sends it to the mobile node at the 3469 latter's home address. Note that the Home Test message is always 3470 sent to the home address of the mobile node, even when there is an 3471 existing binding for the mobile node. 3473 9.4.4. Sending Care-of Test Messages 3475 The correspondent node creates a care-of nonce and uses the current 3476 nonce index as the Care-of Nonce Index. It then creates a Care-of 3477 Test message (Section 6.1.6) and sends it to the mobile node at the 3478 latter's care-of address. 3480 9.5. Processing Bindings 3482 This section explains how the correspondent node processes messages 3483 related to bindings. These messages are: 3485 - Binding Update 3487 - Binding Refresh Request 3488 - Binding Acknowledgement 3490 - Binding Error 3492 9.5.1. Receiving Binding Updates 3494 Before accepting a Binding Update, the receiving node MUST validate 3495 the Binding Update according to the following tests: 3497 - The packet MUST contain a Home Address option with a unicast 3498 routable home address, unless the Source Address is the home 3499 address of the mobile node 3501 - The Header Len field in the Mobility Header is no less than the 3502 length specified in Section 6.1.7. 3504 - The Sequence Number field in the Binding Update is greater than 3505 the Sequence Number received in the previous Binding Update for 3506 this home address, if any. 3508 This Sequence Number comparison MUST be performed modulo 2**16, 3509 i.e., the number is a free running counter represented modulo 3510 65536. A Sequence Number in a received Binding Update is 3511 considered less than or equal to the last received number if 3512 its value lies in the range of the last received number and the 3513 preceding 32767 values, inclusive. For example, if the last 3514 received sequence number was 15, then messages with sequence 3515 numbers 0 through 15, as well as 32784 through 65535, would be 3516 considered less than or equal. 3518 When the return routability procedure is used to enable the 3519 establishment of nonce indices as inputs to the creation of the 3520 binding key Kbm, the following are also required: 3522 - A Nonce Indices mobility option MUST be present, and the Home and 3523 Care-of Nonce Index values in this option MUST be recent enough 3524 to be recognized by the correspondent node. 3526 - The correspondent node MUST re-generate the home keygen token and 3527 the care-of keygen token from the information contained in the 3528 packet. It then generates the binding management key Kbm and 3529 uses it to verify the authenticator field in the Binding Update 3530 as specified in Section 6.1.7. 3532 When using Kbm for validating the Binding Update, the following are 3533 required: 3535 - The Binding Authorization Data mobility option MUST be present, 3536 and its contents MUST satisfy rules presented in Section 5.2.6. 3537 Note that a care-of address different from the Source Address MAY 3538 have been specified by including an Alternate Care-of Address 3539 mobility option in the Binding Update. When such message is 3540 received and the return routability procedure is used as an 3541 authorization method, the correspondent node MUST verify the 3542 authenticator by using the address within the Alternate Care-of 3543 Address in the calculations. 3545 - The Binding Authorization Data mobility option MUST be the last 3546 option and MUST NOT have trailing padding. 3548 - The Home Registration (H) bit MUST NOT be set. 3550 If the mobile node sends a sequence number which is not greater than 3551 the sequence number from the last successful Binding Update, then the 3552 receiving node MUST send back a Binding Acknowledgement with status 3553 code 135, and the last accepted sequence number in the Sequence 3554 Number field of the Binding Acknowledgement. 3556 If the receiving node no longer recognizes the Home Nonce 3557 Index value, Care-of Nonce Index value, or both values from the 3558 Binding Update, then the receiving node MUST send back a Binding 3559 Acknowledgement with status code 136, 137, or 138, respectively. 3561 Packets carrying Binding Updates that fail to satisfy all of these 3562 tests for any reason other than insufficiency of the Sequence Number 3563 or expired nonce index values MUST be silently discarded. 3565 If the Binding Update is valid according to the tests above, then the 3566 Binding Update is processed further as follows: 3568 - If the Lifetime specified in the Binding Update is nonzero and 3569 the specified care-of address is not equal to the home address 3570 for the binding, then this is a request to cache a binding for 3571 the mobile node. If the Home Registration (H) bit is set in the 3572 Binding Update, the Binding Update is processed according to the 3573 procedure specified in Section 10.3.1; otherwise, it is processed 3574 according to the procedure specified in Section 9.5.2. 3576 - If the Lifetime specified in the Binding Update is zero or the 3577 specified care-of address matches the home address for the 3578 binding, then this is a request to delete the mobile node's 3579 cached binding. The update MUST include a valid home nonce index 3580 (the care-of nonce index MUST be ignored by the correspondent 3581 node). In this case, generation of the binding management key 3582 depends exclusively on the home keygen token (Section 5.2.5). If 3583 the Home Registration (H) bit is set in the Binding Update, the 3584 Binding Update is processed according to the procedure specified 3585 in Section 10.3.2; otherwise, it is processed according to the 3586 procedure specified in Section 9.5.3. 3588 The specified care-of address MUST be determined as follows: 3590 - If the Alternate Care-of Address option is present, the care-of 3591 address is the address in that option. 3593 - Otherwise, the care-of address is the Source Address field in the 3594 packet's IPv6 header. 3596 The home address for the binding MUST be determined as follows: 3598 - If the Home Address destination option is present, the home 3599 address is the address in that option. 3601 - Otherwise, the home address is the Source Address field in the 3602 packet's IPv6 header. This implies that the mobile node is at 3603 home and is about to perform de-registration. 3605 9.5.2. Requests to Cache a Binding 3607 This section describes the processing of a valid Binding Update that 3608 requests a node to cache a mobile node's binding, for which the Home 3609 Registration (H) bit is not set in the Binding Update. 3611 In this case, the receiving node SHOULD create a new entry in its 3612 Binding Cache for this mobile node, or update its existing Binding 3613 Cache entry for this mobile node, if such an entry already exists. 3614 The lifetime for the Binding Cache entry is initialized from the 3615 Lifetime field specified in the Binding Update, although this 3616 lifetime MAY be reduced by the node caching the binding; the lifetime 3617 for the Binding Cache entry MUST NOT be greater than the Lifetime 3618 value specified in the Binding Update. Any Binding Cache entry MUST 3619 be deleted after the expiration of its lifetime. 3621 The Sequence Number value received from a mobile node in a Binding 3622 Update is stored by a correspondent node in its Binding Cache entry 3623 for that mobile node. If the receiving correspondent node has no 3624 Binding Cache entry for the sending mobile node, it MUST accept any 3625 Sequence Number value in a received Binding Update from this mobile 3626 node. 3628 The correspondent node MAY refuse to accept a new Binding Cache 3629 entry, if it does not have sufficient resources. A new entry MAY 3630 also be refused if the correspondent node believes its resources are 3631 utilized more efficiently in some other purpose, such as serving 3632 another mobile node with higher amount of traffic. In both cases 3633 the correspondent node SHOULD return a Binding Acknowledgement with 3634 status value 130. 3636 9.5.3. Requests to Delete a Binding 3638 This section describes the processing of a valid Binding Update that 3639 requests a node to delete a mobile node's binding from its Binding 3640 Cache, for which the Home Registration (H) bit is not set in the 3641 Binding Update. 3643 Any existing binding for the mobile node MUST be deleted. A Binding 3644 Cache entry for the mobile node MUST NOT be created in response to 3645 receiving the Binding Update. 3647 If the Binding Cache entry was created by use of return routability 3648 nonces, the correspondent node MUST ensure that the same nonces are 3649 not used again with the particular home and care-of address. If 3650 both nonces are still valid, the correspondent node has to remember 3651 the particular combination of nonce indexes, addresses, and sequence 3652 number as illegal, until at least one of the nonces has become too 3653 old. 3655 9.5.4. Sending Binding Acknowledgements 3657 A Binding Acknowledgement may be sent to indicate receipt of a 3658 Binding Update as follows: 3660 - If the Binding Update was silently discarded as described in 3661 Section 9.5.1, a Binding Acknowledgement MUST NOT be sent. 3663 - Otherwise, if the Acknowledge (A) bit set is set in the Binding 3664 Update, a Binding Acknowledgement MUST be sent. 3666 - Otherwise, if the node rejects the Binding Update, a Binding 3667 Acknowledgement MUST be sent. 3669 - Otherwise, if the node accepts the Binding Update, a Binding 3670 Acknowledgement SHOULD NOT be sent. 3672 If the node accepts the Binding Update and creates or updates 3673 an entry for this binding, the Status field in the Binding 3674 Acknowledgement MUST be set to a value less than 128. Otherwise, the 3675 Status field MUST be set to a value greater than or equal to 128. 3676 Values for the Status field are described in Section 6.1.8 and in the 3677 IANA registry of assigned numbers [18]. 3679 If the Status field in the Binding Acknowledgement contains the value 3680 136 (expired home nonce index), 137 (expired care-of nonce index), 3681 or 138 (expired nonces), then the message MUST NOT include the 3682 Binding Authorization Data mobility option. Otherwise, the Binding 3683 Authorization Data mobility option MUST be included, and MUST meet 3684 the specific authentication requirements for Binding Acknowledgements 3685 as defined in Section 5.2. 3687 If the Source Address field of the IPv6 header that carried the 3688 Binding Update does not contain a unicast address, the Binding 3689 Acknowledgement MUST NOT be sent, and the Binding Update packet MUST 3690 be silently discarded. Otherwise, the acknowledgement MUST be sent 3691 to the Source Address. Unlike the treatment of regular packets, this 3692 addressing procedure does not use information from the Binding Cache. 3694 If the Source Address is the home address of the mobile node, i.e., 3695 the Binding Update did not contain a Home Address destination option, 3696 then the Binding Acknowledgement MUST be sent to that address, 3697 and the routing header MUST NOT be used. Otherwise, the Binding 3698 Acknowledgement MUST be sent using a type 2 routing header which 3699 contains the mobile node's home address. 3701 Entries in a node's Binding Cache MUST be deleted when their lifetime 3702 expires. 3704 9.5.5. Sending Binding Refresh Requests 3706 If a Binding Cache entry being deleted is still in active use 3707 in sending packets to a mobile node, the next packet sent to the 3708 mobile node will be routed normally to the mobile node's home link. 3709 Communication with the mobile node continues, but the tunneling 3710 from the home network creates additional overhead and latency in 3711 delivering packets to the mobile node. 3713 If the sender knows that the Binding Cache entry is still in active 3714 use, it MAY send a Binding Refresh Request message to the mobile node 3715 in an attempt to avoid this overhead and latency due to deleting and 3716 recreating the Binding Cache entry. The Binding Refresh Request 3717 message is sent in the same way as any packet addressed to the mobile 3718 node (Section 9.3.2). 3720 The correspondent node MAY retransmit Binding Refresh Request 3721 messages provided that rate limitation is applied. The correspondent 3722 node SHOULD stop retransmitting when it receives a Binding Update. 3724 9.6. Cache Replacement Policy 3726 Conceptually, a node maintains a separate timer for each entry in its 3727 Binding Cache. When creating or updating a Binding Cache entry in 3728 response to a received and accepted Binding Update, the node sets the 3729 timer for this entry to the specified Lifetime period. Any entry in 3730 a node's Binding Cache MUST be deleted after the expiration of the 3731 Lifetime specified in the Binding Update from which the entry was 3732 created or last updated. 3734 Each node's Binding Cache will, by necessity, have a finite size. 3735 A node MAY use any reasonable local policy for managing the space 3736 within its Binding Cache, except that any entry marked as a home 3737 registration (Section 10.3.1) MUST NOT be deleted from the cache 3738 until the expiration of its lifetime period. When such home 3739 registration entries are deleted, the home agent MUST also cease 3740 intercepting packets on the mobile node's home link addressed to 3741 the mobile node (Section 10.4.1), just as if the mobile node had 3742 de-registered its primary care-of address (see Section 10.3.2). 3744 When attempting to add a new home registration entry in response 3745 to a Binding Update with the Home Registration (H) bit set, if 3746 no sufficient space can be found, the home agent MUST reject the 3747 Binding Update. Furthermore, the home agent MUST return a Binding 3748 Acknowledgement to the sending mobile node, in which the Status field 3749 is set to 130 (insufficient resources). 3751 A node MAY choose to drop any entry already in its Binding Cache, 3752 other than home registration entries, in order to make space for 3753 a new entry. For example, a "least-recently used" (LRU) strategy 3754 for cache entry replacement among entries not marked as home 3755 registrations is likely to work well unless the size of the Binding 3756 Cache is substantially insufficient. 3758 If the node sends a packet to a destination for which it has dropped 3759 the entry from its Binding Cache, the packet will be routed through 3760 the mobile node's home link. The mobile node can detect this, and 3761 establish a new binding if necessary. 3763 10. Home Agent Operation 3765 10.1. Conceptual Data Structures 3767 Each home agent MUST maintain a Binding Cache and Home Agents List. 3769 The rules for maintaining a Binding Cache are same for home 3770 agents and correspondent nodes, and have already been described in 3771 Section 9.1. 3773 The Home Agents List is maintained by each home agent, recording 3774 information about each router on the same link which is acting as 3775 a home agent; this list is used by the dynamic home agent address 3776 discovery mechanism. A router is known to be acting as a home agent, 3777 if it sends a Router Advertisement in which the Home Agent (H) bit 3778 is set. When the lifetime for a list entry (defined below) expires, 3779 that entry is removed from the Home Agents List. The Home Agents 3780 List is thus similar to the Default Router List conceptual data 3781 structure maintained by each host for Neighbor Discovery [12]. The 3782 Home Agents List MAY be implemented in any manner consistent with the 3783 external behavior described in this document. 3785 Each home agent maintains a separate Home Agents List for each link 3786 on which it is serving as a home agent. A new entry is created or an 3787 existing entry is updated in response to receipt of a valid Router 3788 Advertisement in which the Home Agent (H) bit is set. Each Home 3789 Agents List entry conceptually contains the following fields: 3791 - The link-local IP address of a home agent on the link. This 3792 address is learned through the Source Address of the Router 3793 Advertisements received from the router [12]. 3795 - One or more global IP addresses for this home agent. Global 3796 addresses are learned through Prefix Information options with the 3797 Router Address (R) bit set, received in Router Advertisements 3798 from this link-local address. Global addresses for the router 3799 in a Home Agents List entry MUST be deleted once the prefix 3800 associated with that address is no longer valid [12]. 3802 - The remaining lifetime of this Home Agents List entry. If a Home 3803 Agent Information Option is present in a Router Advertisement 3804 received from a home agent, the lifetime of the Home Agents List 3805 entry representing that home agent is initialized from the Home 3806 Agent Lifetime field in the option; otherwise, the lifetime is 3807 initialized from the Router Lifetime field in the received Router 3808 Advertisement. If Home Agents List entry lifetime reaches zero, 3809 the entry MUST be deleted from the Home Agents List. 3811 - The preference for this home agent; higher values indicate a more 3812 preferable home agent. The preference value is taken from the 3813 Home Agent Preference field in the received Router Advertisement, 3814 if the Router Advertisement contains a Home Agent Information 3815 Option, and is otherwise set to the default value of 0. A home 3816 agent uses this preference in ordering the Home Agents List when 3817 it sends an ICMP Home Agent Address Discovery message. 3819 10.2. Processing Mobility Headers 3821 All IPv6 home agents MUST observe the rules described in Section 9.2 3822 when processing Mobility Headers. 3824 10.3. Processing Bindings 3826 10.3.1. Primary Care-of Address Registration 3828 When a node receives a Binding Update, it MUST validate it and 3829 determine the type of Binding Update according to the steps described 3830 in Section 9.5.1. Furthermore, it MUST authenticate the Binding 3831 Update as described in Section 5.1. This includes authorization of 3832 the particular node to control a particular home address, as the home 3833 address unequivocally identifies the security association that must 3834 be used. 3836 This section describes the processing of a valid and authorized 3837 Binding Update, when it requests the registration of the mobile 3838 node's primary care-of address. 3840 To begin processing the Binding Update, the home agent MUST perform 3841 the following sequence of tests: 3843 - If the node is not a router that implements home agent 3844 functionality, then the node MUST reject the Binding Update 3845 and MUST return a Binding Acknowledgement to the mobile node, 3846 in which the Status field is set to 131 (home registration not 3847 supported). 3849 - Else, if the home address for the binding (the Home Address field 3850 in the packet's Home Address option) is not an on-link IPv6 3851 address with respect to the home agent's current Prefix List, 3852 then the home agent MUST reject the Binding Update and SHOULD 3853 return a Binding Acknowledgement to the mobile node, in which the 3854 Status field is set to 132 (not home subnet). 3856 - Else, if the home agent chooses to reject the Binding Update for 3857 any other reason (e.g., insufficient resources to serve another 3858 mobile node as a home agent), then the home agent SHOULD return a 3859 Binding Acknowledgement to the mobile node, in which the Status 3860 field is set to an appropriate value to indicate the reason for 3861 the rejection. 3863 - A Home Address destination option MUST be present in the message. 3865 - Finally, if the Duplicate Address Detection (D) bit is set in the 3866 Binding Update, this home agent MUST perform Duplicate Address 3867 Detection [13] on the mobile node's home link for the link-local 3868 address associated with the home address in this binding, before 3869 returning the Binding Acknowledgement. This ensures that no 3870 other node on the home link was using the mobile node's home 3871 address when the Binding Update arrived. 3873 If home agent accepts the Binding Update, it MUST then create a 3874 new entry in its Binding Cache for this mobile node, or update its 3875 existing Binding Cache entry, if such an entry already exists. The 3876 Home Address field as received in the Home Address option provides 3877 the home address of the mobile node. 3879 The home agent MUST mark this Binding Cache entry as a home 3880 registration to indicate that the node is serving as a home agent for 3881 this binding. Binding Cache entries marked as a home registration 3882 MUST be excluded from the normal cache replacement policy used for 3883 the Binding Cache (Section 9.6) and MUST NOT be removed from the 3884 Binding Cache until the expiration of the Lifetime period. 3886 Normal processing for Duplicate Address Detection specifies that, in 3887 certain cases, the node SHOULD delay sending the initial Neighbor 3888 Solicitation of Duplicate Address Detection by a random delay 3889 between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13]. However, when 3890 the Duplicate Address Detection (D) bit instructs the home agent 3891 to perform Duplicate Address Detection, the home agent SHOULD NOT 3892 perform such a delay. If this Duplicate Address Detection fails, 3893 then the home agent MUST reject the Binding Update and MUST return a 3894 Binding Acknowledgement to the mobile node, in which the Status field 3895 is set to 134 (Duplicate Address Detection failed). When the home 3896 agent sends a successful Binding Acknowledgement to the mobile node, 3897 the home agent assures to the mobile node that its home address will 3898 continue to be kept unique by the home agent at least as long as the 3899 lifetime granted for that home address binding is not over. 3901 If the Single Address Only (S) bit in the Binding Update is zero, 3902 the home agent creates Binding Cache entries for each of possibly 3903 several home addresses. The set of such home addresses is formed 3904 by replacing the routing prefix for the given home address with 3905 all other routing prefixes on the mobile node's home link that are 3906 supported by the home agent processing the Binding Update. The home 3907 agent creates such a separate primary care-of address registration 3908 for each such home address. Note that the same considerations for 3909 Duplicate Address Detection apply for each affected home address. 3910 The value of the Single Address Only (S) bit field is examined only 3911 for new registrations. Its value is ignored on de-registrations and 3912 re-registrations of the same addresses. 3914 The specific addresses which are to be tested before accepting the 3915 Binding Update, and later to be defended by performing Duplicate 3916 Address Detection, depend on the settings of the Single Address Only 3917 (S) and Link-Local Address Compatibility (L) bits, as follows: 3919 - L=0: Defend the given address. The Single Address Only (S) bit 3920 is ignored in this case since we cannot derive other on-link 3921 addresses without knowing the interface identifier. 3923 - L=1 and S=0: Defend all non link-local unicast addresses 3924 possible on link and the derived link-local. 3926 - L=1 and S=1: Defend both the given non link-local unicast (home) 3927 address and the derived link-local. 3929 The lifetime of the Binding Cache entry depends on a number of 3930 factors: 3932 - The lifetime for the Binding Cache entry MUST NOT be greater than 3933 the Lifetime value specified in the Binding Update. 3935 - The lifetime for the Binding Cache entry MUST NOT be greater 3936 than the remaining valid lifetime for the subnet prefix in the 3937 mobile node's home address specified with the Binding Update. 3938 The remaining valid lifetime for this prefix is determined by 3939 the home agent based on its own Prefix List entry for this 3940 prefix [12]. 3942 - However, if the Single Address Only (S) bit field in the Binding 3943 Update is zero, the lifetime for that Binding Cache entry MUST 3944 NOT be greater than the minimum remaining valid lifetime for all 3945 subnet prefixes on the mobile node's home link. If the value of 3946 the Lifetime field specified by the mobile node in its Binding 3947 Update is greater than this prefix lifetime, the home agent MUST 3948 decrease the binding lifetime to less than or equal to the prefix 3949 valid lifetime. 3951 - The home agent MAY further decrease the specified lifetime for 3952 the binding, for example based on a local policy. The resulting 3953 lifetime is stored by the home agent in the Binding Cache entry, 3954 and this Binding Cache entry MUST be deleted by the home agent 3955 after the expiration of this lifetime. 3957 Regardless of the setting of the Acknowledge (A) bit in the Binding 3958 Update, the home agent MUST return a Binding Acknowledgement to the 3959 mobile node, constructed as follows: 3961 - The Status field MUST be set to a value 0, indicating success. 3963 - The Sequence Number field MUST be copied from the Sequence Number 3964 given in the Binding Update. 3966 - The Lifetime field MUST be set to the remaining lifetime for the 3967 binding as set by the home agent in its home registration Binding 3968 Cache entry for the mobile node, as described above. 3970 - If the home agent stores the Binding Cache entry in nonvolatile 3971 storage, then the Binding Refresh Advice mobility option MUST be 3972 omitted. Otherwise, the home agent MAY include this option to 3973 suggest that the mobile node refreshes its binding sooner than 3974 the actual lifetime of the binding ends. 3976 If the Binding Refresh Advice mobility option is present, the 3977 Refresh Interval field in the option MUST be set to a value less 3978 than the Lifetime value being returned in the Binding Update. 3979 This indicates that the mobile node SHOULD attempt to refresh its 3980 home registration at the indicated shorter interval. The home 3981 agent MUST still retain the registration for the Lifetime period, 3982 even if the mobile node does not refresh its registration within 3983 the Refresh period. 3985 The rules for selecting the Destination IP address (and possibly 3986 routing header construction) for the Binding Acknowledgement to the 3987 mobile node are the same as in Section 9.5.4. 3989 In addition, the home agent MUST follow the procedure defined in 3990 Section 10.4.1 to intercept packets on the mobile node's home link 3991 addressed to the mobile node, while the home agent is serving as 3992 the home agent for this mobile node. The home agent MUST also be 3993 prepared to accept reverse tunneled packets from the new care-of 3994 address of the mobile node, as described in Section 10.4.3. Finally, 3995 the home agent MUST also propagate new home network prefixes, as 3996 described in Section 10.6. 3998 10.3.2. Primary Care-of Address De-Registration 4000 A Binding Update is validated and authorized in the manner described 4001 in the previous section. This section describes the processing of a 4002 valid Binding Update that requests the receiving node to no longer 4003 serve as its home agent, de-registering its primary care-of address. 4005 To begin processing the Binding Update, the home agent MUST perform 4006 the following test: 4008 - If the receiving node has no entry marked as a home registration 4009 in its Binding Cache for this mobile node, then this node 4010 MUST reject the Binding Update and SHOULD return a Binding 4011 Acknowledgement to the mobile node, in which the Status field is 4012 set to 133 (not home agent for this mobile node). 4014 If the home agent does not reject the Binding Update as described 4015 above, then it MUST delete any existing entry in its Binding Cache 4016 for this mobile node. Then, the home agent MUST return a Binding 4017 Acknowledgement to the mobile node, constructed as follows: 4019 - The Status field MUST be set to a value 0, indicating success. 4021 - The Sequence Number field MUST be copied from the Sequence Number 4022 given in the Binding Update. 4024 - The Lifetime field MUST be set to zero. 4026 - The Binding Refresh Advice mobility option MUST be omitted. 4028 In addition, the home agent MUST stop intercepting packets on 4029 the mobile node's home link that are addressed to the mobile node 4030 (Section 10.4.1). 4032 The rules for selecting the Destination IP address (and, if required, 4033 routing header construction) for the Binding Acknowledgement to the 4034 mobile node are the same as in the previous section. When the Status 4035 field in the Binding Acknowledgement is greater than or equal to 128 4036 and the Source Address of the Binding Update is on the home link, the 4037 home agent MUST send it to the same link-layer address as the Binding 4038 Update came from. 4040 10.4. Packet Processing 4042 10.4.1. Intercepting Packets for a Mobile Node 4044 While a node is serving as the home agent for mobile node it MUST 4045 attempt to intercept packets on the mobile node's home link that are 4046 addressed to the mobile node, and MUST tunnel each intercepted packet 4047 to the mobile node using IPv6 encapsulation [15]. 4049 In order to do this, when a node begins serving as the home agent 4050 it MUST multicast onto the home link a Neighbor Advertisement 4051 message [12] on behalf of the mobile node. Specifically, the home 4052 agent performs the following steps: 4054 1. The home agent examines the value of the Single Address Only (S) 4055 bit in the received Binding Update. If this bit is nonzero, the 4056 next step is carried out only for the individual home address 4057 specified for this binding. If, instead, this bit is zero, then 4058 the next step is carried out for one address for each one of the 4059 subnet prefixes currently considered by the home agent to be 4060 on-link the mobile node. Each address is formed by replacing, 4061 in turn, the configured subnet prefix in the mobile node's home 4062 address. For this purpose, the set of on-link prefixes includes 4063 both the link-local and site-local prefix. 4065 2. For each specific IP address for the mobile node determined 4066 in the first step above, the home agent sends a Neighbor 4067 Advertisement message [12] to the all-nodes multicast address 4068 on the home link, to advertise the home agent's own link-layer 4069 address for this IP address on behalf of the mobile node. 4071 All fields in each such Neighbor Advertisement message SHOULD be 4072 set in the same way they would be set by the mobile node itself 4073 if sending this Neighbor Advertisement while at home [12], with 4074 the following exceptions: 4076 - The Target Address in the Neighbor Advertisement MUST be set 4077 to the specific IP address for the mobile node. 4079 - The Advertisement MUST include a Target Link-layer Address 4080 option specifying the home agent's link-layer address. 4082 - The Router (R) bit in the Advertisement MUST be set to zero. 4084 - The Solicited Flag (S) in the Advertisement MUST NOT be set, 4085 since it was not solicited by any Neighbor Solicitation. 4087 - The Override Flag (O) in the Advertisement MUST be set, 4088 indicating that the Advertisement SHOULD override any 4089 existing Neighbor Cache entry at any node receiving it. 4091 Any node on the home link receiving one of the Neighbor Advertisement 4092 messages described above will thus update its Neighbor Cache to 4093 associate the mobile node's address with the home agent's link 4094 layer address, causing it to transmit any future packets normally 4095 destined to the mobile node to the mobile node's home agent. Since 4096 multicasting on the local link (such as Ethernet) is typically 4097 not guaranteed to be reliable, the home agent MAY retransmit 4098 this Neighbor Advertisement message up to MAX_ADVERT_REXMIT (see 4099 Section 12) times to increase its reliability. It is still possible 4100 that some nodes on the home link will not receive any of these 4101 Neighbor Advertisements, but these nodes will eventually be able 4102 to detect the link-layer address change for the mobile node's home 4103 address, through use of Neighbor Unreachability Detection [12]. 4105 While a node is serving as a home agent for some mobile node, the 4106 home agent uses IPv6 Neighbor Discovery [12] to intercept unicast 4107 packets on the home link addressed to the mobile node's home address. 4108 In order to intercept packets in this way, the home agent MUST 4109 act as a proxy for this mobile node, and reply to any received 4110 Neighbor Solicitations for it. When a home agent receives a Neighbor 4111 Solicitation, it MUST check if the Target Address specified in the 4112 message matches the home address of any mobile node for which it 4113 has a Binding Cache entry marked as a home registration. Note that 4114 Binding Update with the Single Address Only (S) bit set to zero will 4115 result in multiple Binding Cache entries, so checks on all these 4116 entries necessarily include all possible home addresses for the 4117 mobile node. 4119 If such an entry exists in the home agent's Binding Cache, the 4120 home agent MUST reply to the Neighbor Solicitation with a Neighbor 4121 Advertisement, giving the home agent's own link-layer address as the 4122 link-layer address for the specified Target Address. In addition, 4123 the Router (R) bit in the Advertisement MUST be set to zero. Acting 4124 as a proxy in this way allows other nodes on the mobile node's home 4125 link to resolve the mobile node's IPv6 home address, and allows the 4126 home agent to defend these addresses on the home link for Duplicate 4127 Address Detection [12]. 4129 10.4.2. Tunneling Intercepted Packets to a Mobile Node 4131 For any packet sent to a mobile node from the mobile node's home 4132 agent (for which the home agent is the original sender of the 4133 packet), the home agent is operating as a correspondent node of 4134 the mobile node for this packet and the procedures described in 4135 Section 9.3.2 apply. The home agent then uses a routing header to 4136 route the packet to the mobile node by way of the primary care-of 4137 address in the home agent's Binding Cache. 4139 While the mobile node is away from home, the home agent intercepts 4140 any packets on the home link addressed to the mobile node's home 4141 address (including addresses formed from other on-link prefixes, if 4142 the Single Address Only (S) bit was zero in the Binding Update), as 4143 described in Section 10.4.1. In order to forward each intercepted 4144 packet to the mobile node, the home agent MUST tunnel the packet to 4145 the mobile node using IPv6 encapsulation [15]. When a home agent 4146 encapsulates an intercepted packet for forwarding to the mobile 4147 node, the home agent sets the Source Address in the new tunnel IP 4148 header to the home agent's own IP address, and sets the Destination 4149 Address in the tunnel IP header to the mobile node's primary care-of 4150 address. When received by the mobile node, normal processing of the 4151 tunnel header [15] will result in decapsulation and processing of the 4152 original packet by the mobile node. 4154 However, packets addressed to the mobile node's link-local address 4155 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 4156 be discarded, and the home agent SHOULD return an ICMP Destination 4157 Unreachable, Code 3, message to the packet's Source Address (unless 4158 this Source Address is a multicast address). Packets addressed to 4159 the mobile node's site-local address SHOULD be tunneled to the mobile 4160 node by default, but this behavior MUST be configurable to disable 4161 it; currently, the exact definition and semantics of a "site" and a 4162 site-local address are incompletely defined in IPv6, and this default 4163 behavior might change at some point in the future. 4165 Tunneling of multicast packets to a mobile node follows similar 4166 limitations to those defined above for unicast packets addressed to 4167 the mobile node's link-local and site-local addresses. Multicast 4168 packets addressed to a multicast address with link-local scope [3], 4169 to which the mobile node is subscribed, MUST NOT be tunneled 4170 to the mobile node; such packets SHOULD be silently discarded 4171 (after delivering to other local multicast recipients). Multicast 4172 packets addressed to a multicast address with scope larger 4173 than link-local but smaller than global (e.g., site-local and 4174 organization-local [3]), to which the mobile node is subscribed, 4175 SHOULD be tunneled to the mobile node by default. This behavior MUST 4176 be configurable to allow changing or disabling it. Note that this 4177 default behavior might change at some point in the future as the 4178 definition of these scopes become more completely defined in IPv6. 4180 Before tunneling a packet to the mobile node, the home agent MUST 4181 perform any IPsec processing as indicated by the security policy data 4182 base. 4184 10.4.3. Handling Reverse Tunneled Packets from a Mobile Node 4186 Unless a binding has been established between the mobile node and a 4187 correspondent node, traffic from the mobile node to the correspondent 4188 node goes through a reverse tunnel. Home agents MUST support reverse 4189 tunneling as follows: 4191 - The tunneled traffic arrives to the home agent using IPv6 4192 encapsulation [15]. 4194 - The tunnel entry point is the primary care-of address as 4195 registered with the home agent and the tunnel exit point is the 4196 home agent. 4198 - When a home agent decapsulates a tunneled packet from the mobile 4199 node, the home agent MUST verify that the Source Address in the 4200 tunnel IP header is the mobile node's primary care-of address. 4201 Otherwise any node in the Internet could send traffic through the 4202 home agent and escape ingress filtering limitations. 4204 Reverse tunneled packets MAY be discarded unless accompanied by a 4205 valid AH or ESP header, depending on the security policies used by 4206 the home agent. The support for authenticated reverse tunneling 4207 allows the home agent to protect the home network and correspondent 4208 nodes from malicious nodes masquerading as a mobile node, even if 4209 they know the current location of the real mobile node. 4211 10.4.4. Protecting Return Routability Packets 4213 The return routability procedure described in Section 5.2.5 assumes 4214 that the confidentiality of the Home Test Init and Home Test messages 4215 is protected as they are tunneled between the home agent to the 4216 mobile node. Therefore, the home agent MUST support tunnel mode 4217 IPsec ESP for the protection of packets belonging to the return 4218 routability procedure. Support for a non-null encryption transform 4219 and authentication algorithm MUST be available. It isn't necessary 4220 to distinguish between different kinds of packets within the return 4221 routability procedure. 4223 The security association between the home agent and the mobile node 4224 MUST change its destination address (tunnel gateway address) when the 4225 care-of address for the mobile node changes [24]. 4227 The above protection SHOULD be used with all mobile nodes. The use 4228 is controlled by configuration of the IPsec security policy database 4229 both at the mobile node and at the home agent. 4231 As described earlier, the Binding Update and Binding Acknowledgement 4232 messages require protection between the home agent and the mobile 4233 node. These messages and the return routability messages employ the 4234 same protocol from the point of view of the security policy database, 4235 the Mobility Header. The security policy database entries MUST be 4236 defined as if they were specifically for the tunnel interface between 4237 the mobile node and the home agent. That is, the policy entries are 4238 not generally applied on all traffic on the physical interface(s) of 4239 the nodes, but rather only on traffic that enters the tunnel. This 4240 makes use of per-interface security policy database entries [4], 4241 specific to the tunnel interface (the node's attachment to the 4242 tunnel [11]). 4244 10.5. Dynamic Home Agent Address Discovery 4246 This section describes how a home agent can help mobile nodes to 4247 discover the addresses of the home agents. The home agent keeps 4248 track of the other home agents on the same link, and responds to 4249 queries sent by the mobile node. 4251 10.5.1. Receiving Router Advertisement Messages 4253 For each link on which a router provides service as a home agent, 4254 the router maintains a Home Agents List recording information 4255 about all other home agents on that link. This list is used in 4256 the dynamic home agent address discovery mechanism, described in 4257 Section 10.5. The information for the list is learned through 4258 receipt of the periodic unsolicited multicast Router Advertisements, 4259 in a manner similar to the Default Router List conceptual data 4260 structure maintained by each host for Neighbor Discovery [12]. In 4261 the construction of the Home Agents List, the Router Advertisements 4262 are from each other home agent on the link, and the Home Agent (H) 4263 bit is set in them. 4265 On receipt of a valid Router Advertisement, as defined in the 4266 processing algorithm specified for Neighbor Discovery [12], the home 4267 agent performs the following steps, in addition to any steps already 4268 required of it by Neighbor Discovery: 4270 - If the Home Agent (H) bit in the Router Advertisement is not set, 4271 check to see if the sending node has an entry in the current Home 4272 Agents List. If it does, delete the corresponding entry. In any 4273 case all of the following steps are skipped. 4275 - Otherwise, extract the Source Address from the IP header of the 4276 Router Advertisement. This is the link-local IP address on this 4277 link of the home agent sending this Advertisement [12]. 4279 - Determine the preference for this home agent. If the Router 4280 Advertisement contains a Home Agent Information Option, then the 4281 preference is taken from the Home Agent Preference field in the 4282 option; otherwise, the default preference of 0 MUST be used. 4284 - Determine the lifetime for this home agent. If the Router 4285 Advertisement contains a Home Agent Information Option, then 4286 the lifetime is taken from the Home Agent Lifetime field in the 4287 option; otherwise, the lifetime specified by the Router Lifetime 4288 field in the Router Advertisement SHOULD be used. 4290 - If the link-local address of the home agent sending this 4291 Advertisement is already present in this home agent's Home 4292 Agents List and the received home agent lifetime value is zero, 4293 immediately delete this entry in the Home Agents List. 4295 - Otherwise, if the link-local address of the home agent sending 4296 this Advertisement is already present in the receiving home 4297 agent's Home Agents List, reset its lifetime and preference to 4298 the values determined above. 4300 - If the link-local address of the home agent sending this 4301 Advertisement is not already present in the Home Agents List 4302 maintained by the receiving home agent, and the lifetime for 4303 the sending home agent is non-zero, create a new entry in the 4304 list, and initialize its lifetime and preference to the values 4305 determined above. 4307 - If the Home Agents List entry for the link-local address of 4308 the home agent sending this Advertisement was not deleted as 4309 described above, determine any global address(es) of the home 4310 agent based on each Prefix Information option received in 4311 this Advertisement in which the Router Address (R) bit is set 4312 (Section 7.2). Add all such global addresses to the list of 4313 global addresses in this Home Agents List entry. 4315 A home agent SHOULD maintain an entry in its Home Agents List for 4316 each valid home agent address until that entry's lifetime expires, 4317 after which time the entry MUST be deleted. 4319 As described in Section 11.4.1, a mobile node attempts dynamic 4320 home agent address discovery by sending an ICMP Home Agent Address 4321 Discovery Request message to the Mobile IPv6 Home-Agents anycast 4322 address [16] for its home IP subnet prefix. A home agent receiving 4323 such a Home Agent Address Discovery Request message that is serving 4324 this subnet SHOULD return an ICMP Home Agent Address Discovery Reply 4325 message to the mobile node, with the Source Address of the Reply 4326 packet set to one of the global unicast addresses of the home agent. 4327 The Home Agent Addresses field in the Reply message is constructed as 4328 follows: 4330 - The Home Agent Addresses field SHOULD contain one global IP 4331 address for each home agent currently listed in this home agent's 4332 own Home Agents List (Section 10.1). However, if this home 4333 agent's own global IP address would be placed as the first entry 4334 in the list (as described below), then this home agent SHOULD NOT 4335 include its own address in the Home Agent Addresses field in the 4336 Reply message. Not placing this home agent's own IP address in 4337 the list will cause the receiving mobile node to consider this 4338 home agent as the most preferred home agent; otherwise, this home 4339 agent will be considered to be preferred in its order given by 4340 its place in the list returned. 4342 - The IP addresses in the Home Agent Addresses field SHOULD 4343 be listed in order of decreasing preference values, based 4344 either on the respective advertised preference from a Home 4345 Agent Information option or on the default preference of 0 if 4346 no preference is advertised (or on the configured home agent 4347 preference for this home agent itself). 4349 - Among home agents with equal preference, their IP addresses 4350 in the Home Agent Addresses field SHOULD be listed in an 4351 order randomized with respect to other home agents with equal 4352 preference, each time a Home Agent Address Discovery Reply 4353 message is returned by this home agent. 4355 - For each entry in this home agent's Home Agents List, if more 4356 than one global IP address is associated with this list entry, 4357 then one of these global IP addresses SHOULD be selected to 4358 include in the Home Agent Addresses field in the Reply message. 4360 The selected global IP address for each home agent to include in 4361 forming the Home Agent Addresses field in the Reply message MUST 4362 be the global IP address of the respective home agent sharing a 4363 prefix with the Destination IP address of the Request message. 4364 If no such global IP address is known for some home agent, an 4365 entry for that home agent MUST NOT be included in the Home Agent 4366 Addresses field in the Reply message. 4368 - The home agent SHOULD reduce the number of home agent IP 4369 addresses so that the packet fits within the minimum IPv6 4370 MTU [11]. The home agent addresses selected for inclusion in the 4371 packet SHOULD be those from the complete list with the highest 4372 preference. This limitation avoids the danger of the Reply 4373 message packet being fragmented (or rejected by an intermediate 4374 router with an ICMP Packet Too Big message [14]). 4376 - If the Reply message packet must be truncated to fit within the 4377 minimum IPv6 MTU, and the home agent sending the message is 4378 not the highest priority, then its address MUST appear in the 4379 list sent to avoid implying that it is the highest priority. 4380 Therefore, if this home agent would not appear in the truncated 4381 list because it is of lower priority than the last entry, this 4382 home agent's address must be substituted for the last entry. 4384 10.6. Sending Prefix Information to the Mobile Node 4386 10.6.1. Aggregate List of Home Network Prefixes 4388 Mobile IPv6 arranges to propagate relevant prefix information to the 4389 mobile node when it is away from home, so that it may be used in 4390 mobile node home address configuration, and in network renumbering. 4391 In this mechanism, mobile nodes away from home receive Mobile Prefix 4392 Advertisements messages with Prefix Information Options, which give 4393 the valid lifetime and preferred lifetime for available prefixes on 4394 the home link. 4396 A mobile node on a remote network SHOULD autoconfigure all of the 4397 global IP addresses, which it would autoconfigure if it were attached 4398 to its home network and which are from prefixes served by home 4399 agents. Site-local addresses MAY be autoconfigured if the mobile 4400 node is roaming in a network on the same site as its home addresses. 4401 Site-local addresses and addresses not served by a home agent MUST 4402 NOT be autoconfigured, since they are unusable in the remote network. 4404 To support this, the home agent monitors prefixes advertised by 4405 itself and other home agents routers on the home link, and passes 4406 this aggregated list of relevant subnet prefixes on to the mobile 4407 node in Mobile Prefix Advertisements. 4409 The home agent SHOULD construct the aggregate list of home subnet 4410 prefixes as follows: 4412 - Copy prefix information defined in the home agent's AdvPrefixList 4413 on the home subnet's interfaces to the aggregate list. Also 4414 apply any changes made to the AdvPrefixList on the home agent to 4415 the aggregate list. 4417 - Check valid prefixes received in Router Advertisements from the 4418 home network for consistency with the home agent's AdvPrefixList, 4419 as specified in Section 6.2.7 of RFC 2461 [12]. Do not update 4420 the aggregate list with any information from received prefixes 4421 that fail this check. 4423 - For Router Advertisements which have the Home Agent (H) bit 4424 set, check valid prefixes that are not yet in the aggregate 4425 list. If a Prefix Information option has the autonomous address 4426 configuration (A) flag set and the prefix length is valid 4427 for address autoconfiguration on the home subnet, add these 4428 advertisements and preserve the on-link (L) flag value. Clear 4429 the Router Address (R) flag and zero the interface-id portion of 4430 the prefix field to prevent mobile nodes from treating another 4431 router's interface address as belonging to the home agent. Treat 4432 the lifetimes of these prefixes as decrementing in real time, as 4433 defined in Section 6.2.7 of RFC 2461 [12]. 4435 - Do not perform consistency checks on valid prefixes received 4436 in Router Advertisements on the home network that do not exist 4437 in the home agent's AdvPrefixList. Instead, if the prefixes 4438 already exist in the aggregate list, update the prefix lifetime 4439 fields in the aggregate list according to the rules specified for 4440 hosts in Section 6.3.4 of RFC 2461 [12] and Section 5.5.3 of RFC 4441 2462 [13]. 4443 - If the L flag is set on valid prefixes received in a Router 4444 Advertisement, and that prefix already exists in the aggregate 4445 list, set the flag in the aggregate list. Ignore the flag if it 4446 is clear. 4448 - Delete prefixes from the aggregate list when their valid 4449 lifetimes expire. 4451 The home agent uses the information in the aggregate list to 4452 construct Mobile Prefix Advertisements. It may be possible to 4453 construct an aggregate list by combining information contained in the 4454 home agent's AdvPrefixList and its Home Agents List used for Dynamic 4455 Home Agent Address Discovery (Section 11.4.1). 4457 10.6.2. Scheduling Prefix Deliveries to the Mobile Node 4459 A home agent serving a mobile node will schedule the delivery of new 4460 prefix information to that mobile node when any of the following 4461 conditions occur: 4463 MUST: 4465 - The valid or preferred lifetime or the state of the flags changes 4466 for the prefix of the mobile node's registered home address. 4468 - The mobile node requests the information with a Mobile Prefix 4469 Solicitation (see Section 11.4.2). 4471 MAY: 4473 - A new prefix is added to the aggregate list. 4475 - The valid or preferred lifetime or the state of the flags changes 4476 for a prefix which is not used in any Binding Cache entry for 4477 this mobile node. 4479 The home agent uses the following algorithm to determine when to send 4480 prefix information to the mobile node. 4482 - If the mobile node has not received the prefix information within 4483 the last HomeRtrAdvInterval (see Section 12) seconds, then 4484 transmit the prefix information. This MAY be done according to a 4485 periodically scheduled transmission. 4487 - If a mobile node sends a solicitation, answer right away. 4489 - If a prefix in the aggregate list that matches the mobile node's 4490 home registration is added, or if its information changes in 4491 any way that does not cause the mobile node's address to go 4492 deprecated, ensure that a transmission is scheduled (as described 4493 below), and calculate RAND_ADV_DELAY in order to randomize the 4494 time at which the transmission is scheduled. 4496 - If a home registration expires, cancel any scheduled 4497 advertisements to the mobile node. 4499 The aggregate list is sent in its entirety in all cases. 4501 Suppose that the home agent already has scheduled the transmission 4502 of a Mobile Prefix Advertisement to the mobile node. The home agent 4503 deletes the previously scheduled transmission event and schedules 4504 another advertisement to the mobile node. 4506 Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY, 4507 the offset from the current time for the scheduled transmission 4508 as follows. First calculate the maximum delay for the scheduled 4509 Advertisement: 4511 MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime), 4513 where MaxMobPfxAdvInterval is as defined in Section 12. Then compute 4514 the final delay for the advertisement: 4516 RAND_ADV_DELAY = MinMobPfxAdvInterval + 4517 (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval)) 4519 This computation is expected to alleviate bursts of advertisements 4520 when prefix information changes. In addition, a home agent MAY 4521 further reduce the rate of packet transmission by further delaying 4522 individual advertisements, if needed to avoid overwhelming local 4523 network resources. The home agent SHOULD periodically continue to 4524 retransmit an unsolicited Advertisement to the mobile node, until it 4525 is acknowledged by the receipt of a Mobile Prefix Solicitation from 4526 the mobile node. 4528 The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12) 4529 before the first retransmission, and double the retransmission wait 4530 time for every succeeding retransmission, up until a maximum of 4531 PREFIX_ADV_RETRIES attempts (see Section 12). If the mobile node's 4532 bindings expire before the matching Binding Update has been received, 4533 then the home agent MUST NOT attempt any more retransmissions, even 4534 if not all PREFIX_ADV_RETRIES have been retransmitted. If the 4535 mobile node sends another Binding Update without returning home in 4536 the meantime, the home agent SHOULD again begin transmitting the 4537 unsolicited Advertisement. 4539 If some condition as described above occurs on the home link causes 4540 another Prefix Advertisement to be sent to the mobile node, before 4541 the mobile node acknowledges a previous transmission the home agent 4542 SHOULD combine any Prefix Information options in the unacknowledged 4543 Mobile Prefix Advertisement into a new Advertisement. The home agent 4544 discards the old Advertisement. 4546 10.6.3. Sending Advertisements to the Mobile Node 4548 When sending a Mobile Prefix Advertisement to the mobile node, the 4549 home agent MUST construct the packet as follows: 4551 - The Source Address in the packet's IPv6 header MUST be set to 4552 the home agent's IP address to which the mobile node addressed 4553 its current home registration, or its default global home agent 4554 address if no binding exists. 4556 - If the advertisement was solicited, it MUST be destined to the 4557 source address of the solicitation. If it was triggered by 4558 prefix changes or renumbering, the advertisement's destination 4559 will be the mobile node's home address in the binding which 4560 triggered the rule. 4562 - A type 2 routing header MUST be included with the mobile node's 4563 home address. 4565 - IPsec headers SHOULD be supported and used. 4567 - The home agent MUST send the packet as it would any other unicast 4568 IPv6 packet that it originates. 4570 10.6.4. Lifetimes for Changed Prefixes 4572 As described in Section 10.3.1, the lifetime returned by the home 4573 agent in a Binding Acknowledgement MUST be no greater than the 4574 remaining valid lifetime for the subnet prefix in the mobile node's 4575 home address. This limit on the binding lifetime serves to prohibit 4576 use of a mobile node's home address after it becomes invalid. 4578 11. Mobile Node Operation 4580 11.1. Conceptual Data Structures 4582 Each mobile node MUST maintain a Binding Update List. 4584 The Binding Update List records information for each Binding Update 4585 sent by this mobile node, for which the Lifetime sent in that 4586 Binding Update has not yet expired. The Binding Update List includes 4587 all bindings sent by the mobile node either to its home agent or 4588 correspondent nodes. It also contains Binding Updates which are 4589 waiting for the completion of the return routability procedure before 4590 they can be sent. However, for multiple Binding Updates sent to 4591 the same destination address, the Binding Update List contains only 4592 the most recent Binding Update (i.e., with the greatest Sequence 4593 Number value) sent to that destination. The Binding Update List MAY 4594 be implemented in any manner consistent with the external behavior 4595 described in this document. 4597 Each Binding Update List entry conceptually contains the following 4598 fields: 4600 - The IP address of the node to which a Binding Update was sent. 4601 If the Binding Update was successfully received by that node 4602 (e.g., not lost by the network), a Binding Cache entry may have 4603 been created or updated based on this Binding Update. The 4604 Binding Cache entry may still exist, if that node has not deleted 4605 the entry before its expiration for some reason. 4607 - The home address for which that Binding Update was sent. 4609 - The care-of address sent in that Binding Update. This value 4610 is necessary for the mobile node to determine if it has sent a 4611 Binding Update giving its new care-of address to this destination 4612 after changing its care-of address. 4614 - The initial value of the Lifetime field sent in that Binding 4615 Update. 4617 - The remaining lifetime of that binding. This lifetime is 4618 initialized from the Lifetime value sent in the Binding Update 4619 and is decremented until it reaches zero, at which time this 4620 entry MUST be deleted from the Binding Update List. 4622 - The maximum value of the Sequence Number field sent in previous 4623 Binding Updates to this destination. The Sequence Number field 4624 is 16 bits long, and all comparisons between Sequence Number 4625 values MUST be performed modulo 2**16 (see Section 9.5.1). 4627 - The time at which a Binding Update was last sent to this 4628 destination, as needed to implement the rate limiting restriction 4629 for sending Binding Updates. 4631 - The state of any retransmissions needed for this Binding Update, 4632 if the Acknowledge (A) bit was set in this Binding Update. This 4633 state includes the time remaining until the next retransmission 4634 attempt for the Binding Update, and the current state of the 4635 exponential back-off mechanism for retransmissions. 4637 - A flag specifying whether or not future Binding Updates should 4638 be sent to this destination. The mobile node sets this flag 4639 in the Binding Update List entry when it receives an ICMP 4640 Parameter Problem, Code 1, error message in response to a return 4641 routability message or Binding Update sent to that destination, 4642 as described in Section 11.3.4. 4644 The Binding Update list also conceptually contains the following data 4645 related to running the return routability procedure. This data is 4646 relevant only for Binding Updates sent to correspondent nodes. 4648 - The time at which a Home Test Init or Care-of Test Init message 4649 was last sent to this destination, as needed to implement the 4650 rate limiting restriction for the return routability procedure. 4652 - The state of any retransmissions needed for this return 4653 routability procedure. This state includes the time remaining 4654 until the next retransmission attempt and the current state of 4655 the exponential back-off mechanism for retransmissions. 4657 - Cookie values used the Home Test Init and Care-of Test Init 4658 messages. 4660 - Home and care-of keygen tokens received from the correspondent 4661 node. 4663 - Home and care-of nonce indices received from the correspondent 4664 node. 4666 - The time at which each of the tokens and nonces was received 4667 from this correspondent node, as needed to implement reuse while 4668 moving. 4670 11.2. Processing Mobility Headers 4672 All IPv6 mobile nodes MUST observe the rules described in Section 9.2 4673 when processing Mobility Headers. 4675 11.3. Packet Processing 4677 11.3.1. Sending Packets While Away from Home 4679 While a mobile node is away from home, it continues to use its home 4680 address, as well as also using one or more care-of addresses. When 4681 sending a packet while away from home, a mobile node MAY choose among 4682 these in selecting the address that it will use as the source of the 4683 packet, as follows: 4685 - Protocols layered over IP will generally treat the mobile node's 4686 home address as its IP address for most packets. For packets 4687 sent that are part of transport-level connections established 4688 while the mobile node was at home, the mobile node MUST use 4689 its home address. Likewise, for packets sent that are part of 4690 transport-level connections that the mobile node may still be 4691 using after moving to a new location, the mobile node SHOULD use 4692 its home address in this way. If a binding exists, the mobile 4693 node SHOULD send the packets directly to the correspondent node. 4694 Otherwise, if a binding does not exist, the mobile node MUST use 4695 reverse tunneling. Detailed operation for both of these cases is 4696 described later in this section. 4698 - The mobile node MAY choose to directly use one of its care-of 4699 addresses as the source of the packet, not requiring the use 4700 of a Home Address option in the packet. This is particularly 4701 useful for short-term communication that may easily be retried 4702 if it fails. An example of this type of communication might 4703 be DNS queries sent by the mobile node [27, 28]. Using the 4704 mobile node's care-of address as the source for such queries will 4705 generally have a lower overhead than using the mobile node's 4706 home address, since no extra options need be used in either 4707 the query or its reply. Such packets can be routed normally, 4708 directly between their source and destination without relying 4709 on Mobile IPv6. If application running on the mobile node has 4710 no particular knowledge that the communication being sent fits 4711 within this general type of communication, however, the mobile 4712 node SHOULD NOT use its care-of address as the source of the 4713 packet in this way. 4715 The mobile node may send packets to the correspondent node 4716 that includes the home address destination option directly 4717 to the correspondent node only if the mobile node is aware 4718 that the correspondent node already has a Binding Cache entry 4719 for the mobile node's home address. Section 9.3.1 specifies 4720 the rules for Home Address Destination Option Processing at a 4721 correspondent node. The mobile node needs to ensure that there 4722 exists a Binding Cache entry for its home address so that the 4723 correspondent node can process the packet. 4725 - While not at its home link, the mobile node MUST NOT use its home 4726 address (or the home address destination option) in Neighbor 4727 Discovery messages on the visited link. The mobile node also 4728 MUST NOT use its home address when communicating with link-local 4729 or site-local peers on the visited link, if the scope of the home 4730 address is larger than the scope of the peer's address. 4732 For packets sent by a mobile node while it is at home, no special 4733 Mobile IPv6 processing is required. Likewise, if the mobile 4734 node uses any address other than any of its home addresses as the 4735 source of a packet sent while away from home no special Mobile IPv6 4736 processing is required. In either case, the packet is simply 4737 addressed and transmitted in the same way as any normal IPv6 packet. 4739 For packets sent by the mobile node sent while away from home using 4740 the mobile node's home address as the source, special Mobile IPv6 4741 processing of the packet is required. This can be done in the 4742 following two ways: 4744 direct delivery 4746 This is manner of delivering packets does not require going 4747 through the home network, and typically will enable faster and 4748 more reliable transmission. A mobile node SHOULD arrange to 4749 supply the home address in a Home Address option, and allowing 4750 the IPv6 header's Source Address field to be set to one of the 4751 mobile node's care-of addresses; the correspondent node will 4752 then use the address supplied in the Home Address option to 4753 serve the function traditionally done by the Source IP address 4754 in the IPv6 header. The mobile node's home address is then 4755 supplied to higher protocol layers and applications. 4757 Specifically: 4759 - Construct the packet using the mobile node's home address 4760 as the packet's Source Address, in the same way as if the 4761 mobile node were at home. This includes the calculation of 4762 upper layer checksums using the home address as the value 4763 of the source. 4765 - Insert a Home Address option into the packet, with the Home 4766 Address field copied from the original value of the Source 4767 Address field in the packet. 4769 - Change the Source Address field in the packet's IPv6 header 4770 to one of the mobile node's care-of addresses. This will 4771 typically be the mobile node's current primary care-of 4772 address, but MUST be a care-of address with a subnet prefix 4773 that is on-link on the network interface on which the 4774 mobile node will transmit the packet. 4776 By using the care-of address as the Source Address in the IPv6 4777 header, with the mobile node's home address instead in the Home 4778 Address option, the packet will be able to safely pass through 4779 any router implementing ingress filtering [23]. 4781 reverse tunneling 4783 This is the mechanism which tunnels the packets via the home 4784 agent. It isn't as efficient as the above mechanism, but is 4785 needed if there is no binding yet with the correspondent node. 4786 Specifically: 4788 - The packet is sent to the home agent using IPv6 4789 encapsulation [15]. 4791 - The Source Address in the tunnel packet is the primary 4792 care-of address as registered with the home agent. 4794 - The Destination Address in the tunnel packet is the home 4795 agent's address. 4797 Reverse tunneled packets MAY be protected using a AH or ESP 4798 header, depending on the security policies used by the home 4799 agent. The support for encrypted reverse tunneling allows 4800 mobile nodes to defeat certain kinds of traffic analysis, and 4801 provides a mechanism by which routers on the home network can 4802 distinguish authorized traffic from other possibly malicious 4803 traffic. 4805 11.3.2. Interaction with Outbound IPsec Processing 4807 This section sketches the interaction between outbound Mobile 4808 IPv6 processing and outbound IP Security (IPsec) processing for 4809 packets sent by a mobile node while away from home. Any specific 4810 implementation MAY use algorithms and data structures other than 4811 those suggested here, but its processing MUST be consistent with the 4812 effect of the operation described here and with the relevant IPsec 4813 specifications. In the steps described below, it is assumed that 4814 IPsec is being used in transport mode [4] and that the mobile node is 4815 using its home address as the source for the packet (from the point 4816 of view of higher protocol layers or applications, as described in 4817 Section 11.3.1): 4819 - The packet is created by higher layer protocols and applications 4820 (e.g., by TCP) as if the mobile node were at home and Mobile IPv6 4821 were not being used. 4823 - As part of outbound packet processing in IP, the packet is 4824 compared against the IPsec security policy database to determine 4825 what processing is required for the packet [4]. 4827 - If IPsec processing is required, the packet is either mapped to 4828 an existing Security Association (or SA bundle), or a new SA (or 4829 SA bundle) is created for the packet, according to the procedures 4830 defined for IPsec. 4832 - Since the mobile node is away from home, the mobile is either 4833 using reverse tunneling or route optimization to reach the 4834 correspondent node. 4836 If reverse tunneling is used, the packet is constructed in the 4837 normal manner and then tunneled through the home agent. 4839 If route optimization is in use, the mobile node inserts a Home 4840 Address destination option into the packet, replacing the Source 4841 Address in the packet's IP header with a care-of address suitable 4842 for the link on which the packet is being sent, as described in 4843 Section 11.3.1. The Destination Options header in which the 4844 Home Address destination option is inserted MUST appear in the 4845 packet after the routing header, if present, and before the IPsec 4846 (AH [5] or ESP [6]) header, so that the Home Address destination 4847 option is processed by the destination node before the IPsec 4848 header is processed. 4850 Finally, once the packet is fully assembled, the necessary IPsec 4851 authentication (and encryption, if required) processing is 4852 performed on the packet, initializing the Authentication Data in 4853 the IPsec header. The AH authentication data MUST be calculated 4854 as if the following were true: 4856 * the IPv6 source address in the IPv6 header contains the 4857 mobile node's home address, 4859 * the Home Address field of the Home Address destination option 4860 (Section 6.3) contains the new care-of address. 4862 - This allows, but does not require, the receiver of the packet 4863 containing a Home Address destination option to exchange the two 4864 fields of the incoming packet, simplifying processing for all 4865 subsequent packet headers. However, such an exchange is not 4866 required, as long as the result of the authentication calculation 4867 remains the same. 4869 When an automated key management protocol is used to create new 4870 security associations towards a peer, it is important to ensure that 4871 the peer can send the key management protocol packets to the mobile 4872 node. This may not be possible if the peer is the home agent of the 4873 mobile node, and the purpose of the security associations would be to 4874 send a Binding Update to the home agent. Packets addressed to the 4875 home address of the mobile node cannot be used before the Binding 4876 Update has been processed. For the default case of using IKE as 4877 the automated key management protocol [9, 4], such problems can be 4878 avoided by the following requirements: 4880 - When the mobile node is away from home, it MUST use its care-of 4881 address as the Source Address of all packets it sends as part of 4882 the key management protocol (without use of Mobile IPv6 for these 4883 packets, as suggested in Section 11.3.1). 4885 - In addition, for all security associations bound to the mobile 4886 node's home address established by IKE, the mobile node MUST 4887 include an ISAKMP Identification Payload [8] in the IKE exchange, 4888 giving the mobile node's home address as the initiator of the 4889 Security Association [7]. 4891 11.3.3. Receiving Packets While Away from Home 4893 While away from home, a mobile node will receive packets addressed to 4894 its home address, by one of three methods: 4896 - Packets sent by a correspondent node that does not have a Binding 4897 Cache entry for the mobile node, will be tunneled to the mobile 4898 node via its home agent. 4900 - Packets sent by a correspondent node that has a Binding Cache 4901 entry for the mobile node that contains the mobile node's current 4902 care-of address, will be sent by the correspondent node using 4903 a type 2 routing header. The packet will be addressed to the 4904 mobile node's care-of address, with the final hop in the routing 4905 header directing the packet to the mobile node's home address; 4906 the processing of this last hop of the routing header is entirely 4907 internal to the mobile node, since the care-of address and home 4908 address are both addresses within the mobile node. 4910 For packets received by the first of these methods, the mobile node 4911 MUST check that the IPv6 source address of the tunneled packet is the 4912 IP address of its home agent. 4914 For packets received by either the first or last of these three 4915 methods, the mobile node SHOULD send a Binding Update to the original 4916 sender of the packet, as described in Section 11.7.2, subject to 4917 the rate limiting defined in Section 11.8. The mobile node MUST 4918 also process the received packet in the manner defined for IPv6 4919 encapsulation [15], which will result in the encapsulated (inner) 4920 packet being processed normally by upper-layer protocols within the 4921 mobile node, as if it had been addressed (only) to the mobile node's 4922 home address. 4924 For packets received by the second method above (using a type 2 4925 routing header), the following rules will result in the packet being 4926 processed normally by upper-layer protocols within the mobile node, 4927 as if it had been addressed to the mobile node's home address. 4929 A node receiving a packet addressed to itself (i.e., one of the 4930 node's addresses is in the IPv6 destination field) follows the next 4931 header chain of headers and processes them. When it encounters 4932 a type 2 routing header during this processing it performs the 4933 following checks. If any of these checks fail the node MUST silently 4934 discard the packet. 4936 - The length field in the routing header is exactly 2. 4938 - The segments left field in the routing header is either 0 or 1. 4939 (Values on the wire are always 1. But implementations may 4940 process the routing header so that the value may become 0 after 4941 the routing header has been processed, but before the rest of the 4942 packet is processed.) 4944 - The Home Address field in the routing header is one of the node's 4945 home addresses, if the segments left field was 1. Thus, in 4946 particular the address field is required to be a unicast routable 4947 address. 4949 Once the above checks have been performed, the node swaps the 4950 IPv6 destination field with the Home Address field in the routing 4951 header, decrements segments left, and resubmits the packet to IP 4952 for processing the next header. Conceptually this follows the same 4953 model as in RFC 2460. However, in the case of type 2 routing header 4954 this can be simplified since it is known that the packet will not be 4955 forwarded to a different node. 4957 The definition of AH requires the sender to calculate the AH 4958 integrity check value of a routing header in a way as it appears in 4959 the receiver after it has processed the header. Since IPsec headers 4960 follow the routing header, any IPsec processing will operate on 4961 the packet with the home address in the IP destination field and 4962 segments left being zero. Thus, the AH calculations at the sender 4963 and receiver will have an identical view of the packet. 4965 11.3.4. Receiving ICMP Error Messages 4967 Any node that doesn't recognize the Mobility header will return an 4968 ICMP Parameter Problem, Code 1, message to the sender of the packet. 4969 If the mobile node receives such an ICMP error message in response to 4970 a return routability procedure or Binding Update, it SHOULD record 4971 in its Binding Update List that future Binding Updates SHOULD NOT be 4972 sent to this destination. 4974 Correspondent nodes who have participated in the return routability 4975 procedure MUST implement the ability to correctly process received 4976 packets containing a Home Address destination option. Therefore, 4977 correctly implemented correspondent nodes should always be able to 4978 recognize Home Address options. If a mobile node receives an ICMP 4979 Parameter Problem, Code 2, message from some node indicating that it 4980 does not support the Home Address option, the mobile node SHOULD log 4981 the error and then discard the ICMP message. 4983 11.3.5. Routing Multicast Packets 4985 A mobile node that is connected to its home link functions in the 4986 same way as any other (stationary) node. Thus, when it is at home, 4987 a mobile node functions identically to other multicast senders and 4988 receivers. This section therefore describes the behavior of a mobile 4989 node that is not on its home link. 4991 In order to receive packets sent to some multicast group, a mobile 4992 node must join that multicast group. One method by which a mobile 4993 node MAY join the group is via a (local) multicast router on the 4994 foreign link being visited. The mobile node SHOULD use one of its 4995 care-of addresses that shares a subnet prefix with the multicast 4996 router, as the source IPv6 address of its multicast group membership 4997 control messages. The mobile node MUST NOT use the Home Address 4998 destination option when sending MLD packets [29] 5000 Alternatively, a mobile node MAY join multicast groups via a 5001 bi-directional tunnel to its home agent. The mobile node tunnels its 5002 multicast group membership control packets to its home agent, and the 5003 home agent forwards multicast packets down the tunnel to the mobile 5004 node. 5006 A mobile node that wishes to send packets to a multicast group also 5007 has two options: 5009 1. Send directly on the foreign link being visited. 5011 The application is aware of the care-of address and uses it for 5012 multicast traffic just like any other stationary address. The 5013 mobile node MUST NOT use Home Address destination option in such 5014 traffic. 5016 2. Send via a tunnel to its home agent. 5018 Because multicast routing in general depends upon the Source 5019 Address used in the IPv6 header of the multicast packet, a mobile 5020 node that tunnels a multicast packet to its home agent MUST 5021 use its home address as the IPv6 Source Address of the inner 5022 multicast packet. 5024 Note that direct sending from the foreign link is only applicable 5025 while the mobile node is at that foreign link. This is because the 5026 associated multicast tree is specific to that source location and 5027 any change of location and source address will invalidate the source 5028 specific tree or branch and the application context of the other 5029 multicast group members. 5031 This specification does not provide mechanisms to enable such local 5032 multicast session to survive hand-off, and to seamlessly continue 5033 from a new CCoA on each new foreign link. Any such mechanism, 5034 developed as an extension to this specification, needs to take into 5035 account the impact of fast moving mobile nodes on the Internet 5036 multicast routing protocols and their ability to maintain the 5037 integrity of source specific multicast trees and branches. 5039 While the use of reverse tunnelling can ensure that multicast trees 5040 are independent of the mobile nodes movement, in some case such 5041 tunnelling can have adverse affects. The latency of specific types 5042 of multicast applications such as multicast based discovery protocols 5043 will be affected when the round-trip time between the foreign subnet 5044 and the home agent is significant compared to that of the topology to 5045 be discovered. In addition, the delivery tree from the home agent in 5046 such circumstances relies on unicast encapsulation from the agent to 5047 the mobile node and is therefore bandwidth inefficient compared to 5048 the native multicast forwarding in the foreign multicast system. 5050 11.4. Home Agent and Prefix Management 5052 11.4.1. Dynamic Home Agent Address Discovery 5054 Sometimes, when the mobile node needs to send a Binding Update to its 5055 home agent to register its new primary care-of address, as described 5056 in Section 11.7.1, the mobile node may not know the address of any 5057 router on its home link that can serve as a home agent for it. For 5058 example, some nodes on its home link may have been reconfigured while 5059 the mobile node has been away from home, such that the router that 5060 was operating as the mobile node's home agent has been replaced by a 5061 different router serving this role. 5063 In this case, the mobile node MAY attempt to discover the address of 5064 a suitable home agent on its home link. To do so, the mobile node 5065 sends an ICMP Home Agent Address Discovery Request message to the 5066 Mobile IPv6 Home-Agents anycast address [16] for its home subnet 5067 prefix. As described in Section 10.5, the home agent on its home 5068 link that receives this Request message will return an ICMP Home 5069 Agent Address Discovery Reply message, giving this home agent's own 5070 global unicast IP address along with a list of the global unicast IP 5071 address of each other home agent operating on the home link. 5073 The mobile node, upon receiving this Home Agent Address Discovery 5074 Reply message, MAY then send its home registration Binding Update to 5075 the home agent address given as the IP Source Address of the packet 5076 carrying the Reply message or to any of the unicast IP addresses 5077 listed in the Home Agent Addresses field in the Reply. For example, 5078 if necessary, the mobile node MAY attempt its home registration 5079 with each of these home agents, in turn, by sending each a Binding 5080 Update and waiting for the matching Binding Acknowledgement, until 5081 its registration is accepted by one of these home agents. The mobile 5082 node MUST, however, wait at least 1.5 times longer than (RetransTimer 5083 * DupAddrDetectTransmits) before sending a Binding Update to the next 5084 home agent. In trying each of the returned home agent addresses, the 5085 mobile node SHOULD try each in the order listed in the Home Agent 5086 Addresses field in the received Home Agent Address Discovery Reply 5087 message. If the home agent identified by the Source Address field in 5088 the IP header of the packet carrying the Home Agent Address Discovery 5089 Reply message is not listed in the Home Agent Addresses field in the 5090 Reply, it SHOULD be tried before the first address given in the list; 5091 otherwise, it SHOULD be tried in its listed order. 5093 If the mobile node has a current registration with some home agent 5094 on its home link (the Lifetime for that registration has not yet 5095 expired), then the mobile node MUST attempt any new registration 5096 first with that home agent. If that registration attempt fails 5097 (e.g., times out or is rejected), the mobile node SHOULD then 5098 reattempt this registration with another home agent on its home link. 5099 If the mobile node knows of no other suitable home agent, then it MAY 5100 attempt the dynamic home agent address discovery mechanism described 5101 above. 5103 If, after a mobile node transmits a Home Agent Address Discovery 5104 Request message to the Home Agents Anycast address, it does not 5105 receive a corresponding Home Agent Address Discovery Reply message 5106 within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile 5107 node MAY retransmit the same Request message to the same anycast 5108 address. This retransmission MAY be repeated up to a maximum of 5109 DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be 5110 delayed by twice the time interval of the previous retransmission. 5112 11.4.2. Sending Mobile Prefix Solicitations 5114 When a mobile node has a home address that is about to become 5115 invalid, it sends a Mobile Prefix Solicitation to its home agent 5116 in an attempt to acquire fresh routing prefix information. The 5117 new information also enables the mobile node to participate in 5118 renumbering operations affecting the home network, as described in 5119 Section 10.6. 5121 The mobile node MUST use the Home Address destination option to carry 5122 its home address and SHOULD use IPsec to protect the solicitation. 5124 The mobile node SHOULD send a Solicitation to the home agent when 5125 its home address will become invalid within MaxRtrAdvInterval 5126 seconds, where this value is acquired in a previous Mobile Prefix 5127 Advertisement from the home agent. If no such value is known, the 5128 value MAX_PFX_ADV_DELAY seconds is used instead (see Section 12). 5130 This solicitation follows the same retransmission rules specified for 5131 Router Solicitations [12], except that the initial retransmission 5132 interval is specified to be INITIAL_SOLICIT_TIMER (see Section 12). 5134 As described in Section 11.7.2, Binding Updates sent by the mobile 5135 node to other nodes MUST use a lifetime no greater than the remaining 5136 lifetime of its home registration of its primary care-of address. 5137 The mobile node SHOULD further limit the lifetimes that it sends on 5138 any Binding Updates to be within the remaining valid lifetime (see 5139 Section 10.6.2) for the prefix in its home address. 5141 When the lifetime for a changed prefix decreases, and the change 5142 would cause cached bindings at correspondent nodes in the Binding 5143 Update List to be stored past the newly shortened lifetime, the 5144 mobile node MUST issue a Binding Update to all such correspondent 5145 nodes. 5147 These limits on the binding lifetime serve to prohibit use of a 5148 mobile node's home address after it becomes invalid. 5150 11.4.3. Receiving Mobile Prefix Advertisements 5152 Section 10.6 describes the operation of a home agent to support boot 5153 time configuration and renumbering a mobile node's home subnet while 5154 the mobile node is away from home. The home agent sends Mobile 5155 Prefix Advertisements to the mobile node while away from home, giving 5156 "important" Prefix Information options that describe changes in the 5157 prefixes in use on the mobile node's home link. 5159 The Mobile Prefix Solicitation is similar to the Router Solicitation 5160 used in Neighbor Discovery [12], except it is routed from the mobile 5161 node on the visited network to the home agent on the home network by 5162 usual unicast routing rules. 5164 When a mobile node receives a Mobile Prefix Advertisement, it MUST 5165 validate it according to the following test: 5167 - The Source Address of the IP packet carrying the Mobile Prefix 5168 Advertisement is the same as the home agent address to which 5169 the mobile node last sent an accepted home registration Binding 5170 Update to register its primary care-of address. Otherwise, if 5171 no such registrations have been made, it SHOULD be the mobile 5172 node's stored home agent address, if one exists. Otherwise, if 5173 the mobile node has not yet discovered its home agent's address, 5174 it MUST NOT accept Mobile Prefix Advertisements. 5176 - The packet MUST have a type 2 routing header and SHOULD be 5177 protected by an IPsec header as described in Sections 5.4 5178 and 6.8. 5180 Any received Mobile Prefix Advertisement not meeting this test MUST 5181 be silently discarded. For advertisements that do not contain the 5182 same ICMP Identifier value as in a recently sent solicitation, the 5183 mobile node MUST send a solicitation and expect an advertisement with 5184 a matching Identifier before further processing. 5186 For an accepted Mobile Prefix Advertisement, the mobile node MUST 5187 process the Prefix Information Options as if they arrived in a 5188 Router Advertisement on the mobile node's home link [12]. Such 5189 processing may result in the mobile node configuring a new home 5190 address, although due to separation between preferred lifetime and 5191 valid lifetime, such changes should not affect most communication 5192 by the mobile node, in the same way as for nodes that are at home. 5193 In this case, the mobile node MUST return a Binding Update, which 5194 will be viewed by the home agent as an acknowledgement of the 5195 corresponding Mobile Prefix Advertisement, which it can cease 5196 transmitting. In addition, if the method used for this new home 5197 address configuration would require the mobile node to perform 5198 Duplicate Address Detection [13] for the new address if the mobile 5199 node were located at home, then the mobile node MUST set the 5200 Duplicate Address Detection (D) bit in this Binding Update to its 5201 home agent, to request the home agent to perform this Duplicate 5202 Address Detection on behalf of the mobile node. 5204 11.5. Movement 5206 11.5.1. Movement Detection 5208 The primary movement detection mechanism for Mobile IPv6 defined 5209 in this section uses the facilities of IPv6 Neighbor Discovery, 5210 including Router Discovery and Neighbor Unreachability Detection. 5211 The mobile node SHOULD supplement this mechanism with other 5212 information whenever it is available to the mobile node (e.g., 5213 from lower protocol layers). The description here is based on the 5214 conceptual model of the organization and data structures defined by 5215 Neighbor Discovery [12]. 5217 Mobile nodes SHOULD use Router Discovery to discover new routers 5218 and on-link subnet prefixes; a mobile node MAY send Router 5219 Solicitations, or MAY wait for unsolicited (periodic) multicast 5220 Router Advertisements, as specified for Router Discovery [12]. Based 5221 on received Router Advertisements, a mobile node maintains an entry 5222 in its Default Router List for each router, and an entry in its 5223 Prefix List for each subnet prefix that it currently considers to be 5224 on-link. Each entry in these lists has an associated invalidation 5225 timer value. While away from home, a mobile node typically selects 5226 one default router and one subnet prefix to use as the subnet 5227 prefix in its primary care-of address. A mobile node MAY also have 5228 associated additional care-of addresses, using other subnet prefixes 5229 from its Prefix List. The method by which a mobile node selects 5230 and forms a care-of address from the available subnet prefixes is 5231 described in Section 11.5.2. The mobile node registers its primary 5232 care-of address with its home agent, as described in Section 11.7.1. 5234 While a mobile node is away from home, it is important for the mobile 5235 node to quickly detect when its default router becomes unreachable. 5236 When this happens, the mobile node SHOULD switch to a new default 5237 router and potentially to a new primary care-of address. If, on the 5238 other hand, the mobile node becomes unreachable from its default 5239 router, it should attempt to become reachable through some other 5240 router. To detect when its default router becomes unreachable, a 5241 mobile node SHOULD use Neighbor Unreachability Detection. 5243 For a mobile node to detect when it has become unreachable from its 5244 default router, the mobile node cannot efficiently rely on Neighbor 5245 Unreachability Detection alone, since the network overhead would 5246 be prohibitively high in many cases. Instead, when a mobile node 5247 receives any IPv6 packets from its current default router at all, 5248 irrespective of the source IPv6 address, it SHOULD use that as an 5249 indication that it is still reachable from the router. 5251 Since the router SHOULD be sending periodic unsolicited multicast 5252 Router Advertisements, the mobile node will have frequent opportunity 5253 to check if it is still reachable from its default router, even 5254 in the absence of other packets to it from the router. If Router 5255 Advertisements that the mobile node receives include an Advertisement 5256 Interval option, the mobile node MAY use its Advertisement Interval 5257 field as an indication of the frequency with which it SHOULD expect 5258 to continue to receive future Advertisements from that router. This 5259 field specifies the minimum rate (the maximum amount of time between 5260 successive Advertisements) that the mobile node SHOULD expect. If 5261 this amount of time elapses without the mobile node receiving any 5262 Advertisement from this router, the mobile node can be sure that at 5263 least one Advertisement sent by the router has been lost. It is 5264 thus possible for the mobile node to implement its own policy for 5265 determining the number of Advertisements from its current default 5266 router it is willing to tolerate losing before deciding to switch to 5267 a different router from which it may currently be correctly receiving 5268 Advertisements. 5270 On some types of network interfaces, the mobile node MAY also 5271 supplement this monitoring of Router Advertisements, by setting its 5272 network interface into "promiscuous" receive mode, so that it is able 5273 to receive all packets on the link, including those not addressed to 5274 it at the link layer (i.e., disabling link-level address filtering). 5275 The mobile node will then be able to detect any packets sent by the 5276 router, in order to detect reachability from the router. This use of 5277 promiscuous mode may be useful on very low bandwidth (e.g., wireless) 5278 links, but its use MUST be configurable on the mobile node since it 5279 is likely to consume additional energy resources. 5281 If the above means do not provide indication that the mobile node 5282 is still reachable from its current default router (for instance, 5283 the mobile node receives no packets from the router for a period of 5284 time), then the mobile node SHOULD attempt to actively probe the 5285 router with Neighbor Solicitations, even if it is not otherwise 5286 actively sending packets to the router. If it receives a solicited 5287 Neighbor Advertisement in response from the router, then the mobile 5288 node can deduce that it is still reachable. It is expected that the 5289 mobile node will in most cases be able to determine its reachability 5290 from the router by listening for packets from the router as described 5291 above, and thus, such extra Neighbor Solicitation probes should 5292 rarely be necessary. 5294 With some types of networks, indications about link-layer mobility 5295 might be obtained from lower-layer protocol or device driver software 5296 within the mobile node. However, all link-layer mobility indications 5297 from lower layers do not necessarily indicate a movement of the 5298 mobile node to a new link, such that the mobile node would need to 5299 switch to a new default router and primary care-of address. For 5300 example, movement of a mobile node from one cell to another in 5301 many wireless LANs can be made transparent to the IP level through 5302 use of a link-layer "roaming" protocol, as long as the different 5303 wireless LAN cells all operate as part of the same IP link with 5304 the same subnet prefix. Upon lower-layer indication of link-layer 5305 mobility, the mobile node MAY send Router Solicitations to determine 5306 if additional on-link subnet prefixes are available on its new link. 5308 Such lower-layer information might also be useful to a mobile node in 5309 deciding to switch its primary care-of address to one of the other 5310 care-of addresses it has formed from the on-link subnet prefixes 5311 currently available through different routers from which the mobile 5312 node is reachable. For example, a mobile node MAY use signal 5313 strength or signal quality information (with suitable hysteresis) for 5314 its link with the available routers to decide when to switch to a new 5315 primary care-of address using that router rather than its current 5316 default router (and current primary care-of address). Even though 5317 the mobile node's current default router may still be reachable in 5318 terms of Neighbor Unreachability Detection, the mobile node MAY use 5319 such lower-layer information to determine that switching to a new 5320 default router would provide a better connection. 5322 11.5.2. Forming New Care-of Addresses 5324 After detecting that it has moved from one link to another (i.e., its 5325 current default router has become unreachable and it has discovered 5326 a new default router), a mobile node SHOULD form a new primary 5327 care-of address using one of the on-link subnet prefixes advertised 5328 by the new router. A mobile node MAY form a new primary care-of 5329 address at any time, except that it MUST NOT do so too frequently. 5330 Specifically, a mobile node MUST NOT send a Binding Update about a 5331 new care-of address to its home agent (which is required to register 5332 the new address as its primary care-of address) more often than once 5333 per MAX_UPDATE_RATE seconds. 5335 In addition, after discovering a new on-link subnet prefix, a mobile 5336 node MAY form a new (non-primary) care-of address using that subnet 5337 prefix, even when it has not switched to a new default router. A 5338 mobile node can have only one primary care-of address at a time 5339 (which is registered with its home agent), but it MAY have an 5340 additional care-of address for any or all of the prefixes on its 5341 current link. Furthermore, since a wireless network interface may 5342 actually allow a mobile node to be reachable on more than one link at 5343 a time (i.e., within wireless transmitter range of routers on more 5344 than one separate link), a mobile node MAY have care-of addresses 5345 on more than one link at a time. The use of more than one care-of 5346 address at a time is described in Section 11.5.3. 5348 As described in Section 4, in order to form a new care-of address, 5349 a mobile node MAY use either stateless [13] or stateful (e.g., 5350 DHCPv6 [30]) Address Autoconfiguration. If a mobile node needs to 5351 send packets as part of the method of address autoconfiguration, 5352 it MUST use an IPv6 link-local address rather than its own IPv6 5353 home address as the Source Address in the IPv6 header of each such 5354 autoconfiguration packet. 5356 In some cases, a mobile node may already know a (constant) IPv6 5357 address that has been assigned to it for its use only while 5358 visiting a specific foreign link. For example, a mobile node may be 5359 statically configured with an IPv6 address assigned by the system 5360 administrator of some foreign link, for its use while visiting that 5361 link. If so, rather than using Address Autoconfiguration to form a 5362 new care-of address using this subnet prefix, the mobile node MAY use 5363 its own pre-assigned address as its care-of address on this link. 5365 A mobile node, after forming a new care-of address, MAY begin 5366 using the new care-of address without performing Duplicate Address 5367 Detection. Furthermore, the mobile node MAY continue using the 5368 address without performing Duplicate Address Detection, although 5369 it SHOULD in most cases. begin Duplicate Address Detection 5370 asynchronously when it begins use of the address. This allows the 5371 Duplicate Address Detection procedure to complete in parallel with 5372 normal communication using the address, avoiding major delays for 5373 some applications. 5375 In addition, normal processing for Duplicate Address Detection 5376 specifies that, in certain cases, the node SHOULD delay sending the 5377 initial Neighbor Solicitation message of Duplicate Address Detection 5378 by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13]; 5379 however, in this case, the mobile node SHOULD NOT perform such a 5380 delay in its use of Duplicate Address Detection, unless the mobile 5381 node is initializing after rebooting. 5383 11.5.3. Using Multiple Care-of Addresses 5385 As described in Section 11.5.2, a mobile node MAY use more than one 5386 care-of address at a time. Particularly in the case of many wireless 5387 networks, a mobile node effectively might be reachable through 5388 multiple links at the same time (e.g., with overlapping wireless 5389 cells), on which different on-link subnet prefixes may exist. A 5390 mobile node SHOULD select a primary care-of address from among those 5391 care-of addresses it has formed using any of these subnet prefixes, 5392 based on the movement detection mechanism in use, as described in 5393 Section 11.5.1. After selecting a new primary care-of address, 5394 the mobile node MUST send a Binding Update containing that care-of 5395 address to its home agent. The Binding Update MUST have the Home 5396 Registration (H) and Acknowledge (A) bits set its home agent, as 5397 described on Section 11.7.1. 5399 To assist with smooth handovers, a mobile node SHOULD retain 5400 its previous primary care-of address as a (non-primary) care-of 5401 address, and SHOULD still accept packets at this address, even after 5402 registering its new primary care-of address with its home agent. 5403 This is reasonable, since the mobile node could only receive packets 5404 at its previous primary care-of address if it were indeed still 5405 connected to that link. If the previous primary care-of address was 5406 allocated using stateful Address Autoconfiguration [30], the mobile 5407 node may not wish to release the address immediately upon switching 5408 to a new primary care-of address. 5410 11.5.4. Returning Home 5412 A mobile node detects that it has returned to its home link through 5413 the movement detection algorithm in use (Section 11.5.1), when the 5414 mobile node detects that its home subnet prefix is again on-link. 5415 The mobile node SHOULD then send a Binding Update to its home agent, 5416 to instruct its home agent to no longer intercept or tunnel packets 5417 for it. In this home registration, the mobile node MUST set the 5418 Acknowledge (A) and Home Registration (H) bits, set the Lifetime 5419 field to zero, and set the care-of address for the binding to the 5420 mobile node's own home address. The mobile node MUST use its home 5421 address as the source address in the Binding Update. 5423 When sending this Binding Update to its home agent, the mobile node 5424 must be careful in how it uses Neighbor Solicitation [12] (if needed) 5425 to learn the home agent's link-layer address, since the home agent 5426 will be currently configured to defend the mobile node's home address 5427 for Duplicate Address Detection (DAD). In particular, a Neighbor 5428 Solicitation from the mobile node using its home address as the 5429 Source Address would be detected by the home agent as a duplicate 5430 address. In many cases, Neighbor Solicitation by the mobile node 5431 for the home agent's address will not be necessary, since the mobile 5432 node may have already learned the home agent's link-layer address, 5433 for example from a Source Link-Layer Address option in the Router 5434 Advertisement from which it learned that its home address was on-link 5435 and that the mobile node had thus returned home. 5437 If the mobile node does Neighbor Solicitation to learn the home 5438 agent's link-layer address, in this special case of the mobile node 5439 returning home, the mobile node MUST multicast the packet, and in 5440 addition set the Source Address of this Neighbor Solicitation to the 5441 unspecified address (0:0:0:0:0:0:0:0). The target of the Neighbor 5442 Solicitation MUST be set to the home agent's IPv6 address, which is 5443 known to the mobile node. The destination IP address MUST be set to 5444 the Solicited-Node multicast address [3]. The home agent will be 5445 unable to distinguish this solicitation from a similar packet that 5446 would only be used for DAD, and it will respond as if for DAD. The 5447 home agent will send a multicast Neighbor Advertisement back to the 5448 mobile node with the Solicited flag (S) set to zero. The mobile node 5449 SHOULD accept this advertisement, and set the state of the Neighbor 5450 Cache entry for the home agent to REACHABLE. 5452 The mobile node then sends its Binding Update using the home agent's 5453 link-layer address, instructing its home agent to no longer serve 5454 as a home agent for it. By processing this Binding Update, the 5455 home agent will cease defending the mobile node's home address for 5456 Duplicate Address Detection and will no longer respond to Neighbor 5457 Solicitations for the mobile node's home address. The mobile node 5458 is then the only node on the link receiving packets at the mobile 5459 node's home address. In addition, when returning home prior to the 5460 expiration of a current binding for its home address, and configuring 5461 its home address on its network interface on its home link, the 5462 mobile node MUST NOT perform Duplicate Address Detection on its own 5463 home address, in order to avoid confusion or conflict with its home 5464 agent's use of the same address. If the mobile node returns home 5465 after the bindings for all of its care-of addresses have expired, 5466 then it SHOULD perform DAD. It SHOULD also perform DAD for addresses 5467 which may have been registered with 'D' and 'S' bits set to one. 5469 After the Mobile Node sends the Binding Update, the Home Agent MUST 5470 remove the Proxy Neighbor Cache entry for the Mobile Node and MAY 5471 learn its link-layer address based on the link-layer packet or cached 5472 information, or if that is not available, it SHOULD send a Neighbor 5473 Solicitation with the target address equal to the Binding Update's 5474 source IP address. The Mobile Node MUST then reply with a unicast 5475 Neighbor Advertisement to the Home Agent with its link-layer address. 5476 While the Mobile Node is waiting for a Binding Acknowledgement, it 5477 MUST NOT respond to any Neighbor Solicitations for its Home Address 5478 other than those originating from the IP address to which it sent the 5479 Binding Update. 5481 After receiving the Binding Acknowledgement for its Binding Update to 5482 its home agent, the mobile node MUST multicast onto the home link (to 5483 the all-nodes multicast address) a Neighbor Advertisement [12], to 5484 advertise the mobile node's own link-layer address for its own home 5485 address. The Target Address in this Neighbor Advertisement MUST be 5486 set to the mobile node's home address, and the Advertisement MUST 5487 include a Target Link-layer Address option specifying the mobile 5488 node's link-layer address. The mobile node MUST multicast such a 5489 Neighbor Advertisement for each of its home addresses, as defined by 5490 the current on-link prefixes, including its link-local address and 5491 site-local address. The Solicited Flag (S) in these Advertisements 5492 MUST NOT be set, since they were not solicited by any Neighbor 5493 Solicitation. The Override Flag (O) in these Advertisements MUST be 5494 set, indicating that the Advertisements SHOULD override any existing 5495 Neighbor Cache entries at any node receiving them. 5497 Since multicasting on the local link (such as Ethernet) is typically 5498 not guaranteed to be reliable, the mobile node MAY retransmit these 5499 Neighbor Advertisements up to MAX_ADVERT_REXMIT times to increase 5500 their reliability. It is still possible that some nodes on the home 5501 link will not receive any of these Neighbor Advertisements, but these 5502 nodes will eventually be able to recover through use of Neighbor 5503 Unreachability Detection [12]. 5505 11.6. Return Routability Procedure 5507 This section defines the rules that the mobile node must follow 5508 when performing the return routability procedure. Section 11.7.2 5509 describes the rules when the return routability procedure needs to be 5510 initiated. 5512 11.6.1. Sending Home and Care-of Test Init Messages 5514 A mobile node that initiates a return routability procedure MUST 5515 send (in parallel) a Home Test Init message and a Care-of Test Init 5516 messages. However, if the mobile node has recently received one or 5517 both home or care-of keygen tokens, and associated nonce indices for 5518 the desired addresses, it MAY reuse them. Therefore, the return 5519 routability procedure may in some cases be completed with only one 5520 message pair. It may even be completed without any messages at 5521 all, if the mobile node has a recent home keygen token and and has 5522 previously visited the same care-of address so that it also has a 5523 recent care-of keygen token. If the mobile node sets the Lifetime to 5524 zero or the care-of address in the Binding Update equal to its home 5525 address - such as when returning home - it MUST use the home keygen 5526 token and nonce index by itself (without a care-of keygen token and 5527 nonce index). In this case, generation of the binding management key 5528 depends exclusively on the home keygen token (Section 5.2.5). 5530 A Home Test Init message MUST be created as described in 5531 Section 6.1.3. A Care-of Test Init message MUST be created as 5532 described in Section 6.1.4. When sending a Home Test Init or Care-of 5533 Test Init message the mobile node MUST record in its Binding Update 5534 List the following fields from the messages: 5536 - The IP address of the node to which the message was sent. 5538 - The home address of the mobile node. This value will appear in 5539 the Source Address field of the Home Test Init message. When 5540 sending the Care-of Test Init message, this address does not 5541 appear in the message, but represents the home address for which 5542 the binding is desired. 5544 - The time at which each of these messages was sent. 5546 - The cookies used in the messages. 5548 Note that a single Care-of Test Init message may be sufficient even 5549 when there are multiple home addresses. In this case the mobile node 5550 MAY record the same information in multiple Binding List entries. 5552 11.6.2. Receiving Return Routability Messages 5554 Upon receiving a packet carrying a Home Test message, a mobile node 5555 MUST validate the packet according to the following tests: 5557 - The Header Len field in the Mobility Header is greater than or 5558 equal to the length specified in Section 6.1.5. 5560 - The Source Address of the packet belongs to a correspondent 5561 node for which the mobile node has a Binding Update List entry 5562 with a state indicating that return routability procedure is in 5563 progress. Note that there may be multiple such entries. 5565 - The Binding Update List indicates that no home keygen token has 5566 been received yet. 5568 - The Destination Address of the packet has the home address of the 5569 mobile node, and the packet has been received in a tunnel from 5570 the home agent. 5572 - The home init cookie field in the message matches the value 5573 stored in the Binding Update List. 5575 Any Home Test message not satisfying all of these tests MUST be 5576 silently ignored. Otherwise, the mobile node MUST record the Home 5577 Nonce Index and home keygen token in the Binding Update List. If the 5578 Binding Update List entry does not have a care-of keygen token, the 5579 mobile node SHOULD continue waiting for additional messages. 5581 Upon receiving a packet carrying a Care-of Test message, a mobile 5582 node MUST validate the packet according to the following tests: 5584 - The Header Len field in the Mobility Header is greater than or 5585 equal to the length specified in Section 6.1.6. 5587 - The Source Address of the packet belongs to a correspondent 5588 node for which the mobile node has a Binding Update List entry 5589 with a state indicating that return routability procedure is in 5590 progress. Note that there may be multiple such entries. 5592 - The Binding Update List indicates that no care-of keygen token 5593 has been received yet. 5595 - The Destination Address of the packet is the current care-of 5596 address of the mobile node. 5598 - The care-of init cookie field in the message matches the value 5599 stored in the Binding Update List. 5601 Any Care-of Test message not satisfying all of these tests MUST be 5602 silently ignored. Otherwise, the mobile node MUST record the Care-of 5603 Nonce Index and care-of keygen token in the Binding Update List. If 5604 the Binding Update List entry does not have a home keygen token, the 5605 mobile node SHOULD continue waiting for additional messages. 5607 If after receiving either the Home Test or the Care-of Test message 5608 and performing the above actions, the Binding Update List entry has 5609 both the home and the care-of keygen tokens, the return routability 5610 procedure is complete. The mobile node SHOULD then proceed with 5611 sending a Binding Update as described in Section 11.7.2. 5613 Correspondent nodes from the time before this specification was 5614 published may not support the Mobility Header protocol. These nodes 5615 will respond to Home Test Init and Care-of Test Init messages with 5616 an ICMP Parameter Problem code 1. The mobile node SHOULD take such 5617 messages as an indication that the correspondent node cannot provide 5618 route optimization, and revert back to the use of bidirectional 5619 tunneling. 5621 11.6.3. Protecting Return Routability Packets 5623 The mobile node MUST support the protection of Home Test and Home 5624 Test Init messages as described in Section 10.4.4. 5626 11.7. Processing Bindings 5628 11.7.1. Sending Binding Updates to the Home Agent 5630 After deciding to change its primary care-of address as described in 5631 Sections 11.5.1 and 11.5.2, a mobile node MUST register this care-of 5632 address with its home agent in order to make this its primary care-of 5633 address. Also, if the mobile node wants the services of the home 5634 agent beyond the current registration period, the mobile node MUST 5635 send a new Binding Update to it well before the expiration of this 5636 period, even if it is not changing its primary care-of address. 5638 In both of these situations, the mobile node sends a packet to its 5639 home agent containing a Binding Update, with the packet constructed 5640 as follows: 5642 - The Home Registration (H) bit MUST be set in the Binding Update. 5644 - The Acknowledge (A) bit MUST be set in the Binding Update. 5646 - The packet MUST contain a Home Address destination option, giving 5647 the mobile node's home address for the binding. 5649 - The care-of address for the binding MUST be used as the Source 5650 Address in the packet's IPv6 header, unless an Alternate Care-of 5651 Address mobility option is included in the Binding Update. This 5652 option MAY be included when the mobile node so desires, and 5653 MUST be included if the mobile node cannot be assured that the 5654 IPsec AH protocol is used to secure the Binding Update. The ESP 5655 protocol will not be able to protect care-of addresses in the 5656 IPv6 header. Mobile IPv6 implementations which are unaware of 5657 how IPsec secures their messaging will therefore need to use the 5658 Alternate Care-of Address option. 5660 - The Single Address Only (S) bit is cleared to request a binding 5661 for all home addresses of the mobile node. These addresses are 5662 based on the interface identifier of the home address indicated 5663 in the Binding Update, and all on-link subnet prefixes on the 5664 home link. When this bit is cleared, the Link-Local Address 5665 Compatibility (L) bit MUST be set. 5667 If the mobile node desires that only a single home address should 5668 be affected by this Binding Update, the Single Address Only (S) 5669 bit is set to 1. 5671 The value of the Single Address Only (S) bit MUST be set 5672 equivalently for subsequent de-registrations and re-registrations 5673 with the same addresses. 5675 - If the mobile node's link-local address has the same interface 5676 identifier as the home address for which it is supplying a new 5677 care-of address, then the mobile node SHOULD set the Link-Local 5678 Address Compatibility (L) bit. 5680 - If the home address was generated using RFC 3041 [17], then the 5681 link local address is unlikely to have a compatible interface 5682 identifier. In this case, the mobile node MUST set the 5683 Single Address Only (S) bit and clear the Link-Local Address 5684 Compatibility (L) bit. 5686 - The value specified in the Lifetime field SHOULD be less than 5687 or equal to the remaining lifetime of the home address and the 5688 care-of address specified for the binding. 5690 The Acknowledge (A) bit in the Binding Update requests the home agent 5691 to return a Binding Acknowledgement in response to this Binding 5692 Update. As described in Section 6.1.8, the mobile node SHOULD 5693 retransmit this Binding Update to its home agent until it receives 5694 a matching Binding Acknowledgement. Once reaching a retransmission 5695 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart 5696 the process of delivering the Binding Update, but trying instead the 5697 next home agent returned during dynamic home agent address discovery 5698 (see Section 11.4.1). If there was only one home agent, the mobile 5699 node instead SHOULD continue to periodically retransmit the Binding 5700 Update at this rate until acknowledged (or until it begins attempting 5701 to register a different primary care-of address). See Section 11.8 5702 for information about retransmitting Binding Updates. 5704 Depending on the value of the Single Address Only (S) bit in the 5705 Binding Update, the home agent is requested to serve either a single 5706 home address or all home addresses for the mobile node. Until the 5707 lifetime of this registration expires, the home agent considers 5708 itself the home agent for each such home address of the mobile node. 5709 As the set of on-link subnet prefixes on the home link changes over 5710 time, the home agent changes the set of home addresses for this 5711 mobile node for which it is serving as the home agent. 5713 Each Binding Update MUST be authenticated as coming from the right 5714 mobile node, as defined in Section 5.1. The mobile node MUST use its 5715 home address - either in the Home Address destination option or in 5716 the Source Address field of the IPv6 header - in Binding Updates sent 5717 to the home agent. This is necessary in order to allow the IPsec 5718 policies to be matched with the right home address. 5720 When sending a Binding Update to its home agent, the mobile node MUST 5721 also create or update the corresponding Binding Update List entry, as 5722 specified in Section 11.7.2. 5724 The last Sequence Number value sent to the home agent in a Binding 5725 Update is stored by the mobile node. If the sending mobile node has 5726 no knowledge of the right Sequence Number value, it may start at any 5727 value. If the home agent rejects the value, it sends back a Binding 5728 Acknowledgement with status code 135, and the last accepted sequence 5729 number in the Sequence Number field of the Binding Acknowledgement. 5730 The mobile node MUST store this information and use the next Sequence 5731 Number value for the next Binding Update it sends. 5733 If the mobile node has additional home addresses using a different 5734 interface identifier, then the mobile node SHOULD send an additional 5735 packet containing a Binding Update to its home agent to register the 5736 care-of address for each such other home address (or set of home 5737 addresses sharing an interface identifier). 5739 While the mobile node is away from home, it relies on the home 5740 agent to participate in Duplicate Address Detection (DAD) to defend 5741 its home address against stateless autoconfiguration performed by 5742 another node. Therefore, the mobile node SHOULD set the Duplicate 5743 Address Detection (D) bit based on any requirements for DAD that 5744 would apply to the mobile node if it were at home [12, 13]. If the 5745 mobile node's recent Binding Update was accepted by the home agent, 5746 and the lifetime for that Binding Update has not yet expired, the 5747 mobile node SHOULD NOT set the Duplicate Address Detection (D) bit in 5748 the new Binding Update; the home agent will already be defending the 5749 home address(es) of the mobile node and does not need to perform DAD 5750 again. 5752 The home agent will only perform DAD for the mobile node's home 5753 address when the mobile node has supplied a valid binding between 5754 its home address and a care-of address. If some time elapses during 5755 which the mobile node has no binding at the home agent, it might 5756 be possible for another node to autoconfigure the mobile node's 5757 home address. Therefore, the mobile node MUST treat creation of 5758 a new binding with the home agent using an existing home address 5759 the same as creation of a new home address. In the unlikely event 5760 that the mobile node's home address is autoconfigured as the IPv6 5761 address of another network node on the home network, the home agent 5762 will reply to the mobile node's subsequent Binding Update with a 5763 Binding Acknowledgement containing a Status of 134 (Duplicate Address 5764 Detection failed). In this case, the mobile node MUST NOT attempt to 5765 re-use the same home address. It SHOULD continue to register care-of 5766 addresses for its other home addresses, if any. The mobile node MAY 5767 also attempt to acquire a new home address to replace the one for 5768 which Status 134 was received, for instance by using the techniques 5769 described in Appendix B.5. 5771 11.7.2. Correspondent Binding Procedure 5773 When the mobile node is assured that its home address is valid, it 5774 MAY at any time initiate a correspondent binding procedure with 5775 the purpose of allowing the correspondent node to cache the mobile 5776 node's current care-of address. The mobile node is responsible for 5777 the initiation and completion of this procedure, as well as any 5778 retransmissions that may be needed (subject to the rate limiting 5779 defined in Section 11.8). 5781 This section defines the rules that the mobile node must follow when 5782 performing the correspondent binding procedure. 5784 The mobile node can be assured that its home address is still 5785 valid, for example, by the home agent's use the Duplicate Address 5786 Detection (D) bit of Binding Updates (see Section 10.3.1). In any 5787 Binding Update sent by a mobile node, the care-of address (either the 5788 Source Address in the packet's IPv6 header or the Care-of Address in 5789 the Alternate Care-of Address mobility option of the Binding Update) 5790 MUST be set to one of the care-of addresses currently in use by the 5791 mobile node or to the mobile node's home address. A mobile node MAY 5792 set the care-of address differently for sending Binding Updates to 5793 different correspondent nodes. 5795 A mobile node MAY choose to keep its location private from 5796 certain correspondent nodes, and thus need not initiate the 5797 return routability procedure, or send new Binding Updates to those 5798 correspondents. A mobile node MAY also send a Binding Update to 5799 such a correspondent node to instruct it to delete any existing 5800 binding for the mobile node from its Binding Cache, as described in 5801 Section 6.1.7. However, all Binding Updates to the correspondent 5802 node require the successful completion of the return routability 5803 procedure first, as no other IPv6 nodes are authorized to send 5804 Binding Updates on behalf of a mobile node. 5806 If set to one of the mobile node's current care-of addresses (the 5807 care-of address given MAY differ from the mobile node's primary 5808 care-of address), the Binding Update requests the correspondent node 5809 to create or update an entry for the mobile node in the correspondent 5810 node's Binding Cache in order to record this care-of address for use 5811 in sending future packets to the mobile node. In this case, the 5812 value specified in the Lifetime field sent in the Binding Update 5813 SHOULD be less than or equal to the remaining lifetime of the home 5814 address and the care-of address specified for the binding. 5816 If the care-of address is set to the mobile node's home address 5817 or the Lifetime field set to zero, the Binding Update requests 5818 the correspondent node to delete any existing Binding Cache entry 5819 that it has for the mobile node. In this case, generation of the 5820 binding management key depends exclusively on the home keygen token 5821 (Section 5.2.5). The care-of nonce index SHOULD be set to zero in 5822 this case. In keeping with the Binding Update creation rules below, 5823 the care-of address MUST be set to the home address if the mobile 5824 node is at home, or to the current care-of address if it is away from 5825 home. 5827 After the mobile node has sent a Binding Update to its home 5828 agent to register a new primary care-of address (as described in 5829 Section 11.7.1), the mobile node SHOULD send a Binding Update to each 5830 other node for which an entry exists in the mobile node's Binding 5831 Update List, as detailed below. Typically this requires starting a 5832 return routability procedure. Upon successful return routability 5833 procedure and after receiving a successful Binding Acknowledgement 5834 from the Home Agent, a Binding Update is sent to all other nodes. 5835 Thus, other relevant nodes are generally kept updated about the 5836 mobile node's binding and can send packets directly to the mobile 5837 node using the mobile node's current care-of address. 5839 The mobile node, however, need not initiate these actions immediately 5840 after configuring a new care-of address. For example, the mobile 5841 node MAY delay initiating the return routability procedure to any 5842 correspondent node for a short period of time, if it isn't certain 5843 that there is any significant traffic to the correspondent node. 5845 In addition, when a mobile node receives a packet for which the 5846 mobile node can deduce that the original sender of the packet either 5847 has no Binding Cache entry for the mobile node, or a stale entry 5848 for the mobile node in its Binding Cache, the mobile node SHOULD 5849 initiate a return routability procedure with the sender, in order to 5850 finally update the sender's Binding Cache with the current care-of 5851 address (subject to the rate limiting defined in Section 11.8). In 5852 particular, the mobile node SHOULD initiate a return routability 5853 procedure in response to receiving a packet that meets all of the 5854 following tests: 5856 - The packet was tunneled using IPv6 encapsulation. 5858 - The Destination Address in the tunnel (outer) IPv6 header is 5859 equal to any of the mobile node's care-of addresses. 5861 - The Destination Address in the original (inner) IPv6 header is 5862 equal to one of the mobile node's home addresses. 5864 - The Source Address in the tunnel (outer) IPv6 header differs from 5865 the Source Address in the original (inner) IPv6 header. 5867 The destination address to which the procedure should be initiated to 5868 in response to receiving a packet meeting all of the above tests is 5869 the Source Address in the original (inner) IPv6 header of the packet. 5870 The home address for which this Binding Update is sent should be the 5871 Destination Address of the original (inner) packet. 5873 If the mobile node wants to ensure that its new care-of address 5874 has been entered into a correspondent node's Binding Cache, the 5875 mobile node MAY request an acknowledgement by setting the Acknowledge 5876 (A) bit in the Binding Update. In this case, however, the mobile 5877 node SHOULD NOT continue to retransmit the Binding Update once the 5878 retransmission timeout period has reached MAX_BINDACK_TIMEOUT. 5880 The mobile node SHOULD create a Binding Update as follows: 5882 - The Source Address of the IPv6 header MUST contain the current 5883 care-of address of the mobile node. 5885 - The Destination Address of the IPv6 header MUST contain the 5886 address of the correspondent node. 5888 - The Mobility Header is constructed according to rules in 5889 Section 6.1.7 and 5.2.6, including the Binding Authorization Data 5890 (calculated as defined in Section 6.2.6) and possibly the Nonce 5891 Indices mobility options. 5893 - The home address of the mobile node MUST be added to the packet 5894 in a Home Address destination option, unless the Source Address 5895 is the home address. 5897 Each Binding Update MUST a Sequence Number greater than the Sequence 5898 Number value sent in the previous Binding Update (if any) to the same 5899 destination address modulo 2**16, as described in Section 9.5.1. 5900 There is no requirement, however, that the Sequence Number value 5901 strictly increase by 1 with each new Binding Update sent or received, 5902 as long as the value stays within the window. The last Sequence 5903 Number value sent to a destination in a Binding Update is stored 5904 by the mobile node in its Binding Update List entry for that 5905 destination. If the sending mobile node has no Binding Update List 5906 entry, the Sequence Number SHOULD start at a random value. The 5907 mobile node MUST NOT use the same Sequence Number in two different 5908 Binding Updates to the same correspondent node, even if the Binding 5909 Updates provide different care-of addresses. 5911 11.7.3. Receiving Binding Acknowledgements 5913 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 5914 node MUST validate the packet according to the following tests: 5916 - The packet meets the authentication requirements for Binding 5917 Acknowledgements, defined in Sections 6.1.8 and 5. That is, 5918 if the Binding Update was sent to the home agent, underlying 5919 IPsec protection is used. If the Binding Update was sent to 5920 the correspondent node, the Binding Authorization Data mobility 5921 option MUST be present and have a valid value. 5923 - The Binding Authorization Data mobility option, if present, MUST 5924 be the last option and MUST not have trailing padding. 5926 - The Header Len field in the Binding Acknowledgement is greater 5927 than or equal to the length specified in Section 6.1.8. 5929 - The Sequence Number field matches the Sequence Number sent by the 5930 mobile node to this destination address in an outstanding Binding 5931 Update. 5933 Any Binding Acknowledgement not satisfying all of these tests MUST be 5934 silently ignored. 5936 When a mobile node receives a packet carrying a valid Binding 5937 Acknowledgement, the mobile node MUST examine the Status field as 5938 follows: 5940 - If the Status field indicates that the Binding Update was 5941 accepted (the Status field is less than 128), then the mobile 5942 node MUST update the corresponding entry in its Binding Update 5943 List to indicate that the Binding Update has been acknowledged; 5944 the mobile node MUST then stop retransmitting the Binding Update. 5945 In addition, if the value specified in the Lifetime field in the 5946 Binding Acknowledgement is less than the Lifetime value sent 5947 in the Binding Update being acknowledged, then the mobile node 5948 MUST subtract the difference between these two Lifetime values 5949 from the remaining lifetime for the binding as maintained in the 5950 corresponding Binding Update List entry (with a minimum value 5951 for the Binding Update List entry lifetime of 0). That is, if 5952 the Lifetime value sent in the Binding Update was L_update, the 5953 Lifetime value received in the Binding Acknowledgement was L_ack, 5954 and the current remaining lifetime of the Binding Update List 5955 entry is L_remain, then the new value for the remaining lifetime 5956 of the Binding Update List entry should be 5958 max((L_remain - (L_update - L_ack)), 0) 5960 where max(X, Y) is the maximum of X and Y. The effect of this 5961 step is to correctly manage the mobile node's view of the 5962 binding's remaining lifetime (as maintained in the corresponding 5963 Binding Update List entry) so that it correctly counts down from 5964 the Lifetime value given in the Binding Acknowledgement, but with 5965 the timer countdown beginning at the time that the Binding Update 5966 was sent. 5968 Mobile nodes SHOULD send a new Binding Update well before the 5969 expiration of this period in order to extend the lifetime. 5970 This helps to avoid disruptions in communications, which might 5971 otherwise be caused by network delays or clock drift. 5973 - If the Status field indicates that the Binding Update was 5974 rejected (the Status field is greater than or equal to 128), then 5975 the mobile node MUST delete the corresponding Binding Update List 5976 entry, and it MUST also stop retransmitting the Binding Update. 5977 Optionally, the mobile node MAY then take steps to correct the 5978 cause of the error and retransmit the Binding Update (with a new 5979 Sequence Number value), subject to the rate limiting restriction 5980 specified in Section 11.8. 5982 The treatment of a Binding Refresh Advice mobility option within the 5983 Binding Acknowledgement depends on the where the acknowledgement came 5984 from. This option MUST be ignored if the acknowledgement came from 5985 a correspondent node. If it came from the home agent, the mobile 5986 node uses Refresh Interval field in the option as a suggestion that 5987 it SHOULD attempt to refresh its home registration at the indicated 5988 shorter interval. 5990 11.7.4. Receiving Binding Refresh Requests 5992 When a mobile node receives a packet containing a Binding Refresh 5993 Request message and there already exists a Binding Update List entry 5994 for the source of the Binding Refresh Request, it MAY start a return 5995 routability procedure. The mobile node MAY also choose to either 5996 ignore the Binding Refresh Request or to delete its binding from the 5997 sender of the Binding Refresh Request. Note that the mobile node 5998 SHOULD NOT respond Binding Refresh Requests from previously unknown 5999 correspondent nodes due to Denial-of-Service concerns. 6001 If the return routability procedure completes successfully, a 6002 Binding Update message SHOULD be sent as described in Section 11.7.2. 6003 The Lifetime field in this Binding Update SHOULD be set to a new 6004 lifetime, extending any current lifetime remaining from a previous 6005 Binding Update sent to this node (as indicated in any existing 6006 Binding Update List entry for this node), and lifetime SHOULD 6007 again be less than or equal to the remaining lifetime of the home 6008 registration and the care-of address specified for the binding. When 6009 sending this Binding Update, the mobile node MUST update its Binding 6010 Update List in the same way as for any other Binding Update sent by 6011 the mobile node. 6013 Instead, if the mobile node chooses to delete its binding from the 6014 sender of the Binding Refresh Request, the mobile node SHOULD return 6015 a Binding Update to the sender with the Lifetime specified as zero 6016 and specify a Care-of Address that matches the home address for the 6017 binding. 6019 11.7.5. Receiving Binding Error Messages 6021 When a mobile node receives a packet containing a Binding Error 6022 message, it should first check if the mobile node has a Binding 6023 Update List entry for the source of the Binding Error message. If 6024 the mobile node does not have such entry, it MUST ignore the message. 6025 This is necessary to prevent a waste of resources on e.g. return 6026 routability procedure due to spoofed Binding Error messages. 6028 Otherwise, if the message Status field was 1 (unknown binding for 6029 Home Address destination option), the mobile node should perform one 6030 of the following two actions: 6032 - If the mobile node does have a Binding Update List entry but 6033 has recent upper layer progress information that indicates 6034 communications with the correspondent node are progressing, it 6035 MAY ignore the message. This can be done in order to limit the 6036 damage that spoofed Binding Error messages can cause to ongoing 6037 communications. 6039 - If the mobile node does have a Binding Update List entry but 6040 no upper layer progress information, it MUST remove the entry 6041 and route further communications through the home agent. It 6042 MAY also optionally start a return routability procedure (see 6043 Section 5.2). 6045 If the message Status field was 2 (unrecognized MH Type value), the 6046 mobile node should perform one of the following two actions: 6048 - If the mobile node is not expecting an acknowledgement or 6049 response from the correspondent node, the mobile node SHOULD 6050 ignore this message. 6052 - Otherwise, the mobile node SHOULD cease the use of any extensions 6053 to this specification. If no extensions had been used, the 6054 mobile node should cease the attempt to use route optimization. 6056 11.8. Retransmissions and Rate Limiting 6058 The mobile node is responsible for retransmissions and rate limiting 6059 in the return routability and binding procedures. 6061 When the mobile node sends a Home Test Init, Care-of Test Init or 6062 Binding Update for which it expects a response, the mobile node has 6063 to determine a value for the initial retransmission timer: 6065 - If the mobile node is sending a Binding Update and it does not 6066 have an existing binding at the home agent, it SHOULD use a value 6067 for the initial retransmission timer that is at least 1.5 times 6068 longer than (RetransTimer * DupAddrDetectTransmits). This value 6069 is likely to be substantially longer than the otherwise specified 6070 value of INITIAL_BINDACK_TIMEOUT (see Section 12) that would be 6071 used by the mobile node. This longer retransmission interval 6072 will allow the home agent to complete the DAD procedure which is 6073 mandated in this case, as detailed in Section 11.7.1. 6075 - Otherwise, the mobile node should use the specified value of 6076 INITIAL_BINDACK_TIMEOUT for the initial retransmission timer. 6078 If the mobile node fails to receive a valid, matching response within 6079 the selected initial retransmission interval, the mobile node SHOULD 6080 retransmit the message, until a response is received. 6082 The retransmissions by the mobile node MUST use an exponential 6083 back-off process, in which the timeout period is doubled upon each 6084 retransmission until either the node receives a response or the 6085 timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile node 6086 MAY continue to send these messages at this slower rate indefinitely. 6088 The mobile node SHOULD start a separate back-off process for 6089 different message types, different home addresses and different 6090 care-of addresses. However, in addition an overall rate limitation 6091 applies for messages sent to a particular correspondent node. This 6092 ensures that the correspondent node has sufficient amount of time to 6093 answer when bindings for multiple home addresses are registered, for 6094 instance. The mobile node MUST NOT send Mobility Header messages of 6095 a particular type to a particular correspondent node more often than 6096 once per MAX_UPDATE_RATE seconds. 6098 Retransmitted Binding Updates MUST use a Sequence Number value 6099 greater than that used for the previous transmission of this Binding 6100 Update. Retransmitted Home Test Init and Care-of Test Init messages 6101 MUST use new cookie values. 6103 12. Protocol Constants 6105 HomeRtrAdvInterval 3,600 seconds 6106 DHAAD_RETRIES 3 retransmissions 6107 INITIAL_BINDACK_TIMEOUT 1 second 6108 INITIAL_DHAAD_TIMEOUT 2 seconds 6109 INITIAL_SOLICIT_TIMER 2 seconds 6110 MAX_ADVERT_REXMIT 3 transmissions 6111 MAX_BINDACK_TIMEOUT 256 seconds 6112 MaxMobPfxAdvInterval 86,400 seconds 6113 MAX_NONCE_LIFE 240 seconds 6114 MAX_TOKEN_LIFE 210 seconds 6115 MAX_RR_BINDING_LIFE 420 seconds 6116 MAX_UPDATE_RATE once per second 6117 MinDelayBetweenRAs 0.05 seconds 6118 MinMobPfxAdvInterval 600 seconds 6119 PREFIX_ADV_RETRIES 3 retransmissions 6120 PREFIX_ADV_TIMEOUT 5 seconds 6121 SLOW_UPDATE_RATE once per 10 second interval 6123 The value MinDelayBetweenRAs overrides the value of the protocol 6124 constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 [12]. 6126 13. IANA Considerations 6128 This document defines a new IPv6 protocol, the Mobility Header, 6129 described in Section 6.1. This protocol must be assigned a protocol 6130 number. The MH Type field in the Mobility Header is used to indicate 6131 a particular type of a message. The current message types are 6132 described in Sections 6.1.2 through 6.1.9, and include the following: 6134 0 Binding Refresh Request 6136 1 Home Test Init 6138 2 Care-of Test Init 6140 3 Home Test 6142 4 Care-of Test 6144 5 Binding Update 6146 6 Binding Acknowledgement 6148 7 Binding Error 6150 Future values of the MH Type can be allocated using standards 6151 action [10]. 6153 Furthermore, each mobility message may contain mobility options as 6154 described in Section 6.2. The current mobility options are defined 6155 in Sections 6.2.2 through 6.2.7, and include the following: 6157 0 Pad1 6159 1 PadN 6161 3 Alternate Care-of Address 6163 4 Nonce Indices 6165 5 Authorization Data 6167 6 Binding Refresh Advice 6169 Future values of the Option Type can be allocated using standards 6170 action [10]. 6172 This document also defines a new IPv6 destination option, the Home 6173 Address option, described in Section 6.3. This option must be 6174 assigned an Option Type value. 6176 This document also defines a new IPv6 type 2 routing header, 6177 described in Section 6.4. The value 2 is to be allocated by IANA 6178 when this specification becomes an RFC. 6180 In addition, this document defines four ICMP message types, two used 6181 as part of the dynamic home agent address discovery mechanism and 6182 two used in lieu of Router Solicitations and Advertisements when the 6183 mobile node is away from the home link: 6185 - The Home Agent Address Discovery Request message, described in 6186 Section 6.5; 6188 - The Home Agent Address Discovery Reply message, described in 6189 Section 6.6; 6191 - The Mobile Prefix Solicitation, described in Section 6.7; and 6193 - The Mobile Prefix Advertisement, described in Section 6.8. 6195 This document also defines two new Neighbor Discovery [12] options, 6196 which must be assigned Option Type values within the option numbering 6197 space for Neighbor Discovery messages: 6199 - The Advertisement Interval option, described in Section 7.3; and 6201 - The Home Agent Information option, described in Section 7.4. 6203 14. Security Considerations 6205 14.1. Threats 6207 Any mobility solution must protect itself against misuses of 6208 the mobility features and mechanisms. In Mobile IPv6, most of 6209 the potential threats are concerned with false Bindings, usually 6210 resulting in Denial-of-Service attacks. Some of the threats also 6211 pose potential for Man-in-the-Middle, Hijacking, Confidentiality, 6212 and Impersonation attacks. The main threats this protocol protects 6213 against are the following: 6215 1. Threats involving Binding Updates sent to home agents and 6216 correspondent nodes. For instance, an attacker might claim that 6217 a certain mobile node is currently at a different location than 6218 it really is. If a home agent accepts such spoofed information 6219 sent to it, the mobile node might not get traffic destined to 6220 it. Similarly, a malicious (mobile) node might use the home 6221 address of a victim node in a forged Binding Update sent to a 6222 correspondent node. 6224 These pose threats against confidentiality, integrity, and 6225 availability. That is, an attacker might learn the contents 6226 of packets destined to another node by redirecting the traffic 6227 to itself. Furthermore, an attacker might use the redirected 6228 packets in an attempt to set itself as a Man-in-the-Middle 6229 between a mobile and a correspondent node. This would allow the 6230 attacker to impersonate the mobile node, leading to integrity and 6231 availability problems. 6233 A malicious (mobile) node might also send Binding Updates in 6234 which the care-of address is set to the address of a victim 6235 node. If such Binding Updates were accepted, the malicious 6236 node could lure the correspondent node into sending potentially 6237 large amounts of data to the victim; the correspondent node's 6238 replies to messages sent by the malicious mobile node will be 6239 sent to the victim host or network. This could be used to 6240 cause a Distributed Denial-of-Service attack. For example, 6241 the correspondent node might be a site that will send a 6242 high-bandwidth stream of video to anyone who asks for it. Note 6243 that the use of flow-control protocols such as TCP does not 6244 necessarily defend against this type of attack, because the 6245 attacker can fake the acknowledgements. Even keeping TCP initial 6246 sequence numbers secret doesn't help, because the attacker can 6247 receive the first few segments (including the ISN) at its own 6248 address, and only then redirect the stream to the victim's 6249 address. These types of attacks may also be directed towards 6250 networks instead of nodes. Further variations of this threat are 6251 described elsewhere [31, 32]. 6253 An attacker might also attempt to disrupt a mobile node's 6254 communications by replaying a Binding Update that the node had 6255 sent earlier. If the old Binding Update was accepted, packets 6256 destined for the mobile node would be sent to its old location 6257 and not its current location. 6259 In conclusion, there are Denial-of-Service, Man-in-the-Middle, 6260 Confidentiality, and Impersonation threats against the 6261 parties involved in sending legitimate Binding Updates, and 6262 Denial-of-Service threats against any other party. 6264 2. Threats associated with payload packets: Payload packets 6265 exchanged with mobile nodes are exposed to similar threats as 6266 regular IPv6 traffic is. However, Mobile IPv6 introduces the 6267 Home Address destination option, a new routing header type 6268 (type 2), and uses tunneling headers in the payload packets. The 6269 protocol must protect against potential new threats involving the 6270 use of these mechanisms. 6272 Third parties become exposed to a reflection threat via the 6273 Home Address destination option, unless appropriate security 6274 precautions are followed. The Home Address destination option 6275 could be used to direct response traffic toward a node whose IP 6276 address appears in the option. In this case, ingress filtering 6277 would not catch the forged "return address" [33] [34]. 6279 A similar threat exists with the tunnels between the mobile node 6280 and the home agent. An attacker might forge tunnel packets 6281 between the mobile node and the home agent, making it appear 6282 that the traffic is coming from the mobile node when it is not. 6283 Note that an attacker who is able to forge tunnel packets would 6284 typically be able forge also packets that appear to come directly 6285 from the mobile node. This is a not a new threat as such. 6286 However, it may make it easier for attackers to escape detection 6287 by avoiding ingress filtering and packet tracing mechanisms. 6288 Furthermore, spoofed tunnel packets might be used to gain access 6289 to the home network. 6291 Finally, a routing header could also be used in reflection 6292 attacks, and in attacks designed to bypass firewalls. 6293 The generality of the regular routing header would allow 6294 circumvention of IP-address based rules in firewalls. It would 6295 also allow reflection of traffic to other nodes. These threats 6296 exist with routing headers in general, even if the usage that 6297 Mobile IPv6 requires is safe. 6299 3. Threats associated with dynamic home agent and prefix discovery. 6301 4. Threats against the Mobile IPv6 security mechanisms themselves: 6302 An attacker might, for instance, lure the participants into 6303 executing expensive cryptographic operations or allocating memory 6304 for the purpose of keeping state. The victim node would have no 6305 resources left to handle other tasks. 6307 As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to 6308 be deployed in most nodes of the IPv6 Internet. The above threats 6309 should therefore be considered in the light of being applicable to 6310 the whole Internet. 6312 14.2. Features 6314 This specification provides a number of security features designed to 6315 mitigate or alleviate the threats listed above. The main security 6316 features are the following: 6318 - Reverse Tunneling as a mandatory feature. 6320 - Protection of Binding Updates sent to home agents. 6322 - Protection of Binding Updates sent to correspondent nodes. 6324 - Protection against reflection attacks that use the Home Address 6325 destination option. 6327 - Protection of tunnels between the mobile node and the home agent. 6329 - Closing routing header vulnerabilities. 6331 - Mitigating Denial-of-Service threats to the Mobile IPv6 security 6332 mechanisms themselves. 6334 The support for encrypted reverse tunneling (see Section 11.3.1) 6335 allows mobile nodes to defeat certain kinds of traffic analysis. 6337 Protecting those Binding Updates that are sent to home agents and 6338 those that are sent to arbitrary correspondent nodes requires very 6339 different security solutions due to the different situations. Mobile 6340 nodes and home agents are expected to be naturally subject to the 6341 network administration of the home domain. 6343 Thus, they can and are supposed to have a strong security association 6344 that can be used to reliably authenticate the exchanged messages. 6345 See Section 5.1 for the description of the protocol mechanisms, 6346 and Section 14.3 below for a discussion of the resulting level of 6347 security. 6349 It is expected that Mobile IPv6 route optimization will be 6350 used on a global basis between nodes belonging to different 6351 administrative domains. It would be a very demanding task to 6352 build an authentication infrastructure on this scale. Furthermore, 6353 a traditional authentication infrastructure cannot be easily 6354 used to authenticate IP addresses, because these change often. 6355 It is not sufficient to just authenticate the mobile nodes. 6356 Authorization to claim the right to use an address is needed as 6357 well. Thus, an "infrastructureless" approach is necessary. The 6358 chosen infrastructureless method is described in Section 5.2 and 6359 Section 14.4 discusses the resulting security level and the design 6360 rationale of this approach. 6362 Specific rules guide the use of the Home Address destination option, 6363 the routing header, and the tunneling headers in the payload packets. 6364 These rules are necessary to remove the vulnerabilities associated 6365 with their unrestricted use. The effect of the rules is discussed in 6366 Sections 14.7, 14.8, and 14.9. 6368 Denial-of-Service threats against Mobile IPv6 security mechanisms 6369 themselves concern mainly the Binding Update procedures with 6370 correspondent nodes. The protocol has been designed to limit the 6371 effects of such attacks, as will be described in Section 14.4.5. 6373 14.3. Binding Updates to Home Agent 6375 Signaling between the mobile node and the home agent requires message 6376 integrity, correct ordering and replay protection. This is necessary 6377 to assure the home agent that a Binding Update is from a legitimate 6378 mobile node. 6380 IPsec AH or ESP protects the integrity of the Binding Updates and 6381 Binding Acknowledgements, by securing mobility messages between the 6382 mobile node and the home agent. For ESP, a non-null authentication 6383 algorithm MUST be applied. 6385 However, IPsec can easily provide replay protection only if dynamic 6386 security association establishment is used. This may not always be 6387 possible, and manual keying would be preferred in some cases. IPsec 6388 also does not guarantee correct ordering of packets, only that they 6389 have not been replayed. Because of this, sequence numbers with the 6390 Mobile IPv6 messages ensure correct ordering (see Section 5.1). 6391 However, if a home agent reboots and loses its state regarding the 6392 sequence numbers, replay attacks become possible. he use of a key 6393 management mechanism together with IPsec can be used to prevent such 6394 replay attacks. 6396 A sliding window scheme is used for the sequence numbers. The 6397 protection against replays and reordering attacks without a key 6398 management mechanism works when the attacker remembers up to a 6399 maximum of 2**15 Binding Updates. 6401 The above mechanisms do not show that the care-of address given 6402 in the Binding Update is correct. This opens the possibility for 6403 Denial-of-Service attacks against third parties. However, since the 6404 mobile node and home agent have a security association, the home 6405 agent can always identify an ill-behaving mobile node. This allows 6406 the home agent operator to discontinue the mobile node's service, and 6407 possibly take further actions based on the business relationship with 6408 the mobile node's owner. 6410 Note that where forwarding from a previous care-of address is used, 6411 a router in the visited network must act as a temporary home agent 6412 for the mobile node. Nevertheless, the same security requirements 6413 apply in this case. That is, a pre-arranged security association 6414 must exist even with the temporary home agent. This limits the use 6415 of the forwarding feature to those networks where such arrangements 6416 are practical. 6418 Note that the use of a single pair of manually keyed security 6419 associations conflicts with the generation of a new home 6420 addresses [17] for the mobile node, or with the adoption of a 6421 new home prefix. This is because IPsec SAs are bound to the used 6422 addresses. While certificate-based automatic keying alleviates 6423 this problem to an extent, it is still necessary to ensure that a 6424 given mobile node cannot send Binding Updates for the address of 6425 another mobile node. In general, this leads to the inclusion of 6426 home addresses in certificates in the Subject AltName field. This 6427 again limits the introduction of new addresses without either manual 6428 or automatic procedures to establish new certificates. Therefore, 6429 this specification limits restricts the generation of new home 6430 addresses (for any reason) to those situations where there already 6431 exists a security association or certificate for the new address. 6432 (Section B.4 lists the improvement of security for new addresses as 6433 one of the future developments for Mobile IPv6.) 6435 14.4. Binding Updates to Correspondent Nodes 6437 14.4.1. Overview 6439 The motivation for designing the return routability procedure 6440 was to have sufficient support for Mobile IPv6, without creating 6441 significant new security problems. The goal for this procedure was 6442 not to protect against attacks that were already possible before the 6443 introduction of Mobile IPv6. 6445 The chosen infrastructureless method verifies that the mobile node 6446 is "live" (that is, it responds to probes) at its home and care-of 6447 addresses. Section 5.2 describes the return routability procedure in 6448 detail. The procedure uses the following principles: 6450 - A message exchange verifies that the mobile node is reachable 6451 at its addresses i.e. is at least able to transmit and receive 6452 traffic at both the home and care-of addresses. 6454 - The eventual Binding Update is cryptographically bound to the 6455 tokens supplied in the exchanged messages. 6457 - Symmetric exchanges are employed to avoid the use of this 6458 protocol in reflection attacks. In a symmetric exchange, the 6459 responses are always sent to the same address as the request was 6460 sent from. 6462 - The correspondent node operates in a stateless manner until it 6463 receives a fully authorized Binding Update. 6465 - Some additional protection is provided by encrypting the tunnels 6466 between the mobile node and home agent with IPsec ESP. As the 6467 tunnel transports also the nonce exchanges, this limits the 6468 ability of attackers to see these nonces. For instance, this 6469 prevents attacks launched from the mobile node's current foreign 6470 link where no link-layer confidentiality is available. 6472 For further information about the design rationale of the return 6473 routability procedure, see [31, 32, 35, 34]. The used mechanisms 6474 have been adopted from these documents. 6476 14.4.2. Offered Protection 6478 This procedure protects Binding Updates against all attackers 6479 who are unable to monitor the path between the home agent and the 6480 correspondent node. The procedure does not defend against attackers 6481 who can monitor this path. Note that such attackers are in any case 6482 able to mount an active attack against the mobile node when it is 6483 at its home location. The possibility of such attacks is not an 6484 impediment to the deployment of Mobile IPv6, because these attacks 6485 are possible regardless of whether Mobile IPv6 is in use. 6487 This procedure also protects against Denial-of-Service attacks in 6488 which the attacker pretends to be a mobile, but uses the victim's 6489 address as the care of address. This would cause the correspondent 6490 node to send the victim some unexpected traffic. The procedure 6491 defends against these attacks by requiring at least passive presence 6492 of the attacker at the care-of address or on the path from the 6493 correspondent to the care of address. Normally, this will be the 6494 mobile node. 6496 The Binding Acknowledgement is not authenticated in other ways than 6497 including the right sequence number in the reply. 6499 14.4.3. Comparison to Regular IPv6 Communications 6501 This section discusses the protection offered by the return 6502 routability method by comparing it to the security of regular IPv6 6503 communications. We will divide vulnerabilities in three classes: 6504 (1) those related to attackers on the local network of the mobile 6505 node, home agent, or the correspondent node, (2) those related to 6506 attackers on the path between the home network and the correspondent 6507 node, and (3) off-path attackers, i.e. the rest of the Internet. 6509 We will now discuss the vulnerabilities of regular IPv6 6510 communications. The on-link vulnerabilities of IPv6 communications 6511 include Denial-of-Service, Masquerading, Man-in-the-Middle, 6512 Eavesdropping, and other attacks. These attacks can be launched 6513 through spoofing Router Discovery, Neighbor Discovery and other IPv6 6514 mechanisms. Some of these attacks can be prevented with the use of 6515 cryptographic protection in the packets. 6517 A similar situation exists with on-path attackers. That is, without 6518 cryptographic protection the traffic is completely vulnerable. 6520 Assuming that attackers have not penetrated the security of the 6521 Internet routing protocols, attacks are much harder to launch 6522 from off-path locations. Attacks that can be launched from these 6523 locations are mainly Denial-of-Service attacks, such as flooding 6524 and/or reflection attacks. It is not possible for an off-path 6525 attacker to become a MitM. (Since IPv6 communications are relatively 6526 well protected against off-path attackers, it is important that 6527 Mobile IPv6 prevents off-path attacks as well.) 6529 Next, we will consider the vulnerabilities that exist when IPv6 is 6530 used together with Mobile IPv6 and the return routability procedure. 6531 On the local link the vulnerabilities are same as those as in IPv6, 6532 but Masquerade and MitM attacks can now be launched also against 6533 future communications, and not just against current communications. 6534 If a Binding Update was sent while the attacker was present on the 6535 link, its effects stay during the lifetime of the binding. This 6536 happens even if the attacker moves away from the link. In regular 6537 IPv6, the attacker generally has to be stay on the link in order to 6538 continue the attack. Note that in order to launch these new attacks, 6539 the IP address of the victim must be known. This makes this attack 6540 feasible mainly in the context of well-known interface IDs, such as 6541 those already appearing in the traffic on the link or registered in 6542 the DNS. 6544 On-path attackers can exploit similar vulnerabilities as in regular 6545 IPv6. There are some minor differences, however. Masquerade, MitM, 6546 and DoS attacks can be launched with just the interception of a few 6547 packets, whereas in regular IPv6 it is necessary to intercept every 6548 packet. The effect of the attacks is the same regardless of the 6549 method, however. In any case, the most difficult task attacker faces 6550 in these attacks is getting to the right path. 6552 The vulnerabilities for off-path attackers are the same as in regular 6553 IPv6. Those nodes that are not on the path between the home agent 6554 and the correspondent node will not be able to receive the probe 6555 messages. 6557 In conclusion, we can state the following main results from this 6558 comparison: 6560 - Return routability procedure prevents any off-path attacks beyond 6561 those that are already possible in regular IPv6. This is the 6562 most important result, and prevents attackers from the Internet 6563 from exploiting any vulnerabilities. 6565 - Vulnerabilities to attackers on the home agent link, the 6566 correspondent node link, and the path between them are roughly 6567 the same as in regular IPv6. 6569 - However, one difference is that in basic IPv6 an on-path attacker 6570 must be constantly present on the link or the path, whereas with 6571 Mobile IPv6 an attacker can leave a binding behind after moving 6572 away. 6574 For this reason, this specification limits the creation of 6575 bindings to at most MAX_TOKEN_LIFE seconds after the last 6576 routability check has been performed, and limits the duration of 6577 a binding to at most MAX_RR_BINDING_LIFE seconds. With these 6578 limitation, attackers cannot take practical advantages of this 6579 vulnerability. This limited vulnerability can also be compared 6580 to similar vulnerabilities in IPv6 Neighbor Discovery, with 6581 Neighbor Cache entries having a limited lifetime. 6583 - There are some other minor differences, such as an effect 6584 to the DoS vulnerabilities. These can be considered to be 6585 insignificant. 6587 - The path between the home agent and a correspondent node is 6588 typically easiest to attack on the links at either end, in 6589 particular if these links are publicly accessible wireless LANs. 6590 Attacks against the routers or switches on the path are typically 6591 harder to accomplish. The security on layer 2 of the links plays 6592 then a major role in the resulting overall network security. 6593 Similarly, security of IPv6 Neighbor and Router Discovery on 6594 these links has a large impact. If these were secured using 6595 some new technology in the future, this could make the return 6596 routability procedure the easiest route for attackers. For this 6597 reason, this specification should have a protection mechanism for 6598 selecting between return routability and potential other future 6599 mechanisms. 6601 For a more in-depth discussion of these issues, see [34]. 6603 14.4.4. Return Routability Replays 6605 The return routability procedure also protects the participants 6606 against replayed Binding Updates. The attacker is unable replay 6607 the same message due to the sequence number which is a part of the 6608 Binding Update. It is also unable to modify the Binding Update since 6609 the MAC would not verify after such modification. 6611 Care must be taken when removing bindings at the correspondent 6612 node, however. If a binding is removed while the nonce used in its 6613 creation is still valid, an attacker could replay the old Binding 6614 Update. Rules outlined in Section 5.2.8 ensure that this cannot 6615 happen. 6617 14.4.5. Return Routability Denial-of-Service 6619 The return routability procedure has protection against resource 6620 exhaustion Denial-of-Service attacks. The correspondent nodes do not 6621 retain any state about individual mobile nodes until an authentic 6622 Binding Update arrives. This is achieved through the construct of 6623 keygen tokens from the nonces and node keys that are not specific 6624 to individual mobile nodes. The keygen tokens can be reconstructed 6625 by the correspondent node, based on the home and care-of address 6626 information that arrives with the Binding Update. This means that 6627 the correspondent nodes are safe against memory exhaustion attacks 6628 except where on-path attackers are concerned. Due to the use of 6629 symmetric cryptography, the correspondent nodes are relatively safe 6630 against CPU resource exhaustion attacks as well. 6632 Nevertheless, as [31] describes, there are situations in which it is 6633 impossible for the mobile and correspondent nodes to determine if 6634 they actually need a binding or whether they just have been fooled 6635 into believing so by an attacker. Therefore, it is necessary to 6636 consider situations where such attacks are being made. 6638 Even if route optimization is a very important optimization, it is 6639 still only an optimization. A mobile node can communicate with a 6640 correspondent node even if the correspondent refuses to accept any 6641 Binding Updates. However, performance will suffer because packets 6642 from the correspondent node to the mobile node will be routed via the 6643 mobile's home agent rather than a more direct route. A correspondent 6644 node can protect itself against some of these resource exhaustion 6645 attacks as follows. If the correspondent node is flooded with a 6646 large number of Binding Updates that fail the cryptographic integrity 6647 checks, it can stop processing Binding Updates. If a correspondent 6648 node finds that it is spending more resources on checking bogus 6649 Binding Updates than it is likely to save by accepting genuine 6650 Binding Updates, then it may silently discard some or all Binding 6651 Updates without performing any cryptographic operations. 6653 Layers above IP can usually provide additional information to decide 6654 if there is a need to establish a binding with a specific peer. For 6655 example, TCP knows if the node has a queue of data that it is trying 6656 to send to a peer. An implementation of this specification is not 6657 required to make use of information from higher protocol layers, but 6658 some implementations are likely to be able to manage resources more 6659 effectively by making use of such information. 6661 We also require that all implementations MUST allow route 6662 optimization to be administratively enabled or disabled. The default 6663 SHOULD be enabled. 6665 14.5. Dynamic Home Agent Address Discovery 6667 The dynamic home agent address discovery function could be used to 6668 learn the addresses of home agents in the home network. Attackers 6669 will not be able to learn much from this information, however, and 6670 mobile nodes cannot be tricked into using wrong home agents as all 6671 other communication with the home agents is secure. 6673 14.6. Prefix Discovery 6675 The prefix discovery function may leak interesting information 6676 about network topology and prefix lifetimes to eavesdroppers, 6677 and for this reason requests for this information have to be 6678 authenticated. Responses and unsolicited prefix information 6679 needs to be authenticated to prevent the mobile nodes from being 6680 tricked into believing false information about the prefixes, and 6681 possibly preventing communications with the existing addresses. 6682 Optionally, encryption may be applied to prevent leakage of the 6683 prefix information. 6685 14.7. Tunneling via the Home Agent 6687 Tunnels between the mobile node and the home agent can be 6688 protected by ensuring proper use of source addresses, and optional 6689 cryptographic protection. These procedures are discussed in 6690 Section 5.5. 6692 Binding Updates to the home agents are secure. When receiving 6693 tunneled traffic the home agent verifies the outer IP address 6694 corresponds to the current location of the mobile node. This 6695 prevents attacks where the attacker is controlled by ingress 6696 filtering. It also prevents attacks when the attacker does not know 6697 the current care-of address of the mobile node. Attackers who know 6698 the care-of address and are not controlled by ingress filtering could 6699 still send traffic through the home agent. This includes attackers 6700 on the same local link as the mobile node is currently on. But such 6701 attackers could also send spoofed packets without using a tunnel. 6703 Home agents and mobile nodes may use IPsec AH or ESP to protect 6704 payload packets tunneled between themselves. This is useful to 6705 protect communications against attackers on the path of the tunnel. 6707 When site local home address are used, reverse tunneling can be used 6708 to send site local traffic from another location. Administrators 6709 should be aware of this when allowing such home addresses. In 6710 particular, the outer IP address check described above is not 6711 sufficient against all attackers. The use of encrypted tunnels is 6712 particularly useful for this kind of home addresses. 6714 14.8. Home Address Option 6716 When the mobile node sends packets directly to the correspondent 6717 node, the Source Address field of the packet's IPv6 header is the 6718 care-of address. Ingress filtering [23] works therefore in the usual 6719 manner even for mobile nodes, as the Source Address is topologically 6720 correct. The Home Address option is used to inform the correspondent 6721 node of the mobile node's home address. 6723 However, the care-of address in the Source Address field does 6724 not survive in replies sent by the correspondent node unless 6725 it has a binding for this mobile node. Also, not all attacker 6726 tracing mechanisms work when packets are being reflected through 6727 correspondent nodes using the Home Address option. For these 6728 reasons, this specification restricts the use of the Home Address 6729 option. It may only used when a binding has already been established 6730 with the participation of the node at the home address, as described 6731 in Sections 5.5 and 6.3. This prevents reflection attacks through 6732 the use of the Home Address option. It also ensures that the 6733 correspondent nodes reply to the same address as the mobile node 6734 sends traffic from. 6736 No special authentication of the Home Address option is required 6737 beyond the above, except that if the IPv6 header of a packet is 6738 covered by authentication, then that authentication MUST also cover 6739 the Home Address option; this coverage is achieved automatically by 6740 the definition of the Option Type code for the Home Address option 6741 (Section 6.3), since it indicates that the option is included in the 6742 authentication computation. Thus, even when authentication is used 6743 in the IPv6 header, the security of the Source Address field in the 6744 IPv6 header is not compromised by the presence of a Home Address 6745 option. Without authentication of the packet, then any field in the 6746 IPv6 header, including the Source Address field, and any other parts 6747 of the packet, including the Home Address option, can be forged or 6748 modified in transit. In this case, the contents of the Home Address 6749 option is no more suspect than any other part of the packet. 6751 14.9. Type 2 Routing Header 6753 The definition of the type 2 routing header is described in 6754 Section 6.4. This definition and the associated processing rules 6755 have been chosen so that the header cannot be used for what is 6756 traditionally viewed as source routing. In particular, the Home 6757 Address in the routing header will always have to be assigned to the 6758 home address of the receiving node. Otherwise the packet will be 6759 dropped. 6761 Generally, source routing has a number of security concerns. These 6762 include the automatic reversal of unauthenticated source routes 6763 (which is an issue for IPv4, but not for IPv6). Another concern is 6764 the ability to use source routing to "jump" between nodes inside, as 6765 well as outside a firewall. These security concerns are not issues 6766 in Mobile IPv6, due to the rules mentioned above. 6768 In essence the semantics of the type 2 routing header is the same as 6769 a special form of IP-in-IP tunneling where the inner and outer source 6770 addresses are the same. 6772 This implies that a device which implements filtering of packets 6773 should be able to distinguish between a type 2 routing header and 6774 other routing headers, as required in Section 8.3. This is necessary 6775 in order to allow Mobile IPv6 traffic while still having the option 6776 to filter out other uses of routing headers. 6778 Contributors 6780 Tuomas Aura, Mike Roe, Greg O'Shea (Microsoft), Pekka Nikander 6781 (Ericsson), Erik Nordmark (Sun Microsystems), and Michael Thomas 6782 (Cisco) worked on the return routability protocols which eventually 6783 led to the procedures used in this protocol. The procedures 6784 described in [32] were adopted in the protocol. 6786 Significant contributions were made by members of the Mobile 6787 IPv6 Security Design Team, including (in alphabetical order) 6788 Gabriel Montenegro, Erik Nordmark (Sun Microsystems) and Pekka 6789 Nikander (Ericsson), who have contributed volumes of text to this 6790 specification. 6792 Acknowledgements 6794 We would like to thank the members of the Mobile IP and IPng Working 6795 Groups for their comments and suggestions on this work. We would 6796 particularly like to thank (in alphabetical order) Fred Baker 6797 (Cisco), Josh Broch (Carnegie Mellon University), Samita Chakrabarti 6798 (Sun Microsystems), Robert Chalmers (University of California, Santa 6799 Barbara), Noel Chiappa (MIT), Vijay Devarapalli (Nokia Research 6800 Center), Rich Draves (Microsoft Research), Francis Dupont (ENST 6801 Bretagne), Thomas Eklund (Xelerated), Jun-Ichiro Itojun Hagino (IIJ 6802 Research Laboratory), Brian Haley (Compaq), John Ioannidis (AT & T 6803 Labs Research), James Kempf (DoCoMo), Rajeev Koodli (Nokia), Krishna 6804 Kumar (IBM Research), T.J. Kniveton (Nokia Research), Joe Lau (HP), 6805 Jiwoong Lee (KTF), Aime Le Rouzic (Bull S.A.), Vesa-Matti Mantyla 6806 (Ericsson), Kevin Miles (Cisco), Glenn Morrow (Nortel Networks), 6807 Thomas Narten (IBM), Karen Nielsen (Ericsson Telebit), Simon Nybroe 6808 (Ericsson Telebit), David Oran (Cisco), Brett Pentland (Monash 6809 University), Lars Henrik Petander (HUT), Basavaraj Patil (Nokia), 6810 Mohan Parthasarathy (Tahoe Networks), Alexandru Petrescu (Motorola), 6811 Mattias Petterson (Ericsson), Ken Powell (HP), Phil Roberts 6812 (Megisto), Patrice Romand (Bull S.A.), Jeff Schiller (MIT), Pekka 6813 Savola (Netcore), Arvind Sevalkar (Intinfotech), Keiichi Shima (IIJ 6814 Research Laboratory), Tom Soderlund (Nokia Research), Hesham Soliman 6815 (Ericsson), Jim Solomon (RedBack Networks), Tapio Suihko (Technical 6816 Research Center of Finland), Dave Thaler (Microsoft), Benny Van Houdt 6817 (University of Antwerp), Jon-Olov Vatn (KTH), Vladislav Yasevich 6818 (HP), Alper Yegin (DoCoMo), and Xinhua Zhao (Stanford University) for 6819 their detailed reviews of earlier versions of this document. Their 6820 suggestions have helped to improve both the design and presentation 6821 of the protocol. 6823 We would also like to thank the participants in the Mobile IPv6 6824 testing event held at Nancy, France, September 15-17, 1999, for their 6825 valuable feedback as a result of interoperability testing of four 6826 Mobile IPv6 implementations coming from four different organizations: 6827 Bull, Ericsson Research and Ericsson Telebit, NEC, and INRIA. 6828 Further, we would like to thank the feedback from the implementors 6829 who participated in the Mobile IPv6 interoperability testing 6830 at Connectathons 2000, 2001, and 2002 in San Jose, California. 6831 Similarly, we would like to thank the participants at the ETSI 6832 interoperability testing at ETSI, in Sophia Antipolis, France, during 6833 October 2-6, 2000, including teams from Compaq, Ericsson, INRIA, 6834 Nokia, and Technical University of Helsinki. 6836 References 6838 [1] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 6839 Recommendations for Security. Request for Comments 6840 (Informational) 1750, Internet Engineering Task Force, December 6841 1994. 6843 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 6844 Levels. Request for Comments (Best Current Practice) 2119, 6845 Internet Engineering Task Force, March 1997. 6847 [3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 6848 Request for Comments (Proposed Standard) 2373, Internet 6849 Engineering Task Force, July 1998. 6851 [4] S. Kent and R. Atkinson. Security Architecture for the Internet 6852 Protocol. Request for Comments (Proposed Standard) 2401, 6853 Internet Engineering Task Force, November 1998. 6855 [5] S. Kent and R. Atkinson. IP Authentication Header. Request for 6856 Comments (Proposed Standard) 2402, Internet Engineering Task 6857 Force, November 1998. 6859 [6] S. Kent and R. Atkinson. IP Encapsulating Security Payload 6860 (ESP). Request for Comments (Proposed Standard) 2406, Internet 6861 Engineering Task Force, November 1998. 6863 [7] D. Piper. The Internet IP Security Domain of Interpretation for 6864 ISAKMP. Request for Comments (Proposed Standard) 2407, Internet 6865 Engineering Task Force, November 1998. 6867 [8] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet 6868 Security Association and Key Management Protocol (ISAKMP). 6869 Request for Comments (Proposed Standard) 2408, Internet 6870 Engineering Task Force, November 1998. 6872 [9] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). 6873 Request for Comments (Proposed Standard) 2409, Internet 6874 Engineering Task Force, November 1998. 6876 [10] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 6877 Considerations Section in RFCs. Request for Comments (Best 6878 Current Practice) 2434, Internet Engineering Task Force, October 6879 1998. 6881 [11] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 6882 Specification. Request for Comments (Draft Standard) 2460, 6883 Internet Engineering Task Force, December 1998. 6885 [12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 6886 IP Version 6 (IPv6). Request for Comments (Draft Standard) 6887 2461, Internet Engineering Task Force, December 1998. 6889 [13] S. Thomson and T. Narten. IPv6 Stateless Address 6890 Autoconfiguration. Request for Comments (Draft Standard) 2462, 6891 Internet Engineering Task Force, December 1998. 6893 [14] A. Conta and S. Deering. Internet Control Message Protocol 6894 (ICMPv6) for the Internet Protocol version 6 (IPv6) 6895 specification. Request for Comments (Draft Standard) 2463, 6896 Internet Engineering Task Force, December 1998. 6898 [15] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 6899 Specification. Request for Comments (Proposed Standard) 2473, 6900 Internet Engineering Task Force, December 1998. 6902 [16] D. Johnson and S. Deering. Reserved IPv6 Subnet Anycast 6903 Addresses. Request for Comments (Proposed Standard) 2526, 6904 Internet Engineering Task Force, March 1999. 6906 [17] T. Narten and R. Draves. Privacy Extensions for Stateless 6907 Address Autoconfiguration in IPv6. Request for Comments 6908 (Proposed Standard) 3041, Internet Engineering Task Force, 6909 January 2001. 6911 [18] Editor J. Reynolds. Assigned Numbers: RFC 1700 is Replaced by 6912 an On-line Database. Request for Comments (Informational) 3232, 6913 Internet Engineering Task Force, January 2002. 6915 [19] National Institute of Standards and Technology. Secure hash 6916 standard. Technical Report NIST FIPS PUB 180-1, U.S. Department 6917 of Commerce, April 1995. 6919 [20] C. Perkins. IP Mobility Support. Request for Comments 6920 (Proposed Standard) 2002, Internet Engineering Task Force, 6921 October 1996. 6923 [21] C. Perkins. IP Encapsulation within IP. Request for Comments 6924 (Proposed Standard) 2003, Internet Engineering Task Force, 6925 October 1996. 6927 [22] C. Perkins. Minimal Encapsulation within IP. Request for 6928 Comments (Proposed Standard) 2004, Internet Engineering Task 6929 Force, October 1996. 6931 [23] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating 6932 Denial of Service Attacks which employ IP source address 6933 spoofing. Request for Comments (Informational) 2267, Internet 6934 Engineering Task Force, January 1998. 6936 [24] Jari Arkko, Vijay Devarapalli, and Francis Dupont. Using IPsec 6937 to Protect Mobile IPv6 signaling between Mobile Nodes and Home 6938 Agents (work in progress). Internet Draft, Internet Engineering 6939 Task Force, October 2002. 6941 [25] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 6942 for Message Authentication. Request for Comments 6943 (Informational) 2104, Internet Engineering Task Force, 6944 February 1997. 6946 [26] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 6947 Specification. Request for Comments (Proposed Standard) 1883, 6948 Internet Engineering Task Force, December 1995. 6950 [27] P. V. Mockapetris. Domain names - concepts and facilities. 6951 Request for Comments (Standard) 1034, Internet Engineering Task 6952 Force, November 1987. 6954 [28] P. V. Mockapetris. Domain names - implementation and 6955 specification. Request for Comments (Standard) 1035, Internet 6956 Engineering Task Force, November 1987. 6958 [29] S. Deering, W. Fenner, and B. Haberman. Multicast Listener 6959 Discovery (MLD) for IPv6. Request for Comments (Proposed 6960 Standard) 2710, Internet Engineering Task Force, October 1999. 6962 [30] J. Bound, C. Perkins, M. Carney, and R. Droms. Dynamic Host 6963 Configuration Protocol for IPv6 (DHCPv6) (work in progress). 6964 Internet Draft, Internet Engineering Task Force, January 2001. 6966 [31] Tuomas Aura and Jari Arkko. MIPv6 BU Attacks and Defenses (work 6967 in progress). Internet Draft, Internet Engineering Task Force, 6968 February 2002. 6970 [32] Michael Roe, Greg O'Shea, Tuomas Aura, and Jari Arkko. 6971 Authentication of Mobile IPv6 Binding Updates and 6972 Acknowledgments (work in progress). Internet Draft, 6973 Internet Engineering Task Force, February 2002. 6975 [33] Pekka Savola. Security of IPv6 Routing Header and Home 6976 Address Options (work in progress). Internet Draft, Internet 6977 Engineering Task Force, November 2001. 6979 [34] Erik Nordmark, Gabriel Montenegro, Pekka Nikander, and 6980 Jari Arkko. Mobile IPv6 Security Design Rationale (work in 6981 progress). Internet Draft, Internet Engineering Task Force, 6982 2002. 6984 [35] Erik Nordmark. Securing MIPv6 BUs using Return Routability 6985 (BU3WAY) (work in progress). Internet Draft, Internet 6986 Engineering Task Force, November 2001. 6988 References [1] through [19] are normative and others are informative. 6990 A. Changes from Previous Version of the Draft 6992 This appendix briefly lists some of the major changes in this 6993 draft relative to the previous version of this same draft, 6994 draft-ietf-mobileip-ipv6-18.txt: 6996 A.1. Changes from Draft Version 18 6998 - The draft no longer requires Home Address option and Binding 6999 Error support from all nodes. Similarly, we no longer support 7000 Home Address options protected solely using IPsec (tracked issues 7001 53 and 54). 7003 - Dynamic home agent address advertisement optimizations for 7004 excluding the sender's own address have been aligned with the 7005 priority mechanism (tracked issue 56). 7007 - Units for Binding Update and Acknowledgement lifetimes have been 7008 aligned, and Status code values are now consistent across the 7009 document (tracked issue 58, 91). 7011 - The ability to use link-local and site-local care-of addresses, 7012 home agent addresses, and home addresses has been clarified 7013 (tracked issues 62 and 94). 7015 - Clarified the kind of multicast support provided in the base 7016 Mobile IPv6 specification (tracked issue 63). 7018 - Inconsistencies on using routing headers and Binding 7019 Acknowledgment have been removed (tracked issue 65). 7021 - Semantics for de-registration with the Single Address Only (S) 7022 bit have been specified (tracked issue 66). 7024 - More exact rules for how to use IPsec between the mobile node 7025 and home agent have been provided in this draft as well as in a 7026 separate informative draft (tracked issue 69). 7028 - Rules for when the Alternate Care-of Address mobility option is 7029 needed have been clarified (tracked issue 70). 7031 - Forwarding from previous care-of address has be deprecated 7032 (tracked issue 72). 7034 - New values for MaxRtAdvInterval have been provided (tracked issue 7035 73). 7037 - The rules on how care-of address can be used for some 7038 communications have been clarified (tracked issue 74) 7040 - State machine description has been removed and only the normative 7041 text remains (tracked issue 76). 7043 - Rules for processing Mobility Header messages have been clarified 7044 (tracked issue 77). 7046 - Rules on how to not use Home Address destination option in 7047 Neighbor Discovery packets have been introduced (tracked issue 7048 78). 7050 - Behavior after an address collision has been specified (tracked 7051 issue 79). 7053 - There are no longer specific rules for re-starting return 7054 routability procedure after a Binding Refresh Request has been 7055 received (tracked issue 82). 7057 - It is no longer required to clear the contents of the Binding 7058 Cache upon reboot (tracked issue 83). 7060 - Rules for filling the Home Address field within the Binding Error 7061 message have been clarified (tracked issue 85). 7063 - Binding Acknowledgement length and padding values have been 7064 corrected (tracked issue 87). 7066 - MIN_DELAY_BETWEEN_RAS has been redefined (tracked issue 88). 7068 - The MH Type field has been shortened to 8 bits and MH Length no 7069 longer includes the first 8 bytes (tracked issues 89 and 93). 7071 - It has been clarified that the Home Address option may be used 7072 within the Mobility Header checksum calculation. Also Mobility 7073 Header is considered as an upper layer protocol for the purposes 7074 of checksum calculation (tracked issues 90 and 111). 7076 - Reflection attacks using Binding Acknowledgements have been 7077 prevented (tracked issue 92). 7079 - References to routing headers indicate the type (tracked issue 7080 95). 7082 - The rules for when new nonces are needed have been clarified, as 7083 has the rules for (re-)using keygen tokens (tracked issues 96, 7084 103). 7086 - Binding Refresh Advice type number has been corrected (tracked 7087 issue 97). 7089 - Keygen tokens are now produced with a different formula for home 7090 and care-of tokens (tracked issue 98). 7092 - Binding Acknowledgements with Status code 136-138 are no longer 7093 authenticated (tracked issue 99). 7095 - New requirements have been placed to Section 8. 7097 - The coverage of the Authenticator has been clarified (tracked 7098 issue 106). 7100 - Rules for registering home bindings with the Link-Local Address 7101 Compatibility (L) bit have been improved (tracked issue 108). 7103 - Type 0 routing headers has been specified as orthogonal to type 2 7104 usage (tracked issue 109). 7106 - The inclusion of nonce indices has been made mandatory when 7107 return routability is the authorization method for correspondent 7108 bindings (tracked issue 113). 7110 - Invalid Home and Care-of Test Init messages have to be silently 7111 discarded (tracked issue 114). 7113 - The Binding Authorization Data mobility option is required to be 7114 the last one (tracked issue 115). 7116 - The use of zero lifetime and home addresses in de-registration 7117 and Binding in Refresh Request responses has been clarified 7118 (tracked issue 116). 7120 - Home keygen tokens are now sufficient for de-registration 7121 (tracked issue 117). 7123 - A new Status code has been added to signal the expiry of both 7124 nonces (tracked issue 118). 7126 - Kbm length has been changed to 20 bytes (tracked issue 119). 7128 - Unique Identifier mobility option has been removed (tracked issue 7129 121). 7131 - The security mechanisms and requirements for dynamic home agent 7132 address and prefix discovery have been included (tracked issues 7133 123 and 124). 7135 - Processing order for route headers has been corrected (tracked 7136 issue 125). 7138 - Rate-limiting and retransmission procedures have been combined 7139 and simplified (tracked issues 126 and 136). 7141 - The allowed start time for return routability procedure has been 7142 specified (tracked issue 127). 7144 - Rules for regenerating nonces and Kcn have been changed to 7145 accommodate situations where these values have not been used at 7146 all (tracked issue 131). 7148 - The correspondent node's address which is used in Binding 7149 Authorization Data calculation has been specified to take in 7150 account Home Address destination option (tracked issue 133). 7152 - The matching rules for Home and Care-of Test messages against 7153 sent Init messages have been specified (tracked issue 138). 7155 - Rules for when Home Address destination option may appear in 7156 Binding Updates have been changed and made consistent (tracked 7157 issue 139). 7159 - Authenticator calculation shall precede checksum calculation 7160 (tracked issue 140). 7162 - Rules for sending Binding Acknowledgement errors have been made 7163 consistent (tracked issue 142). 7165 - Invalid authenticator and route optimization not desired Status 7166 values have been removed, and values higher than these have been 7167 renumbered (tracked issues 100). 7169 - The acknowledgement for Mobile Prefix Advertisements is now 7170 Mobile Prefix Solicitation, and not a Binding Update (tracked 7171 issue 144). 7173 - Multiple tries to different home agents are now timed in a manner 7174 that does not cause problems for Duplicate Address Detection 7175 (tracked issue 145). 7177 - Correspondent node binding updates can be secured with also 7178 pre-configured binding management key in addition to return 7179 routability (tracked issue 146). 7181 - Router Advertisement and prefix rules have been clarified 7182 (tracked issue 147). 7184 - Requirements section has been completed to include all necessary 7185 requirements (tracked issue 148). 7187 - Implementations have been given the freedom to implement the 7188 security association - home address check either in the security 7189 policy data base or in the mobile IPv6 code (tracked issue 149). 7191 - A procedure has been provided to deal with failed 7192 de-registration, to ensure that the Binding Acknowledgement still 7193 reaches the mobile node (tracked issue 150). 7195 - Binding Error messages are now sent only to unicast addresses 7196 (tracked issue 151). 7198 - Mobile nodes are now expected to limit their requested bindings 7199 to valid, not preferred, lifetime (tracked issue 152). 7201 - Acknowledgements are now recommended for correspondent bindings 7202 (tracked issue 153). 7204 - A large number of editorial modifications have been performed, 7205 including some restructuring of the document. Some of these 7206 modifications have been tracked as issues 52, 55, 57, 59, 64, 67, 7207 84, 86, 102, 104, 107, 112, 120, 122, 128, 130, 137. 7209 B. Future Extensions 7211 B.1. Piggybacking 7213 This document does not specify how to piggyback payload packets on 7214 the binding related messages. However, it is envisioned that this 7215 can be specified in a separate document when currently discussed 7216 issues such as the interaction between piggybacking and IPsec are 7217 fully resolved (see also Section B.3). The return routability 7218 messages can indicate support for piggybacking with a new mobility 7219 option. 7221 B.2. Triangular Routing and Unverified Home Addresses 7223 Due to the concerns about opening reflection attacks with the Home 7224 Address destination option, this specification requires that this 7225 option must be verified against the Binding Cache, i.e., there must 7226 be a Binding Cache entry for the Home Address and Care-of Address. 7228 Future extensions may be specified that allow the use of unverified 7229 Home Address destination options in ways that do not introduce 7230 security issues. 7232 B.3. New Authorization Methods beyond Return Routability 7234 While the return routability procedure provides a good level 7235 of security, there exists methods that have even higher levels 7236 of security. Secondly, as discussed in Section 14.4, future 7237 enhancements of IPv6 security may cause a need to improve also the 7238 security of the return routability procedure. Using IPsec as the 7239 sole method for authorizing Binding Updates to correspondent nodes 7240 is also possible. The protection of the Mobility Header for this 7241 purpose is easy, though one must ensure that the IPsec SA was created 7242 with appropriate authorization to use the home address referenced 7243 in the Binding Update. For instance, a certificate used by IKE to 7244 create the security association might contain the home address. A 7245 future specification may specify how this is done. 7247 B.4. Security and Dynamically Generated Home Addresses 7249 A future version of this specification may include functionality 7250 that allows the generation of new home addresses without requiring 7251 pre-arranged security associations or certificates even for the new 7252 addresses. 7254 B.5. Remote Home Address Configuration 7256 The method for initializing a mobile node's home addresses on 7257 power-up or after an extended period of being disconnected from 7258 the network is beyond the scope of this specification. Whatever 7259 procedure is used should result in the mobile node having the same 7260 stateless or stateful (e.g., DHCPv6) home address autoconfiguration 7261 information it would have if it were attached to the home network. 7262 Due to the possibility that the home network could be renumbered 7263 while the mobile node is disconnected, a robust mobile node would not 7264 rely solely on storing these addresses locally. 7266 Such a mobile node could initialize by using the following procedure: 7268 1. Generate a care-of address. 7270 2. Query DNS for the home network's mobile agent anycast address. 7272 3. Send a Home Agent Address Discovery Request message to the home 7273 network. 7275 4. Receive Home Agent Address Discovery Reply. 7277 5. Select the most preferred home agent and establish a security 7278 association between the mobile node's current care-of address and 7279 the home agent for temporary use during initialization only. 7281 6. Send a Home Prefix Solicitation with the Request All Prefixes 7282 flag set to the home agent from the mobile node's care-of 7283 address. 7285 7. Receive a Home Prefix Advertisement from the home agent, follow 7286 stateless address autoconfiguration rules to configure home 7287 addresses for prefixes received. 7289 8. Create a security association between the mobile node's home 7290 address and the home agent. 7292 9. Send a Binding Update(s) to the home agent to register the mobile 7293 node's home addresses. 7295 10. Receive Binding Acknowledgement(s) then begin normal 7296 communications. 7298 Chairs' Addresses 7300 The Working Group can be contacted via its current chairs: 7302 Basavaraj Patil Phil Roberts 7303 Nokia Corporation Megisto Corp. 7304 6000 Connection Drive Suite 120 7305 M/S M8-540 20251 Century Blvd 7306 Irving, TX 75039 Germantown MD 20874 7307 USA USA 7308 Phone: +1 972-894-6709 Phone: +1 847-202-9314 7309 Fax : +1 972-894-5349 Email: PRoberts@MEGISTO.com 7310 EMail: Raj.Patil@nokia.com 7312 Authors' Addresses 7314 Questions about this document can also be directed to the authors: 7316 David B. Johnson Charles E. Perkins 7317 Rice University Nokia Research Center 7318 Dept. of Computer Science, MS 132 7319 6100 Main Street 313 Fairchild Drive 7320 Houston, TX 77005-1892 Mountain View, CA 94043 7321 USA USA 7323 Phone: +1 713 348-3063 Phone: +1 650 625-2986 7324 Fax: +1 713 348-5930 Fax: +1 650 625-2502 7325 E-mail: dbj@cs.rice.edu E-mail: charliep@iprg.nokia.com 7327 Jari Arkko 7328 Ericsson 7329 Jorvas 02420 7330 Finland 7332 Phone: +358 40 5079256 7333 E-mail: jari.arkko@ericsson.com