draft-ietf-dna-cpl-01.txt   draft-ietf-dna-cpl-02.txt 
DNA WG J. Choi DNA WG JH. Choi
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: October 3, 2005 E. Nordmark Expires: July 21, 2006 E. Nordmark
Sun Microsystems SUN Microsystems
April 2005 January 17, 2006
DNA with unmodified routers: Prefix list based approach DNA with unmodified routers: Prefix list based approach
draft-ietf-dna-cpl-01.txt draft-ietf-dna-cpl-02.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 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 October 3, 2005. This Internet-Draft will expire on July 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Upon establishing a new link-layer connection, a host determines Upon establishing a new link-layer connection, a host determines
whether a link change has occurred, that is, whether or not it has whether a link change has occurred, that is, whether or not it has
moved at layer 3 and therefor needs new IP configuration. This draft moved at layer 3 and therefore needs new IP configuration. This
presents a way to robustly check for link change without assuming any draft presents a way to robustly check for link change without
changes to the routers. We choose to uniquely identify each link by assuming any changes to the routers. We choose to uniquely identify
the set of prefixes assigned to it. We propose that, at each each link by the set of prefixes assigned to it. We propose that, at
attached link, the host generates the complete prefix list, that is, each attached link, the host generates the Complete Prefix List, that
a prefix list containing all the valid prefixes on the link, and when is, a prefix list containing all the valid prefixes on the link, and
it receives a hint that indicates a possible link change, it detects when it receives a hint that indicates a possible link change, it
the identity of the currently attached link by consulting the detects the identity of the currently attached link by consulting the
existing prefix list. This memo describes how to generate the existing prefix list. This memo describes how to generate the
complete prefix list and to robustly detect the link identity even in Complete Prefix List and to robustly detect the link identity even in
the presence of packet loss. the presence of packet loss.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Prefix list based approach . . . . . . . . . . . . . . . . . 4 2. Prefix list based approach . . . . . . . . . . . . . . . . . 4
2.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DNA based on the complete prefix list . . . . . . . . . . . 7 3. DNA based on the Complete Prefix List . . . . . . . . . . . 7
3.1 Complete prefix list generation . . . . . . . . . . . . . 7 3.1 Complete Prefix List generation . . . . . . . . . . . . . 7
3.2 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 8 3.2 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 8
3.3 Link identity detection . . . . . . . . . . . . . . . . . 9 3.3 Link identity detection . . . . . . . . . . . . . . . . . 9
3.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 10
4. Protocol Specification . . . . . . . . . . . . . . . . . . . 12 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 11
4.1 Conceptual data structures . . . . . . . . . . . . . . . . 12 4.1 Conceptual data structures . . . . . . . . . . . . . . . . 11
4.2 Merging Candidate Link objects . . . . . . . . . . . . . . 13 4.2 Merging Candidate Link objects . . . . . . . . . . . . . . 12
4.3 Timer handling and Garbage Collection . . . . . . . . . . 13 4.3 Timer handling and Garbage Collection . . . . . . . . . . 13
4.4 Receiving link UP notifications . . . . . . . . . . . . . 14 4.4 Receiving link UP notifications . . . . . . . . . . . . . 13
4.5 Receiving valid Router Advertisements . . . . . . . . . . 14 4.5 Receiving valid Router Advertisements . . . . . . . . . . 14
4.6 Changing the link in Neighbor Discovery . . . . . . . . . 16 4.6 Changing the link in Neighbor Discovery . . . . . . . . . 16
5. CPL without a 'link UP' notification . . . . . . . . . . . . 18 5. CPL without a 'link UP' notification . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . 20
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1 Example with link UP event notification . . . . . . . . . 22 8.1 Example with link UP event notification . . . . . . . . . 21
8.2 Example without link UP event notification . . . . . . . . 22 8.2 Example without link UP event notification . . . . . . . . 21
9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 24 9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. Performance Analysis . . . . . . . . . . . . . . . . . . . . 26 11. Performance Analysis . . . . . . . . . . . . . . . . . . . . 25
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 27
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.1 Normative References . . . . . . . . . . . . . . . . . . 30 14.1 Normative References . . . . . . . . . . . . . . . . . . 30
14.2 Informative References . . . . . . . . . . . . . . . . . 30 14.2 Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . 32
1. Introduction 1. Introduction
When a host establishes a new link-layer connection, it may or may When a host establishes a new link-layer connection, it may or may
not have a valid IP configuration, such as the subnet prefixes or the not have a valid IP configuration, such as the subnet prefixes or the
default router addresses, for the link. Though the host has changed default router addresses, for the link. Though the host has changed
its network attachment point (at layer 2), it may still be at the its network Point of Attachment (at layer 2), it may still be at the
same link (at layer 3). The term 'link' used in this document is as same link (at layer 3). The term 'link' used in this document is as
defined in RFC 2461 [1], which is a layer 3 definition. NOTE that defined in RFC 2461 [1], which is a layer 3 definition. NOTE that
that definition is completely different than the definition of the that definition is completely different from the definition of the
term 'link' in IEEE 802 standards. term 'link' in IEEE 802 standards.
Thus the host needs to check for a link change, i.e. it needs to Thus the host needs to check for a link change, i.e. it needs to
verify whether it is attached to the same or a different link as verify whether it is attached to the same or a different link as
before [4]. The host can keep current IP configuration if and only before [4]. The host can keep current IP configuration if and only
if it remains at the same link. if it remains at the same link.
A host receives the link information from RA (Router Advertisement) A host receives the link information from RA (Router Advertisement)
messages. However, as described in 2.2. [4], it's difficult for a messages. However, as described in 2.2. [4], it's difficult for a
host to correctly detect the identity of a link with a single RA. host to correctly detect the identity of a link with a single RA.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
valid lifetime can at most be assigned to one link at any given time. valid lifetime can at most be assigned to one link at any given time.
For the purposes of determining the prefixes, this specification uses For the purposes of determining the prefixes, this specification uses
both 'on-link' and 'addrconf' prefixes [1], that is, prefixes that both 'on-link' and 'addrconf' prefixes [1], that is, prefixes that
have either the 'on-link' flag set, the 'autonomous address- have either the 'on-link' flag set, the 'autonomous address-
autoconfiguration' flag set, or both flags set. This is a safe autoconfiguration' flag set, or both flags set. This is a safe
approach since both the set of valid on-link and the set of valid approach since both the set of valid on-link and the set of valid
addrconf prefixes must be uniquely assigned to one link. addrconf prefixes must be uniquely assigned to one link.
While the approach is conceptually simple, the difficulty lies both While the approach is conceptually simple, the difficulty lies both
in ensuring that the host knows the complete prefix list for a single in ensuring that the host knows the Complete Prefix List for a single
link, and preventing prefixes from possibly different links to be link, and preventing prefixes from possibly different links to be
viewed as the prefixes for a single link. This is challenging for viewed as the prefixes for a single link. This is challenging for
several reasons: A single RA is not required to include all prefixes several reasons: A single RA is not required to include all prefixes
for the link, RAs might be subject to packet loss, new routers and for the link, RAs might be subject to packet loss, new routers and
new prefixes (due to renumbering) might appear at any time on a link, new prefixes (due to renumbering) might appear at any time on a link,
and the host might move to a different link at any time. and the host might move to a different link at any time.
If the prefix list determination is incorrect, there can be two If the prefix list determination is incorrect, there can be two
different types of failures. One is detecting a new link when in different types of failures. One is detecting a new link when in
fact the host remains attached to the same link. The other is fact the host remains attached to the same link. The other is
skipping to change at page 5, line 25 skipping to change at page 5, line 25
attached to multiple links at the same time. Though this kind of attached to multiple links at the same time. Though this kind of
multiple attachments is allowed in neither Ethernet nor 802.11b, it multiple attachments is allowed in neither Ethernet nor 802.11b, it
may be possible in some Cellular System, especially CDMA. may be possible in some Cellular System, especially CDMA.
This assumption implies that, should the host use a layer 2 This assumption implies that, should the host use a layer 2
technology which can be multiply connected, this needs to be technology which can be multiply connected, this needs to be
represented to the DNA (and layer 3 on the host in general), as represented to the DNA (and layer 3 on the host in general), as
separate (virtual) interfaces, so that the DNA module can associate separate (virtual) interfaces, so that the DNA module can associate
each received RA message with a particular (virtual) interface. each received RA message with a particular (virtual) interface.
We also assume that when a host changes its attachment point, the DNA We also assume that when a host changes its Point of Attachment, the
module will be notified of the event using some form of 'link UP' DNA module will be notified of the event using some form of 'link UP'
event notification, and that the DNA module determine which RAs event notification, and that the DNA module determines which RAs
arrived before the event and which arrived after the event [9]. This arrived before the event and which arrived after the event [9]. This
assumption places some requirements on the host implementation, but assumption places some requirements on the host implementation, but
does not place any assumptions on the layer 2 protocol. does not place any assumptions on the layer 2 protocol.
It is possible to have CPL operate in less robust fashion when the It is possible to have CPL operate in less robust fashion when the
implementation does not provide such a 'link UP' event notification. implementation does not provide such a 'link UP' event notification.
We mention this possibility in Section 5. We mention this possibility in Section 5.
2.3 Overview 2.3 Overview
Hints are used to tell a host that a link change might have happened. Hints are used to tell a host that a link change might have happened.
This hint itself doesn't confirm a link change, but can be used to This hint itself doesn't confirm a link change, but can be used to
initiate the appropriate procedures [4]. initiate the appropriate procedures [4].
In order to never view two different links as one it is critical that In order to never view two different links as one, it is critical
when the host might have attached to a link, there has to be some that when the host might have attached to a link, there has to be
form of hint. This hint doesn't imply that a movement to a different some form of hint. This hint doesn't imply that a movement to a
link has occurred, but instead, in the absence of such a hint there different link has occurred, but instead, in the absence of such a
could not have been an attachment to a different link. hint there could not have been an attachment to a different link.
If the IP stack is notified by the link layer when a new attachment If the IP stack is notified by the link layer when a new attachment
is established (e.g., when associating to a different access point in is established (e.g., when associating to a different access point in
802.11), this will serve as such a hint. It helps to reduce the risk 802.11), this will serve as such a hint. It helps to reduce the risk
that the assignment of an additional prefix to a link will be that the assignment of an additional prefix to a link will be
misinterpreted as being attached to a different link. Note that this misinterpreted as being attached to a different link. Note that this
hint is merely a local notification and does not require any protocol hint is merely a local notification and does not require any protocol
changes. For instance, in many implementations this would be a changes. For instance, in many implementations this would be a
notification passed from a link-layer device driver to the IP layer notification passed from a link-layer device driver to the IP layer
[9]. [9].
skipping to change at page 6, line 23 skipping to change at page 6, line 23
more common prefixes it is safe to assume that the host is attached more common prefixes it is safe to assume that the host is attached
to the same link, in which case the prefixes learned after the hint to the same link, in which case the prefixes learned after the hint
can be merged with the prefixes learned before the hint. But if the can be merged with the prefixes learned before the hint. But if the
sets of valid prefixes are disjoint, then at some point in time the sets of valid prefixes are disjoint, then at some point in time the
host will decide that it is attached to a different link. host will decide that it is attached to a different link.
The process of collecting valid prefixes starts when the host is The process of collecting valid prefixes starts when the host is
powered on and first attaches to a link. powered on and first attaches to a link.
Since each RA message isn't guaranteed to contain all valid prefixes Since each RA message isn't guaranteed to contain all valid prefixes
it is a challenge for a host to attain and retain the complete prefix it is a challenge for a host to attain and retain the Complete Prefix
list, especially when packets can be lost on the link. List, especially when packets can be lost on the link.
The host has to rely on approximate knowledge of the prefix list The host has to rely on approximate knowledge of the prefix list
using RS/ RA exchanges. Just as specified in [1], when the host using RS/ RA exchanges. Just as specified in [1], when the host
attaches to a potentially new link, it sends an RS message to All- attaches to a potentially new link, it sends an RS (Router
Router multicast address, then waits for the solicited RAs. If there Solicitation) message to All-Router multicast address, then waits for
was no packet loss, the host would receive the RAs from all the the solicited RAs. If there was no packet loss, the host would
routers on the link in a few seconds thereby knowing all the valid receive the RAs from all the routers on the link in a few seconds
prefixes on the link. Taking into account packet loss, the host may thereby knowing all the valid prefixes on the link. Taking into
need to perform RS/ RA exchanges multiple times to corroborate the account packet loss, the host may need to perform RS/ RA exchanges
result. multiple times to corroborate the result.
When a hint indicating a possible link change happens, if the host is When a hint indicating a possible link change happens, if the host is
reasonably sure that its prefix list is complete, it can determine reasonably sure that its prefix list is complete, it can determine
whether it is attached to the same link on the reception of just one whether it is attached to the same link on the reception of just one
RA containing one or more valid prefixes. RA containing one or more valid prefixes.
Otherwise, to make matters certain, the host may need to attempt Otherwise, to make matters certain, the host may need to attempt
further procedures. A first step to clarify link identity is to wait further procedures. A first step to clarify link identity is to wait
for all RAs which would have been sent in response to the RS. A for all RAs which would have been sent in response to the RS. A
further step is to send multiple RSs (and wait for the resulting further step is to send multiple RSs (and wait for the resulting
RAs). RAs).
All tracking of the prefix lists must take the valid lifetime of the All tracking of the prefix lists must take the valid lifetime of the
prefixes into account. The prefix list is maintained separately per prefixes into account. The prefix list is maintained separately per
network interface. network interface.
3. DNA based on the complete prefix list 3. DNA based on the Complete Prefix List
We choose to identify a link by the set of valid prefixes that are We choose to identify a link by the set of valid prefixes that are
assigned to the link, and we denote this 'the complete prefix list'. assigned to the link, and we denote this 'the Complete Prefix List'.
Each link has its unique complete prefix list. We also say that the Each link has its unique Complete Prefix List. We also say that the
prefix list is complete if all the prefixes on the link belong to it. prefix list is complete if all the prefixes on the link belong to it.
In case that a host has the complete prefix list, it can properly In case that a host has the Complete Prefix List, it can properly
determine whether it is attached to the same link or not, when it determine whether it is attached to the same link or not, when it
receives a single RA message after a hint that a link change might receives a single RA message after a hint of possible link change.
have occurred.
This section presents a procedure to generate the complete prefix This section presents a procedure to generate the Complete Prefix
list and a way to detect the link identity based on the existing List and a way to detect the link identity based on the existing
prefix list even in the presence of packet losses. prefix list even in the presence of packet losses.
3.1 Complete prefix list generation 3.1 Complete Prefix List generation
To efficiently check for link change, a host always maintains the To efficiently check for link change, a host always maintains the
list of all known prefixes on the link. This procedure of attaining list of all known prefixes on the link. This procedure of attaining
and retaining the complete prefix list is initialized when the host and retaining the Complete Prefix List is initialized when the host
is powered on. is powered on.
The host forms the prefix list at any attachment point, that is, this The host forms the prefix list at any PoA (Point of Attachment), that
process starts independently of any movement. Though the procedure is, this process starts independently of any movement. Though the
may take some time, that doesn't matter unless the host moves very procedure may take some time, that doesn't matter unless the host
fast. A host can generate the complete prefix list with reasonable moves very fast. A host can generate the Complete Prefix List with
certainty if it remains attached to a link sufficiently long. It reasonable certainty if it remains attached to a link sufficiently
will take approximately 12 seconds, when it actively perform 3 RS/ RA long. It will take approximately 4 seconds, when it actively
exchanges. If it passively relies on unsolicited RA messages performs 1 RS/ RA exchanges. If it passively relies on unsolicited
instead, it may take much more time. RA messages instead, it may take much more time.
First the host sends an RS to All-Router multicast address. Assuming First the host sends an RS to All-Router multicast address. Assuming
there is no packet loss, every router on the link would receive the there is no packet loss, every router on the link would receive the
RS and usually reply with an RA containing all the prefixes that the RS and usually reply with an RA containing all the prefixes that the
router advertises. However, RFC 2461 mandates certain delays for the router advertises. However, RFC 2461 mandates certain delays for the
RA transmissions. RA transmissions.
After an RS transmission, the host waits for all RAs that would have After an RS transmission, the host waits for all RAs that would have
been triggered by the RS. There is an upper limit on the delay of been triggered by the RS. There is an upper limit on the delay of
the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec) the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec)
+ network propagation delay is the maximum delay between an RS and + network propagation delay is the maximum delay between an RS and
the resulting RAs [1]. 4 seconds would be a safe number for the host the resulting RAs [1]. 4 seconds would be a safe number for the host
to wait for the resulting RAs. Assuming no packet loss, within 4 to wait for the solicited RAs. Assuming no packet loss, within 4
seconds, the host would receive all the RAs and know all the seconds, the host would receive all the RAs and know all the
prefixes. Thus we pick 4 seconds as the value for MAX_RA_WAIT. prefixes. Thus we pick 4 seconds as the value for MAX_RA_WAIT.
In case of packet loss, things get more complicated. In the above In case of packet loss, things get more complicated. In the above
process, there may be a packet loss that results in the generation of process, there may be a packet loss that results in the generation of
the incomplete prefix list, i.e. the prefix list that misses some the Incomplete Prefix List, i.e. the prefix list that misses some
prefix on the link. To remedy this deficiency, the host may perform prefix on the link. To remedy this deficiency, the host may perform
multiple RS/ RA exchanges to collect all the assigned prefixes. multiple RS/ RA exchanges to collect all the assigned prefixes.
After one RS/ RA exchange, to corroborate the completeness of the After one RS/ RA exchange, to corroborate the completeness of the
prefix list, the host may send additional RSs and wait for the prefix list, the host may send additional RSs and wait for the
resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS
[1]. The host takes the union of the prefixes from all the RAs to [1]. The host takes the union of the prefixes from all the RAs to
generate the prefix list. The more RS/ RA exchange the host generate the prefix list. The more RS/ RA exchange the host
performs, the more probable that the resulting prefix list is performs, the more probable that the resulting prefix list is
complete. Section 11 gives the detailed analysis. complete. Section 11 gives the detailed analysis.
To ascertain whether its existing prefix list is complete or not, the To ascertain whether its existing prefix list is complete or not, the
host can set its own policy. The host may take into consideration host can set its own policy. The host may take into consideration
the estimated packet loss rate of the link and the number of RAs it the estimated packet loss rate of the link and the number of RS/ RA
received or should have received from each router while it was exchanges it performed or should have performed while it was attached
attached to the link. Per [1] each router should multicast a RA at to the link.
least every 1800 seconds. Furthermore, [5] defines a Advertisement
Interval option, which the host can use to determine how often it
should receive RAs.
For example, the host may keep track of how many RAs it has received
from each router on this attachment point, and if this is 3 or more
it assumes that the resulting prefix list is complete. But if this
is only 1 or 2, the host doesn't assume the completeness of the
prefix list.
In general, the higher the error rate, the longer time and more RA In general, the higher the error rate, the longer time and more RA
transmissions from the routers are needed to assure the completeness transmissions from the routers are needed to assure the completeness
of the prefix list. of the prefix list.
3.2 Erroneous Prefix Lists 3.2 Erroneous Prefix Lists
The host may generate either 1) the incomplete prefix list, i.e. the The host may generate either 1) the Incomplete Prefix List, i.e. the
prefix list does not include all the prefixes that are assigned to prefix list that does not include all the prefixes that are assigned
the link or 2) the superfluous prefix list, i.e. the prefix list that to the link or 2) the Superfluous Prefix List, i.e. the prefix list
contains some prefix that is not assigned to the link. that contains some prefix that is not assigned to the link.
It is noted that 1) and 2) is not exclusive. The host may generate It is noted that 1) and 2) are not exclusive. The host may generate
the prefix list that excludes some prefix on the link but includes the prefix list that excludes some prefix on the link but includes
the prefix not assigned to the link. the prefix not assigned to the link.
Severe packet losses during prefix list generation may cause the Severe packet losses during prefix list generation may cause the
incomplete prefix list. Or the host may have undergone a link change Incomplete Prefix List. Or the host may have undergone a link change
before finishing the procedure of the complete prefix list before finishing the procedure of the Complete Prefix List
generation. Later we will deal with the case that the host can't be generation. Later we will deal with the case that the host can't be
sure of the completeness of the prefix list. sure of the completeness of the prefix list.
Even if the host falsely assumes that the incomplete prefix list is Even if the host falsely assumes that the Incomplete Prefix List is
complete, the effect of that assumption is that the host might later complete, the effect of that assumption is that the host might later
think it has moved to a different link when in fact it has not. think it has moved to a different link when in fact it has not.
In case that a link change happens, even if the host has the In case that a link change happens, even if the host has the
incomplete prefix list, it will detect a link change. Hence the Incomplete Prefix List, it will detect a link change. Hence the
incomplete prefix list doesn't cause a connection disruption. But it Incomplete Prefix List doesn't cause a connection disruption. But it
may cause extra signaling messages, for example Binding Update may cause extra signaling messages, for example Binding Update
messages in [5]. messages in [5].
The superfluous prefix list presents a more serious problem. The Superfluous Prefix List presents a more serious problem.
Without the assumed 'link UP' event notification from the link-layer, Without the assumed 'link UP' event notification from the link-layer,
the host can't perceive that it has changed its attachment point, the host can't perceive that it has changed its attachment point,
i.e. it has torn down an old link-layer connection and established a i.e. it has torn down an old link-layer connection and established a
new one. We further discuss the issues, should this assumption be new one. We further discuss the issues, should this assumption be
removed, in Section 5. removed, in Section 5.
With the assumed 'link UP' notification, and the assumption of With the assumed 'link UP' notification, and the assumption of
different concurrent layer 2 connections being represented as different concurrent layer 2 connections being represented as
different (virtual) interfaces to the DNA module (see Section 2.2) different (virtual) interfaces to the DNA module (see Section 2.2)
the host will never treat RAs from different links as being part of the host will never treat RAs from different links as being part of
the same link. Hence it can not create a superfluous prefix list. the same link. Hence it will not create a Superfluous Prefix List.
3.3 Link identity detection 3.3 Link identity detection
When a host receives a hint that indicates a possible link change, it When a host receives a hint that indicates a possible link change, it
initiates DNA procedure to determine whether it still remains at the initiates DNA procedure to determine whether it still remains at the
same link or not. At this time, the complete prefix list generation same link or not. At this time, the Complete Prefix List generation
may or may not be finished. may or may not be finished.
First, if the host has finished prefix list generation and can be First, if the host has finished prefix list generation and can be
reasonably sure of its completeness, the receipt of a single RA (with reasonably sure of its completeness, the receipt of a single RA (with
at least one valid prefix) is enough to detect the identify of the at least one valid prefix) is enough to detect the identify of the
currently attached link. currently attached link.
Assume that, after the hint, the host receives an RA that contains at Assume that, after the hint, the host receives an RA that contains at
least one valid prefix. The host compares the valid prefixes in the least one valid prefix. The host compares the valid prefixes in the
RA with those in the existing prefix list. If the RA contains a RA with those in the existing prefix list. If the RA contains a
skipping to change at page 10, line 23 skipping to change at page 10, line 12
attached link. With the resulting prefixes, the host generates the attached link. With the resulting prefixes, the host generates the
second prefix list. second prefix list.
Then the host compares two prefix lists and if the lists are Then the host compares two prefix lists and if the lists are
disjoint, i.e. have no prefix in common, it assumes that a link disjoint, i.e. have no prefix in common, it assumes that a link
change has occurred. Note that if during this procedure, the host change has occurred. Note that if during this procedure, the host
finds a common valid prefix between even one RA and the old prefix finds a common valid prefix between even one RA and the old prefix
list, it can immediately determine that it has not moved to a list, it can immediately determine that it has not moved to a
different link. different link.
For example, assume that the host keeps track of how many RAs it has For example, assume that the host keeps track of how many RS/ RA
received from each router while attached to a link. If this is 3 or exchanges it has performed while attached to a link. If this is more
more, the host assumes that it has seen all the prefixes. Suppose than one, i.e. after the host sends one RS and waits 4 seconds for
that the host has received only one RA from each router, and then it the resulting RAs, the host assumes that it has seen all the
receives a link UP notification that causes it to initiate the DNA prefixes. Suppose that the host doesn't complete even 1 RS/ RA
procedure. If the first RA does not have a valid prefix which is exchange, and then it receives a link UP notification that causes it
common with the old prefixes, then the host needs to wait for to initiate the DNA procedure. If the first RA does not have a valid
additional RAs, and perhaps also send additional RSs and wait for the prefix which is common with the old prefixes, then the host needs to
resulting RAs. In case that the lists are disjoint, the host can wait for additional RAs to complete 1 RS/ RA exchange. In case that
assume it has moved. the lists are disjoint, the host can assume it has moved.
In summary, first a host makes the complete prefix list. When a hint In summary, first a host makes the Complete Prefix List. When a hint
occurs, if the host decides that the prefix list is complete, it will occurs, if the host decides that the prefix list is complete, it will
check for link change with just one RA (with a prefix). Otherwise, check for link change with just one RA (with a prefix). Otherwise,
in case that the host can't be so sure, it will perform additional in case that the host can't be so sure, it will wait for additional
RS/ RA exchanges to corroborate the decision. RAs to corroborate the decision.
3.4 Renumbering 3.4 Renumbering
When the host is sure that the prefix list is complete, a false When the host is sure that the prefix list is complete, a false
movement assumption may happen due to renumbering when a new prefix movement assumption may happen due to renumbering when a new prefix
is introduced in RAs at about the same time as the host handles the is introduced in RAs at about the same time as the host handles the
'link UP' event. We may solve the renumbering problem with minor 'link UP' event. We may solve the renumbering problem with minor
modification like below. modification like below.
When a router starts advertising a new prefix, for the time being, When a router starts advertising a new prefix, for the time being,
every time the router advertises a new prefix in an RA, it includes every time the router advertises a new prefix in an RA, it includes
at least one old prefix in the same RA. The old prefix assures that at least one old prefix in the same RA. The old prefix assures that
the host doesn't falsely assume a link change because of a new the host doesn't falsely assume a link change because of a new
prefix. After a while, hosts will recognize the new prefix as the prefix. After a while, hosts will recognize the new prefix as the
one assigned to the current link and update its prefix list. one assigned to the current link and update its prefix list.
In this way, we may provide a fast and robust solution. If a host In this way, we may provide a fast and robust solution. If a host
can make the complete prefix list with certainty, it can check for can make the Complete Prefix List with certainty, it can check for
link change fast. Otherwise, it can fall back on a slow but robust link change fast. Otherwise, it can fall back on a slow but robust
scheme. It is up to the host to decide which scheme to use. scheme. It is up to the host to decide which scheme to use.
4. Protocol Specification 4. Protocol Specification
This section provides the actual specification for a host This section provides the actual specification for a host
implementing this draft. For generality the specification assumes implementing this draft. For generality the specification assumes
that the host retains multiple (an unbounded set) of prefix lists that the host retains multiple (an unbounded set) of prefix lists
until the information times out, while an actual implementation would until the information times out, while an actual implementation would
limit the number of sets maintained. limit the number of sets maintained.
skipping to change at page 13, line 24 skipping to change at page 12, line 24
received (called time_last_RA_received in this document), which received (called time_last_RA_received in this document), which
actually ignores RAs without prefix options, and the last time a link actually ignores RAs without prefix options, and the last time a link
UP notification was received from the link layer on the host (called UP notification was received from the link layer on the host (called
time_last_linkUP_received in this document). Together these two time_last_linkUP_received in this document). Together these two
conceptual variables serve to identify when a RA containing disjoint conceptual variables serve to identify when a RA containing disjoint
prefixes can't be due to being attached to a new link, because there prefixes can't be due to being attached to a new link, because there
was no link UP notification. was no link UP notification.
For each interface, the host also maintains a counter (called For each interface, the host also maintains a counter (called
num_RS_RA) which counts how many successful RS/RA exchanges have been num_RS_RA) which counts how many successful RS/RA exchanges have been
performed since the last time the host moved to a different link. By accomplished since the last time the host moved to a different link.
"successful exchange" we mean an RS that resulted in receiving at The host declares "one successful RS/RA exchange" is accomplished
least one RA (with at least one prefix) within MAX_RA_WAIT seconds. after it sends an RS, waits for MAX_RA_WAIT seconds and receives a
This counter is used to determine when prefix list is considered to positive number of resulting RAs. At least one RA (with at least one
be complete. This document considers it to be complete when prefix) should be received. After the RS, if a link UP event occurs
NUM_RS_RA_COMPLETE (set to 1) number of successful RS/RA exchanges before MAX_RA_WAIT seconds expire, the host should not assume that a
have been performed. successful RS/RA exchange is accomplished. This counter is used to
determine when prefix list is considered to be complete. This
document considers it to be complete when NUM_RS_RA_COMPLETE (set to
1) number of RS/RA exchanges have been completed.
After one RS/ RA exchange, the host will generate the Complete Prefix
List if there is no packet loss. Even some packet loss may cause an
Incomplete Prefix List, there is a further chance for the host to get
the missing prefixes before it receives link UP notification, i.e.
moves to another PoA. Even the host moves to another PoA with
Incomplete Prefix List, the first RA may contain the prefix in its
prefix list. Considering all those above, even if the host performs
only one RS/ RA exchange, it will be rather rare for the host to
falsely assume a link change. Moreover, even in case of false
detection, there would be no connectivity disruption, because
Incomplete Prefix List causes only additional signaling. This
document proposes a host to send 1 RS and waits for 4 secs to collect
(solicited) RAs and declare CCL complete.
4.2 Merging Candidate Link objects 4.2 Merging Candidate Link objects
When a host has been collecting information about a potentially When a host has been collecting information about a potentially
different link in its Current Candidate Link object, and it discovers different link in its Current Candidate Link object, and it discovers
that it is in fact the same link as another Candidate Link object, that it is in fact the same link as another Candidate Link object,
then it needs to merge the information in the two objects to produce then it needs to merge the information in the two objects to produce
a single new object. Since the CCL contains the most recent a single new object. Since the CCL contains the most recent
information, any information contained in it will override the information, any information contained in it will override the
information in the old Candidate Link, for example the remaining information in the old Candidate Link, for example the remaining
skipping to change at page 15, line 42 skipping to change at page 15, line 10
It is possible that the above comparison will result in matching It is possible that the above comparison will result in matching
multiple Candidate Link objects. For example, if the RA contains the multiple Candidate Link objects. For example, if the RA contains the
prefixes P1 and P2, and there is one Candidate Link object with P1 prefixes P1 and P2, and there is one Candidate Link object with P1
and P3 and other Candidate Link object with P2 and P4. This should and P3 and other Candidate Link object with P2 and P4. This should
not happen during normal operation, but if links have been renumbered not happen during normal operation, but if links have been renumbered
or physically separate links have been made into one link (before the or physically separate links have been made into one link (before the
lifetimes in the Candidate Link objects expired), then the host could lifetimes in the Candidate Link objects expired), then the host could
observe this. One possible action in this case would be for the host observe this. One possible action in this case would be for the host
to merge all such matching Candidate Link objects together with the to merge all such matching Candidate Link objects together with the
information in the receive RA and make this the new CCL. Doing this information in the received RA and make this the new CCL. Doing this
merging correctly requires that each Candidate Link object contains merging correctly requires that each Candidate Link object contains
the time it was last updated by a RA, so that more recent information the time it was last updated by a RA, so that more recent information
can override older information. The security issues involved in such can override older information. The security issues involved in such
merging is the prime motivation for not allowing the Candidate Link merging is the prime motivation for not allowing the Candidate Link
objects to be shared between different interfaces. objects to be shared between different interfaces.
The easy cases of staying on the same link or moving to a previously The easy cases of staying on the same link or moving to a previously
visited link have been handled above. The harder case is when the visited link have been handled above. The harder case is when the
first RA after a link UP notification contains prefixes that are new first RA after a link UP notification contains prefixes that are new
to the host. If the host considers its Current Candidate Link object to the host. If the host considers its Current Candidate Link object
complete (num_RS_RA is at least NUM_RS_RA_COMPLETE), then a RS where complete (num_RS_RA is at least NUM_RS_RA_COMPLETE), then an RA where
the prefixes are disjoint from those in the CCL, can be assumed to be the prefixes are disjoint from those in the CCL, can be assumed to be
a link change in accordance with Section 4.6. If the CCL is not a link change in accordance with Section 4.6. If the CCL is not
considered to be complete, then it isn't obvious whether the host has considered to be complete, then it isn't obvious whether the host has
moved or not, because a new prefix could have been added to the moved or not, because the CCL might have missed the prefixes in the
existing link instead of being associated with a different link. In received RA instead of being associated with a different link. In
order to distinguish those to cases the host needs to do some extra order to distinguish those two cases the host needs to do some extra
work. Thus the host needs to create a new Candidate Link object work. Thus the host needs to create a new Candidate Link object
based on the received RA, and make this object the CCL. However, it based on the received RA, and make this object the CCL. However, it
does not yet treat this as a new link; it is merely a candidate. does not yet treat this as a new link; it is merely a candidate.
Thus it MUST NOT perform the actions in Section 4.6 at this point in Thus it MUST NOT perform the actions in Section 4.6 at this point in
time. Instead, the host should wait for MAX_RA_WAIT seconds, and all time. Instead, the host should wait for MAX_RA_WAIT seconds, and all
RAs that are received during that time interval are processed as RAs that are received during that time interval are processed as
specified above. specified above.
This processing might result in finding a prefix in common between a This processing might result in finding a prefix in common between a
Candidate Link object and the CCL, in which case the host knows Candidate Link object and the CCL, in which case the host knows
skipping to change at page 19, line 19 skipping to change at page 18, line 19
which contains prefix P4. It can not tell whether this RA was in which contains prefix P4. It can not tell whether this RA was in
response to the RS it send above. The host ends up adding this response to the RS it send above. The host ends up adding this
to the CCL, which now has P3 and P4, even though those prefixes to the CCL, which now has P3 and P4, even though those prefixes
are assigned to different links. are assigned to different links.
There doesn't appear to be a way to solve this problem without There doesn't appear to be a way to solve this problem without
changes to the routers and the Router Advertisement messages. changes to the routers and the Router Advertisement messages.
However, the probability of this occurring can be limited by limiting However, the probability of this occurring can be limited by limiting
the window of exposure. The simplest approach is for the host to the window of exposure. The simplest approach is for the host to
assume that any RA received within MAX_RA_WAIT seconds after sending assume that any RA received within MAX_RA_WAIT seconds after sending
a RS was in response to the RS. Basically this relies on the small an RS was in response to the RS. Basically this relies on the small
probability of both moving again in that MAX_RA_WAIT second interval, probability of both moving again in that MAX_RA_WAIT second interval,
and receiving one of the periodic RAs. If the periodic RAs are sent and receiving one of the periodic RAs. If the periodic RAs are sent
infrequently enough, this might work in practise, but is by no means infrequently enough, this might work in practise, but is by no means
bullet-proof. bullet-proof.
6. IANA Considerations 6. IANA Considerations
No new message formats or services are defined in this document. No new message formats or services are defined in this document.
7. Security Considerations 7. Security Considerations
skipping to change at page 26, line 8 skipping to change at page 25, line 8
10. Acknowledgements 10. Acknowledgements
The authors would like to acknowledge the many careful comments from The authors would like to acknowledge the many careful comments from
Greg Daley that helped improve the clarity of the document, as well Greg Daley that helped improve the clarity of the document, as well
as the review of the DNA WG participants in general. as the review of the DNA WG participants in general.
11. Performance Analysis 11. Performance Analysis
In this section, we compute the probability that a host fails to In this section, we compute the probability that a host fails to
generate the complete prefix list due to packet loss, and generate the Complete Prefix List due to packet loss, and
consequently assumes a link change when the host in fact did not move consequently assumes a link change when the host in fact did not move
to a different link. to a different link.
Suppose, in a link, there are N routers, R[1], R[2],...., R[N]. Suppose, in a link, there are N routers, R[1], R[2],...., R[N].
Each R[i] advertises the Router Advertisement RA[i] with the prefix Each R[i] advertises the Router Advertisement RA[i] with the prefix
P[i]. P[i].
It is the worst case that each router advertises the different It is the worst case that each router advertises the different
prefix. It is necessary to receive all the RA[i] to generate the prefix. It is necessary to receive all the RA[i] to generate the
complete prefix list. Complete Prefix List.
We assume there is a host, H, and when the host sends a Router We assume there is a host, H, and when the host sends a Router
Solicitation, let P be the probability that it fails to receive a Solicitation, let P be the probability that it fails to receive a
RA[i] because of a RA loss. For the simplicity, we disregard RS RA[i] because of a RA loss. For the simplicity, we disregard RS
losses. losses.
So when the sends a Router Solicitation, the probability that it will So when the sends a Router Solicitation, the probability that it will
receive all RA[i] is (1-P)^N. receive all RA[i] is (1-P)^N.
Let's assume the host performs RS/ RA exchange T times, 1,2,..,T. Let's assume the host performs RS/ RA exchange T times, 1,2,..,T.
skipping to change at page 26, line 42 skipping to change at page 25, line 42
at k-th RS/RA exchange. The probability that R[i] belongs to S[k] is at k-th RS/RA exchange. The probability that R[i] belongs to S[k] is
(1-P). (1-P).
Let PL[k] be the set of prefixes which are made from S[k], i.e. the Let PL[k] be the set of prefixes which are made from S[k], i.e. the
set of P[j] such that RA[j] belongs to S[k]. Obviously, the set of P[j] such that RA[j] belongs to S[k]. Obviously, the
probability that P[i] belongs to PL[k] is also (1-P). probability that P[i] belongs to PL[k] is also (1-P).
Let PL be the union of all PL[k], from k=1 to k=T. PL is the prefix Let PL be the union of all PL[k], from k=1 to k=T. PL is the prefix
list made from performing RS/ RA exchange T times. list made from performing RS/ RA exchange T times.
1) The probability of the complete prefix list generation 1) The probability of the Complete Prefix List generation
First the probability that P[i] belongs to PL is 1-P^T. The First the probability that P[i] belongs to PL is 1-P^T. The
probability that the prefix list PL is complete is (1-P^T)^N. probability that the prefix list PL is complete is (1-P^T)^N.
For example, assume the error rate is 1 % and there are 3 routers in For example, assume the error rate is 1 % and there are 3 routers in
a link, then, with 2 RS/ RA exchanges, the probability of generating a link, then, with 2 RS/ RA exchanges, the probability of generating
an accurate Complete Prefix List is roughly 99.97 %. an accurate Complete Prefix List is roughly 99.97 %.
At this point, assume that the host H receives a hint that a link At this point, assume that the host H receives a hint that a link
change might have happened and consequently initiates the procedure change might have happened and consequently initiates the procedure
skipping to change at page 28, line 7 skipping to change at page 27, line 7
We think it is reasonable to assume that the RS will be retransmitted We think it is reasonable to assume that the RS will be retransmitted
until at least one RA arrives. If we take a one more assumption that until at least one RA arrives. If we take a one more assumption that
the host receives at least one RA, the probability will be the host receives at least one RA, the probability will be
[[P^T + P^U - P(T+U)]^N - P^(U*N)]/ [1- P^(U*N)] [[P^T + P^U - P(T+U)]^N - P^(U*N)]/ [1- P^(U*N)]
The above converges to zero as T approaches infinity. The above converges to zero as T approaches infinity.
12. Change Log 12. Change Log
The following changes have been made since draft-ietf-dna-cpl-01:
o A few editorial changes. For example, we use the term 'PoA (Point
of Attachment)' instead of attachment point in accordance with
DNAv4 draft [12].
o Clarify further that a host is recommended to declare its prefix
list complete after 1 RS/ RA exchange. We also added a text about
why it is recommended such in section 4.1.
o Make the definition of "successful exchange" more precise in
section 4.1.
The following changes have been made since draft-ietf-dna-cpl-00: The following changes have been made since draft-ietf-dna-cpl-00:
o Many editorial fixes o Many editorial fixes
o Added a count to the CCL to track whether it is likely to be o Added a count to the CCL to track whether it is likely to be
complete (num_RS_RA) complete (num_RS_RA)
o Set the default threshold for this count to 1, that is, after a o Set the default threshold for this count to 1, that is, after a
single RS/RA exchange that resulted in at least one RA being single RS/RA exchange that resulted in at least one RA being
received with a useful prefix, the prefix list will be considered received with a useful prefix, the prefix list will be considered
skipping to change at page 29, line 18 skipping to change at page 30, line 5
notifications? The technique in Section 5 is far from bullet- notifications? The technique in Section 5 is far from bullet-
proof. proof.
o Flash renumbering and immediate reassignment may cause a problem. o Flash renumbering and immediate reassignment may cause a problem.
Assume a prefix is suddenly removed from one link and immediately Assume a prefix is suddenly removed from one link and immediately
reassigned to an another link. A host in first link may not reassigned to an another link. A host in first link may not
perceive the prefix removal and mistakenly assume the prefix is perceive the prefix removal and mistakenly assume the prefix is
still valid. If the host moves to the second link and check for still valid. If the host moves to the second link and check for
link change with the prefix, it will make a false decision. link change with the prefix, it will make a false decision.
o The document currently proposes that hosts send one RS (and
retransmit until at least one RA is received) after a hint, and
afterwards wait for 2 additional unsolicited RAs from each router,
before declaring the prefix list complete. With the default
timers in RFC 2461 this will take a long time (60-90 minutes).
Should we instead recommend that the host send 2 or 3 RSs
initially? If so, how frequently? The additional RSs will
increase the total amount of multicast packets on the link -
perhaps significantly - so there are some tradeoffs involved here.
14. References 14. References
14.1 Normative References 14.1 Normative References
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address [2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[4] Choi, J., "Goals of Detecting Network Attachment in IPv6", [4] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
draft-ietf-dna-goals-04 (work in progress), December 2004. in IPv6", RFC 4135, August 2005.
14.2 Informative References 14.2 Informative References
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[6] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. [6] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P.
Nikander, "SEcure Neighbor Discovery (SEND)", Nikander, "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-06 (work in progress), July 2004. draft-ietf-send-ndopt-06 (work in progress), July 2004.
[7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [7] 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.
[8] Choi, J. and E. Nordmark, "DNA solution framework", [8] Choi, J. and E. Nordmark, "DNA solution framework",
draft-jinchoi-dna-soln-frame-00 (work in progress), July 2004. draft-jinchoi-dna-soln-frame-00 (work in progress), July 2004.
[9] Yegin, A., "Link-layer Event Notifications for Detecting [9] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-01 (work Network Attachments", draft-ietf-dna-link-information-03 (work
in progress), February 2005. in progress), October 2005.
[10] Pentland, B., "An Overview of Approaches to Detecting Network [10] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005. progress), February 2005.
[11] Draves, R. and D. Thaler, "Default Router Preferences and More- [11] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", draft-ietf-ipv6-router-selection-07 (work in Specific Routes", draft-ietf-ipv6-router-selection-07 (work in
progress), January 2005. progress), January 2005.
[12] Aboba, B., "Detecting Network Attachment in IPv4 (DNAv4)",
draft-ietf-dhc-dna-ipv4-18 (work in progress), December 2005.
Authors' Addresses Authors' Addresses
JinHyeock Choi JinHyeock Choi
Samsung AIT Samsung AIT
Communication & N/W Lab Communication 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
Email: jinchoe@samsung.com Email: jinchoe@samsung.com
Erik Nordmark Erik Nordmark
Sun Microsystems Sun Microsystems
17 Network Circle 17 Network Circle
Menlo Park, CA 94043 Menlo Park, CA 94043
skipping to change at page 32, line 41 skipping to change at page 32, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 56 change blocks. 
143 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/