idnits 2.17.1 draft-ietf-mobileip-ipv6-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 45: '...e or stationary, MUST support communic...' RFC 2119 keyword, line 821: '... security policy database entries MUST...' RFC 2119 keyword, line 824: '... is made, the mobile node MUST use the...' RFC 2119 keyword, line 1178: '...bility procedure MUST NOT exceed MAX_R...' RFC 2119 keyword, line 1183: '... MAY be specified by including an Al...' (605 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 June 2002) is 7993 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) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '23' ** Obsolete normative reference: RFC 2267 (ref. '24') (Obsoleted by RFC 2827) -- Possible downref: Non-RFC (?) normative reference: ref. '25' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '26') -- Possible downref: Normative reference to a draft: ref. '29' -- Possible downref: Normative reference to a draft: ref. '30' == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-01 -- Possible downref: Normative reference to a draft: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '32' -- Possible downref: Normative reference to a draft: ref. '33' Summary: 23 errors (**), 0 flaws (~~), 2 warnings (==), 11 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 1 June 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 the IPv6 Internet with mobile 34 computers. Each mobile node is always identified by its home 35 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, MUST support communications with mobile 46 nodes. 48 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 1 56 2. Comparison with Mobile IP for IPv4 2 58 3. Terminology 3 59 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 4 62 4. Overview of Mobile IPv6 7 63 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 9 65 4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 10 66 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 10 67 4.5. Conceptual Data Structures . . . . . . . . . . . . . . . 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 . . . . . . . . . 12 72 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . 13 73 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . 13 74 5.2.3. Cookies . . . . . . . . . . . . . . . . . . . . . 14 75 5.2.4. Cryptographic Functions . . . . . . . . . . . . . 14 76 5.2.5. Return Routability Procedure . . . . . . . . . . 14 77 5.2.6. Applying Return Routability for Correspondent 78 Bindings . . . . . . . . . . . . . . . . . 18 79 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . 20 80 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . 20 81 5.3. Payload Packets . . . . . . . . . . . . . . . . . . . . . 21 83 6. New IPv6 Protocols, Message Types, and Destination Option 21 84 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 21 85 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 22 86 6.1.2. Binding Refresh Request (BRR) Message . . . . . . 23 87 6.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 24 88 6.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 26 89 6.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 27 90 6.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 28 91 6.1.7. Binding Update (BU) Message . . . . . . . . . . . 29 92 6.1.8. Binding Acknowledgement (BA) Message . . . . . . 32 93 6.1.9. Binding Error (BE) Message . . . . . . . . . . . 34 94 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 35 95 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 35 96 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 36 97 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 37 98 6.2.4. Unique Identifier . . . . . . . . . . . . . . . . 37 99 6.2.5. Alternate Care-of Address . . . . . . . . . . . . 38 100 6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 38 101 6.2.7. Binding Authorization Data . . . . . . . . . . . 39 102 6.2.8. Binding Refresh Advice . . . . . . . . . . . . . 39 103 6.3. Home Address Destination Option . . . . . . . . . . . . . 40 104 6.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 42 105 6.4.1. Routing Header Packet format . . . . . . . . . . 42 106 6.5. ICMP Home Agent Address Discovery Request Message . . . . 43 107 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 45 108 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 47 109 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 49 111 7. Modifications to IPv6 Neighbor Discovery 51 112 7.1. Modified Router Advertisement Message Format . . . . . . 51 113 7.2. Modified Prefix Information Option Format . . . . . . . . 52 114 7.3. New Advertisement Interval Option Format . . . . . . . . 54 115 7.4. New Home Agent Information Option Format . . . . . . . . 55 116 7.5. Changes to Sending Router Advertisements . . . . . . . . 57 117 7.6. Changes to Sending Router Solicitations . . . . . . . . . 58 119 8. Requirements for Types of IPv6 Nodes 59 120 8.1. General Requirements for All IPv6 Nodes . . . . . . . . . 59 121 8.2. Route Optimization Requirements for All IPv6 Nodes . . . 59 122 8.3. Requirements for All IPv6 Routers . . . . . . . . . . . . 60 123 8.4. Requirements for IPv6 Home Agents . . . . . . . . . . . . 61 124 8.5. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 62 126 9. Correspondent Node Operation 63 127 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 63 128 9.2. Receiving Packets from a Mobile Node . . . . . . . . . . 64 129 9.2.1. Processing Mobility Header (MH) Messages . . . . 64 130 9.2.2. Receiving Packets with Home Address Destination 131 Option . . . . . . . . . . . . . . . . . . 65 132 9.3. Return Routability Procedure . . . . . . . . . . . . . . 66 133 9.3.1. Receiving Home Test Init Messages . . . . . . . . 66 134 9.3.2. Receiving Care-of Test Init Messages . . . . . . 66 135 9.3.3. Sending Home Test Messages . . . . . . . . . . . 67 136 9.3.4. Sending Care-of Test Messages . . . . . . . . . . 67 137 9.4. Processing Bindings . . . . . . . . . . . . . . . . . . . 67 138 9.4.1. Receiving Binding Updates . . . . . . . . . . . . 67 139 9.4.2. Requests to Cache a Binding . . . . . . . . . . . 69 140 9.4.3. Requests to Delete a Binding . . . . . . . . . . 69 141 9.4.4. Sending Binding Acknowledgements . . . . . . . . 70 142 9.4.5. Sending Binding Refresh Requests . . . . . . . . 71 143 9.4.6. Sending Binding Error Messages . . . . . . . . . 71 144 9.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 71 145 9.6. Sending Packets to a Mobile Node . . . . . . . . . . . . 72 146 9.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 73 148 10. Home Agent Operation 74 149 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 74 150 10.2. Primary Care-of Address Registration . . . . . . . . . . 75 151 10.3. Primary Care-of Address De-Registration . . . . . . . . . 79 152 10.4. Intercepting Packets for a Mobile Node . . . . . . . . . 80 153 10.5. Tunneling Intercepted Packets to a Mobile Node . . . . . 81 154 10.6. Handling Reverse Tunneled Packets from a Mobile Node . . 83 155 10.7. Protecting Return Routability Packets . . . . . . . . . . 83 156 10.8. Receiving Router Advertisement Messages . . . . . . . . . 84 157 10.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 85 158 10.9.1. Aggregate List of Home Network Prefixes . . . . . 87 159 10.9.2. Scheduling Prefix Deliveries to the Mobile Node . 89 160 10.9.3. Sending Advertisements to the Mobile Node . . . . 90 161 10.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 91 163 11. Mobile Node Operation 91 164 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 91 165 11.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 93 166 11.2.1. Sending Packets While Away from Home . . . . . . 93 167 11.2.2. Interaction with Outbound IPsec Processing . . . 96 168 11.2.3. Receiving Packets While Away from Home . . . . . 97 169 11.2.4. Routing Multicast Packets . . . . . . . . . . . . 99 170 11.3. Home Agent and Prefix Management . . . . . . . . . . . . 100 171 11.3.1. Receiving Local Router Advertisement Messages . . 100 172 11.3.2. Dynamic Home Agent Address Discovery . . . . . . 101 173 11.3.3. Sending Mobile Prefix Solicitations . . . . . . . 102 174 11.3.4. Receiving Mobile Prefix Advertisements . . . . . 103 175 11.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . 104 176 11.4.1. Movement Detection . . . . . . . . . . . . . . . 104 177 11.4.2. Forming New Care-of Addresses . . . . . . . . . . 107 178 11.4.3. Using Multiple Care-of Addresses . . . . . . . . 108 179 11.5. Return Routability Procedure . . . . . . . . . . . . . . 109 180 11.5.1. Sending Home and Care-of Test Init Messages . . . 109 181 11.5.2. Receiving Return Routability Messages . . . . . . 109 182 11.5.3. Retransmitting in the Return Routability Procedure 111 183 11.5.4. Rate Limiting for Return Routability Procedure . 111 184 11.6. Processing Bindings . . . . . . . . . . . . . . . . . . . 111 185 11.6.1. Sending Binding Updates to the Home Agent . . . . 111 186 11.6.2. Correspondent Binding Procedure . . . . . . . . . 114 187 11.6.3. Receiving Binding Acknowledgements . . . . . . . 117 188 11.6.4. Receiving Binding Refresh Requests . . . . . . . 118 189 11.6.5. Receiving Binding Error Messages . . . . . . . . 119 190 11.6.6. Forwarding from a Previous Care-of Address . . . 120 191 11.6.7. Returning Home . . . . . . . . . . . . . . . . . 121 192 11.6.8. Retransmitting Binding Updates . . . . . . . . . 123 193 11.6.9. Rate Limiting Binding Updates . . . . . . . . . . 124 194 11.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 124 196 12. Protocol Constants 125 198 13. IANA Considerations 126 199 14. Security Considerations 127 200 14.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 127 201 14.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 129 202 14.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 130 203 14.4. Binding Updates to Correspondent Nodes . . . . . . . . . 132 204 14.4.1. Overview . . . . . . . . . . . . . . . . . . . . 132 205 14.4.2. Offered Protection . . . . . . . . . . . . . . . 132 206 14.4.3. Comparison to Regular IPv6 Communications . . . . 133 207 14.4.4. Return Routability Replays . . . . . . . . . . . 135 208 14.4.5. Return Routability Denial-of-Service . . . . . . 135 209 14.5. Tunneling via the Home Agent . . . . . . . . . . . . . . 136 210 14.6. Home Address Destination Option . . . . . . . . . . . . . 137 211 14.7. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 138 213 Acknowledgements 138 215 References 140 217 A. State Machine for the Correspondent Binding Procedure 142 218 A.1. Main State Machine . . . . . . . . . . . . . . . . . . . 143 219 A.2. Return Routability Procedure . . . . . . . . . . . . . . 149 221 B. Changes from Previous Version of the Draft 153 223 C. Future Extensions 154 224 C.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 154 225 C.2. Triangular Routing and Unverified Home Addresses . . . . 154 226 C.3. New Authorization Methods beyond Return Routability . . . 155 227 C.4. Security and Dynamically Generated Home Addresses . . . . 155 228 C.5. Remote Home Address Configuration . . . . . . . . . . . . 155 230 Chairs' Addresses 157 232 Authors' Addresses 157 233 1. Introduction 235 This document specifies how the IPv6 Internet operates with mobile 236 computers. Without specific support for mobility in IPv6 [11], 237 packets destined to a mobile node would not be able to reach it while 238 the mobile node is away from its home link. In order to continue 239 communication in spite of its movement, a mobile node could change 240 its IP address each time it moves to a new link, but the mobile 241 node would then not be able to maintain transport and higher-layer 242 connections when it changes location. Mobility support in IPv6 is 243 particularly important, as mobile computers are likely to account for 244 a majority or at least a substantial fraction of the population of 245 the Internet during the lifetime of IPv6. 247 The protocol defined in this document, known as Mobile IPv6, allows 248 a mobile node to move from one link to another without changing the 249 mobile node's IP address. A mobile node is always addressable by 250 its "home address", an IP address assigned to the mobile node within 251 its home subnet prefix on its home link. Packets may be routed to 252 the mobile node using this address regardless of the mobile node's 253 current point of attachment to the Internet. The mobile node may 254 also continue to communicate with other nodes (stationary or mobile) 255 after moving to a new link. The movement of a mobile node away from 256 its home link is thus transparent to transport and higher-layer 257 protocols and applications. 259 The Mobile IPv6 protocol is just as suitable for mobility across 260 homogeneous media as for mobility across heterogeneous media. For 261 example, Mobile IPv6 facilitates node movement from one Ethernet 262 segment to another as well as it facilitates node movement from an 263 Ethernet segment to a wireless LAN cell, with the mobile node's IP 264 address remaining unchanged in spite of such movement. 266 One can think of the Mobile IPv6 protocol as solving the 267 network-layer mobility management problem. Some mobility management 268 applications -- for example, handover among wireless transceivers, 269 each of which covers only a very small geographic area -- have been 270 solved using link-layer techniques. For example, in many current 271 wireless LAN products, link-layer mobility mechanisms allow a 272 "handover" of a mobile node from one cell to another, reestablishing 273 link-layer connectivity to the node in each new location. 275 Mobile IP does not attempt to solve all general problems related to 276 the use of mobile computers or wireless networks. In particular, 277 this protocol does not attempt to solve: 279 - Handling links with partial reachability, or unidirectional 280 connectivity, such as are often found in wireless networks (but 281 see Section 11.4.1). 283 - Access control on a link being visited by a mobile node. 285 - Local or hierarchical forms of mobility management (similar to 286 many current link-layer mobility management solutions). 288 - Assistance for adaptive applications 290 - Mobile routers 292 - Service Discovery 294 - Distinguishing between packets lost due to bit errors vs. 295 network congestion 297 2. Comparison with Mobile IP for IPv4 299 The design of Mobile IP support in IPv6 (Mobile IPv6) represents a 300 natural combination of the experiences gained from the development of 301 Mobile IP support in IPv4 (Mobile IPv4) [20, 21, 22], together with 302 the opportunities provided by IPv6. Mobile IPv6 thus shares many 303 features with Mobile IPv4, but is integrated into IP and provides 304 many improvements. This section summarizes the major differences 305 between Mobile IPv4 and Mobile IPv6: 307 - There is no longer any need to deploy special routers as 308 "foreign agents" as are used in Mobile IPv4. In Mobile IPv6, 309 mobile nodes make use of IPv6 features, to operate in any 310 location without any special support required from the local 311 router. 313 - Support for what is known in Mobile IPv4 as "route 314 optimization" [23] is now built in as a fundamental part 315 of the protocol, rather than being added on as an optional set 316 of extensions that may not be supported by all nodes as in 317 Mobile IPv4. 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" [24]. Both the current care-of address and 327 the home address can be carried in packets, allowing packets to 328 pass normally through ingress filtering routers. 330 - In Mobile IPv6, the mobile node does not have to tunnel multicast 331 packets to its home agent. The inclusion of the home address in 332 packets is compatible with multicast routing that is based in 333 part on the packet's Source Address. 335 - The movement detection mechanism in Mobile IPv6 provides 336 bidirectional confirmation of a mobile node's ability to 337 communicate with its default router in its current location. 339 - Most packets sent to a mobile node while away from home in 340 Mobile IPv6 are sent using an IPv6 Routing header rather than IP 341 encapsulation, reducing the amount of resulting overhead compared 342 to Mobile IPv4. 344 - Mobile IPv6 is decoupled from any particular link layer, as it 345 uses IPv6 Neighbor Discovery [12] instead of ARP. This also 346 improves the robustness of the protocol. 348 - The use of IPv6 encapsulation (and the Routing header) removes 349 the need in Mobile IPv6 to manage "tunnel soft state". 351 - The dynamic home agent address discovery mechanism in Mobile IPv6 352 returns a single reply to the mobile node. The directed 353 broadcast approach used in IPv4 returns separate replies from 354 each home agent. 356 3. Terminology 358 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 359 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 360 document are to be interpreted as described in RFC 2119 [2]. 362 3.1. General Terms 364 IP Internet Protocol Version 6 (IPv6). 366 node A device that implements IP. 368 router A node that forwards IP packets not explicitly 369 addressed to itself. 371 host Any node that is not a router. 373 link A communication facility or medium over which nodes 374 can communicate at the link layer, such as an 375 Ethernet (simple or bridged). A link is the layer 376 immediately below IP. 378 interface A node's attachment to a link. 380 subnet prefix 381 A bit string that consists of some number of initial 382 bits of an IP address. 384 interface identifier 385 A number used to identify a node's interface on a 386 link. The interface identifier is the remaining 387 low-order bits in the node's IP address after the 388 subnet prefix. 390 link-layer address 391 A link-layer identifier for an interface, such as 392 IEEE 802 addresses on Ethernet links. 394 packet An IP header plus payload. 396 security association 397 A security object shared between two nodes which 398 includes the data mutually agreed on for operation 399 of some cryptographic algorithm (typically including 400 a key). 402 security policy database 403 A database of rules that describe what security 404 associations should be applied for different kinds 405 of packets. 407 destination option Destination options are carried by the IPv6 408 Destination Options extension header. Mobile IPv6 409 defines one new destination option, the Home Address 410 destination option. 412 3.2. Mobile IPv6 Terms 414 home address An IP address assigned to a mobile node, used as the 415 permanent address of the mobile node. This address 416 is within the mobile node's home link. Standard IP 417 routing mechanisms will deliver packets destined for 418 a mobile node's home address to its home link. 420 home subnet prefix 421 The IP subnet prefix corresponding to a mobile 422 node's home address. 424 home link The link on which a mobile node's home subnet prefix 425 is defined. 427 mobile node A node that can change its point of attachment from 428 one link to another, while still being reachable via 429 its home address. 431 movement A change in a mobile node's point of attachment to 432 the Internet such that it is no longer connected to 433 the same link as it was previously. If a mobile 434 node is not currently attached to its home link, the 435 mobile node is said to be "away from home". 437 correspondent node 438 A peer node with which a mobile node is 439 communicating. The correspondent node may be either 440 mobile or stationary. 442 foreign subnet prefix 443 Any IP subnet prefix other than the mobile node's 444 home subnet prefix. 446 foreign link Any link other than the mobile node's home link. 448 care-of address 449 An IP address associated with a mobile node while 450 visiting a foreign link; the subnet prefix of this 451 IP address is a foreign subnet prefix. Among the 452 multiple care-of addresses that a mobile node may 453 have at any given time (e.g., with different subnet 454 prefixes), the one registered with the mobile node's 455 home agent is called its "primary" care-of address. 457 home agent A router on a mobile node's home link with which 458 the mobile node has registered its current care-of 459 address. While the mobile node is away from home, 460 the home agent intercepts packets on the home 461 link destined to the mobile node's home address, 462 encapsulates them, and tunnels them to the mobile 463 node's registered care-of address. 465 binding The association of the home address of a mobile node 466 with a care-of address for that mobile node, along 467 with the remaining lifetime of that association. 469 binding procedure 470 A binding procedure is initiated by the mobile node 471 to inform either a correspondent node or the mobile 472 node's home agent of the current binding of the 473 mobile node. 475 binding authorization 476 Binding procedure needs to be authorized to allow 477 the recipient to believe that the sender has the 478 right to specify a new binding. 480 return routability procedure 481 The return routability procedure authorizes binding 482 procedures by the use of a cryptographic cookie 483 exchange. 485 correspondent binding procedure 486 A return routability procedure followed by a 487 binding procedure, run between the mobile node and a 488 correspondent node. 490 home binding procedure 491 A binding procedure between the mobile node and its 492 home agent, authorized by the use of IPsec. 494 nonce Nonces are random numbers used internally by the 495 correspondent node in the creation of cookies 496 related to the return routability procedure. The 497 nonces are not specific to a mobile node, and are 498 kept secret within the correspondent node, only used 499 as one input in the creation of the cookies. 501 cookie Cookies are numbers that are used by mobile nodes 502 and correspondent nodes in the return routability 503 procedure. 505 care-of cookie 506 A cookie sent directly to the mobile node's claimed 507 care-of address from the correspondent node. 509 home cookie A cookie sent to the mobile node's claimed home 510 address from the correspondent node. 512 mobile cookie 513 A cookie sent to the correspondent node from the 514 mobile node, and later returned to the mobile node. 515 Mobile cookies are produced randomly. There are two 516 kinds of mobile cookies: the HoT cookie and the CoT 517 cookie. 519 CoT cookie 520 A cookie sent by the mobile node to the the 521 correspondent node in the CoTI message, to be 522 returned to the mobile node in the CoT message. 524 HoT cookie 525 A cookie sent by the mobile node to the the 526 correspondent node in the HoTI message, to be 527 returned to the mobile node in the HoT message. 529 nonce index 530 The mobile node uses a particular set of cookies in 531 the return routability procedure. The cookies have 532 been produced using a particular set of nonces. A 533 nonce index is used to indicate which nonces have 534 been used, without revealing the nonces themselves. 536 binding key 537 a key used for authenticating binding cache 538 management messages. 540 binding security association 541 a security association established specifically 542 for the purpose of producing and verifying 543 authentication data passed with a Binding 544 Authorization Data option. 546 4. Overview of Mobile IPv6 548 4.1. Basic Operation 550 A mobile node is always addressable at its home address, whether it 551 is currently attached to its home link or is away from home. While 552 a mobile node is at home, packets addressed to its home address 553 are routed to it using conventional Internet routing mechanisms in 554 the same way as if the node were stationary. The subnet prefix of 555 a mobile node's home address is one of the subnet prefixes of the 556 mobile node's home link. Packets addressed to the mobile node will 557 therefore be routed to its home link. 559 While a mobile node is attached to some foreign link away from home, 560 it is also addressable at one or more care-of addresses. A care-of 561 address is an IP address associated with a mobile node while visiting 562 a particular foreign link. The subnet prefix of a mobile node's 563 care-of address is one of the subnet prefixes on the foreign link. 564 As long as the mobile node stays in this location, packets addressed 565 to this care-of address will be routed to the mobile node. 567 The association between a mobile node's home address and care-of 568 address is known as a "binding" for the mobile node. A mobile node 569 typically acquires its care-of address through stateless [13] or 570 stateful (e.g., DHCPv6 [25]) Address Autoconfiguration, according 571 to the methods of IPv6 Neighbor Discovery [12]. Other methods 572 of acquiring a care-of address are also possible, but are beyond 573 the scope of this document. The operation of the mobile node is 574 specified in Section 11. 576 While away from home, a mobile node registers one of its care-of 577 addresses with a router on its home link, requesting this router to 578 function as the "home agent" for the mobile node. The mobile node 579 performs this binding registration by sending a "Binding Update" 580 message to the home agent. The home agent replies to the mobile 581 node by returning a "Binding Acknowledgement" message. The care-of 582 address associated with this binding registration is known as the 583 mobile node's "primary care-of address". The mobile node's home 584 agent thereafter uses proxy Neighbor Discovery to intercept any 585 IPv6 packets addressed to the mobile node's home address (or home 586 addresses) on the home link. Each intercepted packet is tunneled 587 to the mobile node's primary care-of address. This tunneling 588 is performed using IPv6 encapsulation [15], with the outer IPv6 589 header addressed to the mobile node's primary care-of address. The 590 operation of the home agent is specified in Section 10. 592 Any node communicating with a mobile node is referred to in this 593 document as a "correspondent node" of the mobile node, and may itself 594 be either a stationary node or a mobile node. The operation of the 595 correspondent node is specified in Section 9. Mobile nodes can 596 inform the correspondent nodes of the current location of the mobile 597 node. This happens through the correspondent binding procedure. As 598 a part of this procedure, a return routability test is performed 599 in order to authorize the establishment of the binding. This is 600 specified in Sections 5.2.5 and 5.2.6. When sending a packet to 601 any IPv6 destination, a node checks its cached bindings for an 602 entry for the packet's destination address. If a cached binding 603 for this destination address is found, the node uses a new type of 604 IPv6 Routing header [11] (see section 6.4) to route the packet to 605 the mobile node by way of the care-of address indicated in this 606 binding. If, instead, the sending node has no cached binding for 607 this destination address, the node sends the packet normally (with 608 no Routing header), and the packet is subsequently intercepted and 609 tunneled by the mobile node's home agent as described above. When a 610 mobile node receives a packet tunneled to it in this manner, it can 611 use this as an indication that the correspondent node has no binding 612 for the mobile node. The mobile node can then establish a binding 613 with the correspondent node. 615 It is expected that correspondent nodes usually will route packets 616 directly to the mobile node's care-of address, so that the home agent 617 is rarely involved with packet transmission to the mobile node. This 618 is important for scalability and reliability, and for minimizing 619 overall network load. Routing packets directly to the mobile node's 620 care-of address also eliminates congestion at the mobile node's home 621 agent and home link. In addition, the impact of any possible failure 622 of the home agent, the home link, or intervening networks leading to 623 or from the home link is reduced, since these nodes and links are not 624 involved in the delivery of most packets to the mobile node. 626 Mobile IPv6 defines a new IPv6 destination option. When a mobile 627 node sends a packet while away from home, it could generally use 628 a tunnel via the home agent to send this packet. However, if the 629 correspondent node in question has a binding for this mobile node, 630 the mobile node can deliver packets directly to the correspondent 631 node. The mobile node sets the Source Address in the packet's IPv6 632 header to one of its current care-of addresses, and include a "Home 633 Address" destination option in the packet, giving the mobile node's 634 home address. By also including the Home Address destination option 635 in each packet, the sending mobile node can communicate its home 636 address to the correspondent node receiving this packet. This makes 637 the use of the care-of address transparent above the Mobile IPv6 638 support level (e.g., at the transport layer). 640 It is possible that while a mobile node is away from home, some nodes 641 on its home link may be reconfigured. The router that was operating 642 as the mobile node's home agent can be replaced by a different 643 router serving the same role. In this case, the mobile node may not 644 know the IP address of its own home agent. Mobile IPv6 provides a 645 mechanism, known as "dynamic home agent address discovery", that 646 allows a mobile node to dynamically discover the IP address of a 647 home agent on its home link with which it may register its (primary) 648 care-of address while away from home. The mobile node sends an ICMP 649 "Home Agent Address Discovery Request" message to the "Mobile IPv6 650 Home-Agents" anycast address for its own home subnet prefix [16] and 651 thus reaches one of the routers on its home link currently operating 652 as a home agent. This home agent then returns an ICMP "Home Agent 653 Address Discovery Reply" message to the mobile node, including a list 654 of home agents on the home link. This procedure is specified in 655 Sections 10.9 and 11.3.2. 657 When a mobile node arrives to a new link and allocates a new care-of 658 address, it is desirable for packets arriving at the previous care-of 659 address to still reach the mobile node. The mobile node may still 660 accept packets at the previous address, if it is still attached to 661 the previous link as well as the new one. This is discussed in 662 Section 11.4.3. If the mobile node is no longer attached to the 663 previous link, procedures described in Section 11.6.6 may be used to 664 establish temporary tunneling from the previous link. 666 4.2. New IPv6 Protocols 668 Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header 669 (see Section 6.1). This Header is used to carry the following 670 messages: 672 Home Test Init 673 Home Test 674 Care-of Test Init 675 Care-of Test 677 These four messages are used to initiate the return routability 678 procedure from the mobile node to a correspondent node. This 679 ensures authorization of subsequent Binding Updates, as 680 described in Section 5.2.5. The format of the messages are 681 defined in Sections 6.1.3 through 6.1.6. 683 Binding Update 685 A Binding Update message is used by a mobile node to notify 686 a correspondent node or the mobile node's home agent of its 687 current binding. The Binding Update sent to the mobile node's 688 home agent to register its primary care-of address is marked as 689 a "home registration". The Binding Update message is described 690 in detail in Section 6.1.7. 692 Binding Acknowledgement 694 A Binding Acknowledgement message is used to acknowledge 695 receipt of a Binding Update, if an acknowledgement was 696 requested in the Binding Update. The Binding Acknowledgement 697 message is described in detail in Section 6.1.8. 699 Binding Refresh Request 701 A Binding Refresh Request message is used to request a mobile 702 node to re-establish its binding with the correspondent node. 703 This message is typically used when the cached binding is in 704 active use but the binding's lifetime is close to expiration. 705 The correspondent node may use, for instance, recent traffic 706 and open transport layer connections as an indication of active 707 use. The Binding Refresh Request message is described in 708 detail in Section 6.1.2. 710 Binding Error 712 The Binding Error message is used by the correspondent node to 713 signal an error related to mobility, such as an inappropriate 714 attempt to use the Home Address destination option without 715 an existing binding. This message is described in detail in 716 Section 6.1.9. 718 4.3. New IPv6 Destination Options 720 Mobile IPv6 defines a new IPv6 destination option, the Home 721 Address destination option. This option is described in detail in 722 Section 6.3. 724 4.4. New IPv6 ICMP Messages 726 Mobile IPv6 also introduces four new ICMP message types, two for use 727 in the dynamic home agent address discovery mechanism, and two for 728 renumbering and mobile configuration mechanisms. As discussed in 729 general in Section 4.1, the following two new ICMP message types are 730 used for home agent address discovery: 732 - Home Agent Address Discovery Request, described in Section 6.5. 734 - Home Agent Address Discovery Reply, described in Section 6.6. 736 The next two message types are used for network renumbering 737 and address configuration on the mobile node, as described in 738 Section 10.9.1: 740 - Mobile Prefix Solicitation, described in Section 6.7. 742 - Mobile Prefix Advertisement, described in Section Section 10.9.3. 744 4.5. Conceptual Data Structures 746 This document describes the Mobile IPv6 protocol in terms of the 747 following three conceptual data structures: 749 Binding Cache 751 A cache, maintained by each IPv6 node, of bindings for other 752 nodes. A separate Binding Cache is maintained by each IPv6 753 node for each of its IPv6 addresses. When sending a packet, 754 the Binding Cache is searched before the Neighbor Discovery 755 conceptual Destination Cache [12]. 757 The Binding Cache for any one of a node's IPv6 addresses may 758 contain at most one entry for each mobile node home address. 759 The contents of all of a node's Binding Cache entries are 760 cleared when it reboots. 762 Binding Cache entries are marked either as "home registration" 763 entries or "correspondent registration" entries. Home 764 registration entries are deleted when its binding lifetime 765 expires, while other entries may be replaced at any time 766 through a local cache replacement policy. 768 Binding Update List 770 A list, maintained by each mobile node, recording information 771 for each Binding Update sent by this mobile node, for which the 772 Lifetime sent in that Binding Update has not yet expired. The 773 Binding Update List includes all bindings sent by the mobile 774 node: those to correspondent nodes, those to the mobile node's 775 home agent, and those to a home agent on the link on which the 776 mobile node's previous care-of address is located. 778 Home Agents List 780 A list, maintained by each home agent and each mobile node, 781 recording information about each home agent from which this 782 node has recently received a Router Advertisement in which the 783 Home Agent (H) bit is set. This list is similar to the Default 784 Router List conceptual data structure maintained by each host 785 for Neighbor Discovery [12]. 787 Each home agent maintains a separate Home Agents List for each 788 link on which it is serving as a home agent; this list is used 789 by a home agent in the dynamic home agent address discovery 790 mechanism. Each mobile node, while away from home, also 791 maintains a Home Agents List, to enable it to notify a home 792 agent on its previous link when it moves to a new link. 794 5. Overview of Mobile IPv6 Security 796 This specification provides a number of security features. These 797 include the protection of Binding Updates both to home agents and 798 correspondent nodes, and the protection of tunnels, home address 799 information, and routing instructions in data packets. 801 5.1. Binding Updates to Home Agents 803 Signaling between the mobile node and the home agent requires message 804 integrity, correct ordering and replay protection. 806 The mobile node and the home agent must have an security association 807 to protect this signaling. Authentication Header (AH) or 808 Encapsulating Security Payload (ESP) can be used for integrity 809 protection. For ESP we require that a non-null authentication 810 algorithm is applied. 812 Mobile IPv6 provides its own ordering mechanism inside the Binding 813 Update and Acknowledgement messages. A sequence number field is 814 used, as described in Section 6.1.7. 816 In order to protect messages exchanged between the mobile node and 817 the home agent with IPsec, appropriate security policy database 818 entries must be created. We need to avoid the possibility that a 819 mobile node could use its security association to send a Binding 820 Update on behalf of another mobile node using the same home agent. 821 In order to do this, the security policy database entries MUST 822 unequivocally identify a single SA for any given home address and 823 home agent. In order for the home address of the mobile node to be 824 visible when the policy check is made, the mobile node MUST use the 825 Home Address destination option in Binding Updates sent to the home 826 agent. 828 5.2. Binding Updates to Correspondent Nodes 830 Binding Updates to correspondent nodes can be protected by using data 831 exchanged during the return routability procedure. We will first 832 discuss a number of preliminary concepts such as node keys, nonces, 833 and cookies and the cryptographic functions used. Section 5.2.5 834 outlines the basic return routability procedure. Section 5.2.6 shows 835 how the results of this procedure are used to authorize a Binding 836 Update to a correspondent node. Finally, Sections 5.2.7 and 5.2.8 837 discuss some additional issues. 839 5.2.1. Node Keys 841 Each correspondent node has a secret key, Kcn. The correspondent 842 node uses this key to verify that the cookies it receives in messages 843 are those which it has created itself. This key does not need to be 844 shared with any other entity. 846 A correspondent node can generate a fresh Kcn each time that it boots 847 to avoid the need for secure persistent storage for Kcn. Kcn can be 848 either a fixed value or regularly updated. Procedures for updating 849 Kcn are discussed later in Section 5.2.7. 851 Kcn consists of 20 octets. 853 5.2.2. Nonces 855 Each correspondent node also generates nonces at regular intervals, 856 for example every few minutes. The nonces should be generated by 857 using a random number generator that is known to have good randomness 858 properties [1]. A correspondent node may use the same Kcn and nonce 859 with all the mobiles it is in communication with, so that it does not 860 need to generate and store a new nonce when a new mobile contacts it. 862 Each nonce is identified by a nonce index. Nonce indices are 863 16-bit values that are e.g. incremented each time a new nonce is 864 created. The index value is communicated in the protocol, so that if 865 a nonce is replaced by new nonce during the run of a protocol, the 866 correspondent node can distinguish messages that should be checked 867 against the old nonce from messages that should be checked against 868 the new nonce. Strictly speaking, indices are not necessary in the 869 authentication, but allow the correspondent node to efficiently find 870 the nonce value that it used in creating a cookie. 872 Correspondent nodes keep both the current nonce and a small set of 873 old nonces. Older values can be discarded, and messages using them 874 will be rejected as replays. 876 The specific nonce index values can not be used by mobile nodes to 877 determine the validity of the nonce. Expected validity times for 878 the nonces values and the procedures for updating them are discussed 879 later in Section 5.2.7. 881 Nonce is an octet string of any length. The recommended length is 882 64-bit. 884 5.2.3. Cookies 886 Three different types of cookies are used in the protocol: 888 - Two mobile cookies are sent to the correspondent node from the 889 mobile node, and later returned to the mobile node. The mobile 890 cookies are produced randomly, and used to verify that the 891 response matches the request, and to ensure that parties who have 892 not seen the request can not spoof responses. One of the mobile 893 cookies is sent in the HoTI message, and returned in the HoT 894 message. This is called the HoT cookie. The other mobile cookie 895 is sent in the CoTI message, and returned in the CoT message. 896 This is called the CoT cookie. 898 - A home cookie sent to the mobile node from the correspondent node 899 via the home agent. Home cookies are produced cryptographically 900 from nonces. 902 - A care-of cookie is similar to a home cookie, but sent directly 903 to the mobile node from the correspondent node. 905 A newly generated random number is typically used for each request 906 that carries a mobile cookie. 908 Home and care-of cookies are produced by the correspondent node, and 909 they are based on the currently active secret keys and nonces of the 910 correspondent node as well as the home or care-of address. Such a 911 cookie is valid as long as both the secret key and the nonce used to 912 create it are valid. 914 5.2.4. Cryptographic Functions 916 MAC_K(m) denotes a Message Authentication Code computed on message 917 m with key K. In this specification, HMAC SHA1 function [26, 19] is 918 used to compute these codes. 920 Hash(m) denotes a hash of message m. In this specification, the 921 function used to compute the hash is SHA1 [19]. 923 5.2.5. Return Routability Procedure 925 The return routability signaling happens as follows: 927 Mobile node Home agent Correspondent node 928 | | 929 | 1a. | 930 | Home Test Init(HoTI) | 931 | Src = home address, | 932 | Dst = correspondent | | 933 | Parameters: | | 934 | - HoT cookie | | 935 |------------------------->|------------------------->| 936 | | | 937 | | 938 | 1b. | 939 | Care-of Test Init(CoTI) | 940 | Src = care-of address | 941 | Dst = correspondent | 942 | Parameters: | 943 | - CoT cookie | 944 |---------------------------------------------------->| 945 | | 946 | 2a. | 947 | Home Test (HoT) | 948 | Src = correspondent, | 949 | Dst = home address | 950 | Parameters: | 951 | - HoT cookie | 952 | | - home cookie | 953 | | - home nonce index | 954 |<-------------------------|<-------------------------| 955 | | | 956 | | 957 | 2b. | 958 | Care-of Test(CoT) | 959 | Src = correspondent, | 960 | Dst = care-of address | 961 | Parameters: | 962 | - CoT cookie | 963 | - care-of cookie | 964 | - care-of nonce index | 965 |<----------------------------------------------------| 966 | | 968 The Home and Care-of Test Init messages are sent at the same 969 time. The correspondent node returns the Home and Care-of Test 970 messages as quickly as possible, and perhaps nearly simultaneously, 971 requiring very little processing. Those four messages form the 972 return routability procedure. Due to the nearly simultaneous 973 message delivery, the return routability procedure completes in about 974 roundtrip between the mobile node and the correspondent. 976 1a. Home Test Init 978 A mobile node sends a Home Test Init message to the 979 correspondent node to acquire the home cookie. The contents of 980 the message can be summarized as follows: 982 Src = home address 983 Dst = correspondent 984 Parameters: 985 - HoT cookie 987 This message conveys the mobile node's home address to the 988 correspondent node. The mobile node also sends along a 64 bit 989 HoT cookie that the correspondent node must return later. The 990 Home Test Init message is reverse tunneled through the home 991 agent. 993 1b. Care-of Test Init 995 The mobile node sends a Care-of Test Init message to the 996 correspondent node to acquire the care-of cookie. The contents 997 of this message can be summarized as follows: 999 Src = care-of address 1000 Dst = correspondent 1001 Parameters: 1002 - CoT cookie 1004 The second message conveys the mobile node's care-of address 1005 to the correspondent node. The mobile node also sends along 1006 a 64 bit CoT cookie that the correspondent node must return 1007 later. The Care-of Test Init message is sent directly to the 1008 correspondent node. 1010 2a. Home Test 1012 This message is sent in response to a Home Test Init message. 1013 The contents of the message are: 1015 Src = correspondent 1016 Dst = home address 1017 Parameters: 1018 - HoT cookie 1019 - home cookie 1020 - home nonce index 1022 When the correspondent node receives the Home Test Init 1023 message, it generates a 64-bit home cookie as follows: 1025 home cookie = First64(MAC_Kcn(home address | nonce)) 1027 The home cookie is formed from the first 64 bits of the MAC 1028 result. The message is sent to the mobile node via the home 1029 agent; the protocol relies on the assumption that the route 1030 between the home agent and the mobile node is secure. The home 1031 cookie also acts as a challenge to test that the mobile can 1032 receive messages sent to its home address. Kcn is used in the 1033 production of home cookie in order to allow the correspondent 1034 node to verify that it generated the home and care-of cookies, 1035 without forcing the correspondent node to remember a list of 1036 all cookies it has handed out. 1038 The HoT cookie from the mobile node is returned in the Home 1039 Test message, to ensure that the message comes from a node on 1040 the route between the home agent and the correspondent node. 1042 The home nonce index is delivered to the mobile node to later 1043 allow the correspondent node to efficiently find the nonce 1044 value that it used in creating the home cookie. 1046 2b. Care-of Test 1048 This message is sent in response to a Care-of Test Init 1049 message. The contents of the message are: 1051 Src = correspondent 1052 Dst = care-of address 1053 Parameters: 1054 - CoT cookie 1055 - care-of cookie 1056 - care-of nonce index 1058 The correspondent node also sends a challenge to the mobile's 1059 care-of address. When the correspondent node receives the 1060 Care-of Test Init message, it generates a 64-bit care-of cookie 1061 as follows: 1063 care-of cookie = First64(MAC_Kcn(care-of address | nonce)) 1065 The cookie is formed from the first 64 bits of the MAC result. 1066 The cookie is sent directly to the mobile node at its care-of 1067 address. The CoT cookie from the from CoTI message is returne 1068 to ensure that the message comes from a node on the route to 1069 the correspondent node. 1071 The care-of nonce index is provided to identify the nonce used 1072 for the care-of cookie. The home and care-of nonce indices are 1073 often the same in the Home and Care-of Test messages. 1075 When the mobile node has received both the Home and Care-of Test 1076 messages, the return routability procedure is complete. As a result, 1077 the mobile node has the means to prove its authority to send a 1078 Binding Update to the correspondent node. The mobile node hashes 1079 together the challenges to form a 16 octet session key Kbu: 1081 Kbu = Hash(home cookie | care-of cookie) 1083 Note that the correspondent node does not create any state specific 1084 to the mobile node, until it receives the Binding Update from that 1085 mobile node. The correspondent node is unaware of the session 1086 key Kbu, though it can recreate Kbu if it is presented the right 1087 addresses and nonce indices. 1089 5.2.6. Applying Return Routability for Correspondent Bindings 1091 After the above procedure has completed, the mobile node can supply a 1092 Binding Update to the correspondent node. An overview of the binding 1093 procedure is shown below. 1095 Mobile Node Correspondent node 1096 | | 1097 | 1. Binding Update | 1098 | Src = care-of address, Dst = correspondent | 1099 | Parameters: | 1100 | - home address | 1101 | - a MAC | 1102 | - home nonce index | 1103 | - care-of nonce index | 1104 | - sequence number | 1105 | - ... | 1106 |---------------------------------------------------->| 1107 | | 1108 | 2. Binding Acknowledgement | 1109 | (if requested) | 1110 | Src = correspondent, | 1111 | Dst = care-of address | 1112 | Parameters: | 1113 | - sequence number | 1114 | - a MAC | 1115 | - ... | 1116 |<----------------------------------------------------| 1117 | | 1119 Message 1 actually creates a binding, and message 2 is optional. The 1120 correspondent binding procedure consists of the return routability 1121 procedure followed by the messages 1 and 2. 1123 1. Binding Update 1125 The mobile node uses the created session key Kbu to authorize 1126 the Binding Update. The contents of the message are as 1127 follows: 1129 Src = care-of address 1130 Dst = correspondent 1131 Parameters: 1132 - home address 1133 - MAC_Kbu(care-of address | correspondent node address | BU) 1134 - home nonce index 1135 - care-of nonce index 1136 - sequence number 1137 - ... 1139 The Binding Update message contains Nonce Index option, so that 1140 the correspondent node knows which home and care-of nonces to 1141 use to recompute the session key. "BU" is the content of the 1142 Binding Update message, excluding (1) the IP header, (2) any 1143 extension headers between the IP header the Mobility Header, 1144 and (3) the Authenticator field inside the Binding Update. The 1145 first 96 bits from the MAC result are used as the Authenticator 1146 field. A sequence number will be used to match an eventual 1147 acknowledgement with this message. The sequence numbers 1148 start from a random value. The three dots represent all the 1149 remaining (not security related) information in the message. 1151 Once the correspondent node has verified the MAC, it can create 1152 a binding cache entry for the mobile. 1154 2. Binding Acknowledgement 1156 The Binding Update is optionally acknowledged by the 1157 correspondent node. The contents of the message are as 1158 follows: 1160 Src = correspondent 1161 Dst = care-of address 1162 Parameters: 1163 - sequence number 1164 - MAC_Kbu(care-of address | correspondent node address | BA) 1165 - ... 1167 The Binding Acknowledgement contains the same sequence number 1168 as the Binding Update did. "BA" is the content of the Binding 1169 Acknowledgement message, excluding (1) the IP header, (2) 1170 any extension headers between the IP header the Mobility 1171 Header, and (3) the Authenticator field inside the Binding 1172 Acknowledgement. The first 96 bits from the MAC result are 1173 used as the Authenticator field. The three dots represent 1174 all the remaining (not security related) information in the 1175 message. 1177 Bindings established with correspondent nodes using the return 1178 routability procedure MUST NOT exceed MAX_RR_BINDING_LIFE seconds. 1180 The value in the Source Address field in the IPv6 header carrying 1181 the Binding Update message is normally also the care-of address 1182 which is used in the binding. However, a different care-of address 1183 MAY be specified by including an Alternate Care-of Address mobility 1184 option in the Binding Update message (see Section 6.2.5). When such 1185 message is sent to the correspondent node and the return routability 1186 procedure is used as the authorization method, the Care-of Test Init 1187 and Care-of Test messages MUST have been performed for the address in 1188 the Alternate Care-of Address option (not the Source Address). The 1189 nonce indices MAC value MUST be based on information gained in this 1190 test. 1192 5.2.7. Updating Node Keys and Nonces 1194 An update of Kcn can be done at the same time as an update of a 1195 nonce, so that the nonce index identifies both the nonce and the key. 1196 Old Kcn values have to be therefore remembered as long as old nonce 1197 values. 1199 Before sending a Binding Update, the mobile node has to wait for both 1200 the Home and Care-of Cookies to arrive. Due to resource limitations, 1201 rapid deletion of bindings, or reboots it can not be guaranteed that 1202 the cookies are still fresh and acceptable when the correspondent 1203 node uses them in the processing of the Binding Update. If the 1204 cookies have become too old, the correspondent node replies with 1205 an an error code in the Binding Acknowledgement. The mobile node 1206 can then retry the return routability procedure. However, it is 1207 recommended that correspondent nodes try to keep these cookies 1208 acceptable as long as possible and SHOULD NOT accept them beyond 1209 MAX_COOKIE_LIFE seconds. 1211 Given that the cookies are normally expected to be usable for 1212 some time, the mobile node MAY use them beyond a single run of the 1213 return routability procedure. A fast moving mobile node may reuse 1214 a recent Home Cookie from a correspondent node when moving to a new 1215 location, and just acquire a new Care-of Cookie to show routability 1216 in the new location. While this does not save roundtrips due to the 1217 parallel nature of the home and care-of return routability tests, the 1218 roundtrip through the home agent may be longer, and consequently this 1219 optimization is often useful. A mobile node that has multiple home 1220 addresses, may also use the same Care-of Cookie for Binding Updates 1221 concerning all of these addresses. 1223 5.2.8. Preventing Replay Attacks 1225 The return routability procedure also protects the participants 1226 against replayed Binding Updates through the use of the sequence 1227 number and a MAC. Care must be taken when removing bindings at 1228 the correspondent node, however. Correspondent nodes must retain 1229 bindings and the associated sequence number information at least as 1230 long as the nonces used in the authorization of the binding are still 1231 valid. The correspondent node can, for instance, change the nonce 1232 often enough to ensure that the nonces used when removed entries 1233 were created are no longer valid. If many such deletions occur 1234 the correspondent node can batch them together to avoid having to 1235 increment the nonce index too often. 1237 5.3. Payload Packets 1239 Payload packets exchanged with mobile nodes can be protected in the 1240 usual manner, in the same way as stationary hosts can protect them. 1241 However, Mobile IPv6 introduces the Home Address destination option, 1242 a Routing Header, and tunneling headers in the payload packets. In 1243 the following we define the security measures taken to protect these, 1244 and to prevent their use in attacks against other parties. 1246 This specification limits the use of the Home Address destination 1247 option to the situation where the correspondent node already has a 1248 binding cache entry for the given home address. This avoids the use 1249 of the Home Address option in attacks described in Section 14.1. We 1250 also allow the option to be used when the packet containing it has 1251 been protected by IPsec. 1253 Mobile IPv6 uses a Mobile IPv6 specific type of a Routing Header. 1254 This type provides the necessary functionality but does not open 1255 vulnerabilities discussed in Section 14.1. 1257 Tunnels between the mobile node and the home agent are protected by 1258 ensuring proper use of source addresses, and optional cryptographic 1259 protection. The mobile node verifies that the outer IP address 1260 corresponds to its home agent. The home agent verifies that the 1261 outer IP address corresponds to the current location of the mobile 1262 node (Binding Updates sent to the home agents are secure). These 1263 measures protect the tunnels against vulnerabilities discussed in 1264 Section 14.1. 1266 For tunneled traffic to and from the mobile node, encapsulating 1267 the traffic inside IPsec AH or ESP offers an optional mechanism to 1268 protect the integrity and confidentiality of the traffic against 1269 on-path attackers. 1271 6. New IPv6 Protocols, Message Types, and Destination Option 1273 6.1. Mobility Header 1275 The Mobility Header is used by mobile nodes, correspondent nodes, and 1276 home agents in all messaging related to the creation and management 1277 of bindings. Sections 6.1.2 through 6.1.9 describe the message types 1278 used in this protocol. These sections also define which addresses to 1279 use in the IPv6 header in these messages. 1281 6.1.1. Format 1283 The Mobility Header is identified by a Next Header value of TBD in 1284 the immediately preceding header, and has the following format: 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Payload Proto | Header Len | MH Type | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Checksum | | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1291 | | 1292 . . 1293 . Message Data . 1294 . . 1295 | | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Payload Proto 1300 8-bit selector. Identifies the type of header immediately 1301 following the Mobility Header. Uses the same values as the 1302 IPv6 Next Header field [11]. 1304 This field is intended to be used by a future specification 1305 of piggybacking binding messages on payload packets (see 1306 Section C.1). 1308 Implementations conforming to this specification SHOULD set the 1309 payload protocol type to NO_NXTHDR (59 decimal). 1311 Header Len 1313 8-bit unsigned integer. Length of the Mobility Header in units 1314 of 8 octets, including the the Payload Proto, MH Type, Header 1315 Len, Checksum, and Message Data fields. 1317 We require that the Mobility Header length is a multiple of 8 1318 octets. 1320 MH Type 1322 16-bit selector. Identifies the particular mobility message 1323 in question. Current values are specified in Sections 6.1.2 1324 to 6.1.9. An unrecognized MH Type field causes an error to be 1325 sent to the source. 1327 Checksum 1329 16-bit unsigned integer. This field contains the checksum of 1330 the Mobility Header. The checksum is calculated from the octet 1331 string consisting of a "pseudo-header" followed by the entire 1332 Mobility Header starting with the Payload Proto field. The 1333 checksum is the 16-bit one's complement of the one's complement 1334 sum of this string. 1336 The pseudo-header contains IPv6 header fields, as specified 1337 in Section 8.1 of [11]. The Next Header value used in the 1338 pseudo-header is TBD. The addresses used in the pseudo-header 1339 are the addresses that appear in the Source and Destination 1340 Address fields in the IPv6 packet carrying the Mobility Header. 1341 For computing the checksum, the checksum field is set to zero. 1343 Message Data 1345 A variable length field containing the data specific to the 1346 indicated Mobility Header type. 1348 Mobile IPv6 also defines a number of "mobility options" for use 1349 within these messages; if included, any options MUST appear after 1350 the fixed portion of the message data specified in this document. 1351 The presence of such options will be indicated by the Header Len 1352 field within the message. When the Header Len is greater than the 1353 length required for the message specified here, the remaining octets 1354 are interpreted as mobility options. These options include padding 1355 options that can be used to ensure that other options are aligned 1356 properly, and that the total length of the message is divisible by 1357 8. The encoding and format of defined options are described in 1358 Section 6.2. 1360 Alignment requirements for the Mobility Header are the same as for 1361 any IPv6 protocol Header. That is, they MUST be aligned on an 1362 8-octet boundary. 1364 6.1.2. Binding Refresh Request (BRR) Message 1366 The Binding Refresh Request (BRR) message is used to request a 1367 mobile node's binding from the mobile node. It is sent according 1368 to the rules in Section 9.4.5. When a mobile node receives a 1369 packet containing a Binding Refresh Request message and there 1370 already exists a Binding Update List entry for the source of the 1371 Binding Refresh Request, it MAY start a return routability procedure 1372 (see Section 5.2) if it believes the amount of traffic with the 1373 correspondent justifies the use of route optimization. Note that 1374 the mobile node SHOULD NOT respond to Binding Refresh Requests from 1375 previously unknown correspondent nodes due to Denial-of-Service 1376 concerns. 1378 The Binding Refresh Request message uses the MH Type value 0. When 1379 this value is indicated in the MH Type field, the format of the 1380 Message Data field in the Mobility Header is as follows: 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Reserved | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | | 1386 . . 1387 . Mobility options . 1388 . . 1389 | | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 Reserved 1394 16-bit field reserved for future use. The value MUST be 1395 initialized to zero by the sender, and MUST be ignored by the 1396 receiver. 1398 Mobility options 1400 Variable-length field of such length that the complete Mobility 1401 Header is an integer multiple of 8 octets long. Contains one 1402 or more TLV-encoded mobility options. The encoding and format 1403 of defined options are described in Section 6.2. The receiver 1404 MUST ignore and skip any options which it does not understand. 1406 There MAY be additional information, associated with this 1407 Binding Refresh Request message, that need not be present in 1408 all Binding Requests sent. This use of mobility options also 1409 allows for future extensions to the format of the Binding 1410 Refresh Request message to be defined. The following options 1411 are valid in a Binding Refresh Request message: 1413 - Unique Identifier Option 1415 - Binding Authorization option 1417 If no actual options are present in this message, no padding is 1418 necessary and the Header Length field will be set to 1. 1420 6.1.3. Home Test Init (HoTI) Message 1422 A mobile node uses the Home Test Init (HoTI) message to initiate 1423 the return routability procedure and request a home cookie from a 1424 correspondent node (see Section 11.5.1). The Home Test Init message 1425 uses the MH Type value 1. When this value is indicated in the MH 1426 Type field, the format of the Message Data field in the Mobility 1427 Header is as follows: 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | Reserved | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | | 1433 + HoT cookie + 1434 | | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | | 1437 . . 1438 . Mobility Options . 1439 . . 1440 | | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Reserved 1445 16-bit field reserved for future use. This value MUST be 1446 initialized to zero by the sender, and MUST be ignored by the 1447 receiver. 1449 HoT cookie 1451 64-bit field which contains a random value, the HoT cookie. 1453 Mobility options 1455 Variable-length field of such length that the complete Mobility 1456 Header is an integer multiple of 8 octets long. Contains 1457 one or more TLV-encoded mobility options. The receiver MUST 1458 ignore and skip any options which it does not understand. This 1459 specification does not define any options valid for the Home 1460 Test Init message. 1462 If no actual options are present in this message, no padding is 1463 necessary and the Header Length field will be set to 2. 1465 This message is sent with the Source Address set to the home 1466 address of the mobile node, and the Destination Address set to the 1467 correspondent node's address. The message is tunneled through the 1468 home agent when the mobile node is away from home. Such tunneling 1469 SHOULD employ IPsec ESP in tunnel mode between the home agent and 1470 the mobile node. This protection is indicated by the IPsec policy 1471 data base. The protection of Home Test Init messages is unrelated 1472 to the requirement to protect regular payload traffic, which MAY 1473 use such tunnels as well. A packet that includes a Home Test Init 1474 message MUST NOT include a Home Address destination option between 1475 the Mobility Header and the preceding IPv6 header. 1477 6.1.4. Care-of Test Init (CoTI) Message 1479 A mobile node uses the Care-of Test Init (CoTI) message to initiate 1480 the return routability procedure and request a care-of cookie from 1481 a correspondent node (see Section 11.5.1). The Care-of Test Init 1482 message uses the MH Type value 2. When this value is indicated 1483 in the MH Type field, the format of the Message Data field in the 1484 Mobility Header is as follows: 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Reserved | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | | 1490 + CoT cookie + 1491 | | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | | 1494 . . 1495 . Mobility Options . 1496 . . 1497 | | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Reserved 1502 16-bit field reserved for future use. The value MUST be 1503 initialized to zero by the sender, and MUST be ignored by the 1504 receiver. 1506 CoT cookie 1508 64-bit field which contains a random value, the CoT cookie. 1510 Mobility options 1512 Variable-length field of such length that the complete Mobility 1513 Header is an integer multiple of 8 octets long. Contains 1514 one or more TLV-encoded mobility options. The receiver MUST 1515 ignore and skip any options which it does not understand. This 1516 specification does not define any options valid for the Care-of 1517 Test Init message. 1519 If no actual options are present in this message, no padding is 1520 necessary and the Header Length field will be set to 2. 1522 This message is always sent with the Source Address set to the 1523 care-of address of the mobile node, and is sent directly to the 1524 correspondent node. A packet that includes a Care-of Test Init 1525 message MUST NOT include a Home Address destination option between 1526 the Mobility Header and the preceding IPv6 header. 1528 6.1.5. Home Test (HoT) Message 1530 The Home Test (HoT) message is a response to the HoTI message, 1531 and is sent from the correspondent node to the mobile node (see 1532 Section 5.2.5). The Home Test message uses the MH Type value 3. 1533 When this value is indicated in the MH Type field, the format of the 1534 Message Data field in the Mobility Header is as follows: 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Home Nonce Index | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | | 1540 + HoT cookie + 1541 | | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | | 1544 + Home Cookie + 1545 | | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | | 1548 . . 1549 . Mobility options . 1550 . . 1551 | | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 Home Nonce Index 1556 This field will be echoed back by the mobile node to the 1557 correspondent node in a subsequent binding update. 1559 HoT cookie 1561 64-bit field which contains the HoT cookie. 1563 Home Cookie 1565 This field contains the 64 bit home cookie in the return 1566 routability procedure; it is the first of two cookies which 1567 are to be processed to form a key which is then used to 1568 authenticate a binding update. 1570 Mobility options 1572 Variable-length field of such length that the complete Mobility 1573 Header is an integer multiple of 8 octets long. Contains 1574 one or more TLV-encoded mobility options. The receiver MUST 1575 ignore and skip any options which it does not understand. This 1576 specification does not define any options valid for the Home 1577 Test message. 1579 If no actual options are present in this message, no padding is 1580 necessary and the Header Length field will be set to 3. This 1581 message is always sent with the Destination Address set to the home 1582 address of the mobile node, Source Address set to the address of the 1583 correspondent node, and is tunneled through the home agent when the 1584 mobile node is away from home. Note that the Home Test message is 1585 always sent to the home address of the mobile node, even when there 1586 is an existing binding for the mobile node. The tunneling between 1587 the home agent and the mobile node SHOULD employ IPsec ESP in tunnel 1588 mode. This protection is indicated by the IPsec policy data base. 1590 6.1.6. Care-of Test (CoT) Message 1592 The Care-of Test (CoT) message is a response to the CoTI message, 1593 and is sent from the correspondent node to the mobile node (see 1594 Section 11.5.2). The Care-of Test message uses the MH Type value 4. 1595 When this value is indicated in the MH Type field, the format of the 1596 Message Data field in the Mobility Header is as follows: 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Care-of Nonce Index | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | | 1602 + CoT cookie + 1603 | | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | | 1606 + Care-of Cookie + 1607 | | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | | 1610 . . 1611 . Mobility Options . 1612 . . 1613 | | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 Reserved 1618 The two 16-bit fields are reserved for future use. These 1619 values MUST be initialized to zero by the sender, and MUST be 1620 ignored by the receiver. 1622 Care-of Nonce Index 1624 This field will be echoed back by the mobile node to the 1625 correspondent node in a subsequent binding update. 1627 CoT cookie 1629 64-bit field which contains the CoT cookie. 1631 Care-of Cookie 1633 This field contains the 64 bit care-of cookie in the return 1634 routability procedure; it is the second of two cookies which 1635 are to be processed to form a key which is then used to 1636 authenticate a binding update. 1638 Mobility options 1640 Variable-length field of such length that the complete Mobility 1641 Header is an integer multiple of 8 octets long. Contains 1642 one or more TLV-encoded mobility options. The receiver MUST 1643 ignore and skip any options which it does not understand. This 1644 specification does not define any options valid for the Care-of 1645 Test message. 1647 The CoT message is always sent with the Source Address set to the 1648 address of the correspondent node, and the Destination Address set to 1649 the care-of address of the mobile node; it is sent directly to the 1650 mobile node. If no actual options are present in this message, no 1651 padding is necessary and the Header Len field will be set to 3. 1653 6.1.7. Binding Update (BU) Message 1655 The Binding Update (BU) message is used by a mobile node to notify 1656 other nodes of a new care-of address for itself. A packet containing 1657 a Binding Update message is sent with the Source Address set to the 1658 care-of address of the mobile node and the Destination Address set to 1659 the correspondent node's address. 1661 The Binding Update message uses the MH Type value 5. When this value 1662 is indicated in the MH Type field, the format of the Message Data 1663 field in the Mobility Header is as follows: 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | Sequence # | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 |A|H|S|D|L| Reserved | Lifetime | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | | 1671 . . 1672 . Mobility options . 1673 . . 1674 | | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 Acknowledge (A) 1678 The Acknowledge (A) bit is set by the sending mobile node to 1679 request a Binding Acknowledgement (Section 6.1.8) be returned 1680 upon receipt of the Binding Update. 1682 Home Registration (H) 1684 The Home Registration (H) bit is set by the sending mobile 1685 node to request that the receiving node should act as this 1686 node's home agent. The destination of the packet carrying this 1687 message MUST be that of a router sharing the same subnet prefix 1688 as the home address of the mobile node in the binding. 1690 Single Address Only (S) 1692 If the `S' bit is set, the mobile node requests that the home 1693 agent make no changes to any other Binding Cache entry except 1694 for the particular one containing the home address specified 1695 in the Home Address destination option. This disables home 1696 agent processing for other related addresses, as is described 1697 in Section 10.2. 1699 Duplicate Address Detection (D) 1701 The Duplicate Address Detection (D) bit is set by the sending 1702 mobile node to request that the receiving node (the mobile 1703 node's home agent) perform Duplicate Address Detection [13] 1704 on the mobile node's home link for the home address in this 1705 binding. This bit is only valid when the Home Registration (H) 1706 and Acknowledge (A) bits are also set, and MUST NOT be set 1707 otherwise. 1709 Link-Local Address Compatibility (L) 1711 The Link-Local Address Compatibility (L) bit is set when the 1712 home address reported by the mobile node has the same interface 1713 identifier (IID) as the mobile node's link-local address. 1715 Reserved 1717 These fields are unused. They MUST be initialized to zero by 1718 the sender and MUST be ignored by the receiver. 1720 Sequence # 1722 A 16-bit number used by the receiving node to sequence Binding 1723 Updates and by the sending node to match a returned Binding 1724 Acknowledgement with this Binding Update. 1726 Lifetime 1728 16-bit unsigned integer. The number of time units remaining 1729 before the binding MUST be considered expired. A value of all 1730 one bits (0xffffffff) indicates infinity. A value of zero 1731 indicates that the Binding Cache entry for the mobile node MUST 1732 be deleted. One time unit is 16 seconds. 1734 Mobility options 1736 Variable-length field of such length that the complete Mobility 1737 Header is an integer multiple of 8 octets long. Contains one 1738 or more TLV-encoded mobility options. The encoding and format 1739 of defined options are described in Section 6.2. The receiver 1740 MUST ignore and skip any options which it does not understand. 1742 The following options are valid in a Binding Update message: 1744 - Unique Identifier option 1746 - Binding Authorization Data option 1748 - Nonce Indices option. 1750 - Alternate Care-of Address option 1752 If no actual options are present in this message, no padding is 1753 necessary and the Header Len field will be set to 4. 1755 A Binding Update to the home agent MUST include the Home Address 1756 destination option if the Source Address field in the IPv6 header is 1757 not the home address of the mobile node. 1759 The care-of address MUST NOT be any IPv6 address which is prohibited 1760 for use within a Routing Header; thus multicast addresses, the 1761 unspecified address, loop-back address, and link-local addresses 1762 are excluded. Binding Updates indicating any such excluded care-of 1763 address MUST be silently discarded. 1765 The deletion of a binding can be indicated by setting the Lifetime 1766 field to 0 or by setting the care-of address equal to the home 1767 address. Correspondent nodes SHOULD NOT expire the binding cache 1768 entry before the lifetime expires, if any application hosted by the 1769 correspondent node is still likely to require communication with the 1770 mobile node. A binding cache entry that is deallocated prematurely 1771 might cause subsequent packets to be dropped from the mobile node, 1772 if they contain the Home Address destination option. This situation 1773 is recoverable, since an error message is sent to the mobile node; 1774 however, it causes unnecessary delay in the communications. 1776 6.1.8. Binding Acknowledgement (BA) Message 1778 The Binding Acknowledgement message is used to acknowledge receipt 1779 of a Binding Update message (Section 6.1.7). When a node receives 1780 a packet containing a Binding Update message, with this node being 1781 the destination of the packet, this node MUST return a Binding 1782 Acknowledgement to the mobile node, if the Acknowledge (A) bit is 1783 set in the the Binding Update. The Binding Acknowledgement message 1784 is sent to the Source Address of the Binding Update message which 1785 is being acknowledged. The packet includes a Routing header if 1786 the Source Address was not the home address of the mobile node, as 1787 described in Sections 10.2 and 9.4.4. The Source Address of the 1788 Binding Acknowledgement is the Destination Address from the Binding 1789 Update. 1791 The Binding Acknowledgement message has the MH Type value 6. When 1792 this value is indicated in the MH Type field, the format of the 1793 Message Data field in the Mobility Header is as follows: 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Status | Reserved | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | Sequence # | Lifetime | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | | 1801 . . 1802 . Mobility options . 1803 . . 1804 | | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 Reserved 1809 These fields are unused. They MUST be initialized to zero by 1810 the sender and MUST be ignored by the receiver. 1812 Status 1814 8-bit unsigned integer indicating the disposition of the 1815 Binding Update. Values of the Status field less than 128 1816 indicate that the Binding Update was accepted by the receiving 1817 node. Values greater than or equal to 128 indicate that 1818 the Binding Update was rejected by the receiving node. The 1819 following Status values are currently defined: 1821 0 Binding Update accepted 1822 128 Reason unspecified 1823 129 Administratively prohibited 1824 130 Insufficient resources 1825 131 Home registration not supported 1826 132 Not home subnet 1827 133 Not home agent for this mobile node 1828 134 Duplicate Address Detection failed 1829 135 Sequence number out of window 1830 136 Route optimization unnecessary due to low traffic 1831 137 Invalid authenticator 1832 138 Expired Home Nonce Index 1833 139 Expired Care-of Nonce Index 1835 Up-to-date values of the Status field are to be specified in 1836 the IANA registry of assigned numbers [18]. 1838 Sequence # 1840 The Sequence Number in the Binding Acknowledgement is copied 1841 from the Sequence Number field in the Binding Update. It used 1842 by the mobile node in matching this Acknowledgement with an 1843 outstanding Binding Update. 1845 Lifetime 1847 The granted lifetime, in time units of 4 seconds, for which 1848 this node SHOULD retain the entry for this mobile node in its 1849 Binding Cache. A value of all one bits (0xffffffff) indicates 1850 infinity. 1852 The value of this field is undefined if the Status field 1853 indicates that the Binding Update was rejected. 1855 Mobility options 1857 Variable-length field of such length that the complete Mobility 1858 Header is an integer multiple of 8 octets long. Contains one 1859 or more TLV-encoded mobility options. The encoding and format 1860 of defined options are described in Section 6.2. The receiver 1861 MUST ignore and skip any options which it does not understand. 1863 There MAY be additional information, associated with this 1864 Binding Acknowledgement message, that need not be present 1865 in all Binding Acknowledgements sent. This use of mobility 1866 options also allows for future extensions to the format of the 1867 Binding Acknowledgement message to be defined. The following 1868 options are valid for the Binding Acknowledgement message: 1870 - Binding Authorization Data option 1872 - Binding Refresh Advice option 1874 If no options are present in this message, 4 bytes of padding is 1875 necessary and the Header Len field will be set to 2. 1877 The Binding Acknowledgement is sent to the source address of the 1878 Binding Update message, regardless of whether the Binding Update 1879 succeeded or failed. No Routing Headers are added to the message. 1881 6.1.9. Binding Error (BE) Message 1883 The Binding Error (BE) message is used by the correspondent node to 1884 signal an error related to mobility, such as an inappropriate attempt 1885 to use the Home Address destination option without an existing 1886 binding. A packet containing a Binding Error message is sent to the 1887 source address of the offending packet. For instance, in the case 1888 of the Home Address destination option error, the packet is the one 1889 that contained the Home Address destination option and therefore 1890 the Binding Error message is sent to the care-of address of the 1891 mobile node. The source address of the Binding Error message is the 1892 correspondent node's address. 1894 The Binding Error message uses the MH Type value 7. When this value 1895 is indicated in the MH Type field, the format of the Message Data 1896 field in the Mobility Header is as follows: 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Status | Reserved | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | | 1902 + + 1903 | | 1904 + Home Address + 1905 | | 1906 + + 1907 | | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 . . 1910 . Mobility Options . 1911 . . 1912 | | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 Status 1917 8-bit unsigned integer indicating the reason for this message. 1918 The following such Status values are currently defined: 1920 1 Home Address destination option used without a binding 1921 2 Received message had an unknown value for the MH Type 1922 field 1924 Reserved 1926 A 8-bit field reserved for future use. The value MUST be 1927 initialized to zero by the sender, and MUST be ignored by the 1928 receiver. 1930 Home Address 1932 The home address that was contained in the Home Address 1933 destination option. The mobile node uses this information to 1934 determine which binding does not exist, in cases where the 1935 mobile node has several home addresses. 1937 Mobility options 1939 Variable-length field of such length that the complete Mobility 1940 Header is an integer multiple of 8 octets long. Contains one 1941 or more TLV-encoded mobility options. The receiver MUST ignore 1942 and skip any options which it does not understand. 1944 There MAY be additional information, associated with this 1945 Binding Error message, that need not be present in all Binding 1946 Error messages sent. This use of mobility options also allows 1947 for future extensions to the format of the Binding Error 1948 message to be defined. The encoding and format of defined 1949 options are described in Section 6.2. This specification does 1950 not define any options valid for the Binding Error message. 1952 If no actual options are present in this message, no padding is 1953 necessary and the Header Len field will be set to 3. 1955 6.2. Mobility Options 1957 6.2.1. Format 1959 In order to allow optional fields that may not be needed in every use 1960 of any given Mobility Header, and to allow future extensions to the 1961 format of these messages to be defined, the Mobility Header messages 1962 defined in this document can include one or more mobility options. 1964 Such options are included in the data portion of the message itself, 1965 after the fixed portion of the message data specified in the message 1966 subsections of section 6.1. 1968 The presence of such options will be indicated by the Header Len of 1969 the Mobility Header. 1971 These options are encoded within the remaining space of the message 1972 data for that message, using a type-length-value (TLV) format as 1973 follows: 1975 0 1 2 3 1976 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 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | Option Type | Option Len | Option Data... 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 Option Type 1983 8-bit identifier of the type of mobility option. When 1984 processing a Mobility Header containing an option for which 1985 the Option Type value is not recognized by the receiver, 1986 the receiver MUST quietly ignore and skip over the option, 1987 correctly handling any remaining options in the message. 1989 Option Len 1991 8-bit unsigned integer. Length of this mobility option, in 1992 octets. The Option Len does not include the length of the 1993 Option Type and Option Len fields. 1995 Option Data 1997 A variable length field that contains data specific to the 1998 option. 2000 The following subsections specify the Option types which are 2001 currently defined for use in the Mobility Header. 2003 Implementations MUST silently ignore any mobility options that they 2004 do not understand. 2006 6.2.2. Pad1 2008 The Pad1 option does not have any alignment requirements. Its format 2009 is as follows: 2011 0 2012 0 1 2 3 4 5 6 7 2013 +-+-+-+-+-+-+-+-+ 2014 | 0 | 2015 +-+-+-+-+-+-+-+-+ 2017 NOTE! the format of the Pad1 option is a special case -- it has 2018 neither Option Len nor Option Data fields. 2020 The Pad1 option is used to insert one octet of padding in the 2021 Mobility Options area of a Mobility Header. If more than one octet 2022 of padding is required, the PadN option, described next, should be 2023 used rather than multiple Pad1 options. 2025 6.2.3. PadN 2027 The PadN option does not have any alignment requirements. Its format 2028 is as follows: 2030 0 1 2031 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2033 | 1 | Option Len | Option Data 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2036 The PadN option is used to insert two or more octets of padding in 2037 the Mobility Options area of a Mobility Header message. For N octets 2038 of padding, the Option Len field contains the value N-2, and the 2039 Option Data consists of N-2 zero-valued octets. Option data MUST be 2040 ignored by the receiver. 2042 6.2.4. Unique Identifier 2044 The Unique Identifier option has the alignment requirement of 2n. 2045 Its format is as follows: 2047 0 1 2 3 2048 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 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | Type = 2 | Length = 2 | Unique Identifier | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 The Unique Identifier option is valid only in Binding Refresh 2054 Request, and Binding Update messages. The Unique Identifier field 2055 contains a 16-bit value that serves to uniquely identify a Binding 2056 Request among those sent by this Source Address, and to allow the 2057 Binding Update to identify the specific Binding Refresh Request to 2058 which it responds. 2060 6.2.5. Alternate Care-of Address 2062 The Alternate Care-of Address option has an alignment requirement of 2063 8n+6. Its format is as follows: 2065 0 1 2 3 2066 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 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Type = 3 | Length = 16 | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | | 2071 + + 2072 | | 2073 + Alternate Care-of Address + 2074 | | 2075 + + 2076 | | 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 The Alternate Care-of Address option is valid only in Binding Update 2080 message. The Alternate Care-of Address field contains an address to 2081 use as the care-of address for the binding, rather than using the 2082 Source Address of the packet as the care-of address. 2084 6.2.6. Nonce Indices 2086 The Nonce Indices option has an alignment requirement of 2n. Its 2087 format is as follows: 2089 0 1 2 3 2090 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 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Type = 4 | Length = 4 | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Home Nonce Index | Care-of Nonce Index | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 The Nonce Indices option is valid only in the Binding Update message, 2098 and only when present together with an Binding Authorization Data 2099 option. 2101 The Home Nonce Index field tells the correspondent node that receives 2102 the message which of the challenge values (Ni) are to be used to 2103 authenticate the Binding Update. 2105 The Care-of Nonce Index field tells the correspondent node that 2106 receives the message which of the challenge values (Nj) are to be 2107 used to authenticate the Binding Update. 2109 6.2.7. Binding Authorization Data 2111 The Binding Authorization Data option has an alignment requirement of 2112 4n+2. Its format is as follows: 2114 0 1 2 3 2115 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 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | Type = 5 | Len | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | | 2120 + + 2121 | Authenticator | 2122 + + 2123 | | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 The Binding Authorization Data option is valid only in the Binding 2127 Refresh Request, Binding Update, and Binding Acknowledgment messages. 2129 The Option Len field contains the length of the authenticator in 2130 octets. 2132 The Authenticator field contains a cryptographic value which can be 2133 used to determine that the message in question comes from the right 2134 authority. Rules for calculating this value depend on the used 2135 authorization procedure. This specification gives the rules only for 2136 the return routability procedure. For this procedure, this option 2137 can only appear in a Binding Update message and rules for calculating 2138 the Authenticator value are described in Section 6.1.7. 2140 6.2.8. Binding Refresh Advice 2142 The Binding Refresh Advice option has an alignment requirement of 2n. 2143 Its format is as follows: 2145 0 1 2 3 2146 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 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Type = 7 | Length = 2 | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | Refresh Interval | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 The Binding Refresh Advice option is only valid in the Binding 2154 Acknowledgement message, and only on Acknowledgements sent from 2155 the mobile node's home agent in reply to a home registration. The 2156 Refresh Interval is measured in seconds, and indicates how long 2157 before the mobile node SHOULD send a new home registration to the 2158 home agent. The Refresh Interval MUST be set to indicate a smaller 2159 time interval than the Lifetime value of the Binding Acknowledgement. 2161 6.3. Home Address Destination Option 2163 The Home Address destination option is used in a packet sent by a 2164 mobile node while away from home, to inform the recipient of the 2165 mobile node's home address. 2167 Multicast addresses, link-local addresses, loopback addresses, IPv4 2168 mapped addresses, and the unspecified address, MUST NOT be used 2169 within a Home Address option. The Home Address Option MUST NOT 2170 appear more than once in any given packet, except inside the payload 2171 part of the packet if tunneling is involved. 2173 The Home Address option is encoded in type-length-value (TLV) format 2174 as follows: 2176 0 1 2 3 2177 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 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | Option Type | Option Length | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | | 2182 + + 2183 | | 2184 + Home Address + 2185 | | 2186 + + 2187 | | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 Option Type 2192 201 = 0xC9 2194 Option Length 2196 8-bit unsigned integer. Length of the option, in octets, 2197 excluding the Option Type and Option Length fields. This field 2198 MUST be set to 16. 2200 Home Address 2202 The home address of the mobile node sending the packet. 2204 IPv6 requires that options appearing in a Hop-by-Hop Options 2205 header or Destination Options header be aligned in a packet so that 2206 multi-octet values within the Option Data field of each option fall 2207 on natural boundaries (i.e., fields of width n octets are placed at 2208 an integer multiple of n octets from the start of the header, for 2209 n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Home 2210 Address option is 8n+6. 2212 The three highest-order bits of the Option Type are encoded to 2213 indicate specific processing of the option [11]. For the Home 2214 Address option, these three bits are set to 110, indicating that any 2215 IPv6 node processing this option that does not recognize the Option 2216 Type must discard the packet and, only if the packet's Destination 2217 Address was not a multicast address, return an ICMP Parameter 2218 Problem, Code 2, message to the packet's Source Address; and that the 2219 data within the option cannot change en-route to the packet's final 2220 destination. 2222 A packet MUST NOT contain more than one Home Address option, except 2223 that an encapsulated packet [15] MAY contain a separate Home Address 2224 option associated with each encapsulating IP header. 2226 The Home Address option MUST be placed as follows: 2228 - After the Routing Header, if that header is present 2230 - Before the Fragment Header, if that header is present 2232 - Before the AH Header or ESP Header, if either one of those 2233 headers is present 2235 The inclusion of a Home Address destination option in a packet 2236 affects the receiving node's processing of only this single packet; 2237 no state is created or modified in the receiving node as a result 2238 of receiving a Home Address option in a packet. In particular, the 2239 presence of a Home Address option in a received packet MUST NOT alter 2240 the contents of the receiver's Binding Cache and MUST NOT cause any 2241 changes in the routing of subsequent packets sent by this receiving 2242 node. 2244 6.4. Routing Header type 2 2246 Mobile IPv6 uses a Routing header to carry the Home Address for 2247 packets sent from a correspondent node to a mobile node. The Care of 2248 Address of the mobile node is carried in the IPv6 destination field. 2250 The new Routing header uses a different type than defined for 2251 "regular" IPv6 source routing, enabling firewalls to apply different 2252 rules to source routed packets than to MIPv6. This Routing header 2253 type (Type 2) is restricted to carry only one IPv6 address. All IPv6 2254 nodes which process this Routing header MUST verify that the address 2255 contained within is the node's own home address in order to prevent 2256 packets from being forwarded outside the node. 2258 6.4.1. Routing Header Packet format 2260 The Type 2 Routing header has the following format: 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | Reserved | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | | 2268 + + 2269 | | 2270 + Home Address + 2271 | | 2272 + + 2273 | | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 Next Header 2278 8-bit selector. Identifies the type of header immediately 2279 following the Routing header. Uses the same values as the IPv6 2280 Next Header field [11]. 2282 Hdr Ext Len 2284 8-bit unsigned integer. Length of the Routing header in 2285 8-octet units, not including the first 8 octets. For the Type 2286 2 Routing header, Hdr Ext Len is always 2. 2288 Routing Type 2290 8-bit unsigned integer that contains the value 2. 2292 Segments Left 2294 8-bit unsigned integer. Number of route segments remaining; 2295 i.e., number of explicitly listed intermediate nodes still to 2296 be visited before reaching the final destination. Packets 2297 transmitted through an interface have Segments left is always 1 2298 in this type of Routing header. 2300 Reserved 2302 32-bit reserved field. Initialized to zero for transmission, 2303 and ignored on reception. 2305 Home Address 2307 The Home Address of the destination Mobile Node. 2309 The ordering rules for extension headers in an IPv6 packet are 2310 described in Section 4.1 of [11]. The new Routing header (Type 2) 2311 defined for Mobile IPv6 follows the same ordering as other routing 2312 headers. If more than one Routing header (e.g., both a Type 0 and a 2313 Type 2 Routing header are present), the Type 2 Routing header should 2314 follow all other Routing headers. Otherwise the order of routing 2315 headers is independent of their type and follows [11]. 2317 In addition, the general procedures defined by IPv6 for Routing 2318 headers suggest that a received Routing header MAY be automatically 2319 "reversed" to construct a Routing header for use in any response 2320 packets sent by upper-layer protocols, if the received packet is 2321 authenticated [6]. This MUST NOT be done automatically for Type 2 2322 Routing headers. 2324 6.5. ICMP Home Agent Address Discovery Request Message 2326 The ICMP Home Agent Address Discovery Request message is used by a 2327 mobile node to initiate the dynamic home agent address discovery 2328 mechanism, as described in Section 11.3.2. The mobile node sends 2329 a Home Agent Address Discovery Request message to the "Mobile IPv6 2330 Home-Agents" anycast address for its own home subnet prefix [16]. 2332 0 1 2 3 2333 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 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | Type | Code | Checksum | 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 | Identifier | Reserved | 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 Type 2341 150 2343 Code 2345 0 2347 Checksum 2349 The ICMP checksum [14]. 2351 Identifier 2353 An identifier to aid in matching Home Agent Address Discovery 2354 Reply messages to this Home Agent Address Discovery Request 2355 message. 2357 Reserved 2359 This field is unused. It MUST be initialized to zero by the 2360 sender and MUST be ignored by the receiver. 2362 The Source Address of the Home Agent Address Discovery Request 2363 message packet MUST be one of the mobile node's current care-of 2364 addresses. The home agent MUST then return the Home Agent Address 2365 Discovery Reply message directly to the Source Address chosen by the 2366 mobile node. Note that, at the time of performing this dynamic home 2367 agent address discovery, it is likely that the mobile node is not 2368 registered with any home agent within the specified anycast group. 2370 6.6. ICMP Home Agent Address Discovery Reply Message 2372 The ICMP Home Agent Address Discovery Reply message is used by a home 2373 agent to respond to a mobile node that uses the dynamic home agent 2374 address discovery mechanism, as described in Section 10.9. One of 2375 the home agents on the home link responds to the mobile node with a 2376 Home Agent Address Discovery Reply message, providing a list of the 2377 routers on the mobile node's home link serving as home agents. 2379 0 1 2 3 2380 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 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | Type | Code | Checksum | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | Identifier | | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2386 | | 2387 + Reserved + 2388 | | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | | 2391 + + 2392 . . 2393 . Home Agent Addresses . 2394 . . 2395 + + 2396 | | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 Type 2401 151 2403 Code 2405 0 2407 Checksum 2409 The ICMP checksum [14]. 2411 Identifier 2413 The identifier from the invoking Home Agent Address Discovery 2414 Request message. 2416 Reserved 2418 This field is unused. It MUST be initialized to zero by the 2419 sender and MUST be ignored by the receiver. 2421 Home Agent Addresses 2423 A list of addresses of home agents on the home link for the 2424 mobile node. The number of addresses present in the list is 2425 indicated by the remaining length of the IPv6 packet carrying 2426 the Home Agent Address Discovery Reply message. 2428 6.7. ICMP Mobile Prefix Solicitation Message Format 2430 The ICMP Mobile Prefix Solicitation Message is sent by a mobile node 2431 to its home agent while it is away from home. The purpose of the 2432 message is to solicit a Mobile Prefix Advertisement from the home 2433 agent, which will allow the mobile node to gather prefix information 2434 about its home network. This information can be used to configure 2435 home address(es) by stateless address autoconfiguration [13], 2436 or update address(es) according to changes in prefix information 2437 supplied by the home agent. 2439 The Mobile Prefix Solicitation is similar to the Router Solicitation 2440 used in Neighbor Discovery [12], except it is routed from the mobile 2441 node on the visited network to the home agent on the home network by 2442 usual unicast routing rules. 2444 0 1 2 3 2445 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 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Type | Code | Checksum | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | Identifier | Reserved | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 IP Fields: 2454 Source Address 2456 The mobile node's care-of address. 2458 Destination Address 2460 The address of the mobile node's home agent. This home agent 2461 must be on the link which the mobile node wishes to learn 2462 prefix information about. 2464 Hop Limit 2466 Set to an initial hop limit value, similarly to any other 2467 unicast packet sent by the mobile node. 2469 Authentication Header 2471 If a Security Association for the IP Authentication Header 2472 exists between the sender and the destination address, then the 2473 sender SHOULD include this header. [subject to change] 2475 ICMP Fields: 2477 Type 2479 152 2481 Code 2483 0 2485 Checksum 2487 The ICMP checksum [14]. 2489 Identifier 2491 An identifier to aid in matching a future Mobile Prefix 2492 Advertisement message to this Mobile Prefix Solicitation 2493 message. 2495 Reserved 2497 This field is unused. It MUST be initialized to zero by the 2498 sender and MUST be ignored by the receiver. 2500 If the mobile node receives a Mobile Prefix Advertisement Message 2501 from its home agent (see section 6.8), and the advertisement does not 2502 contain any authentication data, the mobile node MAY nevertheless 2503 send a Binding Update message to its home agent using its new home 2504 address which has been formed from the newly advertised prefix 2505 information. If there are security concerns that would inhibit 2506 responding to unauthenticated advertisements, then the mobile node 2507 SHOULD send a Mobile Prefix Solicitation message to its home agent, 2508 with a nonzero Identifier value that can be used to match a future 2509 advertisement with the solicitation. 2511 The mobile node SHOULD include authentication data along with any 2512 Mobile Prefix Solicitation message that it sends to the home agent. 2514 6.8. ICMP Mobile Prefix Advertisement Message Format 2516 A home agent will send a Mobile Prefix Advertisement message to a 2517 mobile node to distribute prefix information about the home link 2518 while the mobile node is traveling away from the home network. This 2519 will occur in response to a Mobile Prefix Solicitation with an 2520 Advertisement, or by an unsolicited Advertisement sent according to 2521 the rules in Section 10.9.1. 2523 0 1 2 3 2524 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 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Type | Code | Checksum | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | Identifier | Options ... 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 IP Fields: 2533 Source Address 2534 The home agent's address as the mobile node would 2535 expect to see it (i.e., same network prefix) 2537 Destination Address 2538 If this message is a response to a Mobile Prefix 2539 Solicitation, this field contains the Source Address 2540 field from that packet. For unsolicited messages, 2541 the mobile node's care-of address SHOULD be used. 2542 Note that unsolicited messages can only be sent if 2543 the mobile node is currently registered with the 2544 home agent. 2546 Authentication Header 2547 An AH header MUST be included unless the mobile node 2548 has yet to configure a home address. 2550 ICMP Fields: 2552 Type 2554 153 2556 Code 2558 0 2560 Checksum 2562 The ICMP checksum [14]. 2564 Identifier 2566 An identifier to aid in matching this Mobile Prefix 2567 Advertisement message to a previous Mobile Prefix Solicitation 2568 message. 2570 Options: 2572 Prefix Information 2574 Each message contains one or more Prefix Information options. 2575 Each option carries the prefix(es) that the mobile node 2576 should use to configure its home address(es). Section 10.9.1 2577 describes which prefixes should be advertised to the mobile 2578 node. 2580 The Prefix Information option is defined in Section 4.6.2 2581 of [12], with modifications defined in Section 7.2 of this 2582 specification. The home agent MUST use this modified Prefix 2583 Information option to send the aggregate list of home network 2584 prefixes as defined in Section 10.9.1. 2586 The Mobile Prefix Advertisement sent by the home agent MAY include 2587 the Source Link-layer Address option defined in RFC 2461 [12], or the 2588 Advertisement Interval option specified in Section 7.3. 2590 Future versions of this protocol may define new option types. Mobile 2591 nodes MUST silently ignore any options they do not recognize and 2592 continue processing the message. 2594 If the Advertisement is sent in response to a Mobile Prefix 2595 Solicitation, the home agent MUST copy the Identifier value from that 2596 message into the Identifier field of the Advertisement. 2598 The home agent MUST NOT send more than one Mobile Prefix 2599 Advertisement message per second to any mobile node. 2601 7. Modifications to IPv6 Neighbor Discovery 2603 7.1. Modified Router Advertisement Message Format 2605 Mobile IPv6 modifies the format of the Router Advertisement 2606 message [12] by the addition of a single flag bit to indicate that 2607 the router sending the Advertisement message is serving as a home 2608 agent on this link. The format of the Router Advertisement message 2609 is as follows: 2611 0 1 2 3 2612 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 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 | Type | Code | Checksum | 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | Reachable Time | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 | Retrans Timer | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2622 | Options ... 2623 +-+-+-+-+-+-+-+-+-+-+-+- 2625 This format represents the following changes over that originally 2626 specified for Neighbor Discovery [12]: 2628 Home Agent (H) 2630 The Home Agent (H) bit is set in a Router Advertisement to 2631 indicate that the router sending this Router Advertisement is 2632 also functioning as a Mobile IP home agent on this link. 2634 Reserved 2636 Reduced from a 6-bit field to a 5-bit field to account for the 2637 addition of the Home Agent (H) bit. 2639 7.2. Modified Prefix Information Option Format 2641 Mobile IPv6 requires knowledge of a router's global address for two 2642 reasons: 2644 - To allow a home agent (a router) to learn the address of all 2645 other home agents on the link for which it is providing home 2646 agent service, for use in building its Home Agents List as 2647 part of the dynamic home agent address discovery mechanism 2648 (Sections 10.9 and 11.3.2). 2650 - To allow a mobile node to send a Binding Update to a router on 2651 the link on which its previous care-of address is located, for 2652 purposes of establishing forwarding from this previous care-of 2653 address to its new care-of address (Section 11.6.6). 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 easily 2660 and efficiently advertise its global address, by the addition of a 2661 single flag bit in the format of a Prefix Information option for 2662 use in Router Advertisement messages. The format of the Prefix 2663 Information option is as follows: 2665 0 1 2 3 2666 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 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | Type | Length | Prefix Length |L|A|R|Reserved1| 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 | Valid Lifetime | 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 | Preferred Lifetime | 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | Reserved2 | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | | 2677 + + 2678 | | 2679 + Prefix + 2680 | | 2681 + + 2682 | | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 This format represents the following changes over that originally 2686 specified for Neighbor Discovery [12]: 2688 Router Address (R) 2690 1-bit router address flag. When set, indicates that the 2691 Prefix field, in addition to advertising the indicated prefix, 2692 contains a complete IP address assigned to the sending router. 2693 This router IP address has the same scope and conforms to the 2694 same lifetime values as the advertised prefix. This use of 2695 the Prefix field is compatible with its use in advertising 2696 the prefix itself, since prefix advertisement uses only the 2697 leading number Prefix bits specified by the Prefix Length 2698 field. Interpretation of this flag bit is thus independent 2699 of the processing required for the On-Link (L) and Autonomous 2700 Address-Configuration (A) flag bits. 2702 Reserved1 2704 Reduced from a 6-bit field to a 5-bit field to account for the 2705 addition of the Router Address (R) bit. 2707 In a solicited Router Advertisement, a home agent MUST, and all other 2708 routers SHOULD, include at least one Prefix Information option with 2709 the Router Address (R) bit set. Neighbor Discovery specifies that, 2710 if including all options in a Router Advertisement causes the size of 2711 the Advertisement to exceed the link MTU, multiple Advertisements can 2712 be sent, each containing a subset of the options [12]. In this case, 2713 at least one of these multiple Advertisements being sent instead 2714 of a single larger solicited Advertisement, MUST include a Prefix 2715 Information option with the Router Address (R) bit set. 2717 All routers SHOULD include at least one Prefix Information option 2718 with the Router Address (R) bit set, in each unsolicited multicast 2719 Router Advertisement that they send. If multiple Advertisements 2720 are being sent instead of a single larger unsolicited multicast 2721 Advertisement, at least one of these multiple Advertisements SHOULD 2722 include a Prefix Information option with the Router Address (R) bit 2723 set. 2725 7.3. New Advertisement Interval Option Format 2727 Mobile IPv6 defines a new Advertisement Interval option, used in 2728 Router Advertisement messages to advertise the interval at which the 2729 sending router sends unsolicited multicast Router Advertisements. 2730 The format of the Advertisement Interval option is as follows: 2732 0 1 2 3 2733 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 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 | Type | Length | Reserved | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 | Advertisement Interval | 2738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 Type 2742 7 2744 Length 2746 8-bit unsigned integer. The length of the option (including 2747 the type and length fields) in units of 8 octets. The value of 2748 this field MUST be 1. 2750 Reserved 2752 This field is unused. It MUST be initialized to zero by the 2753 sender and MUST be ignored by the receiver. 2755 Advertisement Interval 2757 32-bit unsigned integer. The maximum time, in milliseconds, 2758 between successive unsolicited router Router Advertisement 2759 messages sent by this router on this network interface. Using 2760 the conceptual router configuration variables defined by 2761 Neighbor Discovery [12], this field MUST be equal to the value 2762 MaxRtrAdvInterval, expressed in milliseconds. 2764 Routers MAY include this option in their Router Advertisements. A 2765 mobile node receiving a Router Advertisement containing this option 2766 SHOULD utilize the specified Advertisement Interval for that router 2767 in its movement detection algorithm, as described in Section 11.4.1. 2769 This option MUST be silently ignored for other Neighbor Discovery 2770 messages. 2772 7.4. New Home Agent Information Option Format 2774 Mobile IPv6 defines a new Home Agent Information option, used in 2775 Router Advertisement messages sent by a home agent to advertise 2776 information specific to this router's functionality as a home agent. 2777 The format of the Home Agent Information option is as follows: 2779 0 1 2 3 2780 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 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Type | Length | Reserved | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 | Home Agent Preference | Home Agent Lifetime | 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 Type 2789 8 2791 Length 2793 8-bit unsigned integer. The length of the option (including 2794 the type and length fields) in units of 8 octets. The value of 2795 this field MUST be 1. 2797 Reserved 2799 This field is unused. It MUST be initialized to zero by the 2800 sender and MUST be ignored by the receiver. 2802 Home Agent Preference 2804 16-bit signed, twos-complement integer. The preference for 2805 the home agent sending this Router Advertisement, for use in 2806 ordering the addresses returned to a mobile node in the Home 2807 Agent Addresses field of a Home Agent Address Discovery Reply 2808 message. Higher values mean more preferable. If this option 2809 is not included in a Router Advertisement in which the Home 2810 Agent (H) bit is set, the preference value for this home agent 2811 SHOULD be considered to be 0. Values greater than 0 indicate a 2812 home agent more preferable than this default value, and values 2813 less than 0 indicate a less preferable home agent. 2815 The manual configuration of the Home Agent Preference value 2816 is described in Section 8.4. In addition, the sending home 2817 agent MAY dynamically set the Home Agent Preference value, for 2818 example basing it on the number of mobile nodes it is currently 2819 serving or on its remaining resources for serving additional 2820 mobile nodes; such dynamic settings are beyond the scope of 2821 this document. Any such dynamic setting of the Home Agent 2822 Preference, however, MUST set the preference appropriately, 2823 relative to the default Home Agent Preference value of 0 that 2824 may be in use by some home agents on this link (i.e., a home 2825 agent not including a Home Agent Information option in its 2826 Router Advertisements will be considered to have a Home Agent 2827 Preference value of 0). 2829 Home Agent Lifetime 2831 16-bit unsigned integer. The lifetime associated with the 2832 home agent in units of seconds. The default value is the same 2833 as the Router Lifetime, as specified in the main body of the 2834 Router Advertisement message. The maximum value corresponds 2835 to 18.2 hours. A value of 0 MUST NOT be used. The Home Agent 2836 Lifetime applies only to this router's usefulness as a home 2837 agent; it does not apply to information contained in other 2838 message fields or options. 2840 Home agents MAY include this option in their Router Advertisements. 2841 This option MUST NOT be included in a Router Advertisement in which 2842 the Home Agent (H) bit (see Section 7.1) is not set. If this option 2843 is not included in a Router Advertisement in which the Home Agent (H) 2844 bit is set, the lifetime for this home agent MUST be considered to 2845 be the same as the Router Lifetime in the Router Advertisement. 2846 If multiple Advertisements are being sent instead of a single 2847 larger unsolicited multicast Advertisement, all of the multiple 2848 Advertisements with the Router Address (R) bit set MUST include this 2849 option with the same contents, otherwise this option MUST be omitted 2850 from all Advertisements. 2852 This option MUST be silently ignored for other Neighbor Discovery 2853 messages. 2855 If both the Home Agent Preference and Home Agent Lifetime are set 2856 to their default values specified above, this option SHOULD NOT be 2857 included in the Router Advertisement messages sent by this home 2858 agent. 2860 7.5. Changes to Sending Router Advertisements 2862 The Neighbor Discovery protocol specification [12] limits routers to 2863 a minimum interval of 3 seconds between sending unsolicited multicast 2864 Router Advertisement messages from any given network interface 2865 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 2867 "Routers generate Router Advertisements frequently enough 2868 that hosts will learn of their presence within a few 2869 minutes, but not frequently enough to rely on an absence 2870 of advertisements to detect router failure; a separate 2871 Neighbor Unreachability Detection algorithm provides failure 2872 detection." 2874 This limitation, however, is not suitable to providing timely 2875 movement detection for mobile nodes. Mobile nodes detect their 2876 own movement by learning the presence of new routers as the mobile 2877 node moves into wireless transmission range of them (or physically 2878 connects to a new wired network), and by learning that previous 2879 routers are no longer reachable. Mobile nodes MUST be able to 2880 quickly detect when they move to a link served by a new router, so 2881 that they can acquire a new care-of address and send Binding Updates 2882 to register this care-of address with their home agent and to notify 2883 correspondent nodes as needed. 2885 Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes 2886 this limit such that routers MAY send unsolicited multicast Router 2887 Advertisements more frequently. In particular, on network interfaces 2888 where the router is expecting to provide service to visiting mobile 2889 nodes (e.g., wireless network interfaces), or on which it is serving 2890 as a home agent to one or more mobile nodes (who may return home and 2891 need to hear its Advertisements), the router SHOULD be configured 2892 with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, 2893 to allow sending of unsolicited multicast Router Advertisements more 2894 often. Recommended values for these limits are: 2896 - MinRtrAdvInterval 0.05 seconds 2898 - MaxRtrAdvInterval 1.5 seconds 2900 Use of these modified limits MUST be configurable, and specific 2901 knowledge of the type of network interface in use SHOULD be taken 2902 into account in configuring these limits for each network interface. 2904 When sending unsolicited multicast Router Advertisements more 2905 frequently than the standard limit on unsolicited multicast 2906 Advertisement frequency, the sending router need not include all 2907 options in each of these Advertisements, but it SHOULD include at 2908 least one Prefix Information option with the Router Address (R) bit 2909 set (Section 7.2) in each. 2911 7.6. Changes to Sending Router Solicitations 2913 In addition to the limit on routers sending unsolicited multicast 2914 Router Advertisement messages (Section 7.5), Neighbor Discovery 2915 defines limits on nodes sending Router Solicitation messages, such 2916 that a node SHOULD send no more than 3 Router Solicitations, and that 2917 these 3 transmissions SHOULD be spaced at least 4 seconds apart. 2918 However, these limits prevent a mobile node from finding a new 2919 default router (and thus a new care-of address) quickly as it moves 2920 about. 2922 Mobile IPv6 relaxes this limit such that, while a mobile node is away 2923 from home, it MAY send Router Solicitations more frequently. The 2924 following limits for sending Router Solicitations are recommended for 2925 mobile nodes while away from home: 2927 - A mobile node that is not configured with any current care-of 2928 address (e.g., the mobile node has moved since its previous 2929 care-of address was configured), MAY send more than the defined 2930 Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router 2931 Solicitations. 2933 - The rate at which a mobile node sends Router Solicitations MUST 2934 be limited, although a mobile node MAY send Router Solicitations 2935 more frequently than the defined Neighbor Discovery limit of 2936 RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST 2937 be configurable, and specific knowledge of the type of network 2938 interface in use SHOULD be taken into account in configuring this 2939 limit for each network interface. A recommended minimum interval 2940 is 1 second. 2942 - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, 2943 a mobile node MUST reduce the rate at which it sends subsequent 2944 Router Solicitations. Subsequent Router Solicitations SHOULD 2945 be sent using a binary exponential backoff mechanism, doubling 2946 the interval between consecutive Router Solicitations, up to a 2947 maximum interval. The maximum interval MUST be configurable and 2948 SHOULD be chosen appropriately based on the characteristics of 2949 the type of network interface in use. 2951 - While still searching for a new default router and care-of 2952 address, a mobile node MUST NOT increase the rate at which it 2953 sends Router Solicitations unless it has received a positive 2954 indication (such as from lower network layers) that it has moved 2955 to a new link. After successfully acquiring a new care-of 2956 address, the mobile node SHOULD also increase the rate at which 2957 it will send Router Solicitations when it next begins searching 2958 for a new default router and care-of address. 2960 - A mobile node that is currently configured with a care-of address 2961 SHOULD NOT send Router Solicitations to the default router 2962 on its current link, until its movement detection algorithm 2963 (Section 11.4.1) determines that it has moved and that its 2964 current care-of address might no longer be valid. 2966 8. Requirements for Types of IPv6 Nodes 2968 Mobile IPv6 places some special requirements on the functions 2969 provided by different types of IPv6 nodes. This section summarizes 2970 those requirements, identifying the functionality each requirement is 2971 intended to support. 2973 The requirements are set for the following groups of nodes: 2975 - All IPv6 nodes. 2977 - All IPv6 nodes with support for route optimization. 2979 - All IPv6 routers. 2981 - All Mobile IPv6 home agents. 2983 - All Mobile IPv6 mobile nodes. 2985 It is outside the scope of this specification to specify which 2986 of these groups are mandatory in IPv6. We only describe what is 2987 mandatory for a node that supports, for instance, route optimization. 2988 Other specifications are expected to define the extent of IPv6. 2990 8.1. General Requirements for All IPv6 Nodes 2992 Any IPv6 node may at any time be a correspondent node of a mobile 2993 node, either sending a packet to a mobile node or receiving a 2994 packet from a mobile node. The following requirements are necessary 2995 for every IPv6 node (whether host or router, whether mobile or 2996 stationary), since otherwise communications may be impossible: 2998 - The node MUST be able to validate a Home Address option received 2999 in any IPv6 packet as described in Section 9.2.2. 3001 - The node MUST be able to send a Binding Error message as 3002 described in Section 9.4.6. 3004 8.2. Route Optimization Requirements for All IPv6 Nodes 3006 The ability of a correspondent node to participate in route 3007 optimization is essential for the efficient operation of the IPv6 3008 Internet, beneficial for robustness and reduction of jitter and 3009 latency, and necessary to avoid congestion in the home network. 3011 The following requirements apply to all nodes that support route 3012 optimization: 3014 - The node MUST be able to participate in a return routability 3015 procedure (Section 9.3). 3017 - The node MUST be able to process Binding Update messages 3018 (Section 9.4). 3020 - The node MUST be able to return a Binding Acknowledgement message 3021 (Section 6.1.8). 3023 - The node MUST be able to maintain a Binding Cache of the 3024 bindings received in accepted Binding Updates, as described in 3025 Sections 9.1 and 9.5. 3027 - The node MUST be able to insert a Routing Header type 2 into 3028 packets to be sent to a mobile node, as described in Section 9.6. 3030 - The node SHOULD be able to interpret ICMP messages as described 3031 in Section 9.7. 3033 8.3. Requirements for All IPv6 Routers 3035 All IPv6 routers, even those not serving as a home agent for 3036 Mobile IPv6, have an effect on how well mobile nodes can communicate: 3038 - Every IPv6 router SHOULD be able to send an Advertisement 3039 Interval option (Section 7.3) in each of its Router 3040 Advertisements [12], to aid movement detection by mobile nodes 3041 (as in Section 11.4.1). The use of this option in Router 3042 Advertisements MUST be configurable. 3044 - Every IPv6 router SHOULD be able to support sending unsolicited 3045 multicast Router Advertisements at the faster rate described in 3046 Section 7.5. The use of this faster rate MUST be configurable. 3048 - Each router SHOULD include at least one prefix with the `R' bit 3049 set and with its full IP address in its router advertisements (as 3050 described in Section 7.2). 3052 - Filtering routers SHOULD support different rules for Type 0 and 3053 Type 2 Routing headers (see Section 6.4) so that filtering of 3054 source routed packets (Type 0) will not necessarily limit MIPv6 3055 traffic which is delivered via Type 2 Routing headers. 3057 8.4. Requirements for IPv6 Home Agents 3059 In order for a mobile node to operate correctly while away from home, 3060 at least one IPv6 router on the mobile node's home link must function 3061 as a home agent for the mobile node. The following additional 3062 requirements apply to all IPv6 routers capable of serving as a home 3063 agent: 3065 - Every home agent MUST be able to maintain an entry in its Binding 3066 Cache for each mobile node for which it is serving as the home 3067 agent (Section 10.1). Each such Binding Cache entry records the 3068 mobile node's binding with its primary care-of address and is 3069 marked as a "home registration" (Section 10.2). 3071 - Every home agent MUST be able to intercept packets (using 3072 proxy Neighbor Discovery [12]) addressed to a mobile node for 3073 which it is currently serving as the home agent, on that mobile 3074 node's home link, while the mobile node is away from home 3075 (Section 10.4). 3077 - Every home agent MUST be able to encapsulate [15] such 3078 intercepted packets in order to tunnel them to the primary 3079 care-of address for the mobile node indicated in its binding in 3080 the home agent's Binding Cache (Section 10.5). 3082 - Every home agent MUST support decapsulating [15] reverse tunneled 3083 packets sent to it from a mobile node's home address. Every home 3084 agent MUST also check that the source address in the tunneled 3085 packets corresponds to the currently registered location of the 3086 mobile node (Section 10.6). 3088 - Every home agent MUST be able to return a Binding Acknowledgement 3089 message in response to a Binding Update option received with the 3090 Acknowledge (A) bit set (Section 10.2). 3092 - Every home agent MUST maintain a separate Home Agents List for 3093 each link on which it is serving as a home agent, as described in 3094 Section 4.5. 3096 - Every home agent MUST be able to accept packets addressed to 3097 the "Mobile IPv6 Home-Agents" anycast address for the subnet 3098 on which it is serving as a home agent [16], and MUST be 3099 able to participate in dynamic home agent address discovery 3100 (Section 10.9). 3102 - Every home agent SHOULD support a configuration mechanism to 3103 allow a system administrator to manually set the value to be sent 3104 by this home agent in the Home Agent Preference field of the Home 3105 Agent Information Option in Router Advertisements that it sends 3106 (Section 7.4). 3108 - Every home agent SHOULD support sending ICMP Mobile Prefix 3109 Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix 3110 Solicitations (Section 6.7). This behavior MUST be configurable, 3111 so that home agents can be configured to avoid sending such 3112 Prefix Advertisements according to the needs of the network 3113 administration in the home domain. 3115 8.5. Requirements for IPv6 Mobile Nodes 3117 Finally, the following requirements apply to all IPv6 nodes capable 3118 of functioning as mobile nodes: 3120 - Every IPv6 mobile node MUST be able to perform IPv6 encapsulation 3121 and decapsulation [15]. 3123 - Every IPv6 mobile node MUST support the return routability 3124 procedure (Section 5.2.5). 3126 - Every IPv6 mobile node MUST be able to send Binding Update 3127 messages, as specified in Sections 11.6.1, 11.6.2, and 11.6.6. 3129 - Every IPv6 mobile node MUST be able to receive and process 3130 Binding Acknowledgement messages, as specified in Section 11.6.3. 3132 - Every IPv6 mobile node MUST maintain a Binding Update List in 3133 which it records the IP address of each other node to which it 3134 has sent a Binding Update, for which the Lifetime sent in that 3135 binding has not yet expired (Section 11.1). 3137 - Every IPv6 mobile node MUST support receiving a Binding Refresh 3138 Request (Section 6.1.2), by responding with a Binding Update 3139 message. 3141 - Every IPv6 mobile node MUST support sending packets containing a 3142 Home Address option (Section 11.2.1). 3144 - Every IPv6 mobile node MUST maintain a Home Agents List, as 3145 described in Section 4.5. 3147 - Every mobile node MUST support receiving Mobile Prefix 3148 Advertisements (Section 11.3.4) and reconfiguring its home 3149 address based on the prefix information contained therein. 3151 - Every IPv6 mobile node SHOULD support use of the dynamic 3152 home agent address discovery mechanism, as described in 3153 Section 11.3.2. 3155 9. Correspondent Node Operation 3157 This section explains the special processing required for the return 3158 routability and binding procedures, as well as to manage the binding 3159 cache, handle ICMP messages and send packets to a mobile node. 3161 9.1. Conceptual Data Structures 3163 Each IPv6 node maintains a Binding Cache of bindings for other nodes. 3164 A separate Binding Cache SHOULD be maintained by each IPv6 node for 3165 each of its IPv6 addresses. The Binding Cache MAY be implemented in 3166 any manner consistent with the external behavior described in this 3167 document, for example by being combined with the node's Destination 3168 Cache as maintained by Neighbor Discovery [12]. When sending a 3169 packet, the Binding Cache is searched before the Neighbor Discovery 3170 conceptual Destination Cache [12] (i.e., any Binding Cache entry for 3171 this destination SHOULD take precedence over any Destination Cache 3172 entry for the same destination). 3174 Each Binding Cache entry conceptually contains the following fields: 3176 - The home address of the mobile node for which this is the Binding 3177 Cache entry. This field is used as the key for searching the 3178 Binding Cache for the destination address of a packet being sent. 3179 If the destination address of the packet matches the home address 3180 in the Binding Cache entry, this entry SHOULD be used in routing 3181 that packet. 3183 - The care-of address for the mobile node indicated by the home 3184 address field in this Binding Cache entry. If the destination 3185 address of a packet being routed by a node matches the home 3186 address in this entry, the packet SHOULD be routed to this 3187 care-of address. This is described in Section 9.6 for packets 3188 originated by this node, and in Section 10.5 if this node is the 3189 mobile node's home agent and the packet was intercepted by it on 3190 the home link. 3192 - A lifetime value, indicating the remaining lifetime for this 3193 Binding Cache entry. The lifetime value is initialized from 3194 the Lifetime field in the Binding Update that created or last 3195 modified this Binding Cache entry. Once the lifetime of this 3196 entry expires, the entry MUST be deleted from the Binding Cache. 3198 - A flag indicating whether or not this Binding Cache entry is a 3199 "home registration" entry. 3201 - The maximum value of the Sequence Number field received in 3202 previous Binding Updates for this mobile node home address. 3203 The Sequence Number field is 16 bits long, and all comparisons 3204 between Sequence Number values MUST be performed modulo 2**15 as 3205 explained in Section 9.4.1. 3207 - Recent usage information for this Binding Cache entry, as needed 3208 to implement the cache replacement policy in use in the Binding 3209 Cache and to assist in determining whether a Binding Refresh 3210 Request should be sent when the lifetime of this entry nears 3211 expiration. 3213 Binding Cache entries not marked as "home registrations" MAY be 3214 replaced at any time by any reasonable local cache replacement policy 3215 but SHOULD NOT be unnecessarily deleted. The Binding Cache for any 3216 one of a node's IPv6 addresses may contain at most one entry for 3217 each mobile node home address. The contents of a node's Binding 3218 Cache MUST NOT be changed in response to a Home Address option in 3219 a received packet. The contents of all of a node's Binding Cache 3220 entries, for each of its IPv6 addresses, MUST be cleared when the 3221 node reboots. 3223 9.2. Receiving Packets from a Mobile Node 3225 Packets sent by a mobile node with either a Home Address destination 3226 option or a Mobility Header (or both) require special processing at 3227 the correspondent node as explained below. 3229 9.2.1. Processing Mobility Header (MH) Messages 3231 All IPv6 correspondent nodes MUST observe the following rules when 3232 processing Mobility Header messages: 3234 1. If an MH message of unknown type is received (Section 6.1, the 3235 correspondent node SHOULD issue a Binding Error message to the 3236 packet's Source Address with Status field set to 2. Finally, the 3237 correspondent node MUST discard the packet. 3239 2. If the "Next Header" field is not NO_NXTHDR (59 decimal), the 3240 packet MUST be silently discarded. 3242 3. The checksum must be verified as per Section 6.1. 3244 Subsequent checks depend on the particular Mobility Header message, 3245 as specified in Sections 9.3 and 9.4. Subsequent checks depend 3246 on the particular Mobility Header message. There are two types 3247 of Mobility Header messages. The return routability procedure 3248 (Section 9.3) is used to verify liveness of the mobile node at both 3249 its home address as well as its care-of address. These liveness 3250 probes are used to secure binding updates. 3252 The other type of Mobility Header messages are directly concerned 3253 with managing bindings (Section 9.4). 3255 9.2.2. Receiving Packets with Home Address Destination Option 3257 If the correspondent node has a Binding Cache Entry for the home 3258 address of a mobile node, packets sent by the mobile node MAY include 3259 a Home Address destination option. The correspondent node MUST 3260 process the option in a manner consistent with exchanging the Home 3261 Address field from the Home Address option into the IPv6 header and 3262 replacing the original value of the Source Address field there. 3263 After all IPv6 options have been processed, it MUST be possible to 3264 process the packet without the knowledge that it came originally from 3265 a care-of address or that a Home Address option was used. 3267 Due to the threat of reflection attacks, this specification requires 3268 that packets containing a Home Address option MUST be dropped if 3269 there is no corresponding Binding Cache Entry for the given home 3270 address and the packet was not protected by IPsec. A corresponding 3271 Binding Cache Entry MUST have the currently registered care-of 3272 address equal to the source address of the packet. A packet that 3273 contains a Binding Update message and a Home Address option is 3274 considered to pass the above tests if the Binding Update successfully 3275 creates or updates a Binding Cache Entry. 3277 If the packet is dropped due the above tests, the correspondent nodes 3278 SHOULD send the Binding Error message to the source address of the 3279 packet that contained the Home Address option (see Section 6.1.9). 3280 The Status field in this message should be set to 1. These messages 3281 SHOULD be rate-limited. 3283 No additional authentication of the Home Address option is 3284 required, except that if the IPv6 header of a packet is covered 3285 by authentication, then that authentication MUST also cover the 3286 Home Address option; this coverage is achieved automatically by the 3287 definition of the Option Type code for the Home Address option, since 3288 it indicates that the data within the option cannot change en-route 3289 to the packet's final destination, and thus the option is included in 3290 the authentication computation. By requiring that any authentication 3291 of the IPv6 header also cover the Home Address option, the security 3292 of the Source Address field in the IPv6 header is not compromised by 3293 the presence of a Home Address option. Security issues related to 3294 the Home Address option are discussed further in Section 5. When 3295 attempting to verify authentication data in a packet that contains 3296 a Home Address option, the receiving node MUST make the calculation 3297 as if the care-of address were present in the Home Address option, 3298 and the home address were present in the source IPv6 address field 3299 of the IPv6 header. This conforms with the calculation specified in 3300 section 11.2.2. 3302 9.3. Return Routability Procedure 3304 This subsection specifies actions taken by a correspondent node 3305 during the return routability procedure. 3307 9.3.1. Receiving Home Test Init Messages 3309 Upon receiving a Home Test Init message, the correspondent node 3310 verifies the following: 3312 - MH Type field for this message is 1. 3314 - The Header Extension Length field MUST be greater than or equal 3315 to the length specified in Section 6.1.3. 3317 - The packet MUST NOT include a Home Address destination option. 3319 In preparation for sending the corresponding Home Test Message, 3320 the correspondent node checks that it has the necessary material 3321 to engage in a return routability procedure, as specified in 3322 Section 5.2. For that procedure, the correspondent node MUST have a 3323 secret Kcn and a nonce Nj. If it does not have this material yet, 3324 it MUST produce it before continuing with the return routability 3325 procedure. 3327 Section 9.3.3 specifies further processing. 3329 9.3.2. Receiving Care-of Test Init Messages 3331 Upon receiving a Care-of Test Init message, the correspondent node 3332 verifies the following: 3334 - MH Type field for this message is 2. 3336 - The Header Extension Length field MUST be greater than or equal 3337 to the length specified in Section 6.1.4. 3339 - The packet MUST NOT include a Home Address destination option. 3341 In preparation for sending the corresponding Care-of Test Message, 3342 the correspondent node checks that it has the necessary material 3343 to engage in a return routability procedure, as specified in 3344 Section 5.2. For that procedure, the correspondent node MUST have a 3345 secret Kcn and a nonce Nl. If it does not have this material yet, 3346 it MUST produce it before continuing with the return routability 3347 procedure. 3349 Section 9.3.4 specifies further processing. 3351 9.3.3. Sending Home Test Messages 3353 Unless already created, the correspondent node creates a "Home 3354 Cookie" and an associated "Home Nonce Index". It then creates a Home 3355 Test message (Section 6.1.5) and sends it to the mobile node at the 3356 latter's home address. 3358 9.3.4. Sending Care-of Test Messages 3360 Unless already created, the correspondent node creates a "Care-of 3361 Cookie" and an associated "Care-of Nonce Index". It then creates a 3362 Care-of Test message (Section 6.1.6) and sends it to the mobile node 3363 at the latter's care-of address. 3365 9.4. Processing Bindings 3367 This section explains how the correspondent node processes the 3368 binding cache messages. These messages are: 3370 - Binding Update 3372 - Binding Refresh Request 3374 - Binding Acknowledgement 3376 - Binding Error 3378 9.4.1. Receiving Binding Updates 3380 Before accepting a Binding Update message, the receiving node MUST 3381 validate the Binding Update according to the following tests: 3383 - The packet MUST contain a Home Address option. 3385 - The Header Len field in the Binding Update option is greater than 3386 or equal to the length specified in Section 6.1.7. 3388 - The Sequence Number field in the Binding Update message is 3389 greater than the Sequence Number received in the previous Binding 3390 Update for this home address, if any. 3392 This Sequence Number comparison MUST be performed modulo 2**16, 3393 i.e., the number is a free running counter represented modulo 3394 65536. A Sequence Number in a received Binding Update is 3395 considered less than or equal to the last received number if 3396 its value lies in the range of the last received number and the 3397 preceding 32767 values, inclusive. For example, if the last 3398 received sequence number was 15, then messages with sequence 3399 numbers 0 through 15, as well as 32784 through 65535, would be 3400 considered less than or equal. 3402 When the return routability procedure is used as an authorization 3403 method, the following are also required: 3405 - The Home and Care-of Nonce Index values in the Nonce Indices 3406 mobility option are recognized by the correspondent node. As 3407 described in Section 5.2, the correspondent node discards Nonce 3408 values that are too old. 3410 - The correspondent node MUST re-generate the Home Cookie and the 3411 Care-of Cookie from the information contained in the packet. 3412 It then generates the session key Kbu and uses it to verify 3413 the authenticator field in the Binding Update as specified in 3414 Section 6.1.7. Note that a care-of address different from the 3415 Source Address MAY have been specified by including an Alternate 3416 Care-of Address mobility option in the Binding Update message. 3417 When such message is received and the return routability 3418 procedure is used as an authorization method, the correspondent 3419 node MUST verify the authenticator by using the address within 3420 the Alternate Care-of Address in the calculations. 3422 - The Binding Authorization Data option MUST be present, and its 3423 contents MUST be satisfy rules presented in Section 5.2.6. 3425 If the mobile node sends a sequence number which is not greater than 3426 the sequence number from the last successful Binding Update, then the 3427 receiving node MUST send back a Binding Acknowledgement with status 3428 code 141, and the last accepted sequence number in the Sequence 3429 Number field of the Binding Acknowledgement. 3431 If the mobile node sends a Home or Care-of Nonce Index value which is 3432 no longer recognized by the correspondent node, then the receiving 3433 node MUST send back a Binding Acknowledgement with status code 144 or 3434 145, respectively. 3436 Any Binding Update which fails to satisfy all of these tests for 3437 any reason other than insufficiency of the Sequence Number or Nonce 3438 Indices MUST be silently ignored, and the packet carrying the Binding 3439 Update MUST be discarded. 3441 In this section, the care-of address refers to the IPv6 address, 3442 which was originally located in the IPv6 header when the packet was 3443 transmitted by the mobile node. 3445 If the Binding Update is valid according to the tests above, then the 3446 Binding Update is processed further as follows: 3448 - If the Lifetime specified in the Binding Update is nonzero and 3449 the specified Care-of Address is not equal to the home address 3450 for the binding, then this is a request to cache a binding for 3451 the mobile node. If the Home Registration (H) bit is set in the 3452 Binding Update, the Binding Update is processed according to the 3453 procedure specified in Section 10.2; otherwise, it is processed 3454 according to the procedure specified in Section 9.4.2. 3456 - If the Lifetime specified in the Binding Update is zero or the 3457 specified Care-of Address matches the home address for the 3458 binding, then this is a request to delete the mobile node's 3459 cached binding. If the Home Registration (H) bit is set in the 3460 Binding Update, the Binding Update is processed according to the 3461 procedure specified in Section 10.3; otherwise, it is processed 3462 according to the procedure specified in Section 9.4.3. 3464 9.4.2. Requests to Cache a Binding 3466 This section describes the processing of a valid Binding Update that 3467 requests a node to cache a mobile node's binding, for which the Home 3468 Registration (H) bit is not set in the Binding Update. 3470 In this case, the receiving node SHOULD create a new entry in its 3471 Binding Cache for this mobile node, or update its existing Binding 3472 Cache entry for this mobile node, if such an entry already exists. 3473 The lifetime for the Binding Cache entry is initialized from the 3474 Lifetime field specified in the Binding Update, although this 3475 lifetime MAY be reduced by the node caching the binding; the lifetime 3476 for the Binding Cache entry MUST NOT be greater than the Lifetime 3477 value specified in the Binding Update. Any Binding Cache entry MUST 3478 be deleted after the expiration of its lifetime. 3480 The Sequence Number value received from a mobile node in a Binding 3481 Update is stored by a correspondent node in its Binding Cache entry 3482 for that mobile node. If the receiving correspondent node has no 3483 Binding Cache entry for the sending mobile node, it MUST accept any 3484 Sequence Number value in a received Binding Update from this mobile 3485 node. 3487 9.4.3. Requests to Delete a Binding 3489 This section describes the processing of a valid Binding Update that 3490 requests a node to delete a mobile node's binding from its Binding 3491 Cache, for which the Home Registration (H) bit is not set in the 3492 Binding Update. 3494 Any existing binding for the mobile node MUST be deleted. A Binding 3495 Cache entry for the mobile node MUST NOT be created in response to 3496 receiving the Binding Update. 3498 If the binding cache entry was created by use of return routability 3499 nonces, the correspondent node MUST ensure that the same nonces are 3500 not used again with the particular home and care-of address. If 3501 both nonces are still valid, the correspondent node has to remember 3502 the particular combination of nonce indexes, addresses, and sequence 3503 number as illegal, until at least one of the nonces has become too 3504 old. 3506 9.4.4. Sending Binding Acknowledgements 3508 When any node receives a packet containing a Binding Update message 3509 in which the Acknowledge (A) bit is set, it MUST return a Binding 3510 Acknowledgement message acknowledging receipt of the Binding Update. 3511 If the node accepts the Binding Update and creates or updates an 3512 entry in its Binding Cache for this binding, the Status field in the 3513 Binding Acknowledgement MUST be set to a value less than 128; if, on 3514 the other hand the Binding Update is accepted and the `A' bit is not 3515 set, the node SHOULD NOT send a Binding Acknowledgement. If the node 3516 rejects the Binding Update and does not create or update an entry for 3517 this binding, a Binding Acknowledgement MUST be sent even if the `A' 3518 bit was not set, and the Status field in the Binding Acknowledgement 3519 MUST be set to a value greater than or equal to 128. Specific values 3520 for the Status field are described in Section 6.1.8 and in the IANA 3521 registry of assigned numbers [18]. 3523 The packet in which the Binding Acknowledgement is returned 3524 MUST meet the specific authentication requirements for Binding 3525 Acknowledgements, defined in Section 5.2. Furthermore, if the packet 3526 is to be sent to the mobile node at any address other than the mobile 3527 node's home address, it MUST be sent using a Routing header (even if 3528 the binding was rejected). The intermediate IP address, to which 3529 the packet will be delivered immediately before the home address, is 3530 determined as follows: 3532 - Whenever the Binding Update is accepted with a nonzero lifetime, 3533 the routing header will be constructed using the care-of address 3534 as described in Section 9.6. 3536 - Otherwise, if the Source IP Address of the packet containing 3537 the Binding Update, is legal for inclusion in a Routing Header, 3538 the routing header will be constructed using that IP address. 3539 Note that multicast addresses, link-local addresses, loopback 3540 addresses, IPv4 mapped addresses, and the unspecified address, 3541 MUST NOT be used within a Routing Header for the Binding 3542 Acknowledgement. 3544 Otherwise, if the Binding Update has a zero lifetime but the Source 3545 IP address is not allowable for use within the Routing Header, 3546 the Binding Acknowledgment MUST be sent to the mobile node's home 3547 address. 3549 Entries in a node's Binding Cache MUST be deleted when their lifetime 3550 expires. 3552 9.4.5. Sending Binding Refresh Requests 3554 If a Binding Cache entry being deleted is still in active use 3555 in sending packets to a mobile node, the next packet sent to the 3556 mobile node will be routed normally to the mobile node's home link. 3557 Communication with the mobile node continues, but the tunneling 3558 from the home network creates additional overhead and latency in 3559 delivering packets to the mobile node. 3561 If the sender knows that the Binding Cache entry is still in active 3562 use, it MAY send a Binding Refresh Request message to the mobile node 3563 in an attempt to avoid this overhead and latency due to deleting and 3564 recreating the Binding Cache entry. The Binding Refresh Request 3565 message is sent in the same way as any packet addressed to the mobile 3566 node (Section 9.6). 3568 The correspondent node MAY retransmit Binding Refresh Request 3569 messages provided that rate limitation is applied. The correspondent 3570 node SHOULD stop retransmitting when it receive a Home Test Init 3571 message, as the mobile node is responsible for retransmissions during 3572 the return routability procedure. 3574 9.4.6. Sending Binding Error Messages 3576 If the correspondent node receives a packet with a Home Address 3577 destination option it MUST verify that it has a binding for that 3578 mobile node. Specifically, it MUST have a binding entry for the 3579 mobile node's home address (as obtained from the Home Address option) 3580 at the mobile node's care-of address (from the IP source address of 3581 the packet). If the correspondent node does not find such a binding 3582 entry, it MUST discard the packet. It MUST also return a Binding 3583 Error message (Section 6.1.9), subject to rate limiting in the same 3584 manner as is done for ICMPv6 messages [14]. 3586 9.5. Cache Replacement Policy 3588 Conceptually, a node maintains a separate timer for each entry in its 3589 Binding Cache. When creating or updating a Binding Cache entry in 3590 response to a received and accepted Binding Update, the node sets the 3591 timer for this entry to the specified Lifetime period. Any entry in 3592 a node's Binding Cache MUST be deleted after the expiration of the 3593 Lifetime specified in the Binding Update from which the entry was 3594 created or last updated. 3596 Each node's Binding Cache will, by necessity, have a finite size. 3597 A node MAY use any reasonable local policy for managing the space 3598 within its Binding Cache, except that any entry marked as a "home 3599 registration" (Section 10.2) MUST NOT be deleted from the cache until 3600 the expiration of its lifetime period. When such "home registration" 3601 entries are deleted, the home agent MUST also cease intercepting 3602 packets on the mobile node's home link addressed to the mobile node 3603 (Section 10.4), just as if the mobile node had de-registered its 3604 primary care-of address (see Section 10.3). 3606 When attempting to add a new "home registration" entry in response 3607 to a Binding Update with the Home Registration (H) bit set, if no 3608 sufficient space can be found, the node MUST reject the Binding 3609 Update and MUST return a Binding Acknowledgement to the sending 3610 mobile node, in which the Status field is set to 131 (insufficient 3611 resources). When otherwise attempting to add a new entry to its 3612 Binding Cache, a node MAY, if needed, choose to drop any entry 3613 already in its Binding Cache, other than "home registration" 3614 entries, in order to make space for the new entry. For example, a 3615 "least-recently used" (LRU) strategy for cache entry replacement 3616 among entries not marked as "home registrations" is likely to 3617 work well unless the size of the Binding Cache is substantially 3618 insufficient. 3620 If the node sends a packet to a destination for which it has dropped 3621 the entry from its Binding Cache, the packet will be routed through 3622 the mobile node's home link. The mobile node can detect this, and 3623 establish a new binding if necessary. 3625 9.6. Sending Packets to a Mobile Node 3627 Before sending any packet, the sending node SHOULD examine its 3628 Binding Cache for an entry for the destination address to which the 3629 packet is being sent. If the sending node has a Binding Cache entry 3630 for this address, the sending node SHOULD use a Routing header to 3631 route the packet to this mobile node (the destination node) by way 3632 of the care-of address in the binding recorded in that Binding Cache 3633 entry. For example, assuming use of a Type 2 Routing header (see 3634 Section 6.4), if no other use of a Routing header is involved in 3635 the routing of this packet, the mobile node sets the fields in the 3636 packet's IPv6 header and Routing header as follows: 3638 - The Destination Address in the packet's IPv6 header is set to 3639 the mobile node's care-of address copied from the Binding Cache 3640 entry. 3642 - The Routing header is initialized to contain a single route 3643 segment, with an Address of the mobile node's home address (the 3644 original destination address to which the packet was being sent). 3646 Following the definition of a Type 2 Routing header in Section 6.4, 3647 this packet will be routed to the mobile node's care-of address, 3648 where it will be delivered to the mobile node (the mobile node has 3649 associated the care-of address with its network interface). 3651 Note that following the above conceptual model in an implementation 3652 creates some additional requirements for path MTU discovery since the 3653 layer that decides the packet size (e.g., TCP and applications using 3654 UDP) needs to be aware of the size of the headers added by the IP 3655 layer on the sending node. 3657 The IP layer will insert the routing header before performing IPsec 3658 processing. The IPsec Security Policy Database will be consulted 3659 based on the IP source address and the final IP destination (which 3660 will be in the routing header). The definition of AH ensures that 3661 the AH calculation is done on the packet in the form it will have on 3662 the receiver after advancing the routing header. 3664 If, instead, the sending node has no Binding Cache entry for the 3665 destination address to which the packet is being sent, the sending 3666 node simply sends the packet normally, with no Routing header. If 3667 the destination node is not a mobile node (or is a mobile node that 3668 is currently at home), the packet will be delivered directly to this 3669 node and processed normally by it. If, however, the destination node 3670 is a mobile node that is currently away from home, the packet will 3671 be intercepted by the mobile node's home agent and tunneled (using 3672 IPv6 encapsulation [15]) to the mobile node's current primary care-of 3673 address, as described in Section 10.5. The mobile node MAY then send 3674 a Binding Update to the sending node, as described in Section 11.6.2, 3675 allowing the sending node to create a Binding Cache entry for its use 3676 in sending subsequent packets to this mobile node. 3678 9.7. Receiving ICMP Error Messages 3680 When the correspondent node has a Binding Cache entry for a mobile 3681 node, all traffic destined to the mobile node goes directly to the 3682 current care-of address of the mobile node using a Routing header. 3683 Any ICMP error message caused by packets on their way to the care-of 3684 address will be returned in the normal manner to the correspondent 3685 node. 3687 On the other hand, if the correspondent node has no Binding Cache 3688 entry for the mobile node, the packet will be routed through the 3689 MN's home link. Any ICMP error message caused by the packet on its 3690 way to the mobile node while in the tunnel, will be transmitted 3691 to the mobile node's home agent. By the definition of IPv6 3692 encapsulation [15], the home agent MUST relay certain ICMP error 3693 messages back to the original sender of the packet, which in this 3694 case is the correspondent node. 3696 Likewise, if a packet for a mobile node arrives at the mobile node's 3697 previous link and is intercepted there by a home agent for the mobile 3698 node's previous care-of address (see Section 11.6.6), the packet will 3699 be tunneled to the mobile node's new care-of address. As above, any 3700 ICMP error message caused by the packet while in this tunnel will 3701 be returned to that home agent, which MUST relay certain ICMP error 3702 messages back to the correspondent node [15]. The relayed packet 3703 MUST NOT contain a routing header entry with the care-of address of 3704 the mobile node. 3706 Thus, in all cases, any meaningful ICMP error messages caused by 3707 packets from a correspondent node to a mobile node will be returned 3708 to the correspondent node. If the correspondent node receives 3709 persistent ICMP Destination Unreachable messages after sending 3710 packets to a mobile node based on an entry in its Binding Cache, the 3711 correspondent node SHOULD delete this Binding Cache entry. 3713 10. Home Agent Operation 3715 10.1. Conceptual Data Structures 3717 Each home agent MUST maintain a Binding Cache and Home Agents List. 3719 The rules for maintaining a Binding Cache are same for home 3720 agents and correspondent nodes, and have already been described in 3721 Section 9.1. In addition, if an entry in a node's Binding Cache 3722 for which the node is serving as a home agent is marked as a "home 3723 registration" entry, it MUST NOT be deleted by the home agent until 3724 the expiration of its binding lifetime. 3726 The Home Agents List is maintained by each home agent (as well as 3727 each mobile node), recording information about each home agent from 3728 which this node has received a Router Advertisement in which the Home 3729 Agent (H) bit is set, for which the remaining lifetime for this list 3730 entry (defined below) has not yet expired. The home agents list is 3731 thus similar to the Default Router List conceptual data structure 3732 maintained by each host for Neighbor Discovery [12], although the 3733 Home Agents List MAY be implemented in any manner consistent with the 3734 external behavior described in this document. 3736 Each home agent maintains a separate Home Agents List for each link 3737 on which it is serving as a home agent; this list is used by a home 3738 agent in the dynamic home agent address discovery mechanism. Each 3739 mobile node, while away from home, also maintains a Home Agents 3740 List, to enable it to notify a home agent on its previous link when 3741 it moves to a new link; a mobile node MAY maintain a separate Home 3742 Agents List for each link on which it has a home agent, or it MAY 3743 maintain a single list for all links. Each Home Agents List entry 3744 conceptually contains the following fields: 3746 - The link-local IP address of a router on the link, that this 3747 node currently believes is operating as a home agent for that 3748 link. A new entry is created or an existing entry is updated 3749 in the Home Agents List in response to receipt of a valid 3750 Router Advertisement in which the Home Agent (H) bit is set. 3751 The link-local address of the home agent is learned through 3752 the Source Address of the Router Advertisements received from 3753 it [12]. 3755 - One or more global IP addresses for this home agent, learned 3756 through Prefix Information options with the Router Address (R) 3757 bit set, received in Router Advertisements from this link-local 3758 address. Global addresses for the router in a Home Agents List 3759 entry MUST be deleted once the prefix associated with that 3760 address is no longer valid [12]. 3762 Are there interactions with the new Router Advertisement 3763 stuff? 3765 - The remaining lifetime of this Home Agents List entry. If a Home 3766 Agent Information Option is present in a Router Advertisement 3767 received from a home agent, the lifetime of the Home Agents List 3768 entry representing that home agent is initialized from the Home 3769 Agent Lifetime field in the option; otherwise, the lifetime 3770 is initialized from the Router Lifetime field in the received 3771 Router Advertisement. The Home Agents List entry lifetime is 3772 decremented until it reaches zero, at which time this entry MUST 3773 be deleted from the Home Agents List. 3775 - The preference for this home agent; higher values indicate a more 3776 preferable home agent. The preference value is taken from the 3777 Home Agent Preference field (a signed, twos-complement integer) 3778 in the received Router Advertisement, if the Router Advertisement 3779 contains a Home Agent Information Option, and is otherwise set 3780 to the default value of 0. A home agent uses this preference 3781 in ordering the Home Agents List returned in an ICMP Home 3782 Agent Address Discovery message in response to a mobile node's 3783 initiation of dynamic home agent address discovery. A mobile 3784 node uses this preference in determining which of the home agents 3785 on its previous link to notify when it moves to a new link. 3787 10.2. Primary Care-of Address Registration 3789 This section describes the processing of a valid Binding Update that 3790 requests the receiving node to serve as its home agent, registering 3791 its primary care-of address. 3793 To begin processing the Binding Update, the home agent MUST perform 3794 the following sequence of tests: 3796 - If the node is not a router that implements home agent 3797 functionality, then the node MUST reject the Binding Update 3798 and MUST return a Binding Acknowledgement to the mobile node, 3799 in which the Status field is set to 132 (home registration not 3800 supported). 3802 - Else, if the home address for the binding (the Home Address field 3803 in the packet's Home Address option) is not an on-link IPv6 3804 address with respect to the home agent's current Prefix List, 3805 then the home agent MUST reject the Binding Update and SHOULD 3806 return a Binding Acknowledgement to the mobile node, in which the 3807 Status field is set to 133 (not home subnet). 3809 - Else, if the home agent chooses to reject the Binding Update for 3810 any other reason (e.g., insufficient resources to serve another 3811 mobile node as a home agent), then the home agent SHOULD return a 3812 Binding Acknowledgement to the mobile node, in which the Status 3813 field is set to an appropriate value to indicate the reason for 3814 the rejection. 3816 - A Home Address destination option MUST be present in the message. 3818 - Finally, if the Duplicate Address Detection (D) bit is set in the 3819 Binding Update, this home agent MUST perform Duplicate Address 3820 Detection [13] on the mobile node's home link for the link-local 3821 address associated with the home address in this binding, before 3822 returning the Binding Acknowledgement. This ensures that no 3823 other node on the home link was using the mobile node's home 3824 address when the Binding Update arrived 3826 If home agent accepts the Binding Update, it MUST then create a 3827 new entry in its Binding Cache for this mobile node, or update its 3828 existing Binding Cache entry, if such an entry already exists. The 3829 Home Address field as received in the Home Address option provides 3830 the home address of the mobile node. The care-of address for this 3831 Binding Cache entry is determined as follows: 3833 - If the Alternate Care-of Address option is present, the care-of 3834 address is the address in that option. 3836 - Otherwise, the care-of address is the the Source Address field in 3837 the packet's IPv6 header. 3839 The home agent MUST mark this Binding Cache entry as a "home 3840 registration" to indicate that the node is serving as a home 3841 agent for this binding. Binding Cache entries marked as a "home 3842 registration" MUST be excluded from the normal cache replacement 3843 policy used for the Binding Cache (Section 9.5) and MUST NOT be 3844 removed from the Binding Cache until the expiration of the Lifetime 3845 period. 3847 When the 'D' bit is set, the address used for Duplicate Address 3848 Detection SHOULD be the mobile node's link-local address. Normal 3849 processing for Duplicate Address Detection specifies that, in 3850 certain cases, the node SHOULD delay sending the initial Neighbor 3851 Solicitation message of Duplicate Address Detection by a random 3852 delay between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13]; however, in 3853 this case, the home agent SHOULD NOT perform such a delay. If this 3854 Duplicate Address Detection fails, then the home agent MUST reject 3855 the Binding Update and MUST return a Binding Acknowledgement to the 3856 mobile node, in which the Status field is set to 138 (Duplicate 3857 Address Detection failed). When the home agent sends a successful 3858 Binding Acknowledgement to the mobile node, in response to a Binding 3859 Update with the `D' bit set, the home agent assures to the mobile 3860 node that its home address will continue to be kept unique by the 3861 home agent at least as long as the lifetime granted for that home 3862 address binding is not over. 3864 If the `S' bit field in the Binding Update is zero, The home agent 3865 creates or updates Binding Cache entries for each of possibly 3866 several home addresses. The set of such home addresses is formed 3867 by replacing the routing prefix for the given home address with 3868 all other routing prefixes on the mobile node's home link that are 3869 supported by the home agent processing the Binding Update. The home 3870 agent creates such a separate primary care-of address registration 3871 for each such home address. Note that the same considerations for 3872 Duplicate Address Detection apply for each affected home address. 3874 The specific addresses which are to be tested before accepting the 3875 Binding Update, and later to be defended by performing Duplicate 3876 Address Detection, depend on the settings of the `S' and `L' bits, as 3877 follows: 3879 - S=0 & L=0: Defend all non link-local unicast addresses possible 3880 on link. 3882 - S=0 & L=1: Defend all non link-local unicast addresses possible 3883 on link and the derived link-local. 3885 - S=1 & L=0: Defend the given address. 3887 - S=1 & L=1: Defend both the given non link-local unicast (home) 3888 address and the derived link-local. 3890 The lifetime of the Binding Cache entry depends on a number of 3891 factors: 3893 - The lifetime for the Binding Cache entry MUST NOT be greater 3894 than the remaining valid lifetime for the subnet prefix in the 3895 mobile node's home address specified with the Binding Update, 3896 and MUST NOT be greater than the Lifetime value specified in the 3897 Binding Update. The remaining valid lifetime for this prefix is 3898 determined by the home agent based on its own Prefix List entry 3899 for this prefix [12]. 3901 - However, if the `S' bit field in the Binding Update is zero, the 3902 lifetime for the each Binding Cache entry MUST NOT be greater 3903 than the minimum remaining valid lifetime for all subnet prefixes 3904 on the mobile node's home link. If the value of the Lifetime 3905 field specified by the mobile node in its Binding Update is 3906 greater than this prefix lifetime, the home agent MUST decrease 3907 the binding lifetime to less than or equal to the prefix valid 3908 lifetime. 3910 - The home agent MAY further decrease the specified lifetime for 3911 the binding, for example based on a local policy. The resulting 3912 lifetime is stored by the home agent in the Binding Cache entry, 3913 and this Binding Cache entry MUST be deleted by the home agent 3914 after the expiration of this lifetime. 3916 Regardless of the setting of the `A' bit in the Binding Update, the 3917 home agent MUST return a Binding Acknowledgement to the mobile node, 3918 constructed as follows: 3920 - The Status field MUST be set to a value 0, indicating success. 3922 - The Sequence Number field MUST be copied from the Sequence Number 3923 given in the Binding Update. 3925 - The Lifetime field MUST be set to the remaining lifetime for 3926 the binding as set by the home agent in its "home registration" 3927 Binding Cache entry for the mobile node, as described above. 3929 - The Refresh field MUST be set to a value less than or equal to 3930 the Lifetime value being returned in the Binding Update. If the 3931 home agent stores the Binding Cache entry in nonvolatile storage 3932 (that survives the crash or other failure of the home agent), 3933 then the Refresh field SHOULD be set to the same value as the 3934 Lifetime field; otherwise, the home agent MAY set the Refresh 3935 field to a value less than the Lifetime field, to indicate that 3936 the mobile node SHOULD attempt to refresh its home registration 3937 at the indicated shorter interval (although the home agent will 3938 still retain the registration for the Lifetime period, even if 3939 the mobile node does not refresh its registration within the 3940 Refresh period). 3942 The rules for selecting the Destination IP address (and possibly 3943 Routing Header construction) for the Binding Acknowledgement to the 3944 mobile node are the same as in section 9.4.4. 3946 In addition, the home agent MUST follow the procedure defined in 3947 Section 10.4 to intercept packets on the mobile node's home link 3948 addressed to the mobile node, while the home agent is serving as 3949 the home agent for this mobile node. The home agent MUST also be 3950 prepared to accept reverse tunneled packets from the new care-of 3951 address of the mobile node, as described in Section 10.6. Finally, 3952 the home agent MUST also propagate new home network prefixes, as 3953 described in Section 10.9.1. 3955 10.3. Primary Care-of Address De-Registration 3957 When a node receives a Binding Update, it MUST validate it and 3958 determine the type of Binding Update according to the steps described 3959 in Section 9.4.1. This section describes the processing of a valid 3960 Binding Update that requests the receiving node to no longer serve as 3961 its home agent, de-registering its primary care-of address. 3963 To begin processing the Binding Update, the home agent MUST perform 3964 the following test: 3966 - If the receiving node has no entry marked as a "home 3967 registration" in its Binding Cache for this mobile node, then 3968 this node MUST reject the Binding Update and SHOULD return a 3969 Binding Acknowledgement to the mobile node, in which the Status 3970 field is set to 137 (not home agent for this mobile node). 3972 If the home agent does not reject the Binding Update as described 3973 above, then it MUST delete any existing entry in its Binding Cache 3974 for this mobile node, and proceed as follows. 3976 The home agent MUST return a Binding Acknowledgement to the mobile 3977 node, constructed as follows: 3979 - The Status field MUST be set to a value 0, indicating success. 3981 - The Sequence Number field MUST be copied from the Sequence Number 3982 given in the Binding Update. 3984 - The Lifetime field MUST be set to zero. 3986 - The Refresh field MUST be set to zero. 3988 In addition, the home agent MUST stop intercepting packets on 3989 the mobile node's home link that are addressed to the mobile node 3990 (Section 10.4). 3992 The rules for selecting the Destination IP address (and possibly 3993 Routing Header construction) for the Binding Acknowledgement to the 3994 mobile node are the same as in section 9.4.4. 3996 10.4. Intercepting Packets for a Mobile Node 3998 While a node is serving as the home agent for mobile node it MUST 3999 attempt to intercept packets on the mobile node's home link that are 4000 addressed to the mobile node, and MUST tunnel each intercepted packet 4001 to the mobile node using IPv6 encapsulation [15]. 4003 In order to do this, when a node begins serving as the home agent 4004 it MUST multicast onto the home link a Neighbor Advertisement 4005 message [12] on behalf of the mobile node. Specifically, the home 4006 agent performs the following steps: 4008 - The home agent examines the value of the `S' bit in the received 4009 Binding Update message. If this bit is nonzero, the following 4010 step is carried out only for the individual home address 4011 specified for this binding. If, instead, this bit is zero, then 4012 the following step is carried out for each address for the mobile 4013 node formed from the interface identifier in the mobile node's 4014 home address in this binding (the remaining low-order bits in 4015 the address after the configured subnet prefix), together with 4016 each one of the subnet prefixes currently considered by the home 4017 agent to be on-link (including both the link-local and site-local 4018 prefix). 4020 - For each specific IP address for the mobile node determined 4021 in the first step above, the home agent sends a Neighbor 4022 Advertisement message [12] to the all-nodes multicast address 4023 on the home link, to advertise the home agent's own link-layer 4024 address for this IP address on behalf of the mobile node. 4026 All fields in each such Neighbor Advertisement message SHOULD be 4027 set in the same way they would be set by the mobile node itself 4028 if sending this Neighbor Advertisement while at home [12], with 4029 the following exceptions: 4031 * The Target Address in the Neighbor Advertisement message MUST 4032 be set to the specific IP address for the mobile node. 4034 * The Advertisement MUST include a Target Link-layer Address 4035 option specifying the home agent's link-layer address. 4037 * The Router (R) bit in the Advertisement MUST be set to zero. 4039 * The Solicited Flag (S) in the Advertisement MUST NOT be set, 4040 since it was not solicited by any Neighbor Solicitation 4041 message. 4043 * The Override Flag (O) in the Advertisement MUST be set, 4044 indicating that the Advertisement SHOULD override any 4045 existing Neighbor Cache entry at any node receiving it. 4047 Any node on the home link receiving one of the Neighbor Advertisement 4048 messages described above will thus update its Neighbor Cache to 4049 associate the mobile node's address with the home agent's link 4050 layer address, causing it to transmit any future packets for the 4051 mobile node normally destined to this address instead to the mobile 4052 node's home agent. Since multicasting on the local link (such as 4053 Ethernet) is typically not guaranteed to be reliable, the home 4054 agent MAY retransmit this Neighbor Advertisement message up to 4055 MAX_ADVERT_REXMIT times to increase its reliability. It is still 4056 possible that some nodes on the home link will not receive any of 4057 these Neighbor Advertisements, but these nodes will eventually be 4058 able to detect the link-layer address change for the mobile node's 4059 home address, through use of Neighbor Unreachability Detection [12]. 4061 While a node is serving as a home agent for some mobile node (it 4062 still has a "home registration" entry for this mobile node in its 4063 Binding Cache), the home agent uses IPv6 Neighbor Discovery [12] to 4064 intercept unicast packets on the home link addressed to the mobile 4065 node's home address. In order to intercept packets in this way, the 4066 home agent MUST act as a proxy for this mobile node, and reply to any 4067 received Neighbor Solicitation messages for it. When a home agent 4068 receives a Neighbor Solicitation message, it MUST check if the Target 4069 Address specified in the message matches the home address of any 4070 mobile node for which it has a Binding Cache entry marked as a "home 4071 registration". (Note that Binding Update messages with the `S' bit 4072 set to zero will result in multiple Binding Cache entries, so checks 4073 on all these entries necessarily include all possible home addresses 4074 for the mobile node). 4076 If such an entry exists in the home agent's Binding Cache, the home 4077 agent MUST reply to the Neighbor Solicitation message with a Neighbor 4078 Advertisement message, giving the home agent's own link-layer address 4079 as the link-layer address for the specified Target Address. In 4080 addition, the Router (R) bit in the Advertisement MUST be set to 4081 zero. Acting as a proxy in this way allows other nodes on the mobile 4082 node's home link to resolve the mobile node's IPv6 home address, and 4083 allows the home agent to defend these addresses on the home link for 4084 Duplicate Address Detection [12]. 4086 10.5. Tunneling Intercepted Packets to a Mobile Node 4088 For any packet sent to a mobile node from the mobile node's home 4089 agent (for which the home agent is the original sender of the 4090 packet), the home agent is operating as a correspondent node of 4091 the mobile node for this packet and the procedures described in 4092 Section 9.6 apply. The home agent (as a correspondent node) uses a 4093 Routing header to route the packet to the mobile node by way of the 4094 care-of address in the home agent's Binding Cache (the mobile node's 4095 primary care-of address, in this case). 4097 While the mobile node is away from home and this node is acting 4098 as the mobile node's home agent, the home agent intercepts any 4099 packets on the home link addressed to the mobile node's home 4100 address (including addresses formed from other on-link prefixes, 4101 if the 'S' bit was zero in the Binding Update), as described in 4102 Section 10.4. The home agent cannot use a Routing header to forward 4103 these intercepted packets to the mobile node, since it cannot modify 4104 the packet in flight without invalidating any existing IPv6 AH [5] or 4105 ESP [6] header present in the packet. 4107 In order to forward each intercepted packet to the mobile node, the 4108 home agent MUST tunnel the packet to the mobile node using IPv6 4109 encapsulation [15]; the tunnel entry point node is the home agent, 4110 and the tunnel exit point node is the primary care-of address as 4111 registered with the home agent. When a home agent encapsulates 4112 an intercepted packet for forwarding to the mobile node, the home 4113 agent sets the Source Address in the new tunnel IP header to the 4114 home agent's own IP address, and sets the Destination Address 4115 in the tunnel IP header to the mobile node's primary care-of 4116 address. When received by the mobile node (using its primary care-of 4117 address), normal processing of the tunnel header [15] will result in 4118 decapsulation and processing of the original packet by the mobile 4119 node. 4121 However, packets addressed to the mobile node's link-local address 4122 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 4123 be discarded, and the home agent SHOULD return an ICMP Destination 4124 Unreachable, Code 3, message to the packet's Source Address (unless 4125 this Source Address is a multicast address). Packets addressed to 4126 the mobile node's site-local address SHOULD be tunneled to the mobile 4127 node by default, but this behavior MUST be configurable to disable 4128 it; currently, the exact definition and semantics of a "site" and a 4129 site-local address are incompletely defined in IPv6, and this default 4130 behavior might change at some point in the future. 4132 Tunneling of multicast packets to a mobile node follows similar 4133 limitations to those defined above for unicast packets addressed to 4134 the mobile node's link-local and site-local addresses. Multicast 4135 packets addressed to a multicast address with link-local scope [3], 4136 to which the mobile node is subscribed, MUST NOT be tunneled 4137 to the mobile node; such packets SHOULD be silently discarded 4138 (after delivering to other local multicast recipients). Multicast 4139 packets addressed to a multicast address with scope larger 4140 than link-local but smaller than global (e.g., site-local and 4141 organization-local) [3], to which the mobile node is subscribed, 4142 SHOULD be tunneled to the mobile node by default, but this behavior 4143 MUST be configurable to disable it; this default behavior might 4144 change at some point in the future as the definition of these scopes 4145 become more completely defined in IPv6. 4147 Before tunneling a packet to the mobile node, the home agent MUST 4148 perform any IPsec processing as indicated by the security policy data 4149 base. 4151 10.6. Handling Reverse Tunneled Packets from a Mobile Node 4153 Unless a binding has been established between the mobile node and a 4154 correspondent node, traffic from the mobile node to the correspondent 4155 node goes through a reverse tunnel. This tunnel extends between the 4156 mobile node and the home agent. Home agents MUST support reverse 4157 tunneling as follows: 4159 - The tunneled traffic arrives to the home agent using IPv6 4160 encapsulation [15]. 4162 - The tunnel entry point is the primary care-of address as 4163 registered with the home agent and the tunnel exit point is the 4164 home agent. 4166 - When a home agent decapsulates a tunneled packet from the mobile 4167 node, the home agent verifies that the Source Address in the 4168 tunnel IP header is the mobile node's primary care-of address. 4170 Reverse tunneled packets MAY be discarded unless accompanied by a 4171 valid AH or ESP header, depending on the security policies used by 4172 the home agent. In any case, the home agent MUST check that the 4173 source address in the tunneled packets corresponds to the currently 4174 registered location of the mobile node, as otherwise any node in the 4175 Internet could send traffic through the home agent and escape ingress 4176 filtering limitations. 4178 The support for authenticated reverse tunneling allows the home agent 4179 to protect the home network and correspondent nodes from malicious 4180 nodes masquerading as a mobile node, even if they know the current 4181 location of the real mobile node. 4183 10.7. Protecting Return Routability Packets 4185 The return routability procedure described in Section 5 assumes that 4186 the confidentiality of the Home Test Init and Home Test messages is 4187 protected as it is tunneled from the home agent to the mobile node. 4188 Therefore, the home agent MUST support IPsec ESP for the protection 4189 of packets belonging to the return routability procedure. Support 4190 for a non-null encryption transform MUST be available. In this case 4191 it isn't necessary to distinguish between different kinds of packets 4192 within the return routability procedure. 4194 The above protection SHOULD be turned on and used with all mobile 4195 nodes. The use is controlled by configuration of the IPsec security 4196 policy database both at the mobile node and at the home agent. 4198 As described earlier, the Binding Update and Binding Acknowledgement 4199 messages require protection between the home agent and the mobile 4200 node. These messages and the return routability messages employ 4201 the same protocol from the point of view of the security policy 4202 database, the Mobility Header. One way to set up the security policy 4203 database is to have one rule for the Mobility Header traffic between 4204 the mobile node and the home agent addresses, and an optional rule 4205 following it for Mobility Header traffic between the mobile node and 4206 any other address. 4208 10.8. Receiving Router Advertisement Messages 4210 For each link on which a router provides service as a home agent, 4211 the router maintains a Home Agents List recording information 4212 about all other home agents on that link. This list is used in 4213 the dynamic home agent address discovery mechanism, described in 4214 Section 10.9. The information for the list is learned through 4215 receipt of the periodic unsolicited multicast Router Advertisements, 4216 in a manner similar to the Default Router List conceptual data 4217 structure maintained by each host for Neighbor Discovery [12]. In 4218 the construction of the Home Agents List, the Router Advertisements 4219 are from each other home agent on the link, and the Home Agent (H) 4220 bit is set in them. 4222 On receipt of a valid Router Advertisement, as defined in the 4223 processing algorithm specified for Neighbor Discovery [12], the home 4224 agent performs the following steps, in addition to any steps already 4225 required of it by Neighbor Discovery: 4227 - If the Home Agent (H) bit in the Router Advertisement is not set, 4228 check to see if the sending node has an entry in the current Home 4229 Agents List. If it does, delete the corresponding entry. In any 4230 case all of the following steps are skipped. 4232 - Otherwise, extract the Source Address from the IP header of the 4233 Router Advertisement. This is the link-local IP address on this 4234 link of the home agent sending this Advertisement [12]. 4236 - Determine from the Router Advertisement the preference for this 4237 home agent. If the Router Advertisement contains a Home Agent 4238 Information Option, then the preference is taken from the Home 4239 Agent Preference field in the option; otherwise, the default 4240 preference of 0 MUST be used. 4242 - Determine from the Router Advertisement the lifetime for 4243 this home agent. If the Router Advertisement contains a Home 4244 Agent Information Option, then the lifetime is taken from 4245 the Home Agent Lifetime field in the option; otherwise, the 4246 lifetime specified by the Router Lifetime field in the Router 4247 Advertisement SHOULD be used. 4249 - If the link-local address of the home agent sending this 4250 Advertisement is already present in this home agent's Home 4251 Agents List and the received home agent lifetime value is zero, 4252 immediately delete this entry in the Home Agents List. 4254 - Otherwise, if the link-local address of the home agent sending 4255 this Advertisement is already present in the receiving home 4256 agent's Home Agents List, reset its lifetime and preference to 4257 the values determined above. 4259 - If the link-local address of the home agent sending this 4260 Advertisement, as determined above, is not already present in 4261 the Home Agents List maintained by the receiving home agent, and 4262 the lifetime for the sending home agent, as determined above, 4263 is non-zero, create a new entry in the list, and initialize its 4264 lifetime and preference to the values determined above. 4266 - If the Home Agents List entry for the link-local address of 4267 the home agent sending this Advertisement was not deleted as 4268 described above, determine any global address(es) of the home 4269 agent based on each Prefix Information option received in 4270 this Advertisement in which the Router Address (R) bit is set 4271 (Section 7.2). For each such global address determined from this 4272 Advertisement, add this global address to the list of global 4273 addresses for this home agent in this Home Agents List entry. 4275 A home agent SHOULD maintain an entry in its Home Agents List for 4276 each such valid home agent address until that entry's lifetime 4277 expires, after which time the entry MUST be deleted. 4279 10.9. Dynamic Home Agent Address Discovery 4281 A mobile node, while away from home, MAY use the dynamic home agent 4282 address discovery mechanism in section 11.3.2 to attempt to discover 4283 the address of one or more routers serving as home agents on its home 4284 link. This discovery might become necessary, for example, if some 4285 nodes on its home link have been reconfigured while the mobile node 4286 has been away from home, such that the router that was operating as 4287 the mobile node's home agent has been replaced by a different router 4288 serving this role. 4290 As described in Section 11.3.2, a mobile node attempts dynamic 4291 home agent address discovery by sending an ICMP Home Agent Address 4292 Discovery Request message to the "Mobile IPv6 Home-Agents" anycast 4293 address [16] for its home IP subnet prefix, using its care-of address 4294 as the Source Address of the packet. A home agent receiving such a 4295 Home Agent Address Discovery Request message that is serving this 4296 subnet (the home agent is configured with this anycast address on one 4297 of its network interfaces) SHOULD return an ICMP Home Agent Address 4298 Discovery Reply message to the mobile node (at its care-of address 4299 that was used as the Source Address of the Request message), with the 4300 Source Address of the Reply packet set to one of the global unicast 4301 addresses of the home agent. The Home Agent Addresses field in the 4302 Reply message is constructed as follows: 4304 - The Home Agent Addresses field SHOULD contain one global IP 4305 address for each home agent currently listed in this home 4306 agent's own Home Agents List (Section 4.5). However, if this 4307 home agent's own global IP address would be placed in the list 4308 (as described below) as the first entry in the list, then this 4309 home agent SHOULD NOT include its own address in the Home Agent 4310 Addresses field in the Reply message. Not placing this home 4311 agent's own IP address in the list will cause the receiving 4312 mobile node to consider this home agent as the most preferred 4313 home agent; otherwise, this home agent will be considered to be 4314 preferred in its order given by its place in the list returned. 4316 - The IP addresses in the Home Agent Addresses field SHOULD be 4317 listed in order of decreasing preference value, based either 4318 on the respective advertised preference from a Home Agent 4319 Information option or on the default preference of 0 if no 4320 preference is advertised (or on the configured home agent 4321 preference for this home agent itself). The home agent with 4322 the highest preference SHOULD be listed first in the Home Agent 4323 Addresses field, and the home agent with the lowest preference 4324 SHOULD be listed last. 4326 - Among home agents with equal preference, their IP addresses 4327 in the Home Agent Addresses field SHOULD be listed in an 4328 order randomized with respect to other home agents with equal 4329 preference, each time a Home Agent Address Discovery Reply 4330 message is returned by this home agent. 4332 - For each entry in this home agent's Home Agents List, if more 4333 than one global IP address is associated with this list entry, 4334 then one of these global IP addresses SHOULD be selected 4335 to include in the Home Agent Addresses field in the Reply 4336 message. As described in Section 4.5, one Home Agents List 4337 entry, identified by the home agent's link-local address, 4338 exists for each home agent on the link; associated with that 4339 list entry is one or more global IP addresses for this home 4340 agent, learned through Prefix Information options with the 4341 Router Address (R) bit is set, received in Router Advertisements 4342 from this link-local address. 4344 The selected global IP address for each home agent to include in 4345 forming the Home Agent Addresses field in the Reply message MUST 4346 be the global IP address of the respective home agent sharing a 4347 prefix with the Destination IP address of the Request message; 4348 if no such global IP address is known for some home agent, an 4349 entry for that home agent MUST NOT be included in the Home Agent 4350 Addresses field in the Reply message. 4352 - In order to avoid the possibility of the Reply message packet 4353 being fragmented (or rejected by an intermediate router with an 4354 ICMP Packet Too Big message [14]), if the resulting total packet 4355 size containing the complete list of home agents in the Home 4356 Agent Addresses field would exceed the minimum IPv6 MTU [11], the 4357 home agent SHOULD reduce the number of home agent IP addresses 4358 returned in the packet to the number of addresses that will fit 4359 without exceeding this limit. The home agent addresses returned 4360 in the packet SHOULD be those from the complete list with the 4361 highest preference. 4363 10.9.1. Aggregate List of Home Network Prefixes 4365 IPv6 provides mechanisms for node configuration when it turns on, 4366 and in renumbering a subnet, such as when a site switches to a new 4367 network service provider. These mechanisms are a part of Neighbor 4368 Discovery [12] and Address Autoconfiguration [13]. 4370 In renumbering, new prefixes and addresses can be introduced for the 4371 subnet and old ones can be deprecated and removed. These mechanisms 4372 are defined to work while all nodes using the old prefixes are at 4373 home, connected to the link using these prefixes. Mobile IPv6 4374 extends these mechanisms to work also with mobile nodes that are away 4375 from home when the renumbering takes place. 4377 Mobile IPv6 arranges to propagate relevant prefix information to the 4378 mobile node when it is away from home, so that it may be used in 4379 mobile node home address configuration, and in network renumbering. 4380 In this mechanism, mobile nodes away from home receive Mobile Prefix 4381 Advertisements messages with Prefix Information Options, which give 4382 the valid lifetime and preferred lifetime for available prefixes on 4383 the home link. 4385 To avoid possible security attacks from forged Mobile Prefix 4386 Advertisements all such Advertisements MUST be authenticated to the 4387 mobile node by its home agent using IPsec [4, 5, 6]. 4389 A mobile node on a remote network SHOULD autoconfigure all of the 4390 global IP addresses, which it would autoconfigure if it were attached 4391 to its home network, from network prefixes representing network 4392 addresses that are served by home agents. Site-local addresses MAY 4393 be autoconfigured if the mobile node is roaming in a network on the 4394 same site as its home addresses. Site-local addresses and addresses 4395 not served by a home agent MUST NOT be autoconfigured, since they are 4396 unusable in the remote network. 4398 To support this, the home agent monitors prefixes advertised by 4399 itself and other home agents routers on the home link, and passes 4400 this aggregated list of relevant subnet prefixes on to the mobile 4401 node in Mobile Prefix Advertisements. 4403 The home agent SHOULD construct the aggregate list of home subnet 4404 prefixes as follows: 4406 - Copy prefix information defined in the home agent's AdvPrefixList 4407 on the home subnet's interfaces to the aggregate list. Also 4408 apply any changes made to the AdvPrefixList on the home agent to 4409 the aggregate list. 4411 - Check valid prefixes received in Router Advertisements 4412 from the home network for consistency with the home agent's 4413 AdvPrefixList, as specified in section 6.2.7 of RFC 2461 4414 (Neighbor Discovery [12]). Do not update the aggregate list with 4415 any information from received prefixes that fail this check. 4417 - Check Router Advertisements which contain an `H' bit (from other 4418 home agents) for valid prefixes that are not yet in the aggregate 4419 list, and if they are usable for autoconfiguration (`A' bit set, 4420 and prefix length is valid for address autoconfiguration on the 4421 home subnet) add them and preserve the `L' flag value. Clear the 4422 `R' flag and zero the interface-id portion of the prefix field 4423 to prevent mobile nodes from treating another router's interface 4424 address as belonging to the home agent. Treat the lifetimes 4425 of these prefixes as decrementing in real time, as defined in 4426 section 6.2.7 of RFC 2461 [12]. 4428 - Do not perform consistency checks on valid prefixes received in 4429 Router Advertisements on the home network that do not exist in 4430 the home agent's AdvPrefixList. Instead, if the prefixes already 4431 exist in the aggregate list, update the prefix lifetime fields in 4432 the aggregate list according to the rules specified for hosts in 4433 section 6.3.4 of RFC 2461 (Neighbor Discovery [12]) and section 4434 5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [13]). 4436 - If the L flag is set on valid prefixes received in a Router 4437 Advertisement, and that prefix already exists in the aggregate 4438 list, set the flag in the aggregate list. Ignore the flag if it 4439 is clear. 4441 - Delete prefixes from the aggregate list when their valid 4442 lifetimes expire. 4444 The home agent uses the information in the aggregate list to 4445 construct Mobile Prefix Advertisements. It may be possible to 4446 construct an aggregate list by combining information contained in the 4447 home agent's AdvPrefixList and its Home Agents List used for Dynamic 4448 Home Agent Address Discovery (Section 11.3.2). 4450 10.9.2. Scheduling Prefix Deliveries to the Mobile Node 4452 A home agent serving a mobile node will schedule the delivery of new 4453 prefix information to that mobile node when any of the following 4454 conditions occur: 4456 MUST: 4458 - The valid or preferred lifetime or the state of the flags changes 4459 for the prefix of the mobile node's registered home address. 4461 - The mobile node requests the information with a Mobile Prefix 4462 Solicitation (see section 11.3.3). 4464 MAY: 4466 - A new prefix is added to the aggregate list. 4468 - The valid or preferred lifetime or the state of the flags changes 4469 for a prefix which is not used in any binding cache entry for 4470 this mobile node. 4472 The home agent uses the following algorithm to determine when to send 4473 prefix information to the mobile node. 4475 - If the mobile node has not received the prefix information within 4476 the last HomeRtrAdvInterval seconds, then transmit the prefix 4477 information. This MAY be done according to a periodically 4478 scheduled transmission. 4480 - If a mobile node sends a solicitation, answer right away. 4482 - If a prefix in the aggregate list that matches the mobile node's 4483 home registration is added, or if its information changes in 4484 any way that does not cause the mobile node's address to go 4485 deprecated, ensure that a transmission is scheduled (as described 4486 below), and calculate RAND_ADV_DELAY in order to randomize the 4487 time at which the transmission is scheduled. 4489 - If a home registration expires, cancel any scheduled 4490 advertisements to the mobile node. 4492 Suppose that the home agent already has scheduled the transmission 4493 of a Router Advertisement to the mobile node. Then add the data 4494 from the existing scheduled transmission to the newly scheduled 4495 transmission, deleting the previously scheduled transmission event. 4496 In this case, the home agent does not perform the following algorithm 4497 to schedule an advertisement to the mobile node. 4499 Otherwise, the home agent uses the following algorithm to compute 4500 a fresh value for RAND_ADV_DELAY, the offset from the current time 4501 for the scheduled transmission. The computation is expected to 4502 alleviate bursts of advertisements when prefix information changes. 4503 In addition, a home agent MAY further reduce the rate of packet 4504 transmission by further delaying individual advertisements, if needed 4505 to avoid overwhelming local network resources. 4507 Calculate the maximum delay for the scheduled Advertisment as 4508 follows. 4509 MAX_SCHEDULE_DELAY == min (MAX_PFX_ADV_DELAY, Preferred Lifetime) 4511 Then compute RAND_ADV_DELAY == 4512 MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) 4514 The home agent SHOULD periodically continue to retransmit an 4515 unsolicited Advertisement to the mobile node, either until it is 4516 acknowledged by the receipt from the mobile node of a Binding Update 4517 with a home address matching the new home prefix in the packet, 4518 or until the home agent receives a Mobile Prefix Solicitation 4519 from the mobile node. The home agent MUST wait PREFIX_ADV_TIMEOUT 4520 before the first retransmission, and double the retransmission wait 4521 time for every succeeding retransmission, up until a maximum of 4522 PREFIX_ADV_RETRIES attempts. If the mobile node's bindings expire 4523 before the matching Binding Update has been received, then the home 4524 agent MUST NOT attempt any more retransmissions, even if not all 4525 PREFIX_ADV_RETRIES have been retransmitted. After another Binding 4526 Update is received from the mobile node, and if the mobile node has 4527 not returned to the home network in the meantime, the home agent 4528 SHOULD begin the process again of transmitting the unsolicited 4529 Advertisement. 4531 If while the home agent is still retransmitting a Mobile Prefix 4532 Advertisement to the mobile node, another condition as described 4533 above occurs on the home link causing another Prefix Advertisement to 4534 be sent to the mobile node, the home agent SHOULD combine any Prefix 4535 Information options in the unacknowledged Mobile Prefix Advertisement 4536 into the new Advertisement, discard the old Advertisement, and then 4537 begin retransmitting the new one. according to the above algorithm. 4539 10.9.3. Sending Advertisements to the Mobile Node 4541 When sending a Mobile Prefix Advertisement to the mobile node, the 4542 home agent MUST construct the packet as follows: 4544 - The Source Address in the packet's IPv6 header MUST be set to 4545 the home agent's IP address to which the mobile node addressed 4546 its current home registration, or its default global home agent 4547 address if no binding exists. 4549 - If a security association exists with the mobile node's address, 4550 the packet MUST be protected by IPsec [4, 5, 6] to guard against 4551 malicious Mobile Prefix Advertisements. The IPsec protection 4552 MUST provide sender authentication and data integrity protection 4553 covering the Mobile Prefix Advertisement, and MAY provide replay 4554 protection. 4556 - If the advertisement was solicited, it MUST be authenticated and 4557 destined to the source address of the solicitation. If it was 4558 triggered by prefix changes or renumbering, the advertisement's 4559 destination will be the mobile node's home address in the binding 4560 which triggered the rule. 4562 - The packet MUST be sent as any other unicast IPv6 packet. If a 4563 care-of address is used, the packet will be delivered directly. 4564 If a binding exists, the home agent will send the packet with 4565 a routing header containing the care-of address, as any other 4566 packet sent to the mobile node originated by the home agent 4567 (rather than using IPv6 encapsulation, as would be used by the 4568 home agent for intercepted packets). 4570 10.9.4. Lifetimes for Changed Prefixes 4572 As described in Section 10.2, the lifetime returned by the home agent 4573 in a Binding Acknowledgement MUST be no greater than the remaining 4574 valid lifetime for the subnet prefix in the mobile node's home 4575 address. This limit on the binding lifetime serves to prohibit use 4576 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 and Home Agents 4583 List. 4585 The rules for maintaining a Home Agents List are same for home agents 4586 and correspondent nodes, and have been described in Section 10.1. 4588 The Binding Update List records information for each Binding Update 4589 sent by this mobile node, for which the Lifetime sent in that Binding 4590 Update has not yet expired. The Binding Update List includes all 4591 bindings sent by the mobile node: those to correspondent nodes, 4592 those to the mobile node's home agent, and those to a home agent 4593 on the link on which the mobile node's previous care-of address is 4594 located. It also contains Binding Updates which are waiting for 4595 the completion of the return routability procedure before they can 4596 be sent. However, for multiple Binding Updates sent to the same 4597 destination address, the Binding Update List contains only the most 4598 recent Binding Update (i.e., with the greatest Sequence Number value) 4599 sent to that destination. The Binding Update List MAY be implemented 4600 in any manner consistent with the external behavior described in this 4601 document. 4603 Each Binding Update List entry conceptually contains the following 4604 fields: 4606 - The IP address of the node to which a Binding Update was sent. 4607 If the Binding Update was successfully received by that node 4608 (e.g., not lost by the network), a Binding Cache entry may have 4609 been created or updated based on this Binding Update. The 4610 Binding Cache entry may still exist, if that node has not deleted 4611 the entry before its expiration (e.g., to reclaim space in its 4612 Binding Cache for other entries). 4614 - The home address for which that Binding Update was sent. This 4615 will be one of the following: 4617 * one the mobile node's home addresses for typical Binding 4618 Updates (Sections 11.6.1 and 11.6.2), or 4620 * the mobile node's previous care-of address for Binding 4621 Updates sent to establish forwarding from the mobile node's 4622 previous location (Section 11.6.6). 4624 - The care-of address sent in that Binding Update. This value 4625 is necessary for the mobile node to determine if it has sent a 4626 Binding Update giving its new care-of address to this destination 4627 after changing its care-of address. 4629 - The initial value of the Lifetime field sent in that Binding 4630 Update. 4632 - The remaining lifetime of that binding. This lifetime is 4633 initialized from the Lifetime value sent in the Binding Update 4634 and is decremented until it reaches zero, at which time this 4635 entry MUST be deleted from the Binding Update List. 4637 - The maximum value of the Sequence Number field sent in previous 4638 Binding Updates to this destination. The Sequence Number field 4639 is 16 bits long, and all comparisons between Sequence Number 4640 values MUST be performed modulo 2**15 in the manner explained 4641 already in Section 9.4.1. 4643 - The time at which a Binding Update was last sent to this 4644 destination, as needed to implement the rate limiting restriction 4645 for sending Binding Updates. 4647 - The state of any retransmissions needed for this Binding Update, 4648 if the Acknowledge (A) bit was set in this Binding Update. This 4649 state includes the time remaining until the next retransmission 4650 attempt for the Binding Update, and the current state of the 4651 exponential back-off mechanism for retransmissions. 4653 - A flag that, when set, indicates that future Binding Updates 4654 should not be sent to this destination. The mobile node sets 4655 this flag in the Binding Update List entry when it receives an 4656 ICMP Parameter Problem, Code 1, error message in response to 4657 a return routability message or Binding Update sent to that 4658 destination, as described in Section 11.7. 4660 The Binding Update list also conceptually contains data related to 4661 running the return routability procedure. This data is relevant only 4662 for Binding Updates sent to correspondent nodes. 4664 - The time at which a Home Test Init or Care-of Test Init message 4665 was last sent to this destination, as needed to implement the 4666 rate limiting restriction for the return routability procedure. 4668 - The state of any retransmissions needed for this return 4669 routability procedure. This state includes the time remaining 4670 until the next retransmission attempt and the current state of 4671 the exponential back-off mechanism for retransmissions. 4673 - Mobile cookie values used the Home Test Init and Care-of Test 4674 Init messages. 4676 - Home and care-of cookies received from the correspondent node. 4678 - Home and care-of nonce indices received from the correspondent 4679 node. 4681 - The time at which each of the cookies was received from this 4682 correspondent node, as needed to implement cookie reuse while 4683 moving. 4685 11.2. Packet Processing 4687 11.2.1. Sending Packets While Away from Home 4689 While a mobile node is away from home, it continues to use its home 4690 address, as well as also using one or more care-of addresses. When 4691 sending a packet while away from home, a mobile node MAY choose among 4692 these in selecting the address that it will use as the source of the 4693 packet, as follows: 4695 - Protocols layered over IP will generally treat the mobile node's 4696 home address as its IP address for most packets. For packets 4697 sent that are part of transport-level connections established 4698 while the mobile node was at home, the mobile node MUST use 4699 its home address. Likewise, for packets sent that are part of 4700 transport-level connections that the mobile node may still be 4701 using after moving to a new location, the mobile node SHOULD 4702 use its home address in this way. When sending such packets, 4703 the delivery method depends on whether a binding exists with 4704 the correspondent node. If a binding exists, the mobile node 4705 SHOULD send the packets directly to the correspondent node. 4706 Otherwise, if a binding does not exist, the mobile node MUST use 4707 reverse tunneling. Detailed operation for both of these cases is 4708 described later in this section. 4710 - For short-term communication, particularly for communication that 4711 may easily be retried if it fails, the mobile node MAY choose 4712 to directly use one of its care-of addresses as the source of 4713 the packet, thus not requiring the use of a Home Address option 4714 in the packet. An example of this type of communication might 4715 be DNS queries sent by the mobile node [27, 28]. Using the 4716 mobile node's care-of address as the source for such queries will 4717 generally have a lower overhead than using the mobile node's 4718 home address, since no extra options need be used in either the 4719 query or its reply, and all packets can be routed normally, 4720 directly between their source and destination without relying 4721 on Mobile IP. If the mobile node has no particular knowledge 4722 that the communication being sent fits within this general type 4723 of communication, however, the mobile node SHOULD NOT use its 4724 care-of address as the source of the packet in this way. 4726 For packets sent by a mobile node while it is at home, no special 4727 Mobile IP processing is required for sending this packet. Likewise, 4728 if the mobile node uses any address other than any of its home 4729 addresses as the source of a packet sent while away from home no 4730 special Mobile IP processing is required for sending that packet. In 4731 each case, the packet is simply addressed and transmitted in the same 4732 way as any normal IPv6 packet. 4734 For packets sent by the mobile node sent while away from home using 4735 the mobile node's home address as the source, special Mobile IP 4736 processing of the packet is required. This can be done in two ways, 4737 as described above. These ways are: 4739 direct delivery 4741 This is manner of delivering packets does not require going 4742 through the home network, and typically will enable faster and 4743 more reliable transmission. A mobile node SHOULD arrange to 4744 supply the home address in a Home Address option, and allowing 4745 the IPv6 header's Source Address field to be set to one of the 4746 mobile node's care-of addresses; the correspondent node will 4747 then use the address supplied in the Home Address option to 4748 serve the function traditionally done by the Source IP address 4749 in the IPv6 header. the mobile node's home address is then 4750 supplied to higher protocol layers and applications. 4752 Specifically: 4754 - Construct the packet using the mobile node's home address 4755 as the packet's Source Address, in the same way as if the 4756 mobile node were at home. 4758 - Insert a Home Address option into the packet, with the Home 4759 Address field copied from the original value of the Source 4760 Address field in the packet. 4762 - Change the Source Address field in the packet's IPv6 header 4763 to one of the mobile node's care-of addresses. This will 4764 typically be the mobile node's current primary care-of 4765 address, but MUST be a care-of address with a subnet prefix 4766 that is on-link on the network interface on which the 4767 mobile node will transmit the packet. 4769 By using the care-of address as the Source Address in the IPv6 4770 header, with the mobile node's home address instead in the Home 4771 Address option, the packet will be able to safely pass through 4772 any router implementing ingress filtering [24]. 4774 reverse tunneling 4776 This is the mechanism which tunnels the packets via the home 4777 agent. It isn't as efficient as the above mechanism, but is 4778 needed if there is no binding yet with the correspondent node. 4779 Specifically: 4781 - The packet is sent to the home agent using IPv6 4782 encapsulation [15]. 4784 - The Source Address in the tunnel packet is the primary 4785 care-of address as registered with the home agent. 4787 - The Destination Address in the tunnel packet is the home 4788 agent's address. 4790 Reverse tunneled packets MAY be protected using a AH or ESP 4791 header, depending on the security policies used by the home 4792 agent. The support for encrypted reverse tunneling allows 4793 mobile nodes to defeat certain kinds of traffic analysis, and 4794 provides a mechanism by which routers on the home network can 4795 distinguish authorized traffic from other possibly malicious 4796 traffic. 4798 11.2.2. Interaction with Outbound IPsec Processing 4800 This section sketches the interaction between outbound Mobile 4801 IP processing and outbound IP Security (IPsec) processing for 4802 packets sent by a mobile node while away from home. Any specific 4803 implementation MAY use algorithms and data structures other than 4804 those suggested here, but its processing MUST be consistent with the 4805 effect of the operation described here and with the relevant IPsec 4806 specifications. In the steps described below, it is assumed that 4807 IPsec is being used in transport mode [4] and that the mobile node is 4808 using its home address as the source for the packet (from the point 4809 of view of higher protocol layers or applications, as described in 4810 Section 11.2.1): 4812 - The packet is created by higher layer protocols and applications 4813 (e.g., by TCP) as if the mobile node were at home and Mobile IP 4814 were not being used. 4816 - As part of outbound packet processing in IP, the packet is 4817 compared against the IPsec security policy database to determine 4818 what processing is required for the packet [4]. 4820 - If IPsec processing is required, the packet is either mapped to 4821 an existing Security Association (or SA bundle), or a new SA (or 4822 SA bundle) is created for the packet, according to the procedures 4823 defined for IPsec. 4825 - Since the mobile node is away from home, the mobile is either 4826 using reverse tunneling or route optimization to reach the 4827 correspondent node. 4829 If reverse tunneling is used, the packet is constructed in the 4830 normal manner and then tunneled through the home agent. 4832 If route optimization is in use, the mobile node inserts a Home 4833 Address destination option into the packet, replacing the Source 4834 Address in the packet's IP header with a care-of address suitable 4835 for the link on which the packet is being sent, as described in 4836 Section 11.2.1. The Destination Options header in which the 4837 Home Address destination option is inserted MUST appear in the 4838 packet after the Routing Header, if present, and before the IPsec 4839 (AH [5] or ESP [6]) header, so that the Home Address destination 4840 option is processed by the destination node before the IPsec 4841 header is processed. 4843 Finally, once the packet is fully assembled, the necessary IPsec 4844 authentication (and encryption, if required) processing is 4845 performed on the packet, initializing the Authentication Data in 4846 the IPsec header. The AH authentication data MUST be calculated 4847 as if the following were true: 4849 * the IPv6 source address in the IPv6 header contains the 4850 mobile node's home address, 4852 * the Home Address field of the Home Address destination option 4853 (section 6.3) contains the new care-of address. 4855 - This allows, but does not require, the receiver of the packet 4856 containing a Home Address destination option to exchange the two 4857 fields of the incoming packet, simplifying processing for all 4858 subsequent packet headers. However, such an exchange is not 4859 required, as long as the result of the authentication calculation 4860 remains the same. 4862 In addition, when using any automated key management protocol [4] 4863 (such as IKE [9]) to create a new SA (or SA bundle) while away from 4864 home, a mobile node MUST take special care in its processing of the 4865 key management protocol. Otherwise, other nodes with which the 4866 mobile node must communicate as part of the automated key management 4867 protocol processing may be unable to correctly deliver packets to 4868 the mobile node if they and/or the mobile node's home agent do 4869 not then have a current Binding Cache entry for the mobile node. 4870 For the default case of using IKE as the automated key management 4871 protocol [9, 4], such problems can be avoided by the following 4872 requirements on the use of IKE by a mobile node while away from home: 4874 - The mobile node MUST use its care-of address as the Source 4875 Address of all packets it sends as part of the key management 4876 protocol (without use of Mobile IP for these packets, as 4877 suggested in Section 11.2.1). 4879 - In addition, for all security associations bound to the mobile 4880 node's home address established by way of IKE, the mobile node 4881 MUST include an ISAKMP Identification Payload [8] in the IKE 4882 exchange, giving the mobile node's home address as the initiator 4883 of the Security Association [7]. 4885 11.2.3. Receiving Packets While Away from Home 4887 While away from home, a mobile node will receive packets addressed to 4888 its home address, by one of three methods: 4890 - Packets sent by a correspondent node that does not have a Binding 4891 Cache entry for the mobile node, will be tunneled to the mobile 4892 node via its home agent. 4894 - Packets sent by a correspondent node that has a Binding Cache 4895 entry for the mobile node that contains the mobile node's current 4896 care-of address, will be sent by the correspondent node using 4897 a type 2 Routing header. The packet will be addressed to the 4898 mobile node's care-of address, with the final hop in the Routing 4899 header directing the packet to the mobile node's home address; 4900 the processing of this last hop of the Routing header is entirely 4901 internal to the mobile node, since the care-of address and home 4902 address are both addresses within the mobile node. 4904 - Packets sent by a correspondent node that has a Binding 4905 Cache entry for the mobile node that contains an out-of-date 4906 care-of address for the mobile node, will also be sent by the 4907 correspondent node using a type 2 Routing header, as described 4908 above. If the mobile node sent a Binding Update to a home agent 4909 on the link on which its previous care-of address is located 4910 (Section 11.6.6), and if this home agent is still serving as a 4911 home agent for the mobile node's previous care-of address, then 4912 such a packet will be delivered to the mobile node via this home 4913 agent. 4915 For packets received by the first of these methods, the mobile node 4916 MUST check that the IPv6 source address of the tunnel packet is the 4917 IP address of its home agent. 4919 For packets received by either the first or last of these three 4920 methods, the mobile node SHOULD send a Binding Update to the original 4921 sender of the packet, as described in Section 11.6.2, subject to 4922 the rate limiting defined in Section 11.6.9. The mobile node MUST 4923 also process the received packet in the manner defined for IPv6 4924 encapsulation [15], which will result in the encapsulated (inner) 4925 packet being processed normally by upper-layer protocols within the 4926 mobile node, as if it had been addressed (only) to the mobile node's 4927 home address. 4929 For packets received by the second method above (using a Type 2 4930 Routing header), the following rules will result in the packet being 4931 processed normally by upper-layer protocols within the mobile node, 4932 as if it had been addressed to the mobile node's home address. 4934 A node receiving a packet addressed to itself (i.e., one of the 4935 node's addresses is in the IPv6 destination field) follows the next 4936 header chain of headers and processes them. When it encounters 4937 a Type 2 Routing header during this processing it performs the 4938 following checks. If any of these checks fail the node MUST silently 4939 discard the packet. 4941 - The length field in the RH is exactly 2. 4943 - The segments left field in the RH is either 0 or 1. (Values on 4944 the wire are always 1. But implementations may process RH in a 4945 manner the value may become 0 after RH has been processed, but 4946 before the rest of the packet is processed.) 4948 - The Home Address field in the RH is one of the node's home 4949 addresses, if the segments left field was 1. 4951 Once the above checks have been performed, the node swaps the IPv6 4952 destination field with the Home Address field in the RH, decrements 4953 segments left, and resubmits the packet to IP for processing the 4954 next header. Conceptually this follows the same model as in RFC 4955 2460. However, in the case of Type 2 Routing header this can be 4956 simplified since it is known that the packet will not be forwarded to 4957 a different node. 4959 The definition of AH requires the sender to calculate the AH 4960 integrity check value of a routing header in a way as it appears in 4961 the receiver after it has processed the header. Since IPsec headers 4962 follow the Routing Header, any IPsec processing will operate on 4963 the packet with the home address in the IP destination field and 4964 segments left being zero. Thus, the AH calculations at the sender 4965 and receiver will have an identical view of the packet. 4967 11.2.4. Routing Multicast Packets 4969 A mobile node that is connected to its home link functions in the 4970 same way as any other (stationary) node. Thus, when it is at home, 4971 a mobile node functions identically to other multicast senders and 4972 receivers. This section therefore describes the behavior of a mobile 4973 node that is not on its home link. 4975 In order to receive packets sent to some multicast group, a mobile 4976 node must join that multicast group. One method by which a mobile 4977 node MAY join the group is via a (local) multicast router on the 4978 foreign link being visited. The mobile node SHOULD use one of its 4979 care-of addresses that shares a subnet prefix with the multicast 4980 router, as the source IPv6 address of its multicast group membership 4981 control messages. If the multicast applications depend on the 4982 address of the joining node, the mobile node MAY treat the router as 4983 a correspondent node and establish a binding with it. The mobile 4984 node can then use the Home Address destination option in the sent 4985 control messages. 4987 Alternatively, a mobile node MAY join multicast groups via a 4988 bi-directional tunnel to its home agent. The mobile node tunnels its 4989 multicast group membership control packets to its home agent, and the 4990 home agent forwards multicast packets down the tunnel to the mobile 4991 node. 4993 A mobile node that wishes to send packets to a multicast group 4994 also has two options: (1) send directly on the foreign link being 4995 visited; or (2) send via a tunnel to its home agent. Because 4996 multicast routing in general depends upon the Source Address used in 4997 the IPv6 header of the multicast packet, a mobile node that tunnels a 4998 multicast packet to its home agent MUST use its home address as the 4999 IPv6 Source Address of the inner multicast packet. 5001 11.3. Home Agent and Prefix Management 5003 11.3.1. Receiving Local Router Advertisement Messages 5005 Each mobile node maintains a Home Agents List recording information 5006 about all home agents from which it receives a Router Advertisement, 5007 for which the home agent lifetime indicated in that Router 5008 Advertisement has not yet expired. This list is used by the mobile 5009 node to enable it to send a Binding Update to the global unicast 5010 address of a home agent on its previous link when it moves to a new 5011 link, as described in Section 11.6.6. On receipt of a valid Router 5012 Advertisement, as defined in the processing algorithm specified for 5013 Neighbor Discovery [12], the mobile node performs the following 5014 steps, in addition to any steps already required of it by Neighbor 5015 Discovery. 5017 - If the Home Agent (H) bit in the Router Advertisement is not set, 5018 and the sending node currently has an entry in the node's Home 5019 Agents List, delete the corresponding entry. Subsequently, skip 5020 all of the following steps. 5022 - Otherwise, extract the Source Address from the IP header of the 5023 Router Advertisement. This is the link-local IP address on this 5024 link of the home agent sending this Advertisement [12]. 5026 - Determine from the Router Advertisement the preference for this 5027 home agent. If the Router Advertisement contains a Home Agent 5028 Information Option, then the preference is taken from the Home 5029 Agent Preference field in the option; otherwise, the default 5030 preference of 0 MUST be used. 5032 - Determine from the Router Advertisement the lifetime for 5033 this home agent. If the Router Advertisement contains a Home 5034 Agent Information Option, then the lifetime is taken from 5035 the Home Agent Lifetime field in the option; otherwise, the 5036 lifetime specified by the Router Lifetime field in the Router 5037 Advertisement SHOULD be used. 5039 - If the link-local address of the home agent sending this 5040 Advertisement is already present in this mobile node's Home 5041 Agents List and the received home agent lifetime value is zero, 5042 immediately delete this entry in the Home Agents List. 5044 - Otherwise, if the link-local address of the home agent sending 5045 this Advertisement is already present in the receiving mobile 5046 node's Home Agents List, reset its lifetime and preference to the 5047 values determined above. 5049 - If the link-local address of the home agent sending this 5050 Advertisement, as determined above, is not already present in the 5051 Home Agents List maintained by the receiving mobile node, and 5052 the lifetime for the sending home agent, as determined above, 5053 is non-zero, create a new entry in the list, and initialize its 5054 lifetime and preference to the values determined above. 5056 - If the Home Agents List entry for the link-local address of 5057 the home agent sending this Advertisement was not deleted as 5058 described above, determine any global address(es) of the home 5059 agent based on each Prefix Information option received in 5060 this Advertisement in which the Router Address (R) bit is set 5061 (Section 7.2). For each such global address determined from this 5062 Advertisement, add this global address to the list of global 5063 addresses for this home agent in this Home Agents List entry. 5065 A mobile node SHOULD maintain an entry in its Home Agents List for 5066 each such valid home agent address until that entry's lifetime 5067 expires, after which time the entry MUST be deleted. 5069 11.3.2. Dynamic Home Agent Address Discovery 5071 Sometimes, when the mobile node needs to send a Binding Update to its 5072 home agent to register its new primary care-of address, as described 5073 in Section 11.6.1, the mobile node may not know the address of any 5074 router on its home link that can serve as a home agent for it. For 5075 example, some nodes on its home link may have been reconfigured while 5076 the mobile node has been away from home, such that the router that 5077 was operating as the mobile node's home agent has been replaced by a 5078 different router serving this role. 5080 In this case, the mobile node MAY attempt to discover the address of 5081 a suitable home agent on its home link. To do so, the mobile node 5082 sends an ICMP Home Agent Address Discovery Request message to the 5083 "Mobile IPv6 Home-Agents" anycast address [16] for its home subnet 5084 prefix. As described in Section 10.9, the home agent on its home 5085 link that receives this Request message will return an ICMP Home 5086 Agent Address Discovery Reply message, giving this home agent's own 5087 global unicast IP address along with a list of the global unicast IP 5088 address of each other home agent operating on the home link. 5090 The mobile node, upon receiving this Home Agent Address Discovery 5091 Reply message, MAY then send its home registration Binding Update to 5092 the home agent address given as the IP Source Address of the packet 5093 carrying the Reply message or to any of the unicast IP addresses 5094 listed in the Home Agent Addresses field in the Reply. For example, 5095 if necessary, the mobile node MAY attempt its home registration 5096 with each of these home agents, in turn, by sending each a Binding 5097 Update and waiting for the matching Binding Acknowledgement, until 5098 its registration is accepted by one of these home agents. In trying 5099 each of the returned home agent addresses, the mobile node SHOULD try 5100 each in the order listed in the Home Agent Addresses field in the 5101 received Home Agent Address Discovery Reply message. If the home 5102 agent identified by the Source Address field in the IP header of the 5103 packet carrying the Home Agent Address Discovery Reply message is 5104 not listed in the Home Agent Addresses field in the Reply, it SHOULD 5105 be tried before the first address given in the list; otherwise, it 5106 SHOULD be tried in its listed order. 5108 If the mobile node has a current registration with some home agent 5109 on its home link (the Lifetime for that registration has not yet 5110 expired), then the mobile node MUST attempt any new registration 5111 first with that home agent. If that registration attempt fails 5112 (e.g., times out or is rejected), the mobile node SHOULD then 5113 reattempt this registration with another home agent on its home link. 5114 If the mobile node knows of no other suitable home agent, then it MAY 5115 attempt the dynamic home agent address discovery mechanism described 5116 above. 5118 If, after a mobile node transmits a Home Agent Address Discovery 5119 Request message to the Home Agents Anycast address, it does not 5120 receive a corresponding Home Agent Address Discovery Reply message 5121 within INITIAL_DHAAD_TIMEOUT seconds, the mobile node MAY retransmit 5122 the same Request message to the same anycast address. This 5123 retransmission MAY be repeated up to a maximum of DHAAD_RETRIES 5124 attempts. Each retransmission MUST be delayed by twice the time 5125 interval of the previous retransmission. 5127 11.3.3. Sending Mobile Prefix Solicitations 5129 When a mobile node has a home address that is about to become 5130 invalid, it sends a Mobile Prefix Solicitation to its home agent 5131 in an attempt to acquire fresh routing prefix information. The 5132 new information also enables the mobile node to participate in 5133 renumbering operations affecting the home network, as described in 5134 section 10.9.1. 5136 The mobile node SHOULD send a Solicitation to the home agent when 5137 its home address will become invalid within MaxRtrAdvInterval 5138 seconds, where this value is acquired in a previous Mobile Prefix 5139 Advertisement from the home agent. If no such value is known, the 5140 value MAX_PFX_ADV_DELAY seconds is used instead (see section 12). 5142 This solicitation follows the same retransmission rules specified for 5143 Router Solicitations [12], except that the initial retransmission 5144 interval is specified to be INITIAL_SOLICIT_TIMER (see section 12). 5146 As described in Section 11.6.2, Binding Updates sent by the mobile 5147 node to other nodes MUST use a lifetime no greater than the remaining 5148 lifetime of its home registration of its primary care-of address. 5149 The mobile node SHOULD further limit the lifetimes that it sends on 5150 any Binding Updates to be within the remaining preferred lifetime 5151 (see Section 10.9.2) for the prefix in its home address. 5153 When the lifetime for a changed prefix decreases, and the change 5154 would cause cached bindings at correspondent nodes in the Binding 5155 Update List to be stored past the newly shortened lifetime, the 5156 mobile node MUST issue a Binding Update to all such correspondent 5157 nodes. 5159 These limits on the binding lifetime serve to prohibit use of a 5160 mobile node's home address after it becomes invalid. 5162 11.3.4. Receiving Mobile Prefix Advertisements 5164 Section 10.9.1 describes the operation of a home agent to support 5165 boot time configuration and renumbering a mobile node's home subnet 5166 while the mobile node is away from home. The home agent sends Mobile 5167 Prefix Advertisement messages to the mobile node while away from 5168 home, giving "important" Prefix Information options that describe 5169 changes in the prefixes in use on the mobile node's home link. 5171 When a mobile node receives a Mobile Prefix Advertisement, it MUST 5172 validate it according to the following test: 5174 - The Source Address of the IP packet carrying the Mobile Prefix 5175 Advertisement is the same as the home agent address to which the 5176 mobile node last sent an accepted "home registration" Binding 5177 Update to register its primary care-of address. Otherwise, if 5178 no such registrations have been made, it SHOULD be the mobile 5179 node's stored home agent address, if one exists. Otherwise, if 5180 the mobile node has not yet discovered its home agent's address, 5181 it MUST NOT accept Mobile Prefix Advertisements. 5183 - The packet MUST be protected by IPsec [4, 5, 6] to guard against 5184 malicious prefix advertisements, if a security association 5185 exists (i.e. unless the mobile node does not yet have a home 5186 address configured). The IPsec protection MUST provide sender 5187 authentication, data integrity protection, and replay protection, 5188 covering the advertisement. 5190 Any received Mobile Prefix Advertisement not meeting this test MUST 5191 be silently discarded. For advertisements that do not contain 5192 a solicitation cookie, the mobile node MAY send a solitication 5193 containing such a cookie before accepting the advertisement for 5194 further processing. 5196 For an accepted Mobile Prefix Advertisement, the mobile node MUST 5197 process the Prefix Information Options as if they arrived in a 5198 Router Advertisement on the mobile node's home link [12]. Such 5199 processing may result in the mobile node configuring a new home 5200 address, although due to separation between preferred lifetime and 5201 valid lifetime, such changes should not affect most communication 5202 by the mobile node, in the same way as for nodes that are at home. 5203 In this case,, the mobile node MUST return a Binding Update, which 5204 will be viewed by the home agent as an acknowledgement of the 5205 corresponding Mobile Prefix Advertisement, which it can cease 5206 transmitting. In addition, if the method used for this new home 5207 address configuration would require the mobile node to perform 5208 Duplicate Address Detection [13] for the new address if the mobile 5209 node were located at home, then the mobile node MUST set the 5210 Duplicate Address Detection (D) bit in this Binding Update to its 5211 home agent, to request the home agent to perform this Duplicate 5212 Address Detection on behalf of the mobile node. 5214 11.4. Movement 5216 11.4.1. Movement Detection 5218 The primary movement detection mechanism for Mobile IPv6 defined 5219 in this section uses the facilities of IPv6 Neighbor Discovery, 5220 including Router Discovery and Neighbor Unreachability Detection. 5221 The mobile node SHOULD supplement this mechanism with other 5222 information whenever it is available to the mobile node (e.g., 5223 from lower protocol layers). The description here is based on the 5224 conceptual model of the organization and data structures defined by 5225 Neighbor Discovery [12]. 5227 Mobile nodes SHOULD use Router Discovery to discover new routers and 5228 on-link subnet prefixes; a mobile node MAY send Router Solicitation 5229 messages, or MAY wait for unsolicited (periodic) multicast Router 5230 Advertisement messages, as specified for Router Discovery [12]. 5231 Based on received Router Advertisement messages, a mobile node 5232 maintains an entry in its Default Router List for each router, and 5233 an entry in its Prefix List for each subnet prefix that it currently 5234 considers to be on-link. Each entry in these lists has an associated 5235 invalidation timer value. While away from home, a mobile node 5236 typically selects one default router and one subnet prefix to use 5237 as the subnet prefix in its primary care-of address. A mobile node 5238 MAY also have associated additional care-of addresses, using other 5239 subnet prefixes from its Prefix List. The method by which a mobile 5240 node selects and forms a care-of address from the available subnet 5241 prefixes is described in Section 11.4.2. The mobile node registers 5242 its primary care-of address with its home agent, as described in 5243 Section 11.6.1. 5245 While a mobile node is away from home, it is important for the mobile 5246 node to quickly detect when its default router becomes unreachable. 5247 When this happens, the mobile node SHOULD switch to a new default 5248 router and potentially to a new primary care-of address. If, on the 5249 other hand, the mobile node becomes unreachable from its default 5250 router, it should attempt to become reachable through some other 5251 router. To detect when its default router becomes unreachable, a 5252 mobile node SHOULD use Neighbor Unreachability Detection. 5254 For a mobile node to detect when it has become unreachable from its 5255 default router, the mobile node cannot efficiently rely on Neighbor 5256 Unreachability Detection alone, since the network overhead would 5257 be prohibitively high in many cases. Instead, when a mobile node 5258 receives any IPv6 packets from its current default router at all, 5259 irrespective of the source IPv6 address, it SHOULD use that as an 5260 indication that it is still reachable from the router. 5262 Since the router SHOULD be sending periodic unsolicited multicast 5263 Router Advertisement messages, the mobile node will have frequent 5264 opportunity to check if it is still reachable from its default 5265 router, even in the absence of other packets to it from the router. 5266 If Router Advertisements that the mobile node receives include 5267 an Advertisement Interval option, the mobile node MAY use its 5268 Advertisement Interval field as an indication of the frequency with 5269 which it SHOULD expect to continue to receive future Advertisements 5270 from that router. This field specifies the minimum rate (the maximum 5271 amount of time between successive Advertisements) that the mobile 5272 node SHOULD expect. If this amount of time elapses without the 5273 mobile node receiving any Advertisement from this router, the mobile 5274 node can be sure that at least one Advertisement sent by the router 5275 has been lost. It is thus possible for the mobile node to implement 5276 its own policy for determining the number of Advertisements from 5277 its current default router it is willing to tolerate losing before 5278 deciding to switch to a different router from which it may currently 5279 be correctly receiving Advertisements. 5281 On some types of network interfaces, the mobile node MAY also 5282 supplement this monitoring of Router Advertisements, by setting its 5283 network interface into "promiscuous" receive mode, so that it is able 5284 to receive all packets on the link, including those not addressed to 5285 it at the link layer (i.e., disabling link-level address filtering). 5286 The mobile node will then be able to detect any packets sent by the 5287 router, in order to detect reachability from the router. This use of 5288 promiscuous mode may be useful on very low bandwidth (e.g., wireless) 5289 links, but its use MUST be configurable on the mobile node since it 5290 is likely to consume additional energy resources. 5292 If the above means do not provide indication that the mobile node 5293 is still reachable from its current default router (for instance, 5294 the mobile node receives no packets from the router for a period 5295 of time), then the mobile node SHOULD attempt to actively probe 5296 the router with Neighbor Solicitation messages, even if it is not 5297 otherwise actively sending packets to the router. If it receives a 5298 solicited Neighbor Advertisement message in response from the router, 5299 then the mobile node can deduce that it is still reachable. It is 5300 expected that the mobile node will in most cases be able to determine 5301 its reachability from the router by listening for packets from the 5302 router as described above, and thus, such extra Neighbor Solicitation 5303 probes should rarely be necessary. 5305 With some types of networks, indications about link-layer mobility 5306 might be obtained from lower-layer protocol or device driver software 5307 within the mobile node. However, all link-layer mobility indications 5308 from lower layers do not necessarily indicate a movement of the 5309 mobile node to a new link, such that the mobile node would need to 5310 switch to a new default router and primary care-of address. For 5311 example, movement of a mobile node from one cell to another in many 5312 wireless LANs can be made transparent to the IP level through use of 5313 a link-layer "roaming" protocol, as long as the different wireless 5314 LAN cells all operate as part of the same IP link with the same 5315 subnet prefix. Upon lower-layer indication of link-layer mobility, 5316 the mobile node MAY send Router Solicitation messages to determine if 5317 additional on-link subnet prefixes are available on its new link. 5319 Such lower-layer information might also be useful to a mobile node in 5320 deciding to switch its primary care-of address to one of the other 5321 care-of addresses it has formed from the on-link subnet prefixes 5322 currently available through different routers from which the mobile 5323 node is reachable. For example, a mobile node MAY use signal 5324 strength or signal quality information (with suitable hysteresis) for 5325 its link with the available routers to decide when to switch to a new 5326 primary care-of address using that router rather than its current 5327 default router (and current primary care-of address). Even though 5328 the mobile node's current default router may still be reachable in 5329 terms of Neighbor Unreachability Detection, the mobile node MAY use 5330 such lower-layer information to determine that switching to a new 5331 default router would provide a better connection. 5333 11.4.2. Forming New Care-of Addresses 5335 After detecting that it has moved from one link to another (i.e., its 5336 current default router has become unreachable and it has discovered 5337 a new default router), a mobile node SHOULD form a new primary 5338 care-of address using one of the on-link subnet prefixes advertised 5339 by the new router. A mobile node MAY form a new primary care-of 5340 address at any time, except that it MUST NOT do so too frequently. 5341 Specifically, a mobile node MUST NOT send a Binding Update about a 5342 new care-of address to its home agent (which is required to register 5343 the new address as its primary care-of address) more often than once 5344 per MAX_UPDATE_RATE seconds. 5346 In addition, after discovering a new on-link subnet prefix, a mobile 5347 node MAY form a new (non-primary) care-of address using that subnet 5348 prefix, even when it has not switched to a new default router. A 5349 mobile node can have only one primary care-of address at a time 5350 (which is registered with its home agent), but it MAY have an 5351 additional care-of address for any or all of the prefixes on its 5352 current link. Furthermore, since a wireless network interface may 5353 actually allow a mobile node to be reachable on more than one link at 5354 a time (i.e., within wireless transmitter range of routers on more 5355 than one separate link), a mobile node MAY have care-of addresses 5356 on more than one link at a time. The use of more than one care-of 5357 address at a time is described in Section 11.4.3. 5359 As described in Section 4, in order to form a new care-of address, 5360 a mobile node MAY use either stateless [13] or stateful (e.g., 5361 DHCPv6 [25]) Address Autoconfiguration. If a mobile node needs to 5362 send packets as part of the method of address autoconfiguration, 5363 it MUST use an IPv6 link-local address rather than its own IPv6 5364 home address as the Source Address in the IPv6 header of each such 5365 autoconfiguration packet. 5367 In some cases, a mobile node may already know a (constant) IPv6 5368 address that has been assigned to it for its use only while 5369 visiting a specific foreign link. For example, a mobile node may be 5370 statically configured with an IPv6 address assigned by the system 5371 administrator of some foreign link, for its use while visiting that 5372 link. If so, rather than using Address Autoconfiguration to form a 5373 new care-of address using this subnet prefix, the mobile node MAY use 5374 its own pre-assigned address as its care-of address on this link. 5376 After forming a new care-of address, a mobile node MAY perform 5377 Duplicate Address Detection [13] on that new address to confirm its 5378 uniqueness. However, doing so represents a trade-off between safety 5379 (ensuring that the new address is not used if it is a duplicate 5380 address) and overhead (performing Duplicate Address Detection 5381 requires the sending of one or more additional packets over what 5382 may be, for example, a slow wireless link through which the mobile 5383 node is connected). Performing Duplicate Address Detection also in 5384 general would cause a delay before the mobile node could use the 5385 new care-of address, possibly causing the mobile node to be unable 5386 to continue communication with correspondent nodes for some period 5387 of time. For these reasons, a mobile node, after forming a new 5388 care-of address, MAY begin using the new care-of address without 5389 performing Duplicate Address Detection. Furthermore, the mobile node 5390 MAY continue using the address without performing Duplicate Address 5391 Detection, although it SHOULD in most cases (e.g., unless network 5392 bandwidth or battery consumption for communication is of primary 5393 concern) begin Duplicate Address Detection asynchronously when it 5394 begins use of the address, allowing the Duplicate Address Detection 5395 procedure to complete in parallel with normal communication using the 5396 address. 5398 In addition, normal processing for Duplicate Address Detection 5399 specifies that, in certain cases, the node SHOULD delay sending the 5400 initial Neighbor Solicitation message of Duplicate Address Detection 5401 by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13]; 5402 however, in this case, the mobile node SHOULD NOT perform such a 5403 delay in its use of Duplicate Address Detection, unless the mobile 5404 node is initializing after rebooting. 5406 11.4.3. Using Multiple Care-of Addresses 5408 As described in Section 11.4.2, a mobile node MAY use more than one 5409 care-of address at a time. Particularly in the case of many wireless 5410 networks, a mobile node effectively might be reachable through 5411 multiple links at the same time (e.g., with overlapping wireless 5412 cells), on which different on-link subnet prefixes may exist. A 5413 mobile node SHOULD select a primary care-of address from among those 5414 care-of addresses it has formed using any of these subnet prefixes, 5415 based on the movement detection mechanism in use, as described in 5416 Section 11.4.1. When the mobile node selects a new primary care-of 5417 address, it MUST register it with its home agent by sending it a 5418 Binding Update with the Home Registration (H) and Acknowledge (A) 5419 bits set, as described in Section 11.6.1. 5421 To assist with smooth handovers, a mobile node SHOULD retain 5422 its previous primary care-of address as a (non-primary) care-of 5423 address, and SHOULD still accept packets at this address, even after 5424 registering its new primary care-of address with its home agent. 5425 This is reasonable, since the mobile node could only receive packets 5426 at its previous primary care-of address if it were indeed still 5427 connected to that link. If the previous primary care-of address was 5428 allocated using stateful Address Autoconfiguration [25], the mobile 5429 node may not wish to release the address immediately upon switching 5430 to a new primary care-of address. 5432 11.5. Return Routability Procedure 5434 This section defines the rules that the mobile node must follow 5435 when performing the return routability procedure. Appendix A 5436 specifies also a (non-normative) state-machine that describes the 5437 same procedure. Section 11.6.2 describes the rules when the return 5438 routability procedure needs to be initiated. 5440 11.5.1. Sending Home and Care-of Test Init Messages 5442 A mobile node that initiates a return routability procedure MUST 5443 send (in parallel) a Home Test Init message and a Care-of Test Init 5444 messages. A Home Test Init message MUST be created as described 5445 in Section 6.1.3. A Care-of Test Init message MUST be created as 5446 described in Section 6.1.4. 5448 When sending a Home Test Init or Care-of Test Init message the mobile 5449 node MUST record in its Binding Update List the following fields from 5450 the messages: 5452 - The IP address of the node to which the message was sent. 5454 - The home address for which the binding is desired. This value 5455 will appear in the Source Address field of the Home Test Init 5456 message. 5458 - The time at which each of these messages was sent. 5460 - The mobile cookie used in the messages. 5462 11.5.2. Receiving Return Routability Messages 5464 Upon receiving a packet carrying a Home Test message, a mobile node 5465 MUST validate the packet according to the following tests: 5467 - The Header Len field in the Mobility Header is greater than or 5468 equal to the length specified in Section 6.1.5. 5470 - The Source Address of the packet belongs to a correspondent 5471 node for which the mobile node has a Binding Update List entry 5472 with a state indicating that return routability procedure is in 5473 progress. 5475 - The Binding Update List indicates that no home cookie has been 5476 received yet. 5478 - The Destination Address of the packet has the home address of the 5479 mobile node, and the packet has been received in a tunnel from 5480 the home agent. 5482 - The Mobile Cookie field in the message matches the value stored 5483 in the Binding Update List. 5485 Any Home Test message not satisfying all of these tests MUST be 5486 silently ignored. Otherwise, the mobile node MUST record the Home 5487 Nonce Index and Home Cookie in the Binding Update List. If the 5488 Binding Update List entry does not have a Care-of Cookie, the mobile 5489 node SHOULD continue waiting for additional messages. 5491 Upon receiving a packet carrying a Care-of Test message, a mobile 5492 node MUST validate the packet according to the following tests: 5494 - The Header Len field in the Mobility Header is greater than or 5495 equal to the length specified in Section 6.1.6. 5497 - The Source Address of the packet belongs to a correspondent 5498 node for which the mobile node has a Binding Update List entry 5499 with a state indicating that return routability procedure is in 5500 progress. 5502 - The Binding Update List indicates that no care-of cookie has been 5503 received yet. 5505 - The Destination Address of the packet is the current care-of 5506 address of the mobile node. 5508 - The Mobile Cookie field in the message matches the value stored 5509 in the Binding Update List. 5511 Any Care-of Test message not satisfying all of these tests MUST be 5512 silently ignored. Otherwise, the mobile node MUST record the Care-of 5513 Nonce Index and Care-of Cookie in the Binding Update List. If the 5514 Binding Update List entry does not have a Home Cookie, the mobile 5515 node SHOULD continue waiting for additional messages. 5517 If after receiving either the Home Test or the Care-of Test message 5518 and performing the above actions, the Binding Update List entry 5519 has both the Home and the Care-of Cookies, the return routability 5520 procedure is complete. The mobile node SHOULD then proceed with 5521 sending a Binding Update message as described in Section 11.6.2. 5523 Correspondent nodes from the time before this specification was 5524 published may not not support the Mobility Header protocol. These 5525 nodes will respond to Home Test Init and Care-of Test Init messages 5526 with an ICMP Parameter Problem code 1. The mobile node SHOULD 5527 take such messages as an indication that the correspondent node 5528 can not provide route optimization, and revert back to the use of 5529 bidirectional routing. 5531 11.5.3. Retransmitting in the Return Routability Procedure 5533 The mobile node is responsible for retransmissions in the return 5534 routability procedure. 5536 When the mobile node sends a Home Test Init or Care-of Test Init 5537 message, it has to determine a value for the initial retransmission 5538 timer. It should use the specified value of INITIAL_BINDACK_TIMEOUT 5539 for this initial retransmission timer. 5541 If, after sending either a Home Test Init or Care-of Test Init 5542 message and the mobile node fails to receive a valid, matching 5543 Home Test or Care-of Test message within the selected initial 5544 retransmission interval, the mobile node SHOULD retransmit 5545 the original message, until a valid answer is received. The 5546 retransmissions by the mobile node MUST use an exponential 5547 back-off process, in which the timeout period is doubled upon each 5548 retransmission until either the node receives a valid response or the 5549 timeout period reaches the value MAX_BINDACK_TIMEOUT. 5551 11.5.4. Rate Limiting for Return Routability Procedure 5553 A mobile node MUST NOT send Home Test Init or Care-of Test 5554 Init messages to any individual node more often than once per 5555 MAX_UPDATE_RATE seconds. After sending MAX_FAST_UPDATES consecutive 5556 messages to a particular node with the same care-of address, the 5557 mobile node SHOULD reduce its rate of sending these messages to that 5558 node, to the rate of SLOW_UPDATE_RATE per second. The mobile node 5559 MAY continue to send these messages at this slower rate indefinitely, 5560 in hopes that the node will eventually be able to complete the return 5561 routability procedure. 5563 11.6. Processing Bindings 5565 11.6.1. Sending Binding Updates to the Home Agent 5567 After deciding to change its primary care-of address as described in 5568 Sections 11.4.1 and 11.4.2, a mobile node MUST register this care-of 5569 address with its home agent in order to make this its primary care-of 5570 address. Also, if the mobile node wants the services of the home 5571 agent beyond the current registration period, the mobile node MUST 5572 send a new Binding Update to it well before the expiration of this 5573 period, even if it is not changing its primary care-of address. 5575 In both of these situations, the mobile node sends a packet to its 5576 home agent containing a Binding Update message, with the packet 5577 constructed as follows: 5579 - The Home Registration (H) bit MUST be set in the Binding Update. 5581 - The Acknowledge (A) bit MUST be set in the Binding Update. 5583 - The packet MUST contain a Home Address destination option, giving 5584 the mobile node's home address for the binding. 5586 - The care-of address for the binding MUST be used as the Source 5587 Address in the packet's IPv6 header, unless an Alternate Care-of 5588 Address mobility option is included in the Binding Update 5589 message. 5591 - The `S' bit is set to the zero to request the mobile node's home 5592 agent to serve as a home agent for all home addresses for the 5593 mobile node based on all on-link subnet prefixes on the home 5594 link; this is the default behavior. If the mobile node desires 5595 that only a single home address should be affected by this 5596 Binding Update, the `S' bit can be set to 1. 5598 - If the mobile node's link-local address has the same interface 5599 identifier (IID) as the home address for which it is supplying a 5600 new care-of address, then the mobile node SHOULD set the `L' bit. 5601 If the home address was generated using RFC 3041 [17], then the 5602 link local address is unlikely to have a compatible IID. In this 5603 case, the mobile node SHOULD NOT set the 'L' bit. 5605 - The value specified in the Lifetime field SHOULD be less than 5606 or equal to the remaining lifetime of the home address and the 5607 care-of address specified for the binding. 5609 The Acknowledge (A) bit in the Binding Update requests the home agent 5610 to return a Binding Acknowledgement in response to this Binding 5611 Update. As described in Section 6.1.8, the mobile node SHOULD 5612 retransmit this Binding Update to its home agent until it receives 5613 a matching Binding Acknowledgement. Once reaching a retransmission 5614 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart 5615 the process of delivering the Binding Update, but trying instead the 5616 next home agent from its Home Agents List (see Section 11.3.2). If 5617 there is only one home agent in the Home Agents List, the mobile node 5618 instead SHOULD continue to periodically retransmit the Binding Update 5619 at this rate until acknowledged (or until it begins attempting to 5620 register a different primary care-of address). See Section 11.6.8 5621 for information about retransmitting Binding Updates. 5623 Depending on the value of the Single Address Only (S) bit in the 5624 Binding Update, the home agent is requested to serve either a single 5625 home address or all home home addresses for the mobile node. Until 5626 the lifetime of this registration expires, the home agent considers 5627 itself the home agent for each such home address of the mobile node. 5628 As the set of on-link subnet prefixes on the home link changes over 5629 time, the home agent changes the set of home addresses for this 5630 mobile node for which it is serving as the home agent. 5632 Each Binding Update MUST be authenticated as coming from the right 5633 mobile node, as defined in Section 5.1. The mobile node MUST use its 5634 home address -- either in the Home Address destination option or in 5635 the Source Address field of the IPv6 header -- in Binding Updates 5636 sent to the home agent. This is necessary in order to allow the 5637 IPsec policies to be matched with the right home address. 5639 When sending a Binding Update to its home agent, the mobile node MUST 5640 also create or update the corresponding Binding Update List entry, as 5641 specified in Section 11.6.2. 5643 The last Sequence Number value sent to the home agent in a Binding 5644 Update is stored by the mobile node. If the sending mobile node has 5645 no knowledge of the right Sequence Number value, it may start at any 5646 value. If the home agent rejects the value, it sends back a Binding 5647 Acknowledgement with status code 141, and the last accepted sequence 5648 number in the Sequence Number field of the Binding Acknowledgement. 5649 The mobile node MUST store this information and use the next Sequence 5650 Number value for the next Binding Update it sends. 5652 If the mobile node has additional home addresses using a different 5653 interface identifier, then the mobile node SHOULD send an additional 5654 packet containing a Binding Update to its home agent to register the 5655 care-of address for each such other home address (or set of home 5656 addresses sharing an interface identifier). 5658 While the mobile node is away from home, it relies on the home agent 5659 to participate in Duplicate Address Detection (DAD) to defend its 5660 home address against stateless autoconfiguration performed by another 5661 node. Therefore, the mobile node SHOULD set the Duplicate Address 5662 Detection (D) bit based on any requirements for DAD that would apply 5663 to the mobile node if it were at home [12, 13]. If the mobile 5664 node's recent Binding Update was accepted by the home agent, and the 5665 lifetime for that Binding Update has not yet expired, the mobile node 5666 SHOULD NOT set the `D' bit in the new Binding Update; the home agent 5667 will already be defending the home address(es) of the mobile node and 5668 does not need to perform DAD again. 5670 The home agent will only perform DAD for the mobile node's home 5671 address when the mobile node has supplied a valid binding between 5672 its home address and a care-of address. If some time elapses during 5673 which the mobile node has no binding at the home agent, it might 5674 be possible for another node to autoconfigure the mobile node's 5675 home address. Therefore, the mobile node MUST treat creation of 5676 a new binding with the home agent using an existing home address 5677 the same as creation of a new home address. In the unlikely event 5678 that the mobile node's home address is autoconfigured as the IPv6 5679 address of another network node on the home network, the home agent 5680 will reply to the mobile node's subsequent Binding Update with a 5681 Binding Acknowledgement containing a Status of 138, Duplicate Address 5682 Detection failed. In this case, the mobile node MUST NOT attempt to 5683 re-use the same home address. It SHOULD continue to register care-of 5684 addresses for its other home addresses, if any. The mobile node MAY 5685 also attempt to acquire a new home address to replace the one for 5686 which Status 138 was received, for instance by using the techniques 5687 described in Appendix C.5. 5689 11.6.2. Correspondent Binding Procedure 5691 When the mobile node is assured that its home address is valid, it 5692 MAY at any time initiate a correspondent binding procedure with 5693 the purpose of allowing the correspondent node to cache the mobile 5694 node's current care-of address. The mobile node is responsible for 5695 the initiation and completion of this procedure, as well as any 5696 retransmissions that may be needed (subject to the rate limiting 5697 defined in Section 11.6.9). 5699 This section defines the rules that the mobile node must follow 5700 when performing the correspondent binding procedure. Appendix A 5701 specifies also a (non-normative) state-machine that describes the 5702 same procedure. 5704 The mobile node can be assured that its home address is still valid, 5705 for example, by the home agent's use the `D' bit of Binding Updates 5706 (see Section 10.2). In any Binding Update sent by a mobile node, 5707 the care-of address (either the Source Address in the packet's IPv6 5708 header or the Care-of Address in the Alternate Care-of Address 5709 mobility option of the Binding Update) MUST be set to one of the 5710 care-of addresses currently in use by the mobile node or to the 5711 mobile node's home address. A mobile node MAY set the care-of 5712 address differently for sending Binding Updates to different 5713 correspondent nodes. 5715 A mobile node MAY choose to keep its location private from 5716 certain correspondent nodes, and thus need not initiate the 5717 return routability procedure, or send new Binding Updates to those 5718 correspondents. A mobile node MAY also send a Binding Update to 5719 such a correspondent node to instruct it to delete any existing 5720 binding for the mobile node from its Binding Cache, as described in 5721 Section 6.1.7. However, all Binding Updates to the correspondent 5722 node require the successful completion of the return routability 5723 procedure first, as no other IPv6 nodes are authorized to send 5724 Binding Updates on behalf of a mobile node. 5726 If set to one of the mobile node's current care-of addresses (the 5727 care-of address given MAY differ from the mobile node's primary 5728 care-of address), the Binding Update requests the correspondent node 5729 to create or update an entry for the mobile node in the correspondent 5730 node's Binding Cache in order to record this care-of address for use 5731 in sending future packets to the mobile node. In this case, the 5732 value specified in the Lifetime field sent in the Binding Update 5733 SHOULD be less than or equal to the remaining lifetime of the home 5734 address and the care-of address specified for the binding. 5736 If, instead, the care-of address is set to the mobile node's home 5737 address, the Binding Update requests the correspondent node to delete 5738 any existing Binding Cache entry that it has for the mobile node. 5740 When a mobile node sends a Binding Update to its home agent 5741 to register a new primary care-of address (as described in 5742 Section 11.6.1), the mobile node SHOULD also start a return 5743 routability procedure to each other node for which an entry exists 5744 in the mobile node's Binding Update List, as detailed below. Upon 5745 successful return routability procedure and after receiving a 5746 successful Binding Acknowledgement from the Home Agent, a Binding 5747 Update message is sent to all other nodes. Thus, other relevant 5748 nodes are generally kept updated about the mobile node's binding and 5749 can send packets directly to the mobile node using the mobile node's 5750 current care-of address. 5752 The mobile node, however, need not initiate these actions immediately 5753 after configuring a new care-of address. For example, the mobile 5754 node MAY delay initiating the return routability procedure to any 5755 correspondent node for a short period of time, if it isn't certain 5756 that there's traffic to the correspondent node. This is particularly 5757 useful if the mobile node anticipates that it is not going to stay 5758 long in this location. 5760 In addition, when a mobile node receives a packet for which the 5761 mobile node can deduce that the original sender of the packet either 5762 has no Binding Cache entry for the mobile node, or a stale entry 5763 for the mobile node in its Binding Cache, the mobile node SHOULD 5764 initiate a return routability procedure with the sender, in order to 5765 finally update the sender's Binding Cache with the current care-of 5766 address (subject to the rate limiting defined in Section 11.6.9). 5767 In particular, the mobile node SHOULD initiate a return routability 5768 procedure in response to receiving a packet that meets all of the 5769 following tests: 5771 - The packet was tunneled using IPv6 encapsulation. 5773 - The Destination Address in the tunnel (outer) IPv6 header is 5774 equal to any of the mobile node's care-of addresses. 5776 - The Destination Address in the original (inner) IPv6 header 5777 is equal to one of the mobile node's home addresses; or this 5778 Destination Address is equal to one of the mobile node's previous 5779 care-of addresses for which the mobile node has an entry in its 5780 Binding Update List, representing an unexpired Binding Update 5781 sent to a home agent on the link on which its previous care-of 5782 address is located (Section 11.6.6). 5784 - The Source Address in the tunnel (outer) IPv6 header differs from 5785 the Source Address in the original (inner) IPv6 header. 5787 The destination address to which the procedure should be initiated to 5788 in response to receiving a packet meeting all of the above tests is 5789 the Source Address in the original (inner) IPv6 header of the packet. 5790 The home address for which this Binding Update is sent should be the 5791 Destination Address of the original (inner) packet. 5793 Binding Updates sent to correspondent nodes are not generally 5794 required to be acknowledged. However, if the mobile node wants 5795 to be sure that its new care-of address has been entered into a 5796 correspondent node's Binding Cache, the mobile node MAY request an 5797 acknowledgement by setting the Acknowledge (A) bit in the Binding 5798 Update. In this case, however, the mobile node SHOULD NOT continue 5799 to retransmit the Binding Update once the retransmission timeout 5800 period has reached MAX_BINDACK_TIMEOUT. 5802 The mobile node SHOULD create a Binding Update message as follows: 5804 - The Source Address of the IPv6 header MUST contain the current 5805 care-of address of the mobile node. 5807 - The Destination Address of the IPv6 header MUST contain the 5808 address of the correspondent node. 5810 - The Mobility Header is constructed according to rules in 5811 Section 6.1.7, including the authenticator field which is 5812 calculated based on the received Home and Care-of Cookies. 5814 - The Home Address destination option MUST be attached to the 5815 message, unless the Source Address is the home address of the 5816 mobile node. 5818 Each Binding Update MUST a Sequence Number greater than the Sequence 5819 Number value sent in the previous Binding Update (if any) to the same 5820 destination address modulo 2**16, as described in Section 9.4.1. 5821 There is no requirement, however, that the Sequence Number value 5822 strictly increase by 1 with each new Binding Update sent or received, 5823 as long as the value stays within the window. The last Sequence 5824 Number value sent to a destination in a Binding Update is stored 5825 by the mobile node in its Binding Update List entry for that 5826 destination. If the sending mobile node has no Binding Update List 5827 entry, the Sequence Number SHOULD start at a random value. The 5828 mobile node MUST NOT use the same Sequence Number in two different 5829 Binding Updates to the same correspondent node, even if the Binding 5830 Updates provide different care-of addresses. 5832 11.6.3. Receiving Binding Acknowledgements 5834 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 5835 node MUST validate the packet according to the following tests: 5837 - The packet meets the authentication requirements for Binding 5838 Acknowledgements, defined in Sections 6.1.8 and 5. That is, 5839 if the Binding Update was sent to the home agent, underlying 5840 IPsec protection is used. If the Binding Update was sent to the 5841 correspondent node, the authenticator field MUST be present and 5842 have a valid value. 5844 - The Header Len field in the Binding Acknowledgement message is 5845 greater than or equal to the length specified in Section 6.1.8. 5847 - The Sequence Number field matches the Sequence Number sent by the 5848 mobile node to this destination address in an outstanding Binding 5849 Update. 5851 Any Binding Acknowledgement not satisfying all of these tests MUST be 5852 silently ignored. 5854 When a mobile node receives a packet carrying a valid Binding 5855 Acknowledgement, the mobile node MUST examine the Status field as 5856 follows: 5858 - If the Status field indicates that the Binding Update was 5859 accepted (the Status field is less than 128), then the mobile 5860 node MUST update the corresponding entry in its Binding Update 5861 List to indicate that the Binding Update has been acknowledged; 5862 the mobile node MUST then stop retransmitting the Binding Update. 5863 In addition, if the value specified in the Lifetime field in the 5864 Binding Acknowledgement is less than the Lifetime value sent 5865 in the Binding Update being acknowledged, then the mobile node 5866 MUST subtract the difference between these two Lifetime values 5867 from the remaining lifetime for the binding as maintained in the 5868 corresponding Binding Update List entry (with a minimum value 5869 for the Binding Update List entry lifetime of 0). That is, if 5870 the Lifetime value sent in the Binding Update was L_update, the 5871 Lifetime value received in the Binding Acknowledgement was L_ack, 5872 and the current remaining lifetime of the Binding Update List 5873 entry is L_remain, then the new value for the remaining lifetime 5874 of the Binding Update List entry should be 5876 max((L_remain - (L_update - L_ack)), 0) 5878 where max(X, Y) is the maximum of X and Y. The effect of this 5879 step is to correctly manage the mobile node's view of the 5880 binding's remaining lifetime (as maintained in the corresponding 5881 Binding Update List entry) so that it correctly counts down from 5882 the Lifetime value given in the Binding Acknowledgement, but with 5883 the timer countdown beginning at the time that the Binding Update 5884 was sent. 5886 Mobile nodes SHOULD send a new Binding Update well before the 5887 expiration of this period in order to extend the lifetime and 5888 not cause a disruption in communications. This is particularly 5889 necessary in order to prevent packets from being dropped due 5890 to the use of the Home Address destination option without an 5891 existing Binding Cache Entry, and the possibility of clock drift. 5893 - If the Status field indicates that the Binding Update was 5894 rejected (the Status field is greater than or equal to 128), then 5895 the mobile node MUST delete the corresponding Binding Update List 5896 entry, and it MUST also stop retransmitting the Binding Update. 5897 Optionally, the mobile node MAY then take steps to correct the 5898 cause of the error and retransmit the Binding Update (with a new 5899 Sequence Number value), subject to the rate limiting restriction 5900 specified in Section 11.6.9. 5902 11.6.4. Receiving Binding Refresh Requests 5904 When a mobile node receives a packet containing a Binding Refresh 5905 Request message and there already exists a Binding Update List 5906 entry for the source of the Binding Refresh Request, it MAY start 5907 a return routability procedure (see Section 5) if it believes 5908 the amount of traffic with the correspondent justifies the use of 5909 route optimization. Note that the mobile node SHOULD NOT respond 5910 Binding Requests from previously unknown correspondent nodes due to 5911 Denial-of-Service concerns. 5913 If the return routability procedure completes successfully, a 5914 Binding Update message SHOULD be sent as described in Section 11.6.2. 5915 The Lifetime field in this Binding Update SHOULD be set to a new 5916 lifetime, extending any current lifetime remaining from a previous 5917 Binding Update sent to this node (as indicated in any existing 5918 Binding Update List entry for this node), and lifetime SHOULD 5919 again be less than or equal to the remaining lifetime of the home 5920 registration and the care-of address specified for the binding. When 5921 sending this Binding Update, the mobile node MUST update its Binding 5922 Update List in the same way as for any other Binding Update sent by 5923 the mobile node. 5925 Note, however, that the mobile node MAY choose to delete its binding 5926 from the sender of the Binding Refresh Request. In this case, the 5927 mobile node instead SHOULD return a Binding Update to the sender, 5928 in which the Lifetime field is set to zero and the care-of address 5929 (using a Alternate Care-Of Address option) is set to the mobile 5930 node's home address. 5932 If the Binding Refresh Request for which the Binding Update is being 5933 returned contains a Unique Identifier mobility option, the resulting 5934 Home Test Init, Care-of Test Init, and Update messages MUST also 5935 include a Unique Identifier mobility option. The unique identifier 5936 in the Option Data field of the Unique Identifier mobility option 5937 MUST be copied from the unique identifier carried in the Binding 5938 Refresh Request. 5940 11.6.5. Receiving Binding Error Messages 5942 When a mobile node receives a packet containing a Binding Error 5943 message, it should first check if the mobile node has a Binding 5944 Update List entry for the the source of the Binding Error message. 5945 If the mobile node does not have such entry, it MUST ignore the 5946 message. This is necessary to prevent a waste of resources on e.g. 5947 return routability procedure due to spoofed Binding Error messages. 5949 Otherwise, if the message Status field was 1 (Home Address 5950 destination option used without a binding), the mobile node should 5951 perform one of the following two actions: 5953 - If the mobile node does have a Binding Update List entry but 5954 has recent upper layer progress information that indicates 5955 communications with the correspondent node are progressing, it 5956 MAY ignore the message. This can be done in order to limit the 5957 damage that spoofed Binding Error messages can cause to ongoing 5958 communications. 5960 - If the mobile node does have a Binding Update List entry but 5961 no upper layer progress information, it MUST remove the entry 5962 and route further communications through the home agent. It 5963 MAY also optionally start a return routability procedure (see 5964 Section 5.2). 5966 If the message Status field was 2 (received message had an unknown 5967 value for the MH Type field), the mobile node should perform one of 5968 the following two actions: 5970 - If the mobile node is not expecting an acknowledgement or 5971 response from the correspondent node, the mobile node SHOULD 5972 ignore this message. 5974 - Otherwise, the mobile node SHOULD cease the use of any extensions 5975 to this specification. If no extensions had been used, the 5976 mobile node should cease the attempt to use route optimization. 5978 11.6.6. Forwarding from a Previous Care-of Address 5980 When a mobile node connects to a new link and forms a new care-of 5981 address, it MAY establish forwarding of packets from a previous 5982 care-of address to this new care-of address. To do so, the mobile 5983 node sends a Binding Update to any home agent on the link on which 5984 the previous care-of address is located, indicating this previous 5985 care-of address as the home address for the binding, and giving its 5986 new care-of address as the binding's care-of address. Such packet 5987 forwarding allows packets destined to the mobile node from nodes that 5988 have not yet learned the mobile node's new care-of address, to be 5989 forwarded to the mobile node rather than being lost once the mobile 5990 node is no longer reachable at this previous care-of address. 5992 This Binding Update is sent to a home agent, albeit a temporary 5993 one. Nevertheless, the authentication requirements for Binding 5994 Updates from a mobile node to its home agent apply, as specified in 5995 Section 11.6.1. 5997 In constructing this Binding Update, the mobile node utilizes the 5998 following specific steps: 6000 - The Home Address field in the Home Address destination option 6001 in the packet carrying the Binding Update MUST be set to the 6002 previous care-of address for which packet forwarding is being 6003 established. 6005 - The care-of address for the new binding MUST be set to the new 6006 care-of address to which packets destined to the previous care-of 6007 address are to be forwarded. Normally, this care-of address for 6008 the binding is specified by setting the Source Address of the 6009 packet carrying the Binding Update, to this address. However, 6010 the mobile node MAY instead include an Alternate Care-of Address 6011 mobility option in the Binding Update message, with its Alternate 6012 Care-of Address field set to the care-of address for the binding. 6014 - The Home Registration (H) bit MUST also be set in this Binding 6015 Update, to request this home agent to temporarily act as a home 6016 agent for this previous care-of address. 6018 - The Duplicate Address Detection (D) and Link-Local Address 6019 Compatibility (L) MUST also be set in this Binding Update. 6020 If previous care-of address did not have the same interface 6021 identifier as the mobile link-local address, the mobile node MUST 6022 NOT use forwarding from a previous care-of address. 6024 This home agent will thus tunnel packets for the mobile node (packets 6025 destined to its specified previous care-of address) to its new 6026 care-of address. All of the procedures defined for home agent 6027 operation MUST be followed by this home agent for this registration. 6028 Note that this home agent does not necessarily know (and need not 6029 know) the mobile node's (permanent) home address as part of this 6030 registration. 6032 The packet carrying the Binding Update MUST be addressed to 6033 this home agent's global unicast address. Normally, this global 6034 unicast address is learned by the mobile node based on the Router 6035 Advertisements received by the mobile node (Section 7.2) while 6036 attached to the link on which this previous care-of address and this 6037 home agent are located; the mobile node obtains this home agent 6038 address from its Home Agents List (Section 4.4). Alternatively, 6039 the mobile node MAY use dynamic home agent address discovery 6040 (Section 10.9) to discover the global unicast address of a home agent 6041 on this previous link, but it SHOULD use an address from its Home 6042 Agents List if available for the prefix it used to form this previous 6043 care-of address. 6045 As with any packet containing a Binding Update (see Section 6.1.7), 6046 the Binding Update packet to this home agent MUST meet the 6047 authentication requirements for Binding Updates, defined in 6048 Section 5.1 and 11.6.1. 6050 11.6.7. Returning Home 6052 A mobile node detects that it has returned to its home link through 6053 the movement detection algorithm in use (Section 11.4.1), when the 6054 mobile node detects that its home subnet prefix is again on-link. 6055 The mobile node SHOULD then send a Binding Update to its home agent, 6056 to instruct its home agent to no longer intercept or tunnel packets 6057 for it. In this home registration, the mobile node MUST set the 6058 Acknowledge (A) and Home Registration (H) bits, and set the care-of 6059 address for the binding to the mobile node's own home address. The 6060 mobile node MUST NOT include a Home Address option in this Binding 6061 Update. 6063 When sending this Binding Update to its home agent, the mobile 6064 node must be careful in how it uses Neighbor Solicitation [12] (if 6065 needed) to learn the home agent's link-layer address, since the home 6066 agent will be currently configured to defend the mobile node's home 6067 address for Duplicate Address Detection. In particular, a Neighbor 6068 Solicitation from the mobile node using its home address as the 6069 Source Address would be detected by the home agent as a duplicate 6070 address. In many cases, Neighbor Solicitation by the mobile node 6071 for the home agent's address will not be necessary, since the mobile 6072 node may have already learned the home agent's link-layer address, 6073 for example from a Source Link-Layer Address option in the Router 6074 Advertisement from which it learned that its home address was on-link 6075 and that the mobile node had thus returned home. 6077 If the mobile node does Neighbor Solicitation to learn the home 6078 agent's link-layer address, in this special case of the mobile node 6079 returning home, the mobile node MUST multicast the packet, and in 6080 addition set the Source Address of this Neighbor Solicitation to the 6081 unspecified address (0:0:0:0:0:0:0:0). The target of the Neighbor 6082 Solicitation MUST be set to the home agent's IPv6 address, which is 6083 known to the mobile node. The destination IP address MUST be set to 6084 the Solicited-Node multicast address [3]. The home agent will be 6085 unable to distinguish this solicitation from a similar packet that 6086 would only be used for DAD, and it will respond as if for DAD. The 6087 home agent will send a multicast Neighbor Advertisement back to the 6088 mobile node with the Solicited flag ('S') set to zero. The mobile 6089 node SHOULD accept this advertisement, and set the state of the 6090 Neighbor Cache entry for the home agent to REACHABLE. 6092 The mobile node then sends its Binding Update using the home agent's 6093 link-layer address, instructing its home agent to no longer serve 6094 as a home agent for it. By processing this Binding Update, the 6095 home agent will cease defending the mobile node's home address for 6096 Duplicate Address Detection and will no longer respond to Neighbor 6097 Solicitations for the mobile node's home address. The mobile node 6098 is then the only node on the link receiving packets at the mobile 6099 node's home address. In addition, when returning home prior to the 6100 expiration of a current binding for its home address, and configuring 6101 its home address on its network interface on its home link, the 6102 mobile node MUST NOT perform Duplicate Address Detection on its own 6103 home address, in order to avoid confusion or conflict with its home 6104 agent's use of the same address. If the mobile node returns home 6105 after the bindings for all of its care-of addresses have expired, 6106 then it SHOULD perform DAD. It SHOULD also perform DAD for addresses 6107 which may have been registered with 'D' and 'S' bits set to one. 6109 After the Mobile Node sends the Binding Update, the Home Agent MUST 6110 remove the Proxy Neighbor Cache entry for the Mobile Node and MAY 6111 learn its link-layer address based on the link-layer packet or cached 6112 information, or if that is not available, it SHOULD send a Neighbor 6113 Solicitation with the target address equal to the Binding Update's 6114 source IP address. The Mobile Node MUST then reply with a unicast 6115 Neighbor Advertisement to the Home Agent with its link-layer address. 6116 While the Mobile Node is waiting for a Binding Acknowledgement, it 6117 MUST NOT respond to any Neighbor Solicitations for its Home Address 6118 other than those originating from the IP address to which it sent the 6119 Binding Update. 6121 After receiving the Binding Acknowledgement for its Binding Update 6122 to its home agent, the mobile node MUST multicast onto the home 6123 link (to the all-nodes multicast address) a Neighbor Advertisement 6124 message [12], to advertise the mobile node's own link-layer address 6125 for its own home address. The Target Address in this Neighbor 6126 Advertisement message MUST be set to the mobile node's home address, 6127 and the Advertisement MUST include a Target Link-layer Address option 6128 specifying the mobile node's link-layer address. The mobile node 6129 MUST multicast such a Neighbor Advertisement message for each of its 6130 home addresses, as defined by the current on-link prefixes, including 6131 its link-local address and site-local address. The Solicited 6132 Flag (S) in these Advertisements MUST NOT be set, since they were 6133 not solicited by any Neighbor Solicitation message. The Override 6134 Flag (O) in these Advertisements MUST be set, indicating that the 6135 Advertisements SHOULD override any existing Neighbor Cache entries at 6136 any node receiving them. 6138 Since multicasting on the local link (such as Ethernet) is typically 6139 not guaranteed to be reliable, the mobile node MAY retransmit these 6140 Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to 6141 increase their reliability. It is still possible that some nodes on 6142 the home link will not receive any of these Neighbor Advertisements, 6143 but these nodes will eventually be able to recover through use of 6144 Neighbor Unreachability Detection [12]. 6146 11.6.8. Retransmitting Binding Updates 6148 The mobile node is responsible for retransmissions in the binding 6149 procedure. 6151 When the mobile node sends a Binding Update message, it has to 6152 determine a value for the initial retransmission timer. If the 6153 mobile node is changing or updating an existing binding at the home 6154 agent, it should use the specified value of INITIAL_BINDACK_TIMEOUT 6155 for this initial retransmission timer. If on the other hand the 6156 mobile node does not have an existing binding at the home agent, it 6157 SHOULD use a value for the initial retransmission timer that is at 6158 least 1.5 times longer than (RetransTimer * DupAddrDetectTransmits). 6159 This value is likely to be substantially longer than the otherwise 6160 specified value of INITIAL_BINDACK_TIMEOUT that would be used by the 6161 mobile node. This longer retransmission interval will allow the the 6162 home agent to complete the DAD procedure which is mandated in this 6163 case, as detailed in Section 11.6.1. 6165 If, after sending a Binding Update in which the care-of address has 6166 changed and the Acknowledge (A) bit is set, a mobile node fails 6167 to receive a valid, matching Binding Acknowledgement within the 6168 selected initial retransmission interval, the mobile node SHOULD 6169 retransmit the Binding Update, until a Binding Acknowledgement is 6170 received. Such a retransmitted Binding Update MUST use a Sequence 6171 Number value greater than that used for the previous transmission of 6172 this Binding Update. The retransmissions by the mobile node MUST 6173 use an exponential back-off process, in which the timeout period 6174 is doubled upon each retransmission until either the node receives 6175 a Binding Acknowledgement or the timeout period reaches the value 6176 MAX_BINDACK_TIMEOUT. 6178 11.6.9. Rate Limiting Binding Updates 6180 A mobile node MUST NOT send Binding Update messages for the 6181 same binding to any individual node more often than once per 6182 MAX_UPDATE_RATE seconds. After sending MAX_FAST_UPDATES consecutive 6183 messages to a particular node with the same care-of address, the 6184 mobile node SHOULD reduce its rate of sending these messages to that 6185 node, to the rate of SLOW_UPDATE_RATE per second. The mobile node 6186 MAY continue to send these messages at this slower rate indefinitely, 6187 in hopes that the node will eventually be able to process a Binding 6188 Update, and begin to route its packets directly to the mobile node at 6189 its new care-of address. 6191 11.7. Receiving ICMP Error Messages 6193 Any node receiving a Mobility header that does not recognize the 6194 protocol SHOULD return an ICMP Parameter Problem, Code 1, message 6195 to the sender of the packet. If a node performing the return 6196 routability procedure or sending a Binding Update receives such an 6197 ICMP error message in response, it SHOULD record in its Binding 6198 Update List that future Binding Updates SHOULD NOT be sent to this 6199 destination. 6201 Correspondent nodes who have participated in the return routability 6202 procedure MUST implement the ability to correctly process received 6203 packets containing a Home Address destination option. Therefore, 6204 correctly implemented correspondent nodes should always be able to 6205 recognize Home Address options. If a mobile node receives an ICMP 6206 Parameter Problem, Code 2, message from some node indicating that it 6207 does not support the Home Address option, the mobile node SHOULD log 6208 the error and then discard the ICMP message. 6210 12. Protocol Constants 6212 HomeRtrAdvInterval 3,600 seconds 6213 DHAAD_RETRIES 3 retransmissions 6214 INITIAL_BINDACK_TIMEOUT 1 second 6215 INITIAL_DHAAD_TIMEOUT 2 seconds 6216 INITIAL_SOLICIT_TIMER 2 seconds 6217 MAX_ADVERT_REXMIT 3 transmissions 6218 MAX_BINDACK_TIMEOUT 256 seconds 6219 MAX_COOKIE_LIFE 240 seconds 6220 MAX_FAST_UPDATES 5 transmissions 6221 MAX_PFX_ADV_DELAY 1,000 seconds 6222 MAX_RR_BINDING_LIFE 420 seconds 6223 MAX_UPDATE_RATE once per second 6224 PREFIX_ADV_RETRIES 3 retransmissions 6225 PREFIX_ADV_TIMEOUT 5 seconds 6226 SLOW_UPDATE_RATE once per 10 second interval 6228 13. IANA Considerations 6230 This document defines a new IPv6 protocol, the Mobility Header, 6231 described in Section 6.1. This protocol must be assigned a protocol 6232 number. The MH Type field in the Mobility Header is used to indicate 6233 a particular type of a message. The current message types are 6234 described in Sections 6.1.2 through 6.1.9, and include the following: 6236 0 Binding Refresh Request 6238 1 Home Test Init 6240 2 Care-of Test Init 6242 3 Home Test 6244 4 Care-of Test 6246 5 Binding Update 6248 6 Binding Acknowledgement 6250 7 Binding Error 6252 Future values of the MH Type can be allocated using standards 6253 action [10]. 6255 Furthermore, each Mobility Header message may contain mobility 6256 options as described in Section 6.2. The current mobility options 6257 are defined in Sections 6.2.4 through 6.2.5, and include the 6258 following: 6260 0 Pad1 6262 1 PadN 6264 2 Unique Identifier 6266 3 Alternate Care-of Address 6268 4 Nonce Indices 6270 5 Authorization Data 6272 Future values of the Option Type can be allocated using standards 6273 action [10]. 6275 This document also defines a new IPv6 destination option, the Home 6276 Address option, described in Section 6.3. This option must be 6277 assigned an Option Type value. 6279 This document also defines a new IPv6 Type 2 Routing Header, 6280 described in Section 6.4. The value 2 must be allocated by IANA when 6281 this specification becomes an RFC. 6283 In addition, this document defines four ICMP message types, two used 6284 as part of the dynamic home agent address discovery mechanism and 6285 two used in lieu of router solicitations and advertisements when the 6286 mobile node is away from the home link: 6288 - The Home Agent Address Discovery Request message, described in 6289 Section 6.5; 6291 - The Home Agent Address Discovery Reply message, described in 6292 Section 6.6; 6294 - The Mobile Prefix Solicitation message, described in Section 6.7; 6295 and 6297 - The Mobile Prefix Advertisement message, described in 6298 Section 6.8. 6300 This document also defines two new Neighbor Discovery [12] options, 6301 which must be assigned Option Type values within the option numbering 6302 space for Neighbor Discovery messages: 6304 - The Advertisement Interval option, described in Section 7.3; and 6306 - The Home Agent Information option, described in Section 7.4. 6308 14. Security Considerations 6310 14.1. Threats 6312 Any mobility solution must protect itself against misuses of 6313 the mobility features and mechanisms. In Mobile IPv6, most of 6314 the potential threats are concerned with false Bindings, usually 6315 resulting in Denial-of-Service attacks. Some of the threats also 6316 pose potential for Man-in-the-Middle, Hijacking, Confidentiality, 6317 and Impersonation attacks. The main threats this protocol protects 6318 against are the following: 6320 1. Threats involving Binding Updates sent to home agents and 6321 correspondent nodes. For instance, an attacker might claim that 6322 a certain mobile node is currently at a different location than 6323 it really is. If a home agent accepts such spoofed information 6324 sent to it, the mobile node might not get traffic destined to 6325 it. Similarly, a malicious (mobile) node might use the home 6326 address of a victim node in a forged Binding Update sent to a 6327 correspondent node. 6329 These pose threats against confidentiality, integrity, and 6330 availability. That is, an attacker might learn the contents 6331 of packets destined to another node by redirecting the traffic 6332 to itself. Furthermore, an attacker might use the redirected 6333 packets in an attempt to set itself as a Man-in-the-Middle 6334 between a mobile and a correspondent node. This would allow the 6335 attacker to impersonate the mobile node, leading to integrity and 6336 availability problems. 6338 A malicious (mobile) node might also send Binding Updates in 6339 which the care-of address is set to the address of a victim 6340 node. If such Binding Updates were accepted, the malicious 6341 node could lure the correspondent node into sending potentially 6342 large amounts of data to the victim; the correspondent node's 6343 replies to messages sent by the malicious mobile node will be 6344 sent to the victim host or network. This could be used to 6345 cause a Distributed Denial-of-Service attack. For example, 6346 the correspondent node might be a site that will send a 6347 high-bandwidth stream of video to anyone who asks for it. Note 6348 that the use of flow-control protocols such as TCP does not 6349 necessarily defend against this type of attack, because the 6350 attacker can fake the acknowledgements. Even keeping TCP initial 6351 sequence numbers secret doesn't help, because the attacker can 6352 receive the first few segments (including the ISN) at its own 6353 address, and only then redirect the stream to the victim's 6354 address. These types of attacks may also be directed towards 6355 networks instead of nodes. Further variations of this threat are 6356 described elsewhere [29, 30]. 6358 An attacker might also attempt to disrupt a mobile node's 6359 communications by replaying a Binding Update that the node had 6360 sent earlier. If the old Binding Update was accepted, packets 6361 destined for the mobile node would be sent to its old location 6362 and not its current location. 6364 In conclusion, there are Denial-of-Service, Man-in-the-Middle, 6365 Confidentiality, and Impersonation threats against the 6366 parties involved in sending legitimate Binding Updates, and 6367 Denial-of-Service threats against any other party. 6369 2. Threats associated with payload packets: Payload packets 6370 exchanged with mobile nodes are exposed to similar threats as 6371 regular IPv6 traffic is. However, Mobile IPv6 introduces the 6372 Home Address destination option, a new Routing Header type (Type 6373 2), and uses tunneling headers in the payload packets. The 6374 protocol must protect against potential new threats involving the 6375 use of these mechanisms. 6377 Third parties become exposed to a reflection threat via the 6378 Home Address destination option, unless appropriate security 6379 precautions are followed. The Home Address destination option 6380 could be used to direct response traffic toward a node whose IP 6381 address appears in the option. In this case, ingress filtering 6382 would not catch the forged "return address" [31] [32]. 6384 A similar threat exists with the tunnels between the mobile node 6385 and the home agent. An attacker might forge tunnel packets 6386 between the mobile node and the home agent, making it appear 6387 that the traffic is coming from the mobile node when it is not. 6388 Note that an attacker who is able to forge tunnel packets would 6389 typically be able forge also packets that appear to come directly 6390 from the mobile node. This is a not a new threat as such. 6391 However, it may make it easier for attackers to escape detection 6392 by avoiding ingress filtering and packet tracing mechanisms. 6393 Furthermore, spoofed tunnel packets might be used to gain access 6394 to the home network. 6396 Finally, a Routing Header could also be used in reflection 6397 attacks, and in attacks designed to bypass firewalls. 6398 The generality of the regular Routing Header would allow 6399 circumvention of IP-address based rules in firewalls. It would 6400 also allow reflection of traffic to other nodes. These threats 6401 exist with Routing Headers in general, even if the usage that 6402 Mobile IPv6 requires is safe. 6404 3. Threats against the Mobile IPv6 security mechanisms themselves: 6405 An attacker might, for instance, lure the participants into 6406 executing expensive cryptographic operations or allocating memory 6407 for the purpose of keeping state. The victim node would have no 6408 resources left to handle other tasks. 6410 As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to 6411 be deployed in most nodes of the IPv6 Internet. The above threats 6412 should therefore be considered in the light of being applicable to 6413 the whole Internet. 6415 14.2. Features 6417 This specification provides a number of security features designed to 6418 mitigate or alleviate the threats listed above. The main security 6419 features are the following: 6421 - Protection of Binding Updates sent to home agents. 6423 - Protection of Binding Updates sent to correspondent nodes. 6425 - Protection against reflection attacks that use the Home Address 6426 destination option. 6428 - Protection of tunnels between the mobile node and the home agent. 6430 - Closing Routing Header vulnerabilities. 6432 - Mitigating Denial-of-Service threats to the Mobile IPv6 security 6433 mechanisms themselves. 6435 Protecting those Binding Updates that are sent to home agents and 6436 those that are sent to arbitrary correspondent nodes requires very 6437 different security solutions due to the different situations. Mobile 6438 nodes and home agents are expected to be naturally subject to the 6439 network administration of the home domain. 6441 Thus, they can and are supposed to have a strong security association 6442 that can be used to reliably authenticate the exchanged messages. 6443 See Section 5.1 for the description of the protocol mechanisms, 6444 and Section 14.3 below for a discussion of the resulting level of 6445 security. 6447 It is expected that Mobile IPv6 route optimization will be 6448 used on a global basis between nodes belonging to different 6449 administrative domains. It would be a very demanding task to 6450 build an authentication infrastructure on this scale. Furthermore, 6451 a traditional authentication infrastructure cannot be easily 6452 used to authenticate IP addresses, because these change often. 6453 It is not sufficient to just authenticate the mobile nodes. 6454 Authorization to claim the right to use an address is needed as 6455 well. Thus, an "infrastructureless" approach is necessary. The 6456 chosen infrastructureless method is described in Section 5.2 and 6457 Section 14.4 discusses the resulting security level and the design 6458 rationale of this approach. 6460 Specific rules guide the use of the Home Address destination option, 6461 the Routing Header, and the tunneling headers in the payload packets. 6462 These rules are necessary to remove the vulnerabilities associated 6463 with their unrestricted use. The effect of the rules is discussed in 6464 Sections 14.5, 14.6, and 14.7. 6466 Denial-of-Service threats against Mobile IPv6 security mechanisms 6467 themselves concern mainly the Binding Update procedures with 6468 correspondent nodes. The protocol has been designed to limit the 6469 effects of such attacks, as will be described in Section 14.4.5. 6471 14.3. Binding Updates to Home Agent 6473 Signaling between the mobile node and the home agent requires message 6474 integrity, correct ordering and replay protection. This is necessary 6475 to assure the home agent that a Binding Update is from a legitimate 6476 mobile node. 6478 IPsec AH or ESP protects the integrity of the Binding Updates and 6479 Binding Acknowledgements, by securing Mobility Header messages 6480 between the mobile node and the home agent. However, IPsec can 6481 easily provide replay protection only if dynamic security association 6482 establishment is used. This may not always be possible, and manual 6483 keying would be preferred in some cases. IPsec also does not 6484 guarantee correct ordering of packets, only that they have not been 6485 replayed. Because of this, sequence numbers with the Mobile IPv6 6486 messages ensure correct ordering (see Section 5.1). However, if 6487 a home agent reboots and loses its state regarding the sequence 6488 numbers, replay attacks become possible. The use of a key management 6489 mechanism together with IPsec can be used to prevent such replay 6490 attacks. 6492 A sliding window scheme is used for the sequence numbers. The 6493 protection against replays and reordering attacks without a key 6494 management mechanism works when the attacker remembers up to a 6495 maximum of 2**15 Binding Updates. 6497 The above mechanisms do not show that the care-of address given 6498 in the Binding Update is correct. This opens the possibility for 6499 Denial-of-Service attacks against third parties. However, since the 6500 mobile node and home agent have a security association, the home 6501 agent can always identify an ill-behaving mobile node. This allows 6502 the home agent operator to discontinue the mobile node's service, and 6503 possibly take further actions based on the business relationship with 6504 the mobile node's owner. 6506 Note that where forwarding from a previous care-of address is used, 6507 a router in the visited network must act as a temporary home agent 6508 for the mobile node. Nevertheless, the same security requirements 6509 apply in this case. That is, a pre-arranged security association 6510 must exist even with the temporary home agent. This limits the use 6511 of the forwarding feature to those networks where such arrangements 6512 are practical. 6514 Note that the use of a single pair of manually keyed security 6515 associations conflicts with the generation of a new home 6516 addresses [17] for the mobile node, or with the adoption of a 6517 new home prefix. This is because IPsec SAs are bound to the used 6518 addresses. While certificate-based automatic keying alleviates 6519 this problem to an extent, it is still necessary to ensure that a 6520 given mobile node can not send Binding Updates for the address of 6521 another mobile node. In general, this leads to the inclusion of 6522 home addresses in certificates in the Subject AltName field. This 6523 again limits the introduction of new addresses without either manual 6524 or automatic procedures to establish new certificates. Therefore, 6525 this specification limits restricts the generation of new home 6526 addresses (for any reason) to those situations where there already 6527 exists a security association or certificate for the new address. 6528 (Section C.4 lists the improvement of security for new addresses as 6529 one of the future developments for Mobile IPv6.) 6531 14.4. Binding Updates to Correspondent Nodes 6533 14.4.1. Overview 6535 The motivation for designing the return routability procedure 6536 was to have sufficient support for Mobile IPv6, without creating 6537 significant new security problems. The goal for this procedure was 6538 not to protect against attacks that were already possible before the 6539 introduction of Mobile IPv6. 6541 The chosen infrastructureless method verifies that the mobile node 6542 is "live" (that is, it responds to probes) at its home and care-of 6543 addresses. Section 5.2 describes the return routability procedure in 6544 detail. The procedure uses the following principles: 6546 - A cookie exchange verifies that the mobile node is reachable at 6547 its addresses i.e. is at least able to transmit and receive 6548 traffic at both the home and care-of addresses. 6550 - The eventual Binding Update is cryptographically bound to the 6551 exchanged cookies. 6553 - Symmetric exchanges are employed to avoid the use of this 6554 protocol in reflection attacks. In a symmetric exchange, the 6555 responses are always sent to the same address as the request was 6556 sent from. 6558 - The correspondent node operates in a stateless manner until it 6559 receives a fully authorized Binding Update. 6561 - Some additional protection is provided by encrypting the tunnels 6562 between the mobile node and home agent with IPsec ESP. As the 6563 tunnel transports also the cookie exchanges, this limits the 6564 ability of attackers to see these cookies. For instance, this 6565 prevents attacks launched from the mobile node's current foreign 6566 link where no link-layer confidentiality is available. 6568 For further information about the design rationale of the return 6569 routability procedure, see [29, 30, 33, 32]. The used mechanisms 6570 have been adopted from these documents. 6572 14.4.2. Offered Protection 6574 This procedure protects Binding Updates against all attackers 6575 who are unable to monitor the path between the home agent and the 6576 correspondent node. The procedure does not defend against attackers 6577 who can monitor this path. Note that such attackers are in any case 6578 able to mount an active attack against the mobile node when it is 6579 at its home location. The possibility of such attacks is not an 6580 impediment to the deployment of Mobile IPv6, because these attacks 6581 are possible regardless of whether Mobile IPv6 is in use. 6583 This procedure also protects against Denial-of-Service attacks in 6584 which the attacker pretends to be a mobile, but uses the victim's 6585 address as the care of address. This would cause the correspondent 6586 node to send the victim some unexpected traffic. The procedure 6587 defends against these attacks by requiring the participation of the 6588 node at the care-of address. Normally, this will be the mobile node. 6590 The Binding Acknowledgement is not authenticated in other ways than 6591 including the right sequence number in the reply. 6593 14.4.3. Comparison to Regular IPv6 Communications 6595 This section discusses the protection offered by the return 6596 routability method by comparing it to the security of regular IPv6 6597 communications. We will divide vulnerabilities in three classes: 6598 (1) those related to attackers on the local network of the mobile 6599 node, home agent, or the correspondent node, (2) those related to 6600 attackers on the path between the MN/HA and the CN, and (3) off-path 6601 attackers, i.e. the rest of the Internet. 6603 We will now discuss the vulnerabilities of regular IPv6 6604 communications. The on-link vulnerabilities of IPv6 communications 6605 include Denial-of-Service, Masquerading, Man-in-the-Middle, 6606 Eavesdropping, and other attacks. These attacks can be launched 6607 through spoofing Router Discovery, Neighbor Discovery and other IPv6 6608 mechanisms. Some of these attacks can be prevented with the use of 6609 cryptographic protection in the packets. 6611 A similar situation exists with on-path attackers. That is, without 6612 cryptographic protection the traffic is completely vulnerable. 6614 Assuming that attackers have not penetrated the security of the 6615 Internet routing protocols, attacks are much harder to launch 6616 from off-path locations. Attacks that can be launched from these 6617 locations are mainly Denial-of-Service attacks, such as flooding 6618 and/or reflection attacks. It is not possible for an off-path 6619 attacker to become a MitM. (Since IPv6 communications are relatively 6620 well protected against off-path attackers, it is important that 6621 Mobile IPv6 prevents off-path attacks as well.) 6623 Next, we will consider the vulnerabilities that exist when IPv6 is 6624 used together with Mobile IPv6 and the return routability procedure. 6625 On the local link the vulnerabilities are same as those as in IPv6, 6626 but Masquerade and MitM attacks can now be launched also against 6627 future communications, and not just against current communications. 6628 If a binding update was sent while the attacker was present on the 6629 link, its effects stay during the lifetime of the binding. This 6630 happens even if the attacker moves away from the link. In regular 6631 IPv6, the attacker generally has to be stay on the link in order to 6632 continue the attack. Note that in order to launch these new attacks, 6633 the IP address of the victim must be known. This makes this attack 6634 feasible mainly in the context of well-known interface IDs, such as 6635 those already appearing in the traffic on the link or registered in 6636 the DNS. 6638 On-path attackers can exploit similar vulnerabilities as in regular 6639 IPv6. There are some minor differences, however. Masquerade, MitM, 6640 and DoS attacks can be launched with just the interception of a few 6641 packets, whereas in regular IPv6 it is necessary to intercept every 6642 packet. The effect of the attacks is the same regardless of the 6643 method, however. In any case, the most difficult task attacker faces 6644 in these attacks is getting to the right path. 6646 The vulnerabilities for off-path attackers are the same as in regular 6647 IPv6. Those nodes that are not on the path between the home agent 6648 and the correspondent node will not be able to receive the probe 6649 messages. 6651 In conclusion, we can state the following main results from this 6652 comparison: 6654 - Return routability procedure prevents any off-path attacks beyond 6655 those that are already possible in regular IPv6. This is the 6656 most important result, and prevents attackers from the Internet 6657 from exploiting any vulnerabilities. 6659 - Vulnerabilities to attackers on the home agent link, the 6660 correspondent node link, and the path between them are roughly 6661 the same as in regular IPv6. 6663 - However, one difference is that in basic IPv6 an on-path attacker 6664 must be constantly present on the link or the path, whereas with 6665 Mobile IPv6 an attacker can leave a binding behind after moving 6666 away. 6668 For this reason, this specification limits the creation of 6669 bindings to at most MAX_COOKIE_LIFE seconds after the last 6670 routability check has been performed, and limits the duration of 6671 a binding to at most MAX_RR_BINDING_LIFE seconds. With these 6672 limitation, attackers can not take practical advantages of this 6673 vulnerability. This limited vulnerability can also be compared 6674 to similar vulnerabilities in IPv6 Neighbor Discovery, with 6675 Neighbour Cache entries having a limited lifetime. 6677 - There are some other minor differences, such as an effect 6678 to the DoS vulnerabilities. These can be considered to be 6679 insignificant. 6681 - The path between the home agent and a correspondent node is 6682 typically easiest to attack on the links at either end, in 6683 particular if these links are publicly accessible wireless LANs. 6684 Attacks against the routers or switches on the path are typically 6685 harder to accomplish. The security on layer 2 of the links plays 6686 then a major role in the resulting overall network security. 6687 Similarly, security of IPv6 Neighbor and Router Discovery on 6688 these links has a large impact. If these were secured using 6689 some new technology in the future, this could make the return 6690 routability procedure the easiest route for attackers. For this 6691 reason, this specification should have a protection mechanism for 6692 selecting between return routability and potential other future 6693 mechanisms. 6695 For a more in-depth discussion of these issues, see [32]. 6697 14.4.4. Return Routability Replays 6699 The return routability procedure also protects the participants 6700 against replayed Binding Updates. The attacker is unable replay 6701 the same message due to the sequence number which is a part of the 6702 Binding Update. It is also unable to modify the Binding Update since 6703 the MAC would not verify after such modification. 6705 Care must be taken when removing bindings at the correspondent 6706 node, however. If a binding is removed while the nonce used in its 6707 creation is still valid, an attacker could replay the old Binding 6708 Update. Rules outlined in Section 5.2.8 ensure that this can not 6709 happen. 6711 14.4.5. Return Routability Denial-of-Service 6713 The return routability procedure has protection against resource 6714 exhaustion Denial-of-Service attacks. The correspondent nodes do not 6715 retain any state about individual mobile nodes until an authentic 6716 Binding Update arrives. This is achieved through the use of the 6717 nonces and node keys that are not specific to individual mobile 6718 nodes. The cookies are specific, but they can be reconstructed 6719 based on the home and care-of address information that arrives 6720 with the Binding Update. This means that the correspondent nodes 6721 are safe against memory exhaustion attacks except where on-path 6722 attackers are concerned. Due to the use of symmetric cryptography, 6723 the correspondent nodes are relatively safe against CPU resource 6724 exhaustion attacks as well. 6726 Nevertheless, as [29] describes, there are situations in which it is 6727 impossible for the mobile and correspondent nodes to determine if 6728 they actually need a binding or whether they just have been fooled 6729 into believing so by an attacker. Therefore, it is necessary to 6730 consider situations where such attacks are being made. 6732 Even if route optimization is a very important optimization, it is 6733 still only an optimization. A mobile node can communicate with a 6734 correspondent node even if the correspondent refuses to accept any 6735 Binding Updates. However, performance will suffer because packets 6736 from the correspondent node to the mobile node will be routed via the 6737 mobile's home agent rather than a more direct route. A correspondent 6738 node can protect itself against some of these resource exhaustion 6739 attacks as follows. If the correspondent node is flooded with a 6740 large number of Binding Updates that fail the cryptographic integrity 6741 checks, it can stop processing Binding Updates. If a correspondent 6742 node finds that it is spending more resources on checking bogus 6743 Binding Updates than it is likely to save by accepting genuine 6744 Binding Updates, then it may reject some or all Binding Updates 6745 without performing any cryptographic operations. 6747 Layers above IP can usually provide additional information to decide 6748 if there is a need to establish a binding with a specific peer. For 6749 example, TCP knows if the node has a queue of data that it is trying 6750 to send to a peer. An implementation of this specification is not 6751 required to make use of information from higher protocol layers, but 6752 some implementations are likely to be able to manage resources more 6753 effectively by making use of such information. 6755 We also require that all implementations MUST allow route 6756 optimization to be administratively enabled or disabled. The default 6757 SHOULD be enabled. 6759 14.5. Tunneling via the Home Agent 6761 Tunnels between the mobile node and the home agent can be 6762 protected by ensuring proper use of source addresses, and optional 6763 cryptographic protection. These procedures are discussed in 6764 Section 5.3. 6766 Binding Updates to the home agents are secure. When receiving 6767 tunneled traffic the home agent verifies the outer IP address 6768 corresponds to the current location of the mobile node. This 6769 prevents attacks where the attacker is controlled by ingress 6770 filtering. It also prevents attacks when the attacker does not know 6771 the current care-of address of the mobile node. Attackers who know 6772 the care-of address and are not controlled by ingress filtering could 6773 still send traffic through the home agent. This includes attackers 6774 on the same local link as the mobile node is currently on. But such 6775 attackers could also send spoofed packets without using a tunnel. 6777 Home agents and mobile nodes may use IPsec AH or ESP to protect 6778 payload packets tunneled between themselves. This is useful to 6779 protect communications against attackers on the path of the tunnel. 6781 When site local home address are used, reverse tunneling can be used 6782 to send site local traffic from another location. Administrators 6783 should be aware of this when allowing such home addresses. In 6784 particular, the outer IP address check described above is not 6785 sufficient against all attackers. The use of encrypted tunnels is 6786 particularly useful for this kind of home addresses. 6788 14.6. Home Address Destination Option 6790 When the mobile node sends packets directly to the correspondent 6791 node, the Source Address field of the packet's IPv6 header is the 6792 care-of address. Ingress filtering [24] works therefore in the usual 6793 manner even for mobile nodes, as the Source Address is topologically 6794 correct. The Home Address destination option is used to inform the 6795 correspondent node of the mobile node's home address. 6797 However, the care-of address in the Source Address field does 6798 not survive in replies sent by the correspondent node unless 6799 it has a binding for this mobile node. Also, not all attacker 6800 tracing mechanisms work when packets are being reflected through 6801 correspondent nodes using the Home Address option. For these 6802 reasons, this specification restricts the use of the Home Address 6803 option. It may only used when a binding has already been established 6804 with the participation of the node at the home address, as described 6805 in Sections 5.3 and 6.3. This prevents reflection attacks through 6806 the use of the Home Address option. It also ensures that the 6807 correspondent nodes reply to the same address as the mobile node 6808 sends traffic from. 6810 No special authentication of the Home Address option is required 6811 beyond the above, except that if the IPv6 header of a packet is 6812 covered by authentication, then that authentication MUST also cover 6813 the Home Address option; this coverage is achieved automatically by 6814 the definition of the Option Type code for the Home Address option 6815 (Section 6.3), since it indicates that the option is included in the 6816 authentication computation. Thus, even when authentication is used 6817 in the IPv6 header, the security of the Source Address field in the 6818 IPv6 header is not compromised by the presence of a Home Address 6819 option. Without authentication of the packet, then any field in 6820 the IPv6 header, including the Source Address field, and any other 6821 parts of the packet, including the Home Address option, can be forged 6822 or modified in transit. In this case, the contents of the Home 6823 Address option is no more suspect than any other part of the packet. 6824 Additionally, if a security association has been used to protect 6825 the packet, we allow the Home Address option to be used even if the 6826 correspondent node does not have a binding for this mobile node. 6828 14.7. Type 2 Routing Header 6830 The definition of the Type 2 Routing Header is described in 6831 Section 6.4. This definition and the associated processing rules 6832 have been chosen so that the header can not be used for what is 6833 traditionally viewed as source routing. In particular, the IPv6 the 6834 Home Address in the routing header will always have to be assigned to 6835 the home address of the receiving node. Otherwise the packet will be 6836 dropped. 6838 Generally, source routing has a number of security concerns. These 6839 include the automatic reversal of unauthenticated source routes 6840 (which is an issue for IPv4, but not for IPv6). Another concern is 6841 the ability to use source routing to "jump" between nodes inside, as 6842 well as outside a firewall. These security concerns are not issues 6843 in Mobile IPv6, due to the rules mentioned above. 6845 In essence the semantics of the type 2 routing header is the same as 6846 a special form of IP-in-IP tunneling where the inner and outer source 6847 addresses are the same. 6849 This implies that a device which implements filtering of packets 6850 should be able to distinguish between a Type 2 Routing header and 6851 other Routing headers, as required in section 8.3. This is necessary 6852 in order to allow Mobile IPv6 traffic while still having the option 6853 to filter out other uses of Routing headers. 6855 Acknowledgements 6857 We would like to thank the members of the Mobile IP and IPng Working 6858 Groups for their comments and suggestions on this work. We would 6859 particularly like to thank (in alphabetical order) Fred Baker 6860 (Cisco), Josh Broch (Carnegie Mellon University), Robert Chalmers 6861 (University of California, Santa Barbara), Noel Chiappa (MIT), 6862 Vijay Devarapalli (Nokia Research Center), Rich Draves (Microsoft 6863 Research), Francis Dupont (ENST Bretagne), Thomas Eklund (Xelerated), 6864 Jun-Ichiro Itojun Hagino (IIJ Research Laboratory), Krishna Kumar 6865 (IBM Research), T.J. Kniveton (Nokia Research), Jiwoong Lee (KTF), 6866 Aime Lerouzic (Bull S.A.), Vesa-Matti Mantyla (Ericsson), Thomas 6867 Narten (IBM), Simon Nybroe (Ericsson Telebit), David Oran (Cisco), 6868 Lars Henrik Petander (HUT), Basavaraj Patil (Nokia), Ken Powell 6869 (Compaq), Phil Roberts (Motorola), Patrice Romand (Bull S.A.), 6870 Jeff Schiller (MIT) Tom Soderlund (Nokia Research), Hesham Soliman 6871 (Ericsson), Jim Solomon (RedBack Networks), Tapio Suihko (Technical 6872 Research Center of Finland), Benny Van Houdt (University of Antwerp), 6873 Jon-Olov Vatn (KTH), Alper Yegin (Sun Microsystems), and Xinhua Zhao 6874 (Stanford University) for their detailed reviews of earlier versions 6875 of this document. Their suggestions have helped to improve both the 6876 design and presentation of the protocol. 6878 We would also like to thank the participants in the Mobile IPv6 6879 testing event held at Nancy, France, September 15-17, 1999, for 6880 their valuable feedback as a result of interoperability testing 6881 of four Mobile IPv6 implementations coming from four different 6882 organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC 6883 (FreeBSD), and INRIA (FreeBSD). Further, we would like to thank the 6884 feedback from the implementors who participated in the Mobile IPv6 6885 interoperability testing at Connectathons 2000, 2001, and 2002 6886 in San Jose, California. Similarly, we would like to thank the 6887 participants at the ETSI interoperability testing at ETSI, in Sophia 6888 Antipolis, France, during October 2-6, 2000, including teams from 6889 Compaq, Ericsson, INRIA, Nokia, and Technical University of Helsinki. 6891 We would also like to thank Tuomas Aura, Mike Roe, and Greg 6892 O'Shea (Microsoft), Pekka Nikander (Ericsson), Erik Nordmark (Sun 6893 Microsystems), and Michael Thomas (Cisco) for the work on the return 6894 routability protocols which eventually led to the procedures used in 6895 this protocol. The procedures described in [30] were adopted in the 6896 protocol. 6898 Lastly, we must express our appreciation for the significant 6899 contributions made by members of the Mobile IPv6 Security Design 6900 Team, including (in alphabetical order) Gabriel Montenegro, Erik 6901 Nordmark, (Sun Microsystems) and Pekka Nikander (Ericsson), who have 6902 contributed volumes of text to this specification. 6904 References 6906 [1] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 6907 Recommendations for Security. Request for Comments 6908 (Informational) 1750, Internet Engineering Task Force, December 6909 1994. 6911 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 6912 Levels. Request for Comments (Best Current Practice) 2119, 6913 Internet Engineering Task Force, March 1997. 6915 [3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 6916 Request for Comments (Proposed Standard) 2373, Internet 6917 Engineering Task Force, July 1998. 6919 [4] S. Kent and R. Atkinson. Security Architecture for the Internet 6920 Protocol. Request for Comments (Proposed Standard) 2401, 6921 Internet Engineering Task Force, November 1998. 6923 [5] S. Kent and R. Atkinson. IP Authentication Header. Request for 6924 Comments (Proposed Standard) 2402, Internet Engineering Task 6925 Force, November 1998. 6927 [6] S. Kent and R. Atkinson. IP Encapsulating Security Payload 6928 (ESP). Request for Comments (Proposed Standard) 2406, Internet 6929 Engineering Task Force, November 1998. 6931 [7] D. Piper. The Internet IP Security Domain of Interpretation for 6932 ISAKMP. Request for Comments (Proposed Standard) 2407, Internet 6933 Engineering Task Force, November 1998. 6935 [8] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet 6936 Security Association and Key Management Protocol (ISAKMP). 6937 Request for Comments (Proposed Standard) 2408, Internet 6938 Engineering Task Force, November 1998. 6940 [9] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). 6941 Request for Comments (Proposed Standard) 2409, Internet 6942 Engineering Task Force, November 1998. 6944 [10] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 6945 Considerations Section in RFCs. Request for Comments (Best 6946 Current Practice) 2434, Internet Engineering Task Force, October 6947 1998. 6949 [11] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) 6950 Specification. Request for Comments (Draft Standard) 2460, 6951 Internet Engineering Task Force, December 1998. 6953 [12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 6954 IP Version 6 (ipv6). Request for Comments (Draft Standard) 6955 2461, Internet Engineering Task Force, December 1998. 6957 [13] S. Thomson and T. Narten. IPv6 Stateless Address 6958 Autoconfiguration. Request for Comments (Draft Standard) 2462, 6959 Internet Engineering Task Force, December 1998. 6961 [14] A. Conta and S. Deering. Internet Control Message Protocol 6962 (ICMPv6) for the Internet protocol version 6 (ipv6) 6963 specification. Request for Comments (Draft Standard) 2463, 6964 Internet Engineering Task Force, December 1998. 6966 [15] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 6967 Specification. Request for Comments (Proposed Standard) 2473, 6968 Internet Engineering Task Force, December 1998. 6970 [16] D. Johnson and S. Deering. Reserved IPv6 Subnet Anycast 6971 Addresses. Request for Comments (Proposed Standard) 2526, 6972 Internet Engineering Task Force, March 1999. 6974 [17] T. Narten and R. Draves. Privacy Extensions for Stateless 6975 Address Autoconfiguration in IPv6, January 2001. 6977 [18] Editor J. Reynolds. Assigned Numbers: RFC 1700 is Replaced by 6978 an On-line Database. Request for Comments (Informational) 3232, 6979 Internet Engineering Task Force, January 2002. 6981 [19] NIST. Secure hash standard. FIPS PUB 180-1, April 1995. 6983 [20] C. Perkins. IP Mobility Support. Request for Comments 6984 (Proposed Standard) 2002, Internet Engineering Task Force, 6985 October 1996. 6987 [21] C. Perkins. IP Encapsulation within IP. Request for Comments 6988 (Proposed Standard) 2003, Internet Engineering Task Force, 6989 October 1996. 6991 [22] C. Perkins. Minimal Encapsulation within IP. Request for 6992 Comments (Proposed Standard) 2004, Internet Engineering Task 6993 Force, October 1996. 6995 [23] C. Perkins and D. Johnson. Route optimization in mobile IP 6996 (work in progress). Internet Draft, Internet Engineering Task 6997 Force, September 2001. 6999 [24] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating 7000 Denial of Service Attacks which employ IP source address 7001 spoofing. Request for Comments (Informational) 2267, Internet 7002 Engineering Task Force, January 1998. 7004 [25] J. Bound, C. Perkins, M. Carney, and R. Droms. Dynamic host 7005 configuration protocol for IPv6 (DHCPv6) (work in progress). 7006 Internet Draft, Internet Engineering Task Force, January 2001. 7008 [26] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 7009 for Message Authentication. Request for Comments 7010 (Informational) 2104, Internet Engineering Task Force, 7011 February 1997. 7013 [27] P. V. Mockapetris. Domain names - concepts and facilities. 7014 Request for Comments (Standard) 1034, Internet Engineering Task 7015 Force, November 1987. 7017 [28] P. V. Mockapetris. Domain names - implementation and 7018 specification. Request for Comments (Standard) 1035, Internet 7019 Engineering Task Force, November 1987. 7021 [29] Tuomas Aura and Jari Arkko. MIPv6 BU attacks and defenses. 7022 Internet Draft draft-aura-mipv6-bu-attacks-01.txt (Work In 7023 Progress), IETF, February 2002. 7025 [30] Michael Roe, Greg O'Shea, Tuomas Aura, and Jari Arkko. 7026 Authentication of Mobile IPv6 binding updates and 7027 acknowledgments. Internet Draft draft-roe-mobileip-updateauth-02.txt 7028 (Work In Progress), IETF, February 2002. 7030 [31] Pekka Savola. Security of IPv6 routing header and home address 7031 options. Internet Draft draft-savola-ipv6-rh-ha-security-01.txt 7032 (Work In Progress), IETF, November 2001. 7034 [32] Erik Nordmark, Gabriel Montenegro, Pekka Nikander, and Jari 7035 Arkko. Mobile ipv6 security design rationale. To appear, 2002. 7037 [33] Erik Nordmark. Securing MIPv6 BUs using return routability 7038 (BU3WAY). Internet Draft draft-nordmark-mobileip-bu3way-00.txt 7039 (Work In Progress), IETF, November 2001. 7041 References [1] through [19] are normative and others are informative. 7043 A. State Machine for the Correspondent Binding Procedure 7045 Home agents and correspondent nodes are stateless until a binding 7046 is actually established. The mobile node, however, is responsible 7047 for initiating the correspondent binding procedure, keeping track of 7048 its state, handle retransmissions and failures, and completing the 7049 procedure. 7051 Section 11.6.2 defines the normative rules that the mobile node must 7052 follow when performing the correspondent binding procedure. This 7053 appendix specifies two additional, non-normative, state-machines 7054 that illustrates the behaviour of the mobile node. The first 7055 state machine describes the full correspondent binding, and the 7056 second state machine describes the details relating to the return 7057 routability procedure. 7059 The state machines in this appendix do not attempt to define 7060 how recently received cookies can be used when moving fast or 7061 when performing deregistrations. They also do not attempt to 7062 define how to behave when the mobile node may be simultaneously 7063 attached to several locations. The state machines also assume that 7064 acknowledgements are always required. 7066 A.1. Main State Machine 7068 The mobile node will keep the following states in its Binding List: 7070 Idle 7072 This is an imaginary state that refers to the situation that 7073 the correspondent node in question does not appear in the 7074 Binding List. In this state, all RR and binding related 7075 messaging is silently ignored. 7077 RRInit 7079 This is a composite state. While in this state, the mobile 7080 node has initiated the return routability procedure but has not 7081 yet completed it, and has no existing binding. The internal 7082 details of this state are described in the second state 7083 machine, later in this appendix. 7085 RRRedo 7087 This is another composite state. While in this state, the 7088 mobile node has an existing binding but has initiated the 7089 return routability procedure in order to refresh it. The 7090 internal details of this state are the same as above. In other 7091 words, the same second state machine is again used. 7093 RRDel 7095 In this state, the mobile node intends to send a 7096 de-registration Binding Update later but is first 7097 waiting for a home cookie before this can be done. (Note that 7098 if the mobile node is at home, it can use a home cookie also as 7099 care-of cookie.) 7101 WaitA 7103 In this state, the mobile node has sent a Binding Update, and 7104 is only waiting for the Binding Acknowledgement message to 7105 arrive. There is no existing binding. 7107 WaitAR 7109 In this state, the mobile node has an existing binding, which 7110 is being refreshed with a Binding Update. The mobile node is 7111 only waiting for the Binding Acknowledgement message to arrive. 7113 WaitD 7115 In this state, the mobile node has sent a de-registration 7116 Binding Update, and is only waiting for the Binding 7117 Acknowledgement message to arrive. 7119 Bound 7121 In this state, the mobile node has established a binding with 7122 the correspondent node. In this state, the mobile node can 7123 send packets directly to the correspondent node. 7125 The following events are possible: 7127 Movement 7129 The mobile node moves off the home-link, or to a new location. 7130 (Note that in some cases the mobile node might not take 7131 movements immediately in account for the purposes of route 7132 optimization.) 7134 Returning home 7136 The mobile node moves back to its home link. (Note that 7137 in some cases the mobile node may wish to give up route 7138 optimization by telling the correspondent nodes that it has 7139 returned home, when it has not.) 7141 Valid BRR received 7143 A valid Binding Refresh Request message has been received. 7145 Valid BA received 7147 A valid Binding Acknowledgement message has been received. 7149 Valid BE received 7151 A valid Binding Error message has been received. 7153 Invalid MH Type received 7155 A Mobility Header message with an unrecognized MH Type field 7156 has been received. 7158 ICMP Problem 1 received 7160 An ICMP Parameter Problem Code 1 message has been 7161 received. This can happen if the peer does not support this 7162 specification. 7164 Retransmission timer 7166 A timer is set to expire when a retransmission of a packet 7167 needs to be made. 7169 Failure timer 7171 A timer is set to expire when all retransmissions have failed. 7173 The following additional conditions are also used: 7175 Forward progress 7177 There is reason to believe forward progress is being made. 7178 Upper layer protocols such as TCP may provide hints to the IP 7179 layer regarding recent successful communications. 7181 Specific Status 7183 Tests of the Status values received in a BE or BA message. 7185 The following actions are possible: 7187 Start RR 7189 This is an abstract action that initiates the second state 7190 machine. 7192 Stop RR 7194 This is an abstract action that stops the second state machine. 7196 Send BU 7198 Send a Binding Update. 7200 Send BE 7202 Send a Binding Error with status 2. 7204 Set sequence number 7206 Set the sequence number we use towards the correspondent node. 7208 Start retransmission timer 7210 Start the retransmission timer that controls the sending of 7211 additional messages after the first message. 7213 Start failure timer 7215 Start the failure timer that controls how long we keep on 7216 trying to retransmit. 7218 Stop retransmission timer 7220 Stop the retransmission timer. 7222 Stop timers 7224 Stop all timers. 7226 The state machine for performing the correspondent binding procedure 7227 is described below. We have omitted events that have no actions and 7228 do not change the current state. 7230 State Event Action New State 7231 -------------------------------------------------------------- 7233 Idle Movement Start RR RRInit 7235 State Event Action New State 7236 -------------------------------------------------------------- 7238 RRInit RR Done Send BU, WaitA 7239 Start retrans- 7240 mission timer 7242 RRInit Valid BE received and Stop RR Idle 7243 status = 2 7245 RRInit Movement Stop RR RRInit 7246 Start RR 7248 RRInit Returning home Stop RR Idle 7250 RRInit ICMP Problem 1 received Stop timers Idle 7252 State Event Action New State 7253 -------------------------------------------------------------- 7254 RRRedo RR Done Send BU, WaitAR 7255 Start retrans- 7256 mission timer 7258 RRRedo Valid BE received and Stop RR Idle 7259 status = 2 7261 RRRedo Movement Stop RR RRInit 7262 Start RR 7264 RRRedo Returning home Stop RR RRDel 7266 RRRedo ICMP Problem 1 received Stop timers Idle 7268 State Event Action New State 7269 -------------------------------------------------------------- 7271 WaitA Valid BA received and Stop timers Bound 7272 status < 128 7274 WaitA Valid BA received and Set sequence WaitA 7275 status = 141 number, 7276 Send BU, 7277 Restart 7278 retransmission 7279 timer, 7280 Start failure 7281 timer 7283 WaitA Valid BA received and Start RR RRInit 7284 status = 144 or 145 7286 WaitA Valid BA received and Stop timers Idle 7287 status anything else 7289 WaitA Retransmission timer Send BU, WaitA 7290 Start retrans- 7291 mission timer 7293 WaitA Valid BE received and Stop timers Idle 7294 status = 2 7296 WaitA Movement Start RR RRInit 7298 WaitA Returning home Start RR RRDel 7300 State Event Action New State 7301 -------------------------------------------------------------- 7303 WaitAR Valid BA received and Stop timers Bound 7304 status < 128 7306 WaitAR Valid BA received and Set sequence WaitAR 7307 status = 141 number, 7308 Send BU, 7309 Restart 7310 retransmission 7311 timer, 7312 Start failure 7313 timer 7315 WaitAR Valid BA received and Start RR RRInit 7316 status = 144 or 145 7318 WaitAR Valid BA received and Stop timers Idle 7319 status anything else 7321 WaitAR Retransmission timer Send BU, WaitAR 7322 Start retrans- 7323 mission timer 7325 WaitAR Valid BE received and Stop timers Idle 7326 status = 2 7328 WaitAR Movement Start RR RRInit 7330 WaitAR Returning home Start RR RRDel 7332 State Event Action New State 7333 -------------------------------------------------------------- 7335 WaitD Valid BA received and Stop timers Idle 7336 status < 128 7338 WaitD Valid BA received and Set sequence WaitD 7339 status = 141 number, 7340 Send BU, 7341 Stop timers, 7342 Start retrans- 7343 mission timer, 7344 Start failure 7345 timer 7347 WaitD Valid BA received and Start RR RRDel 7348 status = 144 or 145 7350 WaitD Valid BA received and Stop timers Idle 7351 status anything else 7353 WaitD Retransmission timer Send BU, WaitD 7354 Start retrans- 7355 mission timer 7357 WaitD Valid BE received Stop timers Idle 7359 WaitD Movement Start RR RRInit 7361 State Event Action New State 7362 -------------------------------------------------------------- 7364 RRDel RR Done Send BU, WaitD 7365 Stop timers, 7366 Start retrans- 7367 mission timer, 7368 Start failure 7369 timer 7371 RRDel Valid BE received Stop RR Idle 7373 RRDel Movement Stop RR, RRInit 7374 Start RR 7376 RRDel ICMP Problem 1 received (None) RRDel 7378 State Event Action New State 7379 -------------------------------------------------------------- 7381 Bound Valid BRR received Start RR RRRedo 7383 Bound Returning home Start RR RRDel 7385 Bound Movement Start RR RRInit 7387 Bound Valid BE received and Start RR RRInit 7388 status = 1 and no reason to 7389 believe forward progress 7390 is being made 7392 State Event Action New State 7393 -------------------------------------------------------------- 7395 (Any) RR Failed (None) Idle 7397 (Any) Failure timer Stop retrans- Idle 7398 mission timer 7400 (Any) Invalid MH Type received Send BE (No change) 7402 A.2. Return Routability Procedure 7404 The second state machine describes how the return routability 7405 procedure is performed. This state machine is used in three 7406 situations in the first state machine, when creating a binding 7407 for the first time, when refreshing an existing binding, and when 7408 performing a deregistration. 7410 The mobile node will keep the following states in its Binding List 7411 for the return routability procedure: 7413 Start 7415 In this state, the return routability procedure is not active. 7417 WaitHC 7419 In this state, the mobile node has sent the Home Test Init 7420 and Care-of Test Init messages, and is waiting for the Home 7421 Test and Care-of Test messages to come back. It will also be 7422 necessary to keep state of retransmissions for both. 7424 WaitH 7426 In this state, the mobile node has a recent Care-of Cookie and 7427 is only waiting for the Home Test message to arrive. 7429 WaitC 7431 In this state, the mobile node has a recent Home Cookie and is 7432 only waiting for the CoT message to arrive. 7434 The following events are possible: 7436 Start RR 7438 This is an abstract message from the first state machine. It 7439 indicates that the return routability procedure needs to be 7440 run. 7442 Start home RR 7444 This a second abstract message from the first state machine. 7445 It indicates that the return routability procedure needs to be 7446 run, but only for the home address. 7448 Stop RR 7450 This is a third abstract message. It signifies that the return 7451 routability procedure is no longer needed. 7453 Valid HoT received 7455 A valid Home Test message has been received. 7457 Valid CoT received 7459 A valid Care-of Test message has been received. 7461 In addition, this state machine uses the Retransmission timer and 7462 Failure timer events from the previous state machine. 7464 The following actions are possible: 7466 Send HoTI 7468 Send the Home Test Init message. 7470 Send CoTI 7472 Send the Care-of Test message. 7474 Store cookie and nonce index 7476 Store the received cookie and nonce index in the appropriate 7477 place in the Binding Update List. 7479 RR Done 7481 This is an abstract event and signals that the return 7482 routability procedure has been completed. 7484 RR Failed 7486 This is an abstract event and signals that the return 7487 routability procedure has failed. 7489 In addition, this state machine uses the Start retransmission timer, 7490 Start failure timer, Stop retransmission timer, and Stop timers 7491 actions from the previous state machine. 7493 The state machine is as follows: 7495 State Event Action New State 7496 -------------------------------------------------------------- 7497 Start Start RR Send HoTI, WaitHC 7498 Send CoTI, 7499 Start retrans- 7500 mission timer, 7501 Start failure 7502 timer 7504 Start Start home RR Send HoTI, WaitH 7505 Start retrans- 7506 mission timer, 7507 Start failure 7508 timer 7510 State Event Action New State 7511 -------------------------------------------------------------- 7513 WaitHC Valid HoT received Store cookie WaitC 7514 and nonce 7515 index 7517 WaitHC Valid CoT received Store cookie WaitH 7518 and nonce 7519 index 7521 WaitHC Retransmission timer Send HoTI, WaitHC 7522 Send CoTI, 7523 Start retrans- 7524 mission timer 7526 State Event Action New State 7527 -------------------------------------------------------------- 7529 WaitH Valid HoT received Store cookie Start 7530 and nonce 7531 index, 7532 Stop timers, 7533 RR Done 7535 WaitH Retransmission timer Send HoTI, WaitH 7536 Start retrans- 7537 mission timer 7539 State Event Action New State 7540 -------------------------------------------------------------- 7542 WaitC Valid CoT received Store cookie Start 7543 and nonce 7544 index, 7545 Stop timers, 7546 RR Done 7548 WaitC Retransmission timer Send CoTI, WaitC 7549 Start retrans- 7550 mission timer 7552 State Event Action New State 7553 -------------------------------------------------------------- 7555 (Any) Stop RR Stop timers Start 7557 (Any) Failure timer Stop retrans- Start 7558 mission timer, 7559 RR Failed 7561 B. Changes from Previous Version of the Draft 7563 This appendix briefly lists some of the major changes in this 7564 draft relative to the previous version of this same draft, 7565 draft-ietf-mobileip-ipv6-17.txt: 7567 - Substantial editorial modifications have taken place, 7568 including the reduction of repetitive text at many places, the 7569 reorganization of security threat and remaining vulnerability 7570 discussion to the Security Considerations section, and so on. 7572 - Mobility Header messages have been reformatted in various ways, 7573 including the reduction of the size of the cookies. 7575 - Recommendations for the RtrAdvInterval, MAX_RR_BINDING_LIFE, and 7576 MAX_COOKIE_LIFE constants have been updated. 7578 - Explanation on how to find the home agent's link-layer address 7579 has been updated. 7581 - Status code values for Binding Acknowledgment have been 7582 renumbered. 7584 - It is required that the (D) and the (L) bits have to be set when 7585 requesting forwarding from a previous care-of address. 7587 - Requirements for IPv6 nodes, routers, and so on have been written 7588 on a new style and without giving a keyword for the support 7589 of route optimization. It is expected that other documents 7590 currently being prepared will have these keywords. 7592 - Binding Error messages are now rate-limited. 7594 - A new flag, the L bit has been introduced to Binding Update 7595 message. 7597 - The refresh field has been moved to a mobility option. 7599 - The Home Address destination option is now used even with Binding 7600 Updates to correspondent nodes. The option MAY used without an 7601 existing binding if the packet has been protected with IPsec. 7603 - The key Kbu is now used also to protect the Binding 7604 Acknowledgement message. 7606 - Both IPsec AH and ESP can be used to protect Binding Updates to 7607 home agents. 7609 - Unsolicited prefix advertisement now stops after a solicitation 7610 arrives to the home agent. 7612 - Security is now required for all prefix discovery messages. 7614 - Limitations regarding the generation of new home addresses for 7615 securing Binding Updates to home agents have been described. 7617 - The state machine for the mobile node has been reorganized. 7619 - Padding and header length texts for the Mobility header have been 7620 corrected. 7622 - Option number and length fields have been corrected for many 7623 mobility options. 7625 - References to mobile router functionality have been removed. 7627 - Acknowledgements section has been updated. 7629 - The mobile cookies have been renamed to be the HoT cookie and the 7630 CoT cookie. 7632 - The Unique Identifier option is no longer specified for use with 7633 the HoTI, CoTI, HoT, or CoT messages. 7635 C. Future Extensions 7637 C.1. Piggybacking 7639 This document does not specify how to piggyback payload packets on 7640 the binding related messages. However, it is envisioned that this 7641 can be specified in a separate document when currently discussed 7642 issues such as the interaction between piggybacking and IPsec are 7643 fully resolved (see also Section C.3). The return routability 7644 messages can indicate support for piggybacking with a new mobility 7645 option. 7647 C.2. Triangular Routing and Unverified Home Addresses 7649 Due to the concerns about opening reflection attacks with the Home 7650 Address destination option, this specification requires that this 7651 option must be verified against the binding cache, i.e., there must 7652 be a binding cache entry for the Home Address and Care-of Address. 7654 Future extensions may be specified that allow the use of unverified 7655 Home Address destination options in ways that do not introduce 7656 security issues. 7658 C.3. New Authorization Methods beyond Return Routability 7660 While the return routability procedure provides a good level 7661 of security, there exists methods that have even higher levels 7662 of security. Secondly, as discussed in Section 14.4, future 7663 enhancements of IPv6 security may cause a need to improve also the 7664 security of the return routability procedure. 7666 Using IPsec as the sole method for authorizing Binding Updates 7667 to correspondent nodes is also possible. The protection of the 7668 Mobility Header for this purpose is easy, though one must ensure 7669 that the IPsec SA was created with appropriate authorization to use 7670 the home address referenced in the Binding Update. For instance, 7671 a certificate used by IKE to create the security association might 7672 contain the home address. A future specification may specify how 7673 this is done. 7675 C.4. Security and Dynamically Generated Home Addresses 7677 A future version of this specification may include functionality 7678 that allows the generation of new home addresses without requiring 7679 pre-arranged security associations or certificates even for the new 7680 addresses. 7682 C.5. Remote Home Address Configuration 7684 The method for initializing a mobile node's home addresses on 7685 power-up or after an extended period of being disconnected from 7686 the network is beyond the scope of this specification. Whatever 7687 procedure is used should result in the mobile node having the same 7688 stateless or stateful (e.g., DHCPv6) home address autoconfiguration 7689 information it would have if it were attached to the home network. 7690 Due to the possibility that the home network could be renumbered 7691 while the mobile node is disconnected, a robust mobile node would not 7692 rely solely on storing these addresses locally. 7694 Such a mobile node could initialize by using the following procedure: 7696 1. Generate a care-of address. 7698 2. Query DNS for the home network's mobile agent anycast address. 7700 3. Send a Home Agent Address Discovery Request message to the home 7701 network. 7703 4. Receive Home Agent Address Discovery Reply message. 7705 5. Select the most preferred home agent and establish a security 7706 association between the mobile node's current care-of address and 7707 the home agent for temporary use during initialization only. 7709 6. Send a Home Prefix Solicitation message with the Request All 7710 Prefixes flag set to the home agent from the mobile node's 7711 care-of address. 7713 7. Receive a Home Prefix Advertisement message from the home agent, 7714 follow stateless address autoconfiguration rules to configure 7715 home addresses for prefixes received. 7717 8. Create a security association between the mobile node's home 7718 address and the home agent. 7720 9. Send a binding update(s) to the home agent to register the mobile 7721 node's home addresses. 7723 10. Receive binding acknowledgement(s) then begin normal 7724 communications. 7726 Chairs' Addresses 7728 The Working Group can be contacted via its current chairs: 7730 Basavaraj Patil Phil Roberts 7731 Nokia Corporation Megisto Corp. 7732 6000 Connection Drive Suite 120 7733 M/S M8-540 20251 Century Blvd 7734 Irving, TX 75039 Germantown MD 20874 7735 USA USA 7736 Phone: +1 972-894-6709 Phone: +1 847-202-9314 7737 Fax : +1 972-894-5349 Email: PRoberts@MEGISTO.com 7738 EMail: Raj.Patil@nokia.com 7740 Authors' Addresses 7742 Questions about this document can also be directed to the authors: 7744 David B. Johnson Charles E. Perkins 7745 Rice University Nokia Research Center 7746 Dept. of Computer Science, MS 132 7747 6100 Main Street 313 Fairchild Drive 7748 Houston, TX 77005-1892 Mountain View, CA 94043 7749 USA USA 7751 Phone: +1 713 348-3063 Phone: +1 650 625-2986 7752 Fax: +1 713 348-5930 Fax: +1 650 625-2502 7753 E-mail: dbj@cs.rice.edu E-mail: charliep@iprg.nokia.com 7755 Jari Arkko 7756 Ericsson 7757 Jorvas 02420 7758 Finland 7760 Phone: +358 40 5079256 7761 E-mail: jari.arkko@ericsson.com