idnits 2.17.1 draft-ietf-dna-routers-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1020. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1004. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1010. ** 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 (June 23, 2005) is 6880 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 633, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 645, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 657, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 661, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 664, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 668, 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 (~~), 11 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: December 25, 2005 G. Daley 5 Monash University CTIE 6 N. Montavont 7 LSIIT - ULP 8 June 23, 2005 10 Detecting Network Attachment in IPv6 - Best Current Practices for 11 Routers 12 draft-ietf-dna-routers-00.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 December 25, 2005. 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 Wireless cell coverage . . . . . . . . . . . . . . . . . . 10 73 3.3 Multiple Router Links . . . . . . . . . . . . . . . . . . 11 74 3.4 Point-to-point Links . . . . . . . . . . . . . . . . . . . 12 75 3.5 Disjoint Administration . . . . . . . . . . . . . . . . . 12 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 4.1 Supporting host security . . . . . . . . . . . . . . . . . 12 79 4.2 Providing Router Authorization . . . . . . . . . . . . . . 13 81 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 5.1 Normative References . . . . . . . . . . . . . . . . . . . 14 83 5.2 Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 87 A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 16 89 B. Analysis of the response time . . . . . . . . . . . . . . . . 18 91 C. Router Advertisement Rates . . . . . . . . . . . . . . . . . . 20 93 Intellectual Property and Copyright Statements . . . . . . . . 22 95 1. Introduction 97 Hosts on the Internet may be connected by various media. It has 98 become common that hosts have access through wireless media and are 99 mobile. The frequency of configuration change for wireless and 100 nomadic devices are elevated, due to the vagaries of wireless 101 propagation or the motion of the hosts themselves. 103 Such hosts need to determine if they have moved to a new IPv6 link 104 rapidly, in order that configuration procedures may be run and 105 application packet delivery services restored. Detecting Network 106 Attachment (DNA) is a strategy to assist such configuration changes 107 by rapidly determining whether they are required. 109 Several network-side factors may impact on the effectiveness and 110 speed of DNA procedures. This document provides guidelines embodying 111 the best current practice for network deployers wishing to support 112 detection of network attachment by IPv6 hosts. 114 It should be noted that many already deployed routers will not 115 support these recommendations, and that hosts SHOULD NOT rely on 116 their being in place, unless they have particular reason to do so. 118 1.1 Terms and Abbreviations 120 Access network: A network where hosts are present. Especially, a 121 network used for the support of visiting wireless hosts. 123 Link: A link is the range across which communications can pass 124 without being forwarded through a router [1]. 126 Link-Change: Link-Change occurs when a host moves from a point-of- 127 attachment on a link, to another point-of-attachment where it is 128 unable to reach devices belonging to the previous link, without 129 being forwarded through a router. 131 Point-of-Attachment: A link-layer base-station, VLAN or port through 132 which a device attempts to reach the network. Changes to a 133 host's point-of-attachment may cause link-change. 135 Reachability Detection: Determination that a device (such as a 136 router) is currently reachable, over both a wireless medium, and 137 any attached fixed network. This is typically achieved using 138 Neighbor Unreachability Detection procedure [1]. 140 Wireless Medium: A physical layer which incorporates free space 141 electromagnetic or optical propagation. Such media are 142 susceptible to mobility and interference effects, potentially 143 resulting in high packet loss probabilities. 145 1.2 Relevant Host Issues 147 Hosts attempting to discover link change are likely to send Router 148 Solicitations (RSs) in order to identify the routers and prefixes 149 available on a link. Additionally, they may wish to send Neighbour 150 Solicitations (NSs) to known routers for reachability detection 151 purposes. 153 The following is a list of critical issues for hosts undertaking link 154 change detection in IPv6: 156 Hosts require Router Advertisements (RAs) rapidly in order to 157 minimize reconfiguration latencies in the case of link change or 158 link failure. 160 Host wishes to identify if their current prefix is still valid on 161 a link before the prefix expires. Existing IPv6 Neighbour 162 Discovery procedures make this difficult. If the host can 163 determine that the target router is still reachable through a 164 NS/NA exchange, it does not mean that the prefix is still valid. 165 Conversely, if host sends an RS, the RA received in response may 166 not contain the prefix of interest for the hosts. 168 Hosts wish to detect if a particular router is reachable in order 169 to use it for routing. 171 Hosts may require some assurance that a device is actually 172 present, and is authorized to act as a router. 174 Consideration for these issues underlie the practices recommended in 175 this document. 177 1.3 Relevant Router Issues 179 The IPv6 Neighbour Discovery RFC [1] provides mechanisms where 180 hosts can send Router Solicitations and receive Router 181 Advertisements, from each of the routers on a link. 183 Responses may either be unicast or multicast, but in all cases, a 184 random delay of between 0 and 500 milliseconds is required before 185 responses are sent. This is to prevent multiple routers 186 responding at the same time, and also may mitigate the effects of 187 simultaneous solicitations. This results in a basic time delay 188 incurred by hosts receiving response RAs, which cannot be avoided 189 within current standards [1]. 191 As described in Section 2.1, additional delays may occur if 192 multicast responses are required. 194 Routers should also be careful not to increase the network 195 overhead by frequently transmitting router advertisements (see 196 Section 2.4). 198 Routers should include all advertised prefixes within the same RA 199 and indicate whether a previous advertised prefix is not valid 200 anymore. Multiple prefixes advertised in different RAs by a 201 single router may lead to host configurations errors. 203 1.4 Summary 205 The practices embodied in this document are considered to provide 206 minimal support for hosts wishing to detect network attachment. 207 Current work within the DNA working group aims to provide 208 substantially improved performance for link change detection. 210 Existing limitations in base protocols such as IPv6 Neighbour 211 Discovery preclude support of real-time applications in some 212 environments. Future deployers and implementers are encouraged to 213 consider the protocols under development at this time in order to 214 provide a generic service to support hosts detecting change. 216 2. Configuration Practices for DNAv6 Routers 218 Routers which are being deployed to support hosts' change detection 219 procedures should attempt to use appropriate configurations, which 220 limit advertisement latency, and provide appropriate service 221 considering the constraints of the deployed access network 222 technology. 224 This section describes several configuration parameters which may 225 exist on IPv6 routers, and how their tuning may affect DNA hosts. 227 2.1 Multicast and Unicast RA Responses 229 While IPv6 Neighbour Discovery assumes that responses to 230 solicitations will be sent multicast, the specification allows any 231 router to respond to RS message with a unicast RA if it desires [1]. 233 The advantage in responding with an unicast RA message is to allow 234 the IP host to conclusively infer bi-directional reachability from 235 the RS-RA exchange. Neighbour Discovery does not provide any 236 mechanism to match multicast RA responses with their solicitation, 237 and therefore it is not possible for the hosts to find out whether at 238 least one of its RS messages was received and processed by the 239 router. Since unicast RAs are only sent in response to solicitation, 240 a host can infer that at least one of its Router Solicitations 241 reached the router. 243 The dis-advantage in sending unicast RA is that the router will not 244 be able to aggregate its response for multiple RS messages from 245 multiple hosts received during the waiting period before RA 246 transmission. 248 Where many unicast responses are scheduled awaiting transmission, 249 Routers MAY consider aggregating them into a single multicast 250 response if a multicast advertisement may be sent before the 251 advertisements' scheduled transmission time. 253 It is noted that computational requirements for SEND may preclude 254 this subsequent aggregation in some environments. 256 Where multiple unicast transmissions for the same destination await 257 transmission, routers MAY remove all transmissions after the first 258 without ill-effect, if a multicast RA is scheduled for the next 259 possible response time. 261 For multicast Router Advertisements, a minimum separating delay 262 exists so that these RAs may not be scheduled close to each other. 263 When a host solicits and attempts to schedule a multicast RA within 264 MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of 265 the previous multicast Router Advertisement, the scheduling of a 266 response will be deferred until the minimum separation expires. 268 This separation delay does not affect unicast Router Advertisement 269 responses. Routers MAY choose to respond to RS messages with a 270 unicast RA response to avoid the delay introduced by the 271 MIN_DELAY_BETWEEN_RAS restriction [1]. 273 In some cases it is not possible to provide unicast responses, since 274 solicitations may be sent with an unspecified address, or 275 solicitations do not provide enough link-layer addressing information 276 to send an unicast response without neighbour discovery exchange. In 277 these cases, a router may need to send multicast responses, even if 278 the expected delay is greater. 280 2.1.1 Recommendations 282 Routers SHOULD respond to a RS message with unicast RS message. 284 Routers SHOULD aggregate RA messages into a multi-cast RA message 285 if more than 3 unicast RA messages are queued for transmission. 287 Where multiple unicast transmissions for the same destination 288 await transmission, routers MAY remove all transmissions after the 289 first without ill-effect. 291 2.2 Router Advertisement Parameters 293 Where hosts have changeable connectivity, there may be a number of 294 prefixes or routers stored in the host's memory, which are no longer 295 directly reachable. This additional storage may make movement 296 detection slower where hosts rapidly pass through networks, or pass 297 through networks which have 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 ongoing transactions, or well known services (such 309 as DNS) are present on a network, this duration SHOULD be greater 310 than the maximum expected outage time (for example 9 hours for 0.999 311 uptime, with a single outage/year). 313 Upon links where fixed hosts are unlikely to be present, 314 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 315 and Preferred Lifetimes on routers used to support DNA. 317 One potential configuration heuristic would be to configure lifetimes 318 to be a low number (for example: 15) of times the MaxRtrAdvInterval, 319 or greater than the lower quartile cell residence time of hosts on 320 the network (if known). This allows reuse of configuration in the 321 case where hosts are moving back and forth rapidly between links, but 322 allows rapid timeouts of old configurations. 324 The Router Lifetime MUST NOT be advertised as less than the 325 MaxRtrAdvInterval unless the router is not to be used as a default 326 [1]. 328 Routers MUST NOT be configured with Valid or Preferred lifetime 329 values lower than the MaxRtrAdvInterval. 331 These minima ensure that lifetimes do not expire in between periodic 332 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 C 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 Routers with interfaces whose technology is bridgeable SHOULD NOT 462 assume that all segments and devices on the link have the same 463 bandwidth available. 465 3.2 Wireless cell coverage 467 Where the topology of a set of access networks is known to have a 468 single cell per link or subnet, IPv6 hosts may immediately solicit 469 for Router Advertisements upon notification of cell change. If link 470 design is also constrained to a single router per cell, RA response 471 delays may be reduced as described in Section 3.4. 473 Where link design is not constrained, many cells may exist within the 474 same link. 476 The scalability of a subnet in terms of wireless cell coverage is 477 likely to be limited by broadcast/multicast traffic between hosts on 478 the link. Where multicast packets may pass from one cell to another 479 in the link (even if no multicast listeners for the group exist), 480 constrained wireless segments' performance may become degraded. 482 In this case, it may be necessary to deploy multicast snooping or 483 split the link into smaller broadcast domains [13]. 485 3.3 Multiple Router Links 487 IPv6 Neighbour Discovery allows multiple routers to be advertising on 488 the same link [1]. These routers are not required to advertise the 489 same prefixes as each other. This section provides some guidelines 490 for deploying multiple routers on the same link. 492 While many routers may exist on a link, it is preferable to limit the 493 number of advertising routers. There SHOULD NOT be more than three 494 (3) routers advertising on a link. This will provide robustness in 495 the case of RA packet loss, but provides a bound for bandwidth 496 consumption. 498 Multiple routers responding to Router Solicitation will reduce the 499 mean delay for solicitation, at the cost of additional traffic. For 500 unicast responses, the delays may be halved for three responding 501 routers. 503 +-----------------------+---------+----------+----------+ 504 |Num advertising routers| 1 | 2 | 3 | 505 +-----------------------+---------+----------+----------+ 506 |Expected Unicast Delay | 0.250s | 0.167s | 0.125s | 507 +-----------------------+---------+----------+----------+ 509 If using advertising intervals lower than those specified in IPv6 510 Neighbour Discovery, only one router MAY advertise at the elevated 511 rate. Other routers beyond the first SHOULD NOT have 512 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 513 the minima specified in IPv6 Neighbour Discovery [1][3]. 515 Where it is possible, routers SHOULD include at least one common 516 prefix in all of their Router Advertisement messages. This allows 517 hosts to immediately see that both routers are on the same link. 519 3.4 Point-to-point Links 521 IPv6 Router Discovery mandates the delay of RA responses by stating 522 (in section 6.2.6 of [1]): 524 "In all cases, Router Advertisements sent in response to a 525 Router Solicitation MUST be delayed by a random time 526 between 0 and MAX_RA_DELAY_TIME seconds." 528 Cases where the router is on a point-to-point link, this restriction 529 is too stringent as the router in question will be the only router on 530 the link. Routers on such point-to-point links MAY avoid the delay 531 by not waiting for the prescribed random time before responding for 532 the Router Solicitation message [8] [14]. 534 3.5 Disjoint Administration 536 It is possible that multiple sets of routers may be administered by 537 different organizations, both advertising on a link. 539 Routers administered by different organizations are likely to have 540 different trust models, especially for routing and renumbering. This 541 may prevent alien routers from learning about changes in 542 configuration. Consequently, re-advertisements of learned prefixes 543 in router advertisements may cause problems for hosts trying to 544 detect link-change. It is important for deployers to remember that 545 prefixes belonging to another organization, but valid within a link, 546 SHOULD NOT be advertised if up-to-date prefix validity or lifetime 547 data are not available. 549 4. Security Considerations 551 When operating a network in support of hosts performing link change 552 detection, both the operational security of the hosts and network 553 infrastructure are important. DNA procedures rely upon rapid 554 delivery of information to hosts using IPv6 Neighbour Discovery. 555 Neighbour Discovery as a critical service in IPv6 networks is subject 556 to various attacks as described in [7]. 558 The following sections describe issues and practices to provide 559 additional functional security for both operators and hosts. 561 4.1 Supporting host security 563 In DNA, some hosts will begin configuration procedures based on a 564 single message transmitted by a router. As such the ability of 565 routing infrastructure to prove its authenticity and authorization is 566 important to support correct operation of hosts. As described in 567 Section 4.2, authentication and authorization mechanisms exist which 568 allow hosts to check security of routers when they receive Router 569 Advertisements indicating link change. 571 Today these mechanisms require additional message exchanges and 572 public key operations to check the authorization chain back to a 573 trusted root. Considering the computational cost for verifying 574 certificates, it will useful for administrators to attempt to 575 minimize the length of these authorization chains. 577 Where a Router Advertisement is sent by a router, it SHOULD contain 578 sufficient information to prove that the router is on the same link 579 as previously seen advertisers, or is indeed the same router. This 580 may prevent expensive checks by hosts which will not need to 581 immediately test the authenticity of the router through signature 582 verification, or additional transmissions. 584 As described in section Section 3.3, advertising common prefixes 585 achieves this goal. 587 4.2 Providing Router Authorization 589 Hosts which wish to have secured exchanges with neighbours and on- 590 link routers may use Secured Neighbour Discovery (SEND) [4]. SEND 591 provides authenticity as well as response matching, using nonces 592 copied from solicitations into advertisements. 594 Responses which contain nonces may be matched to one or more 595 solicitations (dependent on the number of Nonce Options contained in 596 the Advertisement), and may be used to provide authenticated 597 bidirectional reachability confirmation even if received in a 598 multicast advertisement. 600 The router digitally signs its advertisements with a key-pair which 601 was also used to generate the router's transmitting address. This 602 guarantees the origin, as well as the freshness of the Router 603 Advertisement transmission. 605 DNA relies particularly heavily upon router discovery in order to 606 test the validity of routing and addressing configuration. In 607 addition to reachability and configuration parameters, routing 608 authorization needs to be determined for each router. In SEND [4], 609 routing authorization is delegated by certificate authorities. 611 SEND Router Advertisement packets contain the router's public key 612 from a key pair used to sign the message. Certificate authorities 613 delegate a portion of their routing authority to the router, tying 614 them to the public key of the router. Hosts need to test the 615 router's authority to provide routing for the prefixes advertised in 616 its RAs in order to ensure safe configuration. 618 While it may be onerous to organize and manage key distribution and 619 certificates for routing authorization, the security and robustness 620 afforded by secured neighbour discovery provides a key advantage for 621 IPv6 networks over what is available in IPv4. 623 Routers supporting DNA SHOULD provide secured router discovery 624 services using SEND [4]. 626 5. References 628 5.1 Normative References 630 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 631 for IP Version 6 (IPv6)", RFC 2461, December 1998. 633 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 634 Levels", BCP 14, RFC 2119, March 1997. 636 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 637 IPv6", RFC 3775, June 2004. 639 [4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 640 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 641 (work in progress), July 2004. 643 5.2 Informative References 645 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 646 Autoconfiguration", RFC 2462, December 1998. 648 [6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 649 Addressing Architecture", RFC 3513, April 2003. 651 [7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 652 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 654 [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 655 December 1998. 657 [9] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 658 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 659 Std 802.11, 1999. 661 [10] Yamamoto, S., "Detecting Network Attachment Terminology", 662 draft-yamamoto-dna-term-00 (work in progress), February 2004. 664 [11] Manner, J. and M. Kojo, "Mobility Related Terminology", 665 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 666 February 2004. 668 [12] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 669 draft-ietf-ipv6-optimistic-dad-02 (work in progress), 670 September 2004. 672 [13] Christensen, M., Kimball, K., and F. Solensky, "Considerations 673 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 674 (work in progress), February 2005. 676 [14] "3GPP TS 29.061 V5.5.0 (2003-03) Interworking between the 677 Public Land Mobile Network (PLMN) supporting packet based 678 services and Packet Data Networks (PDN) (Release 5)", 679 TS 29.061, March 2003. 681 [15] Choi, J., "Fast Router Discovery with RA Caching", 682 draft-jinchoi-dna-frd-00 (work in progress), July 2004. 684 Authors' Addresses 686 Sathya Narayanan 687 Panasonic Digital Networking Lab 688 Two Research Way, 3rd Floor 689 Princeton, NJ 08536 690 USA 692 Phone: 609 734 7599 693 Email: sathya@Research.Panasonic.COM 694 URI: 696 Greg Daley 697 Centre for Telecommunications and Information Engineering 698 Department of Electrical adn Computer Systems Engineering 699 Monash University 700 Clayton, Victoria 3800 701 Australia 703 Phone: +61 3 9905 4655 704 Email: greg.daley@eng.monash.edu.au 705 Nicolas Montavont 706 LSIIT - Univerity Louis Pasteur 707 Pole API, bureau C444 708 Boulevard Sebastien Brant 709 Illkirch 67400 710 FRANCE 712 Phone: (33) 3 90 24 45 87 713 Email: montavont@dpt-info.u-strasbg.fr 714 URI: http://www-r2.u-strasbg.fr/~montavont/ 716 Appendix A. Summary of Recommendations 718 It should be noted that many already deployed routers will not 719 support these recommendations, and that hosts SHOULD NOT rely on 720 their being in place, unless they have particular reason to do so. 722 Where many unicast responses are scheduled awaiting transmission, 723 Routers MAY consider aggregating them into a single multicast 724 response if a multicast advertisement may be sent before the 725 advertisements' scheduled transmission time. 727 Where multiple unicast transmissions for the same destination await 728 transmission, routers MAY remove all transmissions after the first 729 without ill-effect, if a multicast RA is scheduled for the next 730 possible response time. 732 Routers MAY choose to respond to RS messages with a unicast RA 733 response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS 734 restriction [1]. 736 Routers SHOULD be configured to advertise non-default Valid and 737 Preferred lifetimes in order to provide DNA hosts with link-specific 738 address lifetime information. 740 Where hosts with ongoing transactions, or well known services are 741 present on a network, this duration SHOULD be greater than the 742 maximum expected outage time. 744 Upon links where fixed hosts are unlikely to be present, 745 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 746 and Preferred Lifetimes on routers used to support DNA. 748 The Router Lifetime MUST NOT be advertised as less than the 749 MaxRtrAdvInterval unless the router is not to be used as a default 750 [1]. 752 Routers MUST NOT be configured with Valid or Preferred lifetime 753 values lower than the MaxRtrAdvInterval. 755 Routers SHOULD include at least one global Prefix Information Option 756 in every Router Advertisement. 758 Routers SHOULD include Advertisement Interval options in Router 759 Advertisements. 761 Routers SHOULD advertise at least one global address consistently in 762 a Prefix Information Option, by setting the Router Address 'R' Flag. 764 A router MAY choose to split the options in the RA and send multiple 765 RAs to reduce bandwidth overhead or to reduce the size of the RA to 766 below the link MTU (see section 6.2.3 of [1]). 768 While transitions between links under different administrative 769 control are considered to be common, it is RECOMMENDED that network 770 deployers adopt uniform configuration practices across routers on 771 different links within the same logical domain, in order to provide 772 consistent performance. 774 Routers with interfaces whose technology is bridgeable SHOULD NOT 775 assume that all segments and devices on the link have the same 776 bandwidth available. 778 There SHOULD NOT be more than three (3) routers advertising on a 779 link. 781 If using advertising intervals lower than those specified in IPv6 782 Neighbour Discovery, only one router MAY advertise at the elevated 783 rate. Other routers beyond the first SHOULD NOT have 784 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 785 the minima specified in IPv6 Neighbour Discovery [1][3]. 787 Where it is possible, routers SHOULD include at least one common 788 prefix in all of their Router Advertisement messages. 790 Routers on point-to-point links MAY avoid delay by not waiting for 791 the prescribed random time before responding for the Router 792 Solicitation message [8] [14]. 794 Considering the computational cost for verifying certificates, 795 administrators SHOULD attempt to minimize the length of authorization 796 chains. 798 Where a Router Advertisement is sent by a router, it SHOULD contain 799 sufficient information to prove that the router is on the same link 800 as previously seen advertisers, or is indeed the same router. 802 Routers supporting DNA SHOULD provide secured router discovery 803 services using SEND [4]. 805 On access networks supporting Detecting Network Attachment, 806 administrators SHOULD configure routers to advertise at the shortest 807 safe intervals. 809 Appendix B. Analysis of the response time 811 In IPv6 Neighbour Discovery, the delay induced by the 812 MIN_DELAY_BETWEEN_RAS restriction is up to 3 seconds. This delay may 813 not be very high if the minimum value (MinDelayBetweenRAs=0.03s) 814 suggested in Mobile IPv6 is implemented [3]. 816 The fraction of time which MinDelayBetweenRAs occupies in the Router 817 Advertisement interval determines the probability of scheduling 818 delay. 820 Assuming that the arrival of RS messages is independent of each 821 other, and that the arrival of any particular RS is equally likely 822 across an interval, The probability of delay occurring to a 823 particular RS is: 825 P_mcdelay = MinDelayBetweenRAs 826 ---------------------------- 827 (MinRtrAdvInterval + MaxRtrAdvInterval)/2 829 Where the mean interval is defined as the mean delay before 830 scheduling an unsolicited Router Advertisement. The probability of 831 delay with routers using the minimum values from IPv6 Neighbour 832 Discovery is: 0.851 [1] 834 Considering the above values, it is also necessary to remember that 835 all responses will be delayed by a random time between 0 and 836 MAX_RA_DELAY_TIME (0.5 s) [1]. 838 In this case, the expected delay E_mcrsra for a single arriving RS 839 is: 841 E_mcrsra = P_mcdelay * MinDelayBetweenRAs/2 + MAX_RA_DELAY_TIME/2 843 Again for RFC2461 minima, the expected delay is thus: 1.535 s. 845 The average unicast RA response time of course is 0.250 seconds. 847 Assumptions underpinning this approximation hold only if the 848 likelihood of more than one RS arriving within a multicast delay 849 interval is very low. This depends on the arrival rate (lambda) of 850 Router Solicitations, and is based on a Poisson distribution. 852 The probability of more than one RS arriving in the interval t of 853 MinDelayBetweenRAs (defaulting to MIN_DELAY_BETWEEN_RAS) is: 855 P[X(t) > 1] = 1 - P[X(t) == 1] - P[X(t) == 0] 857 = 1 - (lambda*t)*exp(-lambda*t)/1! - exp(-lambda*t)/0! 859 = 1 - ( 1 + lambda*t)* exp (-lambda*t) 861 For a given load (lambda)=0.05 RS/sec, the probability of multiple RS 862 arrival is 1.01%. 864 Adopting the MinDelayBetweenRAs = 0.03s and MaxRtrAdvinterval= 4s the 865 probability of arrival in the MinDelayBetweenRAs interval is 0.0148. 866 The estimated expected delay for multicast RS/RA exchange is 867 therefore 0.25022 seconds. 869 This is comparable to the unicast response delay. 871 In this case, the chance of additional solicitation arrival during 872 MinDelayBetweenRAs is very low (around 1 in 10^6 for t=0.03, 873 lambda=0.05). 875 Please note that if the MaxRtrAdvInterval is also low (making the 876 mean interval duration low), the solicitor is likely to get get an 877 unsolicited RA due to early scheduling of the RA during the RS/RA 878 delay period (see Appendix C). 880 As described in [3], some systems may not provide tunable 881 MinDelayBetweenRAs except that it assumes the value of the minimum 882 time difference between unsolicited RAs (MinRtrAdvInterval) when 883 MinRtrAdvInterval is less than 3 seconds. Reducing MinRtrAdvInterval 884 to will increase the rate of RA transmission, but this doesn't need 885 to be a dramatic increase. For example, even if the lowest value for 886 MinRtrAdvInterval is selected (0.03 s), if the MaxRtrAdvInterval is 887 kept at its RFC2461 minimum (4 seconds) the mean interval between RAs 888 is over 2 seconds. This compares with a mean interval of 3.5 seconds 889 for advertisement only using the RFC2461 minima. 891 Where the MinDelayBetweenRAs is correspondingly lowered to the 892 minimum values, the rate of solicited multicast RAs may be elevated 893 to around 33 per second. This raises the potential for abuse by 894 attackers which can force uniform resource consumption across all 895 cells in a link. 897 It is possible to choose delay values which provide significantly 898 improved expected and worst case delays over RFC 2461 values, and 899 have well defined upper bound traffic costs for constrained links. 901 For example, if a link is able to sustain a maximum of two multicast 902 RAs per second, a safe value for MinRtrAdvInterval and consequently 903 MinDelayBetweenRAs is t=0.5s. With similar load values to those 904 presented above, the probability of arrival within the interval 905 P_mcdelay = 0.222, with an expected RS/RA delay of E_mcrsra = 0.305s. 907 As mentioned above the probability of multiple RS arrival in the 908 interval would be 3.07 * 10^-4 with a load (lambda)=0.05. 910 This MinDelayBetweenRAs allows fairly good multicast response 911 performance but bounds the number of multicast RAs to two per second. 912 Regardless of load, the worst case delay for RA response in this case 913 is no greater than 2*MIN_DELAY_BETWEEN_RAs (1 second). 915 Appendix C. Router Advertisement Rates 917 Unsolicited Router Advertisements are scheduled to be transmitted at 918 a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last 919 multicast Router Advertisement. These parameters may be configured 920 in the way which best suits the network. The table below summarizes 921 the parameters as described by IPv6 Neighbour Discovery [1]. 923 +-----------------------+----+----+----+-----+----+-----+ 924 | Timer |Maximum |Default |Minimum | 925 +-----------------------+----+----+----+-----+----+-----+ 926 | MaxRtrAdvInterval | 1800 | 600 | 4 | 927 +-----------------------+----+----+----+-----+----+-----+ 928 | MinRtrAdvInterval | 594 | 198 | 3 | 929 +-----------------------+----+----+----+-----+----+-----+ 930 |Avg. Multicast RA time | 1197 | 399 | 3.5 | 931 +-----------------------+----+----+----+-----+----+-----+ 933 The load on the network, and the timeliness of any received 934 information updates are therefore influenced by the router's 935 advertisement parameters. 937 On access networks supporting Detecting Network Attachment, 938 administrators SHOULD configure routers to advertise at the shortest 939 safe intervals. Determination of the shortest safe intervals depends 940 on topology, and the composition of the link, as described in 941 Section 3.1. 943 Mobile IPv6 attempts to address the delays associated with hosts' 944 movement and change detection by reducing the minimum settings for 945 MinRtrAdvInterval to 30ms and MaxRtrAdvInterval to 70ms. Not all 946 IPv6 routers support these configuration values today. Where hosts 947 have no reactive way of detecting change, and do not solicit for 948 Router Advertisements, these intervals may allow change detection 949 sufficiently fast to support real-time applications. 951 The effect of these timers are summarized in the table below. 953 +-----------------------+----+----+----+-----+----+-----+ 954 | Timer |Maximum |Default |Minimum | 955 +-----------------------+----+----+----+-----+----+-----+ 956 | MaxRtrAdvInterval | 1800 | 600 | 0.07 | 957 +-----------------------+----+----+----+-----+----+-----+ 958 | MinRtrAdvInterval | 594 | 198 | 0.03 | 959 +-----------------------+----+----+----+-----+----+-----+ 960 |Avg. Multicast RA time | 1197 | 399 | 0.05 | 961 +-----------------------+----+----+----+-----+----+-----+ 963 Where Mobile IPv6 is supported, the minimum values change, but the 964 default timers are unmodified. If administrators wish to take 965 advantage of shorter intervals between unsolicited RAs, explicit 966 configuration is required. This is because the elevated rate of 967 multicast RA transmission can have detrimental effects on some 968 constrained links [3]. 970 The minimum average for un-solicited Router Advertisements would be 971 20 messages per second. Assuming the minimum packet size for an RA 972 with one prefix as 88 bytes, the bandwidth used will be 14 kbps. 973 With SEND Options, and (somewhat weak) 1024-bit RSA keys, a single RA 974 could be around 432 octets. This would consume approximately 69 kbps 975 without considering link-layer overheads [4]. 977 As described in Section 2.1, parameters may be chosen to optimize 978 solicited behaviour in a way which limits the mean bandwidth overhead 979 for unsolicited RAs. 981 A good example would be setting a MinRtrAdvInterval (along with 982 MinDelayBetweenRAs) as 0.5 s, and the MaxRtrAdvInterval to 4s. This 983 makes the mean delay before receiving an unsolicited RA 2.25 seconds, 984 and limits the bandwidth utilization for unsolicited RAs (using the 985 SEND example above) to 1.5 kbps, and the maximum multicast solicited 986 rate to 6.9 kbps (one multicast RA each 0.5s). 988 Intellectual Property Statement 990 The IETF takes no position regarding the validity or scope of any 991 Intellectual Property Rights or other rights that might be claimed to 992 pertain to the implementation or use of the technology described in 993 this document or the extent to which any license under such rights 994 might or might not be available; nor does it represent that it has 995 made any independent effort to identify any such rights. Information 996 on the procedures with respect to rights in RFC documents can be 997 found in BCP 78 and BCP 79. 999 Copies of IPR disclosures made to the IETF Secretariat and any 1000 assurances of licenses to be made available, or the result of an 1001 attempt made to obtain a general license or permission for the use of 1002 such proprietary rights by implementers or users of this 1003 specification can be obtained from the IETF on-line IPR repository at 1004 http://www.ietf.org/ipr. 1006 The IETF invites any interested party to bring to its attention any 1007 copyrights, patents or patent applications, or other proprietary 1008 rights that may cover technology that may be required to implement 1009 this standard. Please address the information to the IETF at 1010 ietf-ipr@ietf.org. 1012 Disclaimer of Validity 1014 This document and the information contained herein are provided on an 1015 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1016 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1017 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1018 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1019 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1020 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1022 Copyright Statement 1024 Copyright (C) The Internet Society (2005). This document is subject 1025 to the rights, licenses and restrictions contained in BCP 78, and 1026 except as set forth therein, the authors retain all their rights. 1028 Acknowledgment 1030 Funding for the RFC Editor function is currently provided by the 1031 Internet Society.