idnits 2.17.1 draft-ietf-mobileip-ipv6-21.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1055 has weird spacing: '...ated to rever...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST not have trailing padding. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2003) is 7729 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1750 (ref. '1') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '5') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '6') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '8') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '9') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (ref. '11') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '12') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '13') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '14') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (ref. '18') (Obsoleted by RFC 4941) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '19') -- Possible downref: Non-RFC (?) normative reference: ref. '20' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-03 -- Obsolete informational reference (is this intentional?): RFC 2002 (ref. '22') (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 2267 (ref. '26') (Obsoleted by RFC 2827) -- Unexpected draft version: The latest known version of draft-ietf-ipv6-default-addr-select is -08, but you're referring to -09. -- No information found for draft-nikander-mipv6-design-rationale - is the name correct? == Outdated reference: A later version (-08) exists of draft-vida-mld-v2-06 Summary: 17 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IP Working Group D. Johnson 3 Internet-Draft Rice University 4 Expires: August 27, 2003 C. Perkins 5 Nokia Research Center 6 J. Arkko 7 Ericsson 8 February 26, 2003 10 Mobility Support in IPv6 11 draft-ietf-mobileip-ipv6-21.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 27, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document specifies the operation of the IPv6 Internet with 43 mobile computers. Each mobile node is always identified by its home 44 address, regardless of its current point of attachment to the 45 Internet. While situated away from its home, a mobile node is also 46 associated with a care-of address, which provides information about 47 the mobile node's current location. IPv6 packets addressed to a 48 mobile node's home address are transparently routed to its care-of 49 address. The protocol enables IPv6 nodes to cache the binding of a 50 mobile node's home address with its care-of address, and to then send 51 any packets destined for the mobile node directly to it at this 52 care-of address. To support this operation, Mobile IPv6 defines a 53 new IPv6 protocol and a new destination option. All IPv6 nodes, 54 whether mobile or stationary can communicate with mobile nodes. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 59 2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . 8 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.1 General Terms . . . . . . . . . . . . . . . . . . . 9 62 3.2 Mobile IPv6 Terms . . . . . . . . . . . . . . . . . 11 63 4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . 15 64 4.1 Basic Operation . . . . . . . . . . . . . . . . . . 15 65 4.2 New IPv6 Protocol . . . . . . . . . . . . . . . . . 17 66 4.3 New IPv6 Destination Option . . . . . . . . . . . . 18 67 4.4 New IPv6 ICMP Messages . . . . . . . . . . . . . . . 18 68 4.5 Conceptual Data Structure Terminology . . . . . . . 18 69 4.6 Site-Local Addressability . . . . . . . . . . . . . 19 70 5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . 20 71 5.1 Binding Updates to Home Agents . . . . . . . . . . . 20 72 5.2 Binding Updates to Correspondent Nodes . . . . . . . 21 73 5.2.1 Node Keys . . . . . . . . . . . . . . . . . 22 74 5.2.2 Nonces . . . . . . . . . . . . . . . . . . . 22 75 5.2.3 Cookies and Tokens . . . . . . . . . . . . . 23 76 5.2.4 Cryptographic Functions . . . . . . . . . . 23 77 5.2.5 Return Routability Procedure . . . . . . . . 23 78 5.2.6 Authorizing Binding Management Messages . . 27 79 5.2.7 Updating Node Keys and Nonces . . . . . . . 29 80 5.2.8 Preventing Replay Attacks . . . . . . . . . 31 81 5.3 Dynamic Home Agent Address Discovery . . . . . . . . 31 82 5.4 Prefix Discovery . . . . . . . . . . . . . . . . . . 31 83 5.5 Payload Packets . . . . . . . . . . . . . . . . . . 31 84 6. New IPv6 Protocol, Message Types, and Destination Option . 33 85 6.1 Mobility Header . . . . . . . . . . . . . . . . . . 33 86 6.1.1 Format . . . . . . . . . . . . . . . . . . . 33 87 6.1.2 Binding Refresh Request Message . . . . . . 35 88 6.1.3 Home Test Init Message . . . . . . . . . . . 36 89 6.1.4 Care-of Test Init Message . . . . . . . . . 37 90 6.1.5 Home Test Message . . . . . . . . . . . . . 38 91 6.1.6 Care-of Test Message . . . . . . . . . . . . 39 92 6.1.7 Binding Update Message . . . . . . . . . . . 40 93 6.1.8 Binding Acknowledgement Message . . . . . . 42 94 6.1.9 Binding Error Message . . . . . . . . . . . 45 95 6.2 Mobility Options . . . . . . . . . . . . . . . . . . 46 96 6.2.1 Format . . . . . . . . . . . . . . . . . . . 47 97 6.2.2 Pad1 . . . . . . . . . . . . . . . . . . . . 48 98 6.2.3 PadN . . . . . . . . . . . . . . . . . . . . 48 99 6.2.4 Binding Refresh Advice . . . . . . . . . . . 48 100 6.2.5 Alternate Care-of Address . . . . . . . . . 49 101 6.2.6 Nonce Indices . . . . . . . . . . . . . . . 49 102 6.2.7 Binding Authorization Data . . . . . . . . . 50 103 6.3 Home Address Option . . . . . . . . . . . . . . . . 51 104 6.4 Type 2 Routing Header . . . . . . . . . . . . . . . 53 105 6.4.1 Format . . . . . . . . . . . . . . . . . . . 53 106 6.5 ICMP Home Agent Address Discovery Request Message . 55 107 6.6 ICMP Home Agent Address Discovery Reply Message . . 56 108 6.7 ICMP Mobile Prefix Solicitation Message Format . . . 57 109 6.8 ICMP Mobile Prefix Advertisement Message Format . . 59 110 7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . 62 111 7.1 Modified Router Advertisement Message Format . . . . 62 112 7.2 Modified Prefix Information Option Format . . . . . 62 113 7.3 New Advertisement Interval Option Format . . . . . . 64 114 7.4 New Home Agent Information Option Format . . . . . . 65 115 7.5 Changes to Sending Router Advertisements . . . . . . 66 116 7.6 Changes to Duplicate Address Detection . . . . . . . 68 117 8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . 69 118 8.1 All IPv6 Nodes . . . . . . . . . . . . . . . . . . . 69 119 8.2 IPv6 Nodes with Support for Route Optimization . . . 69 120 8.3 All IPv6 Routers . . . . . . . . . . . . . . . . . . 71 121 8.4 IPv6 Home Agents . . . . . . . . . . . . . . . . . . 71 122 8.5 IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . 73 123 9. Correspondent Node Operation . . . . . . . . . . . . . . . 75 124 9.1 Conceptual Data Structures . . . . . . . . . . . . . 75 125 9.2 Processing Mobility Headers . . . . . . . . . . . . 76 126 9.3 Packet Processing . . . . . . . . . . . . . . . . . 76 127 9.3.1 Receiving Packets with Home Address Option . 76 128 9.3.2 Sending Packets to a Mobile Node . . . . . . 77 129 9.3.3 Sending Binding Error Messages . . . . . . . 79 130 9.3.4 Receiving ICMP Error Messages . . . . . . . 79 131 9.4 Return Routability Procedure . . . . . . . . . . . . 80 132 9.4.1 Receiving Home Test Init Messages . . . . . 80 133 9.4.2 Receiving Care-of Test Init Messages . . . . 80 134 9.4.3 Sending Home Test Messages . . . . . . . . . 80 135 9.4.4 Sending Care-of Test Messages . . . . . . . 81 136 9.5 Processing Bindings . . . . . . . . . . . . . . . . 81 137 9.5.1 Receiving Binding Updates . . . . . . . . . 81 138 9.5.2 Requests to Cache a Binding . . . . . . . . 83 139 9.5.3 Requests to Delete a Binding . . . . . . . . 84 140 9.5.4 Sending Binding Acknowledgements . . . . . . 84 141 9.5.5 Sending Binding Refresh Requests . . . . . . 85 142 9.6 Cache Replacement Policy . . . . . . . . . . . . . . 86 143 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . 88 144 10.1 Conceptual Data Structures . . . . . . . . . . . . . 88 145 10.2 Processing Mobility Headers . . . . . . . . . . . . 89 146 10.3 Processing Bindings . . . . . . . . . . . . . . . . 89 147 10.3.1 Primary Care-of Address Registration . . . . 89 148 10.3.2 Primary Care-of Address De-Registration . . 93 149 10.4 Packet Processing . . . . . . . . . . . . . . . . . 94 150 10.4.1 Intercepting Packets for a Mobile Node . . . 94 151 10.4.2 Processing Intercepted Packets . . . . . . . 95 152 10.4.3 Multicast Membership Control . . . . . . . . 97 153 10.4.4 Stateful Address Autoconfiguration . . . . . 98 154 10.4.5 Handling Reverse Tunneled Packets . . . . . 98 155 10.4.6 Protecting Return Routability Packets . . . 99 156 10.5 Dynamic Home Agent Address Discovery . . . . . . . . 99 157 10.5.1 Receiving Router Advertisement Messages . . 100 158 10.6 Sending Prefix Information to the Mobile Node . . .102 159 10.6.1 Aggregate List of Home Network Prefixes . . 102 160 10.6.2 Scheduling Prefix Deliveries . . . . . . . . 103 161 10.6.3 Sending Advertisements . . . . . . . . . . . 105 162 10.6.4 Lifetimes for Changed Prefixes . . . . . . . 106 163 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . 107 164 11.1 Conceptual Data Structures . . . . . . . . . . . . .107 165 11.2 Processing Mobility Headers . . . . . . . . . . . .108 166 11.3 Packet Processing . . . . . . . . . . . . . . . . .108 167 11.3.1 Sending Packets While Away from Home . . . . 109 168 11.3.2 Interaction with Outbound IPsec Processing . 111 169 11.3.3 Receiving Packets While Away from Home . . . 113 170 11.3.4 Routing Multicast Packets . . . . . . . . . 114 171 11.3.5 Receiving ICMP Error Messages . . . . . . . 116 172 11.3.6 Receiving Binding Error Messages . . . . . . 116 173 11.4 Home Agent and Prefix Management . . . . . . . . . .117 174 11.4.1 Dynamic Home Agent Address Discovery . . . . 117 175 11.4.2 Sending Mobile Prefix Solicitations . . . . 118 176 11.4.3 Receiving Mobile Prefix Advertisements . . . 119 177 11.5 Movement . . . . . . . . . . . . . . . . . . . . . .120 178 11.5.1 Movement Detection . . . . . . . . . . . . . 120 179 11.5.2 Forming New Care-of Addresses . . . . . . . 123 180 11.5.3 Using Multiple Care-of Addresses . . . . . . 123 181 11.5.4 Returning Home . . . . . . . . . . . . . . . 124 182 11.6 Return Routability Procedure . . . . . . . . . . . .126 183 11.6.1 Sending Test Init Messages . . . . . . . . . 126 184 11.6.2 Receiving Test Messages . . . . . . . . . . 127 185 11.6.3 Protecting Return Routability Packets . . . 128 186 11.7 Processing Bindings . . . . . . . . . . . . . . . .128 187 11.7.1 Sending Binding Updates to the Home Agent . 128 188 11.7.2 Correspondent Binding Procedure . . . . . . 131 189 11.7.3 Receiving Binding Acknowledgements . . . . . 134 190 11.7.4 Receiving Binding Refresh Requests . . . . . 136 191 11.8 Retransmissions and Rate Limiting . . . . . . . . .137 192 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 139 193 13. Protocol Configuration Variables . . . . . . . . . . . . . 140 194 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 141 195 15. Security Considerations . . . . . . . . . . . . . . . . . 143 196 15.1 Threats . . . . . . . . . . . . . . . . . . . . . .143 197 15.2 Features . . . . . . . . . . . . . . . . . . . . . .145 198 15.3 Binding Updates to Home Agent . . . . . . . . . . .146 199 15.4 Binding Updates to Correspondent Nodes . . . . . . .147 200 15.4.1 Overview . . . . . . . . . . . . . . . . . . 147 201 15.4.2 Achieved Security Properties . . . . . . . . 148 202 15.4.3 Comparison to Regular IPv6 Communications . 149 203 15.4.4 Replay Attacks . . . . . . . . . . . . . . . 151 204 15.4.5 Denial-of-Service Attacks . . . . . . . . . 151 205 15.4.6 Key Lengths . . . . . . . . . . . . . . . . 152 206 15.5 Dynamic Home Agent Address Discovery . . . . . . . .153 207 15.6 Prefix Discovery . . . . . . . . . . . . . . . . . .153 208 15.7 Tunneling via the Home Agent . . . . . . . . . . . .153 209 15.8 Home Address Option . . . . . . . . . . . . . . . .154 210 15.9 Type 2 Routing Header . . . . . . . . . . . . . . .155 211 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . 156 212 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 157 213 Normative References . . . . . . . . . . . . . . . . . . . 158 214 Informative References . . . . . . . . . . . . . . . . . . 160 215 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 161 216 A. Changes from Previous Version of the Draft . . . . . . . . 162 217 B. Future Extensions . . . . . . . . . . . . . . . . . . . . 165 218 B.1 Piggybacking . . . . . . . . . . . . . . . . . . . .165 219 B.2 Triangular Routing . . . . . . . . . . . . . . . . .165 220 B.3 New Authorization Methods . . . . . . . . . . . . .165 221 B.4 Dynamically Generated Home Addresses . . . . . . . .165 222 B.5 Remote Home Address Configuration . . . . . . . . .165 223 B.6 Neighbor Discovery Extensions . . . . . . . . . . .166 224 Intellectual Property and Copyright Statements . . . . . . 168 226 1. Introduction 228 This document specifies how the IPv6 Internet operates with mobile 229 computers. Without specific support for mobility in IPv6 [11], 230 packets destined to a mobile node would not be able to reach it while 231 the mobile node is away from its home link. In order to continue 232 communication in spite of its movement, a mobile node could change 233 its IP address each time it moves to a new link, but the mobile node 234 would then not be able to maintain transport and higher-layer 235 connections when it changes location. Mobility support in IPv6 is 236 particularly important, as mobile computers are likely to account for 237 a majority or at least a substantial fraction of the population of 238 the Internet during the lifetime of IPv6. 240 The protocol defined in this document, known as Mobile IPv6, allows a 241 mobile node to move from one link to another without changing the 242 mobile node's "home address". Packets may be routed to the mobile 243 node using this address regardless of the mobile node's current point 244 of attachment to the Internet. The mobile node may also continue to 245 communicate with other nodes (stationary or mobile) after moving to a 246 new link. The movement of a mobile node away from its home link is 247 thus transparent to transport and higher-layer protocols and 248 applications. 250 The Mobile IPv6 protocol is just as suitable for mobility across 251 homogeneous media as for mobility across heterogeneous media. For 252 example, Mobile IPv6 facilitates node movement from one Ethernet 253 segment to another as well as it facilitates node movement from an 254 Ethernet segment to a wireless LAN cell, with the mobile node's IP 255 address remaining unchanged in spite of such movement. 257 One can think of the Mobile IPv6 protocol as solving the 258 network-layer mobility management problem. Some mobility management 259 applications -- for example, handover among wireless transceivers, 260 each of which covers only a very small geographic area -- have been 261 solved using link-layer techniques. For example, in many current 262 wireless LAN products, link-layer mobility mechanisms allow a 263 "handover" of a mobile node from one cell to another, re-establishing 264 link-layer connectivity to the node in each new location. 266 Mobile IPv6 does not attempt to solve all general problems related to 267 the use of mobile computers or wireless networks. In particular, 268 this protocol does not attempt to solve: 270 o Handling links with partial reachability, or unidirectional 271 connectivity, such as are often found in wireless networks (but 272 see Section 11.5.1). 274 o Access control on a link being visited by a mobile node. 276 o Local or hierarchical forms of mobility management (similar to 277 many current link-layer mobility management solutions). 279 o Assistance for adaptive applications 281 o Mobile routers 283 o Service Discovery 285 o Distinguishing between packets lost due to bit errors vs. network 286 congestion 288 2. Comparison with Mobile IP for IPv4 290 The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both 291 from the experiences gained from the development of Mobile IP support 292 in IPv4 (Mobile IPv4) [22, 23, 24], and from the opportunities 293 provided by IPv6. Mobile IPv6 thus shares many features with Mobile 294 IPv4, but is integrated into IPv6 and offers many other improvements. 295 This section summarizes the major differences between Mobile IPv4 and 296 Mobile IPv6: 298 o There is no need to deploy special routers as "foreign agents", as 299 in Mobile IPv4. Mobile IPv6 operates in any location without any 300 special support required from the local router. 302 o Support for route optimization is a fundamental part of the 303 protocol, rather than a nonstandard set of extensions. 305 o Mobile IPv6 route optimization can operate securely even without 306 pre-arranged security associations. It is expected that route 307 optimization can be deployed on a global scale between all mobile 308 nodes and correspondent nodes. 310 o Support is also integrated into Mobile IPv6 for allowing route 311 optimization to coexist efficiently with routers that perform 312 "ingress filtering" [26]. 314 o The movement detection mechanism in Mobile IPv6 provides 315 bidirectional confirmation of a mobile node's ability to 316 communicate with its default router in its current location. 318 o Most packets sent to a mobile node while away from home in Mobile 319 IPv6 are sent using an IPv6 routing header rather than IP 320 encapsulation, reducing the amount of resulting overhead compared 321 to Mobile IPv4. 323 o Mobile IPv6 is decoupled from any particular link layer, as it 324 uses IPv6 Neighbor Discovery [12] instead of ARP. This also 325 improves the robustness of the protocol. 327 o The use of IPv6 encapsulation (and the routing header) removes the 328 need in Mobile IPv6 to manage "tunnel soft state". 330 o The dynamic home agent address discovery mechanism in Mobile IPv6 331 returns a single reply to the mobile node. The directed broadcast 332 approach used in IPv4 returns separate replies from each home 333 agent. 335 3. Terminology 337 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 338 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 339 document are to be interpreted as described in RFC 2119 [2]. 341 3.1 General Terms 343 IP 345 Internet Protocol Version 6 (IPv6). 347 node 349 A device that implements IP. 351 router 353 A node that forwards IP packets not explicitly addressed to 354 itself. 356 unicast routable address 358 An identifier for a single interface such that a packet sent to it 359 from another IPv6 subnet is delivered to the interface identified 360 by that address. Accordingly, a unicast routable address must 361 have either a global or site-local scope (but not link-local). 363 host 365 Any node that is not a router. 367 link 369 A communication facility or medium over which nodes can 370 communicate at the link layer, such as an Ethernet (simple or 371 bridged). A link is the layer immediately below IP. 373 interface 375 A node's attachment to a link. 377 subnet prefix 379 A bit string that consists of some number of initial bits of an IP 380 address. 382 interface identifier 384 A number used to identify a node's interface on a link. The 385 interface identifier is the remaining low-order bits in the node's 386 IP address after the subnet prefix. 388 link-layer address 390 A link-layer identifier for an interface, such as IEEE 802 391 addresses on Ethernet links. 393 packet 395 An IP header plus payload. 397 security association 399 An IPsec security association is a simplex "connection" that 400 affords security services to the traffic carried by it. Security 401 services are afforded to a security association by the use of the 402 AH and ESP protocols. 404 security policy database 406 A database that specifies what security services are to be offered 407 to IP packets and in what fashion. 409 destination option 411 Destination options are carried by the IPv6 Destination Options 412 extension header. Destination options include optional 413 information that need be examined only by the IPv6 node given as 414 the destination address in the IPv6 header, not by routers in 415 between. Mobile IPv6 defines one new destination option, the Home 416 Address destination option (see Section 6.3). 418 routing header 420 A routing header may be present as an IPv6 header extension, and 421 indicates that the payload has to be delivered to a destination 422 IPv6 address in some way that is different from what would be 423 carried out by standard Internet routing. In this document, use 424 of the term "routing header" typically refers to use of a type 2 425 routing header, as specified in Section 6.4. 427 '|' (concatenation) 429 Some formulas in this specification use the symbol '|' indicate 430 bytewise concatenation, as in A | B. This concatenation requires 431 that all of the bytes of the datum A appear first in the result, 432 followed by all of the bytes of the datum B. 434 First (size, input) 436 Some formulas in this specification use a functional form "First 437 (size, input)" to indicate truncation of the "input" data so that 438 only the first "size" bits remain to be used. 440 3.2 Mobile IPv6 Terms 442 home address 444 A unicast routable address assigned to a mobile node, used as the 445 permanent address of the mobile node. This address is within the 446 mobile node's home link. Standard IP routing mechanisms will 447 deliver packets destined for a mobile node's home address to its 448 home link. 450 home subnet prefix 452 The IP subnet prefix corresponding to a mobile node's home 453 address. 455 home link 457 The link on which a mobile node's home subnet prefix is defined. 459 mobile node 461 A node that can change its point of attachment from one link to 462 another, while still being reachable via its home address. 464 movement 466 A change in a mobile node's point of attachment to the Internet 467 such that it is no longer connected to the same link as it was 468 previously. If a mobile node is not currently attached to its 469 home link, the mobile node is said to be "away from home". 471 correspondent node 473 A peer node with which a mobile node is communicating. The 474 correspondent node may be either mobile or stationary. 476 foreign subnet prefix 478 Any IP subnet prefix other than the mobile node's home subnet 479 prefix. 481 foreign link 483 Any link other than the mobile node's home link. 485 care-of address 487 A unicast routable address associated with a mobile node while 488 visiting a foreign link; the subnet prefix of this IP address is a 489 foreign subnet prefix. Among the multiple care-of addresses that 490 a mobile node may have at any given time (e.g., with different 491 subnet prefixes), the one registered with the mobile node's home 492 agent is called its "primary" care-of address. 494 home agent 496 A router on a mobile node's home link with which the mobile node 497 has registered its current care-of address. While the mobile node 498 is away from home, the home agent intercepts packets on the home 499 link destined to the mobile node's home address, encapsulates 500 them, and tunnels them to the mobile node's registered care-of 501 address. 503 binding 505 The association of the home address of a mobile node with a 506 care-of address for that mobile node, along with the remaining 507 lifetime of that association. 509 registration 511 The process during which a mobile node sends a Binding Update to 512 its home agent or a correspondent node, causing a binding for the 513 mobile node to be registered. 515 mobility message 517 A message containing a Mobility Header (see Section 6.1). 519 binding procedure 521 A binding procedure is initiated by the mobile node to inform 522 either a correspondent node or the mobile node's home agent of the 523 current binding of the mobile node. 525 binding authorization 527 Binding procedure needs to be authorized to allow the recipient to 528 believe that the sender has the right to specify a new binding. 530 return routability procedure 532 The return routability procedure authorizes binding procedures by 533 the use of a cryptographic token exchange. 535 correspondent binding procedure 537 A return routability procedure followed by a binding procedure, 538 run between the mobile node and a correspondent node. 540 home binding procedure 542 A binding procedure between the mobile node and its home agent, 543 authorized by the use of IPsec. 545 nonce 547 Nonces are random numbers used internally by the correspondent 548 node in the creation of keygen tokens related to the return 549 routability procedure. The nonces are not specific to a mobile 550 node, and are kept secret within the correspondent node. 552 nonce index 554 A nonce index is used to indicate which nonces have been used when 555 creating keygen token values, without revealing the nonces 556 themselves. 558 cookie 560 A cookie is a random number used by a mobile nodes to prevent 561 spoofing by a bogus correspondent node in the return routability 562 procedure. 564 care-of init cookie 566 A cookie sent to the correspondent node in the Care-of Test Init 567 message, to be returned in the Care-of Test message. 569 home init cookie 571 A cookie sent to the correspondent node in the Home Test Init 572 message, to be returned in the Home Test message. 574 keygen token 576 A keygen token is a number supplied by a correspondent node in the 577 return routability procedure to enable the mobile node to compute 578 the necessary binding management key for authorizing a Binding 579 Update. 581 care-of keygen token 583 A keygen token sent by the correspondent node in the Care-of Test 584 message. 586 home keygen token 588 A keygen token sent by the correspondent node in the Home Test 589 message. 591 binding management key (Kbm) 593 A binding management key (Kbm) is a key used for authorizing a 594 binding cache management message (e.g., Binding Update or Binding 595 Acknowledgement). Return routability provides a way to create a 596 binding management key. 598 4. Overview of Mobile IPv6 600 4.1 Basic Operation 602 A mobile node is always expected to be addressable at its home 603 address, whether it is currently attached to its home link or is away 604 from home. The "home address" is an IP address assigned to the 605 mobile node within its home subnet prefix on its home link. While a 606 mobile node is at home, packets addressed to its home address are 607 routed to the mobile node's home link, using conventional Internet 608 routing mechanisms. 610 While a mobile node is attached to some foreign link away from home, 611 it is also addressable at one or more care-of addresses. A care-of 612 address is an IP address associated with a mobile node that has the 613 subnet prefix of a particular foreign link. The mobile node can 614 acquire its care-of address through conventional IPv6 mechanisms, 615 such as stateless or stateful auto-configuration. As long as the 616 mobile node stays in this location, packets addressed to this care-of 617 address will be routed to the mobile node. The mobile node may also 618 accept packets from several care-of addresses, such as when it is 619 moving but still reachable at the previous link. 621 The association between a mobile node's home address and care-of 622 address is known as a "binding" for the mobile node. While away from 623 home, a mobile node registers its primary care-of address with a 624 router on its home link, requesting this router to function as the 625 "home agent" for the mobile node. The mobile node performs this 626 binding registration by sending a "Binding Update" message to the 627 home agent. The home agent replies to the mobile node by returning a 628 "Binding Acknowledgement" message. The operation of the mobile node 629 is specified in Section 11, and the operation of the home agent is 630 specified in Section 10. 632 Any node communicating with a mobile node is referred to in this 633 document as a "correspondent node" of the mobile node, and may itself 634 be either a stationary node or a mobile node. Mobile nodes can 635 provide information about their current location to correspondent 636 nodes. This happens through the correspondent binding procedure. As 637 a part of this procedure, a return routability test is performed in 638 order to authorize the establishment of the binding. The operation 639 of the correspondent node is specified in Section 9. 641 There are two possible modes for communications between the mobile 642 node and a correspondent node. The first mode, bidirectional 643 tunneling, does not require Mobile IPv6 support from the 644 correspondent node and is available even if the mobile node has not 645 registered its current binding with the correspondent node. Packets 646 from the correspondent node are routed to the home agent and then 647 tunneled to the mobile node. Packets to the correspondent node are 648 tunneled from the mobile node to the home agent ("reverse tunneled") 649 and then routed normally from the home network to the correspondent 650 node. In this mode, the home agent uses proxy Neighbor Discovery to 651 intercept any IPv6 packets addressed to the mobile node's home 652 address (or home addresses) on the home link. Each intercepted 653 packet is tunneled to the mobile node's primary care-of address. 654 This tunneling is performed using IPv6 encapsulation [15]. 656 The second mode, "route optimization", requires the mobile node to 657 register its current binding at the correspondent node. Packets from 658 the correspondent node can be routed directly to the care-of address 659 of the mobile node. When sending a packet to any IPv6 destination, 660 the correspondent node checks its cached bindings for an entry for 661 the packet's destination address. If a cached binding for this 662 destination address is found, the node uses a new type of IPv6 663 routing header [11] (see Section 6.4) to route the packet to the 664 mobile node by way of the care-of address indicated in this binding. 666 Routing packets directly to the mobile node's care-of address allows 667 the shortest communications path to be used. It also eliminates 668 congestion at the mobile node's home agent and home link. In 669 addition, the impact of any possible failure of the home agent or 670 networks on the path to or from it is reduced. 672 When routing packets directly to the mobile node, the correspondent 673 node sets the Destination Address in the IPv6 header to the care-of 674 address of the mobile node. A new type of IPv6 routing header (see 675 Section 6.4) is also added to the packet to carry the desired home 676 address. Similarly, the mobile node sets the Source Address in the 677 packet's IPv6 header to its current care-of addresses. The mobile 678 node adds a new IPv6 "Home Address" destination option (see Section 679 6.3) to carry its home address. The inclusion of home addresses in 680 these packets makes the use of the care-of address transparent above 681 the network layer (e.g., at the transport layer). 683 Mobile IPv6 also provides support for multiple home agents, and the 684 reconfiguration of the home network. In these cases, the mobile node 685 may not know the IP address of its own home agent, and even the home 686 subnet prefixes may change over time. A mechanism, known as "dynamic 687 home agent address discovery" allows a mobile node to dynamically 688 discover the IP address of a home agent on its home link, even when 689 the mobile node is away from home. Mobile nodes can also learn new 690 information about home subnet prefixes through the "prefix discovery" 691 mechanism. These mechanisms are described starting from Section 6.5. 693 4.2 New IPv6 Protocol 695 Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header 696 (see Section 6.1). This Header is used to carry the following 697 messages: 699 Home Test Init 701 Home Test 703 Care-of Test Init 705 Care-of Test 707 These four messages are used to initiate the return routability 708 procedure from the mobile node to a correspondent node. This 709 ensures authorization of subsequent Binding Updates, as described 710 in Section 5.2.5. 712 Binding Update 714 A Binding Update is used by a mobile node to notify a 715 correspondent node or the mobile node's home agent of its current 716 binding. The Binding Update sent to the mobile node's home agent 717 to register its primary care-of address is marked as a "home 718 registration". 720 Binding Acknowledgement 722 A Binding Acknowledgement is used to acknowledge receipt of a 723 Binding Update, if an acknowledgement was requested in the Binding 724 Update, the binding update was sent to a home agent, or an error 725 occurred. 727 Binding Refresh Request 729 A Binding Refresh Request is used to request a mobile node to 730 re-establish its binding with the correspondent node. This 731 message is typically used when the cached binding is in active use 732 but the binding's lifetime is close to expiration. The 733 correspondent node may use, for instance, recent traffic and open 734 transport layer connections as an indication of active use. 736 Binding Error 738 The Binding Error is used by the correspondent node to signal an 739 error related to mobility, such as an inappropriate attempt to use 740 the Home Address destination option without an existing binding. 742 4.3 New IPv6 Destination Option 744 Mobile IPv6 defines a new IPv6 destination option, the Home Address 745 destination option. This option is described in detail in Section 746 6.3. 748 4.4 New IPv6 ICMP Messages 750 Mobile IPv6 also introduces four new ICMP message types, two for use 751 in the dynamic home agent address discovery mechanism, and two for 752 renumbering and mobile configuration mechanisms. As described in 753 Section 10.5 and Section 11.4.1, the following two new ICMP message 754 types are used for home agent address discovery: 756 o Home Agent Address Discovery Request, described in Section 6.5. 758 o Home Agent Address Discovery Reply, described in Section 6.6. 760 The next two message types are used for network renumbering and 761 address configuration on the mobile node, as described in Section 762 10.6: 764 o Mobile Prefix Solicitation, described in Section 6.7. 766 o Mobile Prefix Advertisement, described in Section 6.8. 768 4.5 Conceptual Data Structure Terminology 770 This document describes the Mobile IPv6 protocol in terms of the 771 following conceptual data structures: 773 Binding Cache 775 A cache of bindings for other nodes. This cache is maintained by 776 home agents and correspondent nodes. The cache contains both 777 "correspondent registration" entries (see Section 9.1) and "home 778 registration" entries (see Section 10.1). 780 Binding Update List 782 This list is maintained by each mobile node. The list has an item 783 for every binding that the mobile node has or is trying to 784 establish with a specific other node. Both correspondent and home 785 registrations are included in this list. Entries from the list 786 are deleted as the lifetime of the binding expires. See Section 787 11.1. 789 Home Agents List 791 Home agents need to know which other home agents are on the same 792 link. This information is stored in the Home Agents List, as 793 described in more detail in Section 10.1. The list is used for 794 informing mobile nodes during dynamic home agent address 795 discovery. 797 4.6 Site-Local Addressability 799 This specification requires that home and care-of addresses MUST be 800 unicast routable addresses. Site-local addresses may be usable on 801 networks that are not connected to the Internet, but this 802 specification does not define when such usage is safe and when not. 803 Mobile nodes may not be aware of which site they are currently on, it 804 is hard to prevent accidental attachment to other sites, and 805 ambiguity of site-local addresses can cause problems if the home and 806 visited networks use the same addresses. Therefore, site-local 807 addresses SHOULD NOT be used as home or care-of addresses. 809 5. Overview of Mobile IPv6 Security 811 This specification provides a number of security features. These 812 include the protection of Binding Updates both to home agents and 813 correspondent nodes, the protection of prefix discovery, and the 814 protection of the mechanisms that Mobile IPv6 uses for transporting 815 data packets. 817 Binding Updates are protected by the use of IPsec extension headers, 818 or by the use of the Binding Authorization Data option. This option 819 employs a binding management key, Kbm, which can be established 820 through the return routability procedure. Prefix discovery is 821 protected through the use of IPsec extension headers. Mechanisms 822 related to transporting payload packets - such as the Home Address 823 destination option and type 2 routing header - have been specified in 824 a manner which restricts their use in attacks. 826 5.1 Binding Updates to Home Agents 828 The mobile node and the home agent MUST use an IPsec security 829 association to protect the integrity and authenticity of the Binding 830 Updates and Acknowledgements. Both the mobile nodes and the home 831 agents SHOULD use the Encapsulating Security Payload (ESP) [6] header 832 in transport mode and MUST use a non-NULL payload authentication 833 algorithm to provide data origin authentication, connectionless 834 integrity and optional anti-replay protection. Note that 835 Authentication Header (AH) [5] is also possible but for brevity not 836 discussed in this specification. 838 In order to protect messages exchanged between the mobile node and 839 the home agent with IPsec, appropriate security policy database 840 entries must be created. A mobile node must be prevented from using 841 its security association to send a Binding Update on behalf of 842 another mobile node using the same home agent. This MUST be achieved 843 by having the home agent check that the given home address has been 844 used with the right security association. Such a check is provided 845 in the IPsec processing, by having the security policy database 846 entries unequivocally identify a single security association for any 847 given home address and home agent. In order to make this possible, 848 it is necessary that the home address of the mobile node is visible 849 in the Binding Updates and Acknowledgements. The home address is 850 used in these packets as a source or destination, or in the Home 851 Address Destination option or the type 2 routing header. 853 As with all IPsec security associations in this specification, manual 854 configuration of security associations MUST be supported. The used 855 shared secrets MUST be random and unique for different mobile nodes, 856 and MUST be distributed off-line to the mobile nodes. 858 Automatic key management with IKE [9] MAY be supported. When IKE is 859 used, either the security policy database entries or the MIPv6 860 processing MUST unequivocally identify the IKE phase 1 credentials 861 which can be used to authorize the creation of security associations 862 for a particular home address. How these mappings are maintained is 863 outside the scope of this specification, but they may be maintained, 864 for instance, as a locally administered table in the home agent. If 865 the phase 1 identity is a FQDN, secure forms of DNS may also be used. 867 Section 11.3.2 discusses how IKE connections to the home agent need a 868 careful treatment of the addresses used for transporting IKE. This 869 is necessary to ensure that a Binding Update is not needed before the 870 IKE exchange which is needed for securing the Binding Update. 872 When IKE version 1 is used with preshared secret authentication 873 between the mobile node and the home agent, aggressive mode MUST be 874 used. Similarly, the ID_IPV6_ADDR Identity Payload MUST NOT be used 875 in IKEv1 phase 1. 877 Reference [21] contains a more detailed description and examples on 878 using IPsec to protect the communications between the mobile node and 879 the home agent. 881 5.2 Binding Updates to Correspondent Nodes 883 The protection of Binding Updates sent to correspondent nodes does 884 not require the configuration of security associations or the 885 existence of an authentication infrastructure between the mobile 886 nodes and correspondent nodes. Instead, a method called the return 887 routability procedure is used to assure that the right mobile node is 888 sending the message. This method does not protect against attackers 889 who are on the path between the home network and the correspondent 890 node. However, attackers in such a location are capable of 891 performing the same attacks even without Mobile IPv6. The main 892 advantage of the return routability procedure is that it limits the 893 potential attackers to those having an access to one specific path in 894 the Internet, and avoids forged Binding Updates from anywhere else in 895 the Internet. For a more in depth explanation of the security 896 properties of the return routability procedure, see Section 15. 898 The integrity and authenticity of the Binding Updates messages to 899 correspondent nodes is protected by using a keyed-hash algorithm. 900 The binding management key, Kbm, is used to key the hash algorithm 901 for this purpose. Kbm is established using data exchanged during the 902 return routability procedure. The data exchange is accomplished by 903 use of node keys, nonces, cookies, tokens, and certain cryptographic 904 functions. Section 5.2.5 outlines the basic return routability 905 procedure. Section 5.2.6 shows how the results of this procedure are 906 used to authorize a Binding Update to a correspondent node. 908 5.2.1 Node Keys 910 Each correspondent node has a secret key, Kcn, called the "node key", 911 which it uses to produce the keygen tokens sent to the mobile nodes. 912 The node key MUST be a random number, 20 octets in length. The node 913 key allows the correspondent node to verify that the keygen tokens 914 used by the mobile node in authorizing a Binding Update are indeed 915 its own. This key MUST NOT be shared with any other entity. 917 A correspondent node MAY generate a fresh node key at any time; this 918 avoids the need for secure persistent key storage. Procedures for 919 optionally updating the node key are discussed later in Section 920 5.2.7. 922 5.2.2 Nonces 924 Each correspondent node also generates nonces at regular intervals. 925 The nonces should be generated by using a random number generator 926 that is known to have good randomness properties [1]. A 927 correspondent node may use the same Kcn and nonce with all the 928 mobiles it is in communication with. 930 Each nonce is identified by a nonce index. When a new nonce is 931 generated, it must be associated with a new nonce index; this may be 932 done, for example, by incrementing the value of the previous nonce 933 index, if the nonce index is used as an array pointer into a linear 934 array of nonces. However, there is no requirement that nonces be 935 stored that way, or that the values of subsequent nonce indices have 936 any particular relationship to each other. The index value is 937 communicated in the protocol, so that if a nonce is replaced by new 938 nonce during the run of a protocol, the correspondent node can 939 distinguish messages that should be checked against the old nonce 940 from messages that should be checked against the new nonce. Strictly 941 speaking, indices are not necessary in the authentication, but allow 942 the correspondent node to efficiently find the nonce value that it 943 used in creating a keygen token. 945 Correspondent nodes keep both the current nonce and a small set of 946 valid previous nonces whose lifetime has not yet expired. Expired 947 values MUST be discarded, and messages using stale or unknown indices 948 will be rejected. 950 The specific nonce index values cannot be used by mobile nodes to 951 determine the validity of the nonce. Expected validity times for the 952 nonces values and the procedures for updating them are discussed 953 later in Section 5.2.7. 955 A nonce is an octet string of any length. The recommended length is 956 64 bits. 958 5.2.3 Cookies and Tokens 960 The return routability address test procedure uses cookies and keygen 961 tokens as opaque values within the test init and test messages, 962 respectively. 964 o The "home init cookie" and "care-of init cookie" are 64 bit values 965 sent to the correspondent node from the mobile node, and later 966 returned to the mobile node. The home init cookie is sent in the 967 Home Test Init message, and returned in the Home Test message. 968 The care-of init cookie is sent in the Care-of Test Init message, 969 and returned in the Care-of Test message. 971 o The "home keygen token" and "care-of keygen token" are 64-bit 972 values sent by the correspondent node to the mobile node via the 973 home agent (via the Home Test message) and the care-of address (by 974 the Care-of Test message), respectively. 976 The mobile node should set the home init or care-of init cookie to a 977 newly generated random number in every Home or Care-of Test Init 978 message it sends. The cookies are used to verify that the Home Test 979 or Care-of Test message matches the Home Test Init or Care-of Test 980 Init message, respectively. These cookies also serve to ensure that 981 parties who have not seen the request cannot spoof responses. 983 Home and care-of keygen tokens are produced by the correspondent node 984 based on its currently active secret key (Kcn) and nonces, as well as 985 the home or care-of address (respectively). A keygen token is valid 986 as long as both the secret key (Kcn) and the nonce used to create it 987 are valid. 989 5.2.4 Cryptographic Functions 991 In this specification, the function used to compute hash values is 992 SHA1 [20]. Message Authentication Codes (MACs) are computed using 993 HMAC_SHA1 [25, 20]. HMAC_SHA1(K,m) denotes such a MAC computed on 994 message m with key K. 996 5.2.5 Return Routability Procedure 998 The Return Routability Procedure enables the correspondent node to 999 obtain some reasonable assurance that the mobile node is in fact 1000 addressable at its claimed care-of address as well as at its home 1001 address. Only with this assurance is the correspondent node able to 1002 accept Binding Updates from the mobile node which would then instruct 1003 the correspondent node to direct that mobile node's data traffic to 1004 its claimed care-of address. 1006 This is done by testing whether packets addressed to the two claimed 1007 addresses are routed to the mobile node. The mobile node can pass 1008 the test only if it is able to supply proof that it received certain 1009 data (the "keygen tokens") which the correspondent node sends to 1010 those addresses. These data are combined by the mobile node into a 1011 binding management key, denoted Kbm. 1013 The below figure shows the message flow for the return routability 1014 procedure. 1016 Mobile node Home agent Correspondent node 1017 | | 1018 | Home Test Init (HoTI) | | 1019 |------------------------->|------------------------->| 1020 | | | 1021 | Care-of Test Init (CoTI) | 1022 |---------------------------------------------------->| 1023 | | 1024 | | Home Test (HoT) | 1025 |<-------------------------|<-------------------------| 1026 | | | 1027 | Care-of Test (CoT) | 1028 |<----------------------------------------------------| 1029 | | 1031 The Home and Care-of Test Init messages are sent at the same time. 1032 The procedure requires very little processing at the correspondent 1033 node, and the Home and Care-of Test messages can be returned quickly, 1034 perhaps nearly simultaneously. These four messages form the return 1035 routability procedure. 1037 Home Test Init 1039 A mobile node sends a Home Test Init message to the correspondent 1040 node to acquire the home keygen token. The contents of the 1041 message can be summarized as follows: 1043 * Source Address = home address 1045 * Destination Address = correspondent 1047 * Parameters: 1049 + home init cookie 1051 The Home Test Init message conveys the mobile node's home address 1052 to the correspondent node. The mobile node also sends along a 1053 home init cookie that the correspondent node must return later. 1054 The Home Test Init message is reverse tunneled through the home 1055 agent. (The headers and addresses related to reverse tunneling 1056 have been omitted from the above discussion of the message 1057 contents.) The mobile node remembers these cookie values to obtain 1058 some assurance that its protocol messages are being processed by 1059 the desired correspondent node. 1061 Care-of Test Init 1063 The mobile node sends a Care-of Test Init message to the 1064 correspondent node to acquire the care-of keygen token. The 1065 contents of this message can be summarized as follows: 1067 * Source Address = care-of address 1069 * Destination Address = correspondent 1071 * Parameters: 1073 + care-of init cookie 1075 The Care-of Test Init message conveys the mobile node's care-of 1076 address to the correspondent node. The mobile node also sends 1077 along a care-of init cookie that the correspondent node must 1078 return later. The Care-of Test Init message is sent directly to 1079 the correspondent node. 1081 Home Test 1083 The Home Test message is sent in response to a Home Test Init 1084 message. The contents of the message are: 1086 * Source Address = correspondent 1088 * Destination Address = home address 1090 * Parameters: 1092 + home init cookie 1094 + home keygen token 1095 + home nonce index 1097 When the correspondent node receives the Home Test Init message, 1098 it generates a home keygen token as follows: 1100 home keygen token := 1101 First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) 1103 where | denotes concatenation. The final "0" inside the HMAC_SHA1 1104 function is a single zero octet, used to distinguish home and 1105 care-of cookies from each other. The home keygen token is formed 1106 from the first 64 bits of the MAC. The home keygen token tests 1107 that the mobile can receive messages sent to its home address. 1108 Kcn is used in the production of home keygen token in order to 1109 allow the correspondent node to verify that it generated the home 1110 and care-of nonces, without forcing the correspondent node to 1111 remember a list of all tokens it has handed out. The Home Test 1112 message is sent to the mobile node via the home network, where it 1113 is presumed that the home agent will tunnel the message to the 1114 mobile node. This means that the mobile node needs to already 1115 have sent a Binding Update to the home agent, so that the home 1116 agent will have received and authorized the new care-of address 1117 for the mobile node before the return routability procedure. For 1118 improved security, the data passed between the home agent and the 1119 mobile node can be made immune to inspection and passive attacks. 1120 Such protection can be gained by encrypting the home keygen token 1121 as it is tunneled from the home agent to the mobile node as 1122 specified in Section 10.4.6. The security properties of this 1123 additional security are discussed in Section 15.4.1. The home 1124 init cookie from the mobile node is returned in the Home Test 1125 message, to ensure that the message comes from a node on the route 1126 between the home agent and the correspondent node. The home nonce 1127 index is delivered to the mobile node to later allow the 1128 correspondent node to efficiently find the nonce value that it 1129 used in creating the home keygen token. 1131 Care-of Test 1133 This message is sent in response to a Care-of Test Init message. 1134 The contents of the message are: 1136 * Source Address = correspondent 1138 * Destination Address = care-of address 1140 * Parameters: 1142 + care-of init cookie 1144 + care-of keygen token 1146 + care-of nonce index 1148 When the correspondent node receives the Care-of Test Init 1149 message, it generates a care-of keygen token as follows: 1151 care-of keygen token := 1152 First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1))) 1154 Here, the final "1" inside the HMAC_SHA1 function is a single 1155 octet containing the hex value 0x01, and is used to distinguish 1156 home and care-of cookies from each other. The keygen token is 1157 formed from the first 64 bits of the MAC, and sent directly to the 1158 mobile node at its care-of address. The care-of init cookie from 1159 the from Care-of Test Init message is returned to ensure that the 1160 message comes from a node on the route to the correspondent node. 1161 The care-of nonce index is provided to identify the nonce used for 1162 the care-of keygen token. The home and care-of nonce indices MAY 1163 be the same, or different, in the Home and Care-of Test messages. 1165 When the mobile node has received both the Home and Care-of Test 1166 messages, the return routability procedure is complete. As a result 1167 of the procedure, the mobile node has the data it needs to send a 1168 Binding Update to the correspondent node. The mobile node hashes the 1169 tokens together to form a 20 octet binding key Kbm: 1171 Kbm = SHA1 (home keygen token | care-of keygen token) 1173 A Binding Update may also be used to delete a previously established 1174 binding (Section 6.1.7). In this case, the care-of keygen token is 1175 not used. Instead, the binding management key is generated as 1176 follows: 1178 Kbm = SHA1(home keygen token) 1180 Note that the correspondent node does not create any state specific 1181 to the mobile node, until it receives the Binding Update from that 1182 mobile node. The correspondent node does not maintain the value for 1183 the binding management key Kbm; it creates Kbm when given the nonce 1184 indices and the mobile node's addresses. 1186 5.2.6 Authorizing Binding Management Messages 1188 After the mobile node has created the binding management key (Kbm), 1189 it can supply a verifiable Binding Update to the correspondent node. 1190 This section provides an overview of this binding procedure. The 1191 below figure shows the message flow. 1193 Mobile node Correspondent node 1194 | | 1195 | Binding Update (BU) | 1196 |---------------------------------------------->| 1197 | (MAC, seq#, nonce indices, care-of address) | 1198 | | 1199 | | 1200 | Binding Acknowledgement (BA) (if sent) | 1201 |<----------------------------------------------| 1202 | (MAC, seq#, status) | 1204 Binding Update 1206 To authorize a Binding Update, the mobile node creates a binding 1207 management key Kbm from the keygen tokens as described in the 1208 previous section. The contents of the Binding Update include the 1209 following: 1211 * Source Address = care-of address 1213 * Destination Address = correspondent 1215 * Parameters: 1217 + home address (within the Home Address destination option if 1218 different from the Source Address) 1220 + sequence number (within the Binding Update message header) 1222 + home nonce index (within the Nonce Indices option) 1224 + care-of nonce index (within the Nonce Indices option) 1226 + HMAC_SHA1 (Kbm, (care-of address | CN address | BU)) 1228 The Binding Update contains a Nonce Indices option, indicating to 1229 the correspondent node which home and care-of nonces to use to 1230 recompute Kbm, the binding management key. The MAC is computed as 1231 described in Section 6.2.7, using the correspondent node's address 1232 as the destination address and the Binding Update message itself 1233 as the Mobility Header Data. Once the correspondent node has 1234 verified the MAC, it can create a Binding Cache entry for the 1235 mobile. 1237 Binding Acknowledgement 1239 The Binding Update is in some cases acknowledged by the 1240 correspondent node. The contents of the message are as follows: 1242 * Source Address = correspondent 1244 * Destination Address = care-of address 1246 * Parameters: 1248 + sequence number (within the Binding Update message header) 1250 + HMAC_SHA1 (Kbm, (care-of address | CN address | BA)) 1252 The Binding Acknowledgement contains the same sequence number as 1253 the Binding Update. The MAC is computed as described in Section 1254 6.2.7, using the correspondent node's address as the destination 1255 address and the message itself as the Mobility Header Data. 1257 Bindings established with correspondent nodes using keys created by 1258 way of the return routability procedure MUST NOT exceed 1259 MAX_RR_BINDING_LIFETIME seconds (see Section 12). 1261 The value in the Source Address field in the IPv6 header carrying the 1262 Binding Update is normally also the care-of address which is used in 1263 the binding. However, a different care-of address MAY be specified 1264 by including an Alternate Care-of Address mobility option in the 1265 Binding Update (see Section 6.2.5). When such a message is sent to 1266 the correspondent node and the return routability procedure is used 1267 as the authorization method, the Care-of Test Init and Care-of Test 1268 messages MUST have been performed for the address in the Alternate 1269 Care-of Address option (not the Source Address). The nonce indices 1270 and MAC value MUST be based on information gained in this test. 1272 Binding Updates may also be sent to delete a previously established 1273 binding. In this case, generation of the binding management key 1274 depends exclusively on the home keygen token and the care-of nonce 1275 index is ignored. 1277 5.2.7 Updating Node Keys and Nonces 1279 Correspondent nodes generate nonces at regular intervals. It is 1280 recommended to keep each nonce (identified by a nonce index) 1281 acceptable for at least MAX_TOKEN_LIFETIME seconds (see Section 12) 1282 after it has been first used in constructing a return routability 1283 message response. However, the correspondent node MUST NOT accept 1284 nonces beyond MAX_NONCE_LIFETIME seconds (see Section 12) after the 1285 first use. As the difference between these two constants is 30 1286 seconds, a convenient way to enforce the above lifetimes is to 1287 generate a new nonce every 30 seconds. The node can then continue to 1288 accept tokens that have been based on the last 8 (MAX_NONCE_LIFETIME 1289 / 30) nonces. This results in tokens being acceptable 1290 MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been 1291 sent to the mobile node, depending on whether the token was sent at 1292 the beginning or end of the first 30 second period. Note that the 1293 correspondent node may also attempt to generate new nonces on demand, 1294 or only if the old nonces have been used. This is possible, as long 1295 as the correspondent node keeps track of how long a time ago the 1296 nonces were used for the first time, and does not generate new nonces 1297 on every return routability request. 1299 Due to resource limitations, rapid deletion of bindings, or reboots 1300 the correspondent node may not in all cases recognize the nonces that 1301 the tokens were based on. If a nonce index is unrecognized, the 1302 correspondent node replies with an an error code in the Binding 1303 Acknowledgement (either 136, 137, or 138 as discussed in Section 1304 6.1.8). The mobile node can then retry the return routability 1305 procedure. 1307 An update of Kcn SHOULD be done at the same time as an update of a 1308 nonce, so that nonce indices can identify both the nonce and the key. 1309 Old Kcn values have to be therefore remembered as long as old nonce 1310 values. 1312 Given that the tokens are normally expected to be usable for 1313 MAX_TOKEN_LIFETIME seconds, the mobile node MAY use them beyond a 1314 single run of the return routability procedure until 1315 MAX_TOKEN_LIFETIME expires. After this the mobile node SHOULD NOT 1316 use the tokens. A fast moving mobile node MAY reuse a recent home 1317 keygen token from a correspondent node when moving to a new location, 1318 and just acquire a new care-of keygen token to show routability in 1319 the new location. 1321 While this does not save the number of round-trips due to the 1322 simultaneous processing of home and care-of return routability tests, 1323 there are fewer messages being exchanged, and a potentially long 1324 round-trip through the home agent is avoided. Consequently, this 1325 optimization is often useful. A mobile node that has multiple home 1326 addresses, MAY also use the same care-of keygen token for Binding 1327 Updates concerning all of these addresses. 1329 5.2.8 Preventing Replay Attacks 1331 The return routability procedure also protects the participants 1332 against replayed Binding Updates through the use of the sequence 1333 number and a MAC. Care must be taken when removing bindings at the 1334 correspondent node, however. Correspondent nodes must retain 1335 bindings and the associated sequence number information at least as 1336 long as the nonces used in the authorization of the binding are still 1337 valid. Alternatively, if memory is very constrained, the 1338 correspondent node MAY invalidate the nonces that were used for the 1339 binding being deleted (or some larger group of nonces that they 1340 belong to). This may, however, impact the ability to accept Binding 1341 Updates from mobile nodes that have recently received keygen tokens. 1342 This alternative is therefore recommended only as a last measure. 1344 5.3 Dynamic Home Agent Address Discovery 1346 No security is required for dynamic home agent address discovery. 1348 5.4 Prefix Discovery 1350 The mobile node and the home agent SHOULD use an IPsec security 1351 association to protect the integrity and authenticity of the Mobile 1352 Prefix Solicitations and Advertisements. Both the mobile nodes and 1353 the home agents SHOULD use the Encapsulating Security Payload (ESP) 1354 header in transport mode with a non-NULL payload authentication 1355 algorithm to provide data origin authentication, connectionless 1356 integrity and optional anti-replay protection. 1358 5.5 Payload Packets 1360 Payload packets exchanged with mobile nodes can be protected in the 1361 usual manner, in the same way as stationary hosts can protect them. 1362 However, Mobile IPv6 introduces the Home Address destination option, 1363 a routing header, and tunneling headers in the payload packets. In 1364 the following we define the security measures taken to protect these, 1365 and to prevent their use in attacks against other parties. 1367 This specification limits the use of the Home Address destination 1368 option to the situation where the correspondent node already has a 1369 Binding Cache entry for the given home address. This avoids the use 1370 of the Home Address option in attacks described in Section 15.1. 1372 Mobile IPv6 uses a Mobile IPv6 specific type of a routing header. 1373 This type provides the necessary functionality but does not open 1374 vulnerabilities discussed in Section 15.1. 1376 Tunnels between the mobile node and the home agent are protected by 1377 ensuring proper use of source addresses, and optional cryptographic 1378 protection. The mobile node verifies that the outer IP address 1379 corresponds to its home agent. The home agent verifies that the 1380 outer IP address corresponds to the current location of the mobile 1381 node (Binding Updates sent to the home agents are secure). The home 1382 agent identifies the mobile node through the source address of the 1383 inner packet. (Typically, this is the home address of the mobile 1384 node, but it can also be a link-local address, as discussed in 1385 Section 10.4.2. To recognize the latter type of addresses, the home 1386 agent requires that the Link-Local Address Compatibility (L) was set 1387 in the Binding Update.) These measures protect the tunnels against 1388 vulnerabilities discussed in Section 15.1. 1390 For traffic tunneled via the home agent, additional IPsec ESP 1391 encapsulation MAY be supported and used. If multicast group 1392 membership control protocols or stateful address autoconfiguration 1393 protocols are supported, payload data protection MUST be supported. 1395 6. New IPv6 Protocol, Message Types, and Destination Option 1397 6.1 Mobility Header 1399 The Mobility Header is an extension header used by mobile nodes, 1400 correspondent nodes, and home agents in all messaging related to the 1401 creation and management of bindings. The subsections within this 1402 section describe the message types that may be sent using the 1403 Mobility Header. 1405 6.1.1 Format 1407 The Mobility Header is identified by a Next Header value of TBD in the immediately preceding header, and has the 1409 following format: 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Payload Proto | Header Len | MH Type | Reserved | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | Checksum | | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1416 | | 1417 . . 1418 . Message Data . 1419 . . 1420 | | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 Payload Proto 1425 8-bit selector. Identifies the type of header immediately 1426 following the Mobility Header. Uses the same values as the IPv6 1427 Next Header field [11]. 1429 This field is intended to be used by a future extension (see 1430 Appendix B.1). Implementations conforming to this specification 1431 SHOULD set the payload protocol type to IPPROTO_NONE (59 decimal). 1433 Header Len 1435 8-bit unsigned integer, representing the length of the Mobility 1436 Header in units of 8 octets, excluding the first 8 octets. 1438 The length of the Mobility Header MUST be a multiple of 8 octets. 1440 MH Type 1442 8-bit selector. Identifies the particular mobility message in 1443 question. Current values are specified in Section 6.1.2 and 1444 onward. An unrecognized MH Type field causes an error indication 1445 to be sent. 1447 Reserved 1449 8-bit field reserved for future use. The value MUST be 1450 initialized to zero by the sender, and MUST be ignored by the 1451 receiver. 1453 Checksum 1455 16-bit unsigned integer. This field contains the checksum of the 1456 Mobility Header. The checksum is calculated from the octet string 1457 consisting of a "pseudo-header" followed by the entire Mobility 1458 Header starting with the Payload Proto field. The checksum is the 1459 16-bit one's complement of the one's complement sum of this 1460 string. 1462 The pseudo-header contains IPv6 header fields, as specified in 1463 Section 8.1 of RFC 2460 [11]. The Next Header value used in the 1464 pseudo-header is TBD . The addresses used 1465 in the pseudo-header are the addresses that appear in the Source 1466 and Destination Address fields in the IPv6 packet carrying the 1467 Mobility Header. Note that the procedures of calculating upper 1468 layer checksums while away from home described in Section 11.3.1 1469 apply even for the Mobility Header. If a mobility message has a 1470 Home Address destination option, then the checksum calculation 1471 uses the home address in this option as the value of the IPv6 1472 Source Address field. The type 2 routing header is treated as 1473 explained in [11]. The Mobility Header is considered as the upper 1474 layer protocol for the purposes of calculating the pseudo-header. 1475 The Upper-Layer Packet Length field in the pseudo-header MUST be 1476 set to the total length of the Mobility Header. For computing the 1477 checksum, the checksum field is set to zero. 1479 Message Data 1481 A variable length field containing the data specific to the 1482 indicated Mobility Header type. 1484 Mobile IPv6 also defines a number of "mobility options" for use 1485 within these messages; if included, any options MUST appear after the 1486 fixed portion of the message data specified in this document. The 1487 presence of such options will be indicated by the Header Len field 1488 within the message. When the Header Len value is greater than the 1489 length required for the message specified here, the remaining octets 1490 are interpreted as mobility options. These options include padding 1491 options that can be used to ensure that other options are aligned 1492 properly, and that the total length of the message is divisible by 8. 1493 The encoding and format of defined options are described in Section 1494 6.2. 1496 Alignment requirements for the Mobility Header are the same as for 1497 any IPv6 protocol Header. That is, they MUST be aligned on an 1498 8-octet boundary. 1500 6.1.2 Binding Refresh Request Message 1502 The Binding Refresh Request (BRR) message requests a mobile node to 1503 update its mobility binding. This message is sent by correspondent 1504 nodes according to the rules in Section 9.5.5. When a mobile node 1505 receives a packet containing a Binding Refresh Request message it 1506 processes the message according to the rules in Section 11.7.4. 1508 The Binding Refresh Request message uses the MH Type value 0. When 1509 this value is indicated in the MH Type field, the format of the 1510 Message Data field in the Mobility Header is as follows: 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Reserved | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | | 1516 . . 1517 . Mobility options . 1518 . . 1519 | | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 Reserved 1524 16-bit field reserved for future use. The value MUST be 1525 initialized to zero by the sender, and MUST be ignored by the 1526 receiver. 1528 Mobility Options 1530 Variable-length field of such length that the complete Mobility 1531 Header is an integer multiple of 8 octets long. This field 1532 contains zero or more TLV-encoded mobility options. The encoding 1533 and format of defined options are described in Section 6.2. The 1534 receiver MUST ignore and skip any options which it does not 1535 understand. 1537 There MAY be additional information, associated with this Binding 1538 Refresh Request message that need not be present in all Binding 1539 Refresh Request messages sent. Mobility options allow future 1540 extensions to the format of the Binding Refresh Request message to 1541 be defined. This specification does not define any options valid 1542 for the Binding Refresh Request message. 1544 If no actual options are present in this message, no padding is 1545 necessary and the Header Len field will be set to 0. 1547 6.1.3 Home Test Init Message 1549 A mobile node uses the Home Test Init (HoTI) message to initiate the 1550 return routability procedure and request a home keygen token from a 1551 correspondent node (see Section 11.6.1). The Home Test Init message 1552 uses the MH Type value 1. When this value is indicated in the MH 1553 Type field, the format of the Message Data field in the Mobility 1554 Header is as follows: 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Reserved | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | | 1560 + Home Init Cookie + 1561 | | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | | 1564 . . 1565 . Mobility Options . 1566 . . 1567 | | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 Reserved 1572 16-bit field reserved for future use. This value MUST be 1573 initialized to zero by the sender, and MUST be ignored by the 1574 receiver. 1576 Home Init Cookie 1578 64-bit field which contains a random value, the home init cookie. 1580 Mobility Options 1582 Variable-length field of such length that the complete Mobility 1583 Header is an integer multiple of 8 octets long. This field 1584 contains zero or more TLV-encoded mobility options. The receiver 1585 MUST ignore and skip any options which it does not understand. 1586 This specification does not define any options valid for the Home 1587 Test Init message. 1589 If no actual options are present in this message, no padding is 1590 necessary and the Header Len field will be set to 1. 1592 This message is tunneled through the home agent when the mobile node 1593 is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel 1594 mode between the home agent and the mobile node. This protection is 1595 indicated by the IPsec security policy database. The protection of 1596 Home Test Init messages is unrelated to the requirement to protect 1597 regular payload traffic, which MAY use such tunnels as well. 1599 6.1.4 Care-of Test Init Message 1601 A mobile node uses the Care-of Test Init (CoTI) message to initiate 1602 the return routability procedure and request a care-of keygen token 1603 from a correspondent node (see Section 11.6.1). The Care-of Test 1604 Init message uses the MH Type value 2. When this value is indicated 1605 in the MH Type field, the format of the Message Data field in the 1606 Mobility Header is as follows: 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Reserved | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | | 1612 + Care-of Init Cookie + 1613 | | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | | 1616 . . 1617 . Mobility Options . 1618 . . 1619 | | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 Reserved 1624 16-bit field reserved for future use. The value MUST be 1625 initialized to zero by the sender, and MUST be ignored by the 1626 receiver. 1628 Care-of Init Cookie 1630 64-bit field which contains a random value, the care-of init 1631 cookie. 1633 Mobility Options 1635 Variable-length field of such length that the complete Mobility 1636 Header is an integer multiple of 8 octets long. This field 1637 contains zero or more TLV-encoded mobility options. The receiver 1638 MUST ignore and skip any options which it does not understand. 1639 This specification does not define any options valid for the 1640 Care-of Test Init message. 1642 If no actual options are present in this message, no padding is 1643 necessary and the Header Len field will be set to 1. 1645 6.1.5 Home Test Message 1647 The Home Test (HoT) message is a response to the Home Test Init 1648 message, and is sent from the correspondent node to the mobile node 1649 (see Section 5.2.5). The Home Test message uses the MH Type value 3. 1650 When this value is indicated in the MH Type field, the format of the 1651 Message Data field in the Mobility Header is as follows: 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Home Nonce Index | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | | 1657 + Home Init Cookie + 1658 | | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | | 1661 + Home Keygen Token + 1662 | | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | | 1665 . . 1666 . Mobility options . 1667 . . 1668 | | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 Home Nonce Index 1673 This field will be echoed back by the mobile node to the 1674 correspondent node in a subsequent Binding Update. 1676 Home Init Cookie 1678 64-bit field which contains the home init cookie. 1680 Home Keygen Token 1682 This field contains the 64 bit home keygen token used in the 1683 return routability procedure. 1685 Mobility Options 1687 Variable-length field of such length that the complete Mobility 1688 Header is an integer multiple of 8 octets long. This field 1689 contains zero or more TLV-encoded mobility options. The receiver 1690 MUST ignore and skip any options which it does not understand. 1691 This specification does not define any options valid for the Home 1692 Test message. 1694 If no actual options are present in this message, no padding is 1695 necessary and the Header Len field will be set to 2. 1697 6.1.6 Care-of Test Message 1699 The Care-of Test (CoT) message is a response to the Care-of Test Init 1700 message, and is sent from the correspondent node to the mobile node 1701 (see Section 11.6.2). The Care-of Test message uses the MH Type 1702 value 4. When this value is indicated in the MH Type field, the 1703 format of the Message Data field in the Mobility Header is as 1704 follows: 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Care-of Nonce Index | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | | 1710 + Care-of Init Cookie + 1711 | | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | | 1714 + Care-of Keygen Token + 1715 | | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | | 1718 . . 1719 . Mobility Options . 1720 . . 1721 | | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 Care-of Nonce Index 1726 This value will be echoed back by the mobile node to the 1727 correspondent node in a subsequent Binding Update. 1729 Care-of Init Cookie 1731 64-bit field which contains the care-of init cookie. 1733 Care-of Keygen Token 1735 This field contains the 64 bit care-of keygen token used in the 1736 return routability procedure. 1738 Mobility Options 1740 Variable-length field of such length that the complete Mobility 1741 Header is an integer multiple of 8 octets long. This field 1742 contains zero or more TLV-encoded mobility options. The receiver 1743 MUST ignore and skip any options which it does not understand. 1744 This specification does not define any options valid for the 1745 Care-of Test message. 1747 If no actual options are present in this message, no padding is 1748 necessary and the Header Len field will be set to 2. 1750 6.1.7 Binding Update Message 1752 The Binding Update (BU) message is used by a mobile node to notify 1753 other nodes of a new care-of address for itself. Binding Updates are 1754 sent as described in Section 11.7.1 and Section 11.7.2. 1756 The Binding Update uses the MH Type value 5. When this value is 1757 indicated in the MH Type field, the format of the Message Data field 1758 in the Mobility Header is as follows: 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | Sequence # | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 |A|H|L|K| Reserved | Lifetime | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | | 1766 . . 1767 . Mobility options . 1768 . . 1769 | | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 Acknowledge (A) 1774 The Acknowledge (A) bit is set by the sending mobile node to 1775 request a Binding Acknowledgement (Section 6.1.8) be returned upon 1776 receipt of the Binding Update. 1778 Home Registration (H) 1780 The Home Registration (H) bit is set by the sending mobile node to 1781 request that the receiving node should act as this node's home 1782 agent. The destination of the packet carrying this message MUST 1783 be that of a router sharing the same subnet prefix as the home 1784 address of the mobile node in the binding. 1786 Link-Local Address Compatibility (L) 1788 The Link-Local Address Compatibility (L) bit is set when the home 1789 address reported by the mobile node has the same interface 1790 identifier as the mobile node's link-local address. 1792 Key Management Mobility Capability (K) 1794 If this bit is cleared, the protocol used for establishing the 1795 IPsec security associations between the mobile node and the home 1796 agent does not survive movements. It may then have to be rerun. 1797 (Note that the IPsec security associations themselves are expected 1798 to survive movements.) If manual IPsec configuration is used, the 1799 bit MUST be set to 1. 1801 This bit is valid only in Binding Updates sent to the home agent, 1802 and MUST be cleared in other Binding Updates. Correspondent nodes 1803 MUST ignore this bit. 1805 Reserved 1807 These fields are unused. They MUST be initialized to zero by the 1808 sender and MUST be ignored by the receiver. 1810 Sequence # 1812 A 16-bit unsigned integer used by the receiving node to sequence 1813 Binding Updates and by the sending node to match a returned 1814 Binding Acknowledgement with this Binding Update. 1816 Lifetime 1818 16-bit unsigned integer. The number of time units remaining 1819 before the binding MUST be considered expired. A value of zero 1820 indicates that the Binding Cache entry for the mobile node MUST be 1821 deleted. (In this case the specified care-of address MUST also be 1822 set equal to the home address.) One time unit is 4 seconds. 1824 Mobility Options 1826 Variable-length field of such length that the complete Mobility 1827 Header is an integer multiple of 8 octets long. This field 1828 contains zero or more TLV-encoded mobility options. The encoding 1829 and format of defined options are described in Section 6.2. The 1830 receiver MUST ignore and skip any options which it does not 1831 understand. 1833 The following options are valid in a Binding Update: 1835 * Binding Authorization Data option 1837 * Nonce Indices option. 1839 * Alternate Care-of Address option 1841 If no options are present in this message, 4 bytes of padding is 1842 necessary and the Header Len field will be set to 1. 1844 The care-of address is specified either by the Source Address field 1845 in the IPv6 header or by the Alternate Care-of Address option, if 1846 present. The care-of address MUST be a unicast routable address. 1847 IPv6 Source Adress MUST be a topologically correct source address. 1848 Binding Updates for a care-of address which is not a unicast routable 1849 address MUST be silently discarded. 1851 The deletion of a binding can be indicated by setting the Lifetime 1852 field to 0 and by setting the care-of address equal to the home 1853 address. In deletion, the generation of the binding management key 1854 depends exclusively on the home keygen token, as explained in Section 1855 5.2.5. (Note that while the senders are required to set both the 1856 Lifetime field to 0 and the care-of address equal to the home 1857 address, Section 9.5.1 rules for receivers are more liberal, and 1858 interprete either condition as a deletion.) 1860 Correspondent nodes SHOULD NOT expire the Binding Cache entry before 1861 the lifetime expires, if any application hosted by the correspondent 1862 node is still likely to require communication with the mobile node. 1863 A Binding Cache entry that is deallocated prematurely might cause 1864 subsequent packets to be dropped from the mobile node, if they 1865 contain the Home Address destination option. This situation is 1866 recoverable, since an Binding Error message is sent to the mobile 1867 node (see Section 6.1.9); however, it causes unnecessary delay in the 1868 communications. 1870 6.1.8 Binding Acknowledgement Message 1871 The Binding Acknowledgement is used to acknowledge receipt of a 1872 Binding Update (Section 6.1.7). This packet is sent as described in 1873 Section 9.5.4 and Section 10.3.1. 1875 The Binding Acknowledgement has the MH Type value 6. When this value 1876 is indicated in the MH Type field, the format of the Message Data 1877 field in the Mobility Header is as follows: 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Status |K| Reserved | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | Sequence # | Lifetime | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | | 1885 . . 1886 . Mobility options . 1887 . . 1888 | | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 Key Management Mobility Capability (K) 1893 If this bit is cleared, the protocol used by the home agent for 1894 establishing the IPsec security associations between the mobile 1895 node and the home agent does not survive movements. It may then 1896 have to be rerun. (Note that the IPsec security associations 1897 themselves are expected to survive movements.) 1899 Correspondent nodes MUST set the K bit to 0. 1901 Reserved 1903 These fields are unused. They MUST be initialized to zero by the 1904 sender and MUST be ignored by the receiver. 1906 Status 1908 8-bit unsigned integer indicating the disposition of the Binding 1909 Update. Values of the Status field less than 128 indicate that 1910 the Binding Update was accepted by the receiving node. Values 1911 greater than or equal to 128 indicate that the Binding Update was 1912 rejected by the receiving node. The following Status values are 1913 currently defined: 1915 0 Binding Update accepted 1916 1 Accepted but prefix discovery necessary 1918 128 Reason unspecified 1920 129 Administratively prohibited 1922 130 Insufficient resources 1924 131 Home registration not supported 1926 132 Not home subnet 1928 133 Not home agent for this mobile node 1930 134 Duplicate Address Detection failed 1932 135 Sequence number out of window 1934 136 Expired home nonce index 1936 137 Expired care-of nonce index 1938 138 Expired nonces 1940 Up-to-date values of the Status field are to be specified in the 1941 IANA registry of assigned numbers [19]. 1943 Sequence # 1945 The Sequence Number in the Binding Acknowledgement is copied from 1946 the Sequence Number field in the Binding Update. It is used by 1947 the mobile node in matching this Binding Acknowledgement with an 1948 outstanding Binding Update. 1950 Lifetime 1952 The granted lifetime, in time units of 4 seconds, for which this 1953 node SHOULD retain the entry for this mobile node in its Binding 1954 Cache. 1956 The value of this field is undefined if the Status field indicates 1957 that the Binding Update was rejected. 1959 Mobility Options 1961 Variable-length field of such length that the complete Mobility 1962 Header is an integer multiple of 8 octets long. This field 1963 contains zero or more TLV-encoded mobility options. The encoding 1964 and format of defined options are described in Section 6.2. The 1965 receiver MUST ignore and skip any options which it does not 1966 understand. 1968 There MAY be additional information, associated with this Binding 1969 Acknowledgement that need not be present in all Binding 1970 Acknowledgements sent. Mobility options allow future extensions 1971 to the format of the Binding Acknowledgement to be defined. The 1972 following options are valid for the Binding Acknowledgement: 1974 * Binding Authorization Data option 1976 * Binding Refresh Advice option 1978 If no options are present in this message, 4 bytes of padding is 1979 necessary and the Header Len field will be set to 1. 1981 6.1.9 Binding Error Message 1983 The Binding Error (BE) message is used by the correspondent node to 1984 signal an error related to mobility, such as an inappropriate attempt 1985 to use the Home Address destination option without an existing 1986 binding; see Section 9.3.3 for details. 1988 The Binding Error message uses the MH Type value 7. When this value 1989 is indicated in the MH Type field, the format of the Message Data 1990 field in the Mobility Header is as follows: 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Status | Reserved | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | | 1996 + + 1997 | | 1998 + Home Address + 1999 | | 2000 + + 2001 | | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 . . 2004 . Mobility Options . 2005 . . 2006 | | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 Status 2011 8-bit unsigned integer indicating the reason for this message. 2012 The following values are currently defined: 2014 1 Unknown binding for Home Address destination option 2016 2 Unrecognized MH Type value 2018 Reserved 2020 A 8-bit field reserved for future use. The value MUST be 2021 initialized to zero by the sender, and MUST be ignored by the 2022 receiver. 2024 Home Address 2026 The home address that was contained in the Home Address 2027 destination option. The mobile node uses this information to 2028 determine which binding does not exist, in cases where the mobile 2029 node has several home addresses. 2031 Mobility Options 2033 Variable-length field of such length that the complete Mobility 2034 Header is an integer multiple of 8 octets long. This field 2035 contains zero or more TLV-encoded mobility options. The receiver 2036 MUST ignore and skip any options which it does not understand. 2038 There MAY be additional information, associated with this Binding 2039 Error message that need not be present in all Binding Error 2040 messages sent. Mobility options allow future extensions to the 2041 format of the format of the Binding Error message to be defined. 2042 The encoding and format of defined options are described in 2043 Section 6.2. This specification does not define any options valid 2044 for the Binding Error message. 2046 If no actual options are present in this message, no padding is 2047 necessary and the Header Len field will be set to 2. 2049 6.2 Mobility Options 2051 Mobility messages can include zero or more mobility options. This 2052 allows optional fields that may not be needed in every use of a 2053 particular Mobility Header, as well as future extensions to the 2054 format of the messages. Such options are included in the Message 2055 Data field of the message itself, after the fixed portion of the 2056 message data specified in the message subsections of Section 6.1. 2058 The presence of such options will be indicated by the Header Len of 2059 the Mobility Header. If included, the Binding Authorization Data 2060 option (Section 6.2.7) MUST be the last option and MUST NOT have 2061 trailing padding. Otherwise, options can be placed in any order. 2063 6.2.1 Format 2065 Mobility options are encoded within the remaining space of the 2066 Message Data field of a mobility message, using a type-length-value 2067 (TLV) format as follows: 2069 0 1 2 3 2070 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 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Option Type | Option Length | Option Data... 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 Option Type 2077 8-bit identifier of the type of mobility option. When processing 2078 a Mobility Header containing an option for which the Option Type 2079 value is not recognized by the receiver, the receiver MUST quietly 2080 ignore and skip over the option, correctly handling any remaining 2081 options in the message. 2083 Option Length 2085 8-bit unsigned integer, representing the length in octets of the 2086 mobility option, not including the Option Type and Option Length 2087 fields. 2089 Option Data 2091 A variable length field that contains data specific to the option. 2093 The following subsections specify the Option types which are 2094 currently defined for use in the Mobility Header. 2096 Implementations MUST silently ignore any mobility options that they 2097 do not understand. 2099 Mobility options may have alignment requirements. Following the 2100 convention in IPv6, these options are aligned in a packet so that 2101 multi-octet values within the Option Data field of each option fall 2102 on natural boundaries (i.e., fields of width n octets are placed at 2103 an integer multiple of n octets from the start of the header, for n = 2104 1, 2, 4, or 8) [11]. 2106 6.2.2 Pad1 2108 The Pad1 option does not have any alignment requirements. Its format 2109 is as follows: 2111 0 2112 0 1 2 3 4 5 6 7 2113 +-+-+-+-+-+-+-+-+ 2114 | Type = 0 | 2115 +-+-+-+-+-+-+-+-+ 2117 NOTE! the format of the Pad1 option is a special case - it has 2118 neither Option Length nor Option Data fields. 2120 The Pad1 option is used to insert one octet of padding in the 2121 Mobility Options area of a Mobility Header. If more than one octet 2122 of padding is required, the PadN option, described next, should be 2123 used rather than multiple Pad1 options. 2125 6.2.3 PadN 2127 The PadN option does not have any alignment requirements. Its format 2128 is as follows: 2130 0 1 2131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2133 | Type = 1 | Option Length | Option Data 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 2136 The PadN option is used to insert two or more octets of padding in 2137 the Mobility Options area of a mobility message. For N octets of 2138 padding, the Option Length field contains the value N-2, and the 2139 Option Data consists of N-2 zero-valued octets. PadN Option data 2140 MUST be ignored by the receiver. 2142 6.2.4 Binding Refresh Advice 2144 The Binding Refresh Advice option has an alignment requirement of 2n. 2145 Its format is as follows: 2147 0 1 2 3 2148 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 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | Type = 2 | Length = 2 | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Refresh Interval | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 The Binding Refresh Advice option is only valid in the Binding 2156 Acknowledgement, and only on Binding Acknowledgements sent from the 2157 mobile node's home agent in reply to a home registration. The 2158 Refresh Interval is measured in units of four seconds, and indicates 2159 how long before the mobile node SHOULD send a new home registration 2160 to the home agent. The Refresh Interval MUST be set to indicate a 2161 smaller time interval than the Lifetime value of the Binding 2162 Acknowledgement. 2164 6.2.5 Alternate Care-of Address 2166 The Alternate Care-of Address option has an alignment requirement of 2167 8n+6. Its format is as follows: 2169 0 1 2 3 2170 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 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | Type = 3 | Length = 16 | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | | 2175 + + 2176 | | 2177 + Alternate Care-of Address + 2178 | | 2179 + + 2180 | | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 Normally, a Binding Update specifies the desired care-of address in 2184 the Source Address field of the IPv6 header. However, this is not 2185 possible in some cases, such as when the mobile node wishes to 2186 indicate a care-of address which it can not use as a topologically 2187 correct source address (Section 6.1.7 and Section 11.7.2) or when the 2188 used security mechanism does not protect the IPv6 header (Section 2189 11.7.1). 2191 The Alternate Care-of Address option is provided for these 2192 situations. This option is valid only in Binding Update. The 2193 Alternate Care-of Address field contains an address to use as the 2194 care-of address for the binding, rather than using the Source Address 2195 of the packet as the care-of address. 2197 6.2.6 Nonce Indices 2199 The Nonce Indices option has an alignment requirement of 2n. Its 2200 format is as follows: 2202 0 1 2 3 2203 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 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | Type = 4 | Length = 4 | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Home Nonce Index | Care-of Nonce Index | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 The Nonce Indices option is valid only in the Binding Update message 2211 sent to a correspondent node, and only when present together with a 2212 Binding Authorization Data option. When the correspondent node 2213 authorizes the Binding Update, it needs to produce home and care-of 2214 keygen tokens from its stored random nonce values. 2216 The Home Nonce Index field tells the correspondent node which nonce 2217 value to use when producing the home keygen token. 2219 The Care-of Nonce Index field is ignored in requests to delete a 2220 binding. Otherwise, it tells the correspondent node which nonce 2221 value to use when producing the care-of keygen token. 2223 6.2.7 Binding Authorization Data 2225 The Binding Authorization Data option does not have alignment 2226 requirements as such. However, since this option must be the last 2227 mobility option, an implicit alignment requirement is 8n + 2. The 2228 format of this option is as follows: 2230 0 1 2 3 2231 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 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 | Type = 5 | Option Length | 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 | | 2236 + + 2237 | Authenticator | 2238 + + 2239 | | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 The Binding Authorization Data option is valid in the Binding Update 2243 and Binding Acknowledgement. 2245 The Option Length field contains the length of the authenticator in 2246 octets. 2248 The Authenticator field contains a cryptographic value which can be 2249 used to determine that the message in question comes from the right 2250 authority. Rules for calculating this value depend on the used 2251 authorization procedure. 2253 For the return routability procedure, this option can appear in the 2254 Binding Update and Binding Acknowledgements. Rules for calculating 2255 the Authenticator value are the following: 2257 Mobility Data = care-of address | final dest | Mobility Header Data 2258 Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data)) 2260 Where | denotes concatenation and "final dest" is the IPv6 address of 2261 the final destination of the packet. "Mobility Header Data" is the 2262 content of the Mobility Header, excluding the Authenticator field 2263 itself. The Authenticator value is calculated as if the Checksum 2264 field in the Mobility Header was zero. The Checksum in the 2265 transmitted packet is still calculated in the usual manner, with the 2266 calculated Authenticator being a part of the packet protected by the 2267 Checksum. Kbm is the binding management key, which is typically 2268 created using nonces provided by the correspondent node (see Section 2269 9.4). 2271 The first 96 bits from the MAC result are used as the Authenticator 2272 field. Note that, if the message is sent to a destination which is 2273 itself mobile, the "final dest" address may not be the address found 2274 in the Destination Address field of the IPv6 header; instead the home 2275 address from the Home Address destination option should be used. 2277 6.3 Home Address Option 2279 The Home Address option is carried by the Destination Option 2280 extension header (Next Header value = 60). It is used in a packet 2281 sent by a mobile node while away from home, to inform the recipient 2282 of the mobile node's home address. 2284 The Home Address option is encoded in type-length-value (TLV) format 2285 as follows: 2287 0 1 2 3 2288 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 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | Option Type | Option Length | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | | 2293 + + 2294 | | 2295 + Home Address + 2296 | | 2297 + + 2298 | | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 Option Type 2303 201 = 0xC9 2305 Option Length 2307 8-bit unsigned integer. Length of the option, in octets, 2308 excluding the Option Type and Option Length fields. This field 2309 MUST be set to 16. 2311 Home Address 2313 The home address of the mobile node sending the packet. This 2314 address MUST be a unicast routable address. 2316 The alignment requirement [11] for the Home Address option is 8n+6. 2318 The three highest-order bits of the Option Type field are encoded to 2319 indicate specific processing of the option [11]; for the Home Address 2320 option, these three bits are set to 110. This indicates the 2321 following processing requirements: 2323 o Any IPv6 node that does not recognize the Option Type must discard 2324 the packet. 2326 o If the packet's Destination Address was not a multicast address, 2327 return an ICMP Parameter Problem, Code 2, message to the packet's 2328 Source Address; otherwise, for multicast addresses, the ICMP 2329 message MUST NOT be sent. 2331 o The data within the option cannot change en-route to the packet's 2332 final destination. 2334 The Home Address option MUST be placed as follows: 2336 o After the routing header, if that header is present 2338 o Before the Fragment Header, if that header is present 2340 o Before the AH Header or ESP Header, if either one of those headers 2341 is present 2343 For each IPv6 packet header, the Home Address Option MUST NOT appear 2344 more than once. However, an encapsulated packet [15] MAY contain a 2345 separate Home Address option associated with each encapsulating IP 2346 header. 2348 The inclusion of a Home Address destination option in a packet 2349 affects the receiving node's processing of only this single packet. 2350 No state is created or modified in the receiving node as a result of 2351 receiving a Home Address option in a packet. In particular, the 2352 presence of a Home Address option in a received packet MUST NOT alter 2353 the contents of the receiver's Binding Cache and MUST NOT cause any 2354 changes in the routing of subsequent packets sent by this receiving 2355 node. 2357 6.4 Type 2 Routing Header 2359 Mobile IPv6 defines a new routing header variant, the type 2 routing 2360 header, to allow the packet to be routed directly from a 2361 correspondent to the mobile node's care-of address. The mobile 2362 node's care-of address is inserted into the IPv6 Destination Address 2363 field. Once the packet arrives at the care-of address, the mobile 2364 node retrieves its home address from the routing header, and this is 2365 used as the final destination address for the packet. 2367 The new routing header uses a different type than defined for 2368 "regular" IPv6 source routing, enabling firewalls to apply different 2369 rules to source routed packets than to Mobile IPv6. This routing 2370 header type (type 2) is restricted to carry only one IPv6 address. 2371 All IPv6 nodes which process this routing header MUST verify that the 2372 address contained within is the node's own home address in order to 2373 prevent packets from being forwarded outside the node. The IP 2374 address contained in the routing header, since it is the mobile 2375 node's home address, MUST be a unicast routable address. 2376 Furthermore, if the scope of the home address is smaller than the 2377 scope of the care-of address, the mobile node MUST discard the packet 2378 (see Section 4.6). 2380 6.4.1 Format 2382 The type 2 routing header has the following format: 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | Reserved | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | | 2390 + + 2391 | | 2392 + Home Address + 2393 | | 2394 + + 2395 | | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 Next Header 2400 8-bit selector. Identifies the type of header immediately 2401 following the routing header. Uses the same values as the IPv6 2402 Next Header field [11]. 2404 Hdr Ext Len 2406 2 (8-bit unsigned integer); length of the routing header in 2407 8-octet units, not including the first 8 octets 2409 Routing Type 2411 2 (8-bit unsigned integer). 2413 Segments Left 2415 1 (8-bit unsigned integer). 2417 Reserved 2419 32-bit reserved field. The value MUST be initialized to zero by 2420 the sender, and MUST be ignored by the receiver. 2422 Home Address 2424 The Home Address of the destination Mobile Node. 2426 For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments 2427 Left value describes the number of route segments remaining; i.e., 2428 number of explicitly listed intermediate nodes still to be visited 2429 before reaching the final destination. Segments Left MUST be 1. The 2430 ordering rules for extension headers in an IPv6 packet are described 2431 in Section 4.1 of RFC 2460 [11]. The type 2 routing header defined 2432 for Mobile IPv6 follows the same ordering as other routing headers. 2433 If both a type 0 and a type 2 routing header are present, the type 2 2434 routing header should follow the other routing header. A packet 2435 containing such nested encapsulation should be created as if the 2436 inner (type 2) routing header was constructed first and then treated 2437 as an original packet by the outer (type 0) routing header 2438 construction process. 2440 In addition, the general procedures defined by IPv6 for routing 2441 headers suggest that a received routing header MAY be automatically 2442 "reversed" to construct a routing header for use in any response 2443 packets sent by upper-layer protocols, if the received packet is 2444 authenticated [6]. This MUST NOT be done automatically for type 2 2445 routing headers. 2447 6.5 ICMP Home Agent Address Discovery Request Message 2449 The ICMP Home Agent Address Discovery Request message is used by a 2450 mobile node to initiate the dynamic home agent address discovery 2451 mechanism, as described in Section 11.4.1. The mobile node sends the 2452 Home Agent Address Discovery Request message to the Mobile IPv6 2453 Home-Agents anycast address [16] for its own home subnet prefix. 2454 (Note that the currently defined anycast addresses may not work with 2455 all prefix lengths other than those defined in RFC 2373 [3, 33].) 2457 0 1 2 3 2458 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 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 | Type | Code | Checksum | 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | Identifier | Reserved | 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 Type 2467 150 2469 Code 2471 0 2473 Checksum 2475 The ICMP checksum [14]. 2477 Identifier 2479 An identifier to aid in matching Home Agent Address Discovery 2480 Reply messages to this Home Agent Address Discovery Request 2481 message. 2483 Reserved 2485 This field is unused. It MUST be initialized to zero by the 2486 sender and MUST be ignored by the receiver. 2488 The Source Address of the Home Agent Address Discovery Request 2489 message packet is typically one of the mobile node's current care-of 2490 addresses. At the time of performing this dynamic home agent address 2491 discovery procedure, it is likely that the mobile node is not 2492 registered with any home agent. Therefore, neither the nature of the 2493 address nor the identity of the mobile node can be established at 2494 this time. The home agent MUST then return the Home Agent Address 2495 Discovery Reply message directly to the Source Address chosen by the 2496 mobile node. 2498 6.6 ICMP Home Agent Address Discovery Reply Message 2500 The ICMP Home Agent Address Discovery Reply message is used by a home 2501 agent to respond to a mobile node that uses the dynamic home agent 2502 address discovery mechanism, as described in Section 10.5. 2504 0 1 2 3 2505 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 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | Type | Code | Checksum | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | Identifier | Reserved | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | | 2512 + + 2513 . . 2514 . Home Agent Addresses . 2515 . . 2516 + + 2517 | | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 Type 2522 151 2524 Code 2526 0 2528 Checksum 2530 The ICMP checksum [14]. 2532 Identifier 2534 The identifier from the invoking Home Agent Address Discovery 2535 Request message. 2537 Reserved 2539 This field is unused. It MUST be initialized to zero by the 2540 sender and MUST be ignored by the receiver. 2542 Home Agent Addresses 2544 A list of addresses of home agents on the home link for the mobile 2545 node. The number of addresses present in the list is indicated by 2546 the remaining length of the IPv6 packet carrying the Home Agent 2547 Address Discovery Reply message. 2549 6.7 ICMP Mobile Prefix Solicitation Message Format 2551 The ICMP Mobile Prefix Solicitation Message is sent by a mobile node 2552 to its home agent while it is away from home. The purpose of the 2553 message is to solicit a Mobile Prefix Advertisement from the home 2554 agent, which will allow the mobile node to gather prefix information 2555 about its home network. This information can be used to configure 2556 and update home address(es) according to changes in prefix 2557 information supplied by the home agent. 2559 0 1 2 3 2560 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 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | Type | Code | Checksum | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | Identifier | Reserved | 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 IP Fields: 2569 Source Address 2571 The mobile node's care-of address. 2573 Destination Address 2575 The address of the mobile node's home agent. This home agent must 2576 be on the link which the mobile node wishes to learn prefix 2577 information about. 2579 Hop Limit 2581 Set to an initial hop limit value, similarly to any other unicast 2582 packet sent by the mobile node. 2584 Destination Option: 2586 A Home Address destination option MUST be included. 2588 ESP header: 2590 IPsec headers MUST be supported and SHOULD be used as described in 2591 Section 5.4. 2593 ICMP Fields: 2595 Type 2597 152 2599 Code 2601 0 2603 Checksum 2605 The ICMP checksum [14]. 2607 Identifier 2609 An identifier to aid in matching a future Mobile Prefix 2610 Advertisement to this Mobile Prefix Solicitation. 2612 Reserved 2614 This field is unused. It MUST be initialized to zero by the 2615 sender and MUST be ignored by the receiver. 2617 6.8 ICMP Mobile Prefix Advertisement Message Format 2619 A home agent will send a Mobile Prefix Advertisement to a mobile node 2620 to distribute prefix information about the home link while the mobile 2621 node is traveling away from the home network. This will occur in 2622 response to a Mobile Prefix Solicitation with an Advertisement, or by 2623 an unsolicited Advertisement sent according to the rules in Section 2624 10.6. 2626 0 1 2 3 2627 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 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 | Type | Code | Checksum | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 | Identifier |M|O| Reserved | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Options ... 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 IP Fields: 2638 Source Address 2640 The home agent's address as the mobile node would expect to see it 2641 (i.e., same network prefix). 2643 Destination Address 2645 If this message is a response to a Mobile Prefix Solicitation, 2646 this field contains the Source Address field from that packet. 2647 For unsolicited messages, the mobile node's care-of address SHOULD 2648 be used. Note that unsolicited messages can only be sent if the 2649 mobile node is currently registered with the home agent. 2651 Routing header: 2653 A type 2 routing header MUST be included. 2655 ESP header: 2657 IPsec headers MUST be supported and SHOULD be used as described in 2658 Section 5.4. 2660 ICMP Fields: 2662 Type 2664 153 2666 Code 2668 0 2670 Checksum 2672 The ICMP checksum [14]. 2674 Identifier 2676 An identifier to aid in matching this Mobile Prefix Advertisement 2677 to a previous Mobile Prefix Solicitation. 2679 M 2681 1-bit Managed Address Configuration flag. When set, hosts use the 2682 administered (stateful) protocol for address autoconfiguration in 2683 addition to any addresses autoconfigured using stateless address 2684 autoconfiguration. The use of this flag is described in [12, 13]. 2686 O 2688 1-bit Other Stateful Configuration flag. When set, hosts use the 2689 administered (stateful) protocol for autoconfiguration of other 2690 (non-address) information. The use of this flag is described in 2691 [12, 13]. 2693 Reserved 2695 This field is unused. It MUST be initialized to zero by the 2696 sender and MUST be ignored by the receiver. 2698 Options: 2700 Prefix Information 2702 Each message contains one or more Prefix Information options. 2703 Each option carries the prefix(es) that the mobile node should use 2704 to configure its home address(es). Section 10.6 describes which 2705 prefixes should be advertised to the mobile node. 2707 The Prefix Information option is defined in Section 4.6.2 of RFC 2708 2461 [12], with modifications defined in Section 7.2 of this 2709 specification. The home agent MUST use this modified Prefix 2710 Information option to send the aggregate list of home network 2711 prefixes as defined in Section 10.6.1. 2713 Future versions of this protocol may define new option types. Mobile 2714 nodes MUST silently ignore any options they do not recognize and 2715 continue processing the message. 2717 If the Advertisement is sent in response to a Mobile Prefix 2718 Solicitation, the home agent MUST copy the Identifier value from that 2719 message into the Identifier field of the Advertisement. 2721 The home agent MUST NOT send more than one Mobile Prefix 2722 Advertisement message per second to any mobile node. 2724 The M and O bits MUST be cleared if the Home Agent DHCPv6 support is 2725 not provided. If such support is provided then they are set in 2726 concert with the home network's administrative settings. 2728 7. Modifications to IPv6 Neighbor Discovery 2730 7.1 Modified Router Advertisement Message Format 2732 Mobile IPv6 modifies the format of the Router Advertisement message 2733 [12] by the addition of a single flag bit to indicate that the router 2734 sending the Advertisement message is serving as a home agent on this 2735 link. The format of the Router Advertisement message is as follows: 2737 0 1 2 3 2738 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 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | Type | Code | Checksum | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | Reachable Time | 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 | Retrans Timer | 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 | Options ... 2749 +-+-+-+-+-+-+-+-+-+-+-+- 2751 This format represents the following changes over that originally 2752 specified for Neighbor Discovery [12]: 2754 Home Agent (H) 2756 The Home Agent (H) bit is set in a Router Advertisement to 2757 indicate that the router sending this Router Advertisement is also 2758 functioning as a Mobile IPv6 home agent on this link. 2760 Reserved 2762 Reduced from a 6-bit field to a 5-bit field to account for the 2763 addition of the above bit. 2765 7.2 Modified Prefix Information Option Format 2767 Mobile IPv6 requires knowledge of a router's global address in 2768 building a Home Agents List as part of the dynamic home agent address 2769 discovery mechanism. 2771 However, Neighbor Discovery [12] only advertises a router's 2772 link-local address, by requiring this address to be used as the IP 2773 Source Address of each Router Advertisement. 2775 Mobile IPv6 extends Neighbor Discovery to allow a router to advertise 2776 its global address, by the addition of a single flag bit in the 2777 format of a Prefix Information option for use in Router Advertisement 2778 messages. The format of the Prefix Information option is as follows: 2780 0 1 2 3 2781 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 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Type | Length | Prefix Length |L|A|R|Reserved1| 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | Valid Lifetime | 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 | Preferred Lifetime | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | Reserved2 | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | | 2792 + + 2793 | | 2794 + Prefix + 2795 | | 2796 + + 2797 | | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 This format represents the following changes over that originally 2801 specified for Neighbor Discovery [12]: 2803 Router Address (R) 2805 1-bit router address flag. When set, indicates that the Prefix 2806 field contains a complete IP address assigned to the sending 2807 router. The indicated prefix is the first Prefix Length bits of 2808 the Prefix field. The router IP address has the same scope and 2809 conforms to the same lifetime values as the advertised prefix. 2810 This use of the Prefix field is compatible with its use in 2811 advertising the prefix itself, since Prefix Advertisement uses 2812 only the leading bits. Interpretation of this flag bit is thus 2813 independent of the processing required for the On-Link (L) and 2814 Autonomous Address-Configuration (A) flag bits. 2816 Reserved1 2818 Reduced from a 6-bit field to a 5-bit field to account for the 2819 addition of the above bit. 2821 In a Router Advertisement, a home agent MUST, and all other routers 2822 MAY, include at least one Prefix Information option with the Router 2823 Address (R) bit set. Neighbor Discovery specifies that, if including 2824 all options in a Router Advertisement causes the size of the 2825 Advertisement to exceed the link MTU, multiple Advertisements can be 2826 sent, each containing a subset of the options [12]. In this case, at 2827 least one (not all) of these multiple Advertisements being sent needs 2828 to satisfy the above requirement. 2830 7.3 New Advertisement Interval Option Format 2832 Mobile IPv6 defines a new Advertisement Interval option, used in 2833 Router Advertisement messages to advertise the interval at which the 2834 sending router sends unsolicited multicast Router Advertisements. 2835 The format of the Advertisement Interval option is as follows: 2837 0 1 2 3 2838 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 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 | Type | Length | Reserved | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | Advertisement Interval | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 Type 2847 7 2849 Length 2851 8-bit unsigned integer. The length of the option (including the 2852 type and length fields) in units of 8 octets. The value of this 2853 field MUST be 1. 2855 Reserved 2857 This field is unused. It MUST be initialized to zero by the 2858 sender and MUST be ignored by the receiver. 2860 Advertisement Interval 2862 32-bit unsigned integer. The maximum time, in milliseconds, 2863 between successive unsolicited router Router Advertisement 2864 messages sent by this router on this network interface. Using the 2865 conceptual router configuration variables defined by Neighbor 2866 Discovery [12], this field MUST be equal to the value 2867 MaxRtrAdvInterval, expressed in milliseconds. 2869 Routers MAY include this option in their Router Advertisements. A 2870 mobile node receiving a Router Advertisement containing this option 2871 SHOULD utilize the specified Advertisement Interval for that router 2872 in its movement detection algorithm, as described in Section 11.5.1. 2874 This option MUST be silently ignored for other Neighbor Discovery 2875 messages. 2877 7.4 New Home Agent Information Option Format 2879 Mobile IPv6 defines a new Home Agent Information option, used in 2880 Router Advertisements sent by a home agent to advertise information 2881 specific to this router's functionality as a home agent. The format 2882 of the Home Agent Information option is as follows: 2884 0 1 2 3 2885 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 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | Type | Length | Reserved | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | Home Agent Preference | Home Agent Lifetime | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 Type 2894 8 2896 Length 2898 8-bit unsigned integer. The length of the option (including the 2899 type and length fields) in units of 8 octets. The value of this 2900 field MUST be 1. 2902 Reserved 2904 This field is unused. It MUST be initialized to zero by the 2905 sender and MUST be ignored by the receiver. 2907 Home Agent Preference 2909 16-bit unsigned integer. The preference for the home agent 2910 sending this Router Advertisement, for use in ordering the 2911 addresses returned to a mobile node in the Home Agent Addresses 2912 field of a Home Agent Address Discovery Reply message. Higher 2913 values mean more preferable. If this option is not included in a 2914 Router Advertisement in which the Home Agent (H) bit is set, the 2915 preference value for this home agent MUST be considered to be 0. 2916 Greater values indicate a more preferable home agent than lower 2917 values. 2919 The manual configuration of the Home Agent Preference value is 2920 described in Section 8.4. In addition, the sending home agent MAY 2921 dynamically set the Home Agent Preference value, for example 2922 basing it on the number of mobile nodes it is currently serving or 2923 on its remaining resources for serving additional mobile nodes; 2924 such dynamic settings are beyond the scope of this document. Any 2925 such dynamic setting of the Home Agent Preference, however, MUST 2926 set the preference appropriately, relative to the default Home 2927 Agent Preference value of 0 that may be in use by some home agents 2928 on this link (i.e., a home agent not including a Home Agent 2929 Information option in its Router Advertisements will be considered 2930 to have a Home Agent Preference value of 0). 2932 Home Agent Lifetime 2934 16-bit unsigned integer. The lifetime associated with the home 2935 agent in units of seconds. The default value is the same as the 2936 Router Lifetime, as specified in the main body of the Router 2937 Advertisement. The maximum value corresponds to 18.2 hours. A 2938 value of 0 MUST NOT be used. The Home Agent Lifetime applies only 2939 to this router's usefulness as a home agent; it does not apply to 2940 information contained in other message fields or options. 2942 Home agents MAY include this option in their Router Advertisements. 2943 This option MUST NOT be included in a Router Advertisement in which 2944 the Home Agent (H) bit (see Section 7.1) is not set. If this option 2945 is not included in a Router Advertisement in which the Home Agent (H) 2946 bit is set, the lifetime for this home agent MUST be considered to be 2947 the same as the Router Lifetime in the Router Advertisement. If 2948 multiple Advertisements are being sent instead of a single larger 2949 unsolicited multicast Advertisement, all of the multiple 2950 Advertisements with the Router Address (R) bit set MUST include this 2951 option with the same contents, otherwise this option MUST be omitted 2952 from all Advertisements. 2954 This option MUST be silently ignored for other Neighbor Discovery 2955 messages. 2957 If both the Home Agent Preference and Home Agent Lifetime are set to 2958 their default values specified above, this option SHOULD NOT be 2959 included in the Router Advertisement messages sent by this home 2960 agent. 2962 7.5 Changes to Sending Router Advertisements 2964 The Neighbor Discovery protocol specification [12] limits routers to 2965 a minimum interval of 3 seconds between sending unsolicited multicast 2966 Router Advertisement messages from any given network interface 2967 (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: 2969 "Routers generate Router Advertisements frequently enough that 2970 hosts will learn of their presence within a few minutes, but not 2971 frequently enough to rely on an absence of advertisements to 2972 detect router failure; a separate Neighbor Unreachability 2973 Detection algorithm provides failure detection." 2975 This limitation, however, is not suitable to providing timely 2976 movement detection for mobile nodes. Mobile nodes detect their own 2977 movement by learning the presence of new routers as the mobile node 2978 moves into wireless transmission range of them (or physically 2979 connects to a new wired network), and by learning that previous 2980 routers are no longer reachable. Mobile nodes MUST be able to 2981 quickly detect when they move to a link served by a new router, so 2982 that they can acquire a new care-of address and send Binding Updates 2983 to register this care-of address with their home agent and to notify 2984 correspondent nodes as needed. 2986 One method which can provide for faster movement detection, is to 2987 increase the rate at which unsolicited Router Advertisements are 2988 sent. Mobile IPv6 relaxes this limit such that routers MAY send 2989 unsolicited multicast Router Advertisements more frequently. This 2990 method can be applied where the router is expecting to provide 2991 service to visiting mobile nodes (e.g., wireless network interfaces), 2992 or on which it is serving as a home agent to one or more mobile nodes 2993 (who may return home and need to hear its Advertisements). 2995 Routers supporting mobility SHOULD be able to be configured with a 2996 smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow 2997 sending of unsolicited multicast Router Advertisements more often. 2998 The minimum allowed values are: 3000 o MinRtrAdvInterval 0.03 seconds 3002 o MaxRtrAdvInterval 0.07 seconds 3004 In the case where the minimum intervals and delays are used, the mean 3005 time between unsolicited multicast router advertisements is 50ms. 3006 Use of these modified limits MUST be configurable (see also the 3007 configuration variable MinDelayBetweenRas in Section 13 which may 3008 also have to be modified accordingly). Systems where these values 3009 are available MUST NOT default to them, and SHOULD default to values 3010 specified in RFC 2461. Knowledge of the type of network interface 3011 and operating environment SHOULD be taken into account in configuring 3012 these limits for each network interface. This is important with some 3013 wireless links, where increasing the frequency of multicast beacons 3014 can cause considerable overhead. Routers SHOULD adhere to the 3015 intervals specified in RFC 2461 [12], if this overhead is likely to 3016 cause service degradation. 3018 Additionally, the possible low values of MaxRtrAdvInterval may cause 3019 some problems with movement detection in some mobile nodes. To 3020 ensure that this is not a problem, Routers SHOULD add 20ms to any 3021 Advertisement Intervals sent in RAs, which are below 200 ms, in order 3022 to account for scheduling granularities on both the MN and the 3023 Router. 3025 Note that multicast Router Advertisements are not always required in 3026 certain wireless networks that have limited bandwidth. Mobility 3027 detection or link changes in such networks may be done at lower 3028 layers. Router advertisements in such networks SHOULD be sent only 3029 when solicited. In such networks it SHOULD be possible to disable 3030 unsolicited multicast Router Advertisements on specific interfaces. 3031 The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set 3032 to some high values. 3034 When sending unsolicited multicast Router Advertisements more 3035 frequently than the limit specified in RFC 2461 [12], the sending 3036 router need not include all options in each of these Advertisements, 3037 but it SHOULD include at least one Prefix Information option with the 3038 Router Address (R) bit set (Section 7.2) in each. 3040 Home agents MUST include the Source Link-Layer Address option in all 3041 Router Advertisements they send. This simplifies the process of 3042 returning home, as discussed in Section 11.5.4. 3044 7.6 Changes to Duplicate Address Detection 3046 Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to 3047 stop using the address and wait for reconfiguration. In addition, if 3048 the failed address was a link-local address formed from an interface 3049 identifier, the interface should be disabled. 3051 Mobile nodes that wish to avoid this situation MAY use temporary 3052 link-local addresses as follows. The mobile node SHOULD generate a 3053 random interface identifier and use it for assigning itself a 3054 link-local address. In order to do this, the mobile node applies to 3055 the link-local address the procedure described in RFC 3041 [18] for 3056 global addresses. At most 5 consecutive attempts SHOULD be performed 3057 to generate such addresses and test them through Duplicate Address 3058 Detection. If after these attempts no unique address was found, the 3059 mobile node SHOULD log a system error and give up attempting to find 3060 a link-local address on that interface, until the node moves to a new 3061 link. 3063 8. Requirements for Types of IPv6 Nodes 3065 Mobile IPv6 places some special requirements on the functions 3066 provided by different types of IPv6 nodes. This section summarizes 3067 those requirements, identifying the functionality each requirement is 3068 intended to support. 3070 The requirements are set for the following groups of nodes: 3072 o All IPv6 nodes. 3074 o All IPv6 nodes with support for route optimization. 3076 o All IPv6 routers. 3078 o All Mobile IPv6 home agents. 3080 o All Mobile IPv6 mobile nodes. 3082 It is outside the scope of this specification to specify which of 3083 these groups are mandatory in IPv6. We only describe what is 3084 mandatory for a node that supports, for instance, route optimization. 3085 Other specifications are expected to define the extent of IPv6. 3087 8.1 All IPv6 Nodes 3089 Any IPv6 node may at any time be a correspondent node of a mobile 3090 node, either sending a packet to a mobile node or receiving a packet 3091 from a mobile node. There are no Mobile IPv6 specific MUST 3092 requirements for such nodes, and basic IPv6 techniques are 3093 sufficient. If a mobile node attempts to set up route optimization 3094 with a node with only basic IPv6 support, an ICMP error will signal 3095 that the node does not support such optimizations (Section 11.3.5), 3096 and communications will flow through the home agent . 3098 8.2 IPv6 Nodes with Support for Route Optimization 3100 Nodes that implement route optimization are a subset of all IPv6 3101 nodes on the Internet. The ability of a correspondent node to 3102 participate in route optimization is essential for the efficient 3103 operation of the IPv6 Internet, for the following reasons: 3105 o Avoidance of congestion in the home network, and enabling the use 3106 of lower-performance home agent equipment even for supporting 3107 thousands of mobile nodes. 3109 o Reduced network load across the entire Internet, as mobile devices 3110 begin to predominate. 3112 o Reduction of jitter and latency for the communications. 3114 o Greater likelihood of success for QoS signaling as tunneling is 3115 avoided and, again, fewer sources of congestion. 3117 o Improved robustness against network partitions, congestion, and 3118 other problems, since fewer routing path segments are traversed. 3120 These effects combine to enable much better performance and 3121 robustness for communications between mobile nodes and IPv6 3122 correspondent nodes. Route optimization introduces a small amount of 3123 additional state for the peers, some additional messaging, and upto 3124 1.5 roundtrip delays before it can be turned on. However, it is 3125 believed that the benefits far outweight the costs in most cases. 3126 Section 11.3.1 discusses how mobile nodes may avoid route 3127 optimization for some of the remaining cases, such as very short-term 3128 communications. 3130 The following requirements apply to all correspondent nodes that 3131 support route optimization: 3133 o The node MUST be able validate a Home Address option using an 3134 existing Binding Cache entry, as described in Section 9.3.1. 3136 o The node MUST be able to insert a type 2 routing header into 3137 packets to be sent to a mobile node, as described in Section 3138 9.3.2. 3140 o Unless the correspondent node is also acting as a mobile node, it 3141 MUST ignore type 2 routing headers and drop all packets that it 3142 has received with such headers. 3144 o The node SHOULD be able to interpret ICMP messages as described in 3145 Section 9.3.4. 3147 o The node MUST be able to send Binding Error messages as described 3148 in Section 9.3.3. 3150 o The node MUST be able to process Mobility Headers as described in 3151 Section 9.2. 3153 o The node MUST be able to participate in a return routability 3154 procedure (Section 9.4). 3156 o The node MUST be able to process Binding Update messages (Section 3157 9.5). 3159 o The node MUST be able to return a Binding Acknowledgement (Section 3160 9.5.4). 3162 o The node MUST be able to maintain a Binding Cache of the bindings 3163 received in accepted Binding Updates, as described in Section 9.1 3164 and Section 9.6. 3166 o The node MUST allow route optimization to be administratively 3167 enabled or disabled. The default SHOULD be enabled. 3169 8.3 All IPv6 Routers 3171 All IPv6 routers, even those not serving as a home agent for Mobile 3172 IPv6, have an effect on how well mobile nodes can communicate: 3174 o Every IPv6 router SHOULD be able to send an Advertisement Interval 3175 option (Section 7.3) in each of its Router Advertisements [12], to 3176 aid movement detection by mobile nodes (as in Section 11.5.1). 3177 The use of this option in Router Advertisements SHOULD be 3178 configurable. 3180 o Every IPv6 router SHOULD be able to support sending unsolicited 3181 multicast Router Advertisements at the faster rate described in 3182 Section 7.5. If the router supports a faster rate, the used rate 3183 MUST be configurable. 3185 o Each router SHOULD include at least one prefix with the Router 3186 Address (R) bit set and with its full IP address in its Router 3187 Advertisements (as described in Section 7.2). 3189 o Routers supporting filtering packets with routing headers SHOULD 3190 support different rules for type 0 and type 2 routing headers (see 3191 Section 6.4) so that filtering of source routed packets (type 0) 3192 will not necessarily limit Mobile IPv6 traffic which is delivered 3193 via type 2 routing headers. 3195 8.4 IPv6 Home Agents 3197 In order for a mobile node to operate correctly while away from home, 3198 at least one IPv6 router on the mobile node's home link must function 3199 as a home agent for the mobile node. The following additional 3200 requirements apply to all IPv6 routers that serve as a home agent: 3202 o Every home agent MUST be able to maintain an entry in its Binding 3203 Cache for each mobile node for which it is serving as the home 3204 agent (Section 10.1 and Section 10.3.1). 3206 o Every home agent MUST be able to intercept packets (using proxy 3207 Neighbor Discovery [12]) addressed to a mobile node for which it 3208 is currently serving as the home agent, on that mobile node's home 3209 link, while the mobile node is away from home (Section 10.4.1). 3211 o Every home agent MUST be able to encapsulate [15] such intercepted 3212 packets in order to tunnel them to the primary care-of address for 3213 the mobile node indicated in its binding in the home agent's 3214 Binding Cache (Section 10.4.2). 3216 o Every home agent MUST support decapsulating [15] reverse tunneled 3217 packets sent to it from a mobile node's home address. Every home 3218 agent MUST also check that the source address in the tunneled 3219 packets corresponds to the currently registered location of the 3220 mobile node (Section 10.4.5). 3222 o The node MUST be able to process Mobility Headers as described in 3223 Section 10.2. 3225 o Every home agent MUST be able to return a Binding Acknowledgement 3226 in response to a Binding Update (Section 10.3.1). 3228 o Every home agent MUST maintain a separate Home Agents List for 3229 each link on which it is serving as a home agent, as described in 3230 Section 10.1 and Section 10.5.1. 3232 o Every home agent MUST be able to accept packets addressed to the 3233 Mobile IPv6 Home-Agents anycast address [16] for the subnet on 3234 which it is serving as a home agent, and MUST be able to 3235 participate in dynamic home agent address discovery (Section 3236 10.5). 3238 o Every home agent SHOULD support a configuration mechanism to allow 3239 a system administrator to manually set the value to be sent by 3240 this home agent in the Home Agent Preference field of the Home 3241 Agent Information Option in Router Advertisements that it sends 3242 (Section 7.4). 3244 o Every home agent SHOULD support sending ICMP Mobile Prefix 3245 Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix 3246 Solicitations (Section 6.7). If supported, this behavior MUST be 3247 configurable, so that home agents can be configured to avoid 3248 sending such Prefix Advertisements according to the needs of the 3249 network administration in the home domain. 3251 o Every home agent MUST support IPsec ESP for protection of packets 3252 belonging to the return routability procedure (Section 10.4.6). 3254 o Every home agent SHOULD support the multicast group membership 3255 control protocols as described in Section 10.4.3. If this support 3256 is provided, the home agent MUST be capable of using it to 3257 determine which multicast data packets to forward via the tunnel 3258 to the mobile node. 3260 o Home agents MAY support stateful address autoconfiguration for 3261 mobile nodes as described in Section 10.4.4. 3263 8.5 IPv6 Mobile Nodes 3265 Finally, the following requirements apply to all IPv6 nodes capable 3266 of functioning as mobile nodes: 3268 o The node MUST maintain a Binding Update List (Section 11.1). 3270 o The node MUST support sending packets containing a Home Address 3271 option (Section 11.3.1), and follow the required IPsec interaction 3272 (Section 11.3.2). 3274 o The node MUST be able to perform IPv6 encapsulation and 3275 decapsulation [15]. 3277 o The node MUST be able to process type 2 routing header as defined 3278 in Section 6.4 and Section 11.3.3. 3280 o The node MUST support receiving a Binding Error message (Section 3281 11.3.6). 3283 o The node MUST support receiving ICMP errors (Section 11.3.5). 3285 o The node MUST support movement detection, care-of address 3286 formation, and returning home (Section 11.5). 3288 o The node MUST be able to process Mobility Headers as described in 3289 Section 11.2. 3291 o The node MUST support the return routability procedure (Section 3292 11.6). 3294 o The node MUST be able to send Binding Updates, as specified in 3295 Section 11.7.1 and Section 11.7.2. 3297 o The node MUST be able to receive and process Binding 3298 Acknowledgements, as specified in Section 11.7.3. 3300 o The node MUST support receiving a Binding Refresh Request (Section 3301 6.1.2), by responding with a Binding Update. 3303 o The node MUST support receiving Mobile Prefix Advertisements 3304 (Section 11.4.3) and reconfiguring its home address based on the 3305 prefix information contained therein. 3307 o The node SHOULD support use of the dynamic home agent address 3308 discovery mechanism, as described in Section 11.4.1. 3310 o The node MUST allow route optimization to be administratively 3311 enabled or disabled. The default SHOULD be enabled. 3313 o The node MAY support the multicast address listener part of a 3314 multicast group membership protocol as described in Section 3315 11.3.4. If this support is provided, the mobile node MUST be able 3316 to receive tunneled multicast packets from the home agent. 3318 o The node MAY support stateful address autoconfiguration mechanisms 3319 such as DHCPv6 [28] on the interface represented by the tunnel to 3320 the home agent. 3322 9. Correspondent Node Operation 3324 9.1 Conceptual Data Structures 3326 IPv6 nodes with route optimization support maintain a Binding Cache 3327 of bindings for other nodes. A separate Binding Cache SHOULD be 3328 maintained by each IPv6 node for each of its unicast routable 3329 addresses. The Binding Cache MAY be implemented in any manner 3330 consistent with the external behavior described in this document, for 3331 example by being combined with the node's Destination Cache as 3332 maintained by Neighbor Discovery [12]. When sending a packet, the 3333 Binding Cache is searched before the Neighbor Discovery conceptual 3334 Destination Cache [12]. That is, any Binding Cache entry for this 3335 destination SHOULD take precedence over any Destination Cache entry 3336 for the same destination. 3338 Each Binding Cache entry conceptually contains the following fields: 3340 o The home address of the mobile node for which this is the Binding 3341 Cache entry. This field is used as the key for searching the 3342 Binding Cache for the destination address of a packet being sent. 3343 If the destination address of the packet matches the home address 3344 in the Binding Cache entry, this entry SHOULD be used in routing 3345 that packet. 3347 o The care-of address for the mobile node indicated by the home 3348 address field in this Binding Cache entry. If the destination 3349 address of a packet being routed by a node matches the home 3350 address in this entry, the packet SHOULD be routed to this care-of 3351 address. This is described in Section 9.3.2 for packets 3352 originated by this node. 3354 o A lifetime value, indicating the remaining lifetime for this 3355 Binding Cache entry. The lifetime value is initialized from the 3356 Lifetime field in the Binding Update that created or last modified 3357 this Binding Cache entry. Once the lifetime of this entry 3358 expires, the entry MUST be deleted from the Binding Cache. 3360 o A flag indicating whether or not this Binding Cache entry is a 3361 home registration entry (applicable only on nodes which support 3362 home agent functionality). 3364 o The maximum value of the Sequence Number field received in 3365 previous Binding Updates for this mobile node home address. The 3366 Sequence Number field is 16 bits long. Sequence Number values 3367 MUST be compared modulo 2**16 as explained in Section 9.5.1. 3369 o Usage information for this Binding Cache entry. This is needed to 3370 implement the cache replacement policy in use in the Binding 3371 Cache. Recent use of a cache entry also serves as an indication 3372 that a Binding Refresh Request should be sent when the lifetime of 3373 this entry nears expiration. 3375 Binding Cache entries not marked as home registrations MAY be 3376 replaced at any time by any reasonable local cache replacement policy 3377 but SHOULD NOT be unnecessarily deleted. The Binding Cache for any 3378 one of a node's IPv6 addresses may contain at most one entry for each 3379 mobile node home address. The contents of a node's Binding Cache 3380 MUST NOT be changed in response to a Home Address option in a 3381 received packet. 3383 9.2 Processing Mobility Headers 3385 Mobility Header processing MUST observe the following rules: 3387 o The checksum must be verified as per Section 6.1. Otherwise, the 3388 node MUST silently discard the message. 3390 o The MH Type field MUST have a known value (Section 6.1.1). 3391 Otherwise, the node MUST discard the message and issue a Binding 3392 Error message as described in Section 9.3.3, with Status field set 3393 to 2 (unrecognized MH Type value). 3395 o The Payload Proto field MUST be IPPROTO_NONE (59 decimal). 3396 Otherwise, the node MUST discard the message and SHOULD send ICMP 3397 Parameter Problem [14], Code 0, to the Source Address of the 3398 packet. 3400 o The Header Len field in the Mobility Header MUST NOT be less than 3401 the length specified for this particular type of message in 3402 Section 6.1. Otherwise, the node MUST discard the message and 3403 SHOULD send ICMP Parameter Problem [14], Code 0, to the Source 3404 Address of the packet. 3406 Subsequent checks depend on the particular Mobility Header. 3408 9.3 Packet Processing 3410 This section describes how the correspondent node sends packets to 3411 the mobile node, and receives packets from it. 3413 9.3.1 Receiving Packets with Home Address Option 3415 Packets containing a Home Address option MUST be dropped if the given 3416 home address is not a unicast routable address. 3418 Mobile nodes are expected to include a Home Address destination 3419 option in a packet they believe the correspondent node has a Binding 3420 Cache entry for the home address of a mobile node. Packets 3421 containing a Home Address option MUST be dropped if there is no 3422 corresponding Binding Cache entry. A corresponding Binding Cache 3423 entry MUST have the same home address as appears in the Home Address 3424 destination option, and the currently registered care-of address MUST 3425 be equal to the source address of the packet. These tests MUST NOT 3426 be done for packets that contain a Home Address option and a Binding 3427 Update. 3429 If the packet is dropped due the above tests, the correspondent node 3430 MUST send the Binding Error message as described in Section 9.3.3. 3431 The Status field in this message should be set to 1 (unknown binding 3432 for Home Address destination option). 3434 The correspondent node MUST process the option in a manner consistent 3435 with exchanging the Home Address field from the Home Address option 3436 into the IPv6 header and replacing the original value of the Source 3437 Address field there. After all IPv6 options have been processed, it 3438 MUST be possible for upper layers to process the packet without the 3439 knowledge that it came originally from a care-of address or that a 3440 Home Address option was used. 3442 No additional authentication of the Home Address option is required, 3443 except that if the IPv6 header of a packet is covered by 3444 authentication, then that authentication MUST also cover the Home 3445 Address option; this coverage is achieved automatically by the 3446 definition of the Option Type code for the Home Address option, since 3447 it indicates that the data within the option cannot change en-route 3448 to the packet's final destination, and thus the option is included in 3449 the authentication computation. By requiring that any authentication 3450 of the IPv6 header also cover the Home Address option, the security 3451 of the Source Address field in the IPv6 header is not compromised by 3452 the presence of a Home Address option. 3454 When attempting to verify authentication data in a packet that 3455 contains a Home Address option, the receiving node MUST calculate the 3456 authentication data as if the following were true: The Home Address 3457 option contains the care-of address, and the source IPv6 address 3458 field of the IPv6 header contains the home address. This conforms 3459 with the calculation specified in Section 11.3.2. 3461 9.3.2 Sending Packets to a Mobile Node 3463 Before sending any packet, the sending node SHOULD examine its 3464 Binding Cache for an entry for the destination address to which the 3465 packet is being sent. If the sending node has a Binding Cache entry 3466 for this address, the sending node SHOULD use a type 2 routing header 3467 to route the packet to this mobile node (the destination node) by way 3468 of its care-of address. When calculating authentication data in a 3469 packet that contains a type 2 routing header, the correspondent node 3470 MUST calculate the authentication data as if the following were true: 3471 The routing header contains the care-of address, the destination IPv6 3472 address field of the IPv6 header contains the home address, and the 3473 Segments Left field is zero. The IPsec Security Policy Database 3474 lookup MUST based on the mobile node's home address. 3476 For instance, assuming there are no additional routing headers in 3477 this packet beyond those needed by Mobile IPv6, the correspondent 3478 node could set the fields in the packet's IPv6 header and routing 3479 header as follows: 3481 o The Destination Address in the packet's IPv6 header is set to the 3482 mobile node's home address (the original destination address to 3483 which the packet was being sent). 3485 o The routing header is initialized to contain a single route 3486 segment, containing the mobile node's care-of address copied from 3487 the Binding Cache entry. The Segments Left field is, however, 3488 temporarily set to zero. 3490 The IP layer will insert the routing header before performing any 3491 necessary IPsec processing. Once all IPsec processing has been 3492 performed, the node swaps the IPv6 destination field with the Home 3493 Address field in the routing header, sets the Segments Left field to 3494 one, and sends the packet. This ensures the AH calculation is done 3495 on the packet in the form it will have on the receiver after 3496 advancing the routing header. 3498 Following the definition of a type 2 routing header in Section 6.4, 3499 this packet will be routed to the mobile node's care-of address, 3500 where it will be delivered to the mobile node (the mobile node has 3501 associated the care-of address with its network interface). 3503 Note that following the above conceptual model in an implementation 3504 creates some additional requirements for path MTU discovery since the 3505 layer that decides the packet size (e.g., TCP and applications using 3506 UDP) needs to be aware of the size of the headers added by the IP 3507 layer on the sending node. 3509 If, instead, the sending node has no Binding Cache entry for the 3510 destination address to which the packet is being sent, the sending 3511 node simply sends the packet normally, with no routing header. If 3512 the destination node is not a mobile node (or is a mobile node that 3513 is currently at home), the packet will be delivered directly to this 3514 node and processed normally by it. If, however, the destination node 3515 is a mobile node that is currently away from home, the packet will be 3516 intercepted by the mobile node's home agent and tunneled to the 3517 mobile node's current primary care-of address. 3519 9.3.3 Sending Binding Error Messages 3521 Section 9.2 and Section 9.3.1 describe error conditions that lead to 3522 a need to send a Binding Error message. 3524 A Binding Error message is sent to the address that appeared in the 3525 IPv6 Source Address field of the offending packet. If the Source 3526 Address field does not contain a unicast address, the Binding Error 3527 message MUST NOT be sent. 3529 The Home Address field in the Binding Error message MUST be copied 3530 from the Home Address field in the Home Address destination option of 3531 the offending packet, or set to the unspecified address if no such 3532 option appeared in the packet. 3534 Binding Error messages SHOULD be subject to rate limiting in the same 3535 manner as is done for ICMPv6 messages [14]. 3537 9.3.4 Receiving ICMP Error Messages 3539 When the correspondent node has a Binding Cache entry for a mobile 3540 node, all traffic destined to the mobile node goes directly to the 3541 current care-of address of the mobile node using a routing header. 3542 Any ICMP error message caused by packets on their way to the care-of 3543 address will be returned in the normal manner to the correspondent 3544 node. 3546 On the other hand, if the correspondent node has no Binding Cache 3547 entry for the mobile node, the packet will be routed through the 3548 mobile node's home link. Any ICMP error message caused by the packet 3549 on its way to the mobile node while in the tunnel, will be 3550 transmitted to the mobile node's home agent. By the definition of 3551 IPv6 encapsulation [15], the home agent MUST relay certain ICMP error 3552 messages back to the original sender of the packet, which in this 3553 case is the correspondent node. 3555 Thus, in all cases, any meaningful ICMP error messages caused by 3556 packets from a correspondent node to a mobile node will be returned 3557 to the correspondent node. If the correspondent node receives 3558 persistent ICMP Destination Unreachable messages after sending 3559 packets to a mobile node based on an entry in its Binding Cache, the 3560 correspondent node SHOULD delete this Binding Cache entry. 3562 9.4 Return Routability Procedure 3564 This subsection specifies actions taken by a correspondent node 3565 during the return routability procedure. 3567 9.4.1 Receiving Home Test Init Messages 3569 Upon receiving a Home Test Init message, the correspondent node 3570 verifies the following: 3572 o The packet MUST NOT include a Home Address destination option. 3574 Any packet carrying a Home Test Init message which fails to satisfy 3575 all of these tests MUST be silently ignored. 3577 Otherwise, in preparation for sending the corresponding Home Test 3578 Message, the correspondent node checks that it has the necessary 3579 material to engage in a return routability procedure, as specified in 3580 Section 5.2. The correspondent node MUST have a secret Kcn and a 3581 nonce. If it does not have this material yet, it MUST produce it 3582 before continuing with the return routability procedure. 3584 Section 9.4.3 specifies further processing. 3586 9.4.2 Receiving Care-of Test Init Messages 3588 Upon receiving a Care-of Test Init message, the correspondent node 3589 verifies the following: 3591 o The packet MUST NOT include a Home Address destination option. 3593 Any packet carrying a Care-of Test Init message which fails to 3594 satisfy all of these tests MUST be silently ignored. 3596 Otherwise, in preparation for sending the corresponding Care-of Test 3597 Message, the correspondent node checks that it has the necessary 3598 material to engage in a return routability procedure in the manner 3599 described in Section 9.4.1. 3601 Section 9.4.4 specifies further processing. 3603 9.4.3 Sending Home Test Messages 3605 The correspondent node creates a home keygen token and uses the 3606 current nonce index as the Home Nonce Index. It then creates a Home 3607 Test message (Section 6.1.5) and sends it to the mobile node at the 3608 latter's home address. Note that the Home Test message is always 3609 sent to the home address of the mobile node without route 3610 optimization, even when there is an existing binding for the mobile 3611 node. 3613 9.4.4 Sending Care-of Test Messages 3615 The correspondent node creates a care-of nonce and uses the current 3616 nonce index as the Care-of Nonce Index. It then creates a Care-of 3617 Test message (Section 6.1.6) and sends it to the mobile node at the 3618 latter's care-of address. 3620 9.5 Processing Bindings 3622 This section explains how the correspondent node processes messages 3623 related to bindings. These messages are: 3625 o Binding Update 3627 o Binding Refresh Request 3629 o Binding Acknowledgement 3631 o Binding Error 3633 9.5.1 Receiving Binding Updates 3635 Before accepting a Binding Update, the receiving node MUST validate 3636 the Binding Update according to the following tests: 3638 o The packet MUST contain a unicast routable home address, either in 3639 the Home Address option or in the Source Address, if the Home 3640 Address option is not present. 3642 o The Sequence Number field in the Binding Update is greater than 3643 the Sequence Number received in the valid previous Binding Update 3644 for this home address, if any. 3646 This Sequence Number comparison MUST be performed modulo 2**16, 3647 i.e., the number is a free running counter represented modulo 3648 65536. A Sequence Number in a received Binding Update is 3649 considered less than or equal to the last received number if its 3650 value lies in the range of the last received number and the 3651 preceding 32767 values, inclusive. For example, if the last 3652 received sequence number was 15, then messages with sequence 3653 numbers 0 through 15, as well as 32784 through 65535, would be 3654 considered less than or equal. 3656 When the return routability procedure is used to enable the 3657 establishment of nonce indices as inputs to the creation of the 3658 binding key Kbm, the following are also required: 3660 o A Nonce Indices mobility option MUST be present, and the Home and 3661 Care-of Nonce Index values in this option MUST be recent enough to 3662 be recognized by the correspondent node. (Care-of Nonce Index 3663 values are not inspected for requests to delete a binding.) 3665 o The correspondent node MUST re-generate the home keygen token and 3666 the care-of keygen token from the information contained in the 3667 packet. It then generates the binding management key Kbm and uses 3668 it to verify the authenticator field in the Binding Update as 3669 specified in Section 6.1.7. 3671 o The Home Registration (H) bit MUST NOT be set. 3673 When using Kbm for validating the Binding Update, the following are 3674 required: 3676 o The Binding Authorization Data mobility option MUST be present, 3677 and its contents MUST satisfy rules presented in Section 5.2.6. 3678 Note that a care-of address different from the Source Address MAY 3679 have been specified by including an Alternate Care-of Address 3680 mobility option in the Binding Update. When such a message is 3681 received and the return routability procedure is used as an 3682 authorization method, the correspondent node MUST verify the 3683 authenticator by using the address within the Alternate Care-of 3684 Address in the calculations. 3686 o The Binding Authorization Data mobility option MUST be the last 3687 option and MUST NOT have trailing padding. 3689 If the mobile node sends a sequence number which is not greater than 3690 the sequence number from the last successful Binding Update, then the 3691 receiving node MUST send back a Binding Acknowledgement with status 3692 code 135, and the last accepted sequence number in the Sequence 3693 Number field of the Binding Acknowledgement. 3695 If the receiving node no longer recognizes the Home Nonce Index 3696 value, Care-of Nonce Index value, or both values from the Binding 3697 Update, then the receiving node MUST send back a Binding 3698 Acknowledgement with status code 136, 137, or 138, respectively. 3700 For packets carrying Binding Updates that fail to satisfy all of 3701 these tests for any reason other than insufficiency of the Sequence 3702 Number or expired nonce index values MUST be silently discarded. 3704 If the Binding Update is valid according to the tests above, then the 3705 Binding Update is processed further as follows: 3707 o If the Lifetime specified in the Binding Update is nonzero and the 3708 specified care-of address is not equal to the home address for the 3709 binding, then this is a request to cache a binding for the mobile 3710 node. If the Home Registration (H) bit is set in the Binding 3711 Update, the Binding Update is processed according to the procedure 3712 specified in Section 10.3.1; otherwise, it is processed according 3713 to the procedure specified in Section 9.5.2. 3715 o If the Lifetime specified in the Binding Update is zero or the 3716 specified care-of address matches the home address for the 3717 binding, then this is a request to delete the mobile node's cached 3718 binding. In this case, the Binding Update MUST include a valid 3719 home nonce index, and the care-of nonce index MUST be ignored by 3720 the correspondent node. The generation of the binding management 3721 key depends then exclusively on the home keygen token (Section 3722 5.2.5). If the Home Registration (H) bit is set in the Binding 3723 Update, the Binding Update is processed according to the procedure 3724 specified in Section 10.3.2; otherwise, it is processed according 3725 to the procedure specified in Section 9.5.3. 3727 The specified care-of address MUST be determined as follows: 3729 o If the Alternate Care-of Address option is present, the care-of 3730 address is the address in that option. 3732 o Otherwise, the care-of address is the Source Address field in the 3733 packet's IPv6 header. 3735 The home address for the binding MUST be determined as follows: 3737 o If the Home Address destination option is present, the home 3738 address is the address in that option. 3740 o Otherwise, the home address is the Source Address field in the 3741 packet's IPv6 header. This implies that the mobile node is at 3742 home and is about to perform de-registration. 3744 9.5.2 Requests to Cache a Binding 3746 This section describes the processing of a valid Binding Update that 3747 requests a node to cache a mobile node's binding, for which the Home 3748 Registration (H) bit is not set in the Binding Update. 3750 In this case, the receiving node SHOULD create a new entry in its 3751 Binding Cache for this mobile node, or update its existing Binding 3752 Cache entry for this mobile node, if such an entry already exists. 3753 The lifetime for the Binding Cache entry is initialized from the 3754 Lifetime field specified in the Binding Update, although this 3755 lifetime MAY be reduced by the node caching the binding; the lifetime 3756 for the Binding Cache entry MUST NOT be greater than the Lifetime 3757 value specified in the Binding Update. Any Binding Cache entry MUST 3758 be deleted after the expiration of its lifetime. 3760 The Sequence Number value received from a mobile node in a Binding 3761 Update is stored by a correspondent node in its Binding Cache entry 3762 for that mobile node. If the receiving correspondent node has no 3763 Binding Cache entry for the sending mobile node, it MUST accept any 3764 Sequence Number value in a received Binding Update from this mobile 3765 node. 3767 The correspondent node MAY refuse to accept a new Binding Cache 3768 entry, if it does not have sufficient resources. A new entry MAY 3769 also be refused if the correspondent node believes its resources are 3770 utilized more efficiently in some other purpose, such as serving 3771 another mobile node with higher amount of traffic. In both cases the 3772 correspondent node SHOULD return a Binding Acknowledgement with 3773 status value 130. 3775 9.5.3 Requests to Delete a Binding 3777 This section describes the processing of a valid Binding Update that 3778 requests a node to delete a mobile node's binding from its Binding 3779 Cache, for which the Home Registration (H) bit is not set in the 3780 Binding Update. 3782 Any existing binding for the mobile node MUST be deleted. A Binding 3783 Cache entry for the mobile node MUST NOT be created in response to 3784 receiving the Binding Update. 3786 If the Binding Cache entry was created by use of return routability 3787 nonces, the correspondent node MUST ensure that the same nonces are 3788 not used again with the particular home and care-of address. If both 3789 nonces are still valid, the correspondent node has to remember the 3790 particular combination of nonce indexes, addresses, and sequence 3791 number as illegal, until at least one of the nonces has become too 3792 old. 3794 9.5.4 Sending Binding Acknowledgements 3796 A Binding Acknowledgement may be sent to indicate receipt of a 3797 Binding Update as follows: 3799 o If the Binding Update was discarded as described in Section 9.2 or 3800 Section 9.5.1, a Binding Acknowledgement MUST NOT be sent. 3801 Otherwise the treatment depends on the below rules. 3803 o If the Acknowledge (A) bit set is set in the Binding Update, a 3804 Binding Acknowledgement MUST be sent. Otherwise, the treatment 3805 depends on the below rule. 3807 o If the node rejects the Binding Update due to an expired nonce 3808 index, sequence number being out of window (Section 9.5.1), or 3809 insufficiency of resources (Section 9.5.2), a Binding 3810 Acknowledgement MUST be sent. If the node accepts the Binding 3811 Update, the Binding Acknowledgement SHOULD NOT be sent. 3813 If the node accepts the Binding Update and creates or updates an 3814 entry for this binding, the Status field in the Binding 3815 Acknowledgement MUST be set to a value less than 128. Otherwise, the 3816 Status field MUST be set to a value greater than or equal to 128. 3817 Values for the Status field are described in Section 6.1.8 and in the 3818 IANA registry of assigned numbers [19]. 3820 If the Status field in the Binding Acknowledgement contains the value 3821 136 (expired home nonce index), 137 (expired care-of nonce index), or 3822 138 (expired nonces) then the message MUST NOT include the Binding 3823 Authorization Data mobility option. Otherwise, the Binding 3824 Authorization Data mobility option MUST be included, and MUST meet 3825 the specific authentication requirements for Binding Acknowledgements 3826 as defined in Section 5.2. 3828 If the Source Address field of the IPv6 header that carried the 3829 Binding Update does not contain a unicast address, the Binding 3830 Acknowledgement MUST NOT be sent, and the Binding Update packet MUST 3831 be silently discarded. Otherwise, the acknowledgement MUST be sent 3832 to the Source Address. Unlike the treatment of regular packets, this 3833 addressing procedure does not use information from the Binding Cache. 3834 However, a routing header is needed in some cases. If the Source 3835 Address is the home address of the mobile node, i.e., the Binding 3836 Update did not contain a Home Address destination option, then the 3837 Binding Acknowledgement MUST be sent to that address, and the routing 3838 header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST 3839 be sent using a type 2 routing header which contains the mobile 3840 node's home address. 3842 Entries in a node's Binding Cache MUST be deleted when their lifetime 3843 expires. 3845 9.5.5 Sending Binding Refresh Requests 3847 If a Binding Cache entry being deleted is still in active use in 3848 sending packets to a mobile node, the next packet sent to the mobile 3849 node will be routed normally to the mobile node's home link. 3850 Communication with the mobile node continues, but the tunneling from 3851 the home network creates additional overhead and latency in 3852 delivering packets to the mobile node. 3854 If the sender knows that the Binding Cache entry is still in active 3855 use, it MAY send a Binding Refresh Request message to the mobile node 3856 in an attempt to avoid this overhead and latency due to deleting and 3857 recreating the Binding Cache entry. The Binding Refresh Request 3858 message is sent in the same way as any packet addressed to the mobile 3859 node (Section 9.3.2). 3861 The correspondent node MAY retransmit Binding Refresh Request 3862 messages provided that rate limitation is applied. The correspondent 3863 node MUST stop retransmitting when it receives a Binding Update. 3865 9.6 Cache Replacement Policy 3867 Conceptually, a node maintains a separate timer for each entry in its 3868 Binding Cache. When creating or updating a Binding Cache entry in 3869 response to a received and accepted Binding Update, the node sets the 3870 timer for this entry to the specified Lifetime period. Any entry in 3871 a node's Binding Cache MUST be deleted after the expiration of the 3872 Lifetime specified in the Binding Update from which the entry was 3873 created or last updated. 3875 Each node's Binding Cache will, by necessity, have a finite size. A 3876 node MAY use any reasonable local policy for managing the space 3877 within its Binding Cache, except that any entry marked as a home 3878 registration (Section 10.3.1) MUST NOT be deleted from the cache 3879 until the expiration of its lifetime period. When such home 3880 registration entries are deleted, the home agent MUST also cease 3881 intercepting packets on the mobile node's home link addressed to the 3882 mobile node (Section 10.4.1), just as if the mobile node had 3883 de-registered its primary care-of address (see Section 10.3.2). 3885 When attempting to add a new home registration entry in response to a 3886 Binding Update with the Home Registration (H) bit set, if no 3887 sufficient space can be found, the home agent MUST reject the Binding 3888 Update. Furthermore, the home agent MUST return a Binding 3889 Acknowledgement to the sending mobile node, in which the Status field 3890 is set to 130 (insufficient resources). 3892 A node MAY choose to drop any entry already in its Binding Cache, 3893 other than home registration entries, in order to make space for a 3894 new entry. For example, a "least-recently used" (LRU) strategy for 3895 cache entry replacement among entries not marked as home 3896 registrations is likely to work well unless the size of the Binding 3897 Cache is substantially insufficient. 3899 If the node sends a packet to a destination for which it has dropped 3900 the entry from its Binding Cache, the packet will be routed through 3901 the mobile node's home link. The mobile node can detect this, and 3902 establish a new binding if necessary. 3904 10. Home Agent Operation 3906 10.1 Conceptual Data Structures 3908 Each home agent MUST maintain a Binding Cache and Home Agents List. 3910 The rules for maintaining a Binding Cache are the same for home 3911 agents and correspondent nodes, and have already been described in 3912 Section 9.1. 3914 The Home Agents List is maintained by each home agent, recording 3915 information about each router on the same link which is acting as a 3916 home agent; this list is used by the dynamic home agent address 3917 discovery mechanism. A router is known to be acting as a home agent, 3918 if it sends a Router Advertisement in which the Home Agent (H) bit is 3919 set. When the lifetime for a list entry (defined below) expires, 3920 that entry is removed from the Home Agents List. The Home Agents 3921 List is thus similar to the Default Router List conceptual data 3922 structure maintained by each host for Neighbor Discovery [12]. The 3923 Home Agents List MAY be implemented in any manner consistent with the 3924 external behavior described in this document. 3926 Each home agent maintains a separate Home Agents List for each link 3927 on which it is serving as a home agent. A new entry is created or an 3928 existing entry is updated in response to receipt of a valid Router 3929 Advertisement in which the Home Agent (H) bit is set. Each Home 3930 Agents List entry conceptually contains the following fields: 3932 o The link-local IP address of a home agent on the link. This 3933 address is learned through the Source Address of the Router 3934 Advertisements [12] received from the router. 3936 o One or more global IP addresses for this home agent. Global 3937 addresses are learned through Prefix Information options with the 3938 Router Address (R) bit set, received in Router Advertisements from 3939 this link-local address. Global addresses for the router in a 3940 Home Agents List entry MUST be deleted once the prefix associated 3941 with that address is no longer valid [12]. 3943 o The remaining lifetime of this Home Agents List entry. If a Home 3944 Agent Information Option is present in a Router Advertisement 3945 received from a home agent, the lifetime of the Home Agents List 3946 entry representing that home agent is initialized from the Home 3947 Agent Lifetime field in the option (if present); otherwise, the 3948 lifetime is initialized from the Router Lifetime field in the 3949 received Router Advertisement. If Home Agents List entry lifetime 3950 reaches zero, the entry MUST be deleted from the Home Agents List. 3952 o The preference for this home agent; higher values indicate a more 3953 preferable home agent. The preference value is taken from the 3954 Home Agent Preference field in the received Router Advertisement, 3955 if the Router Advertisement contains a Home Agent Information 3956 Option, and is otherwise set to the default value of 0. A home 3957 agent uses this preference in ordering the Home Agents List when 3958 it sends an ICMP Home Agent Address Discovery message. 3960 10.2 Processing Mobility Headers 3962 All IPv6 home agents MUST observe the rules described in Section 9.2 3963 when processing Mobility Headers. 3965 10.3 Processing Bindings 3967 10.3.1 Primary Care-of Address Registration 3969 When a node receives a Binding Update, it MUST validate it and 3970 determine the type of Binding Update according to the steps described 3971 in Section 9.5.1. Furthermore, it MUST authenticate the Binding 3972 Update as described in Section 5.1. An authorization step specific 3973 for the home agent is also needed to ensure that only the right node 3974 can control a particular home address. This is provided through the 3975 home address unequivocally identifying the security association that 3976 must be used. 3978 This section describes the processing of a valid and authorized 3979 Binding Update, when it requests the registration of the mobile 3980 node's primary care-of address. 3982 To begin processing the Binding Update, the home agent MUST perform 3983 the following sequence of tests: 3985 o If the node implements only correspondent node functionality, or 3986 has not been configured to act as a home agent, then the node MUST 3987 reject the Binding Update. The node MUST then also return a 3988 Binding Acknowledgement to the mobile node, in which the Status 3989 field is set to 131 (home registration not supported). 3991 o Else, if the home address for the binding (the Home Address field 3992 in the packet's Home Address option) is not an on-link IPv6 3993 address with respect to the home agent's current Prefix List or if 3994 the corresponding prefix was not advertised with the Home Agent 3995 (H) bit set, then the home agent MUST reject the Binding Update 3996 and SHOULD return a Binding Acknowledgement to the mobile node, in 3997 which the Status field is set to 132 (not home subnet). 3999 o Else, if the home agent chooses to reject the Binding Update for 4000 any other reason (e.g., insufficient resources to serve another 4001 mobile node as a home agent), then the home agent SHOULD return a 4002 Binding Acknowledgement to the mobile node, in which the Status 4003 field is set to an appropriate value to indicate the reason for 4004 the rejection. 4006 o A Home Address destination option MUST be present in the message. 4007 It MUST be validated as described in Section 9.3.1 with the 4008 following additional rule. The Binding Cache entry existence test 4009 MUST NOT be done for IPsec packets when the Home Address option 4010 contains an address for which the receiving node could act as a 4011 home agent. 4013 If home agent accepts the Binding Update, it MUST then create a new 4014 entry in its Binding Cache for this mobile node, or update its 4015 existing Binding Cache entry, if such an entry already exists. The 4016 Home Address field as received in the Home Address option provides 4017 the home address of the mobile node. 4019 The home agent MUST mark this Binding Cache entry as a home 4020 registration to indicate that the node is serving as a home agent for 4021 this binding. Binding Cache entries marked as a home registration 4022 MUST be excluded from the normal cache replacement policy used for 4023 the Binding Cache (Section 9.6) and MUST NOT be removed from the 4024 Binding Cache until the expiration of the Lifetime period. 4026 Unless this home agent already has a binding for the given home 4027 address, the home agent MUST perform Duplicate Address Detection [13] 4028 on the mobile node's home link before returning the Binding 4029 Acknowledgement. This ensures that no other node on the home link 4030 was using the mobile node's home address when the Binding Update 4031 arrived. If this Duplicate Address Detection fails for the given 4032 home address or an associated link local address, then the home agent 4033 MUST reject the complete Binding Update and MUST return a Binding 4034 Acknowledgement to the mobile node, in which the Status field is set 4035 to 134 (Duplicate Address Detection failed). When the home agent 4036 sends a successful Binding Acknowledgement to the mobile node, the 4037 home agent assures to the mobile node that its address(es) will 4038 continue to be kept unique by the home agent at least as long as the 4039 lifetime granted for the bindings is not over. 4041 The specific addresses which are to be tested before accepting the 4042 Binding Update, and later to be defended by performing Duplicate 4043 Address Detection, depend on the setting of the Link-Local Address 4044 Compatibility (L) bit, as follows: 4046 o L=0: Defend only the given address. Do not derive a link-local 4047 address. 4049 o L=1: Defend both the given non link-local unicast (home) address 4050 and the derived link-local. The link-local address is derived by 4051 replacing the subnet prefix in the mobile node's home address with 4052 the link-local prefix. 4054 The lifetime of the Binding Cache entry depends on a number of 4055 factors: 4057 o The lifetime for the Binding Cache entry MUST NOT be greater than 4058 the Lifetime value specified in the Binding Update. 4060 o The lifetime for the Binding Cache entry MUST NOT be greater than 4061 the remaining valid lifetime for the subnet prefix in the mobile 4062 node's home address specified with the Binding Update. The 4063 remaining valid lifetime for this prefix is determined by the home 4064 agent based on its own Prefix List entry for this prefix [12]. 4066 The remaining preferred lifetime SHOULD NOT have any impact on the 4067 lifetime for the binding cache entry. The home agent MUST remove 4068 a binding when the valid lifetime of the prefix associated with it 4069 expires. 4071 o The home agent MAY further decrease the specified lifetime for the 4072 binding, for example based on a local policy. The resulting 4073 lifetime is stored by the home agent in the Binding Cache entry, 4074 and this Binding Cache entry MUST be deleted by the home agent 4075 after the expiration of this lifetime. 4077 Regardless of the setting of the Acknowledge (A) bit in the Binding 4078 Update, the home agent MUST return a Binding Acknowledgement to the 4079 mobile node, constructed as follows: 4081 o The Status field MUST be set to a value indicating success. The 4082 value 1 (accepted but prefix discovery necessary) MUST be used if 4083 the subnet prefix of the specified home address is deprecated, 4084 becomes deprecated during the lifetime of the binding, or becomes 4085 invalid at the end of the lifetime. The value 0 MUST be used 4086 otherwise. For the purposes of comparing the binding and prefix 4087 lifetimes, the prefix lifetimes are first converted into units of 4088 four seconds by ignoring the two least significant bits. 4090 o The Key Management Mobility Capability (K) bit is set if the 4091 following conditions are all fulfilled, and cleared otherwise: 4093 * The Key Management Mobility Capability (K) bit was set in the 4094 Binding Update. 4096 * The IPsec security associations between the mobile node and the 4097 home agent have been established dynamically. 4099 * The home agent has the capability to update its endpoint in the 4100 used key management protocol to the new care-of address every 4101 time it moves 4103 Depending on the final value of the bit in the Binding 4104 Acknowledgement, the home agent SHOULD perform the following 4105 actions: 4107 K = 0 4109 Discard key management connections, if any, to the old care-of 4110 address. If the mobile node did not have a binding before 4111 sending this Binding Update, discard the connections to the 4112 home address. 4114 K = 1 4116 Move the peer endpoint of the key management protocol 4117 connection, if any, to the new care-of address. For an IKE 4118 phase 1 connection, this means that any IKE packets sent to the 4119 peer are sent to this address, and packets from this address 4120 with the original ISAKMP cookies are accepted. 4122 o The Sequence Number field MUST be copied from the Sequence Number 4123 given in the Binding Update. 4125 o The Lifetime field MUST be set to the remaining lifetime for the 4126 binding as set by the home agent in its home registration Binding 4127 Cache entry for the mobile node, as described above. 4129 o If the home agent stores the Binding Cache entry in nonvolatile 4130 storage, then the Binding Refresh Advice mobility option MUST be 4131 omitted. Otherwise, the home agent MAY include this option to 4132 suggest that the mobile node refreshes its binding sooner than the 4133 actual lifetime of the binding ends. 4135 If the Binding Refresh Advice mobility option is present, the 4136 Refresh Interval field in the option MUST be set to a value less 4137 than the Lifetime value being returned in the Binding 4138 Acknowledgement. This indicates that the mobile node SHOULD 4139 attempt to refresh its home registration at the indicated shorter 4140 interval. The home agent MUST still retain the registration for 4141 the Lifetime period, even if the mobile node does not refresh its 4142 registration within the Refresh period. 4144 The rules for selecting the Destination IP address (and possibly 4145 routing header construction) for the Binding Acknowledgement to the 4146 mobile node are the same as in Section 9.5.4. 4148 In addition, the home agent MUST follow the procedure defined in 4149 Section 10.4.1 to intercept packets on the mobile node's home link 4150 addressed to the mobile node, while the home agent is serving as the 4151 home agent for this mobile node. The home agent MUST also be 4152 prepared to accept reverse tunneled packets from the new care-of 4153 address of the mobile node, as described in Section 10.4.5. Finally, 4154 the home agent MUST also propagate new home network prefixes, as 4155 described in Section 10.6. 4157 10.3.2 Primary Care-of Address De-Registration 4159 A binding may need to be de-registered when the mobile node returns 4160 home, or when the mobile node knows that it will soon not have any 4161 care-of addresses in the visited network. 4163 A Binding Update is validated and authorized in the manner described 4164 in the previous section. This section describes the processing of a 4165 valid Binding Update that requests the receiving node to no longer 4166 serve as its home agent, de-registering its primary care-of address. 4168 To begin processing the Binding Update, the home agent MUST perform 4169 the following test: 4171 o If the receiving node has no entry marked as a home registration 4172 in its Binding Cache for this mobile node, then this node MUST 4173 reject the Binding Update and SHOULD return a Binding 4174 Acknowledgement to the mobile node, in which the Status field is 4175 set to 133 (not home agent for this mobile node). 4177 If the home agent does not reject the Binding Update as described 4178 above, then it MUST delete any existing entry in its Binding Cache 4179 for this mobile node. Then, the home agent MUST return a Binding 4180 Acknowledgement to the mobile node, constructed as follows: 4182 o The Status field MUST be set to a value 0, indicating success. 4184 o The Key Management Mobility Capability (K) bit is set or cleared, 4185 and actions based on its value are performed as described in the 4186 previous section. The mobile node's home address is used as its 4187 new care-of address for the purposes of moving the key management 4188 connection to a new endpoint. 4190 o The Sequence Number field MUST be copied from the Sequence Number 4191 given in the Binding Update. 4193 o The Lifetime field MUST be set to zero. 4195 o The Binding Refresh Advice mobility option MUST be omitted. 4197 In addition, the home agent MUST stop intercepting packets on the 4198 mobile node's home link that are addressed to the mobile node 4199 (Section 10.4.1). 4201 The rules for selecting the Destination IP address (and, if required, 4202 routing header construction) for the Binding Acknowledgement to the 4203 mobile node are the same as in the previous section. When the Status 4204 field in the Binding Acknowledgement is greater than or equal to 128 4205 and the Source Address of the Binding Update is on the home link, the 4206 home agent MUST send it to the mobile node's link layer address 4207 (retrieved either from the Binding Update or through Neighbor 4208 Solicitation). 4210 10.4 Packet Processing 4212 10.4.1 Intercepting Packets for a Mobile Node 4214 While a node is serving as the home agent for mobile node it MUST 4215 attempt to intercept packets on the mobile node's home link that are 4216 addressed to the mobile node. 4218 In order to do this, when a node begins serving as the home agent it 4219 MUST multicast onto the home link a Neighbor Advertisement message 4220 [12] on behalf of the mobile node. For the home address specified in 4221 the Binding Update, the home agent sends a Neighbor Advertisement 4222 message [12] to the all-nodes multicast address on the home link, to 4223 advertise the home agent's own link-layer address for this IP address 4224 on behalf of the mobile node. If the Link-Layer Address 4225 Compatibility (L) flag has been specified in the Binding Update, the 4226 home agent MUST do the same for the link-local address of the mobile 4227 node. 4229 All fields in each such Neighbor Advertisement message SHOULD be set 4230 in the same way they would be set by the mobile node itself if 4231 sending this Neighbor Advertisement [12] while at home, with the 4232 following exceptions: 4234 o The Target Address in the Neighbor Advertisement MUST be set to 4235 the specific IP address for the mobile node. 4237 o The Advertisement MUST include a Target Link-layer Address option 4238 specifying the home agent's link-layer address. 4240 o The Router (R) bit in the Advertisement MUST be set to zero. 4242 o The Solicited Flag (S) in the Advertisement MUST NOT be set, since 4243 it was not solicited by any Neighbor Solicitation. 4245 o The Override Flag (O) in the Advertisement MUST be set, indicating 4246 that the Advertisement SHOULD override any existing Neighbor Cache 4247 entry at any node receiving it. 4249 o The Source Address in the IPv6 header MUST be set to the home 4250 agent's IP address on the interface used to send the 4251 advertisement. 4253 Any node on the home link receiving one of the Neighbor Advertisement 4254 messages described above will thus update its Neighbor Cache to 4255 associate the mobile node's address with the home agent's link layer 4256 address, causing it to transmit any future packets normally destined 4257 to the mobile node to the mobile node's home agent. Since 4258 multicasting on the local link (such as Ethernet) is typically not 4259 guaranteed to be reliable, the home agent MAY retransmit this 4260 Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see 4261 [12]) times to increase its reliability. It is still possible that 4262 some nodes on the home link will not receive any of these Neighbor 4263 Advertisements, but these nodes will eventually be able to detect the 4264 link-layer address change for the mobile node's address, through use 4265 of Neighbor Unreachability Detection [12]. 4267 While a node is serving as a home agent for some mobile node, the 4268 home agent uses IPv6 Neighbor Discovery [12] to intercept unicast 4269 packets on the home link addressed to the mobile node. In order to 4270 intercept packets in this way, the home agent MUST act as a proxy for 4271 this mobile node, and reply to any received Neighbor Solicitations 4272 for it. When a home agent receives a Neighbor Solicitation, it MUST 4273 check if the Target Address specified in the message matches the 4274 address of any mobile node for which it has a Binding Cache entry 4275 marked as a home registration. 4277 If such an entry exists in the home agent's Binding Cache, the home 4278 agent MUST reply to the Neighbor Solicitation with a Neighbor 4279 Advertisement, giving the home agent's own link-layer address as the 4280 link-layer address for the specified Target Address. In addition, 4281 the Router (R) bit in the Advertisement MUST be set to zero. Acting 4282 as a proxy in this way allows other nodes on the mobile node's home 4283 link to resolve the mobile node's address, and allows the home agent 4284 to defend these addresses on the home link for Duplicate Address 4285 Detection [12]. 4287 10.4.2 Processing Intercepted Packets 4289 For any packet sent to a mobile node from the mobile node's home 4290 agent (for which the home agent is the original sender of the 4291 packet), the home agent is operating as a correspondent node of the 4292 mobile node for this packet and the procedures described in Section 4293 9.3.2 apply. The home agent then uses a routing header to route the 4294 packet to the mobile node by way of the primary care-of address in 4295 the home agent's Binding Cache. 4297 While the mobile node is away from home, the home agent intercepts 4298 any packets on the home link addressed to the mobile node's home 4299 address, as described in Section 10.4.1. In order to forward each 4300 intercepted packet to the mobile node, the home agent MUST tunnel the 4301 packet to the mobile node using IPv6 encapsulation [15]. When a home 4302 agent encapsulates an intercepted packet for forwarding to the mobile 4303 node, the home agent sets the Source Address in the new tunnel IP 4304 header to the home agent's own IP address, and sets the Destination 4305 Address in the tunnel IP header to the mobile node's primary care-of 4306 address. When received by the mobile node, normal processing of the 4307 tunnel header [15] will result in decapsulation and processing of the 4308 original packet by the mobile node. 4310 However, packets addressed to the mobile node's link-local address 4311 MUST NOT be tunneled to the mobile node. Instead, such a packet MUST 4312 be discarded, and the home agent SHOULD return an ICMP Destination 4313 Unreachable, Code 3, message to the packet's Source Address (unless 4314 this Source Address is a multicast address). Packets addressed to 4315 the mobile node's site-local address SHOULD NOT be tunneled to the 4316 mobile node by default. 4318 Interception and tunneling of the following multicast addressed 4319 packets on the home network are only done if the home agent supports 4320 multicast group membership control messages from the mobile node as 4321 described in the next section. Tunneling of multicast packets to a 4322 mobile node follows similar limitations to those defined above for 4323 unicast packets addressed to the mobile node's link-local and 4324 site-local addresses. Multicast packets addressed to a multicast 4325 address with link-local scope [3], to which the mobile node is 4326 subscribed, MUST NOT be tunneled to the mobile node; such packets 4327 SHOULD be silently discarded (after delivering to other local 4328 multicast recipients). Multicast packets addressed to a multicast 4329 address with scope larger than link-local but smaller than global 4330 (e.g., site-local and organization-local [3]), to which the mobile 4331 node is subscribed, SHOULD NOT be tunneled to the mobile node. 4332 Multicast packets addressed with a global scope to which the mobile 4333 node has successfully subscribed MUST be tunneled to the mobile node. 4335 Before tunneling a packet to the mobile node, the home agent MUST 4336 perform any IPsec processing as indicated by the security policy data 4337 base. 4339 10.4.3 Multicast Membership Control 4341 This section is a prerequisite for the multicast data packet 4342 forwarding described in the previous section. If this support is not 4343 provided, multicast group membership control messages are silently 4344 ignored. 4346 In order to forward multicast data packets from the home network to 4347 all the proper mobile nodes the home agent SHOULD be capable of 4348 receiving tunneled multicast group membership control information 4349 from the mobile node in order to determine which groups the mobile 4350 node has subscribed to. These multicast group membership messages 4351 are Listener Report messages specified MLD [17] or in other protocols 4352 such as [35]. 4354 The messages are issued by the mobile node but sent through the 4355 reverse tunnel to the home agent. These messages are issued whenever 4356 the mobile node decides to enable reception of packets for a 4357 multicast group or in response to an MLD Query from the home agent. 4358 The mobile node will also issue multicast group control messages to 4359 disable reception of multicast packets when it is no longer 4360 interested in receiving multicasts for a particular group. 4362 To obtain the mobile node's current multicast group membership the 4363 home agent must periodically transmit MLD Query messages through the 4364 tunnel to the mobile node. These MLD periodic transmissions will 4365 ensure the home agent has an accurate record of the groups in which 4366 the mobile node is interested despite packet losses of the mobile 4367 node's MLD group membership messages. 4369 All MLD packets are sent directly between the mobile node and the 4370 home agent. Since all these packets are destined to a link-scope 4371 multicast address and have a hop limit of 1, there is no direct 4372 forwarding of such packets between the home network and the mobile 4373 node. The MLD packets between the mobile node and the home agent are 4374 encapsulated within the same tunnel header used for other packet 4375 flows between the mobile node and home agent. 4377 Note that at this time, even though a link-local source is used on 4378 MLD packets, no functionality depends on these addresses being 4379 unique, nor do they elicit direct responses. All MLD messages are 4380 sent to multicast destinations. To avoid ambiguity on the home agent 4381 due to mobile nodes which may choose identical link-local source 4382 addresses for their MLD function it is necessary for the home agent 4383 to identify which mobile node was actually the issuer of a particular 4384 MLD message. This may be accomplished by noting which tunnel such an 4385 MLD arrived by, which IPsec SA was used, or by other distinguishing 4386 means. 4388 This specification puts no requirement on how the functions in this 4389 section and the multicast forwarding in Section 10.4.2 are to be 4390 achieved. At the time of this writing it was thought that a full 4391 IPv6 multicast router function would be necessary on the home agent, 4392 but it may be possible to achieve the same effects through a "proxy 4393 MLD" application coupled with kernel multicast forwarding. This may 4394 be the subject of future specifications. 4396 10.4.4 Stateful Address Autoconfiguration 4398 This section describes how home agents support the use of stateful 4399 address autoconfiguration mechanisms such as DHCPv6 [28] from the 4400 mobile nodes. If this support is not provided, then the M and O bits 4401 must remain cleared on the Mobile Prefix Advertisement Messages. Any 4402 mobile node which issues autoconfiguration queries for servers 4403 without this support will not receive a response. 4405 If DHCPv6 is used, packets are sent with link-local source addresses 4406 either to a link-scope multicast address or a link-local address. 4407 Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel 4408 standard DHCPv6 packets to the home agent. Since these link-scope 4409 packets can not be forwarded onto the home network it is necessary 4410 for the home agent to either implement a DHCPv6 relay agent or a 4411 DHCPv6 server function itself. The arriving tunnel or IPsec SA of 4412 DHCPv6 link-scope messages from the mobile node must be noted so that 4413 DHCPv6 responses may be sent back to the appropriate mobile node. 4414 DHCPv6 messages sent to the mobile node with a link-local destination 4415 must be tunneled within the same tunnel header used for other packet 4416 flows. 4418 10.4.5 Handling Reverse Tunneled Packets 4420 Unless a binding has been established between the mobile node and a 4421 correspondent node, traffic from the mobile node to the correspondent 4422 node goes through a reverse tunnel. Home agents MUST support reverse 4423 tunneling as follows: 4425 o The tunneled traffic arrives to the home agent's address using 4426 IPv6 encapsulation [15]. 4428 o When a home agent decapsulates a tunneled packet from the mobile 4429 node, the home agent MUST verify that the Source Address in the 4430 tunnel IP header is the mobile node's primary care-of address. 4431 Otherwise any node in the Internet could send traffic through the 4432 home agent and escape ingress filtering limitations. 4434 Reverse tunneled packets MAY be discarded unless accompanied by a 4435 valid ESP header, depending on the security policies used by the home 4436 agent. The support for authenticated reverse tunneling allows the 4437 home agent to protect the home network and correspondent nodes from 4438 malicious nodes masquerading as a mobile node, even if they know the 4439 current location of the real mobile node. 4441 10.4.6 Protecting Return Routability Packets 4443 The return routability procedure described in Section 5.2.5 assumes 4444 that the confidentiality of the Home Test Init and Home Test messages 4445 is protected as they are tunneled between the home agent to the 4446 mobile node. Therefore, the home agent MUST support tunnel mode 4447 IPsec ESP for the protection of packets belonging to the return 4448 routability procedure. Support for a non-null encryption transform 4449 and authentication algorithm MUST be available. It isn't necessary 4450 to distinguish between different kinds of packets within the return 4451 routability procedure. 4453 Security associations are needed to provide this protection. When 4454 the care-of address for the mobile node changes as a result of an 4455 accepted Binding Update, special treatment is needed for the next 4456 packets sent using these security associations. The home agent MUST 4457 set the new care-of address as the destination address of these 4458 packets, as if the destination gateway address in the security 4459 association had changed [21]. 4461 The above protection SHOULD be used with all mobile nodes. The use 4462 is controlled by configuration of the IPsec security policy database 4463 both at the mobile node and at the home agent. 4465 As described earlier, the Binding Update and Binding Acknowledgement 4466 messages require protection between the home agent and the mobile 4467 node. The Mobility Header protocol carries both these messages as 4468 well as the return routability messages. From the point of view of 4469 the security policy database these messages are indistinguishable. 4470 The security policy database entries MUST be defined as if they were 4471 specifically for the tunnel interface between the mobile node and the 4472 home agent. That is, the policy entries are not generally applied on 4473 all traffic on the physical interface(s) of the nodes, but rather 4474 only on traffic that enters the tunnel. This makes use of 4475 per-interface security policy database entries [4], specific to the 4476 tunnel interface (the node's attachment to the tunnel [11]). 4478 10.5 Dynamic Home Agent Address Discovery 4480 This section describes how a home agent can help mobile nodes to 4481 discover the addresses of the home agents. The home agent keeps 4482 track of the other home agents on the same link, and responds to 4483 queries sent by the mobile node. 4485 10.5.1 Receiving Router Advertisement Messages 4487 For each link on which a router provides service as a home agent, the 4488 router maintains a Home Agents List recording information about all 4489 other home agents on that link. This list is used in the dynamic 4490 home agent address discovery mechanism, described in Section 10.5. 4491 The information for the list is learned through receipt of the 4492 periodic unsolicited multicast Router Advertisements, in a manner 4493 similar to the Default Router List conceptual data structure 4494 maintained by each host for Neighbor Discovery [12]. In the 4495 construction of the Home Agents List, the Router Advertisements are 4496 from each other home agent on the link, and the Home Agent (H) bit is 4497 set in them. 4499 On receipt of a valid Router Advertisement, as defined in the 4500 processing algorithm specified for Neighbor Discovery [12], the home 4501 agent performs the following steps, in addition to any steps already 4502 required of it by Neighbor Discovery: 4504 o If the Home Agent (H) bit in the Router Advertisement is not set, 4505 delete the sending node's entry in the current Home Agents List 4506 (if one exists). Skip all the following steps. 4508 o Otherwise, extract the Source Address from the IP header of the 4509 Router Advertisement. This is the link-local IP address on this 4510 link of the home agent sending this Advertisement [12]. 4512 o Determine the preference for this home agent. If the Router 4513 Advertisement contains a Home Agent Information Option, then the 4514 preference is taken from the Home Agent Preference field in the 4515 option; otherwise, the default preference of 0 MUST be used. 4517 o Determine the lifetime for this home agent. If the Router 4518 Advertisement contains a Home Agent Information Option, then the 4519 lifetime is taken from the Home Agent Lifetime field in the 4520 option; otherwise, the lifetime specified by the Router Lifetime 4521 field in the Router Advertisement SHOULD be used. 4523 o If the link-local address of the home agent sending this 4524 Advertisement is already present in this home agent's Home Agents 4525 List and the received home agent lifetime value is zero, 4526 immediately delete this entry in the Home Agents List. 4528 o Otherwise, if the link-local address of the home agent sending 4529 this Advertisement is already present in the receiving home 4530 agent's Home Agents List, reset its lifetime and preference to the 4531 values determined above. 4533 o If the link-local address of the home agent sending this 4534 Advertisement is not already present in the Home Agents List 4535 maintained by the receiving home agent, and the lifetime for the 4536 sending home agent is non-zero, create a new entry in the list, 4537 and initialize its lifetime and preference to the values 4538 determined above. 4540 o If the Home Agents List entry for the link-local address of the 4541 home agent sending this Advertisement was not deleted as described 4542 above, determine any global address(es) of the home agent based on 4543 each Prefix Information option received in this Advertisement in 4544 which the Router Address (R) bit is set (Section 7.2). Add all 4545 such global addresses to the list of global addresses in this Home 4546 Agents List entry. 4548 A home agent SHOULD maintain an entry in its Home Agents List for 4549 each valid home agent address until that entry's lifetime expires, 4550 after which time the entry MUST be deleted. 4552 As described in Section 11.4.1, a mobile node attempts dynamic home 4553 agent address discovery by sending an ICMP Home Agent Address 4554 Discovery Request message to the Mobile IPv6 Home-Agents anycast 4555 address [16] for its home IP subnet prefix. A home agent receiving 4556 such a Home Agent Address Discovery Request message that is serving 4557 this subnet SHOULD return an ICMP Home Agent Address Discovery Reply 4558 message to the mobile node, with the Source Address of the Reply 4559 packet set to one of the global unicast addresses of the home agent. 4560 The Home Agent Addresses field in the Reply message is constructed as 4561 follows: 4563 o The Home Agent Addresses field SHOULD contain all global IP 4564 addresses for each home agent currently listed in this home 4565 agent's own Home Agents List (Section 10.1). 4567 o The IP addresses in the Home Agent Addresses field SHOULD be 4568 listed in order of decreasing preference values, based either on 4569 the respective advertised preference from a Home Agent Information 4570 option or on the default preference of 0 if no preference is 4571 advertised (or on the configured home agent preference for this 4572 home agent itself). 4574 o Among home agents with equal preference, their IP addresses in the 4575 Home Agent Addresses field SHOULD be listed in an order randomized 4576 with respect to other home agents with equal preference, each time 4577 a Home Agent Address Discovery Reply message is returned by this 4578 home agent. 4580 o If more than one global IP address is associated with a home 4581 agent, these addresses SHOULD be listed in a randomized order. 4583 o The home agent SHOULD reduce the number of home agent IP addresses 4584 so that the packet fits within the minimum IPv6 MTU [11]. The 4585 home agent addresses selected for inclusion in the packet SHOULD 4586 be those from the complete list with the highest preference. This 4587 limitation avoids the danger of the Reply message packet being 4588 fragmented (or rejected by an intermediate router with an ICMP 4589 Packet Too Big message [14]). 4591 10.6 Sending Prefix Information to the Mobile Node 4593 10.6.1 Aggregate List of Home Network Prefixes 4595 Mobile IPv6 arranges to propagate relevant prefix information to the 4596 mobile node when it is away from home, so that it may be used in 4597 mobile node home address configuration, and in network renumbering. 4598 In this mechanism, mobile nodes away from home receive Mobile Prefix 4599 Advertisements messages with Prefix Information Options, which give 4600 the valid lifetime and preferred lifetime for available prefixes on 4601 the home link. 4603 The messages relayed to the mobile node are the ones learned via 4604 Neighbor Discovery on the home link. The prefix options are 4605 processed as defined in [12, 13]. 4607 To support this, the home agent monitors prefixes advertised by 4608 itself and other home agents routers on the home link, and passes 4609 this aggregated list of relevant subnet prefixes on to the mobile 4610 node in Mobile Prefix Advertisements. 4612 The home agent SHOULD construct the aggregate list of home subnet 4613 prefixes as follows: 4615 o Copy prefix information defined in the home agent's AdvPrefixList 4616 on the home subnet's interfaces to the aggregate list. Also apply 4617 any changes made to the AdvPrefixList on the home agent to the 4618 aggregate list. 4620 o Check valid prefixes received in Router Advertisements from the 4621 home network for consistency with the home agent's AdvPrefixList, 4622 as specified in Section 6.2.7 of RFC 2461 [12]. Do not update the 4623 aggregate list with any information from received prefixes that 4624 fail this check. 4626 o For Router Advertisements which have the Home Agent (H) bit set, 4627 check valid prefixes that are not yet in the aggregate list. If a 4628 Prefix Information option has the autonomous address configuration 4629 (A) flag set and the prefix length is valid for address 4630 autoconfiguration on the home subnet, add these advertisements and 4631 preserve the on-link (L) flag value. Clear the Router Address (R) 4632 flag and zero the interface-id portion of the prefix field to 4633 prevent mobile nodes from treating another router's interface 4634 address as belonging to the home agent. Treat the lifetimes of 4635 these prefixes as decrementing in real time, as defined in Section 4636 6.2.7 of RFC 2461 [12]. 4638 o Do not perform consistency checks on valid prefixes received in 4639 Router Advertisements on the home network that do not exist in the 4640 home agent's AdvPrefixList. Instead, if the prefixes already 4641 exist in the aggregate list, update the prefix lifetime fields in 4642 the aggregate list according to the rules specified for hosts in 4643 Section 6.3.4 of RFC 2461 [12] and Section 5.5.3 of RFC 2462 [13], 4644 unless the update would override existing information from this 4645 home agent. 4647 o If the L flag is set on valid prefixes received in a Router 4648 Advertisement, and that prefix already exists in the aggregate 4649 list, set the flag in the aggregate list. Ignore the flag if it 4650 is clear or if the setting of the flag was already configured in 4651 this home agent. 4653 o Delete prefixes from the aggregate list when their valid lifetimes 4654 expire. 4656 The home agent uses the information in the aggregate list to 4657 construct Mobile Prefix Advertisements. It may be possible to 4658 construct an aggregate list by combining information contained in the 4659 home agent's AdvPrefixList and its Home Agents List used for Dynamic 4660 Home Agent Address Discovery (Section 11.4.1). 4662 10.6.2 Scheduling Prefix Deliveries 4664 A home agent serving a mobile node will schedule the delivery of new 4665 prefix information to that mobile node when any of the following 4666 conditions occur: 4668 MUST: 4670 o The valid or preferred lifetime or the state of the flags changes 4671 for the prefix of the mobile node's registered home address. 4673 o The mobile node requests the information with a Mobile Prefix 4674 Solicitation (see Section 11.4.2). 4676 SHOULD: 4678 o A new prefix is added to the aggregate list. 4680 MAY: 4682 o The valid or preferred lifetime or the state of the flags changes 4683 for a prefix which is not used in any Binding Cache entry for this 4684 mobile node. 4686 The home agent uses the following algorithm to determine when to send 4687 prefix information to the mobile node. 4689 o If a mobile node sends a solicitation, answer right away. 4691 o If no Mobile Prefix Advertisement has been sent to the mobile node 4692 in the last MaxMobPfxAdvInterval (see Section 13) seconds, then 4693 ensure that a transmission is scheduled. The actual transmission 4694 time is randomized as described below. 4696 o If a prefix in the aggregate list that matches the mobile node's 4697 home registration is added, or if its information changes in any 4698 way that does not deprecate the mobile node's address, ensure that 4699 a transmission is scheduled. The actual transmission time is 4700 randomized as described below. 4702 o If a home registration expires, cancel any scheduled 4703 advertisements to the mobile node. 4705 The aggregate list is sent in its entirety in all cases. 4707 If the home agent already has scheduled the transmission of a Mobile 4708 Prefix Advertisement to the mobile node, the home agent replaces the 4709 advertisement with a new one, to be sent at the scheduled time. 4711 Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY, 4712 the offset from the current time for the scheduled transmission as 4713 follows. First calculate the maximum delay for the scheduled 4714 Advertisement: 4716 MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime), 4718 where MaxMobPfxAdvInterval is as defined in Section 12. Then compute 4719 the final delay for the advertisement: 4721 RAND_ADV_DELAY = MinMobPfxAdvInterval + 4722 (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval)) 4724 Here rand() returns a random integer value in the range of 0 to the 4725 maximum possible integer value. This computation is expected to 4726 alleviate bursts of advertisements when prefix information changes. 4727 In addition, a home agent MAY further reduce the rate of packet 4728 transmission by further delaying individual advertisements, if needed 4729 to avoid overwhelming local network resources. The home agent SHOULD 4730 periodically continue to retransmit an unsolicited Advertisement to 4731 the mobile node, until it is acknowledged by the receipt of a Mobile 4732 Prefix Solicitation from the mobile node. 4734 The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12) before 4735 the first retransmission, and double the retransmission wait time for 4736 every succeeding retransmission, up until a maximum of 4737 PREFIX_ADV_RETRIES attempts (see Section 12). If the mobile node's 4738 bindings expire before the matching Binding Update has been received, 4739 then the home agent MUST NOT attempt any more retransmissions, even 4740 if not all PREFIX_ADV_RETRIES have been retransmitted. If the mobile 4741 node sends another Binding Update without returning home in the 4742 meantime, the home agent SHOULD again begin transmitting the 4743 unsolicited Advertisement. 4745 If some condition as described above occurs on the home link and 4746 causes another Prefix Advertisement to be sent to the mobile node, 4747 before the mobile node acknowledges a previous transmission, the home 4748 agent SHOULD combine any Prefix Information options in the 4749 unacknowledged Mobile Prefix Advertisement into a new Advertisement. 4750 The home agent discards the old Advertisement. 4752 10.6.3 Sending Advertisements 4754 When sending a Mobile Prefix Advertisement to the mobile node, the 4755 home agent MUST construct the packet as follows: 4757 o The Source Address in the packet's IPv6 header MUST be set to the 4758 home agent's IP address to which the mobile node addressed its 4759 current home registration, or its default global home agent 4760 address if no binding exists. 4762 o If the advertisement was solicited, it MUST be destined to the 4763 source address of the solicitation. If it was triggered by prefix 4764 changes or renumbering, the advertisement's destination will be 4765 the mobile node's home address in the binding which triggered the 4766 rule. 4768 o A type 2 routing header MUST be included with the mobile node's 4769 home address. 4771 o IPsec headers MUST be supported and SHOULD be used. 4773 o The home agent MUST send the packet as it would any other unicast 4774 IPv6 packet that it originates. 4776 o Set the Managed Address Configuration (M) flag if the 4777 corresponding flag has been set in any of the Router 4778 Advertisements from which the prefix information has been learned 4779 (including the ones sent by this home agent). 4781 o Set the Other Stateful Configuration (O) flag if the corresponding 4782 flag has been set in any of the Router Advertisements from which 4783 the prefix information has been learned (including the ones sent 4784 by this home agent). 4786 10.6.4 Lifetimes for Changed Prefixes 4788 As described in Section 10.3.1, the lifetime returned by the home 4789 agent in a Binding Acknowledgement MUST be no greater than the 4790 remaining valid lifetime for the subnet prefix in the mobile node's 4791 home address. This limit on the binding lifetime serves to prohibit 4792 use of a mobile node's home address after it becomes invalid. 4794 11. Mobile Node Operation 4796 11.1 Conceptual Data Structures 4798 Each mobile node MUST maintain a Binding Update List. 4800 The Binding Update List records information for each Binding Update 4801 sent by this mobile node, for which the lifetime of the binding not 4802 yet expired. The Binding Update List includes all bindings sent by 4803 the mobile node either to its home agent or correspondent nodes. It 4804 also contains Binding Updates which are waiting for the completion of 4805 the return routability procedure before they can be sent. However, 4806 for multiple Binding Updates sent to the same destination address, 4807 the Binding Update List contains only the most recent Binding Update 4808 (i.e., with the greatest Sequence Number value) sent to that 4809 destination. The Binding Update List MAY be implemented in any 4810 manner consistent with the external behavior described in this 4811 document. 4813 Each Binding Update List entry conceptually contains the following 4814 fields: 4816 o The IP address of the node to which a Binding Update was sent. 4818 o The home address for which that Binding Update was sent. 4820 o The care-of address sent in that Binding Update. This value is 4821 necessary for the mobile node to determine if it has sent a 4822 Binding Update giving its new care-of address to this destination 4823 after changing its care-of address. 4825 o The initial value of the Lifetime field sent in that Binding 4826 Update. 4828 o The remaining lifetime of that binding. This lifetime is 4829 initialized from the Lifetime value sent in the Binding Update and 4830 is decremented until it reaches zero, at which time this entry 4831 MUST be deleted from the Binding Update List. 4833 o The maximum value of the Sequence Number field sent in previous 4834 Binding Updates to this destination. The Sequence Number field is 4835 16 bits long, and all comparisons between Sequence Number values 4836 MUST be performed modulo 2**16 (see Section 9.5.1). 4838 o The time at which a Binding Update was last sent to this 4839 destination, as needed to implement the rate limiting restriction 4840 for sending Binding Updates. 4842 o The state of any retransmissions needed for this Binding Update. 4843 This state includes the time remaining until the next 4844 retransmission attempt for the Binding Update, and the current 4845 state of the exponential back-off mechanism for retransmissions. 4847 o A flag specifying whether or not future Binding Updates should be 4848 sent to this destination. The mobile node sets this flag in the 4849 Binding Update List entry when it receives an ICMP Parameter 4850 Problem, Code 1, error message in response to a return routability 4851 message or Binding Update sent to that destination, as described 4852 in Section 11.3.5. 4854 The Binding Update list also conceptually contains the following data 4855 related to running the return routability procedure. This data is 4856 relevant only for Binding Updates sent to correspondent nodes. 4858 o The time at which a Home Test Init or Care-of Test Init message 4859 was last sent to this destination, as needed to implement the rate 4860 limiting restriction for the return routability procedure. 4862 o The state of any retransmissions needed for this return 4863 routability procedure. This state includes the time remaining 4864 until the next retransmission attempt and the current state of the 4865 exponential back-off mechanism for retransmissions. 4867 o Cookie values used in the Home Test Init and Care-of Test Init 4868 messages. 4870 o Home and care-of keygen tokens received from the correspondent 4871 node. 4873 o Home and care-of nonce indices received from the correspondent 4874 node. 4876 o The time at which each of the tokens and nonces was received from 4877 this correspondent node, as needed to implement reuse while 4878 moving. 4880 11.2 Processing Mobility Headers 4882 All IPv6 mobile nodes MUST observe the rules described in Section 9.2 4883 when processing Mobility Headers. 4885 11.3 Packet Processing 4886 11.3.1 Sending Packets While Away from Home 4888 While a mobile node is away from home, it continues to use its home 4889 address, as well as also using one or more care-of addresses. When 4890 sending a packet while away from home, a mobile node MAY choose among 4891 these in selecting the address that it will use as the source of the 4892 packet, as follows: 4894 o Protocols layered over IP will generally treat the mobile node's 4895 home address as its IP address for most packets. For packets sent 4896 that are part of transport-level connections established while the 4897 mobile node was at home, the mobile node MUST use its home 4898 address. Likewise, for packets sent that are part of 4899 transport-level connections that the mobile node may still be 4900 using after moving to a new location, the mobile node SHOULD use 4901 its home address in this way. If a binding exists, the mobile 4902 node SHOULD send the packets directly to the correspondent node. 4903 Otherwise, if a binding does not exist, the mobile node MUST use 4904 reverse tunneling. Detailed operation for both of these cases is 4905 described later in this section and also discussed in [29]. 4907 o The mobile node MAY choose to directly use one of its care-of 4908 addresses as the source of the packet, not requiring the use of a 4909 Home Address option in the packet. This is particularly useful 4910 for short-term communication that may easily be retried if it 4911 fails. Using the mobile node's care-of address as the source for 4912 such queries will generally have a lower overhead than using the 4913 mobile node's home address, since no extra options need be used in 4914 either the query or its reply. Such packets can be routed 4915 normally, directly between their source and destination without 4916 relying on Mobile IPv6. If application running on the mobile node 4917 has no particular knowledge that the communication being sent fits 4918 within this general type of communication, however, the mobile 4919 node should not use its care-of address as the source of the 4920 packet in this way. 4922 The choice of the most efficient communications method is 4923 application specific, and outside the scope of this specification. 4924 The APIs necessary for controlling the choice are also out of 4925 scope. 4927 o While not at its home link, the mobile node MUST NOT use the home 4928 address destination option when communicating with link-local or 4929 site-local peers, if the scope of the home address is larger than 4930 the scope of the peer's address. 4932 For packets sent by a mobile node while it is at home, no special 4933 Mobile IPv6 processing is required. Likewise, if the mobile node 4934 uses any address other than any of its home addresses as the source 4935 of a packet sent while away from home no special Mobile IPv6 4936 processing is required. In either case, the packet is simply 4937 addressed and transmitted in the same way as any normal IPv6 packet. 4939 For packets sent by the mobile node sent while away from home using 4940 the mobile node's home address as the source, special Mobile IPv6 4941 processing of the packet is required. This can be done in the 4942 following two ways: 4944 Route Optimization 4946 This manner of delivering packets does not require going through 4947 the home network, and typically will enable faster and more 4948 reliable transmission. 4950 The mobile node may send packets to the correspondent node in this 4951 manner only if the mobile node is aware that the correspondent 4952 node already has a Binding Cache entry for the mobile node's home 4953 address. Section 9.3.1 specifies the rules for Home Address 4954 Destination Option Processing at a correspondent node. The mobile 4955 node needs to ensure that there exists a Binding Cache entry for 4956 its home address so that the correspondent node can process the 4957 packet. A mobile node SHOULD arrange to supply the home address 4958 in a Home Address option, and allowing the IPv6 header's Source 4959 Address field to be set to one of the mobile node's care-of 4960 addresses; the correspondent node will then use the address 4961 supplied in the Home Address option to serve the function 4962 traditionally done by the Source IP address in the IPv6 header. 4963 The mobile node's home address is then supplied to higher protocol 4964 layers and applications. Specifically: 4966 * Construct the packet using the mobile node's home address as 4967 the packet's Source Address, in the same way as if the mobile 4968 node were at home. This includes the calculation of upper 4969 layer checksums using the home address as the value of the 4970 source. 4972 * Insert a Home Address option into the packet, with the Home 4973 Address field copied from the original value of the Source 4974 Address field in the packet. 4976 * Change the Source Address field in the packet's IPv6 header to 4977 one of the mobile node's care-of addresses. This will 4978 typically be the mobile node's current primary care-of address, 4979 but MUST be an address assigned to the interface on the link 4980 being used. 4982 By using the care-of address as the Source Address in the IPv6 4983 header, with the mobile node's home address instead in the Home 4984 Address option, the packet will be able to safely pass through any 4985 router implementing ingress filtering [26]. 4987 Reverse Tunneling 4989 This is the mechanism which tunnels the packets via the home 4990 agent. It isn't as efficient as the above mechanism, but is 4991 needed if there is no binding yet with the correspondent node. 4992 This mechanism is used for packets that have the mobile node's 4993 home address as the Source Address in the IPv6 header, or with 4994 multicast control protocol packets as described in Section 11.3.4. 4995 Specifically: 4997 * The packet is sent to the home agent using IPv6 encapsulation 4998 [15]. 5000 * The Source Address in the tunnel packet is the primary care-of 5001 address as registered with the home agent. 5003 * The Destination Address in the tunnel packet is the home 5004 agent's address. 5006 Then, the home agent will pass the encapsulated packet to the 5007 correspondent node. 5009 11.3.2 Interaction with Outbound IPsec Processing 5011 This section sketches the interaction between outbound Mobile IPv6 5012 processing and outbound IP Security (IPsec) processing for packets 5013 sent by a mobile node while away from home. Any specific 5014 implementation MAY use algorithms and data structures other than 5015 those suggested here, but its processing MUST be consistent with the 5016 effect of the operation described here and with the relevant IPsec 5017 specifications. In the steps described below, it is assumed that 5018 IPsec is being used in transport mode [4] and that the mobile node is 5019 using its home address as the source for the packet (from the point 5020 of view of higher protocol layers or applications, as described in 5021 Section 11.3.1): 5023 o The packet is created by higher layer protocols and applications 5024 (e.g., by TCP) as if the mobile node were at home and Mobile IPv6 5025 were not being used. 5027 o As part of outbound packet processing in IP, the packet is 5028 compared against the IPsec security policy database to determine 5029 what processing is required for the packet [4]. 5031 o If IPsec processing is required, the packet is either mapped to an 5032 existing Security Association (or SA bundle), or a new SA (or SA 5033 bundle) is created for the packet, according to the procedures 5034 defined for IPsec. 5036 o Since the mobile node is away from home, the mobile is either 5037 using reverse tunneling or route optimization to reach the 5038 correspondent node. 5040 If reverse tunneling is used, the packet is constructed in the 5041 normal manner and then tunneled through the home agent. If route 5042 optimization is in use, the mobile node inserts a Home Address 5043 destination option into the packet, replacing the Source Address 5044 in the packet's IP header with a care-of address suitable for the 5045 link on which the packet is being sent, as described in Section 5046 11.3.1. The Destination Options header in which the Home Address 5047 destination option is inserted MUST appear in the packet after the 5048 routing header, if present, and before the IPsec (AH [5] or ESP 5049 [6]) header, so that the Home Address destination option is 5050 processed by the destination node before the IPsec header is 5051 processed. Finally, once the packet is fully assembled, the 5052 necessary IPsec authentication (and encryption, if required) 5053 processing is performed on the packet, initializing the 5054 Authentication Data in the IPsec header. RFC 2402 treatment of 5055 destination options is extended as follows. The AH authentication 5056 data MUST be calculated as if the following were true: 5058 * the IPv6 source address in the IPv6 header contains the mobile 5059 node's home address, 5061 * the Home Address field of the Home Address destination option 5062 (Section 6.3) contains the new care-of address. 5064 o This allows, but does not require, the receiver of the packet 5065 containing a Home Address destination option to exchange the two 5066 fields of the incoming packet to reach the above situation, 5067 simplifying processing for all subsequent packet headers. 5068 However, such an exchange is not required, as long as the result 5069 of the authentication calculation remains the same. 5071 When an automated key management protocol is used to create new 5072 security associations for a peer, it is important to ensure that the 5073 peer can send the key management protocol packets to the mobile node. 5074 This may not be possible if the peer is the home agent of the mobile 5075 node, and the purpose of the security associations would be to send a 5076 Binding Update to the home agent. Packets addressed to the home 5077 address of the mobile node cannot be used before the Binding Update 5078 has been processed. For the default case of using IKE [9] as the 5079 automated key management protocol, such problems can be avoided by 5080 the following requirements when communicating with its home agent: 5082 o When the mobile node is away from home, it MUST use its care-of 5083 address as the Source Address of all packets it sends as part of 5084 the key management protocol (without use of Mobile IPv6 for these 5085 packets, as suggested in Section 11.3.1). 5087 o In addition, for all security associations bound to the mobile 5088 node's home address established by IKE, the mobile node MUST 5089 include an ISAKMP Identification Payload [8] in the IKE exchange, 5090 giving the mobile node's home address as the initiator of the 5091 Security Association [7]. 5093 The Key Management Mobility Capability (K) bit in Binding Updates and 5094 Acknowledgements can be used avoid the need to rerun IKE upon 5095 movements. 5097 11.3.3 Receiving Packets While Away from Home 5099 While away from home, a mobile node will receive packets addressed to 5100 its home address, by one of three methods: 5102 o Packets sent by a correspondent node that does not have a Binding 5103 Cache entry for the mobile node, will be sent to the home address, 5104 captured by the home agent and tunneled to the mobile node 5106 o Packets sent by a correspondent node that has a Binding Cache 5107 entry for the mobile node that contains the mobile node's current 5108 care-of address, will be sent by the correspondent node using a 5109 type 2 routing header. The packet will be addressed to the mobile 5110 node's care-of address, with the final hop in the routing header 5111 directing the packet to the mobile node's home address; the 5112 processing of this last hop of the routing header is entirely 5113 internal to the mobile node, since the care-of address and home 5114 address are both addresses within the mobile node. 5116 For packets received by the first of these methods, the mobile node 5117 MUST check that the IPv6 source address of the tunneled packet is the 5118 IP address of its home agent. In this method the mobile node may 5119 also send a Binding Update to the original sender of the packet, as 5120 described in Section 11.7.2, subject to the rate limiting defined in 5121 Section 11.8. The mobile node MUST also process the received packet 5122 in the manner defined for IPv6 encapsulation [15], which will result 5123 in the encapsulated (inner) packet being processed normally by 5124 upper-layer protocols within the mobile node, as if it had been 5125 addressed (only) to the mobile node's home address. 5127 For packets received by the second method, the following rules will 5128 result in the packet being processed normally by upper-layer 5129 protocols within the mobile node, as if it had been addressed to the 5130 mobile node's home address. 5132 A node receiving a packet addressed to itself (i.e., one of the 5133 node's addresses is in the IPv6 destination field) follows the next 5134 header chain of headers and processes them. When it encounters a 5135 type 2 routing header during this processing it performs the 5136 following checks. If any of these checks fail the node MUST silently 5137 discard the packet. 5139 o The length field in the routing header is exactly 2. 5141 o The segments left field in the routing header is 1 on the wire. 5142 (But implementations may process the routing header so that the 5143 value may become 0 after the routing header has been processed, 5144 but before the rest of the packet is processed.) 5146 o The Home Address field in the routing header is one of the node's 5147 home addresses, if the segments left field was 1. Thus, in 5148 particular the address field is required to be a unicast routable 5149 address. 5151 Once the above checks have been performed, the node swaps the IPv6 5152 destination field with the Home Address field in the routing header, 5153 decrements segments left by one from the value it had on the wire, 5154 and resubmits the packet to IP for processing the next header. 5155 Conceptually this follows the same model as in RFC 2460. However, in 5156 the case of type 2 routing header this can be simplified since it is 5157 known that the packet will not be forwarded to a different node. 5159 The definition of AH requires the sender to calculate the AH 5160 integrity check value of a routing header in a way as it appears in 5161 the receiver after it has processed the header. Since IPsec headers 5162 follow the routing header, any IPsec processing will operate on the 5163 packet with the home address in the IP destination field and segments 5164 left being zero. Thus, the AH calculations at the sender and 5165 receiver will have an identical view of the packet. 5167 11.3.4 Routing Multicast Packets 5169 A mobile node that is connected to its home link functions in the 5170 same way as any other (stationary) node. Thus, when it is at home, a 5171 mobile node functions identically to other multicast senders and 5172 receivers. This section therefore describes the behavior of a mobile 5173 node that is not on its home link. 5175 In order to receive packets sent to some multicast group, a mobile 5176 node must join that multicast group. One method by which a mobile 5177 node MAY join the group is via a (local) multicast router on the 5178 foreign link being visited. In this case, the mobile node MUST use 5179 its care-of address and MUST NOT use the Home Address destination 5180 option when sending MLD packets [17]. 5182 Alternatively, a mobile node MAY join multicast groups via a 5183 bi-directional tunnel to its home agent. The mobile node tunnels its 5184 multicast group membership control packets (such as those defined in 5185 [17] or in [35]) to its home agent, and the home agent forwards 5186 multicast packets down the tunnel to the mobile node. A mobile node 5187 MUST NOT tunnel multicast group membership control packets until (1) 5188 the mobile node has a binding in place at the home agent, and (2) the 5189 latter sends at least one such multicast group membership control 5190 packet via the tunnel. Once this condition is true, the mobile node 5191 SHOULD assume it does not change as long as the binding does not 5192 expire. 5194 A mobile node that wishes to send packets to a multicast group also 5195 has two options: 5197 1. Send directly on the foreign link being visited. 5199 The application is aware of the care-of address and uses it for 5200 multicast traffic just like any other stationary address. The 5201 mobile node MUST NOT use Home Address destination option in such 5202 traffic. 5204 2. Send via a tunnel to its home agent. 5206 Because multicast routing in general depends upon the Source 5207 Address used in the IPv6 header of the multicast packet, a mobile 5208 node that tunnels a multicast packet to its home agent MUST use 5209 its home address as the IPv6 Source Address of the inner 5210 multicast packet. 5212 Note that direct sending from the foreign link is only applicable 5213 while the mobile node is at that foreign link. This is because the 5214 associated multicast tree is specific to that source location and any 5215 change of location and source address will invalidate the source 5216 specific tree or branch and the application context of the other 5217 multicast group members. 5219 This specification does not provide mechanisms to enable such local 5220 multicast session to survive hand-off, and to seamlessly continue 5221 from a new care-of address on each new foreign link. Any such 5222 mechanism, developed as an extension to this specification, needs to 5223 take into account the impact of fast moving mobile nodes on the 5224 Internet multicast routing protocols and their ability to maintain 5225 the integrity of source specific multicast trees and branches. 5227 While the use of reverse tunneling can ensure that multicast trees 5228 are independent of the mobile nodes movement, in some case such 5229 tunneling can have adverse affects. The latency of specific types of 5230 multicast applications such as multicast based discovery protocols 5231 will be affected when the round-trip time between the foreign subnet 5232 and the home agent is significant compared to that of the topology to 5233 be discovered. In addition, the delivery tree from the home agent in 5234 such circumstances relies on unicast encapsulation from the agent to 5235 the mobile node and is therefore bandwidth inefficient compared to 5236 the native multicast forwarding in the foreign multicast system. 5238 11.3.5 Receiving ICMP Error Messages 5240 Any node that doesn't recognize the Mobility header will return an 5241 ICMP Parameter Problem, Code 1, message to the sender of the packet. 5242 If the mobile node receives such an ICMP error message in response to 5243 a return routability procedure or Binding Update, it SHOULD record in 5244 its Binding Update List that future Binding Updates SHOULD NOT be 5245 sent to this destination. 5247 New Binding Update List entries MUST NOT be created as a result of 5248 receiving ICMP error messages. 5250 Correspondent nodes that have participated in the return routability 5251 procedure MUST implement the ability to correctly process received 5252 packets containing a Home Address destination option. Therefore, 5253 correctly implemented correspondent nodes should always be able to 5254 recognize Home Address options. If a mobile node receives an ICMP 5255 Parameter Problem, Code 2, message from some node indicating that it 5256 does not support the Home Address option, the mobile node SHOULD log 5257 the error and then discard the ICMP message. 5259 11.3.6 Receiving Binding Error Messages 5261 When a mobile node receives a packet containing a Binding Error 5262 message, it should first check if the mobile node has a Binding 5263 Update List entry for the source of the Binding Error message. If 5264 the mobile node does not have such an entry, it MUST ignore the 5265 message. This is necessary to prevent a waste of resources on e.g. 5266 return routability procedure due to spoofed Binding Error messages. 5268 Otherwise, if the message Status field was 1 (unknown binding for 5269 Home Address destination option), the mobile node should perform one 5270 of the following two actions: 5272 o If the mobile node has recent upper layer progress information 5273 that indicates communications with the correspondent node are 5274 progressing, it MAY ignore the message. This can be done in order 5275 to limit the damage that spoofed Binding Error messages can cause 5276 to ongoing communications. 5278 o If the mobile node has no upper layer progress information, it 5279 MUST remove the entry and route further communications through the 5280 home agent. It MAY also optionally start a return routability 5281 procedure (see Section 5.2). 5283 If the message Status field was 2 (unrecognized MH Type value), the 5284 mobile node should perform one of the following two actions: 5286 o If the mobile node is not expecting an acknowledgement or response 5287 from the correspondent node, the mobile node SHOULD ignore this 5288 message. 5290 o Otherwise, the mobile node SHOULD cease the use of any extensions 5291 to this specification. If no extensions had been used, the mobile 5292 node should cease the attempt to use route optimization. 5294 11.4 Home Agent and Prefix Management 5296 11.4.1 Dynamic Home Agent Address Discovery 5298 Sometimes, when the mobile node needs to send a Binding Update to its 5299 home agent to register its new primary care-of address, as described 5300 in Section 11.7.1, the mobile node may not know the address of any 5301 router on its home link that can serve as a home agent for it. For 5302 example, some nodes on its home link may have been reconfigured while 5303 the mobile node has been away from home, such that the router that 5304 was operating as the mobile node's home agent has been replaced by a 5305 different router serving this role. 5307 In this case, the mobile node MAY attempt to discover the address of 5308 a suitable home agent on its home link. To do so, the mobile node 5309 sends an ICMP Home Agent Address Discovery Request message to the 5310 Mobile IPv6 Home-Agents anycast address [16] for its home subnet 5311 prefix. As described in Section 10.5, the home agent on its home 5312 link that receives this Request message will return an ICMP Home 5313 Agent Address Discovery Reply message. This message gives the 5314 addresses for the home agents operating on the home link. 5316 The mobile node, upon receiving this Home Agent Address Discovery 5317 Reply message, MAY then send its home registration Binding Update to 5318 any of the unicast IP addresses listed in the Home Agent Addresses 5319 field in the Reply. For example, the mobile node MAY attempt its 5320 home registration to each of these addresses, in turn, until its 5321 registration is accepted. The mobile node sends a Binding Update to 5322 an address and waits for the matching Binding Acknowledgement, moving 5323 on to the next address if there is no response. The mobile node 5324 MUST, however, wait at least InitialBindackTimeoutFirstReg seconds 5325 (see Section 13) before sending a Binding Update to the next home 5326 agent. In trying each of the returned home agent addresses, the 5327 mobile node SHOULD try each in the order listed in the Home Agent 5328 Addresses field in the received Home Agent Address Discovery Reply 5329 message. 5331 If the mobile node has a current registration with some home agent 5332 (the Lifetime for that registration has not yet expired), then the 5333 mobile node MUST attempt any new registration first with that home 5334 agent. If that registration attempt fails (e.g., times out or is 5335 rejected), the mobile node SHOULD then reattempt this registration 5336 with another home agent. If the mobile node knows of no other 5337 suitable home agent, then it MAY attempt the dynamic home agent 5338 address discovery mechanism described above. 5340 If, after a mobile node transmits a Home Agent Address Discovery 5341 Request message to the Home Agents Anycast address, it does not 5342 receive a corresponding Home Agent Address Discovery Reply message 5343 within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile 5344 node MAY retransmit the same Request message to the same anycast 5345 address. This retransmission MAY be repeated up to a maximum of 5346 DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be 5347 delayed by twice the time interval of the previous retransmission. 5349 11.4.2 Sending Mobile Prefix Solicitations 5351 When a mobile node has a home address that is about to become 5352 invalid, it SHOULD send a Mobile Prefix Solicitation to its home 5353 agent in an attempt to acquire fresh routing prefix information. The 5354 new information also enables the mobile node to participate in 5355 renumbering operations affecting the home network, as described in 5356 Section 10.6. 5358 The mobile node MUST use the Home Address destination option to carry 5359 its home address. The mobile node MUST support and SHOULD use IPsec 5360 to protect the solicitation. The mobile node MUST set the Identifier 5361 field in the ICMP header to a random value. 5363 As described in Section 11.7.2, Binding Updates sent by the mobile 5364 node to other nodes MUST use a lifetime no greater than the remaining 5365 lifetime of its home registration of its primary care-of address. 5366 The mobile node SHOULD further limit the lifetimes that it sends on 5367 any Binding Updates to be within the remaining valid lifetime (see 5368 Section 10.6.2) for the prefix in its home address. 5370 When the lifetime for a changed prefix decreases, and the change 5371 would cause cached bindings at correspondent nodes in the Binding 5372 Update List to be stored past the newly shortened lifetime, the 5373 mobile node MUST issue a Binding Update to all such correspondent 5374 nodes. 5376 These limits on the binding lifetime serve to prohibit use of a 5377 mobile node's home address after it becomes invalid. 5379 11.4.3 Receiving Mobile Prefix Advertisements 5381 Section 10.6 describes the operation of a home agent to support boot 5382 time configuration and renumbering a mobile node's home subnet while 5383 the mobile node is away from home. The home agent sends Mobile 5384 Prefix Advertisements to the mobile node while away from home, giving 5385 "important" Prefix Information options that describe changes in the 5386 prefixes in use on the mobile node's home link. 5388 The Mobile Prefix Solicitation is similar to the Router Solicitation 5389 used in Neighbor Discovery [12], except it is routed from the mobile 5390 node on the visited network to the home agent on the home network by 5391 usual unicast routing rules. 5393 When a mobile node receives a Mobile Prefix Advertisement, it MUST 5394 validate it according to the following test: 5396 o The Source Address of the IP packet carrying the Mobile Prefix 5397 Advertisement is the same as the home agent address to which the 5398 mobile node last sent an accepted home registration Binding Update 5399 to register its primary care-of address. Otherwise, if no such 5400 registrations have been made, it SHOULD be the mobile node's 5401 stored home agent address, if one exists. Otherwise, if the 5402 mobile node has not yet discovered its home agent's address, it 5403 MUST NOT accept Mobile Prefix Advertisements. 5405 o The packet MUST have a type 2 routing header and SHOULD be 5406 protected by an IPsec header as described in Section 5.4 and 5407 Section 6.8. 5409 o If a solicitation has been sent recently, the ICMP Identifier 5410 value MUST be the same as in the solicitation. 5412 Any received Mobile Prefix Advertisement not meeting these tests MUST 5413 be silently discarded. 5415 If the advertisement was unsolicited, the mobile node SHOULD send a 5416 Mobile Prefix Solicitation. 5418 For an accepted Mobile Prefix Advertisement, the mobile node MUST 5419 process Managed Address Configuration (M), Other Stateful 5420 Configuration (O), and the Prefix Information Options as if they 5421 arrived in a Router Advertisement [12] on the mobile node's home 5422 link. (This specification does not, however, describe how to acquire 5423 home addresses through stateful protocols.) Such processing may 5424 result in the mobile node configuring a new home address, although 5425 due to separation between preferred lifetime and valid lifetime, such 5426 changes should not affect most communications by the mobile node, in 5427 the same way as for nodes that are at home. 5429 This specification assumes that any security associations and 5430 security policy entries that may be needed for new prefixes have been 5431 pre-configured in the mobile node. Note that while dynamic key 5432 management avoids the need to create new security associations, it is 5433 still necessary to add policy entries to protect the communications 5434 involving the home address(es). Mechanisms for automatic set-up of 5435 these entries are outside the scope of this specification. 5437 11.5 Movement 5439 11.5.1 Movement Detection 5441 The primary movement detection mechanism for Mobile IPv6 defined in 5442 this section uses the facilities of IPv6 Neighbor Discovery, 5443 including Router Discovery and Neighbor Unreachability Detection. 5444 The mobile node SHOULD supplement this mechanism with other 5445 information whenever it is available to the mobile node (e.g., from 5446 lower protocol layers). The description here is based on the 5447 conceptual model of the organization and data structures defined by 5448 Neighbor Discovery [12]. 5450 Mobile nodes SHOULD use Router Discovery to discover new routers and 5451 on-link subnet prefixes; a mobile node MAY send Router Solicitations, 5452 or MAY wait for unsolicited (periodic) multicast Router 5453 Advertisements, as specified for Router Discovery [12]. Based on 5454 received Router Advertisements, a mobile node maintains an entry in 5455 its Default Router List for each router, and an entry in its Prefix 5456 List for each subnet prefix that it currently considers to be 5457 on-link. Each entry in these lists has an associated invalidation 5458 timer value. While away from home, a mobile node typically selects 5459 one default router and one subnet prefix to use as the subnet prefix 5460 in its primary care-of address. A mobile node MAY also have 5461 associated additional care-of addresses, using other subnet prefixes 5462 from its Prefix List. The method by which a mobile node selects and 5463 forms a care-of address from the available subnet prefixes is 5464 described in Section 11.5.2. The mobile node registers its primary 5465 care-of address with its home agent, as described in Section 11.7.1. 5467 While a mobile node is away from home, it is important for the mobile 5468 node to quickly detect when its default router becomes unreachable. 5469 When this happens, the mobile node SHOULD switch to a new default 5470 router and potentially to a new primary care-of address. If, on the 5471 other hand, the mobile node becomes unreachable from its default 5472 router, it should attempt to become reachable through some other 5473 router. To detect when its default router becomes unreachable, a 5474 mobile node SHOULD use Neighbor Unreachability Detection. 5476 For a mobile node to detect when it has become unreachable from its 5477 default router, the mobile node cannot efficiently rely on Neighbor 5478 Unreachability Detection alone, since the network overhead would be 5479 prohibitively high in many cases. Instead, when a mobile node 5480 receives any IPv6 packets from its current default router at all, 5481 irrespective of the source IPv6 address, it SHOULD use that as an 5482 indication that it is still reachable from the router. 5484 Since the router sends periodic unsolicited multicast Router 5485 Advertisements, the mobile node will have an opportunity to check if 5486 it is still reachable from its default router, even in the absence of 5487 other packets to it from the router. If Router Advertisements that 5488 the mobile node receives include an Advertisement Interval option, 5489 the mobile node MAY use its Advertisement Interval field as an 5490 indication of the frequency with which it SHOULD expect to continue 5491 to receive future Advertisements from that router. This field 5492 specifies the minimum rate (the maximum amount of time between 5493 successive Advertisements) that the mobile node SHOULD expect. If 5494 this amount of time elapses without the mobile node receiving any 5495 Advertisement from this router, the mobile node can be sure that at 5496 least one Advertisement sent by the router has been lost. It is thus 5497 possible for the mobile node to implement its own policy for 5498 determining the number of Advertisements from its current default 5499 router it is willing to tolerate losing before deciding to switch to 5500 a different router from which it may currently be correctly receiving 5501 Advertisements. 5503 On some types of network interfaces, the mobile node MAY also 5504 supplement this monitoring of Router Advertisements, by setting its 5505 network interface into "promiscuous" receive mode, so that it is able 5506 to receive all packets on the link, including those not addressed to 5507 it at the link layer (i.e., disabling link-level address filtering). 5509 The mobile node will then be able to detect any packets sent by the 5510 router, in order to detect reachability from the router. This use of 5511 promiscuous mode may be useful on very low bandwidth (e.g., wireless) 5512 links. If this mode is supported, its use MUST be configurable, 5513 since it is likely to consume additional energy resources. 5515 If the above means do not provide indication that the mobile node is 5516 still reachable from its current default router (for instance, the 5517 mobile node receives no packets from the router for a period of 5518 time), then the mobile node SHOULD attempt to actively probe the 5519 router with Neighbor Solicitations, even if it is not otherwise 5520 actively sending packets to the router. If it receives a solicited 5521 Neighbor Advertisement in response from the router, then the mobile 5522 node can deduce that it is still reachable. It is expected that the 5523 mobile node will in most cases be able to determine its reachability 5524 from the router by listening for packets from the router as described 5525 above, and thus, such extra Neighbor Solicitation probes should 5526 rarely be necessary. 5528 With some types of networks, indications about link-layer mobility 5529 might be obtained from lower-layer protocol or device driver software 5530 within the mobile node. However, all link-layer mobility indications 5531 from lower layers do not necessarily indicate a movement of the 5532 mobile node to a new link, such that the mobile node would need to 5533 switch to a new default router and primary care-of address. For 5534 example, movement of a mobile node from one cell to another in many 5535 wireless LANs can be made transparent to the IP level through use of 5536 a link-layer "roaming" protocol, as long as the different wireless 5537 LAN cells all operate as part of the same IP link with the same 5538 subnet prefix. Upon lower-layer indication of link-layer mobility, 5539 the mobile node SHOULD send Router Solicitations to determine if 5540 additional on-link subnet prefixes are available on its new link. 5541 The mobile node SHOULD also mark its link-local address as tentative, 5542 and follow standard Duplicate Address Detection procedures [13]. 5544 Such lower-layer information might also be useful to a mobile node in 5545 deciding to switch its primary care-of address to one of the other 5546 care-of addresses it has formed from the on-link subnet prefixes 5547 currently available through different routers from which the mobile 5548 node is reachable. For example, a mobile node MAY use signal 5549 strength or signal quality information (with suitable hysteresis) for 5550 its link with the available routers to decide when to switch to a new 5551 primary care-of address using that router rather than its current 5552 default router (and current primary care-of address). Even though 5553 the mobile node's current default router may still be reachable in 5554 terms of Neighbor Unreachability Detection, the mobile node MAY use 5555 such lower-layer information to determine that switching to a new 5556 default router would provide a better connection. 5558 11.5.2 Forming New Care-of Addresses 5560 After detecting that it has moved from one link to another (i.e., its 5561 current default router has become unreachable and it has discovered a 5562 new default router), a mobile node SHOULD generate a new primary 5563 care-of address using normal IPv6 mechanisms. A mobile node MAY form 5564 a new primary care-of address at any time, but a mobile node MUST NOT 5565 send a Binding Update about a new care-of address to its home agent 5566 more than MAX_UPDATE_RATE times within a second. 5568 In addition, a mobile node MAY form new non-primary care-of addresses 5569 even when it has not switched to a new default router. A mobile node 5570 can have only one primary care-of address at a time (which is 5571 registered with its home agent), but it MAY have an additional 5572 care-of address for any or all of the prefixes on its current link. 5573 Furthermore, since a wireless network interface may actually allow a 5574 mobile node to be reachable on more than one link at a time (i.e., 5575 within wireless transmitter range of routers on more than one 5576 separate link), a mobile node MAY have care-of addresses on more than 5577 one link at a time. The use of more than one care-of address at a 5578 time is described in Section 11.5.3. 5580 As described in Section 4, in order to form a new care-of address, a 5581 mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6 5582 [28]) Address Autoconfiguration. If a mobile node needs to use a 5583 source address (other than the unspecified address) in packets sent 5584 as a part of address autoconfiguration, it MUST use an IPv6 5585 link-local address rather than its own IPv6 home address. 5587 RFC 2462 [13] specifies that in normal processing for Duplicate 5588 Address Detection, the node SHOULD delay sending the initial Neighbor 5589 Solicitation message by a random delay between 0 and 5590 MAX_RTR_SOLICITATION_DELAY. Since delaying DAD can result in 5591 significant delays in configuring a new care-of address when the 5592 Mobile Node moves to a new link, the Mobile Node preferably SHOULD 5593 NOT delay DAD when configuring a new care-of address. The Mobile 5594 Node SHOULD delay according to the mechanisms specified in RFC 2462 5595 unless the implementation has a behavior that desynchronizes the 5596 steps that happen before the DAD in the case that multiple nodes 5597 experience handover at the same time. Such desynchronizing behaviors 5598 might be due to random delays in the L2 protocols or device drivers, 5599 or due to the movement detection mechanism that is used. 5601 11.5.3 Using Multiple Care-of Addresses 5603 As described in Section 11.5.2, a mobile node MAY use more than one 5604 care-of address at a time. Particularly in the case of many wireless 5605 networks, a mobile node effectively might be reachable through 5606 multiple links at the same time (e.g., with overlapping wireless 5607 cells), on which different on-link subnet prefixes may exist. The 5608 mobile node MUST ensure that its primary care-of address always has a 5609 prefix that is considered on-link by its current default router, 5610 i.e., advertised by its current default router in a solicited Router 5611 Advertisement. After selecting a new primary care-of address, the 5612 mobile node MUST send a Binding Update containing that care-of 5613 address to its home agent. The Binding Update MUST have the Home 5614 Registration (H) and Acknowledge (A) bits set its home agent, as 5615 described on Section 11.7.1. 5617 To assist with smooth handovers, a mobile node SHOULD retain its 5618 previous primary care-of address as a (non-primary) care-of address, 5619 and SHOULD still accept packets at this address, even after 5620 registering its new primary care-of address with its home agent. 5621 This is reasonable, since the mobile node could only receive packets 5622 at its previous primary care-of address if it were indeed still 5623 connected to that link. If the previous primary care-of address was 5624 allocated using stateful Address Autoconfiguration [28], the mobile 5625 node may not wish to release the address immediately upon switching 5626 to a new primary care-of address. 5628 Whenever a mobile node determines that it is no longer reachable 5629 through a given link, it SHOULD invalidate all care-of addresses 5630 associated with address prefixes that it discovered from routers on 5631 the unreachable link which are not in the current set of address 5632 prefixes advertised by the (possibly new) current default router. 5634 11.5.4 Returning Home 5636 A mobile node detects that it has returned to its home link through 5637 the movement detection algorithm in use (Section 11.5.1), when the 5638 mobile node detects that its home subnet prefix is again on-link. 5639 The mobile node SHOULD then send a Binding Update to its home agent, 5640 to instruct its home agent to no longer intercept or tunnel packets 5641 for it. In this home registration, the mobile node MUST set the 5642 Acknowledge (A) and Home Registration (H) bits, set the Lifetime 5643 field to zero, and set the care-of address for the binding to the 5644 mobile node's own home address. The mobile node MUST use its home 5645 address as the source address in the Binding Update. 5647 When sending this Binding Update to its home agent, the mobile node 5648 must be careful in how it uses Neighbor Solicitation [12] (if needed) 5649 to learn the home agent's link-layer address, since the home agent 5650 will be currently configured to intercept packets to the mobile 5651 node's home address using Duplicate Address Detection (DAD). In 5652 particular, the mobile node is unable to use its home address as the 5653 Source Address in the Neighbor Solicitation until the home agent 5654 stops defending the home address. 5656 Neighbor Solicitation by the mobile node for the home agent's address 5657 will normally not be necessary, since the mobile node has already 5658 learned the home agent's link-layer address from a Source Link-Layer 5659 Address option in a Router Advertisement. However, if there are 5660 multiple home agents it may still be necessary to send a 5661 solicitation. In this special case of the mobile node returning 5662 home, the mobile node MUST multicast the packet, and in addition set 5663 the Source Address of this Neighbor Solicitation to the unspecified 5664 address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation 5665 MUST be set to the mobile node's home address. The destination IP 5666 address MUST be set to the Solicited-Node multicast address [3]. The 5667 home agent will send a multicast Neighbor Advertisement back to the 5668 mobile node with the Solicited flag (S) set to zero. In any case, 5669 the mobile node SHOULD record the information from the Source 5670 Link-Layer Address option or from the advertisement, and set the 5671 state of the Neighbor Cache entry for the home agent to REACHABLE. 5673 The mobile node then sends its Binding Update to the home agent's 5674 link-layer address, instructing its home agent to no longer serve as 5675 a home agent for it. By processing this Binding Update, the home 5676 agent will cease defending the mobile node's home address for 5677 Duplicate Address Detection and will no longer respond to Neighbor 5678 Solicitations for the mobile node's home address. The mobile node is 5679 then the only node on the link receiving packets at the mobile node's 5680 home address. In addition, when returning home prior to the 5681 expiration of a current binding for its home address, and configuring 5682 its home address on its network interface on its home link, the 5683 mobile node MUST NOT perform Duplicate Address Detection on its own 5684 home address, in order to avoid confusion or conflict with its home 5685 agent's use of the same address. If the mobile node returns home 5686 after the bindings for all of its care-of addresses have expired, 5687 then it SHOULD perform DAD. 5689 After the Mobile Node sends the Binding Update, it MUST be prepared 5690 to reply to Neighbor Solicitations from its home agent. The replies 5691 MUST be sent using a unicast Neighbor Advertisement to the home 5692 agent's link-layer address. 5694 After receiving the Binding Acknowledgement for its Binding Update to 5695 its home agent, the mobile node MUST multicast onto the home link (to 5696 the all-nodes multicast address) a Neighbor Advertisement [12], to 5697 advertise the mobile node's own link-layer address for its own home 5698 address. The Target Address in this Neighbor Advertisement MUST be 5699 set to the mobile node's home address, and the Advertisement MUST 5700 include a Target Link-layer Address option specifying the mobile 5701 node's link-layer address. The mobile node MUST multicast such a 5702 Neighbor Advertisement for each of its home addresses, as defined by 5703 the current on-link prefixes, including its link-local address and 5704 site-local address. The Solicited Flag (S) in these Advertisements 5705 MUST NOT be set, since they were not solicited by any Neighbor 5706 Solicitation. The Override Flag (O) in these Advertisements MUST be 5707 set, indicating that the Advertisements SHOULD override any existing 5708 Neighbor Cache entries at any node receiving them. 5710 Since multicasting on the local link (such as Ethernet) is typically 5711 not guaranteed to be reliable, the mobile node MAY retransmit these 5712 Neighbor Advertisements [12] up to MAX_NEIGHBOR_ADVERTISEMENT times 5713 to increase their reliability. It is still possible that some nodes 5714 on the home link will not receive any of these Neighbor 5715 Advertisements, but these nodes will eventually be able to recover 5716 through use of Neighbor Unreachability Detection [12]. 5718 11.6 Return Routability Procedure 5720 This section defines the rules that the mobile node must follow when 5721 performing the return routability procedure. Section 11.7.2 5722 describes the rules when the return routability procedure needs to be 5723 initiated. 5725 11.6.1 Sending Test Init Messages 5727 A mobile node that initiates a return routability procedure MUST send 5728 (in parallel) a Home Test Init message and a Care-of Test Init 5729 messages. However, if the mobile node has recently received (see 5730 Section 5.2.7) one or both home or care-of keygen tokens, and 5731 associated nonce indices for the desired addresses, it MAY reuse 5732 them. Therefore, the return routability procedure may in some cases 5733 be completed with only one message pair. It may even be completed 5734 without any messages at all, if the mobile node has a recent home 5735 keygen token and and has previously visited the same care-of address 5736 so that it also has a recent care-of keygen token. If the mobile 5737 node intends to send a Binding Update with the Lifetime set to zero 5738 and the care-of address equal to its home address - such as when 5739 returning home - sending a Home Test Init message is sufficient. In 5740 this case, generation of the binding management key depends 5741 exclusively on the home keygen token (Section 5.2.5). 5743 A Home Test Init message MUST be created as described in Section 5744 6.1.3. A Care-of Test Init message MUST be created as described in 5745 Section 6.1.4. When sending a Home Test Init or Care-of Test Init 5746 message the mobile node MUST record in its Binding Update List the 5747 following fields from the messages: 5749 o The IP address of the node to which the message was sent. 5751 o The home address of the mobile node. This value will appear in 5752 the Source Address field of the Home Test Init message. When 5753 sending the Care-of Test Init message, this address does not 5754 appear in the message, but represents the home address for which 5755 the binding is desired. 5757 o The time at which each of these messages was sent. 5759 o The cookies used in the messages. 5761 Note that a single Care-of Test Init message may be sufficient even 5762 when there are multiple home addresses. In this case the mobile node 5763 MAY record the same information in multiple Binding List entries. 5765 11.6.2 Receiving Test Messages 5767 Upon receiving a packet carrying a Home Test message, a mobile node 5768 MUST validate the packet according to the following tests: 5770 o The Source Address of the packet belongs to a correspondent node 5771 for which the mobile node has a Binding Update List entry with a 5772 state indicating that return routability procedure is in progress. 5773 Note that there may be multiple such entries. 5775 o The Binding Update List indicates that no home keygen token has 5776 been received yet. 5778 o The Destination Address of the packet has the home address of the 5779 mobile node, and the packet has been received in a tunnel from the 5780 home agent. 5782 o The Home Init Cookie field in the message matches the value stored 5783 in the Binding Update List. 5785 Any Home Test message not satisfying all of these tests MUST be 5786 silently ignored. Otherwise, the mobile node MUST record the Home 5787 Nonce Index and home keygen token in the Binding Update List. If the 5788 Binding Update List entry does not have a care-of keygen token, the 5789 mobile node SHOULD continue waiting for additional messages. 5791 Upon receiving a packet carrying a Care-of Test message, a mobile 5792 node MUST validate the packet according to the following tests: 5794 o The Source Address of the packet belongs to a correspondent node 5795 for which the mobile node has a Binding Update List entry with a 5796 state indicating that return routability procedure is in progress. 5797 Note that there may be multiple such entries. 5799 o The Binding Update List indicates that no care-of keygen token has 5800 been received yet. 5802 o The Destination Address of the packet is the current care-of 5803 address of the mobile node. 5805 o The Care-of Init Cookie field in the message matches the value 5806 stored in the Binding Update List. 5808 Any Care-of Test message not satisfying all of these tests MUST be 5809 silently ignored. Otherwise, the mobile node MUST record the Care-of 5810 Nonce Index and care-of keygen token in the Binding Update List. If 5811 the Binding Update List entry does not have a home keygen token, the 5812 mobile node SHOULD continue waiting for additional messages. 5814 If after receiving either the Home Test or the Care-of Test message 5815 and performing the above actions, the Binding Update List entry has 5816 both the home and the care-of keygen tokens, the return routability 5817 procedure is complete. The mobile node SHOULD then proceed with 5818 sending a Binding Update as described in Section 11.7.2. 5820 Correspondent nodes from the time before this specification was 5821 published may not support the Mobility Header protocol. These nodes 5822 will respond to Home Test Init and Care-of Test Init messages with an 5823 ICMP Parameter Problem code 1. The mobile node SHOULD take such 5824 messages as an indication that the correspondent node cannot provide 5825 route optimization, and revert back to the use of bidirectional 5826 tunneling. 5828 11.6.3 Protecting Return Routability Packets 5830 The mobile node MUST support the protection of Home Test and Home 5831 Test Init messages as described in Section 10.4.6. 5833 When IPsec is used to protect return routability signaling or payload 5834 packets, the mobile node MUST set the source address it uses for the 5835 outgoing tunnel packets to the current primary care-of address. The 5836 mobile node starts to use a new primary care-of address immediately 5837 after sending a Binding Update to the home agent to register this new 5838 address. 5840 11.7 Processing Bindings 5842 11.7.1 Sending Binding Updates to the Home Agent 5844 After deciding to change its primary care-of address as described in 5845 Section 11.5.1 and Section 11.5.2, a mobile node MUST register this 5846 care-of address with its home agent in order to make this its primary 5847 care-of address. 5849 Also, if the mobile node wants the services of the home agent beyond 5850 the current registration period, the mobile node should send a new 5851 Binding Update to it well before the expiration of this period, even 5852 if it is not changing its primary care-of address. However, if the 5853 home agent returned a Binding Acknowledgement for the current 5854 registration with Status field set to 1 (accepted but prefix 5855 discovery necessary), the mobile node should not try to register 5856 again before it has learned the validity of its home prefixes through 5857 prefix discovery. This is typically necessary every time this Status 5858 value is received, because information learned through prefix 5859 discovery on an earlier registration may have changed. 5861 To register a care-of address or to extend the lifetime of an 5862 existing registration, the mobile node sends a packet to its home 5863 agent containing a Binding Update, with the packet constructed as 5864 follows: 5866 o The Home Registration (H) bit MUST be set in the Binding Update. 5868 o The Acknowledge (A) bit MUST be set in the Binding Update. 5870 o The packet MUST contain a Home Address destination option, giving 5871 the mobile node's home address for the binding. 5873 o The care-of address for the binding MUST be used as the Source 5874 Address in the packet's IPv6 header, unless an Alternate Care-of 5875 Address mobility option is included in the Binding Update. This 5876 option MUST be included in all home registrations, as the ESP 5877 protocol will not be able to protect care-of addresses in the IPv6 5878 header. (Mobile IPv6 implementations that know they are using 5879 IPsec AH to protect a particular message might avoid this option. 5880 For brevity the usage of AH is not discussed in this document.) 5882 o If the mobile node's link-local address has the same interface 5883 identifier as the home address for which it is supplying a new 5884 care-of address, then the mobile node SHOULD set the Link-Local 5885 Address Compatibility (L) bit. 5887 o If the home address was generated using RFC 3041 [18], then the 5888 link local address is unlikely to have a compatible interface 5889 identifier. In this case, the mobile node MUST clear the 5890 Link-Local Address Compatibility (L) bit. 5892 o If the IPsec security associations between the mobile node and the 5893 home agent have been established dynamically, and the mobile node 5894 has the capability to update its endpoint in the used key 5895 management protocol to the new care-of address every time it 5896 moves, the mobile node SHOULD set the Key Management Mobility 5897 Capability (K) bit in the Binding Update. Otherwise, the mobile 5898 node MUST clear the bit. 5900 o The value specified in the Lifetime field SHOULD be less than or 5901 equal to the remaining valid lifetime of the home address and the 5902 care-of address specified for the binding. 5904 Mobile nodes that use dynamic home agent address discovery should 5905 be careful with long lifetimes. If the mobile node loses the 5906 knowledge of its binding with a specific home agent, registering a 5907 new binding with another home agent may be impossible as the 5908 previous home agent is still defending the existing binding. 5909 Therefore, mobile nodes that use home agent address discovery 5910 SHOULD ensure information about their bindings is not lost, 5911 de-register before losing this information, or use small 5912 lifetimes. 5914 The Acknowledge (A) bit in the Binding Update requests the home agent 5915 to return a Binding Acknowledgement in response to this Binding 5916 Update. As described in Section 6.1.8, the mobile node SHOULD 5917 retransmit this Binding Update to its home agent until it receives a 5918 matching Binding Acknowledgement. Once reaching a retransmission 5919 timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart 5920 the process of delivering the Binding Update, but trying instead the 5921 next home agent returned during dynamic home agent address discovery 5922 (see Section 11.4.1). If there was only one home agent, the mobile 5923 node instead SHOULD continue to periodically retransmit the Binding 5924 Update at this rate until acknowledged (or until it begins attempting 5925 to register a different primary care-of address). See Section 11.8 5926 for information about retransmitting Binding Updates. 5928 With the Binding Update, the mobile node requests the home agent to 5929 serve as the home agent for the given home address. Until the 5930 lifetime of this registration expires, the home agent considers 5931 itself the home agent for this home address. 5933 Each Binding Update MUST be authenticated as coming from the right 5934 mobile node, as defined in Section 5.1. The mobile node MUST use its 5935 home address - either in the Home Address destination option or in 5936 the Source Address field of the IPv6 header - in Binding Updates sent 5937 to the home agent. This is necessary in order to allow the IPsec 5938 policies to be matched with the right home address. 5940 When sending a Binding Update to its home agent, the mobile node MUST 5941 also create or update the corresponding Binding Update List entry, as 5942 specified in Section 11.7.2. 5944 The last Sequence Number value sent to the home agent in a Binding 5945 Update is stored by the mobile node. If the sending mobile node has 5946 no knowledge of the right Sequence Number value, it may start at any 5947 value. If the home agent rejects the value, it sends back a Binding 5948 Acknowledgement with status code 135, and the last accepted sequence 5949 number in the Sequence Number field of the Binding Acknowledgement. 5950 The mobile node MUST store this information and use the next Sequence 5951 Number value for the next Binding Update it sends. 5953 If the mobile node has additional home addresses using a different 5954 interface identifier, then the mobile node SHOULD send an additional 5955 packet containing a Binding Update to its home agent to register the 5956 care-of address for each such other home address (or set of home 5957 addresses sharing an interface identifier). 5959 The home agent will only perform DAD for the mobile node's home 5960 address when the mobile node has supplied a valid binding between its 5961 home address and a care-of address. If some time elapses during 5962 which the mobile node has no binding at the home agent, it might be 5963 possible for another node to autoconfigure the mobile node's home 5964 address. Therefore, the mobile node MUST treat creation of a new 5965 binding with the home agent using an existing home address the same 5966 as creation of a new home address. In the unlikely event that the 5967 mobile node's home address is autoconfigured as the IPv6 address of 5968 another network node on the home network, the home agent will reply 5969 to the mobile node's subsequent Binding Update with a Binding 5970 Acknowledgement containing a Status of 134 (Duplicate Address 5971 Detection failed). In this case, the mobile node MUST NOT attempt to 5972 re-use the same home address. It SHOULD continue to register care-of 5973 addresses for its other home addresses, if any. The mobile node MAY 5974 also attempt to acquire a new home address to replace the one for 5975 which Status 134 was received, for instance by using the techniques 5976 described in Appendix B.5. 5978 11.7.2 Correspondent Binding Procedure 5980 When the mobile node is assured that its home address is valid, it 5981 can initiate a correspondent binding procedure with the purpose of 5982 allowing the correspondent node to cache the mobile node's current 5983 care-of address. This procedure consists of the return routability 5984 procedure followed by a binding procedure. 5986 This section defines when to initiate the correspondent binding 5987 procedure, and rules to follow when performing it. 5989 After the mobile node has sent a Binding Update to its home agent to 5990 register a new primary care-of address (as described in Section 5991 11.7.1), the mobile node SHOULD initiate a correspondent binding 5992 procedure for each node that already appears in the mobile node's 5993 Binding Update List. This is necessary in order to ensure that 5994 correspondent nodes do not have invalid information about the current 5995 location of the mobile node. The initiated procedures can be used to 5996 either update or delete binding information in the correspondent 5997 node. 5999 For nodes that do not appear in the mobile node's Binding Update 6000 List, the mobile node MAY initiate a correspondent binding procedure 6001 at any time after sending the Binding Update to its home agent. 6002 Considerations regarding when (and if) to initiate the procedure 6003 depend on the specific movement and traffic patterns of the mobile 6004 node and are outside the scope of this document. 6006 In addition, when a mobile node receives a packet for which the 6007 mobile node can deduce that the original sender of the packet has a 6008 stale Binding Cache entry for the mobile node, the mobile node SHOULD 6009 initiate a correspondent binding procedure. In addition, the mobile 6010 node MAY initiate the procedure in response to receiving a packet 6011 that meets all of the following tests: 6013 o The packet was tunneled using IPv6 encapsulation. 6015 o The Destination Address in the tunnel (outer) IPv6 header is equal 6016 to any of the mobile node's care-of addresses. 6018 o The Destination Address in the original (inner) IPv6 header is 6019 equal to one of the mobile node's home addresses. 6021 o The Source Address in the tunnel (outer) IPv6 header differs from 6022 the Source Address in the original (inner) IPv6 header. 6024 o The packet does not contain a Care-of Test Init message. 6026 If a mobile node has multiple home addresses, it becomes important to 6027 select the right home address to use in the correspondent binding 6028 procedure. The used home address MUST be the Destination Address of 6029 the original (inner) packet. 6031 The peer address used in the procedure MUST be determined as follows: 6033 o If a Home Address destination option is present in the original 6034 (inner) packet, the address from this option is used. 6036 o Otherwise, the Source Address in the original (inner) IPv6 header 6037 of the packet is used. 6039 Note that the validity of the original packet is checked before 6040 attempting to initiate a correspondent binding procedure. For 6041 instance, if a Home Address destination option appeared in the 6042 original packet, then rules in Section 9.3.1 are followed. 6044 A mobile node MAY also choose to keep its location private from 6045 certain correspondent nodes, and thus need not initiate the 6046 correspondent binding procedure. 6048 Upon successfully completing the return routability procedure, and 6049 after receiving a successful Binding Acknowledgement from the Home 6050 Agent, a Binding Update MAY be sent to the correspondent node. 6052 In any Binding Update sent by a mobile node, the care-of address 6053 (either the Source Address in the packet's IPv6 header or the Care-of 6054 Address in the Alternate Care-of Address mobility option of the 6055 Binding Update) MUST be set to one of the care-of addresses currently 6056 in use by the mobile node or to the mobile node's home address. A 6057 mobile node MAY set the care-of address differently for sending 6058 Binding Updates to different correspondent nodes. 6060 A mobile node MAY also send a Binding Update to such a correspondent 6061 node to instruct it to delete any existing binding for the mobile 6062 node from its Binding Cache, as described in Section 6.1.7. Even in 6063 this case a successful completion of the return routability procedure 6064 is required first. 6066 If set to one of the mobile node's current care-of addresses, the 6067 Binding Update requests the correspondent node to create or update an 6068 entry for the mobile node in the correspondent node's Binding Cache 6069 in order to record this care-of address for use in sending future 6070 packets to the mobile node. In this case, the value specified in the 6071 Lifetime field sent in the Binding Update SHOULD be less than or 6072 equal to the remaining lifetime of the home registration and the 6073 care-of address specified for the binding. The care-of address given 6074 in the Binding Update MAY differ from the mobile node's primary 6075 care-of address. 6077 If the Binding Update is sent to request the correspondent node to 6078 delete any existing Binding Cache entry that it has for the mobile 6079 node, the care-of address is set to the mobile node's home address 6080 and the Lifetime field set to zero. In this case, generation of the 6081 binding management key depends exclusively on the home keygen token 6082 (Section 5.2.5). The care-of nonce index SHOULD be set to zero in 6083 this case. In keeping with the Binding Update creation rules below, 6084 the care-of address MUST be set to the home address if the mobile 6085 node is at home, or to the current care-of address if it is away from 6086 home. 6088 If the mobile node wants to ensure that its new care-of address has 6089 been entered into a correspondent node's Binding Cache, the mobile 6090 node MAY request an acknowledgement by setting the Acknowledge (A) 6091 bit in the Binding Update. In this case, however, the mobile node 6092 SHOULD NOT continue to retransmit the Binding Update once the 6093 retransmission timeout period has reached MAX_BINDACK_TIMEOUT. 6095 A Binding Update is created as follows: 6097 o The Source Address of the IPv6 header MUST contain the current 6098 care-of address of the mobile node. 6100 o The Destination Address of the IPv6 header MUST contain the 6101 address of the correspondent node. 6103 o The Mobility Header is constructed according to rules in Section 6104 6.1.7 and Section 5.2.6, including the Binding Authorization Data 6105 (calculated as defined in Section 6.2.7) and possibly the Nonce 6106 Indices mobility options. 6108 o The home address of the mobile node MUST be added to the packet in 6109 a Home Address destination option, unless the Source Address is 6110 the home address. 6112 Each Binding Update MUST have a Sequence Number greater than the 6113 Sequence Number value sent in the previous Binding Update to the same 6114 destination address (if any). The sequence numbers are compared 6115 modulo 2**16, as described in Section 9.5.1. There is no 6116 requirement, however, that the Sequence Number value strictly 6117 increase by 1 with each new Binding Update sent or received, as long 6118 as the value stays within the window. The last Sequence Number value 6119 sent to a destination in a Binding Update is stored by the mobile 6120 node in its Binding Update List entry for that destination. If the 6121 sending mobile node has no Binding Update List entry, the Sequence 6122 Number SHOULD start at a random value. The mobile node MUST NOT use 6123 the same Sequence Number in two different Binding Updates to the same 6124 correspondent node, even if the Binding Updates provide different 6125 care-of addresses. 6127 The mobile node is responsible for the completion of the 6128 correspondent binding procedure, as well as any retransmissions that 6129 may be needed (subject to the rate limiting defined in Section 11.8). 6131 11.7.3 Receiving Binding Acknowledgements 6133 Upon receiving a packet carrying a Binding Acknowledgement, a mobile 6134 node MUST validate the packet according to the following tests: 6136 o The packet meets the authentication requirements for Binding 6137 Acknowledgements, defined in Section 6.1.8 and Section 5. That 6138 is, if the Binding Update was sent to the home agent, underlying 6139 IPsec protection is used. If the Binding Update was sent to the 6140 correspondent node, the Binding Authorization Data mobility option 6141 MUST be present and have a valid value. 6143 o The Binding Authorization Data mobility option, if present, MUST 6144 be the last option and MUST not have trailing padding. 6146 o The Sequence Number field matches the Sequence Number sent by the 6147 mobile node to this destination address in an outstanding Binding 6148 Update. 6150 Any Binding Acknowledgement not satisfying all of these tests MUST be 6151 silently ignored. 6153 When a mobile node receives a packet carrying a valid Binding 6154 Acknowledgement, the mobile node MUST examine the Status field as 6155 follows: 6157 o If the Status field indicates that the Binding Update was accepted 6158 (the Status field is less than 128), then the mobile node MUST 6159 update the corresponding entry in its Binding Update List to 6160 indicate that the Binding Update has been acknowledged; the mobile 6161 node MUST then stop retransmitting the Binding Update. In 6162 addition, if the value specified in the Lifetime field in the 6163 Binding Acknowledgement is less than the Lifetime value sent in 6164 the Binding Update being acknowledged, then the mobile node MUST 6165 subtract the difference between these two Lifetime values from the 6166 remaining lifetime for the binding as maintained in the 6167 corresponding Binding Update List entry (with a minimum value for 6168 the Binding Update List entry lifetime of 0). That is, if the 6169 Lifetime value sent in the Binding Update was L_update, the 6170 Lifetime value received in the Binding Acknowledgement was L_ack, 6171 and the current remaining lifetime of the Binding Update List 6172 entry is L_remain, then the new value for the remaining lifetime 6173 of the Binding Update List entry should be 6175 max((L_remain - (L_update - L_ack)), 0) 6177 where max(X, Y) is the maximum of X and Y. The effect of this 6178 step is to correctly manage the mobile node's view of the 6179 binding's remaining lifetime (as maintained in the corresponding 6180 Binding Update List entry) so that it correctly counts down from 6181 the Lifetime value given in the Binding Acknowledgement, but with 6182 the timer countdown beginning at the time that the Binding Update 6183 was sent. Mobile nodes SHOULD send a new Binding Update well 6184 before the expiration of this period in order to extend the 6185 lifetime. This helps to avoid disruptions in communications, 6186 which might otherwise be caused by network delays or clock drift. 6188 o Additionally, if the Status field value is 1 (Accepted but prefix 6189 discovery necessary), the mobile node SHOULD send a Mobile Prefix 6190 Solitation message to update its information about the available 6191 prefixes. 6193 o If the Status field indicates that the Binding Update was rejected 6194 (the Status field is greater than or equal to 128), then the 6195 mobile node SHOULD record in its Binding Update List that future 6196 Binding Updates SHOULD NOT be sent to this destination. 6198 Optionally, the mobile node MAY then take steps to correct the 6199 cause of the error and retransmit the Binding Update (with a new 6200 Sequence Number value), subject to the rate limiting restriction 6201 specified in Section 11.8. 6203 The treatment of a Binding Refresh Advice mobility option within the 6204 Binding Acknowledgement depends on the where the acknowledgement came 6205 from. This option MUST be ignored if the acknowledgement came from a 6206 correspondent node. If it came from the home agent, the mobile node 6207 uses Refresh Interval field in the option as a suggestion that it 6208 SHOULD attempt to refresh its home registration at the indicated 6209 shorter interval. 6211 If the acknowledgement came from the home agent, the mobile node 6212 examines the value of the Key Management Mobility Capability (K) bit. 6213 If this bit is not set, the mobile node SHOULD discard key management 6214 protocol connections, if any, to the home agent. The mobile node MAY 6215 also initiate a new key management connection. 6217 If this bit is set, the mobile node SHOULD move its own endpoint in 6218 the key management protocol connections to the home agent, if any. 6219 The mobile node's new endpoint should be the new care-of address. 6220 For an IKE phase 1 connection, this means packets sent to this 6221 address with the original ISAKMP cookies are accepted. 6223 11.7.4 Receiving Binding Refresh Requests 6225 When a mobile node receives a packet containing a Binding Refresh 6226 Request message, the mobile node has a Binding Update List entry for 6227 the source of the Binding Refresh Request, and the mobile node wants 6228 to retain its binding cache entry at the correspondent node, then the 6229 mobile node should start a return routability procedure. If the 6230 mobile node wants to have its binding cache entry removed it can 6231 either ignore the Binding Refresh Request and wait for the binding to 6232 time out, or it can at any time delete its binding from a 6233 correspondent node with an explicit binding update with zero lifetime 6234 and the care-of address set to the home address. If the mobile node 6235 does not know if it needs the binding cache entry, it can make the 6236 decision in an implementation dependent manner, such as based on 6237 available resources. 6239 Note that the mobile node should be careful to not respond to Binding 6240 Refresh Requests for addresses not in the Binding Update List to 6241 avoid being subjected to a denial of service attack. 6243 If the return routability procedure completes successfully, a Binding 6244 Update message SHOULD be sent as described in Section 11.7.2. The 6245 Lifetime field in this Binding Update SHOULD be set to a new 6246 lifetime, extending any current lifetime remaining from a previous 6247 Binding Update sent to this node (as indicated in any existing 6248 Binding Update List entry for this node), and lifetime SHOULD again 6249 be less than or equal to the remaining lifetime of the home 6250 registration and the care-of address specified for the binding. When 6251 sending this Binding Update, the mobile node MUST update its Binding 6252 Update List in the same way as for any other Binding Update sent by 6253 the mobile node. 6255 11.8 Retransmissions and Rate Limiting 6257 The mobile node is responsible for retransmissions and rate limiting 6258 in the return routability and binding procedures and for solicited 6259 prefix discovery. 6261 When the mobile node sends a Mobile Prefix Solicitation, Home Test 6262 Init, Care-of Test Init or Binding Update for which it expects a 6263 response, the mobile node has to determine a value for the initial 6264 retransmission timer: 6266 o If the mobile node is sending a Mobile Prefix Solicitation, it 6267 SHOULD use an initial retransmission interval of 6268 INITIAL_SOLICIT_TIMER (see Section 12). 6270 o If the mobile node is sending a Binding Update and it does not 6271 have an existing binding at the home agent, it SHOULD use 6272 InitialBindackTimeoutFirstReg (see Section 13) as a value for the 6273 initial retransmission timer. This long retransmission interval 6274 will allow the home agent to complete the Duplicate Address 6275 Detection procedure which is mandated in this case, as detailed in 6276 Section 11.7.1. 6278 o Otherwise, the mobile node should use the specified value of 6279 INITIAL_BINDACK_TIMEOUT for the initial retransmission timer. 6281 If the mobile node fails to receive a valid, matching response within 6282 the selected initial retransmission interval, the mobile node SHOULD 6283 retransmit the message, until a response is received. 6285 The retransmissions by the mobile node MUST use an exponential 6286 back-off process, in which the timeout period is doubled upon each 6287 retransmission until either the node receives a response or the 6288 timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile 6289 node MAY continue to send these messages at this slower rate 6290 indefinitely. 6292 The mobile node SHOULD start a separate back-off process for 6293 different message types, different home addresses and different 6294 care-of addresses. However, in addition an overall rate limitation 6295 applies for messages sent to a particular correspondent node. This 6296 ensures that the correspondent node has sufficient amount of time to 6297 answer when bindings for multiple home addresses are registered, for 6298 instance. The mobile node MUST NOT send Mobility Header messages of 6299 a particular type to a particular correspondent node more than 6300 MAX_UPDATE_RATE times within a second. 6302 Retransmitted Binding Updates MUST use a Sequence Number value 6303 greater than that used for the previous transmission of this Binding 6304 Update. Retransmitted Home Test Init and Care-of Test Init messages 6305 MUST use new cookie values. 6307 12. Protocol Constants 6309 DHAAD_RETRIES 4 retransmissions 6310 INITIAL_BINDACK_TIMEOUT 1 second 6311 INITIAL_DHAAD_TIMEOUT 3 seconds 6312 INITIAL_SOLICIT_TIMER 3 seconds 6313 MAX_BINDACK_TIMEOUT 32 seconds 6314 MAX_NONCE_LIFETIME 240 seconds 6315 MAX_TOKEN_LIFETIME 210 seconds 6316 MAX_RR_BINDING_LIFETIME 420 seconds 6317 MAX_UPDATE_RATE 3 times 6318 PREFIX_ADV_RETRIES 3 retransmissions 6319 PREFIX_ADV_TIMEOUT 3 seconds 6321 13. Protocol Configuration Variables 6323 MaxMobPfxAdvInterval Default: 86,400 seconds 6324 MinDelayBetweenRAs Default: 3 seconds, 6325 Min: 0.03 seconds 6326 MinMobPfxAdvInterval Default: 600 seconds 6327 InitialBindackTimeoutFirstReg Default: 1.5 seconds 6329 Home agents MUST allow the first three variables to be configured by 6330 system management, and mobile nodes MUST allow the last variable to 6331 be configured by system management. 6333 The default value for InitialBindackTimeoutFirstReg has been 6334 calculated as 1.5 times the default value of RetransTimer [12] times 6335 the default value of DupAddrDetectTransmits [13]. 6337 The value MinDelayBetweenRAs overrides the value of the protocol 6338 constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 [12]. This 6339 variable SHOULD be set to MinRtrAdvInterval, if MinRtrAdvInterval is 6340 less than 3 seconds. 6342 14. IANA Considerations 6344 This document defines a new IPv6 protocol, the Mobility Header, 6345 described in Section 6.1. This protocol must be assigned a protocol 6346 number. 6348 This document also creates a new name space "Mobility Header Type", 6349 for the MH Type field in the Mobility Header. The current message 6350 types are described starting from Section 6.1.2, and are the 6351 following: 6353 0 Binding Refresh Request 6355 1 Home Test Init 6357 2 Care-of Test Init 6359 3 Home Test 6361 4 Care-of Test 6363 5 Binding Update 6365 6 Binding Acknowledgement 6367 7 Binding Error 6369 Future values of the MH Type can be allocated using standards action 6370 [10]. 6372 Furthermore, each mobility message may contain mobility options as 6373 described in Section 6.2. This document defines a new name space 6374 "Mobility Option" to identify these options. The current mobility 6375 options are defined starting from Section 6.2.2 and are the 6376 following: 6378 0 Pad1 6380 1 PadN 6382 2 Binding Refresh Advice 6384 3 Alternate Care-of Address 6386 4 Nonce Indices 6387 5 Authorization Data 6389 Future values of the Option Type can be allocated using standards 6390 action [10]. 6392 This document also defines a new IPv6 destination option, the Home 6393 Address option, described in Section 6.3. This option has already 6394 been assigned the Option Type value 0xC9. 6396 This document also defines a new IPv6 type 2 routing header, 6397 described in Section 6.4. The value 2 is to be allocated by IANA 6398 when this specification becomes an RFC. 6400 In addition, this document defines four ICMP message types, two used 6401 as part of the dynamic home agent address discovery mechanism and two 6402 used in lieu of Router Solicitations and Advertisements when the 6403 mobile node is away from the home link. These messages must be 6404 assigned ICMPv6 type numbers from the informational message range: 6406 o The Home Agent Address Discovery Request message, described in 6407 Section 6.5; 6409 o The Home Agent Address Discovery Reply message, described in 6410 Section 6.6; 6412 o The Mobile Prefix Solicitation, described in Section 6.7; and 6414 o The Mobile Prefix Advertisement, described in Section 6.8. 6416 This document also defines two new Neighbor Discovery [12] options, 6417 which must be assigned Option Type values within the option numbering 6418 space for Neighbor Discovery messages: 6420 o The Advertisement Interval option, described in Section 7.3; and 6422 o The Home Agent Information option, described in Section 7.4. 6424 15. Security Considerations 6426 15.1 Threats 6428 Any mobility solution must protect itself against misuses of the 6429 mobility features and mechanisms. In Mobile IPv6, most of the 6430 potential threats are concerned with false Bindings, usually 6431 resulting in Denial-of-Service attacks. Some of the threats also 6432 pose potential for Man-in-the-Middle, Hijacking, Confidentiality, and 6433 Impersonation attacks. The main threats this protocol protects 6434 against are the following: 6436 o Threats involving Binding Updates sent to home agents and 6437 correspondent nodes. For instance, an attacker might claim that a 6438 certain mobile node is currently at a different location than it 6439 really is. If a home agent accepts such spoofed information sent 6440 to it, the mobile node might not get traffic destined to it. 6441 Similarly, a malicious (mobile) node might use the home address of 6442 a victim node in a forged Binding Update sent to a correspondent 6443 node. 6445 These pose threats against confidentiality, integrity, and 6446 availability. That is, an attacker might learn the contents of 6447 packets destined to another node by redirecting the traffic to 6448 itself. Furthermore, an attacker might use the redirected packets 6449 in an attempt to set itself as a Man-in-the-Middle between a 6450 mobile and a correspondent node. This would allow the attacker to 6451 impersonate the mobile node, leading to integrity and availability 6452 problems. A malicious (mobile) node might also send Binding 6453 Updates in which the care-of address is set to the address of a 6454 victim node. If such Binding Updates were accepted, the malicious 6455 node could lure the correspondent node into sending potentially 6456 large amounts of data to the victim; the correspondent node's 6457 replies to messages sent by the malicious mobile node will be sent 6458 to the victim host or network. This could be used to cause a 6459 Distributed Denial-of-Service attack. For example, the 6460 correspondent node might be a site that will send a high-bandwidth 6461 stream of video to anyone who asks for it. Note that the use of 6462 flow-control protocols such as TCP does not necessarily defend 6463 against this type of attack, because the attacker can fake the 6464 acknowledgements. Even keeping TCP initial sequence numbers 6465 secret doesn't help, because the attacker can receive the first 6466 few segments (including the ISN) at its own address, and only then 6467 redirect the stream to the victim's address. These types of 6468 attacks may also be directed to networks instead of nodes. 6469 Further variations of this threat are described elsewhere 6470 [27, 32]. An attacker might also attempt to disrupt a mobile 6471 node's communications by replaying a Binding Update that the node 6472 had sent earlier. If the old Binding Update was accepted, packets 6473 destined for the mobile node would be sent to its old location and 6474 not its current location. In conclusion, there are 6475 Denial-of-Service, Man-in-the-Middle, Confidentiality, and 6476 Impersonation threats against the parties involved in sending 6477 legitimate Binding Updates, and Denial-of-Service threats against 6478 any other party. 6480 o Threats associated with payload packets: Payload packets exchanged 6481 with mobile nodes are exposed to similar threats as regular IPv6 6482 traffic is. However, Mobile IPv6 introduces the Home Address 6483 destination option, a new routing header type (type 2), and uses 6484 tunneling headers in the payload packets. The protocol must 6485 protect against potential new threats involving the use of these 6486 mechanisms. 6488 Third parties become exposed to a reflection threat via the Home 6489 Address destination option, unless appropriate security 6490 precautions are followed. The Home Address destination option 6491 could be used to direct response traffic toward a node whose IP 6492 address appears in the option. In this case, ingress filtering 6493 would not catch the forged "return address" [34, 30]. A similar 6494 threat exists with the tunnels between the mobile node and the 6495 home agent. An attacker might forge tunnel packets between the 6496 mobile node and the home agent, making it appear that the traffic 6497 is coming from the mobile node when it is not. Note that an 6498 attacker who is able to forge tunnel packets would typically be 6499 able forge also packets that appear to come directly from the 6500 mobile node. This is not a new threat as such. However, it may 6501 make it easier for attackers to escape detection by avoiding 6502 ingress filtering and packet tracing mechanisms. Furthermore, 6503 spoofed tunnel packets might be used to gain access to the home 6504 network. Finally, a routing header could also be used in 6505 reflection attacks, and in attacks designed to bypass firewalls. 6506 The generality of the regular routing header would allow 6507 circumvention of IP-address based rules in firewalls. It would 6508 also allow reflection of traffic to other nodes. These threats 6509 exist with routing headers in general, even if the usage that 6510 Mobile IPv6 requires is safe. 6512 o Threats associated with dynamic home agent and prefix discovery. 6514 o Threats against the Mobile IPv6 security mechanisms themselves: An 6515 attacker might, for instance, lure the participants into executing 6516 expensive cryptographic operations or allocating memory for the 6517 purpose of keeping state. The victim node would have no resources 6518 left to handle other tasks. 6520 As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to 6521 be deployed in most nodes of the IPv6 Internet. The above threats 6522 should therefore be considered in the light of being applicable to 6523 the whole Internet. 6525 It should also be noted that some additional threats result from 6526 movements as such, even without the involvement of mobility 6527 protocols. Mobile nodes must be capable to defend themselves in the 6528 networks that they visit, as typical perimeter defenses applied in 6529 the home network no longer protect them. 6531 15.2 Features 6533 This specification provides a series of features designed to mitigate 6534 the risk introduced by the threats listed above. The main security 6535 features are the following: 6537 o Reverse Tunneling as a mandatory feature. 6539 o Protection of Binding Updates sent to home agents. 6541 o Protection of Binding Updates sent to correspondent nodes. 6543 o Protection against reflection attacks that use the Home Address 6544 destination option. 6546 o Protection of tunnels between the mobile node and the home agent. 6548 o Closing routing header vulnerabilities. 6550 o Mitigating Denial-of-Service threats to the Mobile IPv6 security 6551 mechanisms themselves. 6553 The support for encrypted reverse tunneling (see Section 11.3.1) 6554 allows mobile nodes to defeat certain kinds of traffic analysis. 6556 Protecting those Binding Updates that are sent to home agents and 6557 those that are sent to arbitrary correspondent nodes requires very 6558 different security solutions due to the different situations. Mobile 6559 nodes and home agents are expected to be naturally subject to the 6560 network administration of the home domain. 6562 Thus, they can and are supposed to have a security association that 6563 can be used to reliably authenticate the exchanged messages. See 6564 Section 5.1 for the description of the protocol mechanisms, and 6565 Section 15.3 below for a discussion of the resulting level of 6566 security. 6568 It is expected that Mobile IPv6 route optimization will be used on a 6569 global basis between nodes belonging to different administrative 6570 domains. It would be a very demanding task to build an 6571 authentication infrastructure on this scale. Furthermore, a 6572 traditional authentication infrastructure cannot be easily used to 6573 authenticate IP addresses, because IP addresses can change often. It 6574 is not sufficient to just authenticate the mobile nodes. 6575 Authorization to claim the right to use an address is needed as well. 6576 Thus, an "infrastructureless" approach is necessary. The chosen 6577 infrastructureless method is described in Section 5.2 and Section 6578 15.4 discusses the resulting security level and the design rationale 6579 of this approach. 6581 Specific rules guide the use of the Home Address destination option, 6582 the routing header, and the tunneling headers in the payload packets. 6583 These rules are necessary to remove the vulnerabilities associated 6584 with their unrestricted use. The effect of the rules is discussed in 6585 Section 15.7, Section 15.8, and Section 15.9. 6587 Denial-of-Service threats against Mobile IPv6 security mechanisms 6588 themselves concern mainly the Binding Update procedures with 6589 correspondent nodes. The protocol has been designed to limit the 6590 effects of such attacks, as will be described in Section 15.4.5. 6592 15.3 Binding Updates to Home Agent 6594 Signaling between the mobile node and the home agent requires message 6595 integrity, correct ordering and replay protection. This is necessary 6596 to assure the home agent that a Binding Update is from a legitimate 6597 mobile node. 6599 IPsec ESP protects the integrity of the Binding Updates and Binding 6600 Acknowledgements, by securing mobility messages between the mobile 6601 node and the home agent. 6603 However, IPsec can easily provide replay protection only if dynamic 6604 security association establishment is used. IPsec also does not 6605 guarantee correct ordering of packets, only that they have not been 6606 replayed. Because of this, sequence numbers with the Mobile IPv6 6607 messages ensure correct ordering (see Section 5.1). However, if a 6608 home agent reboots and loses its state regarding the sequence 6609 numbers, replay attacks become possible. The use of a key management 6610 mechanism together with IPsec can be used to prevent such replay 6611 attacks. 6613 A sliding window scheme is used for the sequence numbers. The 6614 protection against replays and reordering attacks without a key 6615 management mechanism works when the attacker remembers up to a 6616 maximum of 2**15 Binding Updates. 6618 The above mechanisms do not show that the care-of address given in 6619 the Binding Update is correct. This opens the possibility for 6620 Denial-of-Service attacks against third parties. However, since the 6621 mobile node and home agent have a security association, the home 6622 agent can always identify an ill-behaving mobile node. This allows 6623 the home agent operator to discontinue the mobile node's service, and 6624 possibly take further actions based on the business relationship with 6625 the mobile node's owner. 6627 Note that the use of a single pair of manually keyed security 6628 associations conflicts with the generation of a new home addresses 6629 [18] for the mobile node, or with the adoption of a new home subnet 6630 prefix. This is because IPsec security associations are bound to the 6631 used addresses. While certificate-based automatic keying alleviates 6632 this problem to an extent, it is still necessary to ensure that a 6633 given mobile node cannot send Binding Updates for the address of 6634 another mobile node. In general, this leads to the inclusion of home 6635 addresses in certificates in the Subject AltName field. This again 6636 limits the introduction of new addresses without either manual or 6637 automatic procedures to establish new certificates. Therefore, this 6638 specification restricts the generation of new home addresses (for any 6639 reason) to those situations where there already exists a security 6640 association or certificate for the new address. (Appendix B.4 lists 6641 the improvement of security for new addresses as one of the future 6642 developments for Mobile IPv6.) 6644 15.4 Binding Updates to Correspondent Nodes 6646 15.4.1 Overview 6648 The motivation for designing the return routability procedure was to 6649 have sufficient support for Mobile IPv6, without creating significant 6650 new security problems. The goal for this procedure was not to 6651 protect against attacks that were already possible before the 6652 introduction of Mobile IPv6. 6654 The chosen infrastructureless method verifies that the mobile node is 6655 "live" (that is, it responds to probes) at its home and care-of 6656 addresses. Section 5.2 describes the return routability procedure in 6657 detail. The procedure uses the following principles: 6659 o A message exchange verifies that the mobile node is reachable at 6660 its addresses i.e. is at least able to transmit and receive 6661 traffic at both the home and care-of addresses. 6663 o The eventual Binding Update is cryptographically bound to the 6664 tokens supplied in the exchanged messages. 6666 o Symmetric exchanges are employed to avoid the use of this protocol 6667 in reflection attacks. In a symmetric exchange, the responses are 6668 always sent to the same address as the request was sent from. 6670 o The correspondent node operates in a stateless manner until it 6671 receives a fully authorized Binding Update. 6673 o Some additional protection is provided by encrypting the tunnels 6674 between the mobile node and home agent with IPsec ESP. As the 6675 tunnel transports also the nonce exchanges, this limits the 6676 ability of attackers to see these nonces. For instance, this 6677 prevents attacks launched from the mobile node's current foreign 6678 link where no link-layer confidentiality is available. 6680 The resulting level of security is in theory the same even without 6681 this additional protection: the return routability tokens are 6682 still exposed only to one path within the whole Internet. 6683 However, the mobile nodes are often found on an insecure link, 6684 such as a public access Wireless LAN. Thus this addition makes a 6685 practical difference in many cases. 6687 For further information about the design rationale of the return 6688 routability procedure, see [27, 32, 31, 30]. The used mechanisms 6689 have been adopted from these documents. 6691 15.4.2 Achieved Security Properties 6693 The return routability procedure protects Binding Updates against all 6694 attackers who are unable to monitor the path between the home agent 6695 and the correspondent node. The procedure does not defend against 6696 attackers who can monitor this path. Note that such attackers are in 6697 any case able to mount an active attack against the mobile node when 6698 it is at its home location. The possibility of such attacks is not 6699 an impediment to the deployment of Mobile IPv6, because these attacks 6700 are possible regardless of whether Mobile IPv6 is in use. 6702 This procedure also protects against Denial-of-Service attacks in 6703 which the attacker pretends to be a mobile, but uses the victim's 6704 address as the care-of address. This would cause the correspondent 6705 node to send the victim some unexpected traffic. The procedure 6706 defends against these attacks by requiring at least passive presence 6707 of the attacker at the care-of address or on the path from the 6708 correspondent to the care-of address. Normally, this will be the 6709 mobile node. 6711 15.4.3 Comparison to Regular IPv6 Communications 6713 This section discusses the protection offered by the return 6714 routability method by comparing it to the security of regular IPv6 6715 communications. We will divide vulnerabilities in three classes: (1) 6716 those related to attackers on the local network of the mobile node, 6717 home agent, or the correspondent node, (2) those related to attackers 6718 on the path between the home network and the correspondent node, and 6719 (3) off-path attackers, i.e. the rest of the Internet. 6721 We will now discuss the vulnerabilities of regular IPv6 6722 communications. The on-link vulnerabilities of IPv6 communications 6723 include Denial-of-Service, Masquerading, Man-in-the-Middle, 6724 Eavesdropping, and other attacks. These attacks can be launched 6725 through spoofing Router Discovery, Neighbor Discovery and other IPv6 6726 mechanisms. Some of these attacks can be prevented with the use of 6727 cryptographic protection in the packets. 6729 A similar situation exists with on-path attackers. That is, without 6730 cryptographic protection the traffic is completely vulnerable. 6732 Assuming that attackers have not penetrated the security of the 6733 Internet routing protocols, attacks are much harder to launch from 6734 off-path locations. Attacks that can be launched from these 6735 locations are mainly Denial-of-Service attacks, such as flooding and/ 6736 or reflection attacks. It is not possible for an off-path attacker 6737 to become a Man-in-the-Middle. 6739 Next, we will consider the vulnerabilities that exist when IPv6 is 6740 used together with Mobile IPv6 and the return routability procedure. 6741 On the local link the vulnerabilities are same as those as in IPv6, 6742 but Masquerade and Man-in-the-Middle attacks can now be launched also 6743 against future communications, and not just against current 6744 communications. If a Binding Update was sent while the attacker was 6745 present on the link, its effects stay during the lifetime of the 6746 binding. This happens even if the attacker moves away from the link. 6747 In contrast, an attacker who uses only plain IPv6 generally has to be 6748 stay on the link in order to continue the attack. Note that in order 6749 to launch these new attacks, the IP address of the victim must be 6750 known. This makes this attack feasible mainly in the context of 6751 well-known interface IDs, such as those already appearing in the 6752 traffic on the link or registered in the DNS. 6754 On-path attackers can exploit similar vulnerabilities as in regular 6755 IPv6. There are some minor differences, however. Masquerade, 6756 Man-in-the-Middle, and Denial-of-Service attacks can be launched with 6757 just the interception of a few packets, whereas in regular IPv6 it is 6758 necessary to intercept every packet. The effect of the attacks is 6759 the same regardless of the method, however. In any case, the most 6760 difficult task attacker faces in these attacks is getting on the 6761 right path. 6763 The vulnerabilities for off-path attackers are the same as in regular 6764 IPv6. Those nodes that are not on the path between the home agent 6765 and the correspondent node will not be able to receive the home 6766 address probe messages. 6768 In conclusion, we can state the following main results from this 6769 comparison: 6771 o Return routability procedure prevents any off-path attacks beyond 6772 those that are already possible in regular IPv6. This is the most 6773 important result, and prevents attackers from the Internet from 6774 exploiting any vulnerabilities. 6776 o Vulnerabilities to attackers on the home agent link, the 6777 correspondent node link, and the path between them are roughly the 6778 same as in regular IPv6. 6780 o However, one difference is that in basic IPv6 an on-path attacker 6781 must be constantly present on the link or the path, whereas with 6782 Mobile IPv6 an attacker can leave a binding behind after moving 6783 away. 6785 For this reason, this specification limits the creation of 6786 bindings to at most MAX_TOKEN_LIFETIME seconds after the last 6787 routability check has been performed, and limits the duration of a 6788 binding to at most MAX_RR_BINDING_LIFETIME seconds. With these 6789 limitation, attackers cannot take practical advantages of this 6790 vulnerability. This limited vulnerability can also be compared to 6791 similar vulnerabilities in IPv6 Neighbor Discovery, with Neighbor 6792 Cache entries having a limited lifetime. 6794 o There are some other minor differences, such as an effect to the 6795 Denial-of-Service vulnerabilities. These can be considered to be 6796 insignificant. 6798 o The path between the home agent and a correspondent node is 6799 typically easiest to attack on the links at either end, in 6800 particular if these links are publicly accessible wireless LANs. 6801 Attacks against the routers or switches on the path are typically 6802 harder to accomplish. The security on layer 2 of the links plays 6803 then a major role in the resulting overall network security. 6804 Similarly, security of IPv6 Neighbor and Router Discovery on these 6805 links has a large impact. If these were secured using some new 6806 technology in the future, this could change the situation 6807 regarding the easiest point of attack. 6809 For a more in-depth discussion of these issues, see [30]. 6811 15.4.4 Replay Attacks 6813 The return routability procedure also protects the participants 6814 against replayed Binding Updates. The attacker is unable replay the 6815 same message due to the sequence number which is a part of the 6816 Binding Update. It is also unable to modify the Binding Update since 6817 the MAC verification would fail after such a modification. 6819 Care must be taken when removing bindings at the correspondent node, 6820 however. If a binding is removed while the nonce used in its 6821 creation is still valid, an attacker could replay the old Binding 6822 Update. Rules outlined in Section 5.2.8 ensure that this cannot 6823 happen. 6825 15.4.5 Denial-of-Service Attacks 6827 The return routability procedure has protection against resource 6828 exhaustion Denial-of-Service attacks. The correspondent nodes do not 6829 retain any state about individual mobile nodes until an authentic 6830 Binding Update arrives. This is achieved through the construct of 6831 keygen tokens from the nonces and node keys that are not specific to 6832 individual mobile nodes. The keygen tokens can be reconstructed by 6833 the correspondent node, based on the home and care-of address 6834 information that arrives with the Binding Update. This means that 6835 the correspondent nodes are safe against memory exhaustion attacks 6836 except where on-path attackers are concerned. Due to the use of 6837 symmetric cryptography, the correspondent nodes are relatively safe 6838 against CPU resource exhaustion attacks as well. 6840 Nevertheless, as [27] describes, there are situations in which it is 6841 impossible for the mobile and correspondent nodes to determine if 6842 they actually need a binding or whether they just have been fooled 6843 into believing so by an attacker. Therefore, it is necessary to 6844 consider situations where such attacks are being made. 6846 Even if route optimization is a very important optimization, it is 6847 still only an optimization. A mobile node can communicate with a 6848 correspondent node even if the correspondent refuses to accept any 6849 Binding Updates. However, performance will suffer because packets 6850 from the correspondent node to the mobile node will be routed via the 6851 mobile's home agent rather than a more direct route. A correspondent 6852 node can protect itself against some of these resource exhaustion 6853 attacks as follows. If the correspondent node is flooded with a 6854 large number of Binding Updates that fail the cryptographic integrity 6855 checks, it can stop processing Binding Updates. If a correspondent 6856 node finds that it is spending more resources on checking bogus 6857 Binding Updates than it is likely to save by accepting genuine 6858 Binding Updates, then it may silently discard some or all Binding 6859 Updates without performing any cryptographic operations. 6861 Layers above IP can usually provide additional information to decide 6862 if there is a need to establish a binding with a specific peer. For 6863 example, TCP knows if the node has a queue of data that it is trying 6864 to send to a peer. An implementation of this specification is not 6865 required to make use of information from higher protocol layers, but 6866 some implementations are likely to be able to manage resources more 6867 effectively by making use of such information. 6869 We also require that all implementations be capable of 6870 administratively disabling route optimization. 6872 15.4.6 Key Lengths 6874 While the return routability procedure is in progress, 64 bit cookies 6875 are used to protect spoofed responses. This is believed to be 6876 sufficient, given that to blindly spoof a response a very large 6877 number of messages would have to be sent before success would be 6878 probable. 6880 The tokens used in the return routability procedure provide together 6881 128 bits of information. This information is used internally as an 6882 input to a hash function to produce a 160 bit quantity suitable for 6883 producing the keyed hash in the Binding Update using the HMAC_SHA1 6884 algorithm. The final keyed hash length is 96 bits. The limiting 6885 factors in this case are the input token lengths and the final keyed 6886 hash length. The internal hash function application does not reduce 6887 the entropy. 6889 The 96 bit final keyed hash is of typical size and believed to be 6890 secure. The 128 bit input from the tokens is broken in two pieces, 6891 the home keygen token and the care-of keygen token. An attacker can 6892 try to guess the right cookie value, but again this would require a 6893 large number of messages, in the average 2**63 messages for one or 6894 2**127 for two. Furthermore, given that the cookies are valid only 6895 for a short period of time, the attack has to keep a high constant 6896 message rate to achieve a lasting effect. This does not appear 6897 practical. 6899 When the mobile node is returning home, it is allowed to use just the 6900 home keygen token of 64 bits. This is less than 128 bits, but 6901 attacking it blindly would still require a large number of messages 6902 to be sent. If the attacker is on the path and capable of seeing the 6903 Binding Update, it could conceivably break the keyed hash with brute 6904 force. However, in this case the attacker has to be on path, which 6905 appears to offer easier ways for denial-of-service than preventing 6906 route optimization. 6908 15.5 Dynamic Home Agent Address Discovery 6910 The dynamic home agent address discovery function could be used to 6911 learn the addresses of home agents in the home network. 6913 The ability to learn addresses of nodes may be useful to attackers, 6914 because brute-force scanning of the address space is not practical 6915 with IPv6. Thus, they could benefit from any means which make 6916 mapping the networks easier. For example, if a security threat 6917 targeted at routers or even home agents is discovered, having a 6918 simple ICMP mechanism to find out possible targets easily may prove 6919 to be an additional (though minor) security risk. 6921 Apart from discovering the address(es) of home agents, attackers will 6922 not be able to learn much from this information, however, and mobile 6923 nodes cannot be tricked into using wrong home agents as all other 6924 communication with the home agents is secure. 6926 15.6 Prefix Discovery 6928 The prefix discovery function may leak interesting information about 6929 network topology and prefix lifetimes to eavesdroppers, and for this 6930 reason requests for this information have to be authenticated. 6931 Responses and unsolicited prefix information needs to be 6932 authenticated to prevent the mobile nodes from being tricked into 6933 believing false information about the prefixes, and possibly 6934 preventing communications with the existing addresses. Optionally, 6935 encryption may be applied to prevent leakage of the prefix 6936 information. 6938 15.7 Tunneling via the Home Agent 6940 Tunnels between the mobile node and the home agent can be protected 6941 by ensuring proper use of source addresses, and optional 6942 cryptographic protection. These procedures are discussed in Section 6943 5.5. 6945 Binding Updates to the home agents are secure. When receiving 6946 tunneled traffic the home agent verifies the outer IP address 6947 corresponds to the current location of the mobile node. This 6948 prevents attacks where the attacker is controlled by ingress 6949 filtering. It also prevents attacks when the attacker does not know 6950 the current care-of address of the mobile node. Attackers who know 6951 the care-of address and are not controlled by ingress filtering could 6952 still send traffic through the home agent. This includes attackers 6953 on the same local link as the mobile node is currently on. But such 6954 attackers could also send spoofed packets without using a tunnel. 6956 Home agents and mobile nodes may use IPsec ESP to protect payload 6957 packets tunneled between themselves. This is useful to protect 6958 communications against attackers on the path of the tunnel. 6960 When site local home address are used, reverse tunneling can be used 6961 to send site local traffic from another location. Administrators 6962 should be aware of this when allowing such home addresses. In 6963 particular, the outer IP address check described above is not 6964 sufficient against all attackers. The use of encrypted tunnels is 6965 particularly useful for this kind of home addresses. 6967 15.8 Home Address Option 6969 When the mobile node sends packets directly to the correspondent 6970 node, the Source Address field of the packet's IPv6 header is the 6971 care-of address. Ingress filtering [26] works therefore in the usual 6972 manner even for mobile nodes, as the Source Address is topologically 6973 correct. The Home Address option is used to inform the correspondent 6974 node of the mobile node's home address. 6976 However, the care-of address in the Source Address field does not 6977 survive in replies sent by the correspondent node unless it has a 6978 binding for this mobile node. Also, not all attacker tracing 6979 mechanisms work when packets are being reflected through 6980 correspondent nodes using the Home Address option. For these 6981 reasons, this specification restricts the use of the Home Address 6982 option. It may only used when a binding has already been established 6983 with the participation of the node at the home address, as described 6984 in Section 5.5 and Section 6.3. This prevents reflection attacks 6985 through the use of the Home Address option. It also ensures that the 6986 correspondent nodes reply to the same address as the mobile node 6987 sends traffic from. 6989 No special authentication of the Home Address option is required 6990 beyond the above, except that if the IPv6 header of a packet is 6991 covered by authentication, then that authentication MUST also cover 6992 the Home Address option; this coverage is achieved automatically by 6993 the definition of the Option Type code for the Home Address option 6994 (Section 6.3), since it indicates that the option is included in the 6995 authentication computation. Thus, even when authentication is used 6996 in the IPv6 header, the security of the Source Address field in the 6997 IPv6 header is not compromised by the presence of a Home Address 6998 option. Without authentication of the packet, then any field in the 6999 IPv6 header, including the Source Address field, and any other parts 7000 of the packet, including the Home Address option, can be forged or 7001 modified in transit. In this case, the contents of the Home Address 7002 option is no more suspect than any other part of the packet. 7004 15.9 Type 2 Routing Header 7006 The definition of the type 2 routing header is described in Section 7007 6.4. This definition and the associated processing rules have been 7008 chosen so that the header cannot be used for what is traditionally 7009 viewed as source routing. In particular, the Home Address in the 7010 routing header will always have to be assigned to the home address of 7011 the receiving node. Otherwise the packet will be dropped. 7013 Generally, source routing has a number of security concerns. These 7014 include the automatic reversal of unauthenticated source routes 7015 (which is an issue for IPv4, but not for IPv6). Another concern is 7016 the ability to use source routing to "jump" between nodes inside, as 7017 well as outside a firewall. These security concerns are not issues 7018 in Mobile IPv6, due to the rules mentioned above. 7020 In essence the semantics of the type 2 routing header is the same as 7021 a special form of IP-in-IP tunneling where the inner and outer source 7022 addresses are the same. 7024 This implies that a device which implements filtering of packets 7025 should be able to distinguish between a type 2 routing header and 7026 other routing headers, as required in Section 8.3. This is necessary 7027 in order to allow Mobile IPv6 traffic while still having the option 7028 to filter out other uses of routing headers. 7030 16. Contributors 7032 Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, 7033 and Michael Thomas worked on the return routability protocols which 7034 eventually led to the procedures used in this protocol. The 7035 procedures described in [32] were adopted in the protocol. 7037 Significant contributions were made by members of the Mobile IPv6 7038 Security Design Team, including (in alphabetical order) Gabriel 7039 Montenegro, Erik Nordmark and Pekka Nikander, who have contributed 7040 volumes of text to this specification. 7042 17. Acknowledgements 7044 We would like to thank the members of the Mobile IP and IPng Working 7045 Groups for their comments and suggestions on this work. We would 7046 particularly like to thank (in alphabetical order) Fred Baker, Josh 7047 Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Greg Daley, 7048 Vijay Devarapalli, Rich Draves, Francis Dupont, Thomas Eklund, 7049 Jun-Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ioannidis, 7050 James Kempf, Rajeev Koodli, Krishna Kumar, T.J. Kniveton, Joe Lau, 7051 Jiwoong Lee, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin Miles, Glenn 7052 Morrow, Thomas Narten, Karen Nielsen, Simon Nybroe, David Oran, Brett 7053 Pentland, Lars Henrik Petander, Basavaraj Patil, Mohan Parthasarathy, 7054 Alexandru Petrescu, Mattias Petterson, Ken Powell, Phil Roberts, Ed 7055 Remmell, Patrice Romand, Jeff Schiller, Pekka Savola, Arvind 7056 Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon, 7057 Tapio Suihko, Dave Thaler, Benny Van Houdt, Jon-Olov Vatn, Carl E. 7058 Williams, Vladislav Yasevich, Alper Yegin, and Xinhua Zhao, for their 7059 detailed reviews of earlier versions of this document. Their 7060 suggestions have helped to improve both the design and presentation 7061 of the protocol. 7063 We would also like to thank the participants in the Mobile IPv6 7064 testing event held at Nancy, France, September 15-17, 1999, for their 7065 valuable feedback as a result of interoperability testing of four 7066 Mobile IPv6 implementations. Further, we would like to thank the 7067 feedback from the implementors who participated in the Mobile IPv6 7068 interoperability testing at Connectathons 2000, 2001, and 2002 in San 7069 Jose, California. Similarly, we would like to thank the participants 7070 at the ETSI interoperability testing at ETSI, in Sophia Antipolis, 7071 France, during October 2-6, 2000. 7073 Normative References 7075 [1] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 7076 Recommendations for Security", RFC 1750, December 1994. 7078 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 7079 Levels", BCP 14, RFC 2119, March 1997. 7081 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 7082 Architecture", RFC 2373, July 1998. 7084 [4] Kent, S. and R. Atkinson, "Security Architecture for the 7085 Internet Protocol", RFC 2401, November 1998. 7087 [5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 7088 November 1998. 7090 [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 7091 (ESP)", RFC 2406, November 1998. 7093 [7] Piper, D., "The Internet IP Security Domain of Interpretation 7094 for ISAKMP", RFC 2407, November 1998. 7096 [8] Maughan, D., Schertler, M., Schneider, M. and J. Turner, 7097 "Internet Security Association and Key Management Protocol 7098 (ISAKMP)", RFC 2408, November 1998. 7100 [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 7101 RFC 2409, November 1998. 7103 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 7104 Considerations Section in RFCs", BCP 26, RFC 2434, October 7105 1998. 7107 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 7108 Specification", RFC 2460, December 1998. 7110 [12] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 7111 for IP Version 6 (IPv6)", RFC 2461, December 1998. 7113 [13] Thomson, S. and T. Narten, "IPv6 Stateless Address 7114 Autoconfiguration", RFC 2462, December 1998. 7116 [14] Conta, A. and S. Deering, "Internet Control Message Protocol 7117 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 7118 Specification", RFC 2463, December 1998. 7120 [15] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 7121 Specification", RFC 2473, December 1998. 7123 [16] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 7124 Addresses", RFC 2526, March 1999. 7126 [17] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 7127 Discovery (MLD) for IPv6", RFC 2710, October 1999. 7129 [18] Narten, T. and R. Draves, "Privacy Extensions for Stateless 7130 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 7132 [19] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an 7133 On-line Database", RFC 3232, January 2002. 7135 [20] National Institute of Standards and Technology, "Secure Hash 7136 Standard", FIPS PUB 180-1, April 1995, . 7139 [21] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 7140 Protect Mobile IPv6 Signaling betweenMobile Nodes and Home 7141 Agents", draft-ietf-mobileip-mipv6-ha-ipsec-03 (work in 7142 progress), February 2003. 7144 Informative References 7146 [22] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 7148 [23] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 7149 1996. 7151 [24] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 7152 October 1996. 7154 [25] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 7155 for Message Authentication", RFC 2104, February 1997. 7157 [26] Ferguson, P. and D. Senie, "Network Ingress Filtering: 7158 Defeating Denial of Service Attacks which employ IP Source 7159 Address Spoofing", RFC 2267, January 1998. 7161 [27] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 7162 draft-aura-mipv6-bu-attacks-01 (work in progress), March 2002. 7164 [28] Droms, R., "Dynamic Host Configuration Protocol for IPv6 7165 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 7166 November 2002. 7168 [29] Draves, R., "Default Address Selection for IPv6", 7169 draft-ietf-ipv6-default-addr-select-09 (work in progress), 7170 August 2002. 7172 [30] Nikander, P., Nordmark, E., Montenegro, G. and J. Arkko, 7173 "Mobile IPv6 Security Design Rationale", 7174 draft-nikander-mipv6-design-rationale-00.txt (work in 7175 progress), February 2003. 7177 [31] Nordmark, E., "Securing MIPv6 BUs using return routability 7178 (BU3WAY)", draft-nordmark-mobileip-bu3way-00 (work in 7179 progress), November 2001. 7181 [32] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of 7182 Mobile IPv6 Binding Updates and Acknowledgments", 7183 draft-roe-mobileip-updateauth-02 (work in progress), March 7184 2002. 7186 [33] Savola, P., "Use of /127 Prefix Length Between Routers 7187 Considered Harmful", draft-savola-ipv6-127-prefixlen-04 (work 7188 in progress), June 2002. 7190 [34] Savola, P., "Security of IPv6 Routing Header and Home Address 7191 Options", draft-savola-ipv6-rh-ha-security-03 (work in 7192 progress), December 2002. 7194 [35] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 7195 (MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress), 7196 December 2002. 7198 Authors' Addresses 7200 David B. Johnson 7201 Rice University 7202 Dept. of Computer Science, MS 132 7203 6100 Main Street 7204 Houston TX 77005-1892 7205 USA 7207 EMail: dbj@cs.rice.edu 7209 Charles E. Perkins 7210 Nokia Research Center 7211 313 Fairchild Drive 7212 Mountain View CA 94043 7213 USA 7215 EMail: charliep@iprg.nokia.com 7217 Jari Arkko 7218 Ericsson 7219 Jorvas 02420 7220 Finland 7222 EMail: jari.arkko@ericsson.com 7224 Appendix A. Changes from Previous Version of the Draft 7226 This appendix briefly lists some of the major changes in this draft 7227 relative to the previous version of this same draft, 7228 draft-ietf-mobileip-ipv6-20.txt: 7230 o The lifetime of a binding on a correspondent is now limited to the 7231 lifetime of the home registration, not the lifetime of the home 7232 address (tracked issue 261). 7234 o This specification no longer requires site-local forwarding to be 7235 configurable (tracked issue 258). 7237 o Infinite binding lifetimes have been removed (tracked issue 256). 7239 o This specification now disallows the use of the Binding 7240 Authorization Data option in a home registration, and requires 7241 Binding Updates the home agent with such options to be dropped 7242 (tracked issue 255). 7244 o The verification of Home Address Options without an existing 7245 Binding Cache entry has been clarified. IPsec is now sufficient 7246 for this verification only in the case of the home agent and a 7247 home address which the home agent is willing to serve (tracked 7248 issue 253). 7250 o Appendix B.6 now describes some potential Neighbor Discovery 7251 enhancements that may be relevant for Mobile IPv6 in the future 7252 (tracked issue 252). 7254 o The Home Address Option rule has been clarified in Section 11.7.2. 7255 This rule deals with starting route optimization when a tunneled 7256 packet has been received (tracked issue 251). 7258 o Binding Cache entries can now be created from non-error ICMP 7259 messages. This allows Mobile IPv6 to be tested with ping, which 7260 uses ICMP echo messages (tracked issue 250). 7262 o The support for protecting prefix discovery with IPsec has been 7263 made mandatory, but use is still a SHOULD (tracked issue 249). 7265 o It is now required that L=0 registrations do not allow the home 7266 agent to derive any other address from the home address (tracked 7267 issue 248). 7269 o Prefix fetching interval constants have now been defined (tracked 7270 issue 245). 7272 o It is now required that mobile nodes must set both lifetime to 7273 zero and care-of address to the home address when de-registering 7274 (tracked issue 244). 7276 o Requirements for security association and policy configuration for 7277 new home addresses received through prefix discovery have been 7278 specified (tracked issue 243). 7280 o New Status code 1 has been added to Binding Acknowledgement 7281 (tracked issue 243). 7283 o Mobile nodes are now required to initiate prefix discovery upon 7284 receiving Status code 1 in a Binding Acknowledgement (tracked 7285 issue 243). 7287 o The set of addresses for which the home agent intercepts packets 7288 has been clarified (tracked issue 241). 7290 o Both pros and cons of route optimization have been discussed in 7291 Section 8.2 (tracked issue 241). 7293 o Checksum validation is now the first check performed for Mobility 7294 Header messages (tracked issue 241). 7296 o Section 6.1 now correctly indicates that for some Mobility Header 7297 messages the number of options is zero or more, not one or more 7298 (tracked issue 241). 7300 o The security implications of dynamic home agent address discovery 7301 have been updated (tracked issue 239). 7303 o The specification no longer uses RFC 2119 keywords for describing 7304 when route optimization should be started, continued, or stopped 7305 (tracked issue 237). 7307 o The requirements for configuration mechanisms for various Mobile 7308 IPv6 parts have been changed (tracked issue 236). 7310 o A warning has been included about the use of Dynamic Home Agent 7311 Address Discovery with extremely long prefix lengths (tracked 7312 issue 235). 7314 o The usage of the Alternate Care-of Address option has been 7315 clarified in Section 6.2.5 (tracked issue 234). 7317 o The security considerations section now contains an analysis of 7318 the sufficiency of the length of the various cryptographic 7319 entities (tracked issue 233). 7321 o The Home Agent (H) bit is now required to be set in some 7322 advertisement of a prefix before home addresses based on this 7323 prefix can be registered (tracked issues 231 and 246). 7325 o The conditions for delaying Duplicate Address Detection have been 7326 rewritten (tracked issue 230). 7328 o Text relating to keygen token handling in de-registrations has 7329 been clarified (tracked issue 229). 7331 o IPsec protocol and mode requirements have now been stated as 7332 minimal requirements and no longer prevent the use of other 7333 protocols (AH) and modes (tracked issue 228). 7335 o Processing rules for Binding Refresh Requests have been rewritten 7336 (tracked issue 227). 7338 o Binding Error processing is now a MUST requirement (tracked issues 7339 190 and 225). 7341 o The source address in proxy Neighbor Advertisements sent by the 7342 home agent has now been specified (tracked issue 223). 7344 o RFC 2119 keywords are now used for describing the reuse of tokens 7345 in the return routability procedure (tracked issue 221). 7347 o The alignment of the Binding Authorization Data option has changed 7348 (tracked issue 220). 7350 o An editorial correction in the processing order of type 0 and type 7351 2 routing headers has changed the semantics (tracked issue 217). 7353 o When returning home, the mobile node no longer targets the home 7354 agent's address in a Neighbor Solicitation that tries to find the 7355 link-layer address of the home agent. Instead, it target's the 7356 mobile node's own address which the home agent is defending 7357 (tracked issue 218). 7359 o A number of editorial modifications have been performed (tracked 7360 issues 234, 241, 242, 249, 261, 262, 264, and 266). 7362 Appendix B. Future Extensions 7364 B.1 Piggybacking 7366 This document does not specify how to piggyback payload packets on 7367 the binding related messages. However, it is envisioned that this 7368 can be specified in a separate document when currently discussed 7369 issues such as the interaction between piggybacking and IPsec are 7370 fully resolved (see also Appendix B.3). The return routability 7371 messages can indicate support for piggybacking with a new mobility 7372 option. 7374 B.2 Triangular Routing 7376 Due to the concerns about opening reflection attacks with the Home 7377 Address destination option, this specification requires that this 7378 option must be verified against the Binding Cache, i.e., there must 7379 be a Binding Cache entry for the Home Address and Care-of Address. 7381 Future extensions may be specified that allow the use of unverified 7382 Home Address destination options in ways that do not introduce 7383 security issues. 7385 B.3 New Authorization Methods 7387 While the return routability procedure provides a good level of 7388 security, there exists methods that have even higher levels of 7389 security. Secondly, as discussed in Section 15.4, future 7390 enhancements of IPv6 security may cause a need to improve also the 7391 security of the return routability procedure. Using IPsec as the 7392 sole method for authorizing Binding Updates to correspondent nodes is 7393 also possible. The protection of the Mobility Header for this 7394 purpose is easy, though one must ensure that the IPsec SA was created 7395 with appropriate authorization to use the home address referenced in 7396 the Binding Update. For instance, a certificate used by IKE to 7397 create the security association might contain the home address. A 7398 future specification may specify how this is done. 7400 B.4 Dynamically Generated Home Addresses 7402 A future version of this specification may include functionality that 7403 allows the generation of new home addresses without requiring 7404 pre-arranged security associations or certificates even for the new 7405 addresses. 7407 B.5 Remote Home Address Configuration 7409 The method for initializing a mobile node's home addresses on 7410 power-up or after an extended period of being disconnected from the 7411 network is beyond the scope of this specification. Whatever 7412 procedure is used should result in the mobile node having the same 7413 stateless or stateful (e.g., DHCPv6) home address autoconfiguration 7414 information it would have if it were attached to the home network. 7415 Due to the possibility that the home network could be renumbered 7416 while the mobile node is disconnected, a robust mobile node would not 7417 rely solely on storing these addresses locally. 7419 Such a mobile node could initialize by using the following procedure: 7421 1. Generate a care-of address. 7423 2. Query DNS for an anycast address associated with the FQDN of the 7424 home agent(s). 7426 3. Perform home agent address discovery, and select a home agent. 7428 4. Configure one home address based on the selected home agent's 7429 subnet prefix and the interface identifier of the mobile node. 7431 5. Create security associations and security policy database entries 7432 for protecting the traffic between the selected home address and 7433 home agent. 7435 6. Perform a home registration to the selected home agent. 7437 7. Perform prefix discovery. 7439 8. Make a decision if further home addresses need to be configured. 7441 This procedure is restricted to those situations where the home 7442 prefix is 64 bits and the mobile node knows its own interface 7443 identifier of also 64 bits. 7445 B.6 Neighbor Discovery Extensions 7447 Future specifications may improve the efficiency of Neighbor 7448 Discovery tasks, which could be helpful for fast movements. One 7449 factor which is currently being looked at is the delays caused by the 7450 Duplicate Address Detection mechanism. Currently, Duplicate Address 7451 Detection needs to be performed for every new care-of address as the 7452 mobile node moves, and for the mobile node's link-local address on 7453 every new link. In particular, the need and the tradeoffs of 7454 re-performing Duplicate Address Detection for the link-local address 7455 every time when the mobile node moves on to new links will need to be 7456 examined. Improvements in this area are, however, generally 7457 applicable and progressed independently from Mobile IPv6 7458 specification. 7460 Future functional improvements may also be relevant for Mobile IPv6 7461 and other applications. For instance, mechanisms that would allow 7462 recovery from a Duplicate Address Detection collision would be useful 7463 for link-local, care-of, and home addresses. 7465 Intellectual Property Statement 7467 The IETF takes no position regarding the validity or scope of any 7468 intellectual property or other rights that might be claimed to 7469 pertain to the implementation or use of the technology described in 7470 this document or the extent to which any license under such rights 7471 might or might not be available; neither does it represent that it 7472 has made any effort to identify any such rights. Information on the 7473 IETF's procedures with respect to rights in standards-track and 7474 standards-related documentation can be found in BCP-11. Copies of 7475 claims of rights made available for publication and any assurances of 7476 licenses to be made available, or the result of an attempt made to 7477 obtain a general license or permission for the use of such 7478 proprietary rights by implementors or users of this specification can 7479 be obtained from the IETF Secretariat. 7481 The IETF invites any interested party to bring to its attention any 7482 copyrights, patents or patent applications, or other proprietary 7483 rights which may cover technology that may be required to practice 7484 this standard. Please address the information to the IETF Executive 7485 Director. 7487 Full Copyright Statement 7489 Copyright (C) The Internet Society (2003). All Rights Reserved. 7491 This document and translations of it may be copied and furnished to 7492 others, and derivative works that comment on or otherwise explain it 7493 or assist in its implementation may be prepared, copied, published 7494 and distributed, in whole or in part, without restriction of any 7495 kind, provided that the above copyright notice and this paragraph are 7496 included on all such copies and derivative works. However, this 7497 document itself may not be modified in any way, such as by removing 7498 the copyright notice or references to the Internet Society or other 7499 Internet organizations, except as needed for the purpose of 7500 developing Internet standards in which case the procedures for 7501 copyrights defined in the Internet Standards process must be 7502 followed, or as required to translate it into languages other than 7503 English. 7505 The limited permissions granted above are perpetual and will not be 7506 revoked by the Internet Society or its successors or assignees. 7508 This document and the information contained herein is provided on an 7509 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 7510 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 7511 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 7512 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 7513 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7515 Acknowledgement 7517 Funding for the RFC Editor function is currently provided by the 7518 Internet Society.