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.