DNA Working Group S. Narayanan Internet-Draft Panasonic Expires: August 12, 2005 G. Daley Monash University CTIE N. Montavont LSIIT - ULP February 11, 2005 Detecting Network Attachment in IPv6 - Best Current Practices for Routers draft-narayanan-dna-routers-bcp-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 12, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Hosts experiencing rapid link-layer changes may require more frequent configuration change detection procedures than traditional fixed hosts. This document describes practices available to network deployers in order to support hosts Detecting Network Attachment in IPv6 networks. Narayanan, et al. Expires August 12, 2005 [Page 1] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 1.2 Relevant Host Issues . . . . . . . . . . . . . . . . . . . 3 1.3 Relevant Router Issues . . . . . . . . . . . . . . . . . . 4 1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Configuration Practices for DNAv6 Routers . . . . . . . . . . 5 2.1 Multicast and Unicast RA Responses . . . . . . . . . . . . 5 2.2 Analysis of the response time . . . . . . . . . . . . . . 6 2.3 Link-Layer Address Options . . . . . . . . . . . . . . . . 8 2.4 Router Advertisement Rates . . . . . . . . . . . . . . . . 9 2.5 Router Advertisement Parameters . . . . . . . . . . . . . 10 2.6 Router Advertisement Options . . . . . . . . . . . . . . . 11 2.7 Triggered Router Advertisements . . . . . . . . . . . . . 12 2.8 Split Advertisements . . . . . . . . . . . . . . . . . . . 12 2.9 Router Configurations . . . . . . . . . . . . . . . . . . 13 3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 13 3.1 Link Extent and Composition . . . . . . . . . . . . . . . 13 3.2 Wireless cell coverage . . . . . . . . . . . . . . . . . . 13 3.3 Multiple Router Links . . . . . . . . . . . . . . . . . . 14 3.4 Point-to-point Links . . . . . . . . . . . . . . . . . . . 15 3.5 Disjoint Administration . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.1 Supporting host security . . . . . . . . . . . . . . . . . 15 4.2 Providing Router Authorization . . . . . . . . . . . . . . 16 4.3 Neighbour Resolution for Unicast Response . . . . . . . . 17 4.4 Resource management . . . . . . . . . . . . . . . . . . . 17 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 5.2 Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 23 Narayanan, et al. Expires August 12, 2005 [Page 2] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 1. Introduction Hosts on the Internet may be connected by various media. It has become common that hosts have access through wireless media and are mobile, or have a variety of interfaces, which may be used to provide Internet connectivity. The frequency of configuration change for wireless and nomadic devices are elevated, due to the vagaries of wireless propagation or the motion of the hosts themselves. Such hosts need to determine if they have moved to a new IPv6 link rapidly, in order that configuration procedures may be run and application packet delivery services restored. Detecting Network Attachment (DNA) is a strategy to assist such configuration changes by rapidly determining whether they are required. Several network-side factors may impact on the effectiveness and speed of DNA procedures. This document provides guidelines embodying the best current practice for network deployers wishing to support detection of network attachment by IPv6 hosts. It should be noted that many already deployed routers will not support these recommendations, and that hosts SHOULD NOT rely on their being in place, unless they have particular reason to do so. 1.1 Terms and Abbreviations There is an existing DNA terminology draft [10]. At this stage, it is unclear if this draft or the mobility terminology [11] draft need to be referenced, or specific terms need to be placed in this document. While the mobility terminology draft may be applicable, the focus of this draft upon mobile hosts may be distracting for DNA. Comments on this issue are welcome. 1.2 Relevant Host Issues Hosts attempting to discover link change are likely to send Router Solicitations (RSs) in order to identify the routers and prefixes available on a link. Additionally, they may wish to send Neighbour Solicitations (NSs) to known routers for reachability detection purposes. The following is a list of critical issues for hosts undertaking link change detection in IPv6: Hosts require Router Advertisements (RAs) rapidly in order to minimize reconfiguration latencies in the case of link change. Narayanan, et al. Expires August 12, 2005 [Page 3] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 Hosts wish to identify if their currently configured prefix is present on a link. Existing IPv6 Neighbour Discovery procedures make this difficult as the Router Advertisement sent in response to the Router Solicitation message may not contain the prefix of interest for the host. Hosts wish to detect if a particular router is reachable in order to use it for routing. Hosts may require some assurance that a device is actually present, and is authorized to act as a router. Consideration for these issues underlie the practices recommended in this document. 1.3 Relevant Router Issues The IPv6 Neighbour Discovery RFC [1] provides mechanisms where hosts can send Router Solicitations and receive responding Router Advertisements, from each of the routers on a link. Responses may either be unicast or multicast, but in all cases, a random delay of between 0 and 500 milliseconds is scheduled before responses are sent. This is to prevent multiple routers responding at the same time, and also may mitigate the effects of simultaneous solicitations. This provides a basic time delay incurred by hosts receiving response RAs, which in almost all cases, cannot be avoided within current standards [1]. As described in Section 2.1, additional delays may occur if multicast responses are required. Router should also be careful not to increase the network overhead by frequently transmitting router advertisements. 1.4 Summary The practices embodied in this document are considered to provide minimal support for hosts wishing to detect network attachment. Current work within the DNA working group aims to provide substantially improved performance for link change detection. Existing limitations in base protocols such as IPv6 Neighbour Discovery preclude support of real-time applications in some environments. Future deployers and implementers are encouraged to consider the protocols under development at this time in order to provide a generic service to support hosts detecting change. Narayanan, et al. Expires August 12, 2005 [Page 4] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 2. Configuration Practices for DNAv6 Routers Routers which are being deployed to support hosts' change detection procedures should attempt to use appropriate configurations, which limit advertisement latency, and provide appropriate service considering the constraints of the deployed access network technology. This section describes several configuration parameters which may exist on IPv6 routers, and how their tuning may affect DNA hosts. 2.1 Multicast and Unicast RA Responses While IPv6 Neighbour Discovery assumes that responses to solicitations will be sent multicast, the specification allows routers to respond to RS message with a unicast RA if it desires [1]. The advantage in responding with an unicast RA message is to allow the IP host to conclusively infer bi-directional reachability from the RS-RA exchange. Neighbour Discovery does not provide any mechanism to match multicast RA responses with their solicitation, and therefore it is not possible for the hosts to find out whether at least one of its RS messages was received and processed by the router. Since unicast RAs are almost always sent in response to solicitation, a host can infer that at least one of its Router Solicitations reached the router. The dis-advantage in sending unicast RA is that the router will not be able to aggregate its response for multiple RS messages form multiple hosts received during the wait period. Where many unicast responses are scheduled awaiting transmission, Routers MAY consider aggregating them into a single multicast response if a multicast advertisement may be sent before the advertisements' scheduled transmission time. It is noted that computational requirements for SEND may preclude this subsequent aggregation in some environments. Where multiple unicast transmissions for the same destination await transmission, routers MAY remove all transmissions after the first without ill-effect, if a multicast RA is scheduled for the next possible response time. For multicast Router Advertisements, a minimum separating delay exists so that these RAs may not be scheduled close to each other. When a host solicits and attempts to schedule a multicast RA within MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of Narayanan, et al. Expires August 12, 2005 [Page 5] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 the previous multicast Router Advertisement, the scheduling of a response will be deferred until the minimum separation expires. This separation delay does not affect unicast Router Advertisement responses. Routers MAY choose to respond to RS messages with a unicast RA response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS restriction [1]. In some cases it is not possible to provide unicast responses, since solicitations may be sent with an unspecified address, or solicitations do not provide enough link-layer addressing information to send an unicast response without neighbour discovery exchange. In these cases, a router may need to send multicast responses, even if the expected delay is greater. 2.2 Analysis of the response time In IPv6 Neighbour Discovery, the delay induced by the MIN_DELAY_BETWEEN_RAS restriction is up to 3 seconds. This delay may not be very high if the minimum value (MinDelayBetweenRAs=0.03s) suggested in Mobile IPv6 is implemented [3]. The fraction of time which MinDelayBetweenRAs occupies in the Router Advertisement interval determines the probability of scheduling delay. Assuming that the arrival of RS messages is independent of each other, and that the arrival of any particular RS is equally likely across an interval, The probability of delay occurring to a particular RS is: P_mcdelay = MinDelayBetweenRAs ---------------------------- (MinRtrAdvInterval + MaxRtrAdvInterval)/2 Where the mean interval is defined as the mean delay before scheduling an unsolicited Router Advertisement. The probability of delay with routers using the minimum values from IPv6 Neighbour Discovery is: 0.851 [1] Considering the above values, it is also necessary to remember that all responses will be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 s) [1]. In this case, the expected delay E_mcrsra for a single arriving RS is: Narayanan, et al. Expires August 12, 2005 [Page 6] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 E_mcrsra = P_mcdelay * MinDelayBetweenRAs/2 + MAX_RA_DELAY_TIME/2 Again for RFC2461 minima, the expected delay is thus: 1.535 s. The average unicast RA response time of course is 0.250 seconds. Assumptions underpinning this approximation hold only if the likelihood of more than one RS arriving within a multicast delay interval is very low. This depends on the arrival rate (lambda) of Router Solicitations, and is based on a Poisson distribution. The probability of more than one RS arriving in the interval t of MinDelayBetweenRAs (defaulting to MIN_DELAY_BETWEEN_RAS) is: P[X(t) > 1] = 1 - P[X(t) == 1] - P[X(t) == 0] = 1 - (lambda*t)*exp(-lambda*t)/1! - exp(-lambda*t)/0! = 1 - ( 1 + lambda*t)* exp (-lambda*t) For a given load (lambda)=0.05 RS/sec, the probability of multiple RS arrival is 1.01%. Adopting the MinDelayBetweenRAs = 0.03s and MaxRtrAdvinterval= 4s the probability of arrival in the MinDelayBetweenRAs interval is 0.0148. The estimated expected delay for multicast RS/RA exchange is therefore 0.25022 seconds. This is comparable to the unicast response delay. In this case, the chance of additional solicitation arrival during MinDelayBetweenRAs is very low (around 1 in 10^6 for t=0.03, lambda=0.05). Please note that if the MaxRtrAdvInterval is also low (making the mean interval duration low), the solicitor is likely to get get an unsolicited RA due to early scheduling of the RA during the RS/RA delay period (see Section 2.4). As described in [3], some systems may not provide tunable MinDelayBetweenRAs except that it assumes the value of the minimum time difference between unsolicited RAs (MinRtrAdvInterval) when MinRtrAdvInterval is less than 3 seconds. Reducing MinRtrAdvInterval to will increase the rate of RA transmission, but this doesn't need to be a dramatic increase. For example, even if the lowest value for MinRtrAdvInterval is selected (0.03 s), if the MaxRtrAdvInterval is Narayanan, et al. Expires August 12, 2005 [Page 7] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 kept at its RFC2461 minimum (4 seconds) the mean interval between RAs is over 2 seconds. This compares with a mean interval of 3.5 seconds for advertisement only using the RFC2461 minima. Where the MinDelayBetweenRAs is correspondingly lowered to the minimum values, the rate of solicited multicast RAs may be elevated to around 33 per second. This raises the potential for abuse by attackers which can force uniform resource consumption across all cells in a link. It is possible to choose delay values which provide significantly improved expected and worst case delays over RFC 2461 values, and have well defined upper bound traffic costs for constrained links. For example, if a link is able to sustain a maximum of two multicast RAs per second, a safe value for MinRtrAdvInterval and consequently MinDelayBetweenRAs is t=0.5s. With similar load values to those presented above, the probability of arrival within the interval P_mcdelay = 0.222, with an expected RS/RA delay of E_mcrsra = 0.305s. As mentioned above the probability of multiple RS arrival in the interval would be 3.07 * 10^-4 with a load (lambda)=0.05. This MinDelayBetweenRAs allows fairly good multicast response performance but bounds the number of multicast RAs to two per second. Regardless of load, the worst case delay for RA response in this case is no greater than 2*MIN_DELAY_BETWEEN_RAs (1 second). 2.3 Link-Layer Address Options While IPv6 Neighbour Discovery indicates that Router Solicitations SHOULD contain Source Link-Layer Address options on links where link-layer addresses are used, it is still valid to receive and process RSs without them. Recent standardization efforts to improve IPv6 address configuration delays rely upon this capability in order to send solicitations from a specified source address before Duplicate Address Detection completion [12][5]. As hosts attempt to detect network attachment, it is likely that they will adopt these procedures in order to safely undertake router discovery without causing damage to peers' neighbour cache entries. Use of link-layer address options in Router Solicitations while checking addresses can damage neighbour reachability for the real address owner by overwriting the router's neighbour cache entry for the address. Router Solicitations sent to comply with Optimistic Duplicate Address Detection will therefore not contain link-layer Narayanan, et al. Expires August 12, 2005 [Page 8] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 address options [12]. These RSs will not create valid neighbour cache entries. If there is a valid neighbour cache entry for the solicitor's address a response MAY be unicast directly to that address. If there is no neighbour cache entry, the router MAY start neighbour discovery for the host, if it wishes to send a unicast response. This requires an additional bidirectional exchange to be adopted by the router and the sender of the Router Solicitation. Additional packet exchanges for neighbour discovery may pose a threat to routers and bandwidth resources. This is further described in Section 4.3. 2.4 Router Advertisement Rates Unsolicited Router Advertisements are scheduled to be transmitted at a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last multicast Router Advertisement. These parameters may be configured in the way which best suits the network. The table below summarizes the parameters as described by IPv6 Neighbour Discovery [1]. +-----------------------+----+----+----+-----+----+-----+ | Timer |Maximum |Default |Minimum | +-----------------------+----+----+----+-----+----+-----+ | MaxRtrAdvInterval | 1800 | 600 | 4 | +-----------------------+----+----+----+-----+----+-----+ | MinRtrAdvInterval | 594 | 198 | 3 | +-----------------------+----+----+----+-----+----+-----+ |Avg. Multicast RA time | 1197 | 399 | 3.5 | +-----------------------+----+----+----+-----+----+-----+ The load on the network, and the timeliness of any received information updates are therefore influenced by the router's advertisement parameters. On access networks supporting Detecting Network Attachment, administrators SHOULD configure routers to advertise at the shortest safe intervals. Determination of the shortest safe intervals depends on topology, and the composition of the link, as described in Section 3.1. Mobile IPv6 attempts to address the delays associated with hosts' movement and change detection by reducing the minimum settings for MinRtrAdvInterval to 30ms and MaxRtrAdvInterval to 70ms. Not all IPv6 routers support these configuration values today. Where hosts have no reactive way of detecting change, and do not solicit for Narayanan, et al. Expires August 12, 2005 [Page 9] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 Router Advertisements, these intervals may allow change detection sufficiently fast to support real-time applications. The effect of these timers are summarized in the table below. +-----------------------+----+----+----+-----+----+-----+ | Timer |Maximum |Default |Minimum | +-----------------------+----+----+----+-----+----+-----+ | MaxRtrAdvInterval | 1800 | 600 | 0.07 | +-----------------------+----+----+----+-----+----+-----+ | MinRtrAdvInterval | 594 | 198 | 0.03 | +-----------------------+----+----+----+-----+----+-----+ |Avg. Multicast RA time | 1197 | 399 | 0.05 | +-----------------------+----+----+----+-----+----+-----+ Where Mobile IPv6 is supported, the minimum values change, but the default timers are unmodified. If administrators wish to take advantage of shorter intervals between unsolicited RAs, explicit configuration is required. This is because the elevated rate of multicast RA transmission can have detrimental effects on some constrained links [3]. The minimum average for un-solicited Router Advertisements would be 20 messages per second. Assuming the minimum packet size for an RA with one prefix as 88 bytes, the bandwidth used will be 14 kbps. With SEND Options, and (somewhat weak) 1024-bit RSA keys, a single RA could be around 432 octets. This would consume approximately 69 kbps without considering link-layer overheads [4]. As described in Section 2.1, parameters may be chosen to optimize solicited behaviour in a way which limits the mean bandwidth overhead for unsolicited RAs. A good example would be setting a MinRtrAdvInterval (along with MinDelayBetweenRAs) as 0.5 s, and the MaxRtrAdvInterval to 4s. This makes the mean delay before receiving an unsolicited RA 2.25 seconds, and limits the bandwidth utilization for unsolicited RAs (using the SEND example above) to 1.5 kbps, and the maximum multicast solicited rate to 6.9 kbps (one multicast RA each 0.5s). 2.5 Router Advertisement Parameters Where hosts have changeable connectivity, there may be a number of prefixes or routers stored in the host's memory, which are no longer directly reachable. This additional storage may cause harm where hosts rapidly pass through networks, or pass through networks which have very long advertised timeouts. Narayanan, et al. Expires August 12, 2005 [Page 10] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 Routers SHOULD be configured to advertise non-default Valid and Preferred lifetimes in order to provide DNA hosts with link-specific address lifetime information. Administrators are advised to set the advertised Preferred and Valid timers of prefixes to the maximum duration for which any host may be required to continue functioning without receiving a particular advertised prefix. Where hosts with ongoing transactions, or well known services (such as DNS) are present on a network, this duration SHOULD be greater than the maximum expected outage time (for example 9 hours for 0.999 uptime, with a single outage/year). Upon links where fixed hosts are unlikely to be present, administrators SHOULD reduce the Router Lifetime, and Prefix Valid and Preferred Lifetimes on routers used to support DNA. One potential configuration heuristic would be to configure lifetimes to be a low number (for example: 15) of times the MaxRtrAdvInterval, or greater than the lower quartile cell residence time of hosts on the network (if known). This allows reuse of configuration in the case where hosts are moving back and forth rapidly between links, but allows rapid timeouts of old configurations. The Router Lifetime MUST NOT be advertised as less than the MaxRtrAdvInterval unless the router is not to be used as a default [1]. Routers MUST NOT be configured with Valid or Preferred lifetime values lower than the MaxRtrAdvInterval. These minima ensure that lifetimes do not expire in between periodic Router Advertisements. 2.6 Router Advertisement Options When receiving a Router Advertisement from a particular router for the first time, a host needs to determine if the information contained in the RA indicates link change or that the transmitting router is part of the same link as another router it has already seen. It is not possible to do this unless global prefix information is included in the advertisement. Routers SHOULD include at least one global Prefix Information Option in every Router Advertisement. Mobile IPv6 introduced a new option for Router Advertisements, which Narayanan, et al. Expires August 12, 2005 [Page 11] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 indicates the current MaxRtrAdvInterval of router [3]. Reception of this option allows hosts to estimate whether they have missed Router Advertisements, and allows them to check reachability or discover new routers. Routers SHOULD include Advertisement Interval options in Router Advertisements. Mobile IPv6 adds the Router Address 'R' Flag to Prefix Information options [3]. This flag, when set indicates that the router's entire global address is configured and sent in the prefix information option. Bits beyond those specified in the prefix length field identify the router's Interface Identifier [6]. Hosts which are detecting network attachment can use the global router address to uniquely identify the router and link, rather than using link-local source addresses, which may be present on multiple links. Routers SHOULD advertise at least one global address consistently in a Prefix Information Option, by setting the Router Address 'R' Flag. 2.7 Triggered Router Advertisements There are proposals for IPv6 Router Advertisements to be sent to hosts based on network side link-layer information. Where these mechanisms exist they can provide Router Advertisements in the quickest possible time without need for Router Solicitation. These systems rely upon link-layer facilities are not available in all environments. Therefore, interested readers are referred to the individual methods' documentation [15]. 2.8 Split Advertisements A router may choose to split the options in the RA and send multiple RAs to reduce bandwidth overhead or to reduce the size of the RA to below the link MTU (section 6.2.3 of [1]). If such a choice is made, average multicast RA time discussed in Section 2.4 increases for each subset of the prefixes included in the split RA messages. Routers SHOULD consistently include one prefix in both sets of its RA messages. This provide the host with a unique identifier based on the combination of link-local address and the constant prefix, to identify the router every time a RA message is received. Narayanan, et al. Expires August 12, 2005 [Page 12] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 2.9 Router Configurations Each router can have its own configuration with respect to sending RAs, and the treatment of router and neighbour solicitations. Different timers and constants might be used by different routers, such as the delay between Router Advertisements or delay before replying to a multicast RS. If a host is changing its IPv6 link, a newly seen router on that link may have a different configuration and may introduce more delay than the previous default router of the host. While transitions between links under different administrative control are considered to be common, it is RECOMMENDED that network deployers adopt uniform configuration practices across routers on different links within the same logical domain, in order to provide consistent performance. 3. Topological Practices for DNAv6 Networks IPv6 does not prefer one particular network topology over another and allows multiple routers and subnet prefixes to exist on one link. Different deployments of network elements and their configuration may impact on link change detection though. Effects and recommended practices for dealing with different network topologies are presented below. 3.1 Link Extent and Composition Most of today's access networks deploy link-layer bridging technologies in order to extend their logical range beyond a single Medium Access Control domain. Consequently, while many routers will come with traditional wired or optic-fibre interfaces, packets travelling within the same link may have been bridged across from a wired segment to a wireless segment. In many of cases, the router will not have accurate information about the transmission rates or media of particular segments on the link. Routers with interfaces whose technology is bridgeable SHOULD NOT assume that all segments and devices on the link have the same bandwidth available. 3.2 Wireless cell coverage Where the topology of a set of access networks is known to have a single cell per link or subnet, IPv6 hosts may immediately solicit for Router Advertisements upon notification of cell change. If link design is also constrained to a single router per cell, RA response Narayanan, et al. Expires August 12, 2005 [Page 13] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 delays may be reduced as described in Section 3.4. Where link design is not constrained, many cells may exist within the same link. The scalability of a subnet in terms of wireless cell coverage is likely to be limited by broadcast/multicast traffic between hosts on the link. Where multicast packets may pass from one cell to another in the link (even if no multicast listeners for the group exist), constrained wireless segments' performance may become degraded. In this case, it may be necessary to deploy multicast snooping or split the link into smaller broadcast domains [13]. 3.3 Multiple Router Links IPv6 Neighbour Discovery allows multiple routers to be advertising on the same link [1]. These routers are not required to advertise the same prefixes as each other. This section provides some guidelines for deploying multiple routers on the same link. While many routers may exist on a link, it is preferable to limit the number of advertising routers. There SHOULD NOT be more than three (3) routers advertising on a link. This will provide robustness in the case of RA packet loss, but provides a bound for bandwidth consumption. Multiple routers responding to Router Solicitation will reduce the mean delay for solicitation, at the cost of additional traffic. For unicast responses, the delays may be halved for three responding routers. +-----------------------+---------+----------+----------+ |Num advertising routers| 1 | 2 | 3 | +-----------------------+---------+----------+----------+ |Expected Unicast Delay | 0.250s | 0.167s | 0.125s | +-----------------------+---------+----------+----------+ If using advertising intervals lower than those specified in IPv6 Neighbour Discovery, only one router MAY advertise at the elevated rate. Other routers beyond the first SHOULD NOT have MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than the minima specified in IPv6 Neighbour Discovery [1][3]. Where it is possible, routers SHOULD include at least one common prefix in all of their Router Advertisement messages. This allows hosts to immediately see that both routers are on the same link. Narayanan, et al. Expires August 12, 2005 [Page 14] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 3.4 Point-to-point Links IPv6 Router Discovery mandates the delay of RA responses by stating (in section 6.2.6 of [1]): "In all cases, Router Advertisements sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME seconds." Cases where the router is on a point-to-point link, this restriction is too stringent as the router in question will be the only router on the link. Routers on such point-to-point links MAY avoid the delay by not waiting for the prescribed random time before responding for the Router Solicitation message [8][14]. 3.5 Disjoint Administration Where multiple sets of routers administered by different organizations advertise on a link, it is RECOMMENDED that at least one prefix is advertised in common between all sets. This helps to ensure that the routers do not appear to be different links. Routers administered by different organizations are likely to have different trust models, especially for routing and renumbering. This may prevent alien routers from learning about changes in configuration. Deployers SHOULD be aware that advertisement of prefixes for which a router does not have up-to-date address validity and lifetime data can cause problems for hosts if some routers cease advertising a prefix and others don't. Where up-to-date prefix configuration information is not available, routers SHOULD NOT advertise the prefix. 4. Security Considerations When operating a network in support of hosts performing link change detection, both the operational security of the hosts and network infrastructure are important. DNA procedures rely upon rapid delivery of information to hosts using IPv6 Neighbour Discovery. Neighbour Discovery as a critical service in IPv6 networks is subject to various attacks as described in [7]. The following sections describe issues and practices to provide additional functional security for both operators and hosts. 4.1 Supporting host security In DNA, some hosts will begin configuration procedures based on a single message transmitted by a router. As such the ability of Narayanan, et al. Expires August 12, 2005 [Page 15] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 routing infrastructure to prove its authenticity and authorization is important to support correct operation of hosts. As described in Section 4.2, authentication and authorization mechanisms exits which allow hosts to check security of routers when they receive Router Advertisements indicating link change. Today these mechanisms require additional message exchanges and public key operations to check the authorization chain back to a trusted root. Considering the computational cost for verifying certificates, administrators SHOULD attempt to minimize the length of these authorization chains. Where a Router Advertisement is sent by a router, it SHOULD contain sufficient information to prove that the router is on the same link as previously seen advertisers, or is indeed the same router. This may prevent expensive checks by hosts which will not need to immediately test the authenticity of the router through signature verification, or additional transmissions. The simplest way to do this today is to include a common global prefix in all Router Advertisements by routers on a link. 4.2 Providing Router Authorization Hosts which wish to have secured exchanges with neighbours and on-link routers may use Secured Neighbour Discovery (SEND) [4]. SEND provides authenticity as well as response matching, using nonces copied from solicitations into advertisements. Responses which contain Nonces may be matched to one or more solicitations (dependent on the number of Nonce Options contained in the Advertisement), and may be used to provide authenticated bidirectional reachability confirmation even if received in a multicast advertisement. The router digitally signs its advertisements with a key-pair which was also used to generate the router's transmitting address. This guarantees the origin, as well as the freshness of the Router Advertisement transmission. DNA relies particularly heavily upon router discovery in order to test the validity of routing and addressing configuration. In addition to reachability and configuration parameters, routing authorization needs to be determined for each router. In SEND [4], routing authorization is delegated by certificate authorities. SEND Router Advertisement packets contain the router's public key from a key pair used to sign the message. Certificate authorities Narayanan, et al. Expires August 12, 2005 [Page 16] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 delegate a portion of their routing authority to the router, tying them to the public key of the router. Hosts need to test the router's authority to provide routing for the prefixes advertised in its RAs in order to ensure safe configuration. Routers supporting DNA SHOULD provide secured router discovery services using SEND [4]. While it may be onerous to organize and manage key distribution and certificates for routing authorization, the security and robustness afforded by secured neighbour discovery provides a key advantage for IPv6 networks over what is available in IPv4. 4.3 Neighbour Resolution for Unicast Response Where a received Router Solicitation contains insufficient information to create a valid neighbour cache entry, routers may need to perform neighbour discovery if they wish to provide a unicast Router Advertisement response. In this case, it is possible to both make the router (and any existent host at the RS's source address) send additional messages, and consume memory resources with bogus neighbour cache entries. When using SEND, the cost of generating bogus addresses and sending signed messages is likely to mitigate the potential for abuse. Regardless, a router MAY send a multicast Router Advertisement response to Router Solicitations without Source Link-Layer Address Option in order to avoid neighbour cache entry creation. 4.4 Resource management Processing and transmitting messages underlie the role of routers supporting DNA. When performing these tasks though, routers need to be configured so that they protect their own memory and computation resources. It may be necessary to ensure that as the rate of solicitations (and the number of corresponding neighbour cache entries) increases, cache replacement strategies favour removal of least recently used entries which are not confirmed as being reachable. Such a strategy SHOULD ensure that new neighbour cache entries may be made by guaranteeing sufficient space in which to gain responses for legitimate devices. Router SHOULD also ensure that along with other routers on the link, they do not overwhelm the bandwidth of the link, or induce excessive (application affecting) delay variations on constrained links. IPv6 Neighbour Discovery does not specify any rate limitation for unicast Narayanan, et al. Expires August 12, 2005 [Page 17] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 responses to Router Solicitations. Computational loads for IPv6 Neighbour Discovery processing on routers are very low, with limited state being kept for each solicitor. Where SEND is in use, attacks against computation resources may be prevalent. As described in [4] rate limitation MAY be used to limit the effects of CPU cycle stealing attacks. 5. References 5.1 Normative References [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 (work in progress), April 2004. 5.2 Informative References [5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [9] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999. [10] Yamamoto, S., "Detecting Network Attachment Terminology", draft-yamamoto-dna-term-00 (work in progress), February 2004. [11] Manner, J. and M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-06 (work in progress), Narayanan, et al. Expires August 12, 2005 [Page 18] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 February 2004. [12] Moore, N., "Optimistic Duplicate Address Detection for IPv6", draft-ietf-ipv6-optimistic-dad-02 (work in progress), September 2004. [13] Christensen, M., Kimball, K. and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11 (work in progress), May 2004. [14] "3GPP TS 29.061 V5.5.0 (2003-03) Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) (Release 5)", TS 29.061, March 2003. [15] Choi, J., "Fast Router Discovery with RA Caching", draft-jinchoi-dna-frd-00 (work in progress), July 2004. Authors' Addresses Sathya Narayanan Panasonic Digital Networking Lab Two Research Way, 3rd Floor Princeton, NJ 08536 USA Phone: 609 734 7599 EMail: sathya@Research.Panasonic.COM URI: Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical adn Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 EMail: greg.daley@eng.monash.edu.au Narayanan, et al. Expires August 12, 2005 [Page 19] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 Nicolas Montavont LSIIT - Univerity Louis Pasteur Pole API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 EMail: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Appendix A. Summary of Recommendations It should be noted that many already deployed routers will not support these recommendations, and that hosts SHOULD NOT rely on their being in place, unless they have particular reason to do so. Where many unicast responses are scheduled awaiting transmission, Routers MAY consider aggregating them into a single multicast response if a multicast advertisement may be sent before the advertisements' scheduled transmission time. Where multiple unicast transmissions for the same destination await transmission, routers MAY remove all transmissions after the first without ill-effect, if a multicast RA is scheduled for the next possible response time. Routers MAY choose to respond to RS messages with a unicast RA response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS restriction [1]. If there is a valid neighbour cache entry for the solicitor's address a response MAY be unicast directly to that address, even if the RS did not contain a Source Link-Layer address. If there is no neighbour cache entry, the router MAY start neighbour discovery for the host, if it wishes to send a unicast RA response. On access networks supporting Detecting Network Attachment, administrators SHOULD configure routers to advertise at the shortest safe intervals. Routers SHOULD be configured to advertise non-default Valid and Preferred lifetimes in order to provide DNA hosts with link-specific address lifetime information. Where hosts with ongoing transactions, or well known services are present on a network, this duration SHOULD be greater than the Narayanan, et al. Expires August 12, 2005 [Page 20] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 maximum expected outage time. Upon links where fixed hosts are unlikely to be present, administrators SHOULD reduce the Router Lifetime, and Prefix Valid and Preferred Lifetimes on routers used to support DNA. The Router Lifetime MUST NOT be advertised as less than the MaxRtrAdvInterval unless the router is not to be used as a default [1]. Routers MUST NOT be configured with Valid or Preferred lifetime values lower than the MaxRtrAdvInterval. Routers SHOULD include at least one global Prefix Information Option in every Router Advertisement. Routers SHOULD include Advertisement Interval options in Router Advertisements. Routers SHOULD advertise at least one global address consistently in a Prefix Information Option, by setting the Router Address 'R' Flag. A router MAY choose to split the options in the RA and send multiple RAs to reduce bandwidth overhead or to reduce the size of the RA to below the link MTU (see section 6.2.3 of [1]). While transitions between links under different administrative control are considered to be common, it is RECOMMENDED that network deployers adopt uniform configuration practices across routers on different links within the same logical domain, in order to provide consistent performance. Routers with interfaces whose technology is bridgeable SHOULD NOT assume that all segments and devices on the link have the same bandwidth available. There SHOULD NOT be more than three (3) routers advertising on a link. If using advertising intervals lower than those specified in IPv6 Neighbour Discovery, only one router MAY advertise at the elevated rate. Other routers beyond the first SHOULD NOT have MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than the minima specified in IPv6 Neighbour Discovery [1][3]. Where it is possible, routers SHOULD include at least one common prefix in all of their Router Advertisement messages. Narayanan, et al. Expires August 12, 2005 [Page 21] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 Routers on point-to-point links MAY avoid delay by not waiting for the prescribed random time before responding for the Router Solicitation message [8][14]. Where multiple sets of routers administered by different organizations advertise on a link, it is RECOMMENDED that at least one prefix is advertised in common between all sets. Deployers SHOULD be aware that advertisement of prefixes for which a router does not have up-to-date address validity and lifetime data can cause problems for hosts if some routers cease advertising a prefix and others don't. Where up-to-date prefix configuration information is not available, routers SHOULD NOT advertise the prefix. Considering the computational cost for verifying certificates, administrators SHOULD attempt to minimize the length of authorization chains. Where a Router Advertisement is sent by a router, it SHOULD contain sufficient information to prove that the router is on the same link as previously seen advertisers, or is indeed the same router. Routers supporting DNA SHOULD provide secured router discovery services using SEND [4]. A router MAY send a multicast Router Advertisement response to Router Solicitations without Source Link-Layer Address Option in order to avoid neighbour cache entry creation. Cache replacement strategies favour removal of least recently used entries SHOULD ensure that new neighbour cache entries may be made by guaranteeing sufficient space in which to gain responses for legitimate devices. Routers SHOULD also ensure that along with other routers on the link, they do not overwhelm the bandwidth of the link, or induce excessive (application affecting) delay variations on constrained links. Where SEND is in use, attacks against computation resources may be prevalent. As described in [4] rate limitation MAY be used to limit the effects of CPU cycle stealing attacks. Narayanan, et al. Expires August 12, 2005 [Page 22] Internet-Draft BCP for Network Deployment with DNAv6 February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan, et al. Expires August 12, 2005 [Page 23]