idnits 2.17.1 draft-ietf-dna-routers-02.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 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 835. ** 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 (March 6, 2006) is 6598 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 563, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 575, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 587, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 591, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 598, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 602, 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: September 7, 2006 G. Daley 5 Monash University CTIE 6 N. Montavont 7 GET - ENST Bretagne 8 March 6, 2006 10 Detecting Network Attachment in IPv6 - Best Current Practices for 11 Routers 12 draft-ietf-dna-routers-02.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 September 7, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 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 Applicability statement . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 11 73 3.3 Point-to-point Links . . . . . . . . . . . . . . . . . . . 11 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 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 the effectiveness and speed 105 of DNA procedures. This document provides guidelines embodying the 106 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 Hosts need to identify if their current prefix is still valid on a 156 link before the prefix expires. Existing IPv6 Neighbour Discovery 157 procedures make this difficult. If the host can determine that 158 the target router is still reachable through a NS/NA exchange, it 159 does not mean that the prefix is still valid on that link. This 160 is because link-local addresses are used for the NS/NA exchange. 161 Conversely, if host sends an RS, the RA received in response may 162 not contain the prefix of interest for the hosts. 164 Hosts wish to detect if a particular router is reachable in order 165 to use it for routing. 167 Hosts may require some assurance that a device is actually 168 present, and is authorized to act as a router. 170 Consideration for these issues underlie the practices recommended in 171 this document. 173 1.3 Relevant Router Issues 175 The IPv6 Neighbour Discovery RFC [1] provides mechanisms where 176 hosts can send Router Solicitations and receive Router 177 Advertisements, from each of the routers on a link. 179 Responses may either be unicast or multicast, but in all cases, a 180 random delay of between 0 and 500 milliseconds is required before 181 responses are sent. This is to prevent multiple routers 182 responding at the same time, and also may mitigate the effects of 183 simultaneous solicitations. This results in a basic time delay 184 incurred by hosts receiving response RAs, which cannot be avoided 185 within current standards [1]. 187 As described in Section 2.1, additional delays may occur if 188 multicast responses are required. 190 Routers should also be careful not to increase the network 191 overhead by frequently transmitting router advertisements (see 192 Section 2.4). 194 Multiple prefixes advertised in different RAs by a single router 195 may lead to host configurations errors. It may generate erroneous 196 movement detection and/or delay hosts to detect that a prefix is 197 not valid anymore. 199 1.4 Applicability statement 201 The practices embodied in this document are considered to provide 202 minimal support for hosts wishing to detect network attachment. 203 Current work within the DNA working group aims to provide 204 substantially improved performance for link change detection. 206 Existing limitations in base protocols such as IPv6 Neighbour 207 Discovery preclude support of real-time applications in some 208 environments. Future deployers and implementers are encouraged to 209 consider the protocols under development at this time in order to 210 provide a generic service to support hosts detecting change. 212 2. Configuration Practices for DNAv6 Routers 214 Routers which are being deployed to aid hosts' change detection 215 procedures should attempt to use appropriate configurations, which 216 limit advertisement latency, and provide appropriate service 217 considering the constraints of the deployed access network 218 technology. 220 This section describes several configuration parameters which may 221 exist on IPv6 routers, and how their tuning may affect DNA hosts. 223 2.1 Multicast and Unicast RA Responses 225 While IPv6 Neighbour Discovery assumes that responses to 226 solicitations will be sent multicast, the specification allows any 227 router to respond to RS message with a unicast RA [1]. Note that the 228 delay between 0 and MAX_RA_DELAY_TIME is still applicable when a 229 router responds to a RS with a unicast RA. 231 The advantage in responding with an unicast RA message is to allow 232 the IP host to conclusively infer bi-directional reachability from 233 the RS-RA exchange. Neighbour Discovery does not provide any 234 mechanism to match multicast RA responses with their solicitation, 235 and therefore it is not possible for the hosts to find out whether at 236 least one of its RS messages was received and processed by the 237 router. Since unicast RAs are only sent in response to solicitation, 238 a host can infer that at least one of its Router Solicitations 239 reached the router. 241 The dis-advantage in sending unicast RA is that the router will not 242 be able to aggregate its response for multiple RS messages from 243 multiple hosts received during the waiting period before RA 244 transmission. Moreover, using unicast RA to respond to RS disables 245 routers' ability to limit the rate of unicast RA. 247 For multicast Router Advertisements, a minimum separating delay 248 exists so that these RAs may not be scheduled close to each other. 249 When a host solicits and attempts to schedule a multicast RA within 250 MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of 251 the previous multicast Router Advertisement, the scheduling of a 252 response will be deferred until the minimum separation expires. 254 This separation delay does not affect unicast Router Advertisement 255 responses. Routers MAY choose to respond to RS messages with a 256 unicast RA response to avoid the delay introduced by the 257 MIN_DELAY_BETWEEN_RAS restriction [1]. 259 Where many unicast responses are scheduled awaiting transmission, 260 Routers MAY consider aggregating them into a single multicast 261 response if a multicast advertisement may be sent before the 262 advertisements' scheduled transmission time. 264 It is noted that computational requirements for SEND may preclude 265 this subsequent aggregation in some environments. 267 Where multiple unicast transmissions for the same destination await 268 transmission, routers MAY remove all transmissions after the first 269 without ill-effect, if a multicast RA is scheduled for the next 270 possible response time. 272 In some cases it is not possible to provide unicast responses, since 273 solicitations may be sent with an unspecified address, or 274 solicitations do not provide enough link-layer addressing information 275 to send an unicast response without neighbour discovery exchange. In 276 these cases, a router may need to send multicast responses, even if 277 the expected delay is greater. 279 2.1.1 Recommendations 281 Routers SHOULD respond to a RS message with unicast RA message. 283 Routers SHOULD aggregate RA messages into a multi-cast RA message 284 if more than 3 unicast RA messages are queued for transmission. 286 Where multiple unicast transmissions for the same destination 287 await transmission, routers MAY remove all transmissions after the 288 first without ill-effect. 290 2.2 Router Advertisement Parameters 292 Where hosts often change their link attachment (e.g., because they 293 are mobile), there may be a number of prefixes or routers stored in 294 the host's memory, which are no longer directly reachable. This 295 additional storage may make movement detection slower where hosts 296 rapidly pass through networks, or pass through networks which have 297 very long advertised timeouts. 299 Routers SHOULD be configured to advertise non-default Valid and 300 Preferred lifetimes in order to provide DNA hosts with link-specific 301 address lifetime information. 303 Administrators are advised to set the advertised Preferred and Valid 304 timers of prefixes to the maximum duration for which any host may be 305 required to continue functioning without receiving a particular 306 advertised prefix. 308 Where hosts with long-lifetime communications, or well known services 309 (such as DNS) are present on a network, the preferred lifetime SHOULD 310 be greater than the maximum expected outage time (For example, if the 311 maximum router outage is 8.72 hours (for 0.999 uptime), the preferred 312 lifetime could be set to 9 hours, which would be sufficient to 313 support existing and allow new communications across the failure). 315 Upon links where fixed hosts are unlikely to be present, 316 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 317 and Preferred Lifetimes on routers used to support DNA. 319 One potential configuration heuristic would be to configure lifetimes 320 to be a low number (for example: 15) of times the MaxRtrAdvInterval, 321 or greater than the lower quartile cell residence time of hosts on 322 the network (if known). This allows reuse of configuration in the 323 case where hosts are moving back and forth rapidly between links, but 324 allows rapid timeouts of old configurations. 326 The Router Lifetime MUST NOT be advertised as less than the 327 MaxRtrAdvInterval unless the router is not to be used as a default 328 [1]. 330 Routers MUST NOT be configured with Valid or Preferred lifetime 331 values lower than the MaxRtrAdvInterval. These minima ensure that 332 lifetimes do not expire in between periodic Router Advertisements. 334 2.2.1 Recommendations 336 Routers SHOULD be configured to advertise non-default Valid and 337 Preferred lifetimes in order to provide DNA hosts with link- 338 specific address lifetime information. 340 Upon links where fixed hosts are unlikely to be present, 341 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 342 and Preferred Lifetimes on routers used to support DNA. 344 The Router Lifetime MUST NOT be advertised as less than the 345 MaxRtrAdvInterval unless the router is not to be used as a default 346 [1]. 348 Routers MUST NOT be configured with Valid or Preferred lifetime 349 values lower than the MaxRtrAdvInterval. 351 2.3 Router Advertisement Options 353 When receiving a Router Advertisement from a particular router for 354 the first time, a host needs to determine if the information 355 contained in the RA indicates link change or that the transmitting 356 router is part of the same link as another router it has already 357 seen. It is not possible to do this unless global prefix information 358 is included in the advertisement. 360 Routers SHOULD include at least one global Prefix Information Option 361 in every Router Advertisement. 363 Mobile IPv6 introduced a new option for Router Advertisements, which 364 indicates the current MaxRtrAdvInterval of router [3]. Reception of 365 this option allows hosts to estimate whether they have missed Router 366 Advertisements, and allows them to check reachability or discover new 367 routers. 369 Routers SHOULD include Advertisement Interval options in Router 370 Advertisements. 372 Mobile IPv6 adds the Router Address 'R' Flag to Prefix Information 373 options [3]. This flag, when set indicates that the router's entire 374 global address is configured and sent in the prefix information 375 option. Bits beyond those specified in the prefix length field 376 identify the router's Interface Identifier [6]. 378 Hosts which are detecting network attachment can use a global router 379 address to uniquely identify the router and link, rather than using 380 link-local source addresses, which may be present on multiple links. 382 Routers SHOULD advertise at least one global address consistently in 383 a Prefix Information Option, by setting the Router Address 'R' Flag. 385 2.3.1 Recommendations 387 Routers SHOULD include at least one global Prefix Information 388 Option in every Router Advertisement. 390 Routers SHOULD include Advertisement Interval options in Router 391 Advertisements. 393 Routers SHOULD advertise at least one global address consistently 394 in a Prefix Information Option, by setting the Router Address 'R' 395 Flag. 397 2.4 Triggered Router Advertisements 399 There are proposals for IPv6 Router Advertisements to be sent to 400 hosts based on network side link-layer information. 402 Where these mechanisms exist they can provide Router Advertisements 403 in the quickest possible time without need for Router Solicitation. 404 These systems rely upon link-layer facilities are not available in 405 all environments. Therefore, interested readers are referred to the 406 individual methods' documentation [15]. 408 2.5 Split Advertisements 410 A router may choose to split the options in the RA and send multiple 411 RAs to reduce bandwidth overhead or to reduce the size of the RA to 412 below the link MTU (section 6.2.3 of [1]). 414 If such a choice is made, average multicast RA time discussed in 415 Appendix B increases for each subset of the prefixes included in the 416 split RA messages. 418 Routers SHOULD consistently include one prefix in both sets of its RA 419 messages. This provide the host with a unique identifier based on 420 the combination of link-local address and the constant prefix, to 421 identify the router every time a RA message is received. 423 2.6 Router Configurations 425 Each router can have its own configuration with respect to sending 426 RAs, and the treatment of router and neighbour solicitations. 427 Different timers and constants might be used by different routers, 428 such as the delay between Router Advertisements or delay before 429 replying to a multicast RS. If a host is changing its IPv6 link, a 430 newly seen router on that link may have a different configuration and 431 may introduce more delay than the previous default router of the 432 host. 434 While transitions between links under different administrative 435 control are considered to be common, it is RECOMMENDED that network 436 deployers adopt uniform configuration practices across routers on 437 different links within the same logical domain, in order to provide 438 consistent performance. 440 3. Topological Practices for DNAv6 Networks 442 IPv6 does not prefer one particular network topology over another and 443 allows multiple routers and subnet prefixes to exist on one link. 444 Different deployments of network elements and their configuration may 445 impact on link change detection though. Effects and recommended 446 practices for dealing with different network topologies are presented 447 below. 449 3.1 Link Extent and Composition 451 Most of today's access networks deploy link-layer bridging 452 technologies in order to extend their logical range beyond a single 453 Medium Access Control domain. 455 Consequently, while many routers will come with traditional wired or 456 optic-fibre interfaces, packets travelling within the same link may 457 have been bridged across from a wired segment to a wireless segment. 459 In many of cases, the router will not have accurate information about 460 the transmission rates or media of particular segments on the link. 461 When defining the frequency at which RA will be sent over a link, 462 Routers with interfaces whose technology is bridgeable SHOULD NOT 463 assume that all segments and devices on the link have the same 464 bandwidth available. 466 3.2 Multiple Router Links 468 IPv6 Neighbour Discovery allows multiple routers to be advertising on 469 the same link [1]. These routers are not required to advertise the 470 same prefixes as each other. This section provides some guidelines 471 for deploying multiple routers on the same link. 473 While many routers may exist on a link, it is preferable to limit the 474 number of advertising routers. There SHOULD NOT be more than three 475 (3) routers advertising on a link. This will provide robustness in 476 the case of RA packet loss, but provides a bound for bandwidth 477 consumption. 479 Multiple routers responding to Router Solicitation will reduce the 480 mean delay for solicitation, at the cost of additional traffic. For 481 unicast responses, the delays may be halved for three responding 482 routers. 484 +-----------------------+---------+----------+----------+ 485 |Num advertising routers| 1 | 2 | 3 | 486 +-----------------------+---------+----------+----------+ 487 |Expected Unicast Delay | 0.250s | 0.167s | 0.125s | 488 +-----------------------+---------+----------+----------+ 490 If using advertising intervals lower than those specified in IPv6 491 Neighbour Discovery, only one router MAY advertise at the elevated 492 rate. Other routers beyond the first SHOULD NOT have 493 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 494 the minima specified in IPv6 Neighbour Discovery [1][3]. 496 Where it is possible, routers SHOULD include at least one common 497 prefix in all of their Router Advertisement messages. This allows 498 hosts to immediately see that both routers are on the same link. 500 3.3 Point-to-point Links 502 IPv6 Router Discovery mandates the delay of RA responses by stating 503 (in section 6.2.6 of [1]): 505 "In all cases, Router Advertisements sent in response to a 506 Router Solicitation MUST be delayed by a random time 507 between 0 and MAX_RA_DELAY_TIME seconds." 509 Cases where the router is on a point-to-point link, this restriction 510 is too stringent as the router in question will be the only router on 511 the link. Routers on such point-to-point links MAY avoid the delay 512 by not waiting for the prescribed random time before responding for 513 the Router Solicitation message [8] [14]. 515 4. Security Considerations 517 When operating a network in support of hosts performing link change 518 detection, both the operational security of the hosts and network 519 infrastructure are important. DNA procedures rely upon rapid 520 delivery of information to hosts using IPv6 Neighbour Discovery. 521 Neighbour Discovery as a critical service in IPv6 networks is subject 522 to various attacks as described in [7]. 524 The following sections describe issues and practices to provide 525 additional functional security for operators. 527 4.1 Providing Router Authorization 529 In DNA, some hosts will begin configuration procedures based on a 530 single message transmitted by a router. As such the ability of 531 routing infrastructure to prove its authenticity and authorization is 532 important to support correct operation of hosts. Authentication and 533 authorization mechanisms exist which allow hosts to check security of 534 routers when they receive Router Advertisements indicating link 535 change. 537 Today these mechanisms require additional message exchanges and 538 public key operations to check the authorization chain back to a 539 trusted root. Considering the computational cost for verifying 540 certificates, it will be useful for administrators to attempt to 541 minimize the length of these authorization chains. 543 Where a Router Advertisement is sent by a router, it SHOULD contain 544 sufficient information to prove that the router is on the same link 545 as previously seen advertisers, or is indeed the same router. This 546 may prevent expensive checks by hosts which will not need to 547 immediately test the authenticity of the router through signature 548 verification, or additional transmissions. As described in section 549 Section 3.2, advertising common prefixes achieves this goal. 551 Hosts which wish to have secured exchanges with neighbours and on- 552 link routers may use Secured Neighbour Discovery (SEND) [4]. SEND 553 provides authenticity as well as response matching, using nonces 554 copied from solicitations into advertisements. 556 5. References 558 5.1 Normative References 560 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 561 for IP Version 6 (IPv6)", RFC 2461, December 1998. 563 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 564 Levels", BCP 14, RFC 2119, March 1997. 566 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 567 IPv6", RFC 3775, June 2004. 569 [4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 570 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 571 (work in progress), July 2004. 573 5.2 Informative References 575 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 576 Autoconfiguration", RFC 2462, December 1998. 578 [6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 579 Addressing Architecture", RFC 3513, April 2003. 581 [7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 582 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 584 [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 585 December 1998. 587 [9] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 588 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 589 Std 802.11, 1999. 591 [10] Yamamoto, S., "Detecting Network Attachment Terminology", 592 draft-yamamoto-dna-term-00 (work in progress), February 2004. 594 [11] Manner, J. and M. Kojo, "Mobility Related Terminology", 595 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 596 February 2004. 598 [12] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 599 draft-ietf-ipv6-optimistic-dad-02 (work in progress), 600 September 2004. 602 [13] Christensen, M., Kimball, K., and F. Solensky, "Considerations 603 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 604 (work in progress), February 2005. 606 [14] "3GPP TS 29.061 V5.5.0 (2003-03) Interworking between the 607 Public Land Mobile Network (PLMN) supporting packet based 608 services and Packet Data Networks (PDN) (Release 5)", 609 TS 29.061, March 2003. 611 [15] Choi, J., "Fast Router Discovery with RA Caching", 612 draft-jinchoi-dna-frd-00 (work in progress), July 2004. 614 Authors' Addresses 616 Sathya Narayanan 617 Panasonic Digital Networking Lab 618 Two Research Way, 3rd Floor 619 Princeton, NJ 08536 620 USA 622 Phone: 609 734 7599 623 Email: sathya@Research.Panasonic.COM 624 URI: 626 Greg Daley 627 Centre for Telecommunications and Information Engineering 628 Department of Electrical adn Computer Systems Engineering 629 Monash University 630 Clayton, Victoria 3800 631 Australia 633 Phone: +61 3 9905 4655 634 Email: greg.daley@eng.monash.edu.au 636 Nicolas Montavont 637 GET - ENST Bretagne 638 Departement RSM 639 2, rue de la chataigneraie 640 Cesson-Sevigne 35576 641 FRANCE 643 Phone: (33) 2 99 12 70 23 644 Email: nicolas.montavont@enst-bretagne.fr 645 URI: http://www.rennes.enst-bretagne.fr/~montavont/ 647 Appendix A. Summary of Recommendations 649 It should be noted that many already deployed routers will not 650 support these recommendations, and that hosts SHOULD NOT rely on 651 their being in place, unless they have particular reason to do so. 653 Where many unicast responses are scheduled awaiting transmission, 654 Routers MAY consider aggregating them into a single multicast 655 response if a multicast advertisement may be sent before the 656 advertisements' scheduled transmission time. 658 Where multiple unicast transmissions for the same destination await 659 transmission, routers MAY remove all transmissions after the first 660 without ill-effect, if a multicast RA is scheduled for the next 661 possible response time. 663 Routers MAY choose to respond to RS messages with a unicast RA 664 response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS 665 restriction [1]. 667 Routers SHOULD be configured to advertise non-default Valid and 668 Preferred lifetimes in order to provide DNA hosts with link-specific 669 address lifetime information. 671 Where hosts with ongoing transactions, or well known services are 672 present on a network, this duration SHOULD be greater than the 673 maximum expected outage time. 675 Upon links where fixed hosts are unlikely to be present, 676 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 677 and Preferred Lifetimes on routers used to support DNA. 679 The Router Lifetime MUST NOT be advertised as less than the 680 MaxRtrAdvInterval unless the router is not to be used as a default 681 [1]. 683 Routers MUST NOT be configured with Valid or Preferred lifetime 684 values lower than the MaxRtrAdvInterval. 686 Routers SHOULD include at least one global Prefix Information Option 687 in every Router Advertisement. 689 Routers SHOULD include Advertisement Interval options in Router 690 Advertisements. 692 Routers SHOULD advertise at least one global address consistently in 693 a Prefix Information Option, by setting the Router Address 'R' Flag. 695 A router MAY choose to split the options in the RA and send multiple 696 RAs to reduce bandwidth overhead or to reduce the size of the RA to 697 below the link MTU (see section 6.2.3 of [1]). 699 While transitions between links under different administrative 700 control are considered to be common, it is RECOMMENDED that network 701 deployers adopt uniform configuration practices across routers on 702 different links within the same logical domain, in order to provide 703 consistent performance. 705 Routers with interfaces whose technology is bridgeable SHOULD NOT 706 assume that all segments and devices on the link have the same 707 bandwidth available. 709 There SHOULD NOT be more than three (3) routers advertising on a 710 link. 712 If using advertising intervals lower than those specified in IPv6 713 Neighbour Discovery, only one router MAY advertise at the elevated 714 rate. Other routers beyond the first SHOULD NOT have 715 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 716 the minima specified in IPv6 Neighbour Discovery [1][3]. 718 Where it is possible, routers SHOULD include at least one common 719 prefix in all of their Router Advertisement messages. 721 Routers on point-to-point links MAY avoid delay by not waiting for 722 the prescribed random time before responding for the Router 723 Solicitation message [8] [14]. 725 Considering the computational cost for verifying certificates, 726 administrators SHOULD attempt to minimize the length of authorization 727 chains. 729 Where a Router Advertisement is sent by a router, it SHOULD contain 730 sufficient information to prove that the router is on the same link 731 as previously seen advertisers, or is indeed the same router. 733 Routers supporting DNA SHOULD provide secured router discovery 734 services using SEND [4]. 736 On access networks supporting Detecting Network Attachment, 737 administrators SHOULD configure routers to advertise at the shortest 738 safe intervals. 740 Appendix B. Router Advertisement Rates 742 Unsolicited Router Advertisements are scheduled to be transmitted at 743 a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last 744 multicast Router Advertisement. These parameters may be configured 745 in the way which best suits the network. The table below summarizes 746 the parameters as described by IPv6 Neighbour Discovery [1]. 748 +-----------------------+----+----+----+-----+----+-----+ 749 | Timer |Maximum |Default |Minimum | 750 +-----------------------+----+----+----+-----+----+-----+ 751 | MaxRtrAdvInterval | 1800 | 600 | 4 | 752 +-----------------------+----+----+----+-----+----+-----+ 753 | MinRtrAdvInterval | 594 | 198 | 3 | 754 +-----------------------+----+----+----+-----+----+-----+ 755 |Avg. Multicast RA time | 1197 | 399 | 3.5 | 756 +-----------------------+----+----+----+-----+----+-----+ 758 The load on the network, and the timeliness of any received 759 information updates are therefore influenced by the router's 760 advertisement parameters. 762 On access networks supporting Detecting Network Attachment, 763 administrators SHOULD configure routers to advertise at the shortest 764 safe intervals. Determination of the shortest safe intervals depends 765 on topology, and the composition of the link, as described in 766 Section 3.1. 768 Mobile IPv6 attempts to address the delays associated with hosts' 769 movement and change detection by reducing the minimum settings for 770 MinRtrAdvInterval to 30ms and MaxRtrAdvInterval to 70ms. Not all 771 IPv6 routers support these configuration values today. Where hosts 772 have no reactive way of detecting change, and do not solicit for 773 Router Advertisements, these intervals may allow change detection 774 sufficiently fast to support real-time applications. 776 The effect of these timers are summarized in the table below. 778 +-----------------------+----+----+----+-----+----+-----+ 779 | Timer |Maximum |Default |Minimum | 780 +-----------------------+----+----+----+-----+----+-----+ 781 | MaxRtrAdvInterval | 1800 | 600 | 0.07 | 782 +-----------------------+----+----+----+-----+----+-----+ 783 | MinRtrAdvInterval | 594 | 198 | 0.03 | 784 +-----------------------+----+----+----+-----+----+-----+ 785 |Avg. Multicast RA time | 1197 | 399 | 0.05 | 786 +-----------------------+----+----+----+-----+----+-----+ 788 Where Mobile IPv6 is supported, the minimum values change, but the 789 default timers are unmodified. If administrators wish to take 790 advantage of shorter intervals between unsolicited RAs, explicit 791 configuration is required. This is because the elevated rate of 792 multicast RA transmission can have detrimental effects on some 793 constrained links [3]. 795 The minimum average for un-solicited Router Advertisements would be 796 20 messages per second. Assuming the minimum packet size for an RA 797 with one prefix as 88 bytes, the bandwidth used will be 14 kbps. 798 With SEND Options, and (somewhat weak) 1024-bit RSA keys, a single RA 799 could be around 432 octets. This would consume approximately 69 kbps 800 without considering link-layer overheads [4]. 802 As described in Section 2.1, parameters may be chosen to optimize 803 solicited behaviour in a way which limits the mean bandwidth overhead 804 for unsolicited RAs. 806 A good example would be setting a MinRtrAdvInterval (along with 807 MinDelayBetweenRAs) as 0.5 s, and the MaxRtrAdvInterval to 4s. This 808 makes the mean delay before receiving an unsolicited RA 2.25 seconds, 809 and limits the bandwidth utilization for unsolicited RAs (using the 810 SEND example above) to 1.5 kbps, and the maximum multicast solicited 811 rate to 6.9 kbps (one multicast RA each 0.5s). 813 Intellectual Property Statement 815 The IETF takes no position regarding the validity or scope of any 816 Intellectual Property Rights or other rights that might be claimed to 817 pertain to the implementation or use of the technology described in 818 this document or the extent to which any license under such rights 819 might or might not be available; nor does it represent that it has 820 made any independent effort to identify any such rights. Information 821 on the procedures with respect to rights in RFC documents can be 822 found in BCP 78 and BCP 79. 824 Copies of IPR disclosures made to the IETF Secretariat and any 825 assurances of licenses to be made available, or the result of an 826 attempt made to obtain a general license or permission for the use of 827 such proprietary rights by implementers or users of this 828 specification can be obtained from the IETF on-line IPR repository at 829 http://www.ietf.org/ipr. 831 The IETF invites any interested party to bring to its attention any 832 copyrights, patents or patent applications, or other proprietary 833 rights that may cover technology that may be required to implement 834 this standard. Please address the information to the IETF at 835 ietf-ipr@ietf.org. 837 Disclaimer of Validity 839 This document and the information contained herein are provided on an 840 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 841 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 842 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 843 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 844 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 845 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 847 Copyright Statement 849 Copyright (C) The Internet Society (2006). This document is subject 850 to the rights, licenses and restrictions contained in BCP 78, and 851 except as set forth therein, the authors retain all their rights. 853 Acknowledgment 855 Funding for the RFC Editor function is currently provided by the 856 Internet Society.