idnits 2.17.1 draft-ietf-dna-network-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 824. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 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 6, 2006) is 6505 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: '8' is defined on line 592, 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 3513 (ref. '5') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2472 (ref. '7') (Obsoleted by RFC 5072, RFC 5172) == Outdated reference: A later version (-02) exists of draft-ietf-dna-frd-00 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group S. Narayanan 3 Internet-Draft G. Daley 4 Expires: December 8, 2006 Panasonic 5 N. Montavont 6 GET - ENST Bretagne 7 June 6, 2006 9 Detecting Network Attachment in IPv6 - Network Deployment Considerations 10 draft-ietf-dna-network-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 8, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Hosts experiencing rapid link-layer changes may require to do 44 configuration change detection procedures more frequently than 45 traditional fixed hosts. This document describes practices available 46 to network deployers in order to support such hosts in Detecting 47 Network Attachment in IPv6 networks. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [2]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 59 1.2 Relevant Host Issues . . . . . . . . . . . . . . . . . . . 4 60 1.3 Relevant Router Issues . . . . . . . . . . . . . . . . . . 4 61 1.4 Applicability statement . . . . . . . . . . . . . . . . . 5 63 2. Configuration Practices for DNAv6 Routers . . . . . . . . . . 5 64 2.1 Multicast and Unicast RA Responses . . . . . . . . . . . . 5 65 2.1.1 Recommendations . . . . . . . . . . . . . . . . . . . 7 66 2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7 67 2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8 68 2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8 69 2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9 70 2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9 71 2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9 72 2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10 74 3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10 75 3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10 76 3.2 Multiple Router Links . . . . . . . . . . . . . . . . . . 11 77 3.3 Point-to-point Links . . . . . . . . . . . . . . . . . . . 11 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 5.1 Providing Router Authorization . . . . . . . . . . . . . . 12 84 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 6.1 Normative References . . . . . . . . . . . . . . . . . . . 13 86 6.2 Informative References . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 90 A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14 92 B. Router Advertisement Rates . . . . . . . . . . . . . . . . . . 16 94 Intellectual Property and Copyright Statements . . . . . . . . 19 96 1. Introduction 98 Hosts on the Internet may be connected by various media. It has 99 become common that hosts have access through wireless media and are 100 mobile. The frequency of configuration change for wireless and 101 nomadic devices are elevated, due to the vagaries of wireless 102 propagation or the motion of the hosts themselves. 104 Such hosts need to determine if they have moved to a new IPv6 link 105 rapidly, in order that configuration procedures may be run and 106 application packet delivery services restored. Detecting Network 107 Attachment (DNA) is a strategy to assist such configuration changes 108 by rapidly determining whether they are required. 110 Several network-side factors may impact the effectiveness and speed 111 of DNA procedures. This document provides guidelines embodying the 112 best current practice for network deployers wishing to support 113 detection of network attachment by IPv6 hosts. 115 It should be noted that many already deployed routers will not 116 support these recommendations, and that hosts SHOULD NOT rely on 117 their being in place, unless they have particular reason to do so. 119 1.1 Terms and Abbreviations 121 Access network: A network where hosts are present. Especially, a 122 network used for the support of visiting wireless hosts. 124 Link: A link is the range across which communications can pass 125 without being forwarded through a router [1]. 127 Link-Change: Link-Change occurs when a host moves from a point-of- 128 attachment on a link, to another point-of-attachment where it is 129 unable to reach devices belonging to the previous link, without 130 being forwarded through a router. 132 Point-of-Attachment: A link-layer base-station, VLAN or port through 133 which a device attempts to reach the network. Changes to a 134 host's point-of-attachment may cause link-change. 136 Reachability Detection: Determination that a device (such as a 137 router) is currently reachable, over both a wireless medium, and 138 any attached fixed network. This is typically achieved using 139 Neighbor Unreachability Detection procedure [1]. 141 Wireless Medium: A physical layer which incorporates free space 142 electromagnetic or optical propagation. Such media are 143 susceptible to mobility and interference effects, potentially 144 resulting in high packet loss probabilities. 146 1.2 Relevant Host Issues 148 Hosts attempting to discover link change are likely to send Router 149 Solicitations (RSs) in order to identify the routers and prefixes 150 available on a link. Additionally, they may wish to send Neighbour 151 Solicitations (NSs) to known routers for reachability detection 152 purposes. 154 The following is a list of critical issues for hosts undertaking link 155 change detection in IPv6: 157 Hosts require Router Advertisements (RAs) rapidly in order to 158 minimize reconfiguration latencies in the case of link change or 159 link failure. 161 Hosts need to identify if their current prefix is still valid on a 162 link before the prefix expires. Existing IPv6 Neighbour Discovery 163 procedures make this difficult. If the host can determine that 164 the target router is still reachable through a NS/NA exchange, it 165 does not mean that the prefix is still valid on that link. This 166 is because link-local addresses are used for the NS/NA exchange. 167 Conversely, if host sends an RS, the RA received in response may 168 not contain the prefix of interest for the hosts. 170 Hosts wish to detect if a particular router is reachable in order 171 to use it for routing. 173 Hosts may require some assurance that a device is actually 174 present, and is authorized to act as a router. 176 Consideration for these issues underlie the practices recommended in 177 this document. 179 1.3 Relevant Router Issues 181 The IPv6 Neighbour Discovery RFC [1] provides mechanisms where 182 hosts can send Router Solicitations and receive Router 183 Advertisements, from each of the routers on a link. 185 Responses may either be unicast or multicast, but in all cases, a 186 random delay of between 0 and 500 milliseconds is required before 187 responses are sent. This is to prevent multiple routers 188 responding at the same time, and also may mitigate the effects of 189 simultaneous solicitations. This results in a basic time delay 190 incurred by hosts receiving response RAs, which cannot be avoided 191 within current standards [1]. 193 As described in Section 2.1, additional delays may occur if 194 multicast responses are required. 196 Routers should also be careful not to increase the network 197 overhead by frequently transmitting router advertisements (see 198 Section 2.4). 200 Multiple prefixes advertised in different RAs by a single router 201 may lead to host configurations errors. It may generate erroneous 202 movement detection and/or delay hosts to detect that a prefix is 203 not valid anymore. 205 1.4 Applicability statement 207 The practices embodied in this document are considered to provide 208 minimal support for hosts wishing to detect network attachment. 209 Current work within the DNA working group aims to provide 210 substantially improved performance for link change detection. 212 Existing limitations in base protocols such as IPv6 Neighbour 213 Discovery preclude support of real-time applications in some 214 environments. Future deployers and implementers are encouraged to 215 consider the protocols under development at this time in order to 216 provide a generic service to support hosts detecting change. 218 2. Configuration Practices for DNAv6 Routers 220 Routers which are being deployed to aid hosts' change detection 221 procedures should attempt to use appropriate configurations, which 222 limit advertisement latency, and provide appropriate service 223 considering the constraints of the deployed access network 224 technology. 226 This section describes several configuration parameters which may 227 exist on IPv6 routers, and how their tuning may affect DNA hosts. 229 2.1 Multicast and Unicast RA Responses 231 While IPv6 Neighbour Discovery assumes that responses to 232 solicitations will be sent multicast, the specification allows any 233 router to respond to RS message with a unicast RA [1]. Note that the 234 delay between 0 and MAX_RA_DELAY_TIME is still applicable when a 235 router responds to a RS with a unicast RA. 237 The advantage in responding with an unicast RA message is to allow 238 the IP host to conclusively infer bi-directional reachability from 239 the RS-RA exchange. Neighbour Discovery does not provide any 240 mechanism to match multicast RA responses with their solicitation, 241 and therefore it is not possible for the hosts to find out whether at 242 least one of its RS messages was received and processed by the 243 router. Since unicast RAs are only sent in response to solicitation, 244 a host can infer that at least one of its Router Solicitations 245 reached the router. 247 The dis-advantage in sending unicast RA is that the router will not 248 be able to aggregate its response for multiple RS messages from 249 multiple hosts received during the waiting period before RA 250 transmission. Moreover, using unicast RA to respond to RS disables 251 routers' ability to limit the rate of unicast RA. 253 For multicast Router Advertisements, a minimum separating delay 254 exists so that these RAs may not be scheduled close to each other. 255 When a host solicits and attempts to schedule a multicast RA within 256 MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of 257 the previous multicast Router Advertisement, the scheduling of a 258 response will be deferred until the minimum separation expires. 260 This separation delay does not affect unicast Router Advertisement 261 responses. Routers MAY choose to respond to RS messages with a 262 unicast RA response to avoid the delay introduced by the 263 MIN_DELAY_BETWEEN_RAS restriction [1]. 265 Where many unicast responses are scheduled awaiting transmission, 266 Routers MAY consider aggregating them into a single multicast 267 response if a multicast advertisement may be sent before the 268 advertisements' scheduled transmission time. 270 It is noted that computational requirements for SEND may preclude 271 this subsequent aggregation in some environments. 273 Where multiple unicast transmissions for the same destination await 274 transmission, routers MAY remove all transmissions after the first 275 without ill-effect, if a multicast RA is scheduled for the next 276 possible response time. 278 In some cases it is not possible to provide unicast responses, since 279 solicitations may be sent with an unspecified address, or 280 solicitations do not provide enough link-layer addressing information 281 to send an unicast response without neighbour discovery exchange. In 282 these cases, a router may need to send multicast responses, even if 283 the expected delay is greater. 285 2.1.1 Recommendations 287 Routers SHOULD respond to a RS message with unicast RA message. 289 Routers SHOULD aggregate RA messages into a multi-cast RA message 290 if more than 3 unicast RA messages are queued for transmission. 292 Where multiple unicast transmissions for the same destination 293 await transmission, routers MAY remove all transmissions after the 294 first without ill-effect. 296 2.2 Router Advertisement Parameters 298 Where hosts often change their link attachment (e.g., because they 299 are mobile), there may be a number of prefixes or routers stored in 300 the host's memory, which are no longer directly reachable. This 301 additional storage may make movement detection slower where hosts 302 rapidly pass through networks, or pass through networks which have 303 very long advertised timeouts. 305 Routers SHOULD be configured to advertise non-default Valid and 306 Preferred lifetimes in order to provide DNA hosts with link-specific 307 address lifetime information. 309 Administrators are advised to set the advertised Preferred and Valid 310 timers of prefixes to the maximum duration for which any host may be 311 required to continue functioning without receiving a particular 312 advertised prefix. 314 Where hosts with long-lifetime communications, or well known services 315 (such as DNS) are present on a network, the preferred lifetime SHOULD 316 be greater than the maximum expected outage time (For example, if the 317 maximum router outage is 8.72 hours (for 0.999 uptime), the preferred 318 lifetime could be set to 9 hours, which would be sufficient to 319 support existing and allow new communications across the failure). 321 Upon links where fixed hosts are unlikely to be present, 322 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 323 and Preferred Lifetimes on routers used to support DNA. 325 One potential configuration heuristic would be to configure lifetimes 326 to be a low number (for example: 15) of times the MaxRtrAdvInterval, 327 or greater than the lower quartile cell residence time of hosts on 328 the network (if known). This allows reuse of configuration in the 329 case where hosts are moving back and forth rapidly between links, but 330 allows rapid timeouts of old configurations. 332 The Router Lifetime MUST NOT be advertised as less than the 333 MaxRtrAdvInterval unless the router is not to be used as a default 334 [1]. 336 Routers MUST NOT be configured with Valid or Preferred lifetime 337 values lower than the MaxRtrAdvInterval. These minima ensure that 338 lifetimes do not expire in between periodic Router Advertisements. 340 2.2.1 Recommendations 342 Routers SHOULD be configured to advertise non-default Valid and 343 Preferred lifetimes in order to provide DNA hosts with link- 344 specific address lifetime information. 346 Upon links where fixed hosts are unlikely to be present, 347 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 348 and Preferred Lifetimes on routers used to support DNA. 350 The Router Lifetime MUST NOT be advertised as less than the 351 MaxRtrAdvInterval unless the router is not to be used as a default 352 [1]. 354 Routers MUST NOT be configured with Valid or Preferred lifetime 355 values lower than the MaxRtrAdvInterval. 357 2.3 Router Advertisement Options 359 When receiving a Router Advertisement from a particular router for 360 the first time, a host needs to determine if the information 361 contained in the RA indicates link change or that the transmitting 362 router is part of the same link as another router it has already 363 seen. It is not possible to do this unless global prefix information 364 is included in the advertisement. 366 Routers SHOULD include at least one global Prefix Information Option 367 in every Router Advertisement. 369 Mobile IPv6 introduced a new option for Router Advertisements, which 370 indicates the current MaxRtrAdvInterval of router [3]. Reception of 371 this option allows hosts to estimate whether they have missed Router 372 Advertisements, and allows them to check reachability or discover new 373 routers. 375 Routers SHOULD include Advertisement Interval options in Router 376 Advertisements. 378 Mobile IPv6 adds the Router Address 'R' Flag to Prefix Information 379 options [3]. This flag, when set indicates that the router's entire 380 global address is configured and sent in the prefix information 381 option. Bits beyond those specified in the prefix length field 382 identify the router's Interface Identifier [5]. 384 Hosts which are detecting network attachment can use a global router 385 address to uniquely identify the router and link, rather than using 386 link-local source addresses, which may be present on multiple links. 388 Routers SHOULD advertise at least one global address consistently in 389 a Prefix Information Option, by setting the Router Address 'R' Flag. 391 2.3.1 Recommendations 393 Routers SHOULD include at least one global Prefix Information 394 Option in every Router Advertisement. 396 Routers SHOULD include Advertisement Interval options in Router 397 Advertisements. 399 Routers SHOULD advertise at least one global address consistently 400 in a Prefix Information Option, by setting the Router Address 'R' 401 Flag. 403 2.4 Triggered Router Advertisements 405 There are proposals for IPv6 Router Advertisements to be sent to 406 hosts based on network side link-layer information. 408 Where these mechanisms exist they can provide Router Advertisements 409 in the quickest possible time without need for Router Solicitation. 410 These systems rely upon link-layer facilities are not available in 411 all environments. Therefore, interested readers are referred to the 412 individual methods' documentation [10]. 414 2.5 Split Advertisements 416 A router may choose to split the options in the RA and send multiple 417 RAs to reduce bandwidth overhead or to reduce the size of the RA to 418 below the link MTU (section 6.2.3 of [1]). 420 If such a choice is made, average multicast RA time discussed in 421 Appendix B increases for each subset of the prefixes included in the 422 split RA messages. 424 Routers SHOULD consistently include one prefix in both sets of its RA 425 messages. This provide the host with a unique identifier based on 426 the combination of link-local address and the constant prefix, to 427 identify the router every time a RA message is received. 429 2.6 Router Configurations 431 Each router can have its own configuration with respect to sending 432 RAs, and the treatment of router and neighbour solicitations. 433 Different timers and constants might be used by different routers, 434 such as the delay between Router Advertisements or delay before 435 replying to a multicast RS. If a host is changing its IPv6 link, a 436 newly seen router on that link may have a different configuration and 437 may introduce more delay than the previous default router of the 438 host. 440 While transitions between links under different administrative 441 control are considered to be common, it is RECOMMENDED that network 442 deployers adopt uniform configuration practices across routers on 443 different links within the same logical domain, in order to provide 444 consistent performance. 446 3. Topological Practices for DNAv6 Networks 448 IPv6 does not prefer one particular network topology over another and 449 allows multiple routers and subnet prefixes to exist on one link. 450 Different deployments of network elements and their configuration may 451 impact on link change detection though. Effects and recommended 452 practices for dealing with different network topologies are presented 453 below. 455 3.1 Link Extent and Composition 457 Most of today's access networks deploy link-layer bridging 458 technologies in order to extend their logical range beyond a single 459 Medium Access Control domain. 461 Consequently, while many routers will come with traditional wired or 462 optic-fibre interfaces, packets travelling within the same link may 463 have been bridged across from a wired segment to a wireless segment. 465 In many of cases, the router will not have accurate information about 466 the transmission rates or media of particular segments on the link. 467 When defining the frequency at which RA will be sent over a link, 468 Routers with interfaces whose technology is bridgeable SHOULD NOT 469 assume that all segments and devices on the link have the same 470 bandwidth available. 472 3.2 Multiple Router Links 474 IPv6 Neighbour Discovery allows multiple routers to be advertising on 475 the same link [1]. These routers are not required to advertise the 476 same prefixes as each other. This section provides some guidelines 477 for deploying multiple routers on the same link. 479 While many routers may exist on a link, it is preferable to limit the 480 number of advertising routers. There SHOULD NOT be more than three 481 (3) routers advertising on a link. This will provide robustness in 482 the case of RA packet loss, but provides a bound for bandwidth 483 consumption. 485 Multiple routers responding to Router Solicitation will reduce the 486 mean delay for solicitation, at the cost of additional traffic. For 487 unicast responses, the delays may be halved for three responding 488 routers. 490 +-----------------------+---------+----------+----------+ 491 |Num advertising routers| 1 | 2 | 3 | 492 +-----------------------+---------+----------+----------+ 493 |Expected Unicast Delay | 0.250s | 0.167s | 0.125s | 494 +-----------------------+---------+----------+----------+ 496 If using advertising intervals lower than those specified in IPv6 497 Neighbour Discovery, only one router MAY advertise at the elevated 498 rate. Other routers beyond the first SHOULD NOT have 499 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 500 the minima specified in IPv6 Neighbour Discovery [1][3]. 502 Where it is possible, routers SHOULD include at least one common 503 prefix in all of their Router Advertisement messages. This allows 504 hosts to immediately see that both routers are on the same link. 506 3.3 Point-to-point Links 508 IPv6 Router Discovery mandates the delay of RA responses by stating 509 (in section 6.2.6 of [1]): 511 "In all cases, Router Advertisements sent in response to a 512 Router Solicitation MUST be delayed by a random time 513 between 0 and MAX_RA_DELAY_TIME seconds." 515 Cases where the router is on a point-to-point link, this restriction 516 is too stringent as the router in question will be the only router on 517 the link. Routers on such point-to-point links MAY avoid the delay 518 by not waiting for the prescribed random time before responding for 519 the Router Solicitation message [7] [9]. 521 4. IANA Considerations 523 No action is required by IANA for this document 525 5. Security Considerations 527 When operating a network in support of hosts performing link change 528 detection, both the operational security of the hosts and network 529 infrastructure are important. DNA procedures rely upon rapid 530 delivery of information to hosts using IPv6 Neighbour Discovery. 531 Neighbour Discovery as a critical service in IPv6 networks is subject 532 to various attacks as described in [6]. 534 The following sections describe issues and practices to provide 535 additional functional security for operators. 537 5.1 Providing Router Authorization 539 In DNA, some hosts will begin configuration procedures based on a 540 single message transmitted by a router. As such the ability of 541 routing infrastructure to prove its authenticity and authorization is 542 important to support correct operation of hosts. Authentication and 543 authorization mechanisms exist which allow hosts to check security of 544 routers when they receive Router Advertisements indicating link 545 change. 547 Today these mechanisms require additional message exchanges and 548 public key operations to check the authorization chain back to a 549 trusted root. Considering the computational cost for verifying 550 certificates, it will be useful for administrators to attempt to 551 minimize the length of these authorization chains. 553 Where a Router Advertisement is sent by a router, it SHOULD contain 554 sufficient information to prove that the router is on the same link 555 as previously seen advertisers, or is indeed the same router. This 556 may prevent expensive checks by hosts which will not need to 557 immediately test the authenticity of the router through signature 558 verification, or additional transmissions. As described in section 559 Section 3.2, advertising common prefixes achieves this goal. 561 Hosts which wish to have secured exchanges with neighbours and on- 562 link routers may use Secured Neighbour Discovery (SEND) [4]. SEND 563 provides authenticity as well as response matching, using nonces 564 copied from solicitations into advertisements. 566 6. References 567 6.1 Normative References 569 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 570 for IP Version 6 (IPv6)", RFC 2461, December 1998. 572 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 573 Levels", BCP 14, RFC 2119, March 1997. 575 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 576 IPv6", RFC 3775, June 2004. 578 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 579 Neighbor Discovery (SEND)", RFC 3971, March 2005. 581 6.2 Informative References 583 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 584 Addressing Architecture", RFC 3513, April 2003. 586 [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 587 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 589 [7] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 590 December 1998. 592 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", 593 RFC 3753, June 2004. 595 [9] "3GPP TS 29.061 V5.5.0 (2003-03) Interworking between the 596 Public Land Mobile Network (PLMN) supporting packet based 597 services and Packet Data Networks (PDN) (Release 5)", 598 TS 29.061, March 2003. 600 [10] Choi, J., "Fast Router Discovery with L2 support", 601 draft-ietf-dna-frd-00 (work in progress), October 2005. 603 Authors' Addresses 605 Sathya Narayanan 606 Panasonic Princeton Lab 607 Two Research Way, 3rd Floor 608 Princeton, NJ 08536 609 USA 611 Phone: 609 734 7599 612 Email: sathya@Research.Panasonic.COM 613 URI: 615 Greg Daley 616 Panasonic Princeton Lab 617 Two Research Way, 3rd Floor 618 Princeton, NJ 08536 619 USA 621 Phone: 609 734 7334 622 Email: gregd@Research.Panasonic.COM 623 URI: 625 Nicolas Montavont 626 GET - ENST Bretagne 627 Departement RSM 628 2, rue de la chataigneraie 629 Cesson-Sevigne 35576 630 FRANCE 632 Phone: (33) 2 99 12 70 23 633 Email: nicolas.montavont@enst-bretagne.fr 634 URI: http://www.rennes.enst-bretagne.fr/~montavont/ 636 Appendix A. Summary of Recommendations 638 It should be noted that many already deployed routers will not 639 support these recommendations, and that hosts SHOULD NOT rely on 640 their being in place, unless they have particular reason to do so. 642 Where many unicast responses are scheduled awaiting transmission, 643 Routers MAY consider aggregating them into a single multicast 644 response if a multicast advertisement may be sent before the 645 advertisements' scheduled transmission time. 647 Where multiple unicast transmissions for the same destination await 648 transmission, routers MAY remove all transmissions after the first 649 without ill-effect, if a multicast RA is scheduled for the next 650 possible response time. 652 Routers MAY choose to respond to RS messages with a unicast RA 653 response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS 654 restriction [1]. 656 Routers SHOULD be configured to advertise non-default Valid and 657 Preferred lifetimes in order to provide DNA hosts with link-specific 658 address lifetime information. 660 Where hosts with ongoing transactions, or well known services are 661 present on a network, this duration SHOULD be greater than the 662 maximum expected outage time. 664 Upon links where fixed hosts are unlikely to be present, 665 administrators SHOULD reduce the Router Lifetime, and Prefix Valid 666 and Preferred Lifetimes on routers used to support DNA. 668 The Router Lifetime MUST NOT be advertised as less than the 669 MaxRtrAdvInterval unless the router is not to be used as a default 670 [1]. 672 Routers MUST NOT be configured with Valid or Preferred lifetime 673 values lower than the MaxRtrAdvInterval. 675 Routers SHOULD include at least one global Prefix Information Option 676 in every Router Advertisement. 678 Routers SHOULD include Advertisement Interval options in Router 679 Advertisements. 681 Routers SHOULD advertise at least one global address consistently in 682 a Prefix Information Option, by setting the Router Address 'R' Flag. 684 A router MAY choose to split the options in the RA and send multiple 685 RAs to reduce bandwidth overhead or to reduce the size of the RA to 686 below the link MTU (see section 6.2.3 of [1]). 688 While transitions between links under different administrative 689 control are considered to be common, it is RECOMMENDED that network 690 deployers adopt uniform configuration practices across routers on 691 different links within the same logical domain, in order to provide 692 consistent performance. 694 Routers with interfaces whose technology is bridgeable SHOULD NOT 695 assume that all segments and devices on the link have the same 696 bandwidth available. 698 There SHOULD NOT be more than three (3) routers advertising on a 699 link. 701 If using advertising intervals lower than those specified in IPv6 702 Neighbour Discovery, only one router MAY advertise at the elevated 703 rate. Other routers beyond the first SHOULD NOT have 704 MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than 705 the minima specified in IPv6 Neighbour Discovery [1][3]. 707 Where it is possible, routers SHOULD include at least one common 708 prefix in all of their Router Advertisement messages. 710 Routers on point-to-point links MAY avoid delay by not waiting for 711 the prescribed random time before responding for the Router 712 Solicitation message [7] [9]. 714 Considering the computational cost for verifying certificates, 715 administrators SHOULD attempt to minimize the length of authorization 716 chains. 718 Where a Router Advertisement is sent by a router, it SHOULD contain 719 sufficient information to prove that the router is on the same link 720 as previously seen advertisers, or is indeed the same router. 722 Routers supporting DNA SHOULD provide secured router discovery 723 services using SEND [4]. 725 On access networks supporting Detecting Network Attachment, 726 administrators SHOULD configure routers to advertise at the shortest 727 safe intervals. 729 Appendix B. Router Advertisement Rates 731 Unsolicited Router Advertisements are scheduled to be transmitted at 732 a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last 733 multicast Router Advertisement. These parameters may be configured 734 in the way which best suits the network. The table below summarizes 735 the parameters as described by IPv6 Neighbour Discovery [1]. 737 +-----------------------+----+----+----+-----+----+-----+ 738 | Timer |Maximum |Default |Minimum | 739 +-----------------------+----+----+----+-----+----+-----+ 740 | MaxRtrAdvInterval | 1800 | 600 | 4 | 741 +-----------------------+----+----+----+-----+----+-----+ 742 | MinRtrAdvInterval | 594 | 198 | 3 | 743 +-----------------------+----+----+----+-----+----+-----+ 744 |Avg. Multicast RA time | 1197 | 399 | 3.5 | 745 +-----------------------+----+----+----+-----+----+-----+ 747 The load on the network, and the timeliness of any received 748 information updates are therefore influenced by the router's 749 advertisement parameters. 751 On access networks supporting Detecting Network Attachment, 752 administrators SHOULD configure routers to advertise at the shortest 753 safe intervals. Determination of the shortest safe intervals depends 754 on topology, and the composition of the link, as described in 755 Section 3.1. 757 Mobile IPv6 attempts to address the delays associated with hosts' 758 movement and change detection by reducing the minimum settings for 759 MinRtrAdvInterval to 30ms and MaxRtrAdvInterval to 70ms. Not all 760 IPv6 routers support these configuration values today. Where hosts 761 have no reactive way of detecting change, and do not solicit for 762 Router Advertisements, these intervals may allow change detection 763 sufficiently fast to support real-time applications. 765 The effect of these timers are summarized in the table below. 767 +-----------------------+----+----+----+-----+----+-----+ 768 | Timer |Maximum |Default |Minimum | 769 +-----------------------+----+----+----+-----+----+-----+ 770 | MaxRtrAdvInterval | 1800 | 600 | 0.07 | 771 +-----------------------+----+----+----+-----+----+-----+ 772 | MinRtrAdvInterval | 594 | 198 | 0.03 | 773 +-----------------------+----+----+----+-----+----+-----+ 774 |Avg. Multicast RA time | 1197 | 399 | 0.05 | 775 +-----------------------+----+----+----+-----+----+-----+ 777 Where Mobile IPv6 is supported, the minimum values change, but the 778 default timers are unmodified. If administrators wish to take 779 advantage of shorter intervals between unsolicited RAs, explicit 780 configuration is required. This is because the elevated rate of 781 multicast RA transmission can have detrimental effects on some 782 constrained links [3]. 784 The minimum average for un-solicited Router Advertisements would be 785 20 messages per second. Assuming the minimum packet size for an RA 786 with one prefix as 88 bytes, the bandwidth used will be 14 kbps. 787 With SEND Options, and (somewhat weak) 1024-bit RSA keys, a single RA 788 could be around 432 octets. This would consume approximately 69 kbps 789 without considering link-layer overheads [4]. 791 As described in Section 2.1, parameters may be chosen to optimize 792 solicited behaviour in a way which limits the mean bandwidth overhead 793 for unsolicited RAs. 795 A good example would be setting a MinRtrAdvInterval (along with 796 MinDelayBetweenRAs) as 0.5 s, and the MaxRtrAdvInterval to 4s. This 797 makes the mean delay before receiving an unsolicited RA 2.25 seconds, 798 and limits the bandwidth utilization for unsolicited RAs (using the 799 SEND example above) to 1.5 kbps, and the maximum multicast solicited 800 rate to 6.9 kbps (one multicast RA each 0.5s). 802 Intellectual Property Statement 804 The IETF takes no position regarding the validity or scope of any 805 Intellectual Property Rights or other rights that might be claimed to 806 pertain to the implementation or use of the technology described in 807 this document or the extent to which any license under such rights 808 might or might not be available; nor does it represent that it has 809 made any independent effort to identify any such rights. Information 810 on the procedures with respect to rights in RFC documents can be 811 found in BCP 78 and BCP 79. 813 Copies of IPR disclosures made to the IETF Secretariat and any 814 assurances of licenses to be made available, or the result of an 815 attempt made to obtain a general license or permission for the use of 816 such proprietary rights by implementers or users of this 817 specification can be obtained from the IETF on-line IPR repository at 818 http://www.ietf.org/ipr. 820 The IETF invites any interested party to bring to its attention any 821 copyrights, patents or patent applications, or other proprietary 822 rights that may cover technology that may be required to implement 823 this standard. Please address the information to the IETF at 824 ietf-ipr@ietf.org. 826 Disclaimer of Validity 828 This document and the information contained herein are provided on an 829 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 830 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 831 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 832 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 833 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 834 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Copyright Statement 838 Copyright (C) The Internet Society (2006). This document is subject 839 to the rights, licenses and restrictions contained in BCP 78, and 840 except as set forth therein, the authors retain all their rights. 842 Acknowledgment 844 Funding for the RFC Editor function is currently provided by the 845 Internet Society.