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:
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:
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:
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:
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]:
		- before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and		transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY (1 second). Furthermore, any Router		MAX_RTR_SOLICITATION_DELAY (1 second).
Advertisement sent in response to a Router Solicitation MUST be
delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5		- Furthermore, any Router Advertisement sent in response to a Router
seconds).		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:
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		[5] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.		Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.		[6] Yegin, A., "Link-layer Event Notifications for Detecting Network
Carney, "Dynamic Host Configuration Protocol for IPv6		Attachments", draft-ietf-dna-link-information-00 (work in
(DHCPv6)", RFC 3315, July 2003.		progress), September 2004.
[8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
[9] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 (work
in 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.
This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/