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/ |