draft-ietf-dna-cpl-00.txt   draft-ietf-dna-cpl-01.txt 
DNA WG JinHyeock Choi DNA WG J. Choi
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: October 23, 2005 Erik Nordmark Expires: October 3, 2005 E. Nordmark
SUN Microsystems Sun Microsystems
April 21, 2005 April 2005
DNA with unmodified routers: Prefix list based approach DNA with unmodified routers: Prefix list based approach
draft-ietf-dna-cpl-00.txt draft-ietf-dna-cpl-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 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 23, 2005. This Internet-Draft will expire on October 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 therefor needs new IP configuration. This draft
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . 12
4.1 Conceptual data structures . . . . . . . . . . . . . . . . 12 4.1 Conceptual data structures . . . . . . . . . . . . . . . . 12
4.2 Merging Candidate Link objects . . . . . . . . . . . . . . 13 4.2 Merging Candidate Link objects . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . 17 5. CPL without a 'link UP' notification . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . 21
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Example with link UP event notification . . . . . . . . . 21 8.1 Example with link UP event notification . . . . . . . . . 22
8.2 Example without link UP event notification . . . . . . . . 21 8.2 Example without link UP event notification . . . . . . . . 22
9. Performance Analysis . . . . . . . . . . . . . . . . . . . . 23 9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 24
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Performance Analysis . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1 Normative References . . . . . . . . . . . . . . . . . . 27 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29
12.2 Informative References . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 14.1 Normative References . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 29 14.2 Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
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 attachment point (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 than the definition of the
skipping to change at page 4, line 22 skipping to change at page 4, line 22
'The set of all the valid and global prefixes assigned to a link.' 'The set of all the valid and global prefixes assigned to a link.'
If a host has the complete list of all the assigned prefixes, it can If a host has the complete list of all the assigned prefixes, it can
properly determine whether a link change has occurred. If the host properly determine whether a link change has occurred. If the host
receives an RA containing one or more prefixes and none of the receives an RA containing one or more prefixes and none of the
prefixes in it matches the previously known prefixes for the link, prefixes in it matches the previously known prefixes for the link,
then it is assumed to be a new link. then it is assumed to be a new link.
This works because each and every valid global prefix on a link must This works because each and every valid global prefix on a link must
not be used on any other link thus the sets of global prefixes on not be used on any other link thus the sets of global prefixes on
different links must be disjoint. different links must be disjoint [3].
This is the case even as there is renumbering. During graceful This is the case even as there is renumbering. During graceful
renumbering a prefix would gradually have its (preferred and valid) renumbering a prefix would gradually have its (preferred and valid)
lifetimes decrement, until the valid lifetime reaches zero. Some lifetimes decrement, until the valid lifetime reaches zero. Some
point after the valid lifetime has reached zero, the prefix may be point after the valid lifetime has reached zero, the prefix may be
reassigned to some different link. Even during 'flash' renumbering, reassigned to some different link. Even during 'flash' renumbering,
when the prefix isn't allowed to gracefully move through the when the prefix isn't allowed to gracefully move through the
deprecated state [2], independently of DNA, the prefix needs to be deprecated state [2], independently of DNA, the prefix needs to be
advertised with a zero valid lifetime on the old link before it can advertised with a zero valid lifetime on the old link before it can
be reassigned. Thus we can assume that a prefix with a non-zero be reassigned. Thus we can assume that a prefix with a non-zero
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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 attachment point, the DNA
module will be notified of the event using some form of 'link UP' 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 determine which RAs
arrived before the event and which arrived after the event. 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.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
link has occurred, but instead, in the absence of such a hint there link has occurred, but instead, in the absence of such a hint there
could not have been an attachment to a different link. 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].
Once a hint is received the host will start to collect a new set of Once a hint is received the host will start to collect a new set of
valid prefixes for the possibly different link, and compare them with valid prefixes for the possibly different link, and compare them with
the valid prefixes known from before the hint. If there is one or the valid prefixes known from before the hint. If there is one or
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.
skipping to change at page 6, line 40 skipping to change at page 6, line 41
routers on the link in a few seconds thereby knowing all the valid routers on the link in a few seconds thereby knowing all the valid
prefixes on the link. Taking into account packet loss, the host may prefixes on the link. Taking into account packet loss, the host may
need to perform RS/ RA exchanges multiple times to corroborate the need to perform RS/ RA exchanges multiple times to corroborate the
result. 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 at least to Otherwise, to make matters certain, the host may need to attempt
wait for more than the first RAs, or additionally, perform multiple further procedures. A first step to clarify link identity is to wait
RS/ RA exchanges after the hint. The first level of trying harder is for all RAs which would have been sent in response to the RS. A
to, after the RS transmission, wait for all RAs that would have been further step is to send multiple RSs (and wait for the resulting
triggered by the RS. The second level of trying harder is to send RAs).
multiple RSs (and waiting for the resulting 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
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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 resulting 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. 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 9 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 packet loss rate of the link and the number of RAs it received or the estimated packet loss rate of the link and the number of RAs it
should have received from each router while it was attached to the received or should have received from each router while it was
link. Per [1] each router should multicast a RA at least every 1800 attached to the link. Per [1] each router should multicast a RA at
seconds. Furthermore, [5] defines a Advertisement Interval option, least every 1800 seconds. Furthermore, [5] defines a Advertisement
which the host can use to determine how often it should receive RAs. Interval option, which the host can use to determine how often it
should receive RAs.
For example, the host may keep track of how RAs it has received from For example, the host may keep track of how many RAs it has received
each router on this attachment point, and if this is 3 or more it from each router on this attachment point, and if this is 3 or more
assumes that the resulting prefix list is complete. But if this is it assumes that the resulting prefix list is complete. But if this
only 1 or 2, the host doesn't assume the completeness of the prefix is only 1 or 2, the host doesn't assume the completeness of the
list. 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 does not include all the prefixes that are assigned to
the link or 2) the superfluous prefix list, i.e. the prefix list that the link or 2) the superfluous prefix list, i.e. the prefix list that
skipping to change at page 9, line 33 skipping to change at page 9, line 33
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 can 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 generation may same link or not. At this time, the complete prefix list generation
or may not be finished. may or may not be finished.
First, if the host has finished the complete prefix list generation First, if the host has finished prefix list generation and can be
and can be reasonably sure of its completeness, the receipt of a reasonably sure of its completeness, the receipt of a single RA (with
single RA (with at least one valid prefix) is enough to detect the at least one valid prefix) is enough to detect the identify of 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
prefix that is also a member of the existing prefix list, the host is prefix that is also a member of the existing prefix list, the host is
still at the same link. Otherwise, if none of the prefixes in that still at the same link. Otherwise, if none of the prefixes in that
RA matches the previously known prefixes, it is at a different link. RA matches the previously known prefixes, it is at a different link.
If the host is not sure that the prefix list was complete before the If the host is not sure that the prefix list was complete before the
hint reception, then the host needs to take several RAs into account hint reception, then the host needs to take several RAs into account
skipping to change at page 13, line 22 skipping to change at page 13, line 22
For each interface, the host maintains the last time a valid RA was For each interface, the host maintains the last time a valid RA was
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
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
"successful exchange" we mean an RS that resulted in receiving at
least one RA (with at least one prefix) within MAX_RA_WAIT seconds.
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 successful RS/RA exchanges
have been performed.
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
lifetimes for the prefixes. When the two objects contain different lifetimes for the prefixes. When the two objects contain different
skipping to change at page 14, line 17 skipping to change at page 14, line 27
When the host receives a link UP notification from its link layer, it When the host receives a link UP notification from its link layer, it
sets time_last_linkUP_received to the current time. sets time_last_linkUP_received to the current time.
The host also uses this to trigger sending an RS, subject to the rate The host also uses this to trigger sending an RS, subject to the rate
limitations in [1]. Since there is no natural limit on how limitations in [1]. Since there is no natural limit on how
frequently the link UP notifications might be generated, we take the frequently the link UP notifications might be generated, we take the
conservative approach that even if the host establishes new link conservative approach that even if the host establishes new link
layer connectivity very often, under no circumstances should it send layer connectivity very often, under no circumstances should it send
Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL. Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL.
Thus if it handled the most recent link UP notification less than 4 Thus if it handled the most recent link UP notification less than
seconds ago, it can not immediately send one when it processes a link MAX_RA_WAIT seconds ago, it can not immediately send one when it
UP notification. processes a link UP notification.
If the RS does not result in the host receiving at least one RA with If the RS does not result in the host receiving at least one RA with
at least one valid prefix, then the host can retransmit the RS. It at least one valid prefix, then the host can retransmit the RS. It
is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages
spaced RTR_SOLICITATION_INTERVAL apart. spaced RTR_SOLICITATION_INTERVAL apart.
Note that if link-layer notifications are reliable, a host can reset
the number of sent Router Solicitations to 0, while still maintaining
RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is
necessary so that after each link up notification, the host is
allowed to send MAX_RTR_SOLICITATIONS to reliably discover the,
possibly new, prefix list.
4.5 Receiving valid Router Advertisements 4.5 Receiving valid Router Advertisements
When a host receives a valid RA message (after the validity checks When a host receives a valid RA message (after the validity checks
specified in [1]) it performs the following processing in addition to specified in [1]) it performs the following processing in addition to
the processing specified in [1] and [2] the processing specified in [1] and [2]
If the valid RA does not contain any prefix information options, or If the valid RA does not contain any prefix information options, or
all the prefixes have a zero valid lifetime, then no further all the prefixes have a zero valid lifetime, then no further
processing is performed. Note that not even the processing is performed. Note that not even the
time_last_RA_received is updated. time_last_RA_received is updated.
skipping to change at page 15, line 7 skipping to change at page 15, line 24
recently than time_last_RA_received, we have the case when the host recently than time_last_RA_received, we have the case when the host
needs to perform comparisons of the prefix sets in its Candidate Link needs to perform comparisons of the prefix sets in its Candidate Link
objects and the prefix set in the RA. In this case, objects and the prefix set in the RA. In this case,
time_last_RA_received is always set to the current time. time_last_RA_received is always set to the current time.
Should the received RA contain at least one valid prefix which is in Should the received RA contain at least one valid prefix which is in
the prefix list in the CCL, then the host is still attached to the the prefix list in the CCL, then the host is still attached to the
same link, and just needs to update the CCL with any new information same link, and just needs to update the CCL with any new information
in the RA. in the RA.
Otherwise, if the received RA contains one or more prefixes which is Otherwise, if the received RA contains one or more prefixes which are
part of the prefix list in some retained Candidate Link object, then part of a prefix list in some retained Candidate Link object, then
the host has most likely moved back to that link. In this case the the host has most likely moved back to that link. In this case the
host will retain the content of the CCL for future matching, but host may retain the content of the CCL for future matching, but
switch the CCL to be that matching object. The, now new, CCL should switch the CCL to be that matching object. The, now new, CCL should
be updated based on the information in the RA. Then the DNA module be updated based on the information in the RA. Then the DNA module
informs the Neighbor Discovery module to replace the old information informs the Neighbor Discovery module to replace the old information
with the information in the new CCL as specified in Section 4.6. with the information in the new CCL as specified in Section 4.6.
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. The most sensible action would be for the host to observe this. One possible action in this case would be for the host
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 receive RA and make this the new CCL. Doing this
merging correctly probably requires that each Candidate Link object merging correctly requires that each Candidate Link object contains
contains the time it was last updated by a RA, so that more recent the time it was last updated by a RA, so that more recent information
information can override older information. Note that this case is can override older information. The security issues involved in such
one reason one needs to be concerned about security issues when merging is the prime motivation for not allowing the Candidate Link
Candidate Link objects are shared across multiple 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. In this case it isn't obvious whether the host has 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
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
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 a new prefix could have been added to the
existing link instead of being associated with a different link. In existing link 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 to cases the host needs to do some extra
work. The host handles this by creating a new Candidate Link object work. Thus the host needs to create a new Candidate Link object
which it initializes with the information in the received RA, and based on the received RA, and make this object the CCL. However, it
makes this object the CCL. However, it does not yet treat this as a does not yet treat this as a new link; it is merely a candidate.
new link; it is merely a candidate. Thus it MUST NOT perform the Thus it MUST NOT perform the actions in Section 4.6 at this point in
actions in Section 4.6. time. Instead, the host should wait for MAX_RA_WAIT seconds, and all
RAs that are received during that time interval are processed as
specified above.
Then the host waits for more RA messages. At a minimum it waits for This processing might result in finding a prefix in common between a
4 seconds, that is, it starts a timer and RAs that are received
during that time interval are processed as specified above. 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
whether and to which link it has moved. But should the 4 seconds whether and to which link it has moved. But should the MAX_RA_WAIT
expire without any common prefix, then it will conclude that it has seconds expire without any common prefix, then it will conclude that
moved to a new link and inform the rest of the host of the movement it has moved to a new link and inform the rest of the host of the
(Section 4.6.) Note that the arrival of a new link UP notification movement (Section 4.6.) Note that the arrival of a new link UP
during the 4 second timer must prevent the timer from firing. In notification during the MAX_RA_WAIT second timer must prevent the
this case the host might yet again have moved so it is necessary to MAX_RA_WAIT second timer from firing. In this case the host might
restart the process of inspecting the RAs. yet again have moved so it is necessary to restart the process of
inspecting the RAs.
Subject to local policy, and perhaps also the host's knowledge of the Subject to local policy, and perhaps also the host's knowledge of the
packet loss characteristics of the interface or type of L2 packet loss characteristics of the interface or type of L2
technology, the host can try harder than just waiting for 4 seconds. technology, the host can try harder than just waiting for MAX_RA_WAIT
It is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS seconds, by sending additional Router Solicitations. It is allowed
messages spaced RTR_SOLICITATION_INTERVAL apart. In the most to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages spaced
conservative approach this means a 12 second delay until the host RTR_SOLICITATION_INTERVAL apart. In the most conservative approach
will declare that is has moved to a new link. Just as above, this this means a 12 second delay until the host will declare that is has
process should be terminated should a new link UP notification arrive moved to a new link. Just as above, this process should be
during the 12 seconds. terminated should a new link UP notification arrive during the 12
seconds.
4.6 Changing the link in Neighbor Discovery 4.6 Changing the link in Neighbor Discovery
When DNA detects that it has moved to a different link this needs to When DNA detects that it has moved to a different link this needs to
cause Neighbor Discovery, Address autoconfiguration, and DHCPv6 to cause Neighbor Discovery, Address autoconfiguration, and DHCPv6 to
take some action. While the full implications are outside of the take some action. While the full implications are outside of the
scope of this document, here is what we know about the impact on scope of this document, here is what we know about the impact on
Neighbor Discovery. Neighbor Discovery.
Everything learned from the RAs on the interface should be discarded, Everything learned from the RAs on the interface should be discarded,
skipping to change at page 16, line 30 skipping to change at page 17, line 4
4.6 Changing the link in Neighbor Discovery 4.6 Changing the link in Neighbor Discovery
When DNA detects that it has moved to a different link this needs to When DNA detects that it has moved to a different link this needs to
cause Neighbor Discovery, Address autoconfiguration, and DHCPv6 to cause Neighbor Discovery, Address autoconfiguration, and DHCPv6 to
take some action. While the full implications are outside of the take some action. While the full implications are outside of the
scope of this document, here is what we know about the impact on scope of this document, here is what we know about the impact on
Neighbor Discovery. Neighbor Discovery.
Everything learned from the RAs on the interface should be discarded, Everything learned from the RAs on the interface should be discarded,
such as the default router list and the on-link prefix list. such as the default router list and the on-link prefix list.
Furthermore, all neighbor cache entries, in particular redirects, Furthermore, all neighbor cache entries, in particular redirects,
need to be discarded. Finally the information in the Current need to be discarded. Finally the information in the Current
Candidate Link object is used to create a new default router list and Candidate Link object is used to create a new default router list and
on-link prefix list. on-link prefix list.
The list of things are are potentially affected by this movement is The list of things are potentially affected by this movement is
fairly extensive, since new Neighbor Discovery options are being fairly extensive, since new Neighbor Discovery options are being
created. In addition to what is mentioned above, the list includes: created. In addition to what is mentioned above, the list includes:
o The MTU option defined in [1]. o The MTU option defined in [1].
o The Advertisement Interval option defined in [5]. o The Advertisement Interval option defined in [5].
o The Home Agent Information option defined in [5]. o The Home Agent Information option defined in [5].
o The Route Information option defined in [11]. o The Route Information option defined in [11].
In addition, when the host determines it has moved it needs to set
num_RS_RA to zero.
5. CPL without a 'link UP' notification 5. CPL without a 'link UP' notification
If the host implementation does not provide any link-layer event If the host implementation does not provide any link-layer event
notifications [9], and in particular, a link UP notification, the notifications [9], and in particular, a link UP notification, the
host needs additional logic to try to decide whether a received RA host needs additional logic to try to decide whether a received RA
applies to the "old" link or a "new" link. applies to the "old" link or a "new" link.
In this case there is an increased risk that the host get confused, In this case there is an increased risk that the host get confused,
thus it isn't clear whether this should be part of the thus it isn't clear whether this should be part of the
recommendation, or whether we should just require that hosts which recommendation, or whether we should just require that hosts which
skipping to change at page 17, line 43 skipping to change at page 18, line 43
link UP notification as a hint, as specified below. link UP notification as a hint, as specified below.
The implications of treating such an RA as a hint, is that such an RA The implications of treating such an RA as a hint, is that such an RA
would set 'time_last_linkUP_received' to the current time, create a would set 'time_last_linkUP_received' to the current time, create a
new Candidate Link object with the information extracted from that new Candidate Link object with the information extracted from that
RA, and then send an RS as specified in Section 4.4. RA, and then send an RS as specified in Section 4.4.
However, there is still a risk for confusion because the host can not However, there is still a risk for confusion because the host can not
tell from the RAs whether they were solicited by the host. (RFC 2461 tell from the RAs whether they were solicited by the host. (RFC 2461
recommends that solicited RAs be multicast.) The danger is recommends that solicited RAs be multicast.) The danger is
examplified by this: exemplified by this:
1. Assume the host has a CCL with prefixes P1 and P2. 1. Assume the host has a CCL with prefixes P1 and P2.
2. The host changes link layer attachment, but there is no link UP 2. The host changes link layer attachment, but there is no link UP
notification. notification.
3. The host receives an RA with a disjoint set of prefixes: prefix 3. The host receives an RA with a disjoint set of prefixes: prefix
P3. This causes the host to form a new Candidate Link object P3. This causes the host to form a new Candidate Link object
with P3 and send an RS. with P3 and send an RS.
skipping to change at page 18, line 18 skipping to change at page 19, line 18
5. The host receives one of the periodic multicast RAs on the link, 5. The host receives one of the periodic multicast RAs on the link,
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 4 seconds after sending a RS was assume that any RA received within MAX_RA_WAIT seconds after sending
in response to the RS. Basically this relies on the small a RS was in response to the RS. Basically this relies on the small
probability of both moving again in that 4 second interval, and probability of both moving again in that MAX_RA_WAIT second interval,
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
DNA process is intimately related to Neighbor Discovery protocol and DNA process is intimately related to Neighbor Discovery protocol and
skipping to change at page 23, line 5 skipping to change at page 24, line 5
certain whether P5, P6, and P7 are assigned to the same link (and certain whether P5, P6, and P7 are assigned to the same link (and
without a link UP notification such uncertainties do exist). without a link UP notification such uncertainties do exist).
A millisecond later an RA with prefixes P6 and P7 is received. Now A millisecond later an RA with prefixes P6 and P7 is received. Now
the host decides that P5,P6, and P7 are assigned to the same link. the host decides that P5,P6, and P7 are assigned to the same link.
Four seconds after the RS was sent and no RA containing P1, P2, P3, Four seconds after the RS was sent and no RA containing P1, P2, P3,
or P4 has been received the host can conclude with high probability or P4 has been received the host can conclude with high probability
that it is no longer attached to the link which had those prefixes. that it is no longer attached to the link which had those prefixes.
9. Performance Analysis 9. Protocol Constants
The following protocol constants are defined in this document.
+--------------------+----------------+
| Constant name | Constant value |
+--------------------+----------------+
| NUM_RS_RA_COMPLETE | 1 |
| | |
| MAX_RA_WAIT | 4 seconds |
+--------------------+----------------+
Table 1
10. Acknowledgements
The authors would like to acknowledge the many careful comments from
Greg Daley that helped improve the clarity of the document, as well
as the review of the DNA WG participants in general.
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].
skipping to change at page 25, line 5 skipping to change at page 28, line 5
remains at the same link, a host needs to receive at least one RA. remains at the same link, a host needs to receive at least one RA.
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.
10. Change Log 12. Change Log
The following changes have been made since draft-ietf-dna-cpl-00:
o Many editorial fixes
o Added a count to the CCL to track whether it is likely to be
complete (num_RS_RA)
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
received with a useful prefix, the prefix list will be considered
to be complete. The value is named NUM_RS_RA_COMPLETE.
o In section 4.5 added some fudge around whether merging when a RA
has prefixes which matches multiple Candidate Link objects. We
need to decide what to specify in this area.
o Clarified section 4.5 that Candidate Link objects can not be
shared between different interfaces.
The following changes have been made since draft-jinchoi-dna-cpl-01: The following changes have been made since draft-jinchoi-dna-cpl-01:
o Clarified that only prefixes with a non-zero valid lifetime are o Clarified that only prefixes with a non-zero valid lifetime are
considered. considered.
o Added some text about renumbering considerations. o Added some text about renumbering considerations.
o Limited the retention of old Candidate Link objects to 90 minutes o Limited the retention of old Candidate Link objects to 90 minutes
to avoid problems if there is flash renumbering *and* a prefix is to avoid problems if there is flash renumbering *and* a prefix is
skipping to change at page 26, line 5 skipping to change at page 29, line 5
o Added text in section 4.6 to say that current and future ND o Added text in section 4.6 to say that current and future ND
options need to be included in the information that is discarded options need to be included in the information that is discarded
when the host declares that is has moved to a different link. when the host declares that is has moved to a different link.
o Made the Candidate Link objects be per interface, since there are o Made the Candidate Link objects be per interface, since there are
some security issues when they are shared between interfaces that some security issues when they are shared between interfaces that
might be of different trustworthyness. might be of different trustworthyness.
o Many editorial clarifications. o Many editorial clarifications.
11. Open Issues 13. Open Issues
o Should we worry about implementations without 'link Up' o Should we worry about implementations without 'link Up'
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
skipping to change at page 27, line 5 skipping to change at page 30, line 5
o The document currently proposes that hosts send one RS (and o The document currently proposes that hosts send one RS (and
retransmit until at least one RA is received) after a hint, and retransmit until at least one RA is received) after a hint, and
afterwards wait for 2 additional unsolicited RAs from each router, afterwards wait for 2 additional unsolicited RAs from each router,
before declaring the prefix list complete. With the default before declaring the prefix list complete. With the default
timers in RFC 2461 this will take a long time (60-90 minutes). 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 Should we instead recommend that the host send 2 or 3 RSs
initially? If so, how frequently? The additional RSs will initially? If so, how frequently? The additional RSs will
increase the total amount of multicast packets on the link - increase the total amount of multicast packets on the link -
perhaps significantly - so there are some tradeoffs involved here. perhaps significantly - so there are some tradeoffs involved here.
12. References 14. References
12.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., "Detecting Network Attachment in IPv6 Goals", [4] Choi, J., "Goals of Detecting Network Attachment in IPv6",
draft-ietf-dna-goals-04 (work in progress), December 2004. draft-ietf-dna-goals-04 (work in progress), December 2004.
12.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.
 End of changes. 

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