idnits 2.17.1 draft-arkko-mip6-3775bis-ndmobext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 684. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2461, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3775, but the abstract doesn't seem to directly say this. It does mention RFC3775 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 the creation date from RFC2461, updated by this document, for RFC5378 checks: 1997-07-30) (Using the creation date from RFC3775, updated by this document, for RFC5378 checks: 1996-01-29) -- 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 27, 2006) is 6634 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) == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-05 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Updates: 3775,2461 (if approved) C. Perkins 5 Expires: August 31, 2006 Nokia Research Center 6 D. Johnson 7 Rice University 8 February 27, 2006 10 IPv6 Neighbor Discovery Extensions for Mobility 11 draft-arkko-mip6-3775bis-ndmobext-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 31, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This specification extends IPv6 Neighbor Discovery with features that 45 are useful for mobile nodes. These features provide information for 46 the purposes of detecting the loss of Router Advertisements, 47 determining the global address of the router, or for discovering 48 which routers are also Mobile IPv6 home agents. These extensions are 49 required for Mobile IPv6 operation, but they are also useful for any 50 type of nomadic or mobile nodes. This document revises a part of RFC 51 3775 which originally defined these extensions. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 57 3. General Extensions . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Router Address Extension for Prefix Information Option . . 3 59 3.2. Advertisement Interval Option . . . . . . . . . . . . . . 5 60 3.3. Changes to Sending Router Advertisements . . . . . . . . . 6 61 4. Extensions for Mobile IPv6 Support . . . . . . . . . . . . . . 8 62 4.1. Modified Router Advertisement Message . . . . . . . . . . 8 63 4.2. Home Agent Information Option . . . . . . . . . . . . . . 9 64 4.3. Home Agents List . . . . . . . . . . . . . . . . . . . . . 11 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 70 Appendix A. Changes from RFC 3775 . . . . . . . . . . . . . . . . 14 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 75 1. Introduction 77 This specification extends IPv6 Neighbor Discovery with features that 78 are useful for mobile nodes. These features provide information for 79 the purposes of detecting the loss of Router Advertisements, 80 determining the global address of the router, or for discovering 81 Mobile IPv6 home agents (see RFC 3775 [RFC3775]). This specification 82 also relaxes the timing constraints related to the sending of the 83 Router Advertisements. 85 These extensions are complementary to other protocol enhancements, 86 including those defined in [I-D.pentland-dna-protocol3] for fast 87 detection of network attachments. 89 The extensions in this specification are required for Mobile IPv6 90 operation, but they are also useful for any type of nomadic or mobile 91 nodes. The generally useful extensions are introduced in Section 3 92 and the Mobile IPv6 specific extensions in Section 4. 94 2. Requirements language 96 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 97 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 98 described in [RFC2119]. 100 3. General Extensions 102 3.1. Router Address Extension for Prefix Information Option 104 Knowledge of a router's global address can be useful in many cases, 105 including the building of a list of home agents in Mobile IPv6 106 [RFC3775]. 108 However, Neighbor Discovery [I-D.ietf-ipv6-2461bis] only advertises a 109 router's link- local address, by requiring this address to be used as 110 the IP Source Address of each Router Advertisement. 112 This specification extends Neighbor Discovery to allow a router to 113 advertise its global address, by the addition of a single flag bit in 114 the format of a Prefix Information option for use in Router 115 Advertisement messages. The format of the Prefix Information option 116 is as follows: 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type | Length | Prefix Length |L|A|R|Reserved1| 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Valid Lifetime | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Preferred Lifetime | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Reserved2 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 + + 131 | | 132 + Prefix + 133 | | 134 + + 135 | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 This format represents the following changes over that originally 139 specified for Neighbor Discovery [I-D.ietf-ipv6-2461bis]: 141 Router Address (R) 143 1-bit router address flag. When set, indicates that the Prefix 144 field contains a complete IP address assigned to the sending 145 router. The indicated prefix is the first Prefix Length bits of 146 the Prefix field. The router IP address has the same scope and 147 conforms to the same lifetime values as the advertised prefix. 148 This use of the Prefix field is compatible with its use in 149 advertising the prefix itself, since Prefix Advertisement uses 150 only the leading bits. Interpretation of this flag bit is thus 151 independent of the processing required for the On-Link (L) and 152 Autonomous Address-Configuration (A) flag bits. 154 Reserved1 156 Reduced from a 6-bit field to a 5-bit field to account for the 157 addition of the above bit. 159 In a Router Advertisement, a Mobile IPv6 home agent MUST, and all 160 other routers MAY, include at least one Prefix Information option 161 with the Router Address (R) bit set. Neighbor Discovery specifies 162 that, if including all options in a Router Advertisement causes the 163 size of the Advertisement to exceed the link MTU, multiple 164 Advertisements can be sent, each containing a subset of the options 165 [I-D.ietf-ipv6-2461bis]. Also, when sending unsolicited multicast 166 Router Advertisements more frequently than the limit specified in 167 Neighbor Discovery [I-D.ietf-ipv6-2461bis], the sending router need 168 not include all options in each of these Advertisements. However, in 169 both of these cases the router SHOULD include at least one Prefix 170 Information option with the Router Address (R) bit set in each such 171 advertisement, if this bit is set in some advertisement sent by the 172 router. 174 In addition, the following requirement can assist mobile nodes in 175 movement detection. Barring changes in the prefixes for the link, 176 routers that send multiple Router Advertisements with the Router 177 Address (R) bit set in some of the included Prefix Information 178 options SHOULD provide at least one option and router address which 179 stays the same in all of the Advertisements. 181 3.2. Advertisement Interval Option 183 The Advertisement Interval option is used in Router Advertisement 184 messages to advertise the interval at which the sending router sends 185 unsolicited multicast Router Advertisements. The format of the 186 Advertisement Interval option is as follows: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type | Length | Reserved | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Advertisement Interval | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Where the fields are defined as follows: 198 Type 200 7 202 Length 204 8-bit unsigned integer. The length of the option (including the 205 type and length fields) is in units of 8 octets. The value of 206 this field MUST be 1. 208 Reserved 210 This field is unused. It MUST be initialized to zero by the 211 sender and MUST be ignored by the receiver. 213 Advertisement Interval 215 32-bit unsigned integer. The maximum time, in milliseconds, 216 between successive unsolicited Router Advertisement messages sent 217 by this router on this network interface. Using the conceptual 218 router configuration variables defined by Neighbor Discovery 219 [I-D.ietf-ipv6-2461bis], this field MUST be equal to the value 220 MaxRtrAdvInterval, expressed in milliseconds. 222 Routers MAY include this option in their Router Advertisements. All 223 IPv6 routers SHOULD be able to send it, to aid movement detection by 224 mobile nodes. The use of this option SHOULD be configurable. 226 If Router Advertisements that a mobile node receives include an 227 Advertisement Interval option, the mobile node may use its 228 Advertisement Interval field as an indication of the frequency with 229 which it should expect to continue to receive future Advertisements 230 from that router. This field specifies the minimum rate (the maximum 231 amount of time between successive Advertisements) that the mobile 232 node should expect. If this amount of time elapses without the 233 mobile node receiving any Advertisement from this router, the mobile 234 node can be sure that at least one Advertisement sent by the router 235 has been lost. The mobile node can then implement its own policy to 236 determine how many lost Advertisements from its current default 237 router constitute an L3 handover indication. 239 This option MUST be silently ignored for other Neighbor Discovery 240 messages. 242 3.3. Changes to Sending Router Advertisements 244 The Neighbor Discovery protocol specification [I-D.ietf-ipv6-2461bis] 245 limits routers to a minimum interval of 3 seconds between sending 246 unsolicited multicast Router Advertisement messages from any given 247 network interface (limited by MinRtrAdvInterval and 248 MaxRtrAdvInterval), stating that: 250 "Routers generate Router Advertisements frequently enough that 251 hosts will learn of their presence within a few minutes, but not 252 frequently enough to rely on an absence of advertisements to 253 detect router failure; a separate Neighbor Unreachability 254 Detection algorithm provides failure detection." 256 This limitation, however, is not suitable to providing timely 257 movement detection for mobile nodes. Mobile nodes detect their own 258 movement by learning the presence of new routers as the mobile node 259 moves into wireless transmission range of them (or physically 260 connects to a new wired network), and by learning that previous 261 routers are no longer reachable. Mobile nodes need to quickly detect 262 when they move to a link served by a new router, so that they can 263 acquire a new care-of address, register this address in a Mobile IPv6 264 homea agent (for instance), and notify correspondent nodes as needed. 266 One method which can provide for faster movement detection, is to 267 increase the rate at which unsolicited Router Advertisements are 268 sent. This specification relaxes this limit such that routers MAY 269 send unsolicited multicast Router Advertisements more frequently. 270 This method can be applied where the router is expecting to provide 271 service to mobile nodes. 273 All IPv6 routers SHOULD be able to support a faster rate. The 274 minimum allowed values are: 276 o MinRtrAdvInterval 0.03 seconds 278 o MaxRtrAdvInterval 0.07 seconds 280 In the case where the minimum intervals and delays are used, the mean 281 time between unsolicited multicast router advertisements is 50 ms. 282 Use of these modified limits MUST be configurable. Systems where 283 these values are available MUST NOT default to them, and SHOULD 284 default to values specified in Neighbor Discovery [I-D.ietf-ipv6- 285 2461bis]. Knowledge of the type of network interface and operating 286 environment SHOULD be taken into account in configuring these limits 287 for each network interface. This is important with some wireless 288 links, where increasing the frequency of multicast beacons can cause 289 considerable overhead. Routers SHOULD adhere to the intervals 290 specified in Neighbor Discovery [I-D.ietf-ipv6-2461bis], if this 291 overhead is likely to cause service degradation. 293 Additionally, the possible low values of MaxRtrAdvInterval may cause 294 some problems with movement detection in some mobile nodes. To 295 ensure that this is not a problem, Routers SHOULD add 20 ms to any 296 Advertisement Intervals sent in RAs, which are below 200 ms, in order 297 to account for scheduling granularities on both the MN and the 298 Router. 300 Note that multicast Router Advertisements are not always required in 301 wireless networks that have limited bandwidth, as mobility detection 302 or link changes in such networks may also be done at lower layers. 303 Router advertisements in such networks SHOULD be sent only when 304 solicited. In such networks it SHOULD be possible to disable 305 unsolicited multicast Router Advertisements on specific interfaces. 306 The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set 307 to some high values. 309 Similarly, routers that support a faster rate MUST allow this 310 variable to be configured by system management: 312 MinDelayBetweenRAs Default: 3 seconds, 313 Min: 0.03 seconds 315 The value MinDelayBetweenRAs overrides the value of the protocol 316 constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery 317 [I-D.ietf-ipv6-2461bis]. This variable SHOULD be set to 318 MinRtrAdvInterval, if MinRtrAdvInterval is less than 3 seconds. 320 Mobile IPv6 Home agents MUST include the Source Link-Layer Address 321 option in all Router Advertisements they send. This simplifies the 322 process of returning home, as discussed in [RFC3775]. 324 Note that according to Neighbor Discovery [I-D.ietf-ipv6-2461bis], 325 AdvDefaultLifetime is by default based on the value of 326 MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime 327 field of Router Advertisements. Given that this field is expressed 328 in seconds, a small MaxRtrAdvInterval value can result in a zero 329 value for this field. To prevent this, routers SHOULD keep 330 AdvDefaultLifetime in at least one second, even if the use of 331 MaxRtrAdvInterval would result in a smaller value. 333 4. Extensions for Mobile IPv6 Support 335 4.1. Modified Router Advertisement Message 337 A single flag bit to indicates that the router sending the Router 338 Advertisement message [I-D.ietf-ipv6-2461bis] is serving as a Mobile 339 IPv6 home agent on this link. The format of the Router Advertisement 340 message is as follows: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Code | Checksum | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Reachable Time | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Retrans Timer | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Options ... 354 +-+-+-+-+-+-+-+-+-+-+-+- 355 This format represents the following changes over that originally 356 specified for Neighbor Discovery [I-D.ietf-ipv6-2461bis]: 358 Home Agent (H) 360 The Home Agent (H) bit is set in a Router Advertisement to 361 indicate that the router sending this Router Advertisement is also 362 functioning as a Mobile IPv6 home agent on this link. 364 Reserved 366 Reduced from a 6-bit field to a 5-bit field to account for the 367 addition of the above bit. 369 Mobile IPv6 home agents MUST support this format and related 370 processing rules in Section 4.3. 372 4.2. Home Agent Information Option 374 The Home Agent Information option is used in Router Advertisements 375 sent by a Mobile IPv6 home agent to advertise information specific to 376 this router's functionality as a home agent. The format of the Home 377 Agent Information option is as follows: 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type | Length | Reserved | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Home Agent Preference | Home Agent Lifetime | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Where the fields are defined as follows: 389 Type 391 8 393 Length 395 8-bit unsigned integer. The length of the option (including the 396 type and length fields) in units of 8 octets. The value of this 397 field MUST be 1. 399 Reserved 401 This field is unused. It MUST be initialized to zero by the 402 sender and MUST be ignored by the receiver. 404 Home Agent Preference 406 16-bit unsigned integer. The preference for the home agent 407 sending this Router Advertisement, for use in ordering the 408 addresses returned to a mobile node in the Home Agent Addresses 409 field of a Home Agent Address Discovery Reply message. Higher 410 values mean more preferable. If this option is not included in a 411 Router Advertisement in which the Home Agent (H) bit is set, the 412 preference value for this home agent MUST be considered to be 0. 413 Greater values indicate a more preferable home agent than lower 414 values. 416 Mobile IPv6 home agents SHOULD support a configuration mechanism 417 to allow a system administrator to manually set the value to be 418 sent in this field. In addition, the sending home agent MAY 419 dynamically set the Home Agent Preference value, for example 420 basing it on the number of mobile nodes it is currently serving or 421 on its remaining resources for serving additional mobile nodes; 422 such dynamic settings are beyond the scope of this document. Any 423 such dynamic setting of the Home Agent Preference, however, MUST 424 set the preference appropriately, relative to the default Home 425 Agent Preference value of 0 that may be in use by some home agents 426 on this link (i.e., a home agent not including a Home Agent 427 Information option in its Router Advertisements will be considered 428 to have a Home Agent Preference value of 0). 430 Home Agent Lifetime 432 16-bit unsigned integer. The lifetime associated with the home 433 agent in units of seconds. The default value is the same as the 434 Router Lifetime, as specified in the main body of the Router 435 Advertisement. The maximum value corresponds to 18.2 hours. A 436 value of 0 MUST NOT be used. The Home Agent Lifetime applies only 437 to this router's usefulness as a home agent; it does not apply to 438 information contained in other message fields or options. 440 Mobile IPv6 home agents MUST support this option and related process 441 rules in Section 4.3. 443 Home agents MAY include this option in their Router Advertisements. 444 This option MUST NOT be included in a Router Advertisement in which 445 the Home Agent (H) bit (see Section 4.1) is not set. If this option 446 is not included in a Router Advertisement in which the Home Agent (H) 447 bit is set, the lifetime for this home agent MUST be considered to be 448 the same as the Router Lifetime in the Router Advertisement. If 449 multiple Advertisements are being sent instead of a single larger 450 unsolicited multicast Advertisement, all of the multiple 451 Advertisements with the Router Address (R) bit set MUST include this 452 option with the same contents, otherwise this option MUST be omitted 453 from all Advertisements. 455 This option MUST be silently ignored for other Neighbor Discovery 456 messages. 458 If both the Home Agent Preference and Home Agent Lifetime are set to 459 their default values specified above, this option SHOULD NOT be 460 included in the Router Advertisement messages sent by this home 461 agent. 463 4.3. Home Agents List 465 Each Mobile IPv6 home agent MUST maintain a conceptual data structure 466 called the Home Agents List. 468 The Home Agents List is maintained by each home agent, recording 469 information about each router on the same link that is acting as a 470 home agent. This list is used by the dynamic home agent address 471 discovery mechanism from [RFC3775]. A router is known to be acting 472 as a home agent, if it sends a Router Advertisement in which the Home 473 Agent (H) bit is set. When the lifetime for a list entry (defined 474 below) expires, that entry is removed from the Home Agents List. The 475 Home Agents List is similar to the Default Router List conceptual 476 data structure maintained by each host for Neighbor Discovery 477 [I-D.ietf-ipv6-2461bis]. The Home Agents List MAY be implemented in 478 any manner consistent with the external behavior described in this 479 document. 481 Each home agent maintains a separate Home Agents List for each link 482 on which it is serving as a home agent. A new entry is created or an 483 existing entry is updated in response to receipt of a valid Router 484 Advertisement in which the Home Agent (H) bit is set. Each Home 485 Agents List entry conceptually contains the following fields: 487 o The link-local IP address of a home agent on the link. This 488 address is learned through the Source Address of the Router 489 Advertisements received from the router. 491 o One or more global IP addresses for this home agent. Global 492 addresses are learned through Prefix Information options with the 493 Router Address (R) bit set and received in Router Advertisements 494 from this link-local address. Global addresses for the router in 495 a Home Agents List entry MUST be deleted once the prefix 496 associated with that address is no longer valid. 498 o The remaining lifetime of this Home Agents List entry. If a Home 499 Agent Information Option is present in a Router Advertisement 500 received from a home agent, the lifetime of the Home Agents List 501 entry representing that home agent is initialized from the Home 502 Agent Lifetime field in the option (if present); otherwise, the 503 lifetime is initialized from the Router Lifetime field in the 504 received Router Advertisement. If Home Agents List entry lifetime 505 reaches zero, the entry MUST be deleted from the Home Agents List. 507 o The preference for this home agent; higher values indicate a more 508 preferable home agent. The preference value is taken from the 509 Home Agent Preference field in the received Router Advertisement, 510 if the Router Advertisement contains a Home Agent Information 511 Option and is otherwise set to the default value of 0. A home 512 agent uses this preference in ordering the Home Agents List when 513 it sends an ICMP Home Agent Address Discovery message. 515 On receipt of a valid Router Advertisement, as defined in the 516 processing algorithm specified for Neighbor Discovery, the home agent 517 performs the following steps in addition to any steps already 518 required of it by Neighbor Discovery: 520 o If the Home Agent (H) bit in the Router Advertisement is not set, 521 delete the sending node's entry in the current Home Agents List 522 (if one exists). Skip all the following steps. 524 o Otherwise, extract the Source Address from the IP header of the 525 Router Advertisement. This is the link-local IP address on this 526 link of the home agent sending this Advertisement. 528 o Determine the preference for this home agent. If the Router 529 Advertisement contains a Home Agent Information Option, then the 530 preference is taken from the Home Agent Preference field in the 531 option; otherwise, the default preference of 0 MUST be used. 533 o Determine the lifetime for this home agent. If the Router 534 Advertisement contains a Home Agent Information Option, then the 535 lifetime is taken from the Home Agent Lifetime field in the 536 option; otherwise, the lifetime specified by the Router Lifetime 537 field in the Router Advertisement SHOULD be used. 539 o If the link-local address of the home agent sending this 540 Advertisement is already present in this home agent's Home Agents 541 List and the received home agent lifetime value is zero, 542 immediately delete this entry in the Home Agents List. 544 o Otherwise, if the link-local address of the home agent sending 545 this Advertisement is already present in the receiving home 546 agent's Home Agents List, reset its lifetime and preference to the 547 values determined above. 549 o If the link-local address of the home agent sending this 550 Advertisement is not already present in the Home Agents List 551 maintained by the receiving home agent, and the lifetime for the 552 sending home agent is non-zero, create a new entry in the list, 553 and initialize its lifetime and preference to the values 554 determined above. 556 o If the Home Agents List entry for the link-local address of the 557 home agent sending this Advertisement was not deleted as described 558 above, determine any global address(es) of the home agent based on 559 each Prefix Information option received in this Advertisement in 560 which the Router Address (R) bit is set (Section 3.1). Add all 561 such global addresses to the list of global addresses in this Home 562 Agents List entry. 564 A home agent SHOULD maintain an entry in its Home Agents List for 565 each valid home agent address until that entry's lifetime expires, 566 after which time the entry MUST be deleted. 568 5. Security Considerations 570 This specification allows additional information to be provided about 571 routers on this link. Disclosure of this information is usually not 572 a problem, and where it is, controlling access to the link helps 573 avoid this problem along with many others. 575 Spoofing this information can, however, be problematic in certain 576 cases. For instance, sending a spoofed Router Advertisement with a 577 smaller Advertisement Interval than what is really in use may 578 convince other nodes on the link to believe that they have moved. 579 This vulnerability can be addressed in the same way as other Router 580 Discovery information can be protected, for instance, by employing 581 SEND [RFC3971]. Similarly, attackers may spoof information related 582 to Mobile IPv6 home agents available on this link. However, the 583 discovery of home agents as such does not lead nodes into believing 584 that these are indeed legitimate home agents, even if this 585 information was secured at the Router Discovery level. An actual use 586 of the home agent requires mutual authentication between the mobile 587 node and the home agents. 589 6. IANA Considerations 591 This document defines two Neighbor Discovery options (Section 3.2 and 592 Section 4.2), which have already been assigned Option Type values 7 593 and 8 within the option numbering space for Neighbor Discovery 594 messages per RFC 3775. No new IANA action is required. 596 7. References 598 7.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [I-D.ietf-ipv6-2461bis] 604 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 605 draft-ietf-ipv6-2461bis-05 (work in progress), 606 October 2005. 608 7.2. Informative References 610 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 611 in IPv6", RFC 3775, June 2004. 613 [I-D.pentland-dna-protocol3] 614 Pentland, B., "Detecting Network Attachment in IPv6 615 Networks (DNAv6)", draft-pentland-dna-protocol3-00 (work 616 in progress), October 2005. 618 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 619 Neighbor Discovery (SEND)", RFC 3971, March 2005. 621 Appendix A. Changes from RFC 3775 623 This document provides no protocol changes or extensions over what 624 was defined in RFC 3775 [RFC3775]. Security considerations for these 625 extensions have, however, been provided. 627 Appendix B. Acknowledgements 629 The authors wish to thank everyone involved in the creation of RFC 630 3775, and Thomas Narten for suggesting specific parts of document the 631 document that could be in different specifications. 633 Charlie Perkins and Dave Johnson are listed as authors of this draft 634 due them being authors of RFC 3775. 636 Authors' Addresses 638 Jari Arkko 639 Ericsson 640 Jorvas 02420 641 Finland 643 Email: jari.arkko@ericsson.com 645 Charles E. Perkins 646 Nokia Research Center 647 313 Fairchild Drive 648 Mountain View CA 94043 649 USA 651 Email: charliep@iprg.nokia.com 653 David B. Johnson 654 Rice University 655 Dept. of Computer Science, MS 132 656 6100 Main Street 657 Houston TX 77005-1892 658 USA 660 Email: dbj@cs.rice.edu 662 Intellectual Property Statement 664 The IETF takes no position regarding the validity or scope of any 665 Intellectual Property Rights or other rights that might be claimed to 666 pertain to the implementation or use of the technology described in 667 this document or the extent to which any license under such rights 668 might or might not be available; nor does it represent that it has 669 made any independent effort to identify any such rights. Information 670 on the procedures with respect to rights in RFC documents can be 671 found in BCP 78 and BCP 79. 673 Copies of IPR disclosures made to the IETF Secretariat and any 674 assurances of licenses to be made available, or the result of an 675 attempt made to obtain a general license or permission for the use of 676 such proprietary rights by implementers or users of this 677 specification can be obtained from the IETF on-line IPR repository at 678 http://www.ietf.org/ipr. 680 The IETF invites any interested party to bring to its attention any 681 copyrights, patents or patent applications, or other proprietary 682 rights that may cover technology that may be required to implement 683 this standard. Please address the information to the IETF at 684 ietf-ipr@ietf.org. 686 Disclaimer of Validity 688 This document and the information contained herein are provided on an 689 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 690 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 691 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 692 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 693 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 694 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 696 Copyright Statement 698 Copyright (C) The Internet Society (2006). This document is subject 699 to the rights, licenses and restrictions contained in BCP 78, and 700 except as set forth therein, the authors retain all their rights. 702 Acknowledgment 704 Funding for the RFC Editor function is currently provided by the 705 Internet Society.