idnits 2.17.1 draft-ietf-mobileip-ipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '...IPv6 nodes and routers MUST be able to...' RFC 2119 keyword, line 234: '... entry and SHOULD NOT be deleted...' RFC 2119 keyword, line 236: '... entries MAY be replaced at an...' RFC 2119 keyword, line 331: '... MUST...' RFC 2119 keyword, line 336: '... MUST NOT...' (153 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (13 June 1996) is 10179 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 1826 (ref. '1') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1825 (ref. '2') (Obsoleted by RFC 2401) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-05 ** Obsolete normative reference: RFC 1885 (ref. '4') (Obsoleted by RFC 2463) == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-ipv6-tunnel-01 ** Obsolete normative reference: RFC 1883 (ref. '6') (Obsoleted by RFC 2460) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-04 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-03 ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) == Outdated reference: A later version (-07) exists of draft-teraoka-ipv6-mobility-sup-02 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-07) exists of draft-ietf-addrconf-ipv6-auto-06 Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group David B. Johnson 2 INTERNET-DRAFT Carnegie Mellon University 3 Charles Perkins 4 IBM Corporation 5 13 June 1996 7 Mobility Support in IPv6 9 11 Abstract 13 This document specifies the operation of mobile computers using IPv6. 14 Each mobile node is always identified by its home address, regardless 15 of its current point of attachment to the Internet. While situated 16 away from its home, a mobile node is also associated with a care-of 17 address, which provides information about the mobile node's current 18 location. IPv6 packets addressed to a mobile node's home address are 19 transparently routed to its care-of address. The protocol enables 20 IPv6 nodes to cache the binding of a mobile node's home address with 21 its care-of address, and to then send packets destined for the mobile 22 node directly to it at this care-of address. 24 Status of This Memo 26 This document is a submission by the Mobile IP Working Group of the 27 Internet Engineering Task Force (IETF). Comments should be submitted 28 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 29 Distribution of this memo is unlimited. 31 This document is an Internet-Draft. Internet-Drafts are working 32 documents of the Internet Engineering Task Force (IETF), its areas, 33 and its working groups. Note that other groups may also distribute 34 working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at 38 any time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 To learn the current status of any Internet-Draft, please check 42 the "1id-abstracts.txt" listing contained in the Internet-Drafts 43 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 44 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 45 ftp.isi.edu (US West Coast). 47 Contents 49 Abstract i 51 Status of This Memo i 53 1. Introduction 1 54 1.1. Design Requirements . . . . . . . . . . . . . . . . . . . 2 55 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 2 58 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.6. Specification Language . . . . . . . . . . . . . . . . . 5 61 2. Overview of Mobile IPv6 Operation 7 63 3. Message and Option Formats 9 64 3.1. Binding Update Option . . . . . . . . . . . . . . . . . . 9 65 3.2. ICMP Binding Acknowledgement Message . . . . . . . . . . 13 67 4. Requirements for IPv6 Nodes 15 69 5. Binding Cache Management 17 70 5.1. Receiving Binding Updates . . . . . . . . . . . . . . . . 17 71 5.2. Requests to Cache a Binding . . . . . . . . . . . . . . . 17 72 5.3. Requests to Delete a Binding . . . . . . . . . . . . . . 18 73 5.4. Sending Binding Acknowledgements . . . . . . . . . . . . 18 74 5.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 19 75 5.6. Receiving ICMP Error Messages . . . . . . . . . . . . . . 19 77 6. Mobile Node Considerations 21 78 6.1. Movement Detection . . . . . . . . . . . . . . . . . . . 21 79 6.2. Forming New Care-of Addresses . . . . . . . . . . . . . . 23 80 6.3. Sending Binding Updates to the Home Agent . . . . . . . . 24 81 6.4. Sending Binding Updates to Correspondent Nodes . . . . . 25 82 6.5. Sending Binding Updates to the Previous Default Router . 25 83 6.6. Rate Limiting for Sending Binding Updates . . . . . . . . 26 84 6.7. Receiving Binding Acknowledgements . . . . . . . . . . . 26 85 6.8. Using Multiple Care-of Addresses . . . . . . . . . . . . 27 86 6.9. Returning Home . . . . . . . . . . . . . . . . . . . . . 28 88 7. Home Agent Considerations 29 89 7.1. Home Agent Care-of Address Registration . . . . . . . . . 29 90 7.2. Home Agent Care-of Address De-registration . . . . . . . 31 91 7.3. Delivering Packets to a Mobile Node . . . . . . . . . . . 32 92 7.4. Renumbering the Home Network . . . . . . . . . . . . . . 32 94 8. Correspondent Node Considerations 34 95 8.1. Delivering Packets to a Mobile Node . . . . . . . . . . . 34 97 9. Authentication and Replay Protection 36 99 10. Routing Multicast Packets 37 101 11. Constants 38 103 Acknowledgements 38 105 References 39 107 A. Open Issues 40 108 A.1. Session Keys with Local Routers . . . . . . . . . . . . . 40 109 A.2. Source Address Filtering by Firewalls . . . . . . . . . . 40 111 Chair's Address 42 113 Authors' Addresses 42 114 1. Introduction 116 This document specifies the operation of mobile computers using 117 Internet Protocol Version 6 (IPv6) [6]. Mobile computers are likely 118 to account for a majority or at least a substantial fraction of 119 the population of the Internet during the lifetime of IPv6. The 120 protocol, known as Mobile IPv6, allows transparent routing of IPv6 121 packets to mobile nodes using the mobile node's home IPv6 address, 122 regardless of the mobile node's current point of attachment to the 123 Internet. 125 The most important function needed to support such routing to mobile 126 nodes is the reliable and timely notification of a mobile node's 127 current location to those other nodes that need it. Correspondent 128 nodes communicating with a mobile node need this location information 129 in order to correctly deliver their own packets to a mobile node; 130 Mobile IPv6 allows correspondent nodes to learn and cache a mobile 131 node's location, and to use this cached information to route their 132 own packets directly to a mobile node at its current location. The 133 mobile node's "home agent", a router on the mobile node's home 134 network, also needs this location information in order to forward 135 intercepted packets from the home network to the mobile node, for 136 correspondent nodes that have not yet learned the mobile node's 137 location, and indeed, for correspondent nodes that do not even yet 138 know that the mobile node is currently away from home. 140 A mobile node's current location is represented as a "care-of 141 address", an IPv6 address assigned to the mobile node (in addition 142 to its home IPv6 address) within the foreign network currently being 143 visited by the mobile node. The association between a mobile node's 144 home address and its care-of address, along with the remaining 145 lifetime of that association, is known as a "binding", and the mobile 146 node notifies other nodes about its current binding using a new 147 destination option called a Binding Update. IPv6 correspondent nodes 148 then use a Routing header to deliver subsequent packets to the mobile 149 node's care-of address. All IPv6 nodes and routers MUST be able to 150 cache mobile node bindings received in Binding Updates; this leads to 151 dramatic simplifications in the required protocols, compared to the 152 methods required for IPv4. 154 In this document, "movement" is considered to be a change in a mobile 155 node's point of attachment to the Internet such that it is no longer 156 link-level connected to the same IPv6 subnet (network prefix) as 157 it was previously. If a mobile node is not currently link-level 158 connected to its home IPv6 network, the mobile node is said to be 159 "away from home". 161 1.1. Design Requirements 163 A mobile node must continue to be able to be addressed by its home 164 IPv6 address, and to be able to communicate with other IPv6 nodes 165 using its home address, after changing its link-level point of 166 attachment from one IPv6 subnet to another. 168 All messages used to update another node as to the location of a 169 mobile node must be authenticated in order to protect against remote 170 redirection attacks. 172 1.2. Goals 174 The number of administrative messages sent over the link by which 175 a mobile node is directly attached to the Internet should be 176 minimized, and the size of these messages should be kept as small 177 as is reasonably possible. This link may often be a wireless link, 178 having a substantially lower bandwidth and higher error rate than 179 traditional wired networks, and many mobile nodes are likely to 180 operate on limited battery power. By reducing the number and size 181 of administrative messages required for mobility support, network 182 resources and mobile node battery resources are conserved. 184 1.3. Assumptions 186 This protocol places no additional constraints on the assignment of 187 IPv6 addresses. That is, a mobile node may acquire its addresses 188 using stateless address autoconfiguration [12], or alternatively 189 using a stateful address configuration protocol such as DHCPv6 [3] or 190 PPPv6 [7]. 192 This protocol assumes that any mobile node will generally not change 193 its link-level point of attachment from one IPv6 subnet to another 194 more frequently than once per second. 196 This protocol assumes that IPv6 unicast packets are routed based on 197 the Destination Address in the packet's IPv6 header (and not, for 198 example, by source address). 200 1.4. Applicability 202 Mobile IPv6 is intended to enable nodes to move from one IPv6 subnet 203 to another. It is just as suitable for mobility across homogeneous 204 media as it is for mobility across heterogeneous media. That is, 205 Mobile IPv6 facilitates node movement from one Ethernet segment to 206 another as well as it accommodates node movement from an Ethernet 207 segment to a wireless LAN, as long as the mobile node's IPv6 address 208 remains the same after such a movement. 210 One can think of Mobile IPv6 as solving the "macro" mobility 211 management problem. It is less well suited for more "micro" mobility 212 management applications -- for example, handoff amongst wireless 213 transceivers, each of which covers only a very small geographic 214 area. As long as node movement does not occur between link-level 215 points of attachment on different IPv6 subnets, link-layer mechanisms 216 for mobility management (i.e., link-layer handoff) may offer faster 217 convergence and far less overhead than Mobile IPv6. 219 1.5. Terminology 221 This document uses the following special terms: 223 Binding 225 The association of the home address of a mobile node with a 226 care-of address for that mobile node, along with the remaining 227 lifetime of that association. 229 Binding Cache 231 A cache, maintained by each IPv6 node, of bindings for other 232 nodes. An entry in a node's binding cache for which the node 233 is serving as a home agent is marked as a "home registration" 234 entry and SHOULD NOT be deleted by the node until the 235 expiration of its binding lifetime, whereas other Binding Cache 236 entries MAY be replaced at any time by any reasonable local 237 cache replacement policy. The Binding Cache is a conceptual 238 data structure used in this document, which may be implemented 239 in any manner consistent with the external behavior described 240 here, for example by being combined with the node's Destination 241 Cache as maintained through Neighbor Discovery [9]. 243 Binding Update List 245 A list, maintained by each IPv6 mobile node, of the IPv6 246 address of each other node to which this node has sent a 247 Binding Update giving its binding, such that the lifetime of 248 the binding sent to that node has not yet expired. This is a 249 conceptual data structure used in this document, which may be 250 implemented in any manner consistent with the external behavior 251 described here. 253 Care-of Address 255 An IPv6 address associated with a mobile node while visiting a 256 foreign network, which uses the network prefix of that foreign 257 network. Among the multiple care-of addresses that a mobile 258 node may have at a time (with different network prefixes), the 259 one registered with its home agent is called its "primary" 260 care-of address. 262 Correspondent Node 264 A peer with which a mobile node is communicating. The 265 correspondent node may be either mobile or stationary. 267 Foreign Network 269 Any network other than the mobile node's home network. 271 Home Address 273 An IPv6 address that is assigned for an extended period of 274 time to a mobile node. It remains unchanged regardless of the 275 node's current link-level point of attachment to the Internet. 277 Home Agent 279 A router on a mobile node's home network that, while the mobile 280 node is away from home, intercepts packets on the home network 281 destined to the mobile node's home address, encapsulates them, 282 and tunnels them to the mobile node's current care-of address. 283 The home agent maintains a registry of the current binding for 284 mobile nodes whose home address is on the home network routed 285 by the home agent. 287 Home Network 289 A network, which may possibly be a virtual network, having a 290 network prefix matching that of a mobile node's home address. 291 Standard IPv6 routing mechanisms will deliver packets destined 292 for a mobile node's home address to the mobile node's home 293 network. 295 Link 297 A facility or medium over which nodes can communicate at the 298 link layer. A link underlies the network layer. 300 Mobile Node 302 A node that can change its link-level point of attachment from 303 one IPv6 subnet to another, while still being addressable via 304 its IPv6 home address. 306 Node 308 A host or a router. 310 Tunnel 312 The path followed by a packet while it is encapsulated. The 313 model is that, while it is encapsulated, a packet is routed 314 to a knowledgeable decapsulating agent, which decapsulates 315 the packet and then correctly delivers it to its ultimate 316 destination. 318 Virtual Network 320 A network with no physical instantiation beyond a home agent 321 (with a physical network interface on another network). The 322 home agent generally advertises reachability to the network 323 prefix of the virtual network using conventional routing 324 protocols. 326 1.6. Specification Language 328 In this document, several words are used to signify the requirements 329 of the specification. These words are often capitalized. 331 MUST 333 This word, or the adjective "required", means that the 334 definition is an absolute requirement of the specification. 336 MUST NOT 338 This phrase means that the definition is an absolute 339 prohibition of the specification. 341 SHOULD 343 This word, or the adjective "recommended", means that, in some 344 circumstances, valid reasons may exist to ignore this item, but 345 the full implications must be understood and carefully weighed 346 before choosing a different course. Unexpected results may 347 result otherwise. 349 MAY 351 This word, or the adjective "optional", means that this item is 352 one of an allowed set of alternatives. An implementation which 353 does not include this option MUST be prepared to interoperate 354 with another implementation which does include the option. 356 silently discard 358 The implementation discards the packet without further 359 processing, and without indicating an error to the sender. The 360 implementation SHOULD provide the capability of logging the 361 error, including the contents of the discarded packet, and 362 SHOULD record the event in a statistics counter. 364 2. Overview of Mobile IPv6 Operation 366 In addition to its (permanent) IPv6 home address, a mobile node 367 while away from home will have assigned to its network interface(s) 368 a "primary care-of address" and possibly other "care-of addresses". 369 A care-of address is an IPv6 address assigned to a mobile node only 370 while visiting a particular foreign network, typically acquired 371 through stateless [12] or stateful (e.g., DHCPv6 [3]) address 372 autoconfiguration. The decision about which manner of address 373 autoconfiguration to use is made according to the methods of IPv6 374 Neighbor Discovery [9]. 376 Each time a mobile node moves its link-level point of attachment from 377 one IPv6 subnet to another, it will configure its primary care-of 378 address at its new point of attachment, and will send a Binding 379 Update containing that care-of address to its home agent. The 380 care-of address for a mobile node registered with its home agent is 381 known as the mobile node's "primary" care-of address, and the mobile 382 node may also have additional care-of addresses, one for each of the 383 network prefixes that it currently considers to be on-link. Each 384 time it changes its primary care-of address, a mobile node also sends 385 a Binding Update to each other (correspondent) node that may have an 386 out-of-date care-of address for the mobile node in its Binding Cache. 388 A mobile node attached to the Internet can always be reached by 389 sending packets to its home IPv6 address. If the mobile node is not 390 present on its home network, any packet arriving there for it will be 391 intercepted there by its home agent, which will tunnel the packet to 392 the mobile node's current primary care-of address. The home agent 393 uses IPv6 encapsulation [5] to tunnel the packet. 395 A correspondent node sending a packet checks its Binding Cache for 396 an entry for the Destination Address of the packet, and uses a 397 Routing header (instead of encapsulation) to route the packet to the 398 destination mobile node's care-of address if a cached binding is 399 found. Otherwise, the correspondent node sends the packet normally 400 (with no Routing header), and the packet is then intercepted and 401 tunneled by the mobile node's home agent as described above. When 402 the tunneled packet reaches the mobile node, the mobile node returns 403 a Binding Update to the correspondent node, allowing it to cache the 404 mobile node's binding for future packets. 406 Since correspondent nodes cache bindings, it is expected that 407 correspondent nodes usually will route packets directly to the mobile 408 node's care-of address, so that the home agent is rarely involved 409 with packet transmission to the mobile node. This is essential for 410 scalability and reliability, and for minimizing overall network load. 411 By caching the care-of address of a mobile node, optimal routing of 412 packets can be achieved between the correspondent node and the mobile 413 node. Routing packets directly to the mobile node's care-of address 414 also eliminates congestion at the mobile node's home agent and home 415 network. In addition, the impact of of any possible failure of the 416 home agent, the home network, or intervening networks leading to the 417 home network is drastically reduced, since these components are not 418 involved in the delivery of most packets to the mobile node. 420 3. Message and Option Formats 422 3.1. Binding Update Option 424 A Binding Update is a new IPv6 destination option, used by a mobile 425 node to notify a correspondent node or its home agent of its current 426 care-of address. As a destination option, it can appear in a 427 Destination Options header in any IPv6 packet [6], and thus can be 428 included in any normal data packet or can be sent in a separate 429 packet containing no data. The Binding Update contains the mobile 430 node's care-of address, an identification for the Update (to sequence 431 Updates and to protect against attempts to replay it), and a lifetime 432 for the binding. The mobile node's IPv6 home address MUST be the 433 source address of the packet containing the Binding Update, since 434 the option does not contain space to separately represent the mobile 435 node's home address. 437 Binding Updates should be considered a form of routing updates; 438 handled incorrectly, they could be a source of security problems and 439 routing loops. Therefore, packets which include Binding Updates MUST 440 also include an IPv6 Authentication header [1]; sequencing and replay 441 protection is then achieved by use of the Identification field in the 442 Binding Update. 444 The Binding Update option is encoded in type-length-value (TLV) 445 format as follows: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Option Type | Option Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |A|H|L| Reserved | Lifetime | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | 455 + Identification + 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 + + 460 | | 461 + Care-of Address + 462 | | 463 + + 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 + + 468 | | 469 + Home Link-Local Address + 470 | (only present if L bit set) | 471 + + 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Option Type 477 16 479 Option Length 481 8-bit unsigned integer. Length of the option, in octets, 482 excluding the Option Type and Option Length fields. For the 483 current definition of the Binding Update option, this field 484 must be set to 28. 486 Acknowledge (A) 488 The Acknowledge (A) bit is set by the sending node to request a 489 Binding Acknowledgement message be returned upon receipt of the 490 Binding Update option. 492 Home Registration (H) 494 The Home Registration (H) bit is set by the sending node to 495 request the receiving node to act as this node's home agent. 496 The Destination Address in the IPv6 header of the packet 497 carrying this option MUST be that of a router sharing the same 498 network prefix as the mobile node's home IPv6 address. 500 Home Link-Local Address Present (L) 502 The Home Link-Local Address Present (L) bit indicates the 503 presence of the Home Link-Local Address field in the Binding 504 Update. This bit is set by the sending mobile node to request 505 the receiving node to act as a proxy (for participating in 506 the Neighbor Discovery Protocol) for the node while it is 507 away from home. This bit MUST NOT be set unless the Home 508 Registration (H) bit is also set in the Binding Update. 510 Reserved 512 Sent as 0; ignored on reception. 514 Lifetime 516 16-bit unsigned integer. The number of seconds remaining 517 before the binding must be considered expired. A value of all 518 ones (0xffff) indicates infinity. A value of zero indicates 519 that the Binding Cache entry for the mobile node should be 520 deleted. 522 Identification 524 a 64-bit number used to sequence Binding Updates and to match 525 a returned Binding Acknowledgement message with this Binding 526 Update. The Identification field also serves to protect 527 against replay attacks for Binding Updates. 529 Care-of Address 531 The current care-of address of the mobile node. When set equal 532 to the home address of the mobile node, the Binding Update 533 option instead indicates that any existing binding for the 534 mobile node should be deleted; no binding for the mobile node 535 should be created. 537 Home Link-Local Address 539 The link-local address of the mobile node used by the mobile 540 node when it was last attached to its home network. This field 541 in the Binding Update is optional and is only present when the 542 Home Link-Local Address (L) bit is set. 544 As with all IPv6 options, the highest-order three bits of the Option 545 Type Field (16) of the Binding Update option specify the following 546 properties of the option: 548 - The highest-order two bits are 00: Any node receiving this 549 option that does not recognize the Option Type MUST skip over 550 this option and continue processing the header. 552 - The third-highest-order bit is 0: The Option Data does not 553 change en-route, and thus, when an Authentication header is 554 present in the packet, the entire Binding Update option MUST be 555 included when computing or verifying the packet's authenticating 556 value. 558 Extensions to the Binding Update option format may be included after 559 the fixed portion of the Binding Update option specified above. 560 The presence of such extensions will be indicated by the Option 561 Length field. When the Option Length is greater than 28 octets, 562 the remaining octets are interpreted as extensions. Currently no 563 extensions have been defined. 565 3.2. ICMP Binding Acknowledgement Message 567 A Binding Acknowledgement message is an informational ICMP message 568 used to acknowledge acceptance of a Binding Update (Section 3.1) 569 option, if that Binding Update has the Acknowledge (A) bit set. 571 Upon receipt of a Binding Update requesting an acknowledgement, the 572 receiving node returns a Binding Acknowledgement message addressed to 573 the care-of address in the Binding Update. 575 If a mobile node fails to receive an acceptable Binding 576 Acknowledgement message within INITIAL_BINDACK_TIMEOUT seconds 577 after transmitting the Binding Update, it SHOULD retransmit the 578 Binding Update until a Binding Acknowledgement is received. Such a 579 retransmitted Binding Update MUST use he same Identification value as 580 the original transmission. The retransmissions by the mobile node 581 MUST use an exponential back-off process, in which timeout period 582 is doubled upon each retransmission until either the node receives 583 a Binding Acknowledgement message or the timeout period reaches the 584 value MAX_BINDACK_TIMEOUT. 586 The ICMP Binding Acknowledgement message has the following format: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type | Code | Checksum | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 + Identification + 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Type 600 133 602 Code 604 8-bit unsigned integer indicating the disposition of the 605 Binding Update. Values of the Code field less than 128 606 indicate that the Binding Update was accepted by the receiving 607 node. The following such values are currently defined: 609 0 Binding Update accepted 611 Values of the Code field greater than or equal to 128 indicate 612 that the Binding Update was rejected by the receiving node. 613 The following such values are currently defined: 615 128 Reason unspecified 616 129 Poorly formed Binding Update 617 130 Administratively prohibited 618 131 Insufficient resources 619 132 Home registration not supported 620 133 Not home network 621 134 Identification field mismatch 622 135 Unknown home agent address 624 Checksum 626 The checksum of the message calculated as specified for ICMP 627 for IPv6 [4]. 629 Identification 631 The acknowledgement Identification is derived from the Binding 632 Update option, for use by the mobile node in matching the 633 acknowledgement with an outstanding Binding Update. 635 Up-to-date values of the Code field are to be specified in the most 636 recent "Assigned Numbers" [10]. 638 Extensions to the Binding Acknowledgement message format may be 639 included after the fixed portion of the Binding Acknowledgement 640 message specified above. The presence of such extensions will be 641 indicated by the ICMP message length, derived from the IPv6 Payload 642 Length field. When the Option Length is greater than 16 octets, 643 the remaining octets are interpreted as extensions. Currently no 644 extensions have been defined. 646 4. Requirements for IPv6 Nodes 648 Mobile IPv6 places some special requirements on the functions 649 provided by different IPv6 nodes. This section itemizes those 650 requirements, identifying the functionality each requirement is 651 intended to support. Further details on this functionality is 652 provided in the following sections. 654 Since any IPv6 node may at any time be a correspondent of a mobile 655 node, all IPv6 nodes MUST support the following requirements: 657 - Every IPv6 node MUST be able to process a received Binding Update 658 option, and to return a Binding Acknowledgement message if 659 requested. 661 - Every IPv6 node MUST be able to maintain a Binding Cache of the 662 bindings received in accepted Binding Updates. 664 - Every IPv6 node MUST be able to maintain Security Associations 665 for use in IPv6 Authentication Headers [2, 1, 6]. An IPv6 666 node receiving a packet containing a Binding Update option 667 MUST verify, using the Authentication Header in the packet, 668 the authenticity of the sender (the mobile node for which this 669 binding applies) before modifying its Binding Cache in response 670 to that Binding Update option. 672 Since any IPv6 router may at any time have a Binding Cache entry 673 for a mobile node, all IPv6 router MUST support the following 674 requirement: 676 - Every IPv6 router MUST be able to use its Binding Cache in 677 forwarding packets; if the router has a Binding Cache entry for 678 the Destination Address of a packet it is forwarding, then the 679 router SHOULD encapsulate the packet and tunnel it to the care-of 680 address in the Binding Cache entry. 682 In order for a mobile node to correctly operate while away from 683 home, at least one IPv6 router in its home network must support 684 functioning as a home agent for the mobile node. All IPv6 routers 685 capable of serving as a home agent MUST support the following special 686 requirements: 688 - Every home agent MUST be able to maintain a registry of mobile 689 node bindings for those mobile nodes for which it is serving as 690 the home agent. 692 - Every home agent MUST be able to intercept packets (e.g., using 693 Neighbor Advertisements) on the local network addressed to 694 a mobile node for which it holds a binding in its registry 695 indicating that the mobile node is currently away from home. 697 - Every home agent MUST be able to encapsulate such intercepted 698 packets in order to tunnel them to the care-of address for the 699 mobile node indicated in its binding. 701 - Every home agent MUST be able to issue Binding Acknowledgement 702 messages in response to Binding Updates received from a mobile 703 node. 705 - Every home agent MUST be able to maintain Security Associations 706 for the mobile nodes from which it will accept Binding Updates. 708 Finally, all IPv6 nodes capable of functioning as mobile nodes MUST 709 support the following requirements: 711 - Every IPv6 mobile node MUST be able to perform IPv6 712 decapsulation [5]. 714 - Every IPv6 mobile node MUST support sending Binding Updates, 715 as specified in Sections 6.3, 6.4, and 6.5; and MUST be able 716 to receive and process Binding Acknowledgement messages, as 717 specified in Section 6.7. 719 - Every IPv6 mobile node MUST maintain a Binding Update List in 720 which it keeps track of which other IPv6 nodes it has sent a 721 Binding Update to, for which the Lifetime sent in that binding 722 has not yet expired. 724 5. Binding Cache Management 726 The Binding Cache is the central data structure in Mobile IPv6. 727 All IPv6 nodes MUST support maintenance of a Binding Cache, and 728 MUST support processing of received Binding Updates. This section 729 describes the management aspects of a Binding Cache common to all 730 nodes. 732 5.1. Receiving Binding Updates 734 Upon receiving a Binding Update option in some packet, the receiving 735 node MUST validate the packet according to the following tests: 737 - The packet contains an IP Authentication header and the 738 authentication is valid [1]. The Authentication header is 739 assumed to provide both authentication and integrity protection. 741 - The length of the option specified in the Option Length field is 742 greater than or equal to 28 octets. 744 - The Identification field is valid. 746 Any Binding Update not satisfying all of these tests MUST be silently 747 ignored, although the remainder of the packet (i.e., other options, 748 extension headers, or payload) SHOULD be processed normally according 749 to any procedure defined for that part of the packet. 751 If the Binding Update is valid according to the tests above, then the 752 Binding Update is processed further as follows: 754 - If the Lifetime specified in the Binding Update is nonzero and 755 the specified Care-of Address differs from the Home Address, 756 this is a request to cache a binding for the mobile node. 757 Processing for this type of received Binding Update is described 758 in Section 5.2. 760 - If the Lifetime specified in the Binding Update is zero or the 761 specified Care-of Address matches the Home Address, then this is 762 a request to delete the mobile node's binding. Processing for 763 this type of received Binding Update is described in Section 5.3. 765 5.2. Requests to Cache a Binding 767 If a node receives a valid Binding Update requesting it to cache a 768 binding for a mobile node, as specified in Section 5.1, then the node 769 MUST examine the Home Registration (H) bit in the Binding Update 770 to determine how to further process the Binding Update. If the 771 Home Registration (H) bit is set, the Binding Update is processed 772 according to the procedure specified in Section 7.1. 774 If the Home Registration (H) bit is not set, then the receiving 775 node SHOULD create a new entry in its Binding Cache for this mobile 776 node's Home Address (or update its existing Binding Cache Entry for 777 this Home Address) to record the Care-of Address as specified in the 778 Binding Update, and begin a timer to delete this Binding Cache entry 779 after the expiration of the Lifetime period specified in the Binding 780 Update. 782 5.3. Requests to Delete a Binding 784 If a node receives a valid Binding Update requesting it to delete 785 a binding for a mobile node, as specified in Section 5.1, then the 786 node MUST examine the Home Registration (H) bit in the Binding Update 787 to determine how to further process the Binding Update. If the 788 Home Registration (H) bit is set, the Binding Update is processed 789 according to the procedure specified in Section 7.2. 791 If the Home Registration (H) bit is not set, and if a node receives a 792 valid Binding Update requesting it to delete a binding for a mobile 793 node, as specified in Section 5.1, then it MUST delete any existing 794 entry in its Binding Cache for this mobile node's Home Address. 796 5.4. Sending Binding Acknowledgements 798 When any node receives a packet containing a Binding Update option, 799 it SHOULD return a Binding Acknowledgement message acknowledging 800 receipt of the Binding Update. If the node accepts the Binding 801 Update and adds the binding contained in it to its Binding Cache, the 802 Code field in the Binding Acknowledgement MUST be set to a value less 803 than 128; if the node rejects the Binding Update and does not add 804 the binding contained in it to its Binding Cache, the Code field in 805 the Binding Acknowledgement MUST be set to a value greater than or 806 equal to 128. Specific values for the Code field are described in 807 Section 3.2 and in the most recent "Assigned Numbers" [10]. 809 The Destination Address in the IPv6 header for the Binding 810 Acknowledgement MUST be set to the Care-of Address copied from the 811 Binding Update option. This ensures that the Binding Acknowledgement 812 will be routed to the current location of the node sending the 813 Binding Update, whether the Binding Update was accepted or rejected. 815 5.5. Cache Replacement Policy 817 Any entry in a node's Binding Cache MUST be deleted after the 818 expiration the Lifetime specified in the Binding Update from which 819 the entry was created. Conceptually, a node MUST maintain a separate 820 timer for each entry in its Binding Cache. When creating or updating 821 a Binding Cache entry in response to a received Binding Update, the 822 node sets the timer for this entry to the specified Lifetime period. 823 When a Binding Cache entry's timer expires, the node MUST delete the 824 entry. 826 Each node's Binding Cache will, by necessity, have a finite size. 827 A node MAY use any reasonable local policy for managing the space 828 within its Binding Cache, except that any entry marked as a "home 829 registration" (Section 7.1) SHOULD NOT be deleted from the cache 830 until the expiration of its lifetime period. When attempting to 831 add a new "home registration" entry in response to Binding Update 832 with the Home Registration (H) bit set, if insufficient space exists 833 (or can be reclaimed) in the node's Binding Cache, the node MUST 834 reject the Binding Update and SHOULD return a Binding Acknowledgement 835 message to the sending mobile node, in which the Code field is set to 836 131 (Insufficient resources). When otherwise attempting to add a new 837 entry to its Binding Cache, a node MAY if needed choose to drop any 838 entry already in the Binding Cache other than a "home registration" 839 entry, in order to make space for the new entry. For example, a 840 "least-recently used" (LRU) strategy for cache entry replacement is 841 likely to work well. 843 If a packet is sent by a node to a destination for which it has 844 dropped the cache entry from its Binding Cache, the packet will be 845 routed normally, leading to the mobile node's home network, where it 846 will be intercepted by the mobile node's home agent and tunneled to 847 the mobile node's current primary care-of address. As when a Binding 848 Cache entry is initially created, this indirect routing to the mobile 849 node will result in the mobile node sending a Binding Update to this 850 sending node, allowing it to add this entry again to its Binding 851 Cache. 853 5.6. Receiving ICMP Error Messages 855 When a correspondent node sends a packet to a mobile node, if the 856 correspondent node has a Binding Cache entry for the destination 857 mobile node's address (its home address), then the correspondent node 858 uses a Routing header to deliver the packet to the mobile node's 859 care-of address, and then to the mobile node's home address. Any 860 ICMP error message caused by the packet on its way to the mobile node 861 will be returned normally to the correspondent node. 863 On the other hand, if the correspondent node has no Binding Cache 864 entry for the mobile node, the packet will be routed to the mobile 865 node's home network, where it will be intercepted by the mobile 866 node's home agent, encapsulated, and tunneled to the mobile node's 867 care-of address. Similarly, if a packet for a mobile node arrives 868 at the mobile node's previous default router (e.g., the mobile node 869 moved after the packet was sent), the router will encapsulate and 870 tunnel the packet to the mobile node's new care-of address (if it has 871 a Binding Cache entry for the mobile node). Any ICMP error message 872 caused by the packet on its way to the mobile node while in the 873 tunnel, will be returned to the node that encapsulated the packet 874 (the home agent or the previous default router, respectively). By 875 the definition of IPv6 encapsulation [5], however, this encapsulating 876 node MUST relay certain ICMP error messages back to the original 877 sender of the packet (the correspondent node). 879 Thus, whether the correspondent node has a Binding Cache entry 880 for the destination mobile node or not, the correspondent node 881 will receive any meaningful ICMP error message that is caused by 882 its packet on its way to the mobile node. If the correspondent 883 node receives an ICMP Host Unreachable or Network Unreachable 884 error message after sending a packet to a mobile node using its 885 cached care-of address, the correspondent node SHOULD delete its 886 Binding Cache entry for this mobile node. If the correspondent node 887 subsequently transmits another packet to the mobile node, the packet 888 will be routed to the mobile node's home network, intercepted by the 889 mobile node's home agent, and tunneled to the mobile node's care-of 890 address using IPv6 encapsulation. The mobile node will then return a 891 Binding Update to the correspondent node, allowing it to recreate a 892 (correct) Binding Cache entry for the mobile node. 894 6. Mobile Node Considerations 896 6.1. Movement Detection 898 A mobile node MAY use any combination of mechanisms available to 899 it to detect when its link-level point of attachment has moved 900 from one IPv6 subnet to another. The primary movement detection 901 mechanism for Mobile IPv6 defined here uses the facilities of 902 IPv6 Neighbor Discovery, including Router Discovery and Neighbor 903 Unreachability Detection. The description here is based on the 904 conceptual model of the organization and data structures defined by 905 Neighbor Discovery [9]. 907 Mobile nodes SHOULD use Router Discovery to discover new routers and 908 on-link network prefixes; a mobile node MAY send Router Solicitation 909 messages, or MAY wait for unsolicited (periodic) Router Advertisement 910 messages, as specified for Router Discovery [9]. Based on received 911 Router Advertisement messages, a mobile node (in the same way as any 912 other node) maintains an entry in its Default Router List for each 913 router, and an entry in its Prefix List for each network prefix, 914 that it currently considers to be on-link. Each entry in these 915 lists has an associated invalidation timer value (extracted from the 916 Advertisement) used to expire the entry when it becomes invalid. 918 While away from home, a mobile node SHOULD select one router from its 919 Default Router List to use as its default router, and one network 920 prefix advertised by that router from its Prefix List to use as 921 the network prefix in its primary care-of address. A mobile node 922 MAY also have associated additional care-of addresses, using other 923 network prefixes from its Prefix List. The method by which a mobile 924 node selects and forms a care-of address from the available network 925 prefixes is described in Section 6.2. The mobile node registers 926 its primary care-of address with its home agent, as described in 927 Section 6.3. 929 While away from home and using some router as its default router, 930 it is important for a mobile node to be able to quickly detect when 931 that router becomes unreachable, so that it can switch to a new 932 default router and to a new primary care-of address. Since some 933 links (notably wireless) do not necessarily work equally well in 934 both directions, it is likewise important for the mobile node to 935 detect when it becomes unreachable to its default router, so that any 936 correspondent nodes attempting to communicate with the mobile node 937 can still reach it. 939 To detect when its default router becomes unreachable, a mobile 940 node SHOULD use Neighbor Unreachability Detection. As specified 941 in Neighbor Discovery [9], while the mobile node is actively 942 sending packets to (or through) its default router, the mobile node 943 can detect that the router has become unreachable either through 944 indications from upper layer protocols on the mobile node that a 945 connection is not making "forward progress" (e.g., TCP timing out 946 waiting for an acknowledgement after a number of retransmissions), 947 or through the failure to receive a Neighbor Advertisement messages 948 form its default router in response to retransmitted explicit 949 Neighbor Solicitation messages to it. No exceptions to Neighbor 950 Unreachability Detection are necessary for this aspect of movement 951 detection in Mobile IPv6. 953 For a mobile node to detect when it has become unreachable to its 954 default router, however, the mobile node cannot efficiently rely on 955 Neighbor Unreachability Detection alone, since the network overhead 956 would be prohibitively high in many cases for a mobile node to 957 continually probe its default router with Neighbor Solicitation 958 messages even when it is not otherwise actively sending packets to 959 it. Instead, a mobile node SHOULD consider receipt of any IPv6 960 packets from its current default router as an indication that it is 961 still reachable from the router. Both packets from the router's IPv6 962 address and (IPv6) packets from its link-layer address (e.g., those 963 forwarded but not originated by the router) SHOULD be considered. 965 Since the router SHOULD be sending periodic multicast Router 966 Advertisement messages, the mobile node will have frequent 967 opportunity to check if it is still reachable to its default router, 968 even in the absence of other packets to it from the router. On some 969 types of network interfaces, the mobile node MAY also supplement 970 this by setting its network interface into "promiscuous" receive 971 mode, so that is able to receive all packets on the link, including 972 those not link-level addressed to it. The mobile node will then 973 be able to detect any packets sent by the router, in order to to 974 detect reachability from the router. This may be useful on very low 975 bandwidth (e.g., wireless) links, but its use MUST be configurable on 976 the mobile node. 978 If the above means do not provide indication that the mobile node 979 is still reachable from its current default router (i.e., the 980 mobile node receives no packets form the router for a period of 981 time), then the mobile node SHOULD actively probe the router with 982 Neighbor Solicitation messages, even if it is not otherwise actively 983 sending packets to the router. If it receives a solicited Neighbor 984 Advertisement message in response from the router, then the mobile 985 node can deduce that it is still reachable. It is expected that the 986 mobile node will in most cases be able to determine its reachability 987 from the router by listening for packets from the router as described 988 above, and thus, such extra Neighbor Unreachability Detection probes 989 should rarely be necessary. 991 With some types of networks, it is possible that additional 992 indications about link-layer mobility can be obtained from 993 lower-layer protocol or device driver software within the mobile 994 node. However, a mobile node MUST NOT assume that all link-layer 995 mobility indications from lower layers indicate a movement of the 996 mobile node's link-layer connection to a new IPv6 subnet, such that 997 the mobile node would need to switch to a new default router and 998 primary care-of address. Upon lower-layer indication of link-layer 999 mobility, the mobile node SHOULD send Router Solicitation messages 1000 to determine if new routers (and new on-link network prefixes) are 1001 present on its new link. 1003 Such lower-layer information might also be useful to a mobile node in 1004 deciding to switch its primary care-of address to one of the other 1005 care-of addresses it has formed from the on-link network prefixes 1006 currently available through different default routers from which the 1007 mobile node is reachable. For example, a mobile node MAY use signal 1008 strength or signal quality information (with suitable hysteresis) 1009 for its link with the available default routers to decide when to 1010 switch to a new primary care-of address using that default router 1011 rather than its current default router (and current primary care-of 1012 address). Even though the mobile node's current default router may 1013 still be reachable in terms of Neighbor Unreachability Detection, the 1014 mobile node MAY use such lower-layer information to determine that 1015 switching to a new default router would provide a better connection. 1017 6.2. Forming New Care-of Addresses 1019 After detecting that its link-layer point of attachment has moved 1020 from one IPv6 subnet to another (i.e., its current default router 1021 has become unreachable and it has discovered a new default router), 1022 a mobile node SHOULD form a new primary care-of address using one of 1023 the on-link network prefixes advertised by the new router. A mobile 1024 node MAY form a new primary care-of address at any time, except 1025 that it MUST NOT do so too frequently (more often than once per 1026 MAX_UPDATE_RATE seconds). 1028 In addition, after discovering a new on-link network prefix, a 1029 mobile node MAY form a new (non-primary) care-of address using that 1030 network prefix, even when it has not switched to a new default 1031 router. A mobile node can have only one primary care-of address 1032 at a time (registered with its home agent), but it MAY have an 1033 additional care-of address for each network prefix on its current 1034 link. Furthermore, since a wireless network interface may actually 1035 allow a mobile node to be reachable on more than one link at a time 1036 (i.e., within wireless transmitter range of routers on more than one 1037 separate link), a mobile node MAY have care-of addresses on more than 1038 one link at a time. For more information on using more than one 1039 care-of address at a time, see Section 6.8. 1041 As described in Section 2, in order to form a new care-of address, 1042 a mobile node MAY use either stateless [12] or stateful (e.g., 1043 DHCPv6 [3]) address autoconfiguration. If a mobile node needs to 1044 send packets as part of the method of address autoconfiguration, it 1045 MUST use an IPv6 link-local address rather than its own IPv6 home 1046 address as the Source Address. 1048 In some cases, a mobile node may already know a (constant) IPv6 1049 address that has been assigned to it for its use while visiting this 1050 network. For example, it may be statically configured with an IPv6 1051 address assigned by the system administrator of the new network. If 1052 so, rather than using address autoconfiguration to form a new care-of 1053 address using this network prefix, the mobile node SHOULD use its own 1054 pre-assigned address as its care-of address on this network. 1056 6.3. Sending Binding Updates to the Home Agent 1058 After changing its primary care-of address as described in 1059 Sections 6.1 and 6.2, a mobile node SHOULD register its new primary 1060 care-of address with its home agent. To do so, the mobile node sends 1061 a packet to its home agent containing a Binding Update option with 1062 the Acknowledge (A) bit set, requesting the home agent to return a 1063 Binding Acknowledgement message in response to this Binding Update. 1064 As described in Section 3.2, the mobile node SHOULD retransmit this 1065 Binding Update to its home agent until it receives a matching Binding 1066 Acknowledgement message. Once reaching a retransmission timeout 1067 period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD continue 1068 to periodically retransmit the Binding Update at this rate until 1069 acknowledged. 1071 It is useful for a mobile node to be able to send a Binding Update 1072 its home agent without explicitly knowing the home agent's address. 1073 For example, since the mobile node was last at home, it may have 1074 become necessary to replace the node serving as its home agent due 1075 to the failure of the original node or due to reconfiguration of the 1076 home network. It thus may not always be possible or convenient for a 1077 mobile node to know the exact address of its own home agent. 1079 Mobile nodes can dynamically discover the address of a home agent 1080 by sending a Binding Update to the anycast address on their home 1081 network. Each router on the home network which receives this Binding 1082 Update MUST reject the Binding Update and include its address in the 1083 Binding Acknowledgement message indicating the rejection. The mobile 1084 node is assumed to know a proper anycast address on its home network 1085 before making use of this method for determining a particular home 1086 agent's address. 1088 6.4. Sending Binding Updates to Correspondent Nodes 1090 A mobile node MAY also include a Binding Update in any normal data 1091 packet sent to a correspondent node. For each correspondent node 1092 to which it has sent a Binding Update, the mobile node MUST keep 1093 information to determine whether or not the correspondent node has 1094 been sent a fresh Binding Update since the last time the mobile node 1095 switched to a new primary care-of address. When a packet is to be 1096 sent to a correspondent node that has not been sent a fresh Binding 1097 Update, the mobile node SHOULD include the Binding Update within the 1098 packet. Thus, correspondent nodes are generally kept updated and 1099 can send almost all data packets directly to the mobile node using 1100 the mobile node's current binding. Such Binding Updates are not 1101 generally required to be acknowledged; however, if the mobile node 1102 wants to be sure, an acknowledgement can be requested, although in 1103 this case, the mobile node SHOULD NOT continue to retransmit the 1104 Binding Update once the retransmission timeout period has reached 1105 MAX_BINDACK_TIMEOUT. 1107 A mobile node MAY also send a Binding Update in any otherwise empty 1108 packet, whenever the mobile node wishes to update a correspondent 1109 node as to its current binding. This is normally done only if 1110 the mobile suspects that its home agent is not operational or is 1111 too far away, a correspondent node is not sending the traffic to 1112 the proper care-of address, or there is an immediate need for the 1113 correspondent node to obtain the binding. A mobile node can detect 1114 that a correspondent node is not sending packets to the proper 1115 care-of address because in that case the packets arrive at the mobile 1116 node's care-of address by encapsulation instead by inclusion in a 1117 routing header within the packet. 1119 A mobile node MAY choose to keep its location private from certain 1120 correspondent nodes, and thus need not send new Binding Updates to 1121 those correspondents. A mobile node MAY also send a Binding Update 1122 to such a correspondent node to instruct it to delete any existing 1123 binding for the mobile node from its Binding Cache, as described in 1124 Section 3.1. No other IPv6 nodes are authorized to send Binding 1125 Updates on behalf of a mobile node. 1127 6.5. Sending Binding Updates to the Previous Default Router 1129 After switching to a new default router (and thus also changing 1130 its primary care-of address), a mobile node SHOULD send a Binding 1131 Update message to its previous default router, giving its new care-of 1132 address. If it sends such a Binding Update, the mobile node MUST set 1133 the Home Address field to its old primary care-of address (that it 1134 used while using this default router), and set the Care-of Address 1135 field to its new primary care-of address. Note that the previous 1136 router does not necessarily know the mobile node's home address as 1137 part of this sequence of events. 1139 The mobile node's previous default router then, in effect, 1140 temporarily act as a home agent for the mobile node's old primary 1141 care-of address. If any subsequent packets arrive at this previous 1142 router for forwarding to the mobile node's old primary care-of 1143 address, the router SHOULD encapsulate each and tunnel it to the 1144 mobile node at its new primary care-of address. Moreover, the 1145 previous router should issue Neighbor Advertisement packets for the 1146 previous care-of address, so that on-link neighbors will send packets 1147 destined to the mobile node's old primary care-of address to the 1148 previous router for encapsulation and tunneling to its new care-of 1149 address. 1151 6.6. Rate Limiting for Sending Binding Updates 1153 A mobile node MUST NOT send Binding Update messages more often than 1154 once per MAX_UPDATE_RATE seconds to any correspondent node. After 1155 sending 5 consecutive Binding Updates to a particular correspondent 1156 node with the same care-of address, the mobile node SHOULD reduce its 1157 rate of sending Binding Updates to that correspondent node, to the 1158 rate of SLOW_UPDATE_RATE per second. The mobile node MAY continue 1159 to send Binding Updates at the slower rate indefinitely, in hopes 1160 that the correspondent node will finally be able to process a Binding 1161 Update and begin to route its packets directly to the mobile node at 1162 its current primary care-of address. 1164 6.7. Receiving Binding Acknowledgements 1166 Upon receiving a packet carrying a Binding Acknowledgement message, 1167 a mobile node MUST validate the packet according to the following 1168 tests: 1170 - The packet contains an IP Authentication header and the 1171 authentication is valid [1]. The Authentication header is 1172 assumed to provide both authentication and integrity protection. 1174 - The ICMP Checksum is valid. 1176 - The length of the ICMP message (derived from the IPv6 Payload 1177 Length field) is greater than or equal to 16 octets. 1179 - The Identification field is valid. 1181 Any Binding Acknowledgement not satisfying all of these tests MUST be 1182 silently discarded. 1184 If the Binding Acknowledgement is valid, the mobile node MUST examine 1185 the Code field as follows: 1187 - If the Code field indicates that the Binding Update was accepted 1188 (the Code field is less than 128), then the mobile node MUST 1189 update the corresponding entry in its Binding Update List to 1190 indicate that the Binding Update has been acknowledged. The 1191 mobile node SHOULD thus stop retransmitting the Binding Update. 1193 - If the Code field indicates that the Binding Update was not 1194 accepted (the Code field is greater than or equal to 128), then 1195 the mobile node MUST delete the corresponding Binding Update List 1196 entry. Optionally, the mobile node MAY take steps to correct the 1197 cause of the error and retransmit the Binding Update, subject to 1198 the rate limiting restriction specified in Section 6.6. 1200 6.8. Using Multiple Care-of Addresses 1202 As described in Section 6.2, a mobile node MAY have more than 1203 one care-of address at a time. Particularly in the case of many 1204 wireless networks, a mobile node effectively may be reachable through 1205 multiple link-level points of attachment at the same time (e.g., 1206 with overlapping wireless cells), on which different on-link network 1207 prefixes may exist. A mobile node SHOULD select a primary care-of 1208 address from among those care-of addresses it has formed using any 1209 of these network prefixes, based on the movement detection mechanism 1210 in use (Section 6.1). When the mobile node selects a new primary 1211 care-of address, it MUST register it with its home agent through a 1212 Binding Update message with the Acknowledge (A) bit set, as described 1213 in Section 6.3. 1215 To assist in smooth handoffs, a mobile node SHOULD retain its 1216 previous primary care-of address as a care-of address, and SHOULD 1217 still accept packets at this address, even after registering its new 1218 primary care-of address with its home agent. This is reasonable, 1219 since the mobile node could only receive packets at its previous 1220 primary care-of address if it were indeed still connected to that 1221 link. If the previous primary care-of address was allocated using 1222 stateful address autoconfiguration [3], the mobile node may not wish 1223 to release the address immediately upon switching to a new primary 1224 care-of address. The stateful address autoconfiguration server 1225 will allow mobile nodes to acquire new addresses while still using 1226 previously allocated addresses. 1228 6.9. Returning Home 1230 A mobile node detects that it has returned to its home network 1231 through the movement detection algorithm in use (Section 6.1), 1232 when the mobile node detects that its home network prefix is again 1233 on-link. The mobile node SHOULD then send a Binding Update to its 1234 home agent, to instruct its home agent to no longer intercept or 1235 tunnel packets for it. In this Binding Update, the mobile node MUST 1236 set the Care-of Address field to its own IPv6 home address. As with 1237 other Binding Updates sent to register with its home agent, the 1238 mobile node MUST set the Acknowledge (A) and Home Registration (H) 1239 bits and SHOULD retransmit the Binding Update until a matching 1240 Binding Acknowledgement message is received. 1242 The mobile node MUST also send out the appropriate Neighbor 1243 Advertisement packets with the Override flag set, so that its 1244 neighbors on its home network will update the relevant information 1245 for the mobile node in their Neighbor Caches. The mobile node 1246 MUST do this for both its link-local address and its home address. 1247 The Neighbor Advertisement packets can be repeated a small number 1248 of times to guard against occasional loss of packets on the home 1249 network. 1251 7. Home Agent Considerations 1253 7.1. Home Agent Care-of Address Registration 1255 General processing of a received Binding Update that requests a 1256 binding to be cached, is described in Section 5.2. However, if the 1257 Home Registration (H) bit is set in the Binding Update, then the 1258 receiving node MUST process the Binding Update as specified in this 1259 section, rather than following the generall procedure specified in 1260 Section 5.2. 1262 To begin processing the Binding Update, the home agent MUST perform 1263 the following sequence of tests: 1265 - If the node is not a router that implements home agent 1266 functionality, then the node MUST reject the Binding Update and 1267 SHOULD return a Binding Acknowledgement message to the mobile 1268 node, in which the Code field is set to 132 (Home registration 1269 not supported). 1271 - Else, if the Home Address field in the Binding Update is not an 1272 on-link IPv6 address with respect to the home agent's current 1273 Prefix List, then the home agent MUST reject the Binding Update 1274 and SHOULD return a Binding Acknowledgement message to the mobile 1275 node, in which the Code field is set to 133 (Not home network). 1277 - Else, if the home agent chooses to reject the Binding Update for 1278 any other reason (e.g., insufficient resources to serve another 1279 mobile node as a home agent), then the home agent SHOULD return a 1280 Binding Acknowledgement message to the mobile node, in which the 1281 Code field is set to an appropriate value to indicate the reason 1282 for the rejection. 1284 If the home agent does not reject the Binding Update as described 1285 above, then it becomes the home agent for the mobile node. The 1286 new home agent (the receiving node) MUST then create a new entry 1287 (or update the existing entry) in its Binding Cache for this 1288 mobile node's Home Address, as described in Section 5.2. In 1289 addition, the home agent MUST mark this Binding Cache entry as a 1290 "home registration" to indicate that the node is serving as a home 1291 agent for this binding. Binding Cache entries marked as a "home 1292 registration" SHOULD be excluded from the normal cache replacement 1293 policy used for the Binding Cache (Section 5.5) and SHOULD NOT be 1294 removed from the Binding Cache until the expiration of the Lifetime 1295 period. 1297 If the home agent was not already serving as a home agent for the 1298 Home Address specified in the Binding Update (the home agent did 1299 not already have a Binding Cache entry for this address marked as 1300 a "home registration"), then the home agent MUST multicast onto 1301 the home network (to the all-nodes multicast address), a Neighbor 1302 Advertisement message on behalf of the mobile node, with the fields 1303 in the Neighbor Advertisement set as follows: 1305 Router Flag (R) 1307 1 -- the sending node (the home agent) is a router. 1309 Solicited Flag (S) 1311 0 -- the Neighbor Advertisement message is unsolicited. 1313 Override Flag (O) 1315 1 -- the advertisement SHOULD override any existing Neighbor 1316 Cache entry at the receiver, updating the receiver's cached 1317 link-layer address for this Target Address. 1319 Target Address 1321 The mobile node's home address, copied from the Home Address 1322 field of the Binding Update. 1324 Options 1326 The home agent MUST include at least a Target Link-layer 1327 Address option in the Neighbor Advertisement message, in which 1328 the Link-Layer Address gives the link-layer address of the home 1329 agent itself. 1331 Any node on the home network receiving this Neighbor Advertisement 1332 message will thus update its Neighbor Cache to associate the mobile 1333 node's home address with the home agent's link layer address, causing 1334 it to transmit future packets for the mobile node instead to the 1335 mobile node's home agent. Since multicasts on the local link (such 1336 as Ethernet) are typically not guaranteed to be reliable, the home 1337 agent MAY retransmit this Neighbor Advertisement message a small 1338 number of times to increase its reliability. It is still possible 1339 that some nodes on the home network will not receive any of these 1340 Neighbor Advertisements, but these nodes will eventually be able 1341 to detect the link-layer address change for the mobile node's home 1342 address, through use of Neighbor Unreachability Detection [9]. 1344 In addition, while this node is serving as a home agent to any mobile 1345 node (it has at least one entry marked as a "home registration" in 1346 its Binding Cache), it SHOULD act as a proxy for each such mobile 1347 node to reply to any received Neighbor Solicitation messages for 1348 it. When a home agent receives a Neighbor Solicitation message, it 1349 MUST check if the Target Address specified in the message matches 1350 the Home Address of any mobile node for which it has a Binding Cache 1351 entry marked as a "home registration". If such an entry exists 1352 in its Binding Cache, the home agent MUST reply to the Neighbor 1353 Solicitation message with a Neighbor Advertisement message, giving 1354 the home agent's own link-layer address as the link-layer address for 1355 the specified Target Address. 1357 7.2. Home Agent Care-of Address De-registration 1359 General processing of a received Binding Update that requests a 1360 binding to be deleted, is described in Section 5.3. However, if the 1361 Home Registration (H) bit is set in the Binding Update, then the 1362 receiving node MUST process the Binding Update as specified in this 1363 section, rather than following the generall procedure specified in 1364 Section 5.3. 1366 To begin processing the Binding Update, the home agent MUST perform 1367 the following sequence of tests: 1369 - If the node is not a router that implements home agent 1370 functionality, then the node MUST reject the Binding Update and 1371 SHOULD return a Binding Acknowledgement message to the mobile 1372 node, in which the Code field is set to 132 (Home registration 1373 not supported). 1375 - Else, if the Home Address field in the Binding Update is not an 1376 on-link IPv6 address with respect to the home agent's current 1377 Prefix List, then it MUST reject the Binding Update and SHOULD 1378 return a Binding Acknowledgement message to the mobile node, in 1379 which the Code field is set to 133 (Not home network). 1381 If the home agent does not reject the Binding Update as described 1382 above, then it MUST delete any existing entry in its Binding Cache 1383 for this mobile node's Home Address, as specified in the Binding 1384 Update. 1386 In addition, the home agent SHOULD multicast a Neighbor Advertisement 1387 message (to the all-nodes multicast address), giving the mobile 1388 node's home address as the Target Address, and specifying the mobile 1389 node's link-layer address in a Target Link-layer Address option in 1390 the Neighbor Advertisement message. The home agent MAY retransmit 1391 this Neighbor Advertisement message a small number of times to 1392 increase its reliability, and any nodes on the home network that miss 1393 all of these Neighbor Advertisements can also eventually detect the 1394 link-layer address change for the mobile node's home address, through 1395 use of Neighbor Unreachability Detection [9]. 1397 7.3. Delivering Packets to a Mobile Node 1399 Home agents cannot use Routing headers to deliver packets to the 1400 mobile node, because they can't modify the packet and add to it 1401 in flight. They must always use IPv6 encapsulation [5] for this 1402 purpose. 1404 When a home agent encapsulates a packet for delivery to the mobile 1405 node, the home agent uses the care-of address as the destination 1406 address in the outer IPv6 header. Since the mobile node is presumed 1407 to be receiving packets at the care-of address, the delivery path 1408 from the care-of address to the mobile node's home address is then 1409 trivial. 1411 Note that the home agent cannot insert a routing header, or 1412 modify the destination address of the mobile node, because of IPv6 1413 authentication mechanisms [1]. The home agent is expected to be 1414 involved only rarely with the transmission of data to the mobile 1415 node, because the mobile node will send Binding Updates as soon as 1416 possible to its correspondent nodes. 1418 7.4. Renumbering the Home Network 1420 Neighbor Discovery [9] specifies a mechanism by which all nodes on a 1421 network can gracefully autoconfigure new addresses, say by combining 1422 a new routing prefix with their existing MAC address. As currently 1423 specified, this mechanism works when the nodes are on the same link 1424 as the router issuing the necessary multicast packets to advertise 1425 the new routing prefix(es) appropriate for the link. 1427 However, for mobile nodes away from home, special care must be taken 1428 to allow the mobile nodes to renumber gracefully. The most direct 1429 method of insuring this is for the home agent to encapsulated and 1430 tunnel the multicast packets to the care-of address of the mobile 1431 node as necessary. The rules for this are as follows: 1433 - A mobile node assumes that its routing prefix has not changes 1434 unless it receives authenticated router advertisement messages 1435 from its home agent that the prefix has changed. 1437 - When the mobile node is at home, the home agent does not tunnel 1438 router advertisements to it. 1440 - When a home network prefix changes, the home agent tunnels router 1441 advertisement packets to each mobile node which is currently 1442 away from home and using a home address with the affected 1443 routing prefix. Such tunneled router advertisements MUST be 1444 authenticated [1]. 1446 - When a mobile node receives a tunneled router advertisement 1447 containing a new routing prefix, it must perform the standard 1448 autoconfiguration operation to create its new address 1450 - When a mobile node returns to its home network, it must again 1451 perform Duplicate Address Detection at the earliest possible 1452 moment after it has registered with its home agent. 1454 - A mobile node may send a router solicitation to its home agent at 1455 any time, within the constraints imposed by rate control in the 1456 Neighbor Discovery specification [9] 1458 Note that a mobile node is guaranteed that its home address is unique 1459 and used by no other mobile node. However, in some circumstances it 1460 may nevertheless be true that other nodes on its home network form 1461 the same link-local address as the mobile node during the time when 1462 the mobile node is away from its home network. Thus, there is the 1463 requirement above that the mobile node perform Duplicate Address 1464 Detection when it returns again to its home network. 1466 8. Correspondent Node Considerations 1468 8.1. Delivering Packets to a Mobile Node 1470 The routing infrastructure of the Internet will normally route a 1471 packet destined to a mobile node to the mobile node's home network, 1472 if the Destination Address in the packet's IPv6 header is the mobile 1473 node's home address. Once the packet reaches the home network, it 1474 will be intercepted by the mobile node's home agent if the mobile 1475 node is away from home, and will then be encapsulated using IPv6 1476 encapsulation and tunneled to the mobile node's current primary 1477 care-of address. Using this delivery mechanism, the sender need not 1478 know that the node is mobile. 1480 Correspondent nodes that have received and cached a Binding Update 1481 for a mobile node, MAY instead route packets directly to that mobile 1482 node's care-of address. To do so, the correspondent node includes 1483 a Routing header in each packet to the mobile node, to cause the 1484 packet to be routed to the mobile node's care-of address as the last 1485 intermediate routing point before reaching the final destination 1486 of the mobile node's home address. When the packet arrives at the 1487 care-of address (which the mobile node has associated with its 1488 network interface), normal processing of the Routing header by the 1489 mobile node will result in delivery of the packet to the mobile node 1490 as the final destination of the packet. 1492 For example, assuming no other use of the Routing header in the 1493 packet, the sender initializes the Destination Address in the IPv6 1494 header to the mobile node's care-of address, and includes a Type 0 1495 Routing header [6] in the packet initialized as follows: 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Next Header | Hdr Ext Len | Routing Type=0|Segments Left=1| 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Reserved | Strict/Loose Bit Map | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | | 1503 + + 1504 | | 1505 + Home Address + 1506 | | 1507 + + 1508 | | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 Next Header 1512 8-bit selector. Identifies the type of header immediately 1513 following the Routing header. 1515 Hdr Ext Len 1517 8-bit unsigned integer. Length of the Routing header in 1518 8-octet units, not including the first 8 octets. For this use 1519 of the Type 0 Routing header, Hdr Ext Len is equal to 2. 1521 Routing Type 1523 0 1525 Segments Left 1527 8-bit unsigned integer. Number of route segments remaining 1528 before reaching the final destination. For this use of the 1529 Type 0 Routing header, Segments Left is initialized to 1 by the 1530 sender. 1532 Reserved 1534 8-bit reserved field. Initialized to zero for transmission; 1535 ignored on reception. 1537 Strict/Loose Bit Map 1539 24-bit bit-map, numbered 0 to 23, left-to-right. For this use 1540 of the Type 0 Routing header, bit 0 of the Strict/Loose Bit Map 1541 is set to 1, indicating strict routing from the care-of 1542 address to the mobile node's home address (both addresses are 1543 associated with the mobile node itself). 1545 Home Address 1547 The home address of the destination mobile node. 1549 If a correspondent node receives an ICMP Host Unreachable or Network 1550 Unreachable message after sending a packet to a mobile node using 1551 its cached care-of address, it SHOULD delete the cache entry from 1552 its Binding Cache until information about the mobile node's current 1553 care-of address becomes available (via a Binding Update). 1555 9. Authentication and Replay Protection 1557 When sending Binding Updates, a mobile node uses the Identification 1558 field in the option, in conjunction with the IPv6 Authentication 1559 Header, to protect against replays of the Binding Update. The style 1560 of replay protection specified for the IPv6 Binding Update involves 1561 the use of a timestamp as the Identification data. Accordingly the 1562 mobile node and the target of its Binding Update have to roughly 1563 agree on the current time. Stale Binding Updates MUST be rejected. 1565 10. Routing Multicast Packets 1567 A mobile node that is connected to its home network functions just 1568 like any other (stationary) node. Thus, when it is at home, a mobile 1569 node functions identically to other multicast senders and receivers. 1570 This section therefore describes the behavior of a mobile node that 1571 is not on its home network. 1573 In order receive multicasts, a mobile node must join the multicast 1574 group. Mobile nodes MAY join multicast groups in order to receive 1575 transmissions in one of two ways. First, they MAY join the group 1576 via a (local) multicast router on the visited subnet. This option 1577 assumes that there is a multicast router present on the visited 1578 subnet. The mobile node SHOULD use its dynamically acquired care-of 1579 address (if it has acquired one) as the source IPv6 address of its 1580 multicast group membership control message packets. Otherwise, it 1581 MAY use its home address. 1583 Alternatively, a mobile node which wishes to receive multicasts can 1584 join groups via a bi-directional tunnel to its home agent, assuming 1585 that its home agent is a multicast router. The mobile node tunnels 1586 the appropriate multicast group membership control packets to its 1587 home agent and the home agent forwards multicast packets down the 1588 tunnel to the mobile node. The home agent must tunnel the packet 1589 directly to the mobile node's dynamically acquired care-of address, 1590 or, the packet must be tunneled first to the mobile node's home 1591 address and then recursively tunneled to the mobile node's care-of 1592 address. 1594 A mobile node which wishes to send packets to a multicast group also 1595 has two options: (1) send directly on the visited network; or (2) 1596 send via a tunnel to its home agent. Because multicast routing in 1597 general depends upon the IPv6 source address, a mobile node which 1598 sends multicast packets directly on the visited network MUST use a 1599 dynamically acquired care-of address as the IPv6 source address. 1600 Similarly, a mobile node which tunnels a multicast packet to its home 1601 agent MUST use its home address as the IPv6 source address of both 1602 the (inner) multicast packet and the (outer) encapsulating packet. 1603 This second option assumes that the home agent is a multicast router. 1605 11. Constants 1607 INITIAL_BINDACK_TIMEOUT 1 second 1609 MAX_BINDACK_TIMEOUT 256 seconds 1611 MAX_UPDATE_RATE 1 per second 1613 SLOW_UPDATE_RATE once per 10 seconds 1615 Acknowledgements 1617 We would like to thank Thomas Narten for contributing valuable 1618 discussion and reviewing this draft, and for helping to shape some of 1619 the recent changes relevant to the operation of Neighbor Discovery. 1621 References 1623 [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 1625 [2] R. Atkinson. Security Architecture for the Internet Protocol. 1626 RFC 1825, August 1995. 1628 [3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol 1629 for IPv6. draft-ietf-dhc-dhcpv6-05.txt -- work in progress, 1630 June 1996. 1632 [4] A. Conta and S. Deering. Internet Control Message Protocol 1633 (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, 1634 December 1995. 1636 [5] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 1637 draft-ietf-ipngwg-ipv6-tunnel-01.txt - work in progress, 1638 February 1996. 1640 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1641 Specification. RFC 1883, December 1995. 1643 [7] D. Haskin and E. Allen. IP Version 6 over PPP. 1644 draft-ietf-ipngwg-pppext-ipv6cp-03.txt - work in progress, June 1645 1996. 1647 [8] David B. Johnson and Charles E. Perkins. Route Optimization 1648 in Mobile-IP. draft-ietf-mobileip-optim-04.txt -- work in 1649 progress, February 1996. 1651 [9] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor 1652 Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in 1653 progress, November 1995. 1655 [10] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, 1656 October 1994. 1658 [11] Fumio Teraoka. draft-teraoka-ipv6-mobility-sup-02.txt. 1659 Internet Draft -- work in progress, January 1996. 1661 [12] S. Thomson and T. Narten. IPv6 Stateless Address 1662 Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt 1663 - work in progress, November 1995. 1665 A. Open Issues 1667 A.1. Session Keys with Local Routers 1669 In the IPv4 route optimization proposal [8], a mechanism is outlined 1670 whereby a session key can be established between foreign agents 1671 and mobile nodes, without requiring any pre-established security 1672 relationship between them. A similar mechanism could be defined for 1673 IPv6, to avoid the need for a possibly time-consuming negotiation 1674 between routers and mobile nodes for the purpose of obtaining the 1675 session key, which under many circumstances would only be used once. 1676 This mechanism, if needed, can be specified completely outside 1677 the Mobile IPv6 protocol and would amount to a way of creating a 1678 dynamic security association between two nodes which do not share an 1679 existing trust relationship, but which need to agree on a key for 1680 some particular purpose (here, allowing the future authentication of 1681 a Binding Update). Hopefully, the work of the IP Security Working 1682 Group will allow this function to be performed appropriately for 1683 mobile nodes, say by a Diffie-Hellman key exchange. 1685 A.2. Source Address Filtering by Firewalls 1687 The current specification does nothing to permit mobile nodes to 1688 send their packets through firewalls which filter out packets with 1689 the "wrong" source IPv6 addresses in the IPv6 packet header. The 1690 mobile node's home address may be unlikely to fall within the ranges 1691 required to satisfy the firewall's criteria for further delivery. 1693 As indicated by recent discussion, firewalls are unlikely to 1694 disappear. Any standardized solution [11] to the firewall problem 1695 based on hiding the non-local source address outside the source 1696 address field of the IPv6 header is likely to fail. Any vendor or 1697 facilities administrator wanting to filter based on the address in 1698 the IPv6 source address field would also quickly begin filtering on 1699 hidden source addresses. 1701 Assume, for the moment, that a mobile node is able to establish a 1702 secure tunnel through a firewall protecting the domain in which 1703 a correspondent node is located. The mobile node could then 1704 encapsulate its packet so that the outer IPv6 header was addressed 1705 to the firewall and used the mobile node's care-of address as the 1706 source address. When the firewall decapsulates, it would be able to 1707 authenticate the inner packet based (correctly) on the mobile node's 1708 home address. After the authentication is performed, the firewall 1709 could forward the packet to the correspondent node as desired. This 1710 simple procedure has the feature that it requires the minimal amount 1711 of encapsulation, no assistance by routers or other agents, and that 1712 the firewall can establish a security relationship with the mobile 1713 node based on its home (i.e., permanent) address. 1715 Chair's Address 1717 The Working Group can be contacted via its current chair: 1719 Jim Solomon 1720 Motorola, Inc. 1721 1301 E. Algonquin Rd. 1722 Schaumburg, IL 60196 1724 Work: +1-847-576-2753 1725 E-mail: solomon@comm.mot.com 1727 Authors' Addresses 1729 Questions about this document can also be directed to the authors: 1731 David B. Johnson 1732 Computer Science Department 1733 Carnegie Mellon University 1734 5000 Forbes Avenue 1735 Pittsburgh, PA 15213-3891 1737 Work: +1 412 268-7399 1738 Fax: +1 412 268-5576 1739 E-mail: dbj@cs.cmu.edu 1741 Charles Perkins 1742 Room H3-D34 1743 T. J. Watson Research Center 1744 IBM Corporation 1745 30 Saw Mill River Rd. 1746 Hawthorne, NY 10532 1748 Work: +1 914 789-7350 1749 Fax: +1 914 784-6205 1750 E-mail: perk@watson.ibm.com