< draft-ietf-dna-goals-03.txt		draft-ietf-dna-goals-04.txt >
	DNA WG JinHyeock Choi		DNA WG JinHyeock Choi
	Internet-Draft Samsung AIT		Internet-Draft Samsung AIT
	Expires: April 13, 2005 Greg Daley		Expires: June 17, 2005 Greg Daley
	CTIE Monash University		CTIE Monash University
	October 13, 2004		December 17, 2004
	Detecting Network Attachment in IPv6 Goals		Goals of Detecting Network Attachment in IPv6
	draft-ietf-dna-goals-03.txt		draft-ietf-dna-goals-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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 35 ¶		skipping to change at page 1, line 35 ¶
	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 April 13, 2005.		This Internet-Draft will expire on June 17, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	At the time a host establishes a new link-layer connection, it may or		At the time a host establishes a new link-layer connection, it may or
	may not have a valid IP configuration for Internet connectivity. The		may not have a valid IP configuration for Internet connectivity. The
	host may check for link change, i.e. determine whether a link change		host may check for link change, i.e. determine whether a link change
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	2.2 Link identity detection with a single RA . . . . . . . . . 5		2.2 Link identity detection with a single RA . . . . . . . . . 5
	2.3 Delays . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3 Delays . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Goals for Detecting Network Attachment . . . . . . . . . . . . 8		3. Goals for Detecting Network Attachment . . . . . . . . . . . . 8
	3.1 Goals list . . . . . . . . . . . . . . . . . . . . . . . . 8		3.1 Goals list . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13		7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
	7.2 Informative References . . . . . . . . . . . . . . . . . . . 13		7.2 Informative References . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . 15
	1. Introduction		1. Introduction
	When a host has established a new link-layer connection, it can send		When a host has established a new link-layer connection, it can send
	and receive some IPv6 packets at the link, particularly those used		and receive some IPv6 packets on the link, including those used for
	for configuration. On the other hand, the host has full Internet		configuration. On the other hand, the host has Internet connectivity
	connectivity only when it is able to exchange packets with arbitrary		only when it is able to exchange packets with off-link destinations.
	destinations.
	When a link-layer connection is established or re-established, the		When a link-layer connection is established or re-established, the
	host may not know whether its existing IP configuration is still		host may not know whether its existing IP configuration is still
	valid for Internet connectivity. A subnet change might have occurred		valid for Internet connectivity. A subnet change might have occurred
	when the host changed its attachment point.		when the host changed its attachment point.
	In practice, the host doesn't know which of its addresses are valid		In practice, the host doesn't know which of its addresses are valid
	on the newly attached link. The host knows neither if its existing		on the newly attached link. It also doesn't know whether its
	default router is on this link, nor whether its neighbor cache		existing default router is on this link nor if its neighbor cache
	entries are valid. Correct configuration of each of these components		entries are valid. Correct configuration of each of these components
	are necessary in order to send packets on and off the link.		is necessary in order to send packets on and off the link.
	To examine the status of the existing configuration, a host may check		To examine the status of the existing configuration, a host may check
	whether a 'link change' has occurred. The term 'link' used in this		whether a 'link change' has occurred. The term 'link' used in this
	document is as defined in RFC 2461 [1]. The notion 'link' is not		document is as defined in RFC 2461 [1]. The notion 'link' is not
	identical with the notion 'subnet' as defined in RFC 3753 [3]. For		identical with the notion 'subnet' as defined in RFC 3753 [2]. For
	example, there may be more than one subnets on a link and a host		example, there may be more than one subnet on a link and a host
	connected to a link may be part of one or more of the subnets on the		connected to a link may be part of one or more of the subnets on the
	link.		link.
	Today, a link change necessitates an IP configuration change.		Today, a link change necessitates an IP configuration change.
	Whenever a host detects that it has remained at the same link, it can		Whenever a host detects that it has remained at the same link, it can
	usually assume its IP configuration is still valid. Otherwise, the		usually assume its IP configuration is still valid. Otherwise, the
	existing one is no longer valid and a new configuration must be		existing one is no longer valid and a new configuration must be
	acquired. Hence, to examine the validity of an IP configuration, all		acquired. Hence, to examine the validity of an IP configuration, all
	that is required is that the host checks for link change.		that is required is that the host checks for link change.
	skipping to change at page 3, line 51 ¶		skipping to change at page 3, line 50 ¶
	on-link prefixes. So, when an IP subnet change has occurred, the		on-link prefixes. So, when an IP subnet change has occurred, the
	host can immediately initiate the process of getting a new IP		host can immediately initiate the process of getting a new IP
	configuration. This may reduce handoff delay and minimize signaling.		configuration. This may reduce handoff delay and minimize signaling.
	Rapid attachment detection is required for a device that changes		Rapid attachment detection is required for a device that changes
	subnet while having on-going sessions. This may be the case if a		subnet while having on-going sessions. This may be the case if a
	host is connected intermittently, is a mobile node, or has urgent		host is connected intermittently, is a mobile node, or has urgent
	data to transmit upon attachment to a link.		data to transmit upon attachment to a link.
	The process by which a host collects the appropriate information and		The process by which a host collects the appropriate information and
	detects the identity of its currently attached link to ascertains the		detects the identity of its currently attached link to ascertain the
	validity of its IP configuration, is called Detecting Network		validity of its IP configuration, is called Detecting Network
	Attachment (DNA).		Attachment (DNA).
	DNA schemes are typically run per interface. When a host has		DNA schemes are typically run per interface. When a host has
	multiple interfaces, the host separately checks for link changes on		multiple interfaces, the host separately checks for link changes on
	each interface.		each interface.
	It is important to note that DNA process does not include the actual		It is important to note that DNA process does not include the actual
	IP configuration procedure. For example, with respect to DHCP, the		IP configuration procedure. For example, with respect to DHCP, the
	DNA process may determine that the host needs to get some		DNA process may determine that the host needs to get some
	configuration information from a DHCP server. However, the process		configuration information from a DHCP server. However, the process
	of actually retrieving the information from a DHCP server falls		of actually retrieving the information from a DHCP server falls
	beyond the scope of DNA.		beyond the scope of DNA.
	This draft considers the DNA procedure only from the IPv6 point of		This draft considers the DNA procedure only from the IPv6 point of
	view, unless otherwise explicitly mentioned. Hence, the term "IP" is		view, unless otherwise explicitly mentioned. Hence, the term "IP" is
	to be understood to denote IPv6, by default. For the IPv4 case,		to be understood to denote IPv6, by default. For the IPv4 case,
	refer [10].		refer to [7].
	2. Problems in Detecting Network Attachment		2. Problems in Detecting Network Attachment
	There are a number of issues that make DNA complicated. First,		There are a number of issues that make DNA complicated. First,
	wireless connectivity is not as clear-cut as wired one. Second, it's		wireless connectivity is not as clear-cut as wired connectivity.
	difficult for a single RA message to indicate a link change. Third,		Second, it's difficult for a single Router Advertisement message to
	Router Discovery may take too long and result in service disruption.		indicate a link change. Third, the current Router Discovery
			specification specifies that routers wait a random delay of 0-.5
			seconds prior to responding with a solicited RA. This delay can be
			significant and may result in service disruption.
	2.1 Wireless link properties		2.1 Wireless link properties
	Unlike wired environments, what constitutes a wireless link is		Unlike wired environments, what constitutes a wireless link is
	variable both in time and space. Wireless links do not have clear		variable both in time and space. Wireless links do not have clear
	boundaries. This may be illustrated by the fact that a host may be		boundaries. This may be illustrated by the fact that a host may be
	within the coverage area of multiple (802.11) access points at the		within the coverage area of multiple (802.11) access points at the
	same time. Moreover, connectivity on a wireless link can be very		same time. Moreover, connectivity on a wireless link can be very
	volatile, which may make link identity detection hard. For example,		volatile, which may make link identity detection hard. For example,
	it takes time for a host to check for link change. If the host		it takes time for a host to check for link change. If the host
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 19 ¶
	disruption.		disruption.
	1) Delay for receiving a hint		1) Delay for receiving a hint
	Hint is an indication that a link change might have occurred. This		Hint is an indication that a link change might have occurred. This
	hint itself doesn't confirm a link change, but initiates appropriate		hint itself doesn't confirm a link change, but initiates appropriate
	DNA procedures to detect the identity of the currently attached link.		DNA procedures to detect the identity of the currently attached link.
	Hints come in various forms, and differ in how they indicate a		Hints come in various forms, and differ in how they indicate a
	possible link change. They can be link-layer event notifications		possible link change. They can be link-layer event notifications
	[9], the lack of RA from the default router, or the receipt of a new		[6], the lack of RA from the default router, or the receipt of a new
	RA. The time taken to receive a hint also varies.		RA. The time taken to receive a hint also varies.
	As soon as a new link-layer connection has been made, the link-layer		As soon as a new link-layer connection has been made, the link-layer
	may send a link up notification to the IP layer. A host may		may send a link up notification to the IP layer. A host may
	interpret the new link-layer connection as a hint for a possible link		interpret the new link-layer connection as a hint for a possible link
	change. With link-layer support, a host can receive such a hint		change. With link-layer support, a host can receive such a hint
	almost instantly.		almost instantly.
	Mobile IPv6 [5] defines the use of RA Interval Timer expiry for a		Mobile IPv6 [4] defines the use of RA Interval Timer expiry for a
	hint. A host keeps monitoring for periodic RAs and interprets the		hint. A host keeps monitoring for periodic RAs and interprets the
	lack of them as a hint. It may implement its own policy to determine		lack of them as a hint. It may implement its own policy to determine
	the number of missing RAs needed to interpret that as a hint. Hence,		the number of missing RAs needed to interpret that as a hint. Hence,
	the delay depends on the Router Advertisement interval.		the delay depends on the Router Advertisement interval.
	Without schemes such as the ones above, a host must receive a new RA		Without schemes such as the ones above, a host must receive a new RA
	from a new router to detect a possible link change. The detection		from a new router to detect a possible link change. The detection
	time then also depends on the Router advertisement frequency.		time then also depends on the Router Advertisement frequency.
	Periodic RA beaconing transmits packets within an interval varying		Periodic RA beaconing transmits packets within an interval varying
	randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.		randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.
	Because a network attachment is unrelated to the advertisement time		Because a network attachment is unrelated to the advertisement time
	on the new link, hosts are expected to arrive, on average, half way		on the new link, hosts are expected to arrive, on average, half way
	through the interval. This is approximately 1.75 seconds with		through the interval. This is approximately 1.75 seconds with
	Neighbor Discovery [1] advertisement rates.		Neighbor Discovery [1] advertisement rates.
	2) Random delay execution for RS/ RA exchange		2) Random delay execution for RS/ RA exchange
	Router Solicitation and Router Advertisement messages are used for		Router Solicitation and Router Advertisement messages are used for
	Router Discovery. According to [1], it is sometimes necessary for a		Router Discovery. According to [1], it is sometimes necessary for a
	host to wait a random amount of time before it may send an RS, and		host to wait a random amount of time before it may send an RS, and
	for a router to wait before it may reply with an RA.		for a router to wait before it may reply with an RA.
	Before a host sends an initial solicitation, it SHOULD delay the		According to RFC 2461 [1]:
	transmission for a random amount of time between 0 and
	MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router		- before a host sends an initial solicitation, it SHOULD delay the
	Advertisement sent in response to a Router Solicitation MUST be		transmission for a random amount of time between 0 and
	delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5		MAX_RTR_SOLICITATION_DELAY (1 second).
	seconds).
			- Furthermore, any Router Advertisement sent in response to a Router
			Solicitation MUST be delayed by a random time between 0 and
			MAX_RA_DELAY_TIME (0.5 seconds).
	3. Goals for Detecting Network Attachment		3. Goals for Detecting Network Attachment
	The DNA working group has been chartered to define an improved scheme		The DNA working group has been chartered to define an improved scheme
	for detecting IPv6 network attachment. In this section, we define		for detecting IPv6 network attachment. In this section, we define
	the goals that any such solutions should aim to fulfil.		the goals that any such solution should aim to fulfil.
	DNA solutions should correctly determine whether a link change has		DNA solutions should correctly determine whether a link change has
	occurred. Additionally, they should be sufficiently fast so that		occurred. Additionally, they should be sufficiently fast so that
	there would be no or at most minimal service disruption. They should		there would be no or at most minimal service disruption. They should
	neither flood the link with related signaling nor introduce new		neither flood the link with related signaling nor introduce new
	security holes.		security holes.
	When defining new solutions, it is necessary to investigate the usage		When defining new solutions, it is necessary to investigate the usage
	of available tools, NS/NA messages, RS/RA messages, link-layer event		of available tools, Neighbor Solicitation/Neighbor Advertisement
	notifications [9], and other features. This will allow precise		messages, RS/RA messages, link-layer event notifications [6], and
	description of procedures for efficient DNA Schemes.		other features. This will allow precise description of procedures
			for efficient DNA Schemes.
	3.1 Goals list		3.1 Goals list
	G1 DNA schemes should detect the identity of the currently attached		G1 DNA schemes should detect the identity of the currently attached
	link to ascertain the validity of the existing IP configuration.		link to ascertain the validity of the existing IP configuration.
	They should recognize and determine whether a link change has		They should recognize and determine whether a link change has
	occurred and initiate the process of acquiring a new configuration		occurred and initiate the process of acquiring a new configuration
	if necessary.		if necessary.
	G2 When upper-layer protocol sessions are being supported, DNA		G2 DNA schemes should detect the identity of an attached link with
	schemes should detect the identity of an attached link with
	minimal latency lest there should be service disruption.		minimal latency lest there should be service disruption.
	G3 In the case where a host has not changed a link, DNA schemes		G3 In the case where a host has not changed a link, DNA schemes
	should not falsely assume a link change and an IP configuration		should not falsely assume a link change and an IP configuration
	change should not occur.		change should not occur.
	G4 DNA schemes should not cause undue signaling on a link.		G4 DNA schemes should not cause undue signaling on a link.
	G5 DNA schemes should make use of existing signaling mechanisms where		G5 DNA schemes should make use of existing signaling mechanisms where
	available.		available.
	G6 DNA schemes should make use of signaling within the link		G6 DNA schemes should make use of signaling within the link
	(particularly link-local scope messages), since communication		(particularly link-local scope messages), since communication
	off-link may not be achievable in the case of a link change.		off-link may not be achievable in the case of a link change.
	G7 DNA schemes should be compatible with security schemes such as		G7 DNA schemes should be compatible with security schemes such as
	Secure Neighbour Discovery [4].		Secure Neighbour Discovery [3].
	G8 DNA schemes should not introduce new security vulnerabilities.		G8 DNA schemes should not introduce new security vulnerabilities.
	The node supporting DNA schemes should not expose itself or others		The node supporting DNA schemes should not expose itself or others
	on a link to additional man in the middle, identity revealing, or		on a link to additional man-in-the-middle, identity revealing, or
	denial of service attacks.		denial of service attacks.
	G9 The nodes, such as routers or hosts, supporting DNA schemes should		G9 The nodes, such as routers or hosts, supporting DNA schemes should
	work appropriately with unmodified nodes, such as routers or		work appropriately with unmodified nodes, such as routers or
	hosts, which do not support DNA schemes.		hosts, which do not support DNA schemes.
	G10 Hosts, especially in wireless environments, may perceive routers		G10 Hosts, especially in wireless environments, may perceive routers
	reachable on different links. DNA schemes should take into		reachable on different links. DNA schemes should take into
	consideration the case where a host is attached to more than one		consideration the case where a host is attached to more than one
	link at the same time.		link at the same time.
	4. IANA Considerations		4. IANA Considerations
	No new message formats or services are defined in this document.		No new message formats or services are defined in this document.
	5. Security Considerations		5. Security Considerations
	Because DNA schemes are based on Neighbor Discovery, its trust models		DNA process is intimately related to Neighbor Discovery protocol [1]
	and threats are similar to the ones presented in RFC 3756 [6]. Nodes		and its trust model and threats have much in common with the ones
	connected over wireless interfaces may be particularly susceptible to		presented in RFC 3756 [5]. Nodes connected over wireless interfaces
	jamming, monitoring, and packet insertion attacks.		may be particularly susceptible to jamming, monitoring, and packet
			insertion attacks.
	With unsecured DNA schemes, it is inadvisable for a host to adjust		With unsecured DNA schemes, it is inadvisable for a host to adjust
	its security based on which network it believes it is attached to.		its security based on which network it believes it is attached to.
	For example, it would be inappropriate for a host to disable its		For example, it would be inappropriate for a host to disable its
	personal firewall based on the belief that it had connected to a home		personal firewall based on the belief that it had connected to a home
	network.		network.
	Even in the case where authoritative information (routing and prefix		Even in the case where authoritative information (routing and prefix
	state) are advertised, wireless network attackers may still prevent		state) are advertised, wireless network attackers may still prevent
	soliciting nodes from receiving packets. This may cause unnecessary		soliciting nodes from receiving packets. This may cause unnecessary
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 12 ¶
	Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim		Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim
	Bound and Jari Arkko for their contributions to this draft.		Bound and Jari Arkko for their contributions to this draft.
	7. References		7. References
	7.1 Normative References		7.1 Normative References
	[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for		[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
	IP Version 6 (IPv6)", RFC 2461, December 1998.		IP Version 6 (IPv6)", RFC 2461, December 1998.
	[2] Thomson, S. and T. Narten, "IPv6 Stateless Address		[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
	Autoconfiguration", RFC 2462, December 1998.
	[3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
	3753, June 2004.		3753, June 2004.
	[4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,		[3] 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.
	7.2 Informative References		7.2 Informative References
	[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[6] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
	Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
	[7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
	Carney, "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.
	[8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document		[5] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
	Roadmap", RFC 2411, November 1998.		Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
	[9] Yegin, A., "Link-layer Event Notifications for Detecting		[6] Yegin, A., "Link-layer Event Notifications for Detecting Network
	Network Attachments", draft-ietf-dna-link-information-00 (work		Attachments", draft-ietf-dna-link-information-00 (work in
	in progress), September 2004.		progress), September 2004.
	[10] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",		[7] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
	draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004.		draft-ietf-dhc-dna-ipv4-09 (work in progress), October 2004.
	Authors' Addresses		Authors' Addresses
	JinHyeock Choi		JinHyeock Choi
	Samsung AIT		Samsung AIT
	Communication & N/W Lab		Communication & N/W Lab
	P.O.Box 111 Suwon 440-600		P.O.Box 111 Suwon 440-600
	KOREA		KOREA
	Phone: +82 31 280 9233		Phone: +82 31 280 9233
End of changes. 28 change blocks.
	62 lines changed or deleted		58 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/