draft-ietf-dna-protocol-00.txt		draft-ietf-dna-protocol-01.txt
	DNA Working Group J. Kempf		DNA Working Group J. Kempf
	Internet-Draft DoCoMo Communications Labs USA		Internet-Draft DoCoMo Communications Labs USA
	Expires: August 30, 2006 S. Narayanan		Expires: December 27, 2006 S. Narayanan
	Panasonic		Panasonic
	E. Nordmark		E. Nordmark
	Sun Microsystems		Sun Microsystems
	B. Pentland, Ed.		B. Pentland, Ed.
	Monash University CTIE		Monash University CTIE
	JH. Choi		JH. Choi
	Samsung AIT		Samsung AIT
	February 26, 2006		June 25, 2006
	Detecting Network Attachment in IPv6 Networks (DNAv6)		Detecting Network Attachment in IPv6 Networks (DNAv6)
	draft-ietf-dna-protocol-00.txt		draft-ietf-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 41		skipping to change at page 1, line 41
	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 August 30, 2006.		This Internet-Draft will expire on December 27, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	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
	skipping to change at page 3, line 42		skipping to change at page 3, line 42
	5.1.10 Removing a Prefix from an Interface . . . . . . . . 20		5.1.10 Removing a Prefix from an Interface . . . . . . . . 20
	5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 21		5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 21
	5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21		5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21
	5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21		5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21
	5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22		5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22
	5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 22		5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 22
	5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 23		5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 23
	5.2.5 Processing Router Advertisements . . . . . . . . . . . 23		5.2.5 Processing Router Advertisements . . . . . . . . . . . 23
	5.2.6 DNA and Address Configuration . . . . . . . . . . . . 25		5.2.6 DNA and Address Configuration . . . . . . . . . . . . 25
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 28		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 29
	6.1 Non-DNA Host with DNA Routers . . . . . . . . . . . . . . 28		6.1 Non-DNA Host with DNA Routers . . . . . . . . . . . . . . 29
	6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 28		6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 29
	7. Security Considerations . . . . . . . . . . . . . . . . . . 28		7. Security Considerations . . . . . . . . . . . . . . . . . . 29
	7.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 28		7.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 29
	7.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 29		7.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 29
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.1 Normative References . . . . . . . . . . . . . . . . . . 30		10.1 Normative References . . . . . . . . . . . . . . . . . . 31
	10.2 Informative References . . . . . . . . . . . . . . . . . 30		10.2 Informative References . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32
	A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 32		A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . 34		Intellectual Property and Copyright Statements . . . . . . . 35
	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 [16]: Complete RA is used for the link		solutions catalogued in [16]: Complete RA is used for the link
	identification, and Hash-based Fast RA is used to achieve fast		identification, and Hash-based Fast RA is used to achieve fast
	response to RS messages. Aspects of prefix-based LinkID and		response to RS messages. Aspects of prefix-based LinkID and
	Requested Landmark are included to allow for a decrease in the packet		Requested Landmark are included to allow for a decrease in the packet
	sizes associated with Complete RA.		sizes associated with Complete RA.
	skipping to change at page 17, line 7		skipping to change at page 17, line 7
	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
	expiry time is updated.		expiry time is updated.
	Regardless of the state of the FastRA flag, each PIO in the RA is		Regardless of the state of the FastRA flag, each PIO in the RA is
	examined. If the prefix is not in the router's DNARouterPrefixList		examined. If the prefix is not in the router's DNARouterPrefixList
	and not in the router's AdvPrefixList [3], it is added to the		and not in the router's AdvPrefixList [3], it is added to the
	DNARouterPrefixList, and its expiry time is set.		DNARouterPrefixList, and its expiry time is set.
	5.1.5 Processing Router Solicitations		5.1.5 Processing Router Solicitations
	All Router Advertisements sent by a DNA router MUST have the "F" flag		The usual response to a Router Solicitation SHOULD be a unicast RA.
	set so that hosts processing them know that they can count on the		However, to keep control of the rate of unicast RAs sent, a token
	content being interpretable according to this specification.		bucket is used. The token bucket is filled at one token every
			UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored.
	The usual response to an RS SHOULD be a unicast RA. However, to keep		When a Router Solicitation is received, the router checks if it is
	control of the rate of unicast RAs sent, a token bucket is used. The		possible to send a unicast response. A unicast response requires
	token bucket is filled at one token every UnicastRAInterval. A		that the following conditions to be met:
	maximum of MaxUnicastRABurst tokens are stored.
	In order to respond to a Router Solicitation, the router SHOULD		o A unicast send token is available.
	generate a Complete RA as specified in Section 5.1.6. The Router
	Advertisement MUST include the LinkID, as described in Section 5.1.7.
	If a unicast send token is available AND the source address of the		o The source address of the Router Solicitation is NOT the
	Router Solicitation is NOT the unspecified address (::), then a token		unspecified address (::).
	is removed and the Router Advertisement is scheduled for transmission
	as specified in Section 5.1.8.
	If no unicast send token is available OR the source address of the		If a unicast response is possible and the Router Solicitation
	Router Solicitation is the unspecified address, then if there is no		contains a Landmark Option whose prefix is included in
	multicast RA scheduled for transmission in the next MulticastRADelay		DNARouterPrefixList or AdvPrefixList, the router SHOULD send an
	the RA MUST be sent to the link-scoped all-nodes multicast address at		abbreviated Router Advertisement.
	the current time plus MulticastRADelay.
	If no unicast send token is available OR the source address of the		This abbreviated advertisement includes only the Landmark Option,
	Router Solicitation is the unspecified address but there is a		with the "Y" flag set, plus the base RA header and any SEND options
	multicast RA scheduled for transmission in the next MulticastRADelay,		as appropriate. The FastRA flag MUST be set. The Complete flag MUST
	then the Router Solicitation MUST be dropped.		NOT be set. This is the one exception where the LinkID MAY be
			omitted as the Y flag implies that link change has not occured and
			that the previously received LinkID is still current.
	5.1.5.1 Space Optimized Advertisements		If there is NO Landmark Option in the received Router Solicitation or
			it contains a Landmark Option whose prefix is NOT included in
			DNARouterPrefixList or AdvPrefixList or a unicast response is not
			possible, then the router SHOULD generate a Complete RA as specified
			in Section 5.1.6. The Router Advertisement MUST include the LinkID,
			as described in Section 5.1.7.
	If the Router Solicitation contains a Landmark Option whose prefix is		If a unicast response is possible, then a token is removed and the
	included in DNARouterPrefixList or AdvPrefixList AND the		Router Advertisement is scheduled for transmission as specified in
	corresponding Router Advertisement will be unicast, the router MAY		Section 5.1.8.
	send an abbreviated Router Advertisement.
	The abbreviated advertisement includes only the Landmark Option, with		If a unicast response is not possible and there is no multicast RA
	the "Y" flag set, plus the base RA header and any SEND options as		already scheduled for transmission in the next MulticastRADelay the
	appropriate. The Complete flag MUST NOT be set. This is the one		RA MUST be sent to the link-scoped all-nodes multicast address at the
	exception where the LinkID MAY be omitted as the Y flag implies that		current time plus MulticastRADelay.
	link change has not occured.
	Some prefixes may also be omitted from unsolicited Router		If a unicast response is not possible but there is a multicast RA
	Advertisements, as described in Section 5.1.9.		already scheduled for transmission in the next MulticastRADelay, then
			the Router Solicitation MUST be silently discarded.
	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 FastRA flag is set. As		Advertisement Interval, flags, etc.), the FastRA flag is set. As
	many Prefix Information Options for explicitly configured prefixes as		many Prefix Information Options for explicitly configured prefixes as
	will fit are added to the Router Advertisement. If there is		will fit are added to the Router Advertisement. If there is
	sufficient room, a Learned Prefix Option as defined in Section 4.4		sufficient room, a Learned Prefix Option as defined in Section 4.4
	skipping to change at page 24, line 26		skipping to change at page 24, line 26
	DNAHostPrefixList, then the host can conclude that it has changed		DNAHostPrefixList, then the host can conclude that it has changed
	link and SHOULD initiate re-configuration using the information in		link and SHOULD initiate re-configuration using the information in
	the received Router Advertisement.		the received Router Advertisement.
	If the received RA is not complete, contains no prefixes that are		If the received RA is not complete, contains no prefixes that are
	stored in DNAHostPrefixList, does not contain a Landmark Option		stored in DNAHostPrefixList, does not contain a Landmark Option
	that matches a corresponding option in the most recent RS and		that matches a corresponding option in the most recent RS and
	contains no LinkID, then the host SHOULD use CPL logic to decide		contains no LinkID, then the host SHOULD use CPL logic to decide
	whether or not to reconfigure as described in [15].		whether or not to reconfigure as described in [15].
	If the destination address of the received RA is a unicast address,
	the host knows the router heard its RS, and hence it SHOULD mark that
	router's Neighbor Cache Entry [3] as REACHABLE.
	5.2.5.1 Maintaining the DNAHostPrefixList		5.2.5.1 Maintaining the DNAHostPrefixList
	If a Router Advertisement does not indicate a link change, the host		If a Router Advertisement does not indicate a link change, the host
	updates its DNAHostPrefixList, adding any new prefixes if necessary.		updates its DNAHostPrefixList, adding any new prefixes if necessary.
	If the Router Advertisement has the C flag set, then the host SHOULD		If the Router Advertisement has the C flag set, then the host SHOULD
	make the DNAHostPrefixList match the contents of the advertisement.		make the DNAHostPrefixList match the contents of the advertisement.
	Any new prefixes are added and any prefixes in the list that are		Any new prefixes are added and any prefixes in the list that are
	absent in the advertisement are removed. Expiry times on prefixes		absent in the advertisement are removed. Expiry times on prefixes
	are updated if the prefix was contained in a PIO, but not if it was		are updated if the prefix was contained in a PIO, but not if it was
	skipping to change at page 25, line 5		skipping to change at page 24, line 47
	If the Router Advertisement does not have the C flag set, then the		If the Router Advertisement does not have the C flag set, then the
	host SHOULD add any new prefixes and update expiry times as above,		host SHOULD add any new prefixes and update expiry times as above,
	but SHOULD NOT remove any entries from DNAHostPrefixList.		but SHOULD NOT remove any entries from DNAHostPrefixList.
	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 DNAHostPrefixList and repopulate it with		remove all prefixes in the DNAHostPrefixList and repopulate it with
	the prefixes in the Prefix Information Options and Learned Prefix		the prefixes in the Prefix Information Options and Learned Prefix
	Option, if any, in the RA.		Option, if any, in the RA.
			5.2.5.2 Router Reachability Detection and Default Router Selection
			The receipt of a unicast RA from a router in response to a multicast
			RS indicates that the host has bi-directional reachability with the
			routers that responded. Such reachability is necessary for the host
			to use a router as a default router, in order to have packets routed
			off the host's current link. If the destination address of the
			received RA is a unicast address, the host knows the router heard its
			RS, and therefore that the host has reachability with the router.
			Prior to sending a DNA RS in response to an indication of link
			change, the host SHOULD set all Neighbor Cache entries for routers on
			its Default Router List to STALE. When the host receives an RA in
			reply to the RS, the host SHOULD mark that router's Neighbor Cache
			Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the
			REACHABLE state if one does not currently exist.
			The host SHOULD also update its Default Router List in the following
			fashion. If any of the routers returning RAs are already on the
			default router list, the host SHOULD use the information in the RA to
			update the Default Route List entry with the new information. The
			host SHOULD add entries to the Default Router List for any routers
			returning RAs that are not on the list. The host SHOULD confine
			selection of a router from the Default Router List to those routers
			whose Neighbor Cache entries are in the REACHABLE state. Note that
			the Default Router List SHOULD be updated as described here
			regardless of whether the RA indicates that the host has changed to a
			new IP link, since changes in router reachability are possible on
			some link types even if the host remains on the same IP link.
			Note that this procedure does not prevent a MN from sending packets
			to its current default router while the RA solicitation is in
			progress and if reachability with the current default router is
			unchanged, there should be no change in default router after the RA
			solicitation completes. If the current default router is still
			reachable, it will forward the packets.
	5.2.6 DNA and Address Configuration		5.2.6 DNA and Address Configuration
	When a host moves to a new point of attachment, a potential exists		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		for a change in the validity of its unicast and multicast addresses
	on that network interface. In this section, host processing for		on that network interface. In this section, host processing for
	address configuration is specified. The section considers both		address configuration is specified. The section considers both
	statelessly and statefully configured addresses.		statelessly and statefully configured addresses.
	5.2.6.1 Duplicate Address Detection		5.2.6.1 Duplicate Address Detection
End of changes. 23 change blocks.
	56 lines changed or deleted		90 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/