draft-ietf-dna-routers-00.txt		draft-ietf-dna-hosts-01.txt
DNA Working Group S. Narayanan		DNA Working Group S. Narayanan
Internet-Draft Panasonic		Internet-Draft Panasonic
Expires: December 25, 2005 G. Daley		Expires: December 25, 2005 G. Daley
Monash University CTIE		Monash University CTIE
N. Montavont		N. Montavont
LSIIT - ULP		LSIIT - ULP
June 23, 2005		June 23, 2005
Detecting Network Attachment in IPv6 - Best Current Practices for		Detecting Network Attachment in IPv6 - Best Current Practices for hosts.
Routers		draft-ietf-dna-hosts-01.txt
draft-ietf-dna-routers-00.txt
Status of this Memo		Status of this Memo
By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
Skipping to change at page 1, line 46:
http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2005.		This Internet-Draft will expire on December 25, 2005.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
Abstract		Abstract
Hosts experiencing rapid link-layer changes may require to do		Hosts experiencing rapid link-layer changes may require efficient IP
configuration change detection procedures more frequently than		configuration change detection procedures than traditional fixed
traditional fixed hosts. This document describes practices available		hosts. DNA is defined as the process by which a host collects
to network deployers in order to support such hosts in Detecting		appropriate information and detects the identity of its currently
Network Attachment in IPv6 networks.		attached link to ascertains the validity of its IP configuration.
		This document details best current practice for Detecting Network
		Attachment in IPv6 hosts using existing Neighbor Discovery
		procedures. Since there is no explicit link identification mechanism
		in the existing Neighbor Discovery for IP Version 6, the document
		describes implicit mechanisms for identifying the current link.
Table of Contents		Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3		1.1 Structure of this Document . . . . . . . . . . . . . . . . 5
1.2 Relevant Host Issues . . . . . . . . . . . . . . . . . . . 4
1.3 Relevant Router Issues . . . . . . . . . . . . . . . . . . 4
1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Configuration Practices for DNAv6 Routers . . . . . . . . . . 5		2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
2.1 Multicast and Unicast RA Responses . . . . . . . . . . . . 5
2.1.1 Recommendations . . . . . . . . . . . . . . . . . . . 7
2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7
2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8
2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8
2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9
2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9
2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9
2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10
3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10		3. Background & Motivation for DNA . . . . . . . . . . . . . . . 6
3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10		3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Wireless cell coverage . . . . . . . . . . . . . . . . . . 10
3.3 Multiple Router Links . . . . . . . . . . . . . . . . . . 11
3.4 Point-to-point Links . . . . . . . . . . . . . . . . . . . 12
3.5 Disjoint Administration . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 7
4.1 Supporting host security . . . . . . . . . . . . . . . . . 12		4.1 Making use of Prior Information . . . . . . . . . . . . . 7
4.2 Providing Router Authorization . . . . . . . . . . . . . . 13		4.2 Duplicate Address Detection . . . . . . . . . . . . . . . 8
		4.3 Link identification . . . . . . . . . . . . . . . . . . . 9
		4.3.1 Same link . . . . . . . . . . . . . . . . . . . . . . 9
		4.3.2 Link change . . . . . . . . . . . . . . . . . . . . . 10
		4.4 Multicast Listener State . . . . . . . . . . . . . . . . . 10
		4.5 Reachability detection . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11
5.1 Normative References . . . . . . . . . . . . . . . . . . . 14		5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12
5.2 Informative References . . . . . . . . . . . . . . . . . . 14		5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12
		5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 13
		5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13
		5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 14
		5.6 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 14
		5.7 Hint Management for Inactive Hosts . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15		6. IP Hosts Configuration . . . . . . . . . . . . . . . . . . . . 15
		6.1 Router and Prefix list . . . . . . . . . . . . . . . . . . 15
		6.2 IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 16
		6.2.1 Autoconfiguration . . . . . . . . . . . . . . . . . . 16
		6.2.2 Dynamic Host Configuration . . . . . . . . . . . . . . 16
		6.3 Neighbor cache . . . . . . . . . . . . . . . . . . . . . . 17
		6.4 Mobility Management . . . . . . . . . . . . . . . . . . . 17
A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 16		7. Complications to Detecting Network Attachment . . . . . . . . 18
		7.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18
		7.2 Router Configurations . . . . . . . . . . . . . . . . . . 18
		7.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 18
		7.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 19
		7.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 19
B. Analysis of the response time . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
		8.1 Authorization and Detecting Network Attachment . . . . . . 20
		8.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20
C. Router Advertisement Rates . . . . . . . . . . . . . . . . . . 20		9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 21
		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
		11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
		11.2 Informative References . . . . . . . . . . . . . . . . . . 22
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
		A. Example State Transition Diagram . . . . . . . . . . . . . . . 24
		Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction		1. Introduction
Hosts on the Internet may be connected by various media. It has		When operating in changing environments, IPv6 hosts may experience
become common that hosts have access through wireless media and are		variations in reachability or configuration state over time. For
mobile. The frequency of configuration change for wireless and		hosts accessing the Internet over wireless media, such changes may be
nomadic devices are elevated, due to the vagaries of wireless		caused by changes in wireless propagation or host motion.
propagation or the motion of the hosts themselves.
Such hosts need to determine if they have moved to a new IPv6 link		Detecting Network Attachment (DNA) in IPv6 is the task of checking
rapidly, in order that configuration procedures may be run and		for changes in the validity of a host's IP configuration [15].
application packet delivery services restored. Detecting Network		Changes may occur on establishment or disconnection of a link-layer.
Attachment (DNA) is a strategy to assist such configuration changes		For newly connected interfaces, they may be on a link different from
by rapidly determining whether they are required.		the existing configuration of the node.
Several network-side factors may impact on the effectiveness and		In these and other cases, IP addressing and default routing
speed of DNA procedures. This document provides guidelines embodying		configuration of the node may become invalid preventing packet
the best current practice for network deployers wishing to support		transfer. DNA uses IPv6 Neighbour Discovery to provide information
detection of network attachment by IPv6 hosts.		about the reachability and identity of the link.
It should be noted that many already deployed routers will not		DNA focuses on determining whether the current configuration is
support these recommendations, and that hosts SHOULD NOT rely on		valid, leaving the actual practice of re-configuration to other
their being in place, unless they have particular reason to do so.		subsystems, if the current configuration is invalid.
1.1 Terms and Abbreviations		This document presents the best current practices for IPv6 hosts to
		address the task of Detecting Network Attachment in changing and
		wireless environments.
		1.1 Structure of this Document
		Section 3 of this document provides background and motivation for
		Detecting Network Attachment.
		Elaboration of specific practices for hosts in detecting network
		attachment continues in Section 4, while Section 5 discuss the
		initiation of DNA procedures.
		Section 6 describes interactions with other protocols, particularly
		upon link-change, while Section 7 describes environmental challenges
		to detection of network attachment.
		Section 8 provides security considerations, and details a number of
		issues which arise due to wireless connectivity and the changeable
		nature of DNA hosts' Internet connections.
		2. Terms and Abbreviations
Access network: A network where hosts are present. Especially, a		Access network: A network where hosts are present. Especially, a
network used for the support of visiting wireless hosts.		network used for the support of visiting wireless hosts.
		Attachment: The process of entering a new cell. Attachment (and
		detachment) may cause a link-change.
		Cell: A system constituted by the propagation range of a wireless
		base station and its serviced hosts. Dependent on topology, one
		or many cells may be part of the same link.
		Hint: An indication from other subsystems or protocol layers that
		link-change may have occurred.
Link: A link is the range across which communications can pass		Link: A link is the range across which communications can pass
without being forwarded through a router [1].		without being forwarded through a router [1].
Link-Change: Link-Change occurs when a host moves from a point-of-		Link-Change: Link-Change occurs when a host moves from a point-of-
attachment on a link, to another point-of-attachment where it is		attachment on a link, to another point-of-attachment where it is
unable to reach devices belonging to the previous link, without		unable to reach devices belonging to a link, without being
being forwarded through a router.		forwarded through a router.
Point-of-Attachment: A link-layer base-station, VLAN or port through		Point-of-Attachment: A link-layer base-station, VLAN or port through
which a device attempts to reach the network. Changes to a		which a device attempts to reach the network. Changes to a
host's point-of-attachment may cause link-change.		host's point-of-attachment may cause link-change.
Reachability Detection: Determination that a device (such as a		Reachability Detection: Determination that a device (such as a
router) is currently reachable, over both a wireless medium, and		router) is currently reachable, over both a wireless medium, and
any attached fixed network. This is typically achieved using		any attached fixed network. This is typically achieved using
Neighbor Unreachability Detection procedure [1].		Neighbor Unreachability Detection procedure [1].
Wireless Medium: A physical layer which incorporates free space		Wireless Medium: A physical layer which incorporates free space
electromagnetic or optical propagation. Such media are		electromagnetic or optical propagation. Such media are
susceptible to mobility and interference effects, potentially		susceptible to mobility and interference effects, potentially
resulting in high packet loss probabilities.		resulting in high packet loss probabilities.
1.2 Relevant Host Issues		3. Background & Motivation for DNA
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 or
link failure.
Host wishes to identify if their current prefix is still valid on		Hosts on the Internet may be connected by various media. It has
a link before the prefix expires. Existing IPv6 Neighbour		become common that hosts have access through wireless media and are
Discovery procedures make this difficult. If the host can		mobile, and have a variety of interfaces through which internet
determine that the target router is still reachable through a		connectivity is provided. The frequency of configuration change for
NS/NA exchange, it does not mean that the prefix is still valid.		wireless and nomadic devices are high due to the vagaries of wireless
Conversely, if host sends an RS, the RA received in response may		propagation or the motion of the hosts themselves. Detecting Network
not contain the prefix of interest for the hosts.		Attachment is a strategy to assist such rapid configuration changes
		by determining whether they are required.
Hosts wish to detect if a particular router is reachable in order		Due to these frequent link-layer changes, an IP configuration change
to use it for routing.		detection mechanism for DNA needs to be efficient and rapid to avoid
		unnecessary configuration delays upon link-change.
Hosts may require some assurance that a device is actually		In an wireless environment, there will typically be a trade-off
present, and is authorized to act as a router.		between configuration delays and the channel bandwidth utilized or
		host's energy used to transmit packets. This trade-off affects
		choices as to whether hosts probe for configuration information, or
		wait for network information. DNA seeks to assist hosts by providing
		information about network state, which may allow hosts to
		appropriately make decisions regarding such trade-offs.
Consideration for these issues underlie the practices recommended in		Even though DNA is restricted to determining whether change is
this document.		needed, in some circumstances the process of obtaining information
		for the new configuration may occur simultaneously with the detection
		to improve the efficiency of these two steps.
1.3 Relevant Router Issues		3.1 Issues
The IPv6 Neighbour Discovery RFC [1] provides mechanisms where		The following features of RFC 2461 make the detection of link
hosts can send Router Solicitations and receive Router		identity difficult:
Advertisements, from each of the routers on a link.
Responses may either be unicast or multicast, but in all cases, a		Routers are not required to include all the prefixes they support
random delay of between 0 and 500 milliseconds is required before		in a single router advertisement message [1].
responses are sent. This is to prevent multiple routers
responding at the same time, and also may mitigate the effects of
simultaneous solicitations. This results in a basic time delay
incurred by hosts receiving response RAs, which cannot be avoided
within current standards [1].
As described in Section 2.1, additional delays may occur if		The default router address is link-local address and hence may
multicast responses are required.		only be unique within one link [1].
Routers should also be careful not to increase the network		While neighbor cache entries are valid only on a single link,
overhead by frequently transmitting router advertisements (see		link-local addresses may be duplicated across many links, and only
Section 2.4).		global addressing can be used to identify if there is a link
		change.
Routers should include all advertised prefixes within the same RA		4. Detecting Network Attachment Steps
and indicate whether a previous advertised prefix is not valid
anymore. Multiple prefixes advertised in different RAs by a
single router may lead to host configurations errors.
1.4 Summary		4.1 Making use of Prior Information
The practices embodied in this document are considered to provide		A device that has recently been attached to a particular wireless
minimal support for hosts wishing to detect network attachment.		base station may still have state regarding the IP configuration
Current work within the DNA working group aims to provide		valid for use on that link. This allows a host to begin any
substantially improved performance for link change detection.		configuration procedures before checking the ongoing validity and
		security of the parameters.
Existing limitations in base protocols such as IPv6 Neighbour		The experimental protocols FMIPv6 [19] and CARD [20] each provide
Discovery preclude support of real-time applications in some		ways to generate such information using network-layer signaling,
environments. Future deployers and implementers are encouraged to		before arrival on a link. Additionally, the issue is the same when a
consider the protocols under development at this time in order to		host disconnects from one cell and returns to it immediately, or
provide a generic service to support hosts detecting change.		movement occurs between a pair of cells (the ping-pong effect).
2. Configuration Practices for DNAv6 Routers		A IP host MAY store L2 to L3 mapping information for the links for a
		period of time in order to use the information in the future. When a
		host attaches itself to a point-of-attachment for which it has an L2
		to L3 mapping, if the stored record doesn't contain the prefix the
		host is using, the host SHOULD conclude that it has changed link and
		initiate a new configuration procedure.
Routers which are being deployed to support hosts' change detection		If the host finds the prefix it is using in the stored record, a host
procedures should attempt to use appropriate configurations, which		MAY conclude that it is on the same link, but SHOULD undertake
limit advertisement latency, and provide appropriate service		reachability testing as described in Section 4.5. In this case, the
considering the constraints of the deployed access network		host MUST undertake Duplicate Address Detection [3][8] to confirm
technology.		that there are no duplicate addresses on the link.
This section describes several configuration parameters which may		The host MUST age this cached information based on the possibility
exist on IPv6 routers, and how their tuning may affect DNA hosts.		that the link's configuration has changed and MUST NOT store
		information beyond either the remaining router or address lifetime or
		(at the outside) MAC_CACHE_TIME time-units.
2.1 Multicast and Unicast RA Responses		If the assumptions attached to the stored configuration are incorrect
		the configuration cost may be increased, or even cause disruption of
		services to other devices. Hosts MUST NOT cause any disruption of
		the IP connectivity to other devices due to the invalidity or
		staleness of their configuration.
While IPv6 Neighbour Discovery assumes that responses to		4.2 Duplicate Address Detection
solicitations will be sent multicast, the specification allows any
router 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		When a host connects to a new link, it needs to create a link-local
the IP host to conclusively infer bi-directional reachability from		address. But to ensure that the link-local address is unique on a
the RS-RA exchange. Neighbour Discovery does not provide any		link, Duplication Address Detection (DAD) MUST be performed [3] by
mechanism to match multicast RA responses with their solicitation,		sending NS targeted at the link-local address undergoing validation.
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 only 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		Optimistic Duplicate Address Detection allows addresses to be used
be able to aggregate its response for multiple RS messages from		while they are being checked, without marking addresses as tentative.
multiple hosts received during the waiting period before RA		Procedures defined in optimistic DAD [8] ensure that persistent
transmission.		invalid neighbour cache entries are not created. This may allow
		faster DNA procedures, by avoiding use of unspecified source
		addresses in RS's and consequently allowing unicast Router
		Advertisements responses [8]. It is RECOMMENDED that hosts follow
		the recommendations of optimistic DAD [8] to reduce the DAD delay.
Where many unicast responses are scheduled awaiting transmission,		Link-local addresses SHOULD be treated as either optimistic or
Routers MAY consider aggregating them into a single multicast		tentative, and globally unique addresses SHOULD NOT be used in a way
response if a multicast advertisement may be sent before the		which creates neighbor cache state on their peers, while DNA
advertisements' scheduled transmission time.		procedures are underway.
It is noted that computational requirements for SEND may preclude		While hosts performing DNA do not know if they have arrived on a new
this subsequent aggregation in some environments.		link, they SHOULD treat their addresses as if they were. The
		different treatment of IP addressing comes from the fact that on the
		global addresses cannot have an address conflict if they move to a
		topologically incorrect network where link-local addresses may. Even
		though global addresses will not collide, the incorrect creation of
		neighbor cache entries on legacy peers may cause them some harm.
Where multiple unicast transmissions for the same destination await		In the case that the host has not changed link and if the time
transmission, routers MAY remove all transmissions after the first		elapsed since the hint is less than the DAD completion time (minus a
without ill-effect, if a multicast RA is scheduled for the next		packet transmission and propagation time), the host MAY reclaim the
possible response time.		address by sending Neighbor Advertisement messages as if another host
		had attempted DAD while the host was away. This will prevent DAD
		completion by another node upon NA reception.
For multicast Router Advertisements, a minimum separating delay		If a host has not been present on a link to defend its address, and
exists so that these RAs may not be scheduled close to each other.		has been absent for a full DAD delay (minus transmission time) the
When a host solicits and attempts to schedule a multicast RA within		host MUST undertake the full DAD procedure for each address from that
MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of		link it wishes to configure [3][8].
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		4.3 Link identification
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		4.3.1 Same link
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.1.1 Recommendations		An IP host MUST conclude that it is on the same link if any of the
		following events happen.
Routers SHOULD respond to a RS message with unicast RS message.		Reception of a RA with the prefix known to be on the link from one
		of its default router address, even if it is the link-local
		address of the router.
Routers SHOULD aggregate RA messages into a multi-cast RA message		Reception of a RA from a known router's global address, present in
if more than 3 unicast RA messages are queued for transmission.		a Prefix Information Option containing the R-"Router Address" flag
		[5].
Where multiple unicast transmissions for the same destination		A host SHOULD conclude that it is on the same link if any of the
await transmission, routers MAY remove all transmissions after the		following events happen.
first without ill-effect.
2.2 Router Advertisement Parameters		Reception of a RA with a prefix that is known to be on the current
		link.
Where hosts have changeable connectivity, there may be a number of		Reception of data packets addressed to its current global address
prefixes or routers stored in the host's memory, which are no longer		if the message was sent from or through a device which is known to
directly reachable. This additional storage may make movement		be fixed (such as a router).
detection slower where hosts rapidly pass through networks, or pass
through networks which have very long advertised timeouts.
Routers SHOULD be configured to advertise non-default Valid and		Confirmation of a global address entry with the Router 'R' flag
Preferred lifetimes in order to provide DNA hosts with link-specific		set in its neighbor cache[1].
address lifetime information.
Administrators are advised to set the advertised Preferred and Valid		4.3.2 Link change
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		A host makes use of Router Discovery messages to determine that it
as DNS) are present on a network, this duration SHOULD be greater		has moved to a new link. Since the content of an existing received
than the maximum expected outage time (for example 9 hours for 0.999		RA is not sufficient to identify the absence of any other prefix,
uptime, with a single outage/year).		additional inference is required for fast and accurate link-change
		detection.
Upon links where fixed hosts are unlikely to be present,		Complete Prefix Lists provide a robust mechanism for link-change
administrators SHOULD reduce the Router Lifetime, and Prefix Valid		detection with even unmodified non-DNA routers if link-layer
and Preferred Lifetimes on routers used to support DNA.		indications are available [24][18]. These procedures provide
		mechanisms to build confidence that a host knows all of a link's
		prefixes and so may rapidly identify a newly received RA as being
		from a different link.
One potential configuration heuristic would be to configure lifetimes		A host SHOULD maintain a complete prefix list as recommended by
to be a low number (for example: 15) of times the MaxRtrAdvInterval,		[24] to identify if the link has changed.
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		4.4 Multicast Listener State
MaxRtrAdvInterval unless the router is not to be used as a default
[1].
Routers MUST NOT be configured with Valid or Preferred lifetime		Multicast routers on a link are aware of which groups are in use
values lower than the MaxRtrAdvInterval.		within a link. This information is used to undertake initiation of
		multicast routing for off-link multicast sources to the link [9]
		[11].
These minima ensure that lifetimes do not expire in between periodic		When a node arrives on a link, it may need to send Multicast Listener
Router Advertisements.		Discovery (MLD) reports, if the multicast stream is not already being
		received on the link. If it is an MLDv2 node it SHOULD send state
		change reports upon arrival on a link [11].
2.2.1 Recommendations		Since the identity of the link is tied to the presence and identity
		of routers, initiation of these procedures may be undertaken when DNA
		procedures have been completed. In the absence of received data
		packets from a multicast stream, it is unlikely that a host will be
		able to determine if the multicast stream is being received on a new
		link, and will have to send state change reports, in addition to
		responses to periodic multicast queries [9] [11].
Routers SHOULD be configured to advertise non-default Valid and		For link scoped multicast, reporting needs to be done to ensure that
Preferred lifetimes in order to provide DNA hosts with link-		packet reception in the link is available due to multicast snoopers.
specific address lifetime information.		Some interaction is possible when sending messages for the purpose of
		DNA on a network where multicast snooping is in use. This issue is
		described in Section 7.4.
Upon links where fixed hosts are unlikely to be present,		4.5 Reachability detection
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		If an IP node needs to confirm bi-directional reachability to its
MaxRtrAdvInterval unless the router is not to be used as a default		default router either a NS-NA or an RS-RA message exchange can be
		used to conduct reachability testing. It is notable that the choice
		of whether the messages are addressed to multicast or unicast address
		will have different reachability implications. The reachability
		implications from the hosts' perspective for the four different
		message exchanges defined by RFC 2461 [1] are presented in the table
		below. The host can confirm bi-directional reachability from the
		neighbor discovery or router discovery message exchanges except when
		a multicast RA is received at the host for its RS message. In this
		case, using IPv6 Neighbour Discovery procedures, the host cannot know
		whether the multicast RA is in response to its solicitation message
		or whether it is a periodic un-solicited transmission from the router
[1].		[1].
Routers MUST NOT be configured with Valid or Preferred lifetime		+-----------------+----+----+----+-----+
values lower than the MaxRtrAdvInterval.		| Exchanges: |Upstream |Downstream|
		+-----------------+----+----+----+-----+
2.3 Router Advertisement Options		| multicast NS/NA | Y | Y |
		+-----------------+----+----+----+-----+
When receiving a Router Advertisement from a particular router for		| unicast NS/NA | Y | Y |
the first time, a host needs to determine if the information		+-----------------+----+----+----+-----+
contained in the RA indicates link change or that the transmitting		| RS/multicast RA | N | Y |
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		| RS/unicast RA | Y | Y |
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
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 a 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.3.1 Recommendations
Routers SHOULD include at least one global Prefix Information		Successful exchange of the messages listed in the table indicate the
Option in every Router Advertisement.		corresponding links to be operational. Lack of reception of response
		from the router may indicate that reachability is broken for one or
		both of the transmission directions or it may indicate an ordinary
		packet loss event in either direction.
Routers SHOULD include Advertisement Interval options in Router		Link-change detection incorporates message reception which may itself
Advertisements.		create neighbour reachability state. When this is the case, a host
		SHOULD rely upon existing Neighbor Discovery procedures in order to
		provide and maintain reachability detection [1].
Routers SHOULD advertise at least one global address consistently		5. Initiation of DNA Procedures
in a Prefix Information Option, by setting the Router Address 'R'
Flag.
2.4 Triggered Router Advertisements		Link change detection procedures are initiated when information is
		received either directly from the network or from other protocol
		layers within the host. This information indicates that network
		reachability or configuration is suspect and is called a hint.
There are proposals for IPv6 Router Advertisements to be sent to		Hints MAY be used to update a wireless host's timers or probing
hosts based on network side link-layer information.		behavior in such a way as to assist detection of network attachment.
		Hints SHOULD NOT be considered to be authoritative for detecting IP
		configuration change by themselves.
Where these mechanisms exist they can provide Router Advertisements		In some cases, hints will carry significant information (for example
in the quickest possible time without need for Router Solicitation.		a hint indicating PPP IPv6CP open state [4]), although details of the
These systems rely upon link-layer facilities are not available in		configuration parameters may be available only after other IP
all environments. Therefore, interested readers are referred to the		configuration procedures. Implementers are encouraged to treat hints
individual methods' documentation [15].		as though they may be incorrect, and require confirmation.
2.5 Split Advertisements		Hosts MUST ensure that untrusted hints do not cause unnecessary
		configuration changes, or significant consumption of host resources
		or bandwidth. In order to achieve this aim, a host MAY implement
		hysteresis mechanisms such as token buckets, hint weighting or
		holddown timers in order to limit the effect of excessive hints (see
		Section 5.6).
A router may choose to split the options in the RA and send multiple		5.1 Actions Upon Hint Reception
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		Upon reception of a hint that link change detection may have
Appendix C increases for each subset of the prefixes included in the		occurred, a host SHOULD send Router Solicitation messages to
split RA messages.		determine the routers and prefixes which exist on a link. Hosts
		SHOULD apply rate limiting and/or hysteresis to this behaviour as
		appropriate to the link technology subject to the reliability of the
		hints.
Routers SHOULD consistently include one prefix in both sets of its RA		Router Advertisements received as a result of such solicitation have
messages. This provide the host with a unique identifier based on		a role in determining if existing configuration is valid, and may be
the combination of link-local address and the constant prefix, to		used to construct prefix lists for a new link [24].
identify the router every time a RA message is received.
2.6 Router Configurations		5.2 Hints Due to Network Layer Messages
Each router can have its own configuration with respect to sending		Hint reception may be due to network-layer messages such as
RAs, and the treatment of router and neighbour solicitations.		unexpected Router Advertisements, multicast listener queries or
Different timers and constants might be used by different routers,		ICMPv6 error messages [1][9][6]. In these cases, the authenticity of
such as the delay between Router Advertisements or delay before		the messages MUST be verified before expending resources to initiate
replying to a multicast RS. If a host is changing its IPv6 link, a		DNA procedure.
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		When a host arrives on a new link, hints received due to external IP
control are considered to be common, it is RECOMMENDED that network		packets will typically be due to multicast messages. Actions based
deployers adopt uniform configuration practices across routers on		on multicast reception from untrusted sources are dangerous due to
different links within the same logical domain, in order to provide		the threat of multicast response flooding. This issue is discussed
consistent performance.		further in Section 8.
3. Topological Practices for DNAv6 Networks		State changes within the network-layer itself may initiate link-
		change detection procedures. Existing subsystems for router and
		neighbor discovery, address leasing and multicast reception maintain
		their own timers and state variables. Changes to the state of one or
		more of these mechanisms may hint that link change has occurred, and
		initiate detection of network attachment.
IPv6 does not prefer one particular network topology over another and		5.3 Handling Hints from Other Layers
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		Events at other protocol layers may provide hints of link change to
		network attachment detection systems. Two examples of such events
		are TCP retransmission timeout and completion of link-layer access
		procedures [18].
Most of today's access networks deploy link-layer bridging		While hints from other protocol layers originate from within the
technologies in order to extend their logical range beyond a single		host's own stack, the network layer SHOULD NOT treat hints from other
Medium Access Control domain.		protocol layers as authoritative indications of link change.
Consequently, while many routers will come with traditional wired or		This is because state changes within other protocol layers may be
optic-fibre interfaces, packets travelling within the same link may		triggered by untrusted messages, come from compromised sources (for
have been bridged across from a wired segment to a wireless segment.		example 802.11 WEP Encryption [21]) or be inaccurate with regard to
		network-layer state.
In many of cases, the router will not have accurate information about		While these hints come from the host's own stack, such hints may
the transmission rates or media of particular segments on the link.		actually be due to packet reception or non-reception events at the
Routers with interfaces whose technology is bridgeable SHOULD NOT		originating layers. As such, it may be possible for other devices to
assume that all segments and devices on the link have the same		instigate hint delivery on a host or multiple hosts deliberately, in
bandwidth available.		order to prompt packet transmission, or configuration modification.
3.2 Wireless cell coverage		Therefore, hosts SHOULD NOT change their configuration state based on
		hints from other protocol layers. A host MAY adopt an appropriate
		link change detection strategy based upon hints received from other
		layers, with suitable caution and hysteresis, as described in
		Section 5.6.
Where the topology of a set of access networks is known to have a		5.4 Timer and Loss Based Hints
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
delays may be reduced as described in Section 3.4.
Where link design is not constrained, many cells may exist within the		Other hints may be received due to timer expiry, particularly In some
same link.		cases the expiry of these timers may be a good hint that DNA
		procedures are necessary.
The scalability of a subnet in terms of wireless cell coverage is		Since DNA is likely to be used when communicating with devices over
likely to be limited by broadcast/multicast traffic between hosts on		wireless links, suitable resilience to packet loss SHOULD be
the link. Where multicast packets may pass from one cell to another		incorporated into the DNA initiation system. Notably, non-reception
in the link (even if no multicast listeners for the group exist),		of data associated with end-to-end communication over the Internet
constrained wireless segments' performance may become degraded.		may be caused by reception errors at either end or because of network
		congestion. Hosts SHOULD NOT act immediately on packet loss
		indications, delaying until it is clear that the packet losses aren't
		caused by transient events.
In this case, it may be necessary to deploy multicast snooping or		Use of the Advertisement Interval Option specified in [5] follows
split the link into smaller broadcast domains [13].		these principles. Routers sending this option indicate the maximum
		interval between successive router advertisements. Hosts receiving
		this option monitor for multiple successive packet losses and
		initiate change discovery.
3.3 Multiple Router Links		5.5 Simultaneous Hints
IPv6 Neighbour Discovery allows multiple routers to be advertising on		Some events which generate hints may affect a number of devices
the same link [1]. These routers are not required to advertise the		simultaneously.
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		For example, if a wireless base station goes down, all the hosts on
number of advertising routers. There SHOULD NOT be more than three		that base station are likely to initiate link-layer configuration
(3) routers advertising on a link. This will provide robustness in		strategies after losing track of the last beacon or pilot signal from
the case of RA packet loss, but provides a bound for bandwidth		the base station.
consumption.
Multiple routers responding to Router Solicitation will reduce the		As described in [1][6], a host SHOULD delay randomly before acting on
mean delay for solicitation, at the cost of additional traffic. For		a widely receivable advertisement, in order to avoid response
unicast responses, the delays may be halved for three responding		implosion.
routers.
+-----------------------+---------+----------+----------+		Where a host considers it may be on a new link and learns this from a
|Num advertising routers| 1 | 2 | 3 |		hint generated by a multicast message, the host SHOULD defer 0-1000ms
+-----------------------+---------+----------+----------+		in accordance with [1][3]. Please note though that a single
|Expected Unicast Delay | 0.250s | 0.167s | 0.125s |		desynchronization is required for any number of transmissions
+-----------------------+---------+----------+----------+		subsequent to a hint, regardless of which messages need to be sent.
If using advertising intervals lower than those specified in IPv6		In link-layers where sufficient serialization occurs after an event
Neighbour Discovery, only one router MAY advertise at the elevated		experienced by multiple hosts, each host MAY avoid the random delays
rate. Other routers beyond the first SHOULD NOT have		before sending solicitations specified in [1].
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		5.6 Hint Validity and Hysteresis
prefix in all of their Router Advertisement messages. This allows
hosts to immediately see that both routers are on the same link.
3.4 Point-to-point Links		In some cases, hints can be generated by lower-layer protocols at an
		elevated rate, which do not reflect actual changes in IP
		configuration. In other cases, hints may also be received prior to
		the availability of the medium for network-layer packets.
IPv6 Router Discovery mandates the delay of RA responses by stating		Additionally, since packet reception at the network and other layers
(in section 6.2.6 of [1]):		are a source for hints, it is possible for traffic patterns on the
		link to create hints, through chance or malicious intent. Therefore,
		it may be necessary to classify hint sources and types for their
		relevance and recent behavior.
"In all cases, Router Advertisements sent in response to a		When experiencing a large number of hints, a host SHOULD employ
Router Solicitation MUST be delayed by a random time		hysteresis techniques to prevent excessive use of network resources.
between 0 and MAX_RA_DELAY_TIME seconds."		The host MAY change the weight of particular hints, to devalue them
		if their accuracy has been poor, they suggest invalid configurations,
		or are suspicious (refer to Section 8).
Cases where the router is on a point-to-point link, this restriction		It is notable, that such hysteresis may cause sub-optimal change
is too stringent as the router in question will be the only router on		detection performance, and may themselves be used to block legitimate
the link. Routers on such point-to-point links MAY avoid the delay		hint reception.
by not waiting for the prescribed random time before responding for
the Router Solicitation message [8] [14].
3.5 Disjoint Administration		5.7 Hint Management for Inactive Hosts
It is possible that multiple sets of routers may be administered by		If a host does not expect to send or receive packets soon, it MAY
different organizations, both advertising on a link.		choose to defer detection of network attachment. This may preserve
		resources on latent hosts, by removing any need for packet
		transmission when a hint is received.
Routers administered by different organizations are likely to have		These hosts SHOULD delay 0-1000ms before sending a solicitation, and
different trust models, especially for routing and renumbering. This		MAY choose to wait up to twice the advertised Router Advertisement
may prevent alien routers from learning about changes in		Interval (plus the random delay) before sending a solicitation [5].
configuration. Consequently, re-advertisements of learned prefixes
in router advertisements may cause problems for hosts trying to
detect link-change. It is important for deployers to remember that
prefixes belonging to another organization, but valid within a link,
SHOULD NOT be advertised if up-to-date prefix validity or lifetime
data are not available.
4. Security Considerations		One benefit of inactive hosts' deferral of DNA procedures is that
		herd-like host configuration testing is mitigated when base-station
		failure or simultaneous motion occur. When latent hosts defer DNA
		tests, the number of devices actively probing for data simultaneously
		is reduced to those hosts which currently support active data
		sessions.
When operating a network in support of hosts performing link change		When a device begins sending packets, it will be necessary to test
detection, both the operational security of the hosts and network		bidirectional reachability with the router (whose current Neighbor
infrastructure are important. DNA procedures rely upon rapid		Cache state is STALE). As described in [1], the host will delay
delivery of information to hosts using IPv6 Neighbour Discovery.		before probing to allow for the probability that upper layer packet
Neighbour Discovery as a critical service in IPv6 networks is subject		reception confirms reachability.
to various attacks as described in [7].
The following sections describe issues and practices to provide		6. IP Hosts Configuration
additional functional security for both operators and hosts.
4.1 Supporting host security		Various protocols within IPv6 provide their own configuration
		processes. A host will have collected various configuration
		information using these protocols during its presence on a link.
		Following is the list of steps the host needs to take if a link-
		change has occured.
In DNA, some hosts will begin configuration procedures based on a		Invalidation of router and prefix list
single message transmitted by a router. As such the ability of
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 exist which
allow hosts to check security of routers when they receive Router
Advertisements indicating link change.
Today these mechanisms require additional message exchanges and		Invalidation of IPv6 addresses
public key operations to check the authorization chain back to a
trusted root. Considering the computational cost for verifying
certificates, it will useful for administrators to attempt to
minimize the length of these authorization chains.
Where a Router Advertisement is sent by a router, it SHOULD contain		Removing neighbor cache entries
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.
As described in section Section 3.3, advertising common prefixes		Completion of DAD for Link-Local Addresses.
achieves this goal.
4.2 Providing Router Authorization		Initiating mobility signaling
Hosts which wish to have secured exchanges with neighbours and on-		The following sub-sections elaborate on these steps.
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		6.1 Router and Prefix list
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		Router Discovery is designed to provide hosts with a set of locally
was also used to generate the router's transmitting address. This		configurable prefixes and default routers. These may then be
guarantees the origin, as well as the freshness of the Router		configured by hosts for access to the Internet [1].
Advertisement transmission.
DNA relies particularly heavily upon router discovery in order to		It allows hosts to discover routers and manage lists of eligible next
test the validity of routing and addressing configuration. In		hop gateways, and is based on IPv6 Neighbor Discovery. When one of
addition to reachability and configuration parameters, routing		the routers in the router list is determined to be no longer
authorization needs to be determined for each router. In SEND [4],		reachable, its destination cache entry is removed, and new router is
routing authorization is delegated by certificate authorities.		selected from the list. If a currently configured router is
		unreachable, it is quite likely that other devices on the same link
		are no longer reachable.
SEND Router Advertisement packets contain the router's public key		On determining that link-change has occurred, the default router list
from a key pair used to sign the message. Certificate authorities		SHOULD have entries removed which are related to unreachable routers,
delegate a portion of their routing authority to the router, tying		and consequently these routers' destination cache entries SHOULD be
them to the public key of the router. Hosts need to test the		removed [1]. If no eligible default routers are in the default
router's authority to provide routing for the prefixes advertised in		router list, Router Solicitations MAY be sent, in order to discover
its RAs in order to ensure safe configuration.		new routers.
While it may be onerous to organize and manage key distribution and		6.2 IPv6 Addresses
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.
Routers supporting DNA SHOULD provide secured router discovery		6.2.1 Autoconfiguration
services using SEND [4].
5. References		Unicast source addresses are required to send all packets on the
		Internet, except a restricted subset of local signaling such as
		router and neighbor solicitations.
5.1 Normative References		In dynamic environments, hosts need to undertake automatic
		configuration of addresses, and select which addresses to use based
		on prefix information advertised in Router Advertisements. Such
		configurations may be based on either Stateless Address
		Autoconfiguration [3] or DHCPv6 [13].
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery		For any configured address, Duplicate Address Detection (DAD) MUST be
for IP Version 6 (IPv6)", RFC 2461, December 1998.		performed [3]. DAD defines that an address is treated tentatively
		until either series of timeouts expire after probe transmissions or
		an address owner defends its address. Tentative addresses cannot
		modify peers' neighbor cache entries, nor can they receive packets.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		As described in Section 4.2, messages used in DNA signaling should be
Levels", BCP 14, RFC 2119, March 1997.		treated as unconfirmed, due to the chance of link change. Optimistic
		DAD is designed to allow use of addressing while they are being
		checked for validity. Careful use of these addresses may contribute
		to faster DNA operation [8].
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		6.2.2 Dynamic Host Configuration
IPv6", RFC 3775, June 2004.
[4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,		Dynamic Host Configuration Procedures for IPv6 define their own
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06		detection procedures [13]. In order to check if the current set of
(work in progress), July 2004.		configuration is valid, a host can send a 'Confirm' message with a
		sample of its current configuration, which is able to be responded to
		by any DHCP relay on a link.
5.2 Informative References		If the replying relay knows it is not on the same link, it may
		respond, indicating that the host's configuration is invalid.
		Current use of this technique is hampered by the lack of wide scale
		deployment of DHCPv6 and hence the detection mechanism doesn't work
		when the host moves to a link which doesn't contain DHCP relays or
		servers.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address		Upon link change, any configuration learned from DHCP which is link
Autoconfiguration", RFC 2462, December 1998.		or administrative domain specific may have become invalid.
		Subsequent operation of DHCP on the new link may therefore be
		necessary.
[6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		6.3 Neighbor cache
Addressing Architecture", RFC 3513, April 2003.
[7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor		Neighbor caches allow for delivery of packets to peers on the same
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.		link. Neighbor cache entries are created by router or neighbor
		discovery signaling, and may be updated either by upper-layer
		reachability confirmations or explicit neighbor discovery exchanges.
[8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,		In order to determine which link-layer address a peer is at, nodes
December 1998.		send solicitations to the link-local solicited-node multicast address
		of their peer. If hosts are reachable on this address, then they
		will respond to the solicitation with a unicast response.
		Information from these responses are stored in neighbour cache
		entries.
[9] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control		When link change occurs, the reachability of all existing neighbor
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE		cache entries is likely to be invalidated, if link change prevents
Std 802.11, 1999.		packet reception from an old link. For these links, the neighbor
		cache entries SHOULD be removed when a host moves to a new link
		(although it MAY be possible to keep keying and authorization
		information for such hosts cached on a least-recently-used basis
		[7]).
[10] Yamamoto, S., "Detecting Network Attachment Terminology",		Reachability of a single node may support the likelihood of reaching
draft-yamamoto-dna-term-00 (work in progress), February 2004.		the rest of the link, for example if a particular access technology
		relays such messages through wireless base stations.
[11] Manner, J. and M. Kojo, "Mobility Related Terminology",		6.4 Mobility Management
draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004.
[12] Moore, N., "Optimistic Duplicate Address Detection for IPv6",		Mobile IPv6 provides global mobility signaling for hosts wishing to
draft-ietf-ipv6-optimistic-dad-02 (work in progress),		preserve sessions when their configured address becomes topologically
September 2004.		incorrect [5]. This system relies upon signaling messages and tunnel
		movement to provide reachability at a constant address, while
		directing packets to its visited network.
[13] Christensen, M., Kimball, K., and F. Solensky, "Considerations		The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures,
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12		which themselves rely upon Neighbor Discovery, to initiate mobility
(work in progress), February 2005.		signaling. These procedures allow for some modification of Neighbor
		Discovery to enable faster change or movement detection. When a host
		identifies that it is on a new link, if it is Mobile-IPv6 enabled
		host, it MAY initiate mobility signaling with its home agent and
		correspondent node.
[14] "3GPP TS 29.061 V5.5.0 (2003-03) Interworking between the		7. Complications to Detecting Network Attachment
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",		Detection of network attachment procedures can be delayed or may be
draft-jinchoi-dna-frd-00 (work in progress), July 2004.		incorrect due to different factors. This section gives some examples
		where complications may interfere with DNA processing.
Authors' Addresses		7.1 Packet Loss
Sathya Narayanan		Generally, packet loss introduces significant delays in validation of
Panasonic Digital Networking Lab		current configuration or discovery of new configuration. Because
Two Research Way, 3rd Floor		most of the protocols rely on timeout to consider that a peer is not
Princeton, NJ 08536		reachable anymore, packet loss may lead to erroneous conclusions.
USA
Phone: 609 734 7599		Additionally, packet loss rates for particular transmission modes
Email: sathya@Research.Panasonic.COM		(multicast or unicast) may differ, meaning that particular classes of
URI:		DNA tests have higher chance of failure due to loss. Hosts SHOULD
		attempt to verify tests through retransmission where packet loss is
		prevalent.
Greg Daley		7.2 Router Configurations
Centre for Telecommunications and Information Engineering
Department of Electrical adn Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 4655		Each router can have its own configuration with respect to sending
Email: greg.daley@eng.monash.edu.au		RA, and the treatment of router and neighbor solicitations.
Nicolas Montavont		Different timers and constants might be used by different routers,
LSIIT - Univerity Louis Pasteur		such as the delay between Router Advertisements or delay before
Pole API, bureau C444		replying to an RS. If a host is changing its IPv6 link, the new
Boulevard Sebastien Brant		router on that link may have a different configuration and may
Illkirch 67400		introduce more delay than the previous default router of the host.
FRANCE		The time needed to discover the new link can then be longer than
		expected by the host.
Phone: (33) 3 90 24 45 87		7.3 Overlapping Coverage
Email: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Appendix A. Summary of Recommendations		If a host can be attached to different links at the same time with
		the same interface, the host will probably listen to different
		routers, at least one on each link. To be simultaneously attached to
		several links may be very valuable for a MN when it moves from one
		access network to another. If the node can still be reachable
		through its old link while configuring the interface for its new
		link, packet loss can be minimized.
It should be noted that many already deployed routers will not		Such a situation may happen in a wireless environment if the link
support these recommendations, and that hosts SHOULD NOT rely on		layer technology allows the MN to be simultaneously attached to
their being in place, unless they have particular reason to do so.		several points of attachment and if the coverage area of access
		points are overlapping.
Where many unicast responses are scheduled awaiting transmission,		For the purposes of DNA, it is necessary to treat each of these
Routers MAY consider aggregating them into a single multicast		points-of-attachment separately, otherwise incorrect conclusions of
response if a multicast advertisement may be sent before the		link-change may be made even if another of the link-layer connections
advertisements' scheduled transmission time.		is valid.
Where multiple unicast transmissions for the same destination await		7.4 Multicast Snooping
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		When a host is participating in DNA on a link where multicast
response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS		snooping is in use, multicast packets may not be delivered to the
restriction [1].		LAN-segment to which the host is attached until MLD signaling has
		been performed [9][11] [17]. Where DNA relies upon multicast packet
		delivery (for example, if a router needs to send a Neighbor
		Solicitation to the host), its function will be degraded until after
		an MLD report is sent.
Routers SHOULD be configured to advertise non-default Valid and		Where it is possible that multicast snooping is in operation, hosts
Preferred lifetimes in order to provide DNA hosts with link-specific		MUST send MLD group joins (MLD reports) for solicited nodes'
address lifetime information.		addresses swiftly after starting DNA procedures.
Where hosts with ongoing transactions, or well known services are		7.5 Link Partition
present on a network, this duration SHOULD be greater than the
maximum expected outage time.
Upon links where fixed hosts are unlikely to be present,		Link partitioning occurs when a link's internal switching or relaying
administrators SHOULD reduce the Router Lifetime, and Prefix Valid		hardware fails, or if the internal communications within a link are
and Preferred Lifetimes on routers used to support DNA.		prevented due to topology changes or wireless propagation.
The Router Lifetime MUST NOT be advertised as less than the		When a host is on a link which partitions, only a subset of the
MaxRtrAdvInterval unless the router is not to be used as a default		addresses or devices it is communicating with may still be available.
[1].		Where link partitioning is rare (for example, with wired
		communication between routers on the link), existing router and
		neighbor discovery procedures may be sufficient for detecting change.
Routers MUST NOT be configured with Valid or Preferred lifetime		8. Security Considerations
values lower than the MaxRtrAdvInterval.
Routers SHOULD include at least one global Prefix Information Option		Detecting Network Attachment is a mechanism which allows network
in every Router Advertisement.		messages to change the node's belief about its IPv6 configuration
		state. As such, it is important that the need for rapid testing of
		link change does not lead to situations where configuration is
		invalidated by malicious third parties, nor that information passed
		to configuration processes exposes the host to other attacks.
Routers SHOULD include Advertisement Interval options in Router		Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats
Advertisements.		which are applicable to those procedures also affect Detecting
		Network Attachment. These threats are described in [12].
Routers SHOULD advertise at least one global address consistently in		Some additional threats are outlined below.
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		8.1 Authorization and Detecting Network Attachment
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		Hosts connecting to the Internet over wireless media may be exposed
control are considered to be common, it is RECOMMENDED that network		to a variety of network configurations with differing robustness,
deployers adopt uniform configuration practices across routers on		controls and security.
different links within the same logical domain, in order to provide
consistent performance.
Routers with interfaces whose technology is bridgeable SHOULD NOT		When a host is determining if link change has occurred, it may
assume that all segments and devices on the link have the same		receive messages from devices with no advertised security mechanisms
bandwidth available.		purporting to be routers, nodes sending signed router advertisements
		but with unknown delegation, or routers whose credentials need to be
		checked [12]. Where a host wishes to configure an unsecured router,
		it SHOULD confirm bidirectional reachability with the device, and it
		MUST mark the device as unsecured as described in [7].
There SHOULD NOT be more than three (3) routers advertising on a		In any case, a secured router SHOULD be preferred over an unsecured
link.		one, except where other factors (unreachability) make the router
		unsuitable. Since secured routers' advertisement services may be
		subject to attack, alternative (secured) reachability mechanisms from
		upper layers, or secured reachability of other devices known to be on
		the same link may be used to check reachability in the first
		instance.
If using advertising intervals lower than those specified in IPv6		8.2 Addressing
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		While a DNA host is checking for link-change, and observing DAD, it
prefix in all of their Router Advertisement messages.		may receive a DAD defense NA from an unsecured source.
Routers on point-to-point links MAY avoid delay by not waiting for		SEND says that DAD defenses MAY be accepted even from non SEND nodes
the prescribed random time before responding for the Router		for the first configured address [7].
Solicitation message [8] [14].
Considering the computational cost for verifying certificates,		While this is a valid action in the case where a host collides with
administrators SHOULD attempt to minimize the length of authorization		another address owner after arrival on a new link, In the case that
chains.		the host returns immediately to the same link, such a DAD defense NA
		message can only be a denial-of-service attempt.
Where a Router Advertisement is sent by a router, it SHOULD contain		If a non-SEND node forges a DAD defense for an address which is still
sufficient information to prove that the router is on the same link		in peers' neighbor cache entries, a host may send a SEND protected
as previously seen advertisers, or is indeed the same router.		unicast neighbor solicitation without a source link-layer address
		option to one of its peers (which also uses SEND). If this peer is
		reachable, it will not have registered the non-SEND DAD defense NA in
		its neighbor cache, and will send a direct NA back to the soliciting
		host. Such an NA reception disproves the DAD defense NA's validity.
Routers supporting DNA SHOULD provide secured router discovery		Therefore, a SEND host performing DNA which receives a DAD defense
services using SEND [4].		from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a
		STALE or REACHABLE secure neighbor cache entry, omitting source link-
		layer address options. In this case, the host should pick an entry
		which is likely to have a corresponding entry on the peer. If the
		host responds within a RetransTimer interval, then the DAD defense
		was an attack, and the host SHOULD inform its systems administrator
		without disabling the address.
On access networks supporting Detecting Network Attachment,		9. Constants
administrators SHOULD configure routers to advertise at the shortest
safe intervals.
Appendix B. Analysis of the response time		MAC_CACHE_TIME: 30 minutes
In IPv6 Neighbour Discovery, the delay induced by the		10. Acknowledgments
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		Thanks to JinHyeock Choi and Erik Nordmark for their significant
Advertisement interval determines the probability of scheduling		contributions. Bernard Aboba's work on DNA for IPv4 strongly
delay.		influenced this document.
Assuming that the arrival of RS messages is independent of each		11. References
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		11.1 Normative References
----------------------------
(MinRtrAdvInterval + MaxRtrAdvInterval)/2
Where the mean interval is defined as the mean delay before		[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
scheduling an unsolicited Router Advertisement. The probability of		for IP Version 6 (IPv6)", RFC 2461, December 1998.
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		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
all responses will be delayed by a random time between 0 and		Levels", BCP 14, RFC 2119, March 1997.
MAX_RA_DELAY_TIME (0.5 s) [1].
In this case, the expected delay E_mcrsra for a single arriving RS		[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
is:		Autoconfiguration", RFC 2462, December 1998.
E_mcrsra = P_mcdelay * MinDelayBetweenRAs/2 + MAX_RA_DELAY_TIME/2		[4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
		December 1998.
Again for RFC2461 minima, the expected delay is thus: 1.535 s.		[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
		IPv6", RFC 3775, June 2004.
The average unicast RA response time of course is 0.250 seconds.		[6] Conta, A. and S. Deering, "Internet Control Message Protocol
		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
		Specification", RFC2463 2463, December 1998.
Assumptions underpinning this approximation hold only if the		[7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
likelihood of more than one RS arriving within a multicast delay		Neighbor Discovery (SEND)", RFC 3971, March 2005.
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		[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
MinDelayBetweenRAs (defaulting to MIN_DELAY_BETWEEN_RAS) is:		draft-ietf-ipv6-optimistic-dad-02 (work in progress),
		September 2004.
P[X(t) > 1] = 1 - P[X(t) == 1] - P[X(t) == 0]		11.2 Informative References
= 1 - (lambda*t)*exp(-lambda*t)/1! - exp(-lambda*t)/0!		[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
		Discovery (MLD) for IPv6", RFC 2710, October 1999.
= 1 - ( 1 + lambda*t)* exp (-lambda*t)		[10] Haberman, B., "Source Address Selection for the Multicast
		Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
For a given load (lambda)=0.05 RS/sec, the probability of multiple RS		[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
arrival is 1.01%.		(MLDv2) for IPv6", RFC 3810, June 2004.
Adopting the MinDelayBetweenRAs = 0.03s and MaxRtrAdvinterval= 4s the		[12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
probability of arrival in the MinDelayBetweenRAs interval is 0.0148.		Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
The estimated expected delay for multicast RS/RA exchange is
therefore 0.25022 seconds.
This is comparable to the unicast response delay.		[13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
		Carney, "Dynamic Host Configuration Protocol for IPv6
		(DHCPv6)", RFC 3315, July 2003.
In this case, the chance of additional solicitation arrival during		[14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
MinDelayBetweenRAs is very low (around 1 in 10^6 for t=0.03,		Addressing Architecture", RFC 3513, April 2003.
lambda=0.05).
Please note that if the MaxRtrAdvInterval is also low (making the		[15] Choi, J., "Detecting Network Attachment in IPv6 Goals",
mean interval duration low), the solicitor is likely to get get an		draft-ietf-dna-goals-04 (work in progress), December 2004.
unsolicited RA due to early scheduling of the RA during the RS/RA
delay period (see Appendix C).
As described in [3], some systems may not provide tunable		[16] Fikouras, N A., K"onsgen, A J., and C. G"org, "Accelerating
MinDelayBetweenRAs except that it assumes the value of the minimum		Mobile IP Hand-offs through Link-layer Information",
time difference between unsolicited RAs (MinRtrAdvInterval) when		Proceedings of the International Multiconference on
MinRtrAdvInterval is less than 3 seconds. Reducing MinRtrAdvInterval		Measurement, Modelling, and Evaluation of Computer-
to will increase the rate of RA transmission, but this doesn't need		Communication Systems (MMB) 2001, September 2001.
to be a dramatic increase. For example, even if the lowest value for
MinRtrAdvInterval is selected (0.03 s), if the MaxRtrAdvInterval is
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		[17] Christensen, M., Kimball, K., and F. Solensky, "Considerations
minimum values, the rate of solicited multicast RAs may be elevated		for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12
to around 33 per second. This raises the potential for abuse by		(work in progress), February 2005.
attackers which can force uniform resource consumption across all
cells in a link.
It is possible to choose delay values which provide significantly		[18] Yegin, A., "Link-layer Event Notifications for Detecting
improved expected and worst case delays over RFC 2461 values, and		Network Attachments", draft-ietf-dna-link-information-00 (work
have well defined upper bound traffic costs for constrained links.		in progress), September 2004.
For example, if a link is able to sustain a maximum of two multicast		[19] Koodli, R., "Fast Handovers for Mobile IPv6",
RAs per second, a safe value for MinRtrAdvInterval and consequently		draft-ietf-mipshop-fast-mipv6-03 (work in progress),
MinDelayBetweenRAs is t=0.5s. With similar load values to those		October 2004.
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		[20] Liebsch, M., "Candidate Access Router Discovery",
interval would be 3.07 * 10^-4 with a load (lambda)=0.05.		draft-ietf-seamoby-card-protocol-08 (work in progress),
		September 2004.
This MinDelayBetweenRAs allows fairly good multicast response		[21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control
performance but bounds the number of multicast RAs to two per second.		(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE
Regardless of load, the worst case delay for RA response in this case		Std 802.11, 1999.
is no greater than 2*MIN_DELAY_BETWEEN_RAs (1 second).
Appendix C. Router Advertisement Rates		[22] Yamamoto, S., "Detecting Network Attachment Terminology",
		draft-yamamoto-dna-term-00 (work in progress), February 2004.
Unsolicited Router Advertisements are scheduled to be transmitted at		[23] Manner, J. and M. Kojo, "Mobility Related Terminology",
a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last		draft-ietf-seamoby-mobility-terminology-06 (work in progress),
multicast Router Advertisement. These parameters may be configured		February 2004.
in the way which best suits the network. The table below summarizes
the parameters as described by IPv6 Neighbour Discovery [1].
+-----------------------+----+----+----+-----+----+-----+		[24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
| Timer |Maximum |Default |Minimum |		list based approach", draft-j-dna-cpl-00 (work in progress),
+-----------------------+----+----+----+-----+----+-----+		October 2005.
| 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		Authors' Addresses
information updates are therefore influenced by the router's
advertisement parameters.
On access networks supporting Detecting Network Attachment,		Sathya Narayanan
administrators SHOULD configure routers to advertise at the shortest		Panasonic Digital Networking Lab
safe intervals. Determination of the shortest safe intervals depends		Two Research Way, 3rd Floor
on topology, and the composition of the link, as described in		Princeton, NJ 08536
Section 3.1.		USA
Mobile IPv6 attempts to address the delays associated with hosts'		Phone: 609 734 7599
movement and change detection by reducing the minimum settings for		Email: sathya@Research.Panasonic.COM
MinRtrAdvInterval to 30ms and MaxRtrAdvInterval to 70ms. Not all		URI:
IPv6 routers support these configuration values today. Where hosts
have no reactive way of detecting change, and do not solicit for
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.		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
| Timer |Maximum |Default |Minimum |		Email: greg.daley@eng.monash.edu.au
+-----------------------+----+----+----+-----+----+-----+		Nicolas Montavont
| MaxRtrAdvInterval | 1800 | 600 | 0.07 |		LSIIT - Univerity Louis Pasteur
+-----------------------+----+----+----+-----+----+-----+		Pole API, bureau C444
| MinRtrAdvInterval | 594 | 198 | 0.03 |		Boulevard Sebastien Brant
+-----------------------+----+----+----+-----+----+-----+		Illkirch 67400
|Avg. Multicast RA time | 1197 | 399 | 0.05 |		FRANCE
+-----------------------+----+----+----+-----+----+-----+
Where Mobile IPv6 is supported, the minimum values change, but the		Phone: (33) 3 90 24 45 87
default timers are unmodified. If administrators wish to take		Email: montavont@dpt-info.u-strasbg.fr
advantage of shorter intervals between unsolicited RAs, explicit		URI: http://www-r2.u-strasbg.fr/~montavont/
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		Appendix A. Example State Transition Diagram
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		Below is an example state diagram which indicates relationships
solicited behaviour in a way which limits the mean bandwidth overhead		between the practices in this document.
for unsolicited RAs.
A good example would be setting a MinRtrAdvInterval (along with		+---------+ +----------+
MinDelayBetweenRAs) as 0.5 s, and the MaxRtrAdvInterval to 4s. This		| Test |< - - - - -| Init |===>
makes the mean delay before receiving an unsolicited RA 2.25 seconds,		|Reachable|<-\ | Config |\
and limits the bandwidth utilization for unsolicited RAs (using the		+---------+ +----------+ \
SEND example above) to 1.5 kbps, and the maximum multicast solicited		| \ New ^ \
rate to 6.9 kbps (one multicast RA each 0.5s).		| ID | \
		V \ | |
		+---------+ +----------+ |
		| *Idle | \--| Link ID | |
		| |<==========| Check | |
		+---------+Same ID +----------+ |
		^ |Hint Creds^ |
		Timer| |Recv OK | |
		| | | |
		| | | |
		| V | |
		+----------+ Hint +----------+ |
		|Hysteresis| Recv | Authorize| |
		| |<--\ | Check | |
		+----------+ \-/ +----------+ |
		| ^ | |
		|Threshold RA | |Bad /
		| Recv| |Auth /
		V | V /
		+----------+ Solicit +----------+L
		| Init |=========>|Await |
		| DNA |<=========|Rtr Advert|
		+----------+ Timer +----------+
Intellectual Property Statement		Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes.
This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/