idnits 2.17.1 draft-ietf-dna-routers-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. ** 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 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.) 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). -- 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 (Oct 23, 2005) is 6753 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) == Unused Reference: '2' is defined on line 561, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 573, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 585, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 592, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 596, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 600, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '5') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '6') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2472 (ref. '8') (Obsoleted by RFC 5072, RFC 5172) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-02 == Outdated reference: A later version (-01) exists of draft-jinchoi-dna-frd-00 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group S. Narayanan 3 Internet-Draft Panasonic 4 Expires: April 26, 2006 G. Daley 5 Monash University CTIE 6 N. Montavont 7 LSIIT - ULP 8 Oct 23, 2005 10 Detecting Network Attachment in IPv6 - Best Current Practices for 11 Routers 12 draft-ietf-dna-routers-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 26, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 Hosts experiencing rapid link-layer changes may require to do 46 configuration change detection procedures more frequently than 47 traditional fixed hosts. This document describes practices available 48 to network deployers in order to support such hosts in Detecting 49 Network Attachment in IPv6 networks. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 55 1.2 Relevant Host Issues . . . . . . . . . . . . . . . . . . . 4 56 1.3 Relevant Router Issues . . . . . . . . . . . . . . . . . . 4 57 1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Configuration Practices for DNAv6 Routers . . . . . . . . . . 5 60 2.1 Multicast and Unicast RA Responses . . . . . . . . . . . . 5 61 2.1.1 Recommendations . . . . . . . . . . . . . . . . . . . 7 62 2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7 63 2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8 64 2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8 65 2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9 66 2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9 67 2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9 68 2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10 70 3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10 71 3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10 72 3.2 Multiple Router Links . . . . . . . . . . . . . . . . . . 10 73 3.3 Point-to-point Links . . . . . . . . . . . . . . . . . . . 11 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 4.1 Providing Router Authorization . . . . . . . . . . . . . . 12 78 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 80 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 84 A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14 86 B. Router Advertisement Rates . . . . . . . . . . . . . . . . . . 16 88 Intellectual Property and Copyright Statements . . . . . . . . 19 90 1. Introduction 92 Hosts on the Internet may be connected by various media. It has 93 become common that hosts have access through wireless media and are 94 mobile. The frequency of configuration change for wireless and 95 nomadic devices are elevated, due to the vagaries of wireless 96 propagation or the motion of the hosts themselves. 98 Such hosts need to determine if they have moved to a new IPv6 link 99 rapidly, in order that configuration procedures may be run and 100 application packet delivery services restored. Detecting Network 101 Attachment (DNA) is a strategy to assist such configuration changes 102 by rapidly determining whether they are required. 104 Several network-side factors may impact on the effectiveness and 105 speed of DNA procedures. This document provides guidelines embodying 106 the best current practice for network deployers wishing to support 107 detection of network attachment by IPv6 hosts. 109 It should be noted that many already deployed routers will not 110 support these recommendations, and that hosts SHOULD NOT rely on 111 their being in place, unless they have particular reason to do so. 113 1.1 Terms and Abbreviations 115 Access network: A network where hosts are present. Especially, a 116 network used for the support of visiting wireless hosts. 118 Link: A link is the range across which communications can pass 119 without being forwarded through a router [1]. 121 Link-Change: Link-Change occurs when a host moves from a point-of- 122 attachment on a link, to another point-of-attachment where it is 123 unable to reach devices belonging to the previous link, without 124 being forwarded through a router. 126 Point-of-Attachment: A link-layer base-station, VLAN or port through 127 which a device attempts to reach the network. Changes to a 128 host's point-of-attachment may cause link-change. 130 Reachability Detection: Determination that a device (such as a 131 router) is currently reachable, over both a wireless medium, and 132 any attached fixed network. This is typically achieved using 133 Neighbor Unreachability Detection procedure [1]. 135 Wireless Medium: A physical layer which incorporates free space 136 electromagnetic or optical propagation. Such media are 137 susceptible to mobility and interference effects, potentially 138 resulting in high packet loss probabilities. 140 1.2 Relevant Host Issues 142 Hosts attempting to discover link change are likely to send Router 143 Solicitations (RSs) in order to identify the routers and prefixes 144 available on a link. Additionally, they may wish to send Neighbour 145 Solicitations (NSs) to known routers for reachability detection 146 purposes. 148 The following is a list of critical issues for hosts undertaking link 149 change detection in IPv6: 151 Hosts require Router Advertisements (RAs) rapidly in order to 152 minimize reconfiguration latencies in the case of link change or 153 link failure. 155 Host wishes to identify if their current prefix is still valid on 156 a link before the prefix expires. Existing IPv6 Neighbour 157 Discovery procedures make this difficult. If the host can 158 determine that the target router is still reachable through a 159 NS/NA exchange, it does not mean that the prefix is still valid. 160 Conversely, if host sends an RS, the RA received in response may 161 not contain the prefix of interest for the hosts. 163 Hosts wish to detect if a particular router is reachable in order 164 to use it for routing. 166 Hosts may require some assurance that a device is actually 167 present, and is authorized to act as a router. 169 Consideration for these issues underlie the practices recommended in 170 this document. 172 1.3 Relevant Router Issues 174 The IPv6 Neighbour Discovery RFC [1] provides mechanisms where 175 hosts can send Router Solicitations and receive Router 176 Advertisements, from each of the routers on a link. 178 Responses may either be unicast or multicast, but in all cases, a 179 random delay of between 0 and 500 milliseconds is required before 180 responses are sent. This is to prevent multiple routers 181 responding at the same time, and also may mitigate the effects of 182 simultaneous solicitations. This results in a basic time delay 183 incurred by hosts receiving response RAs, which cannot be avoided 184 within current standards [1]. 186 As described in Section 2.1, additional delays may occur if 187 multicast responses are required. 189 Routers should also be careful not to increase the network 190 overhead by frequently transmitting router advertisements (see 191 Section 2.4). 193 Routers should include all advertised prefixes within the same RA 194 and indicate whether a previous advertised prefix is not valid 195 anymore. Multiple prefixes advertised in different RAs by a 196 single router may lead to host configurations errors. 198 1.4 Summary 200 The practices embodied in this document are considered to provide 201 minimal support for hosts wishing to detect network attachment. 202 Current work within the DNA working group aims to provide 203 substantially improved performance for link change detection. 205 Existing limitations in base protocols such as IPv6 Neighbour 206 Discovery preclude support of real-time applications in some 207 environments. Future deployers and implementers are encouraged to 208 consider the protocols under development at this time in order to 209 provide a generic service to support hosts detecting change. 211 2. Configuration Practices for DNAv6 Routers 213 Routers which are being deployed to support hosts' change detection 214 procedures should attempt to use appropriate configurations, which 215 limit advertisement latency, and provide appropriate service 216 considering the constraints of the deployed access network 217 technology. 219 This section describes several configuration parameters which may 220 exist on IPv6 routers, and how their tuning may affect DNA hosts. 222 2.1 Multicast and Unicast RA Responses 224 While IPv6 Neighbour Discovery assumes that responses to 225 solicitations will be sent multicast, the specification allows any 226 router to respond to RS message with a unicast RA if it desires [1]. 228 The advantage in responding with an unicast RA message is to allow 229 the IP host to conclusively infer bi-directional reachability from 230 the RS-RA exchange. Neighbour Discovery does not provide any 231 mechanism to match multicast RA responses with their solicitation, 232 and therefore it is not possible for the hosts to find out whether at 233 least one of its RS messages was received and processed by the 234 router. Since unicast RAs are only sent in response to solicitation, 235 a host can infer that at least one of its Router Solicitations 236 reached the router. 238 The dis-advantage in sending unicast RA is that the router will not 239 be able to aggregate its response for multiple RS messages from 240 multiple hosts received during the waiting period before RA 241 transmission. 243 For multicast Router Advertisements, a minimum separating delay 244 exists so that these RAs may not be scheduled close to each other. 245 When a host solicits and attempts to schedule a multicast RA within 246 MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of 247 the previous multicast Router Advertisement, the scheduling of a 248 response will be deferred until the minimum separation expires. 250 This separation delay does not affect unicast Router Advertisement 251 responses. Routers MAY choose to respond to RS messages with a 252 unicast RA response to avoid the delay introduced by the 253 MIN_DELAY_BETWEEN_RAS restriction [1]. 255 Where many unicast responses are scheduled awaiting transmission, 256 Routers MAY consider aggregating them into a single multicast 257 response if a multicast advertisement may be sent before the 258 advertisements' scheduled transmission time. 260 It is noted that computational requirements for SEND may preclude 261 this subsequent aggregation in some environments. 263 Where multiple unicast transmissions for the same destination await 264 transmission, routers MAY remove all transmissions after the first 265 without ill-effect, if a multicast RA is scheduled for the next 266 possible response time. 268 In some cases it is not possible to provide unicast responses, since 269 solicitations may be sent with an unspecified address, or 270 solicitations do not provide enough link-layer addressing information 271 to send an unicast response without neighbour discovery exchange. In 272 these cases, a router may need to send multicast responses, even if 273 the expected delay is greater. 275 2.1.1 Recommendations 277 Routers SHOULD respond to a RS message with unicast RS message. 279 Routers SHOULD aggregate RA messages into a multi-cast RA message 280 if more than 3 unicast RA messages are queued for transmission. 282 Where multiple unicast transmissions for the same destination 283 await transmission, routers MAY remove all transmissions after the 284 first without ill-effect. 286 2.2 Router Advertisement Parameters 288 Where hosts have changeable connectivity, there may be a number of 289 prefixes or routers stored in the host's memory, which are no longer 290 directly reachable. This additional storage may make movement 291 detection slower where hosts rapidly pass through networks, or pass 292 through networks which have very long advertised timeouts. 294 Routers SHOULD be configured to advertise non-default Valid and 295 Preferred lifetimes in order to provide DNA hosts with link-specific 296 address lifetime information. 298 Administrators are advised to set the advertised Preferred and Valid 299 timers of prefixes to the maximum duration for which any host may be 300 required to continue functioning without receiving a particular 301 advertised prefix. 303 Where hosts with ongoing transactions, or well known services (such 304 as DNS) are present on a network, this duration SHOULD be greater 305 than the maximum expected outage time (for example 9 hours for 0.999 306 uptime, with a single outage/year). 308 Upon links where fixed hosts are unlikely to be present, 309 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 310 and Preferred Lifetimes on routers used to support DNA. 312 One potential configuration heuristic would be to configure lifetimes 313 to be a low number (for example: 15) of times the MaxRtrAdvInterval, 314 or greater than the lower quartile cell residence time of hosts on 315 the network (if known). This allows reuse of configuration in the 316 case where hosts are moving back and forth rapidly between links, but 317 allows rapid timeouts of old configurations. 319 The Router Lifetime MUST NOT be advertised as less than the 320 MaxRtrAdvInterval unless the router is not to be used as a default 321 [1]. 323 Routers MUST NOT be configured with Valid or Preferred lifetime 324 values lower than the MaxRtrAdvInterval. These minima ensure that 325 lifetimes do not expire in between periodic Router Advertisements. 327 2.2.1 Recommendations 329 Routers SHOULD be configured to advertise non-default Valid and 330 Preferred lifetimes in order to provide DNA hosts with link- 331 specific address lifetime information. 333 Upon links where fixed hosts are unlikely to be present, 334 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 335 and Preferred Lifetimes on routers used to support DNA. 337 The Router Lifetime MUST NOT be advertised as less than the 338 MaxRtrAdvInterval unless the router is not to be used as a default 339 [1]. 341 Routers MUST NOT be configured with Valid or Preferred lifetime 342 values lower than the MaxRtrAdvInterval. 344 2.3 Router Advertisement Options 346 When receiving a Router Advertisement from a particular router for 347 the first time, a host needs to determine if the information 348 contained in the RA indicates link change or that the transmitting 349 router is part of the same link as another router it has already 350 seen. It is not possible to do this unless global prefix information 351 is included in the advertisement. 353 Routers SHOULD include at least one global Prefix Information Option 354 in every Router Advertisement. 356 Mobile IPv6 introduced a new option for Router Advertisements, which 357 indicates the current MaxRtrAdvInterval of router [3]. Reception of 358 this option allows hosts to estimate whether they have missed Router 359 Advertisements, and allows them to check reachability or discover new 360 routers. 362 Routers SHOULD include Advertisement Interval options in Router 363 Advertisements. 365 Mobile IPv6 adds the Router Address 'R' Flag to Prefix Information 366 options [3]. This flag, when set indicates that the router's entire 367 global address is configured and sent in the prefix information 368 option. Bits beyond those specified in the prefix length field 369 identify the router's Interface Identifier [6]. 371 Hosts which are detecting network attachment can use a global router 372 address to uniquely identify the router and link, rather than using 373 link-local source addresses, which may be present on multiple links. 375 Routers SHOULD advertise at least one global address consistently in 376 a Prefix Information Option, by setting the Router Address 'R' Flag. 378 2.3.1 Recommendations 380 Routers SHOULD include at least one global Prefix Information 381 Option in every Router Advertisement. 383 Routers SHOULD include Advertisement Interval options in Router 384 Advertisements. 386 Routers SHOULD advertise at least one global address consistently 387 in a Prefix Information Option, by setting the Router Address 'R' 388 Flag. 390 2.4 Triggered Router Advertisements 392 There are proposals for IPv6 Router Advertisements to be sent to 393 hosts based on network side link-layer information. 395 Where these mechanisms exist they can provide Router Advertisements 396 in the quickest possible time without need for Router Solicitation. 397 These systems rely upon link-layer facilities are not available in 398 all environments. Therefore, interested readers are referred to the 399 individual methods' documentation [15]. 401 2.5 Split Advertisements 403 A router may choose to split the options in the RA and send multiple 404 RAs to reduce bandwidth overhead or to reduce the size of the RA to 405 below the link MTU (section 6.2.3 of [1]). 407 If such a choice is made, average multicast RA time discussed in 408 Appendix B increases for each subset of the prefixes included in the 409 split RA messages. 411 Routers SHOULD consistently include one prefix in both sets of its RA 412 messages. This provide the host with a unique identifier based on 413 the combination of link-local address and the constant prefix, to 414 identify the router every time a RA message is received. 416 2.6 Router Configurations 418 Each router can have its own configuration with respect to sending 419 RAs, and the treatment of router and neighbour solicitations. 420 Different timers and constants might be used by different routers, 421 such as the delay between Router Advertisements or delay before 422 replying to a multicast RS. If a host is changing its IPv6 link, a 423 newly seen router on that link may have a different configuration and 424 may introduce more delay than the previous default router of the 425 host. 427 While transitions between links under different administrative 428 control are considered to be common, it is RECOMMENDED that network 429 deployers adopt uniform configuration practices across routers on 430 different links within the same logical domain, in order to provide 431 consistent performance. 433 3. Topological Practices for DNAv6 Networks 435 IPv6 does not prefer one particular network topology over another and 436 allows multiple routers and subnet prefixes to exist on one link. 437 Different deployments of network elements and their configuration may 438 impact on link change detection though. Effects and recommended 439 practices for dealing with different network topologies are presented 440 below. 442 3.1 Link Extent and Composition 444 Most of today's access networks deploy link-layer bridging 445 technologies in order to extend their logical range beyond a single 446 Medium Access Control domain. 448 Consequently, while many routers will come with traditional wired or 449 optic-fibre interfaces, packets travelling within the same link may 450 have been bridged across from a wired segment to a wireless segment. 452 In many of cases, the router will not have accurate information about 453 the transmission rates or media of particular segments on the link. 454 Routers with interfaces whose technology is bridgeable SHOULD NOT 455 assume that all segments and devices on the link have the same 456 bandwidth available. 458 3.2 Multiple Router Links 460 IPv6 Neighbour Discovery allows multiple routers to be advertising on 461 the same link [1]. These routers are not required to advertise the 462 same prefixes as each other. This section provides some guidelines 463 for deploying multiple routers on the same link. 465 While many routers may exist on a link, it is preferable to limit the 466 number of advertising routers. There SHOULD NOT be more than three 467 (3) routers advertising on a link. This will provide robustness in 468 the case of RA packet loss, but provides a bound for bandwidth 469 consumption. 471 Multiple routers responding to Router Solicitation will reduce the 472 mean delay for solicitation, at the cost of additional traffic. For 473 unicast responses, the delays may be halved for three responding 474 routers. 476 +-----------------------+---------+----------+----------+ 477 |Num advertising routers| 1 | 2 | 3 | 478 +-----------------------+---------+----------+----------+ 479 |Expected Unicast Delay | 0.250s | 0.167s | 0.125s | 480 +-----------------------+---------+----------+----------+ 482 If using advertising intervals lower than those specified in IPv6 483 Neighbour Discovery, only one router MAY advertise at the elevated 484 rate. Other routers beyond the first SHOULD NOT have 485 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 486 the minima specified in IPv6 Neighbour Discovery [1][3]. 488 Where it is possible, routers SHOULD include at least one common 489 prefix in all of their Router Advertisement messages. This allows 490 hosts to immediately see that both routers are on the same link. 492 3.3 Point-to-point Links 494 IPv6 Router Discovery mandates the delay of RA responses by stating 495 (in section 6.2.6 of [1]): 497 "In all cases, Router Advertisements sent in response to a 498 Router Solicitation MUST be delayed by a random time 499 between 0 and MAX_RA_DELAY_TIME seconds." 501 Cases where the router is on a point-to-point link, this restriction 502 is too stringent as the router in question will be the only router on 503 the link. Routers on such point-to-point links MAY avoid the delay 504 by not waiting for the prescribed random time before responding for 505 the Router Solicitation message [8] [14]. 507 4. Security Considerations 509 When operating a network in support of hosts performing link change 510 detection, both the operational security of the hosts and network 511 infrastructure are important. DNA procedures rely upon rapid 512 delivery of information to hosts using IPv6 Neighbour Discovery. 514 Neighbour Discovery as a critical service in IPv6 networks is subject 515 to various attacks as described in [7]. 517 The following sections describe issues and practices to provide 518 additional functional security for both operators and hosts. 520 4.1 Providing Router Authorization 522 In DNA, some hosts will begin configuration procedures based on a 523 single message transmitted by a router. As such the ability of 524 routing infrastructure to prove its authenticity and authorization is 525 important to support correct operation of hosts. Authentication and 526 authorization mechanisms exist which allow hosts to check security of 527 routers when they receive Router Advertisements indicating link 528 change. 530 Today these mechanisms require additional message exchanges and 531 public key operations to check the authorization chain back to a 532 trusted root. Considering the computational cost for verifying 533 certificates, it will useful for administrators to attempt to 534 minimize the length of these authorization chains. 536 Where a Router Advertisement is sent by a router, it SHOULD contain 537 sufficient information to prove that the router is on the same link 538 as previously seen advertisers, or is indeed the same router. This 539 may prevent expensive checks by hosts which will not need to 540 immediately test the authenticity of the router through signature 541 verification, or additional transmissions. 543 As described in section Section 3.2, advertising common prefixes 544 achieves this goal. 546 Hosts which wish to have secured exchanges with neighbours and on- 547 link routers may use Secured Neighbour Discovery (SEND) [4]. SEND 548 provides authenticity as well as response matching, using nonces 549 copied from solicitations into advertisements. 551 Routers supporting DNA SHOULD provide secured router discovery 552 services using SEND [4]. 554 5. References 556 5.1 Normative References 558 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 559 for IP Version 6 (IPv6)", RFC 2461, December 1998. 561 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 562 Levels", BCP 14, RFC 2119, March 1997. 564 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 565 IPv6", RFC 3775, June 2004. 567 [4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 568 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 569 (work in progress), July 2004. 571 5.2 Informative References 573 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 574 Autoconfiguration", RFC 2462, December 1998. 576 [6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 577 Addressing Architecture", RFC 3513, April 2003. 579 [7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 580 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 582 [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 583 December 1998. 585 [9] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 586 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 587 Std 802.11, 1999. 589 [10] Yamamoto, S., "Detecting Network Attachment Terminology", 590 draft-yamamoto-dna-term-00 (work in progress), February 2004. 592 [11] Manner, J. and M. Kojo, "Mobility Related Terminology", 593 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 594 February 2004. 596 [12] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 597 draft-ietf-ipv6-optimistic-dad-02 (work in progress), 598 September 2004. 600 [13] Christensen, M., Kimball, K., and F. Solensky, "Considerations 601 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 602 (work in progress), February 2005. 604 [14] "3GPP TS 29.061 V5.5.0 (2003-03) Interworking between the 605 Public Land Mobile Network (PLMN) supporting packet based 606 services and Packet Data Networks (PDN) (Release 5)", 607 TS 29.061, March 2003. 609 [15] Choi, J., "Fast Router Discovery with RA Caching", 610 draft-jinchoi-dna-frd-00 (work in progress), July 2004. 612 Authors' Addresses 614 Sathya Narayanan 615 Panasonic Digital Networking Lab 616 Two Research Way, 3rd Floor 617 Princeton, NJ 08536 618 USA 620 Phone: 609 734 7599 621 Email: sathya@Research.Panasonic.COM 622 URI: 624 Greg Daley 625 Centre for Telecommunications and Information Engineering 626 Department of Electrical adn Computer Systems Engineering 627 Monash University 628 Clayton, Victoria 3800 629 Australia 631 Phone: +61 3 9905 4655 632 Email: greg.daley@eng.monash.edu.au 634 Nicolas Montavont 635 LSIIT - Univerity Louis Pasteur 636 Pole API, bureau C444 637 Boulevard Sebastien Brant 638 Illkirch 67400 639 FRANCE 641 Phone: (33) 3 90 24 45 87 642 Email: montavont@dpt-info.u-strasbg.fr 643 URI: http://www-r2.u-strasbg.fr/~montavont/ 645 Appendix A. Summary of Recommendations 647 It should be noted that many already deployed routers will not 648 support these recommendations, and that hosts SHOULD NOT rely on 649 their being in place, unless they have particular reason to do so. 651 Where many unicast responses are scheduled awaiting transmission, 652 Routers MAY consider aggregating them into a single multicast 653 response if a multicast advertisement may be sent before the 654 advertisements' scheduled transmission time. 656 Where multiple unicast transmissions for the same destination await 657 transmission, routers MAY remove all transmissions after the first 658 without ill-effect, if a multicast RA is scheduled for the next 659 possible response time. 661 Routers MAY choose to respond to RS messages with a unicast RA 662 response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS 663 restriction [1]. 665 Routers SHOULD be configured to advertise non-default Valid and 666 Preferred lifetimes in order to provide DNA hosts with link-specific 667 address lifetime information. 669 Where hosts with ongoing transactions, or well known services are 670 present on a network, this duration SHOULD be greater than the 671 maximum expected outage time. 673 Upon links where fixed hosts are unlikely to be present, 674 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 675 and Preferred Lifetimes on routers used to support DNA. 677 The Router Lifetime MUST NOT be advertised as less than the 678 MaxRtrAdvInterval unless the router is not to be used as a default 679 [1]. 681 Routers MUST NOT be configured with Valid or Preferred lifetime 682 values lower than the MaxRtrAdvInterval. 684 Routers SHOULD include at least one global Prefix Information Option 685 in every Router Advertisement. 687 Routers SHOULD include Advertisement Interval options in Router 688 Advertisements. 690 Routers SHOULD advertise at least one global address consistently in 691 a Prefix Information Option, by setting the Router Address 'R' Flag. 693 A router MAY choose to split the options in the RA and send multiple 694 RAs to reduce bandwidth overhead or to reduce the size of the RA to 695 below the link MTU (see section 6.2.3 of [1]). 697 While transitions between links under different administrative 698 control are considered to be common, it is RECOMMENDED that network 699 deployers adopt uniform configuration practices across routers on 700 different links within the same logical domain, in order to provide 701 consistent performance. 703 Routers with interfaces whose technology is bridgeable SHOULD NOT 704 assume that all segments and devices on the link have the same 705 bandwidth available. 707 There SHOULD NOT be more than three (3) routers advertising on a 708 link. 710 If using advertising intervals lower than those specified in IPv6 711 Neighbour Discovery, only one router MAY advertise at the elevated 712 rate. Other routers beyond the first SHOULD NOT have 713 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 714 the minima specified in IPv6 Neighbour Discovery [1][3]. 716 Where it is possible, routers SHOULD include at least one common 717 prefix in all of their Router Advertisement messages. 719 Routers on point-to-point links MAY avoid delay by not waiting for 720 the prescribed random time before responding for the Router 721 Solicitation message [8] [14]. 723 Considering the computational cost for verifying certificates, 724 administrators SHOULD attempt to minimize the length of authorization 725 chains. 727 Where a Router Advertisement is sent by a router, it SHOULD contain 728 sufficient information to prove that the router is on the same link 729 as previously seen advertisers, or is indeed the same router. 731 Routers supporting DNA SHOULD provide secured router discovery 732 services using SEND [4]. 734 On access networks supporting Detecting Network Attachment, 735 administrators SHOULD configure routers to advertise at the shortest 736 safe intervals. 738 Appendix B. Router Advertisement Rates 740 Unsolicited Router Advertisements are scheduled to be transmitted at 741 a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last 742 multicast Router Advertisement. These parameters may be configured 743 in the way which best suits the network. The table below summarizes 744 the parameters as described by IPv6 Neighbour Discovery [1]. 746 +-----------------------+----+----+----+-----+----+-----+ 747 | Timer |Maximum |Default |Minimum | 748 +-----------------------+----+----+----+-----+----+-----+ 749 | MaxRtrAdvInterval | 1800 | 600 | 4 | 750 +-----------------------+----+----+----+-----+----+-----+ 751 | MinRtrAdvInterval | 594 | 198 | 3 | 752 +-----------------------+----+----+----+-----+----+-----+ 753 |Avg. Multicast RA time | 1197 | 399 | 3.5 | 754 +-----------------------+----+----+----+-----+----+-----+ 756 The load on the network, and the timeliness of any received 757 information updates are therefore influenced by the router's 758 advertisement parameters. 760 On access networks supporting Detecting Network Attachment, 761 administrators SHOULD configure routers to advertise at the shortest 762 safe intervals. Determination of the shortest safe intervals depends 763 on topology, and the composition of the link, as described in 764 Section 3.1. 766 Mobile IPv6 attempts to address the delays associated with hosts' 767 movement and change detection by reducing the minimum settings for 768 MinRtrAdvInterval to 30ms and MaxRtrAdvInterval to 70ms. Not all 769 IPv6 routers support these configuration values today. Where hosts 770 have no reactive way of detecting change, and do not solicit for 771 Router Advertisements, these intervals may allow change detection 772 sufficiently fast to support real-time applications. 774 The effect of these timers are summarized in the table below. 776 +-----------------------+----+----+----+-----+----+-----+ 777 | Timer |Maximum |Default |Minimum | 778 +-----------------------+----+----+----+-----+----+-----+ 779 | MaxRtrAdvInterval | 1800 | 600 | 0.07 | 780 +-----------------------+----+----+----+-----+----+-----+ 781 | MinRtrAdvInterval | 594 | 198 | 0.03 | 782 +-----------------------+----+----+----+-----+----+-----+ 783 |Avg. Multicast RA time | 1197 | 399 | 0.05 | 784 +-----------------------+----+----+----+-----+----+-----+ 786 Where Mobile IPv6 is supported, the minimum values change, but the 787 default timers are unmodified. If administrators wish to take 788 advantage of shorter intervals between unsolicited RAs, explicit 789 configuration is required. This is because the elevated rate of 790 multicast RA transmission can have detrimental effects on some 791 constrained links [3]. 793 The minimum average for un-solicited Router Advertisements would be 794 20 messages per second. Assuming the minimum packet size for an RA 795 with one prefix as 88 bytes, the bandwidth used will be 14 kbps. 796 With SEND Options, and (somewhat weak) 1024-bit RSA keys, a single RA 797 could be around 432 octets. This would consume approximately 69 kbps 798 without considering link-layer overheads [4]. 800 As described in Section 2.1, parameters may be chosen to optimize 801 solicited behaviour in a way which limits the mean bandwidth overhead 802 for unsolicited RAs. 804 A good example would be setting a MinRtrAdvInterval (along with 805 MinDelayBetweenRAs) as 0.5 s, and the MaxRtrAdvInterval to 4s. This 806 makes the mean delay before receiving an unsolicited RA 2.25 seconds, 807 and limits the bandwidth utilization for unsolicited RAs (using the 808 SEND example above) to 1.5 kbps, and the maximum multicast solicited 809 rate to 6.9 kbps (one multicast RA each 0.5s). 811 Intellectual Property Statement 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the procedures with respect to rights in RFC documents can be 820 found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at 833 ietf-ipr@ietf.org. 835 Disclaimer of Validity 837 This document and the information contained herein are provided on an 838 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 839 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 840 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 841 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 842 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 843 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 845 Copyright Statement 847 Copyright (C) The Internet Society (2005). This document is subject 848 to the rights, licenses and restrictions contained in BCP 78, and 849 except as set forth therein, the authors retain all their rights. 851 Acknowledgment 853 Funding for the RFC Editor function is currently provided by the 854 Internet Society.