draft-pentland-dna-protocol-00.txt		draft-pentland-dna-protocol-01.txt
	DNA Working Group S. Narayanan		DNA Working Group J. Kempf
	Internet-Draft Panasonic		Internet-Draft DoCoMo Communications Labs USA
	Expires: November 4, 2005 E. Nordmark		Expires: January 19, 2006 S. Narayanan
			Panasonic
			E. Nordmark
	Sun Microsystems		Sun Microsystems
	B. Pentland		B. Pentland, Ed.
	Monash University CTIE		Monash University CTIE
	May 3, 2005		July 18, 2005
	Detecting Network Attachment in IPv6 Networks (DNAv6)		Detecting Network Attachment in IPv6 Networks (DNAv6)
	draft-dnadt-dna-protocol-00.txt		draft-pentland-dna-protocol-01.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 37		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 4, 2005.		This Internet-Draft will expire on January 19, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	Efficient detection of network attachment in IPv6 needs the following		Efficient detection of network attachment in IPv6 needs the following
	two components: a method for the host to query routers on the link to		two components: a method for the host to query routers on the link to
	identify the link (Link Identification) and a method for the routers		identify the link (Link Identification) and a method for the routers
	on the link to consistently respond to such a query with minimal		on the link to consistently respond to such a query with minimal
	delay (Fast RA). Solving the link identification based strictly on		delay (Fast RA). Solving the link identification based strictly on
	RFC 2461 is difficult because of the flexibilities offered to routers		RFC 2461 is difficult because of the flexibilities offered to routers
	in terms of prefixes advertised in a router advertisement (RA)		in terms of prefixes advertised in a router advertisement (RA)
	message. Similarly, the random delay in responding to router		message. Similarly, the random delay in responding to router
	solicitation messages imposed by RFC 2461 makes to it difficult to		solicitation messages imposed by RFC 2461 makes to it difficult to
	achive fast RA. A known set of solutions to these two problems were		achieve fast RA. A known set of solutions to these two problems was
	identified and catalogued by the DNA design team. In this memo, an		identified and catalogued by the DNA design team. In this memo, an
	integrated solution is presented, based on a sub-set of the		integrated solution is presented, based on a sub-set of the
	catalogued solutions. This integrated solution consolidates most of		catalogued solutions. This integrated solution consolidates most of
	the advantages of all known solutions while addressing most of the		the advantages of all known solutions while addressing most of the
	disadvantages.		disadvantages.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5		2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6		3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6
	3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6		3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6
	3.3 Fast Router Advertisment . . . . . . . . . . . . . . . . . 7		3.3 Fast Router Advertisement . . . . . . . . . . . . . . . . 7
	4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8		4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8		4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8
	4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9		4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9
	4.3 DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10		4.3 DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 11		5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 11		5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 12
	5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 11		5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 12
	5.1.2 Router Configuration Variables . . . . . . . . . . . . 12		5.1.2 Router Configuration Variables . . . . . . . . . . . . 13
	5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 13		5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 14
	5.1.4 Processing Router Advertisements . . . . . . . . . . . 13		5.1.4 Processing Router Advertisements . . . . . . . . . . . 15
	5.1.5 Processing Router Solicitations . . . . . . . . . . . 13		5.1.5 Processing Router Solicitations . . . . . . . . . . . 15
	5.1.6 Complete Router Advertisements . . . . . . . . . . . . 15		5.1.6 Complete Router Advertisements . . . . . . . . . . . . 16
	5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 15		5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 16
	5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 16		5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 17
	5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 16		5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 17
	5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 16		5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 17
	5.2.2 Selection of a Landmark Prefix . . . . . . . . . . . . 17		5.2.2 Host Configuration Variables . . . . . . . . . . . . . 18
	5.2.3 Sending Router Solicitations . . . . . . . . . . . . . 17		5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 18
	5.2.4 Processing Router Advertisements . . . . . . . . . . . 17		5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 19
			5.2.5 Processing Router Advertisements . . . . . . . . . . . 19
	6. Backward Compatability . . . . . . . . . . . . . . . . . . . . 18		5.2.6 DNA and Address Configuration . . . . . . . . . . . . 20
	6.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 18
	6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23
	7.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 19		6.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 23
	7.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 19		6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 24
	7.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
			7.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 24
			7.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 24
			7.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 25
	9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21		9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26
	11.1 Normative References . . . . . . . . . . . . . . . . . . . 22		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	11.2 Informative References . . . . . . . . . . . . . . . . . . 22		11.1 Normative References . . . . . . . . . . . . . . . . . . . 26
			11.2 Informative References . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
	A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . . 23		A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . . 28
	Intellectual Property and Copyright Statements . . . . . . . . 25		Intellectual Property and Copyright Statements . . . . . . . . 30
	1. Introduction		1. Introduction
	The proposed scheme in this memo is built upon the following		The proposed scheme in this memo is built upon the following
	solutions catalogued in [12]: Complete RA and Requested Landmark are		solutions catalogued in [15]: Complete RA and Requested Landmark are
	used for the link identification, and Hash-based Fast RA is used to		used for the link identification, and Hash-based Fast RA is used to
	achieve fast response to RS messages. The reasoning behind these		achieve fast response to RS messages. The reasoning behind these
	choices will become evident as the whole scheme and its advantages		choices will become evident as the whole scheme and its advantages
	are understood.		are understood.
	2. Terms and Abbreviations		2. Terms and Abbreviations
	There is an existing DNA terminology draft [9]. This draft does not		There is an existing DNA terminology draft [12]. This draft does not
	introduce any new terminology not already used by existing drafts.		introduce any new terminology not already used by existing drafts.
	The term "link" is used as defined in RFC 2460 [2]. NOTE: this is		The term "link" is used as defined in RFC 2460 [2]. NOTE: this is
	completely different from the term "link" as used by IEEE 802, etc.		completely different from the term "link" as used by IEEE 802, etc.
	3. Overview		3. Overview
	The DNA protocol presented in this document tries to achieve the		The DNA protocol presented in this document tries to achieve the
	following objectives:		following objectives:
	o Eliminate the delays introduced by RFC 2461 in discovering the		o Eliminate the delays introduced by RFC 2461 in discovering the
	configuration		configuration.
	o Make it possible for the hosts to accurately detect the identity		o Make it possible for the hosts to accurately detect the identity
	of their current link from a single RA		of their current link from a single RA.
	o Keep the packets relatively small in size.		o Keep the packets relatively small in size.
	The approach described in this memo is based on the combination of		The approach described in this memo is based on the combination of
	Requested Landmark and CompleteRA for link identification and the		Requested Landmark and CompleteRA for link identification and the
	hash-based Fast RA mechanism. The rest of the document refers to		Hash-based Fast RA mechanism. The rest of the document refers to
	this approach by the term "DNAv6".		this approach by the term "DNAv6".
	DNAv6 assumes that the host's wireless link interface software and		DNAv6 assumes that the host's wireless link interface software and
	hardware is capable of delivering a 'link up' event notification when		hardware is capable of delivering a 'link up' event notification when
	layer 2 on the host is configured and sufficiently stable for IP		layer 2 on the host is configured and sufficiently stable for IP
	traffic. This event notification acts as a hint to the layer 3 DNA		traffic. This event notification acts as a hint to the layer 3 DNA
	procedures to check whether or not the host is attached to the same		procedures to check whether or not the host is attached to the same
	link as before. DNAv6 also assumes that an interface on the host is		link as before. DNAv6 also assumes that an interface on the host is
	never connected to two links at the same time. In the case that the		never connected to two links at the same time. In the case that the
	layer 2 technology is capable of having multiple attachments (for		layer 2 technology is capable of having multiple attachments (for
	skipping to change at page 7, line 16		skipping to change at page 7, line 16
	information consists of the prefixes a router would advertise itself		information consists of the prefixes a router would advertise itself
	as per RFC 2461, and also, the prefixes learned from other routers on		as per RFC 2461, and also, the prefixes learned from other routers on
	the link that are not being advertised by itself. These learned		the link that are not being advertised by itself. These learned
	prefixes are included in a new DNA Option in the Router		prefixes are included in a new DNA Option in the Router
	Advertisement.		Advertisement.
	When the resulting multicast RA carries all the prefixes known to the		When the resulting multicast RA carries all the prefixes known to the
	router, the RA is marked as "complete" using a new bit in the		router, the RA is marked as "complete" using a new bit in the
	message. When a host receives a complete multicast RA, the host can		message. When a host receives a complete multicast RA, the host can
	easily decide whether it is attached to the same link or not from the		easily decide whether it is attached to the same link or not from the
	single RA. Thus, unlike CPL [11], the host does not have to wait for		single RA. Thus, unlike CPL [14], the host does not have to wait for
	multiple advertisements before making a decision.		multiple advertisements before making a decision.
	In order for the routers be able to both respond to the landmark		In order for the routers be able to both respond to the landmark
	questions and send the complete RAs, the routers need to track the		questions and send the complete RAs, the routers need to track the
	prefixes that other routers advertise on the link. This process is		prefixes that other routers advertise on the link. This process is
	initialized when a router is enabled, by sending a Router		initialized when a router is enabled, by sending a Router
	Solicitation and collecting the resulting RAs, and then multicasting		Solicitation and collecting the resulting RAs, and then multicasting
	a few RAs more rapidly as already suggested in RFC 2461. This		a few RAs more rapidly as already suggested in RFC 2461. This
	process ensures with high probability that all the routers have the		process ensures with high probability that all the routers have the
	same notion of the set of prefixes assigned to the link.		same notion of the set of prefixes assigned to the link.
	3.3 Fast Router Advertisment		3.3 Fast Router Advertisement
	According to RFC 2461 a solicited Router Advertisement should have a		According to RFC 2461 a solicited Router Advertisement should have a
	random delay between 0 and 500 milliseconds, to avoid the		random delay between 0 and 500 milliseconds, to avoid the
	advertisements from all the routers colliding on the link causing		advertisements from all the routers colliding on the link causing
	congestion and higher probability of packet loss. In addition, RFC		congestion and higher probability of packet loss. In addition, RFC
	2461 suggests that the RAs be multicast, and multicast RAs are rate		2461 suggests that the RAs be multicast, and multicast RAs are rate
	limited to one message every 3 seconds. This implies that the		limited to one message every 3 seconds. This implies that the
	response to a RS might be delayed up to 3.5 seconds.		response to a RS might be delayed up to 3.5 seconds.
	DNAv6 avoids this delay by using a different mechanism to ensure that		DNAv6 avoids this delay by using a different mechanism to ensure that
	skipping to change at page 10, line 38		skipping to change at page 10, line 38
	Prefix		Prefix
	A prefix being used by the host currently for a global IPv6		A prefix being used by the host currently for a global IPv6
	address, padded at the right with zeros. If the prefix length is		address, padded at the right with zeros. If the prefix length is
	less than 65 bits, only 64 bits need be included, otherwise 128		less than 65 bits, only 64 bits need be included, otherwise 128
	bits are included.		bits are included.
	4.3 DNA Option		4.3 DNA Option
	The DNA Option (DNAO) is used by a router to indicate prefixes that		The DNA Option (DNAO) is used by a router to indicate prefixes that
	are being advertised in PIOs by other routers on the link, but not		are being advertised in PIOs by other routers on the link, but not by
	itself.		itself.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Learned Prefixes ... |		| Type | Length | Prefix Len 1 | Prefix Len 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		| ... | Prefix Len N | Padding |
	| ... Padding |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Prefix 1 +
			| |
			+ +
			| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Prefix 2 +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ ...
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Prefix N +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	TBA		TBA
	Length		Length
	8 bit unsigned integer indicating the length of the option in		8 bit unsigned integer indicating the length of the option in
	units of 8 octets.		units of 8 octets.
	Learned Prefixes		Prefix Len
			One or more fields (N) each consisting of an 8-bit unsigned
	Zero or more fields each consisting of an 8-bit prefix length		integer representing the prefix lengths of the following prefixes.
	followed by a 128-bit address representing a prefix that has been		The Prefix Len fields are ordered the same as the Prefix fields so
	heard on the link but is not explicitly configured on this router.		that the first Prefix Len field represents the prefix length of
			the prefix contained in the first prefix field, and so on.
	Padding		Padding
	Zero padding to make the option an integer multiple of 8 octets.		Zero padding sufficient to align the following prefix field on an
			8-octet boundary.
			Prefix
			One or more fields (N) each containing a 128-bit address
			representing a prefix that has been heard on the link but is not
			explicitly configured on this router.
	Description		Description
	This option MUST only be included in a Router Advertisement. This		This option MUST only be included in a Router Advertisement. This
	option contains prefixes that are being advertised on the link but		option contains prefixes that are being advertised on the link but
	are not explicitly configured on the sending router. The router		are not explicitly configured on the sending router. The router
	MUST NOT include any prefixes with a zero valid lifetime in the		MUST NOT include any prefixes with a zero valid lifetime in the
	DNAO.		DNAO.
	NOTE: Some discussion is needed on the best format for this
	option.
	5. DNA Operation		5. DNA Operation
	5.1 DNA Router Operation		5.1 DNA Router Operation
	Routers MUST collect information about the other routers that are		Routers MUST collect information about the other routers that are
	advertising on the link.		advertising on the link.
	5.1.1 Data Structures		5.1.1 Data Structures
	The routers maintain a set of conceptual data structures for each		The routers maintain a set of conceptual data structures for each
	interface to track the prefixes advertised by other routers on the		interface to track the prefixes advertised by other routers on the
	link, and also the set of DNA routers (the routers that will quickly		link, and also the set of DNA routers (the routers that will quickly
	respond to RAs) on the link. For each interface, routers maintain a		respond to RSs) on the link.
	list of all prefixes advertised on the link. The list will be
	referred to in this document as "DNAPrefixList". For each prefix the		For each interface, routers maintain a list of all prefixes
	router MUST store the following information:		advertised on the link. The list will be referred to in this
			document as "DNAPrefixList". For each prefix the router MUST store
			sufficient information to identify the prefix and to know when to
			remove the prefix entry from the list. This may be achieved by
			storing the following information:
	1. Prefix		1. Prefix
	2. Prefix length		2. Prefix length
	3. Valid lifetime		3. Valid lifetime
	4. Time last refreshed		4. Time last refreshed
	For each interface, routers also maintain a list of the other routers		For each interface, routers also maintain a list of the other routers
	advertising on the link. The list will be referred to in this memo		advertising on the link. The list will be referred to in this memo
	as "DNARouterList". For each router from which a Router		as "DNARouterList". For each router from which a Router
	Advertisement is received with the DNA flag set, the following		Advertisement is received with the DNA flag set, the following
	information MUST be stored:		information MUST be stored:
	1. Source address of advertising router		1. Source address of advertising router
	2. Token equal to the first 64 bits of an SHA-1 hash of the above		2. Token equal to the first 64 bits of an SHA-1 hash of the above
	address		address
			3. Time last refreshed
	Each router MUST include itself in the DNARouterList and generate a		Each router MUST include itself in the DNARouterList and generate a
	token for itself as describe above based on the link-local address		token for itself as describe above based on the link-local address
	used in its RA messages.		used in its RA messages.
	5.1.2 Router Configuration Variables		5.1.2 Router Configuration Variables
	A DNAv6 router MUST allow for the following conceptual variables to		A DNAv6 router MUST allow for the following conceptual variables to
	be configured by the system management. Default values are set to		be configured by the system management. Default values are set to
	ease configuation load.		ease configuration load.
	UnicastRAInterval		UnicastRAInterval
	The interval corresponding to the maximum average rate of Router		The interval corresponding to the maximum average rate of Router
	Solicitations that the router is prepared to service with unicast		Solicitations that the router is prepared to service with unicast
	responses. This is the interval at which the token bucket		responses. This is the interval at which the token bucket
	controlling the unicast responses is replenished.		controlling the unicast responses is replenished.
	Default: 50 milliseconds		Default: 50 milliseconds
	skipping to change at page 13, line 21		skipping to change at page 14, line 21
	Default: 20 milliseconds		Default: 20 milliseconds
	MulticastRADelay		MulticastRADelay
	The delay to be introduced when scheduling a multicast RA in		The delay to be introduced when scheduling a multicast RA in
	response to a RS message when the token bucket is empty.		response to a RS message when the token bucket is empty.
	Default: 3000 milliseconds		Default: 3000 milliseconds
			FastRAThreshold
			The maximum number of fast responses that a host should receive
			when soliciting for Router Advertisements.
			Default: 3
	5.1.3 Bootstrapping DNA Data Structures		5.1.3 Bootstrapping DNA Data Structures
	When an interface on a router first starts up, it SHOULD transmit up		When an interface on a router first starts up, it SHOULD transmit up
	to MAX_RTR_SOLICITATIONS Router Solicitations separated by		to MAX_RTR_SOLICITATIONS Router Solicitations separated by
	RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other		RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other
	routers and prefixes active on the link.		routers and prefixes active on the link.
			Upon startup, a router interface SHOULD also send a few unsolicited
			Router Advertisements as recommended in Section 6.2.4 of RFC 2461
			[3], in order to inform others routers on the link of its presence.
			During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) *
			RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface
			both sends unsolicited Router Advertisements and responds to Router
			Solicitations, but with a few restrictions on the message content.
			Router Advertisements MUST NOT include any DNA specific options
			except that the DNA flag MUST be set. The DNA flag is set so that
			other routers will know to include this router in their timing
			calculations for fast RA transmission. Other DNA options are omitted
			because the router may have incomplete information during bootstrap.
			During the bootstrap period, the timing of Router Advertisement
			transmission is as specified in RFC 2461.
	5.1.4 Processing Router Advertisements		5.1.4 Processing Router Advertisements
	When a router receives a Router Advertisement, it first validates the		When a router receives a Router Advertisement, it first validates the
	RA per the rules in RFC 2461, and then performs the actions specified		RA as per the rules in RFC 2461, and then performs the actions
	in RFC 2461. In addition, each valid Router Advertisement is		specified in RFC 2461. In addition, each valid Router Advertisement
	processed as follows:		is processed as follows:
	If the DNA flag is set in the RA, the router checks if there is an		If the DNA flag is set in the RA, the router checks if there is an
	entry in its DNARouterList. Thus it looks up the source address of		entry in its DNARouterList. Thus it looks up the source address of
	the RA in that list and, if not found, a new entry is added to		the RA in that list and, if not found, a new entry is added to
	DNARouterList, including the source address and a token equal to the		DNARouterList, including the source address and a token equal to the
	first 64 bits of an SHA-1 hash of the source address. The entry's		first 64 bits of an SHA-1 hash of the source address. The entry's
	'Time last refreshed' is updated.		'Time last refreshed' is updated.
	Regardless of the state of the DNA flag, each PIO in the RA is		Regardless of the state of the DNA flag, each PIO in the RA is
	examined. If the prefix is not in the router's AdvPrefixList [3] and		examined. If the prefix is not in the router's DNAPrefixList, it is
	not already in the DNAPrefixList, it is added to the DNAPrefixList,		added, along with the lifetime and refresh information.
	along with the lifetime and refresh information.
	5.1.5 Processing Router Solicitations		5.1.5 Processing Router Solicitations
	The usual response to an RS SHOULD be a unicast RA. To keep control		The usual response to an RS SHOULD be a unicast RA. However, to keep
	of the number of unicast RAs sent, a token bucket is used to limit		control of the rate of unicast RAs sent, a token bucket is used. The
	the rate at which they are sent. The token bucket is filled at one		token bucket is filled at one token every UnicastRAInterval. A
	token every UnicastRAInterval. A maximum of MaxUnicastRABurst tokens		maximum of MaxUnicastRABurst tokens are stored.
	are stored.
	The router interface switches bewteen two states with respect to
	Router Solicitation response, depending on the availablity of tokens
	in the token bucket. The states are called UnicastSender and
	MulticastSender. The interface MUST be initialised to the
	UnicastSender state and the token bucket to full.
	If the interface is in the UnicastSender state then the router checks		When a Router Solicitation is received, if a unicast send token is
	whether there are any unicast send tokens available. If a unicast		available then:
	send token is available:
	If the source address of the Router Solicitation is the		If the source address of the Router Solicitation is the
	Unspecified Address or if it does not contain a landmark option,		Unspecified Address, then the router builds a Complete RA as
	then the router builds a CompleteRA and schedules it for multicast		specified in Section 5.1.6 and schedules it for multicast
	transmission as per RFC 2461. The interface MUST remain in the		transmission as per RFC 2461.
	UnicastSender state.
	If the source address of the RS is NOT the unspecified address,		If the source address of the RS is NOT the unspecified address,
	AND the RS message contains a Landmark option, the router consumes		the router consumes one unicast send token and then builds a
	one unicast send token and then builds a Router Advertisement as		Router Advertisement as follows:
	follows:
	The DNA flag is set.		The DNA flag is set.
	If the RS contains a Landmark Option whose prefix matches one		If the RS contains a Landmark Option whose prefix matches one
	of those in the interface's stored prefix list, then the		of those in the interface's DNAPrefixList, then the Landmark
	Landmark option with the Landmark prefix is included in the RA		option with the Landmark prefix is included in the RA but with
	but with the Yes flag set. At this point the RA is ready for		the Yes flag set. All configuration related options (MTU,
	transmission, and is scheduled as specified in Section 5.1.7.		Advertisement Interval, etc., including PIOs) SHOULD NOT be
			included as this information is already known to the host.
			SEND options, if any, MUST NOT be omitted. At this point the
			RA is ready for transmission, and is scheduled as specified in
			Section 5.1.7.
	If the RS contains a Landmark Option whose prefix does not		If the RS contains a Landmark Option whose prefix does not
	match any of those in the interface's stored prefix list, then		match any of those in the interface's stored prefix list, then
	the Landmark option with the Landmark prefix is included in the		the Landmark option with the Landmark prefix is included in the
	RA but with the No flag set. All fixed options (MTU,		RA but with the No flag set. All fixed options (MTU,
	Advertisement Interval, flags, etc.) are added to the Router		Advertisement Interval, flags, etc.) are added to the Router
	Advertisement. Prefix Information Options for any explicitly		Advertisement. Prefix Information Options for any explicitly
	configured prefixes SHOULD be added to the Router		configured prefixes SHOULD be added to the Router
	Advertisement, while the DNAO for learned prefixes MUST not be		Advertisement, while the DNAO for learned prefixes SHOULD NOT
	added. If there is insufficent room to fit all of the PIOs, an		be added. If there is insufficient room to fit all of the
	additional Router Advertisement is built after consuming		PIOs, an additional Router Advertisement is built after
	another token, if available. At this point the Router		consuming another token, if available. At this point the
	Advertisment is ready for transmission, and is scheduled as		Router Advertisement is ready for transmission, and is
	specified in Section 5.1.7.		scheduled as specified in Section 5.1.7.
	If the interface is in UnicastSender state and a unicast send token		If the RS does not contain a Landmark Option, then the router
	is not available in the token bucket, the router MUST start a timer		builds a complete RA as specified in Section 5.1.6 and
	(MulticastTimer) to expire after MulticastRADelay. The interface		schedules it for unicast transmission as specified in
	MUST transition to the MulticastSender state.		Section 5.1.7.
	If a Router Solicitation is received when the interface is in the		If no unicast send token is available in the token bucket, AND there
	MulticastSender state, then the Router Solicitation MUST be dropped.		are no existing scheduled multicast RAs, the router MUST construct a
	A multicast Router Advertisement has already been scheduled.		Complete RA as specified in Section 5.1.6 and schedule it for
			transmission after MulticastRADelay.
	When the MulticastTimer expires, the router MUST schedule a multicast		Otherwise it is not possible to send a fast unicast response and a
	RA for transmission. This multicast RA SHOULD be constructed as a		multicast Complete RA is already scheduled so therefore the Router
	CompleteRA, as specified in Section 5.1.6. After transmission of		Solicitation MUST be dropped.
	this multicast Router Advertisement in MulticastSenderState, the
	interface MUST transision to the UnicastSender state.
	5.1.6 Complete Router Advertisements		5.1.6 Complete Router Advertisements
	A CompleteRA is formed as follows:		A CompleteRA is formed as follows:
	Starting with a Router Advertisement with all fixed options (MTU,		Starting with a Router Advertisement with all fixed options (MTU,
	Advertisement Interval, flags, etc.), the DNA flag is set. As many		Advertisement Interval, flags, etc.), the DNA flag is set. As many
	Prefix Information Options for explicitly configured prefixes as will		Prefix Information Options for explicitly configured prefixes as will
	fit are added to the Router Advertisement. If there is sufficient		fit are added to the Router Advertisement. If there is sufficient
	room, a DNA option as defined in Section 4.3 containing as many of		room, a DNA option as defined in Section 4.3 containing as many of
	skipping to change at page 15, line 46		skipping to change at page 17, line 13
	RAs may need to be delayed to avoid collisions in the case that there		RAs may need to be delayed to avoid collisions in the case that there
	is more than one router on a link. The delay is calculated by		is more than one router on a link. The delay is calculated by
	determining a ranking for the router for the received RS, and		determining a ranking for the router for the received RS, and
	multiplying that by RASeparation.		multiplying that by RASeparation.
	A token is needed from the RS to calculate the router's ranking. The		A token is needed from the RS to calculate the router's ranking. The
	low order 64 bits of the RS source address MUST be used as the RS		low order 64 bits of the RS source address MUST be used as the RS
	token.		token.
	A router's ranking is determined by taking the XOR of the RS token		A router's ranking is determined by taking the XOR of the RS token
	and each of the stored router tokens. The result of this XOR		and each of the stored router tokens. The results of these XOR
	operation is a 64-bit number. For the purpose of comparison it is		operations are sorted lowest to highest, doing comparisons byte-by-
	treated as an unsigned integer. The lowest result is ranked zero,		byte starting with the least significant byte. The router
			corresponding to the first entry in the sorted list is ranked zero,
	the second, one, and so on.		the second, one, and so on.
	The RA MUST be scheduled for transmission in Rank * RASeparation		Note: it is not necessary for a router to actually sort the whole
	milliseconds. When the router is ranked as zero, the resulting delay		list. Each router just needs to determine its own position in the
	is zero, thus the RA SHOULD be sent immediately.		sorted list.
			If Rank < FastRAThreshold, then the RA MUST be scheduled for
			transmission in Rank * RASeparation milliseconds. When the router is
			ranked as zero, the resulting delay is zero, thus the RA SHOULD be
			sent immediately.
			If Rank >= FastRAThreshold, then the RA MUST be replaced with a
			Complete RA, if it is not one already, and scheduled for multicast
			transmission as in RFC 2461.
	5.1.8 Scheduling Unsolicited Router Advertisements		5.1.8 Scheduling Unsolicited Router Advertisements
	The unsolicited router advertisements scheduled as per RFC 2461		Unsolicited router advertisements MUST be scheduled as per RFC 2461
	SHOULD be a complete RA. This recommendation is made to keep the		SHOULD be Complete RAs. This recommendation is made to keep the
	multicast RA messages transmitted on the link looking the same,		multicast RA messages transmitted on the link looking the same,
	whether they are the multicast RA messages transmitted in		whether they are responses to solicitation that are unable to be
	MulticastSender state of the proposed DNAv6 protocol or the		unicast or the unsolicited RA messages transmitted based on RFC 2461.
	unsolicited RA messages transmitted based on RFC 2461.
	5.2 DNA Host Operation		5.2 DNA Host Operation
	Hosts collect information about the prefixes available on the link to		Hosts collect information about the prefixes available on the link to
	which they are connected to facilitate change detection.		which they are connected to facilitate change detection.
	5.2.1 Data Structures		5.2.1 Data Structures
	Hosts MUST maintain a list of prefixes advertised on the link. This		Hosts MUST maintain a list of prefixes advertised on the link. This
	is separate from the RFC 2461 "Prefix List" and will be referred to		is separate from the RFC 2461 "Prefix List" and will be referred to
	skipping to change at page 16, line 48		skipping to change at page 18, line 24
	If a host is not able to store this information for every prefix,		If a host is not able to store this information for every prefix,
	there is a risk that the host will incorrectly decide that it has		there is a risk that the host will incorrectly decide that it has
	moved to a new link, when it receives advertisements from a non-DNA		moved to a new link, when it receives advertisements from a non-DNA
	router.		router.
	Prefix information entry MUST be removed from the DNAPrefixList when		Prefix information entry MUST be removed from the DNAPrefixList when
	its valid lifetime expires or if the entry has not been refreshed in		its valid lifetime expires or if the entry has not been refreshed in
	the last 1.5 hours.		the last 1.5 hours.
	Hosts MUST also maintain a "Landmark Prefix" as described in		Hosts MUST also maintain a "Landmark Prefix" as described in
	Section 5.2.2.		Section 5.2.3.
	5.2.2 Selection of a Landmark Prefix		5.2.2 Host Configuration Variables
			Hosts MUST make use of the following conceptual variables and they
			SHOULD be configurable:
			DNASameLinkDADFlag
			Boolean value indicating whether or not a host should re-run DAD
			when DNA indicates that link change has not occurred.
			Default: False
			5.2.3 Selection of a Landmark Prefix
	For each interface, hosts MUST choose a prefix to use as a Landmark		For each interface, hosts MUST choose a prefix to use as a Landmark
	Prefix in Router Solicitations. The following rules are used in		Prefix in Router Solicitations. The following rules are used in
	selecting the landmark prefix:		selecting the landmark prefix:
	The prefix MUST have a non-zero valid lifetime.		The prefix MUST have a non-zero valid lifetime.
	The prefix MUST be one the host is using for one of its non-link-		The prefix MUST be one the host is using for one of its non-link-
	local IPv6 addresses.		local IPv6 addresses.
	The prefix SHOULD be chosen as the one with the longest preferred		The prefix SHOULD be chosen as the one with the longest preferred
	lifetime, but it is not necessary to switch to different prefix if		lifetime, but it is not necessary to switch to different prefix if
	the preferred lifetime of the current landmark prefix changes.		the preferred lifetime of the current landmark prefix changes.
	5.2.3 Sending Router Solicitations		5.2.4 Sending Router Solicitations
	Upon the occurance of a Layer 2 link-up event notification, hosts		Upon the occurrence of a Layer 2 link-up event notification, hosts
	SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting		SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting
	and/or hysteresis to this behaviour as appropriate to the link		and/or hysteresis to this behaviour as appropriate to the link
	technology subject to the reliability of the hints.		technology subject to the reliability of the hints.
	Hosts SHOULD include a Landmark Option (LO) in the RS message with		Hosts SHOULD include a Landmark Option (LO) in the RS message with
	the landmark prefix chosen based on the rules in section		the landmark prefix chosen based on the rules in section
	Section 5.2.2.		Section 5.2.3.
	Hosts MUST include a tentative source link layer address option		Hosts MUST include a tentative source link layer address option
	(TSLLAO) in the RS message [13]. The router solicitation message is		(TSLLAO) in the RS message [16]. The router solicitation message is
	sent to the All_Routers_Multicast address and the source address MUST		sent to the All_Routers_Multicast address and the source address MUST
	be the link local address of the host.		be the link local address of the host.
	The host MUST consider its link local address to be in the		The host MUST consider its link local address to be in the
	"Optimistic" state for duplicate address detection [6] until either		"Optimistic" state for duplicate address detection [6] until either
	the returned RA confirms that the host has not switched to a new link		the returned RA confirms that the host has not switched to a new link
	or, if an link switch has occured, the host has performed optimistic		or, if an link change has occurred, the host has performed optimistic
	duplicate address detection for the address.		duplicate address detection for the address.
	5.2.4 Processing Router Advertisements		5.2.5 Processing Router Advertisements
	When the host receives a router advertisment, the host checks for the		When the host receives a Router Advertisement, the host checks for
	conditions and derives the associated conclusions given below:		the conditions and derives the associated conclusions given below:
	If the received router advertisement message was sent unicast to the		If the received Router Advertisement message was sent unicast to the
	host:		host:
	If the unicast Router Advertisement contains a Landmark option		If the unicast Router Advertisement contains a Landmark Option
	that matches the Landmark Option in the last transmitted Router		that matches the Landmark Option in the last transmitted Router
	Solicitation, and the 'Y' bit is set in the received Landmark		Solicitation, and the 'Y' bit is set in the received Landmark
	option, then that indicates that no link change has occured and		option, then that indicates that no link change has occurred and
	current configuration can be assumed to be still current.		current configuration can be assumed to be still current.
	Instead if the 'N' bit is set in the received landmark option, a		Instead if the 'N' bit is set in the received Landmark Option, a
	change of link is indicated and the host SHOULD initiate		change of link is indicated and the host SHOULD initiate
	reconfiguration using the information in the Router Advertisement.		reconfiguration using the information in the Router Advertisement.
	Since the host received a unicast RA from the router, the host		Since the host received a unicast RA from the router, the host
	knows the router heard its RS, hence it SHOULD mark that router as		knows the router heard its RS, hence it SHOULD mark that router as
	REACHABLE from a Neighbor Unreachability Perspective.		REACHABLE from a Neighbor Unreachability Perspective.
	If a Router Advertisement is received with a multicast destination		If a Router Advertisement is received with a multicast destination
	address and the DNA flag is set, check if the received RA is a		address and the DNA flag is set, check if the received RA is a
	completeRA by checking the complete (C) bit in the RA message.		Complete RA by checking the Complete (C) bit in the RA message.
	If the RA is a complete RA and the landmark prefix is not included		If the RA is a Complete RA and the landmark prefix is not included
	in either a PIO or DNAO, then the host can conclude that it has		in either a PIO or DNAO, then the host can conclude that it has
	changed link and SHOULD initiate re-configuration using the		changed link and SHOULD initiate re-configuration using the
	information in the received router advertisement.		information in the received router advertisement.
	If the RA is a complete RA and the the landmark prefix is included		If the RA is a Complete RA and the the landmark prefix is included
	in either a PIO or DNAO, then the host can conclude that it has		in either a PIO or DNAO, then the host can conclude that it has
	not changed link.		not changed link.
	If the received RA is not complete then the host SHOULD use CPL		If the received RA is not complete then the host SHOULD use CPL
	logic to decide whether or not to reconfigure as described in		logic to decide whether or not to reconfigure as described in
	[11].		[14].
	If the DNA flag is not set then the host SHOULD use CPL logic to		If the DNA flag is not set then the host SHOULD use CPL logic to
	decide whether or not to reconfigure as described in [11].		decide whether or not to reconfigure as described in [14].
	When initiating reconfiguration due to link change, the host MUST		When initiating reconfiguration due to link change, the host MUST
	remove all prefixes in the DNAPrefixList and repopulate it with the		remove all prefixes in the DNAPrefixList and repopulate it with the
	prefixes in the Prefix Information Options in the RA.		prefixes in the Prefix Information Options in the RA.
	6. Backward Compatability		5.2.6 DNA and Address Configuration
			When a host moves to a new point of attachment, a potential exists
			for a change in the validity of its unicast and multicast addresses
			on that network interface. In this section, host processing for
			address configuration is specified. The section considers both
			statelessly and statefully configured addresses.
			5.2.6.1 Duplicate Address Detection
			A DNA host MUST support optimistic Duplicate Address Detection [6]
			for autoconfiguring unicast link local addresses. If a DNA host uses
			address autoconfiguration [7] for global unicast addresses, the DNA
			host MUST support optimistic Duplicate Address Detection for
			autoconfiguring global unicast addresses.
			5.2.6.2 DNA and the Address Autoconfiguration State Machine
			When a link level event occurs on a network interface indicating that
			the host has moved from one point of attachment to another, it is
			possible that a change in the reachability of the addresses
			associated with that interface may occur. Upon detection of such a
			link event and prior to sending the RS initiating a DNA exchange, a
			DNA host MUST change the state of addresses associated with the
			interface in the following way (address state designations follow RFC
			2461):
			o Addresses in the "Preferred" state are moved to the "Optimistic"
			state, but the host defers sending out an NS to initiate Duplicate
			Address Detection.
			o Addresses in the "Optimistic" state remain in the "Optimistic"
			state, but the host defers sending out an NS to initiate Duplicate
			Address Detection.
			o Addresses in the "Deprecated" state remain in the "Deprecated"
			state.
			o No addresses should be in the "Tentative" state, since this state
			is unnecessary for nodes that support optimistic Duplicate Address
			Detection.
			A host MUST keep track of which "Preferred" addresses are moved to
			the "Optimistic" state, so it is possible to know which addresses
			were in the "Preferred" state and which were in the "Optimistic"
			state prior to the change in point of attachment.
			In order to perform the DNA transaction, the DNA host SHOULD select
			one of the unicast link local addresses that was in the "Preferred"
			state prior to switching to "Optimistic" and utilize that as the
			source address on the DNA RS. If the host had no "Preferred" unicast
			link local address but did have an address in the "Optimistic" state,
			it MUST utilize such an address as the source address. If the host
			currently has no unicast link local addresses, it MUST construct one
			and put it into the "Optimistic" state and note this address as
			having been in the "Optimistic" state previously, but defer sending
			the NS to confirm. Note that the presence of a duplicate unicast
			link local address on the link will not interfere with the ability of
			the link to route a unicast DNA RA from the router back to the host
			nor will it result in corruption of the router's neighbor cache,
			because the TSLLA option is included in the RS and is utilized by the
			router on the RA frame without changing the neighbor cache.
			When the host receives unicast or multicast RAs from the router, if
			the host determines from the received RAs that it has moved to a new
			link, the host MUST immediately move all unicast global addresses to
			the "Deprecated" state and configure new addresses using the subnet
			prefixes obtained from the RA. For all unicast link local addresses,
			the host MUST initiate NS signaling for optimistic Duplicate Address
			Detection to confirm the uniqueness of the unicast link local
			addresses on the new link.
			If the host determines from the received RAs that it has not moved to
			a new link (i.e. the link has not changed) and the previous state of
			an address was "Optimistic", then the host MUST send an NS to confirm
			that the address is unique on the link. This is required because
			optimistic Duplicate Address Detection may not have completed on the
			previous point of attachment, so the host may not have confirmed
			address uniqueness. If the previous state of an address was
			"Preferred", whether or not the host initiates optimistic Duplicate
			Address Detection depends on the configurable DNASameLinkDADFlag
			flag. A host MUST forgo sending an NS to confirm uniqueness if the
			value of the DNASameLinkDAD flag is False. If, however, the
			DNASameLinkDAD flag is True, the host MUST perform optimistic
			duplicate address detection on its unicast link local and unicast
			global addresses to determine address uniqueness.
			5.2.6.3 DNA and Statefully Configured Addresses
			The DHCPv6 specification [8] requires hosts to send a DHCPv6 CONFIRM
			message when a change in point of attachment is detected. Since the
			DNA protocol provides the same level of movement detection as the
			DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the
			DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive
			signaling. If, however, a non-DNA RA is received, the host SHOULD
			use the DHCPv6 CONFIRM message as described in RFC 3315 [8] rather
			than wait for additional RAs to perform CPL, since this will reduce
			the amount of time required for the host to confirm whether or not it
			has moved to a new link. If the CONFIRM message validates the
			addresses, the host can continue to use them.
			When a DNA RA is received and the received RA indicates that the host
			has not moved to a new link, the host SHOULD apply the same rules to
			interpreting the 'M' flag in the received RA and any subsequently
			received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA
			is received with the 'M' flag set, then the 'M' flag value is copied
			into the ManagedFlag, and if the ManagedFlag changes from False to
			True the host should run DHCPv6, but if the ManagedFlag changes from
			True to False, the host should continue to run DHCPv6. If, however,
			the value of the ManagedFlag remains the same both before and after
			the change in point of attachment on the same link has been
			confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain
			new addresses, since the old addresses will continue to be valid.
			If the DNA RA indicates that the host has moved to a new link or the
			DHCPv6 CONFIRM indicates that the addresses are invalid, the host
			MUST move its old addresses to the "Deprecated" state and MUST run
			DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is
			4-message exchange, however, this exchange allows for redundancy
			(multiple DHCPv6 servers) without wasting addresses, as addresses are
			only provisionally assigned to a host until the host chooses and
			requests one of the provisionally assigned addresses. If the DNA
			host supports the Rapid Commit Option [8], the host SHOULD use the
			Rapid Commit Option in order to shorten the exchange from 4 messages
			to 2 messages.
			5.2.6.4 Packet Delivery During DNA
			The specification of packet delivery before, during, and immediately
			after DNA when a change in point of attachment occurs is out of scope
			for this document. The details of how packets are delivered depends
			on the mobility management protocols (if any) available to the host's
			stack.
			5.2.6.5 Multicast Address Configuration
			If the returning RAs indicate that the host has not moved to a new
			link, no further action is required for multicast addresses to which
			the host has subscribed using MLD Report [9]. In particular, the
			host MUST NOT perform MLD signaling for any multicast addresses
			unless such signaling was not performed prior to movement to the new
			point of attachment. For example, if an address is put into the
			"Optimistic" state prior to movement but the MLD Report for the
			Solicited_Node_Multicast_Address is not sent prior to movement to a
			new point of attachment, the host MUST send the MLD Report on the new
			point of attachment prior to performing optimistic Duplicate Address
			Detection. The host SHOULD use the procedure described below for
			sending an MLD Report.
			If, on the other hand, the DNA RA indicates that the host has moved
			to a new link, the host MUST issue a new MLD Report to the router for
			subscribed multicast addresses. MLD signaling for the
			Solicited_Node_Multicast_Addresses [7] MUST be sent prior to
			performing signaling for optimistic DAD.
			To avoid lengthy delays in address reconfiguration, it is RECOMMENDED
			that the host send the MLD Report for newly configured addresses
			immediately, as soon as the addresses have been constructed, rather
			than waiting for a random backoff.
			Hosts MUST defer MLD signaling until after the results of DNA have
			confirmed whether or not a link change has occurred.
			6. Backward Compatibility
	6.1 Non DNA Host with DNA Routers		6.1 Non DNA Host with DNA Routers
	The RS message sent by non-DNA hosts will not contain any of the new		The RS message sent by non-DNA hosts will not contain any of the new
	options defined by this document. The host will receive a multicast		options defined by this document. The host will receive a Complete
	RA in response to the solicitation message and process it as per RFC		RA in response to the solicitation message and process it as per RFC
	2461.		2461. This means that it will drop the unrecognised DNA option, but
			process the included PIOs and non-DNA flags normally.
	6.2 DNA Host with Non-DNA Routers		6.2 DNA Host with Non-DNA Routers
	The routers will behave based in the recommendations of RFC 2461 [3]		The routers will behave based in the recommendations of RFC 2461 [3]
	and ignore the new options defined in this memo. Hosts will receive		and ignore the new options defined in this memo. Hosts will receive
	RA message without the DNA bit in the RA header set and will fallback		RA message without the DNA bit in the RA header set and will fallback
	on CPL for link identification. Obviously, the objective of		on CPL for link identification. Obviously, the objective of
	receiving fast response for RS message can not be achieved.		receiving fast response for RS message can not be achieved.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 19, line 21		skipping to change at page 24, line 28
	The two security threats discussed in Section 7.1 and Section 7.2 are		The two security threats discussed in Section 7.1 and Section 7.2 are
	part of the discussion catalogued as Issue 14 in Section 9.		part of the discussion catalogued as Issue 14 in Section 9.
	7.1 Amplification Effect		7.1 Amplification Effect
	With N routers on a link, each RS message sent on the link will have		With N routers on a link, each RS message sent on the link will have
	N RA responses sent on the link within (N-1) * RASeparation time.		N RA responses sent on the link within (N-1) * RASeparation time.
	The rate control mechanism specified by this memo only controls the		The rate control mechanism specified by this memo only controls the
	rate of RA messages generated by each of the routers. But, since		rate of RA messages generated by each of the routers. But, since
	there is no theoretical restriction on the number of routers on the		there is no theoretical restriction on the number of routers on the
	link, this amplification can deteriote the performance of the nodes		link, this amplification can deteriorate the performance of the nodes
	on the link. The routers could mitigate this effect by aggregating		on the link. The routers could mitigate this effect by aggregating
	multiple RA messages into a single multicast RA message. When a RS		multiple RA messages into a single multicast RA message. When a RS
	message is received, except for the router chosen to respond first,		message is received, except for the router chosen to respond first,
	all the other routers have a delay introduced before they respond to		all the other routers have a delay introduced before they respond to
	the RS message. Also, when the token bucket is empty ( see		the RS message. Also, when the token bucket is empty ( see
	Section 7.2), the routers will have to wait for a token to be		Section 7.2), the routers will have to wait for a token to be
	generated before responding. If multiple RS messages are received		generated before responding. If multiple RS messages are received
	during this wait time, the routers MAY choose to aggregate the		during this wait time, the routers MAY choose to aggregate the
	responses to a single multicast RA message. Aggregation can be done		responses to a single multicast RA message. Aggregation can be done
	by creating a completeRA message as specified by Section 5.1.6. But,		by creating a Complete RA message as specified by Section 5.1.6.
	since MIN_DELAY_BETWEEN_RAS restriction for multicast RA messages is		But, since MIN_DELAY_BETWEEN_RAS restriction for multicast RA
	inherited by this document, such aggregations are only possible every		messages is inherited by this document, such aggregations are only
	MIN_DELAY_BETWEEN_RAS (3 seconds).		possible every MIN_DELAY_BETWEEN_RAS (3 seconds).
	7.2 Attacks on the Token Bucket		7.2 Attacks on the Token Bucket
	A host on the link could easily drain the token bucket(s) of the		A host on the link could easily drain the token bucket(s) of the
	router(s) on the link by continously sending RS messages on the link.		router(s) on the link by continuously sending RS messages on the
	For example, if a host sends one RS message every UnicastRAInterval,		link. For example, if a host sends one RS message every
	and send a additional RS every third UnicastRAInterval, the token		UnicastRAInterval, and send a additional RS every third
	bucket in the router(s) on the link will drain within		UnicastRAInterval, the token bucket in the router(s) on the link will
	MaxUnicastRABurst * UnicastRAInterval * 3 time-units. For the		drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units.
	recommended values of UnicastRAInterval and MaxUnicastRABurst, this		For the recommended values of UnicastRAInterval and
	value is 3000 milli-seconds. It is not clear whether arrival of such		MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear
	RS messages can be recognized by the router as a DoS attack. This		whether arrival of such RS messages can be recognized by the router
	attack can also be mitigated by aggregating responses. Since only		as a DoS attack. This attack can also be mitigated by aggregating
	one aggregation is possible in this interval due to		responses. Since only one aggregation is possible in this interval
	MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able		due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able
	protect the tokens in the bucket.		protect the tokens in the bucket.
	7.3 Attacks on DNA Hosts		7.3 Attacks on DNA Hosts
	RFC 3756 outlines a collection of threats involving rouge routers.		RFC 3756 outlines a collection of threats involving rouge routers.
	Since DNAv6 requires a host to obtain trustworthy responses from		Since DNAv6 requires a host to obtain trustworthy responses from
	routers, such threats are relevent to DNAv6. In order to counter		routers, such threats are relevant to DNAv6. In order to counter
	such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router		such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router
	discovery.		discovery.
	8. IANA Considerations		8. IANA Considerations
	This memo defines two new Neighbor Discovery [3] options, which must		This memo defines two new Neighbor Discovery [3] options, which must
	be assigned Option Type values within the option numbering space for		be assigned Option Type values within the option numbering space for
	Neighbor Discovery messages:		Neighbor Discovery messages:
	1. The Landmark option, described in Section 4.2; and		1. The Landmark option, described in Section 4.2; and
	skipping to change at page 20, line 41		skipping to change at page 25, line 47
	Issue 006: Congestion control in hosts		Issue 006: Congestion control in hosts
	The draft currently does not discuss congestion control in hosts		The draft currently does not discuss congestion control in hosts
	and thus if there is no response to an RS, a host will follow RFC		and thus if there is no response to an RS, a host will follow RFC
	2461 and send MAX_RTR_SOLICITATIONS separated by		2461 and send MAX_RTR_SOLICITATIONS separated by
	RTR_SOLICITATION_INTERVAL (default 3 RSs at 4 sec. intervals).		RTR_SOLICITATION_INTERVAL (default 3 RSs at 4 sec. intervals).
	Should we specify some kind of exponential backoff to improve		Should we specify some kind of exponential backoff to improve
	response performance for DNAv6 routers or should we try to		response performance for DNAv6 routers or should we try to
	maintain compatibility with RFC 2461?		maintain compatibility with RFC 2461?
	Issue 007: Timers on info stored by hosts
	The draft doesn't currently specify how hosts should age the
	information they collect about prefixes active on a link.
	Issue 009: LNOLO vs matched prefix		Issue 009: LNOLO vs matched prefix
	If there is a landmark option with 'N' bit set in an RA, and *in		If there is a landmark option with 'N' bit set in an RA, and *in
	the same RA* there is PIO that matches another prefix that the		the same RA* there is PIO that matches another prefix that the
	host believes is on the current link, what should the host		host believes is on the current link, what should the host
	conclude?		conclude?
	Issue 0010: Host response to inconsistent information
			Issue 010: Host response to inconsistent information
	What does the host do if it receives multiple RAs that have		What does the host do if it receives multiple RAs that have
	conflicting information?		conflicting information?
	Issue 0012: Network renumbering - guidelines for deployment		Issue 012: Network renumbering - guidelines for deployment
	What does the draft need to say about network renumbering?		What does the draft need to say about network renumbering?
	Recommendations about not flash renumbering? Explanation of		Recommendations about not flash renumbering? Explanation of
	effects of flash renumbering?		effects of flash renumbering?
	Issue 0013: Lifetime of learned prefixes and routers		Issue 013: Lifetime of learned prefixes and routers
	Since the maximum possible values for lifetimes of routers and		Since the maximum possible values for lifetimes of routers and
	prefixes could be very high, should we put an upper limit on how		prefixes could be very high, should we put an upper limit on how
	long learned prefixes and routers information can be stored by		long learned prefixes and routers information can be stored by
	routers?		routers?
	Issue 0014: TBF vs RDA
	Since the current text, using TBF (Token Bucked Flow control),
	allows the router to immediately respond to a RS message, it is
	possible for an attacker to empty the token buckets and move the
	router into MulticastSender state thereby denying other legitimate
	nodes quick link detection. RDA (Random drop approach) recommends
	that the router should do some random unicast responding even in
	MulticastSender without becoming completely silent.
	Issue 0015: DAD Interaction
	Need to add text to address DAD.
	Issue 0016: MLD Interaction
	Need to add text to address MLD.
	10. Acknowledgments		10. Acknowledgments
	The design presented in this document was generated by discussions		The design presented in this document was generated by discussions
	among the members of the DNA design team (JinHyeock Choi, Tero		among the members of the DNA design team (JinHyeock Choi, Tero
	Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett		Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett
	Pentland). The spirited debates on the design, advantages and dis-		Pentland). The spirited debates on the design, advantages and dis-
	advantages of various DNA solutions helped creation of this document.		advantages of various DNA solutions helped creation of this document.
			Thanks to Greg Daley and Subba Reddy for their review of this
			document, and thanks also to other members of the DNA working group
			for their helpful comments.
	11. References		11. References
	11.1 Normative References		11.1 Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	skipping to change at page 22, line 29		skipping to change at page 27, line 18
	[5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,		[5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06		"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
	(work in progress), July 2004.		(work in progress), July 2004.
	[6] Moore, N., "Optimistic Duplicate Address Detection for IPv6",		[6] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
	draft-ietf-ipv6-optimistic-dad-05 (work in progress),		draft-ietf-ipv6-optimistic-dad-05 (work in progress),
	February 2005.		February 2005.
	11.2 Informative References		11.2 Informative References
	[7] Choi, J., "Detecting Network Attachment in IPv6 Goals",		[7] Thomson, S. and T. Narten, "IPv6 Stateless Address
			Autoconfiguration", RFC2462 2462, December 1998.
			[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
			Carney, "Dynamic Host Configuration Protocol for IPv6
			(DHCPv6)", RFC 3315, July 2003.
			[9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
			(MLDv2) for IPv6", RFC 3810, June 2004.
			[10] Choi, J., "Detecting Network Attachment in IPv6 Goals",
	draft-ietf-dna-goals-04 (work in progress), December 2004.		draft-ietf-dna-goals-04 (work in progress), December 2004.
	[8] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network		[11] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network
	Attachment in IPv6 - Best Current Practices",		Attachment in IPv6 - Best Current Practices",
	draft-narayanan-dna-bcp-00 (work in progress), June 2004.		draft-narayanan-dna-bcp-00 (work in progress), June 2004.
	[9] Yamamoto, S., "Detecting Network Attachment Terminology",		[12] Yamamoto, S., "Detecting Network Attachment Terminology",
	draft-yamamoto-dna-term-00 (work in progress), February 2004.		draft-yamamoto-dna-term-00 (work in progress), February 2004.
	[10] Manner, J. and M. Kojo, "Mobility Related Terminology",		[13] Manner, J. and M. Kojo, "Mobility Related Terminology",
	draft-ietf-seamoby-mobility-terminology-06 (work in progress),		draft-ietf-seamoby-mobility-terminology-06 (work in progress),
	February 2004.		February 2004.
	[11] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix		[14] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
	list based approach", draft-ietf-dna-cpl-00 (work in progress),		list based approach", draft-ietf-dna-cpl-00 (work in progress),
	April 2005.		April 2005.
	[12] Pentland, B., "An Overview of Approaches to Detecting Network		[15] Pentland, B., "An Overview of Approaches to Detecting Network
	Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in		Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
	progress), February 2005.		progress), February 2005.
	[13] Daley, G., "Tentative Source Link-Layer Address Options for		[16] Daley, G., "Tentative Source Link-Layer Address Options for
	IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in		IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in
	progress), June 2004.		progress), June 2004.
	Authors' Addresses		Authors' Addresses
			James Kempf
			DoCoMo Communications Labs USA
			USA
			Phone:
			Email: kempf@docomolabs-usa.com
	Sathya Narayanan		Sathya Narayanan
	Panasonic Digital Networking Lab		Panasonic Digital Networking Lab
	Two Research Way, 3rd Floor		Two Research Way, 3rd Floor
	Princeton, NJ 08536		Princeton, NJ 08536
	USA		USA
	Phone: 609 734 7599		Phone: 609 734 7599
	Email: sathya@Research.Panasonic.COM		Email: sathya@Research.Panasonic.COM
	URI:		URI:
	Erik Nordmark		Erik Nordmark
	Sun Microsystems, Inc.		Sun Microsystems, Inc.
	17 Network Circle		17 Network Circle
	Mountain View, CA		Mountain View, CA
	USA		USA
	Phone: +1 650 786 2921		Phone: +1 650 786 2921
	Email: erik.nordmark@sun.com		Email: erik.nordmark@sun.com
	Brett Pentland		Brett Pentland (editor)
	Centre for Telecommunications and Information Engineering		Centre for Telecommunications and Information Engineering
	Department of Electrical and Computer Systems Engineering		Department of Electrical and Computer Systems Engineering
	Monash University		Monash University
	Clayton, Victoria 3800		Clayton, Victoria 3800
	Australia		Australia
	Phone: +61 3 9905 5245		Phone: +61 3 9905 5245
	Email: brett.pentland@eng.monash.edu.au		Email: brett.pentland@eng.monash.edu.au
	Appendix A. How the Goals are Met?		Appendix A. How the Goals are Met?
	The DNA goals document [7] contains a list of goals identified by G1		The DNA goals document [10] contains a list of goals identified by G1
	to G10. This is also enumerated in the solutions discussion document		to G10. This is also enumerated in the solutions discussion document
	[12] generated by the DNA design team. This section discusses how		[15] generated by the DNA design team. This section discusses how
	the proposed scheme addresses each of these goals.		the proposed scheme addresses each of these goals.
	G1 The answer to the landmark question confirms whether link change		G1 The answer to the landmark question confirms whether link change
	has occured and if it has the RA contains sufficient information		has occurred and if it has the RA contains sufficient information
	for the host to commence re-configuration. If a multicast RA is		for the host to commence re-configuration. If a multicast RA is
	used it contains a complete list of prefixes advertised on the		used it contains a complete list of prefixes advertised on the
	link allowing the host to determine whether link change has		link allowing the host to determine whether link change has
	occured and to re-configure if necessary.		occurred and to re-configure if necessary.
	G2 Under normal circumstances the host will receive a RA response		G2 Under normal circumstances the host will receive a RA response
	within round-trip time and some processing time on the router. If		within round-trip time and some processing time on the router. If
	the first RA message is lost, if another router is on the link, a		the first RA message is lost, if another router is on the link, a
	second RA should arrive within a slot time and so on.		second RA should arrive within a slot time and so on.
	G3 Non movement scenarios will be correctly identified because the		G3 Non movement scenarios will be correctly identified because the
	landmark will be confirmed by the router(s) on the link.		landmark will be confirmed by the router(s) on the link.
	G4 A single RS/RA message exchange is initiated in response to a hint		G4 A single RS/RA message exchange is initiated in response to a hint
	that link change may have occured.		that link change may have occurred.
	G5 The existing RS/RA signalling is used along with unsolicited RA		G5 The existing RS/RA signalling is used along with unsolicited RA
	messages. Some new options and flags are proposed.		messages. Some new options and flags are proposed.
	G6 Only link scope signaling is used.		G6 Only link scope signaling is used.
	G7 SEND can be used to protect the RS and RA messages exchanged.		G7 SEND can be used to protect the RS and RA messages exchanged.
	G8 If SEND is not deployed, then a rogue device could cause a host to		G8 If SEND is not deployed, then a rogue device could cause a host to
	think its configuration is invalid by sending an RA that answers		think its configuration is invalid by sending an RA that answers
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/