draft-ietf-dna-protocol-02.txt   draft-ietf-dna-protocol-03.txt 
DNA Working Group S. Narayanan, Ed. DNA Working Group S. Narayanan, Ed.
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: April 23, 2007 October 20, 2006 Expires: April 26, 2007 October 23, 2006
Detecting Network Attachment in IPv6 Networks (DNAv6) Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-ietf-dna-protocol-02.txt draft-ietf-dna-protocol-03.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 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2007. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following Efficient detection of network attachment in IPv6 needs the following
three components: a method for hosts to detect link change in the three components: a method for hosts to detect link change in the
presence of unmodified (non-DNAv6) routers, a method for the host to presence of unmodified (non-DNAv6) routers, a method for the host to
skipping to change at page 3, line 7 skipping to change at page 3, line 7
5.1.10 Removing a Prefix from an Interface . . . . . . . . 26 5.1.10 Removing a Prefix from an Interface . . . . . . . . 26
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 26 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 26
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 27 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 27
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 27 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 27
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 28 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 28
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 29 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 29
5.2.4 Making use of Prior Information . . . . . . . . . . . 30 5.2.4 Making use of Prior Information . . . . . . . . . . . 30
5.2.5 Selection of a Landmark Prefix . . . . . . . . . . . . 30 5.2.5 Selection of a Landmark Prefix . . . . . . . . . . . . 30
5.2.6 Sending Router Solicitations . . . . . . . . . . . . . 31 5.2.6 Sending Router Solicitations . . . . . . . . . . . . . 31
5.2.7 Processing Router Advertisements . . . . . . . . . . . 32 5.2.7 Processing Router Advertisements . . . . . . . . . . . 32
5.2.8 DNA and Address Configuration . . . . . . . . . . . . 37 5.2.8 DNA and Address Configuration . . . . . . . . . . . . 38
5.3 DNA without a 'link UP' notification . . . . . . . . . . . 41 5.3 DNA without a 'link UP' notification . . . . . . . . . . . 41
6. Tentative options for IPv6 ND . . . . . . . . . . . . . . . 42 6. Tentative options for IPv6 ND . . . . . . . . . . . . . . . 43
6.1 Sending solicitations containing Tentative Options . . . . 42 6.1 Sending solicitations containing Tentative Options . . . . 43
6.1.1 Sending Neighbour Solicitations with Tentative 6.1.1 Sending Neighbour Solicitations with Tentative
Options . . . . . . . . . . . . . . . . . . . . . . . 43 Options . . . . . . . . . . . . . . . . . . . . . . . 43
6.1.2 Sending Router Solicitations with Tentative Options . 43 6.1.2 Sending Router Solicitations with Tentative Options . 43
6.2 Receiving Tentative Options . . . . . . . . . . . . . . . 43 6.2 Receiving Tentative Options . . . . . . . . . . . . . . . 44
6.2.1 Receiving Neighbour Solicitations containing 6.2.1 Receiving Neighbour Solicitations containing
Tentative Options . . . . . . . . . . . . . . . . . . 44 Tentative Options . . . . . . . . . . . . . . . . . . 45
6.2.2 Receiving Router Solicitations containing Tentative 6.2.2 Receiving Router Solicitations containing Tentative
Options . . . . . . . . . . . . . . . . . . . . . . . 45 Options . . . . . . . . . . . . . . . . . . . . . . . 45
7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . 45 7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . 45
7.1 Hints Due to Network Layer Messages . . . . . . . . . . . 46 7.1 Hints Due to Network Layer Messages . . . . . . . . . . . 46
7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 46 7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 46
7.3 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 47 7.3 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 47
7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 47 7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 47
7.5 Hint Management for Inactive Hosts . . . . . . . . . . . . 48 7.5 Hint Management for Inactive Hosts . . . . . . . . . . . . 48
8. Complications to Detecting Network Attachment . . . . . . . 48 8. Complications to Detecting Network Attachment . . . . . . . 48
8.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 48 8.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 49
8.2 Router Configurations . . . . . . . . . . . . . . . . . . 48 8.2 Router Configurations . . . . . . . . . . . . . . . . . . 49
8.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 49 8.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 49
8.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 49 8.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 49
8.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 49 8.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 50
9. Security Considerations . . . . . . . . . . . . . . . . . . 50 9. Security Considerations . . . . . . . . . . . . . . . . . . 50
9.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 50 9.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 50
9.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 50 9.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 50
9.3 Tentative options . . . . . . . . . . . . . . . . . . . . 50 9.3 Tentative options . . . . . . . . . . . . . . . . . . . . 51
9.4 Authorization and Detecting Network Attachment . . . . . . 51 9.4 Authorization and Detecting Network Attachment . . . . . . 52
9.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 52 9.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 52
9.6 Hint Management Security . . . . . . . . . . . . . . . . . 52 9.6 Hint Management Security . . . . . . . . . . . . . . . . . 52
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53 11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 53
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54
14.1 Normative References . . . . . . . . . . . . . . . . . . 54 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.2 Informative References . . . . . . . . . . . . . . . . . 55 15.1 Normative References . . . . . . . . . . . . . . . . . . 55
15.2 Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 58 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 58
B. Sending directed advertisements without the neighbour B. Sending directed advertisements without the neighbour
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . . 61
1. Introduction 1. Introduction
This memo defines a mechanism for an IPv6 host to detect link-change This memo defines a mechanism for an IPv6 host to detect link-change
in the presence of unmodified (non-DNAv6) routers and proposes new in the presence of unmodified (non-DNAv6) routers and proposes new
extensions to "IPv6 Neighbor Discovery" [3] to increase the extensions to "IPv6 Neighbor Discovery" [3] to increase the
efficiency of link-change detection in the presence of DNAv6 enabled efficiency of link-change detection in the presence of DNAv6 enabled
routers. The new extensions use complete RA for link identification, routers. The new extensions use complete RA for link identification,
and Hash-based Fast RA to achieve fast response to RS messages. and Hash-based Fast RA to achieve fast response to RS messages.
Aspects of prefix-based LinkID and Requested Landmark are included to Aspects of prefix-based LinkID and Requested Landmark are included to
skipping to change at page 9, line 4 skipping to change at page 9, line 4
initialized when a router is enabled, by sending a Router initialized when a router is enabled, by sending a Router
Solicitation and collecting the resulting RAs, and then multicasting Solicitation and collecting the resulting RAs, and then multicasting
a few RAs more rapidly as already suggested in RFC 2461. This a few RAs more rapidly as already suggested in RFC 2461. This
process ensures with high probability that all the routers have the process ensures with high probability that all the routers have the
same notion of the set of prefixes assigned to the link. same notion of the set of prefixes assigned to the link.
In order for the host to be able to make decisions about link change In order for the host to be able to make decisions about link change
with a single received RA, the hosts need to track all the prefixes with a single received RA, the hosts need to track all the prefixes
advertised on the link. The hosts also have to maintain a notion of advertised on the link. The hosts also have to maintain a notion of
'completeness' associated with its prefix list. This document 'completeness' associated with its prefix list. This document
recommends that NUM_RS_RA_COMPLETE RS/RA exchanges SHOULD be done for recommends that NumRSRAComplete RS/RA exchanges SHOULD be done for
the prefix list to be considered 'complete'. the prefix list to be considered 'complete'.
3.2 Fast Router Advertisement 3.2 Fast Router Advertisement
According to RFC 2461 a solicited Router Advertisement should have a According to RFC 2461 a solicited Router Advertisement should have a
random delay between 0 and 500 milliseconds, to avoid the random delay between 0 and 500 milliseconds, to avoid the
advertisements from all the routers colliding on the link causing advertisements from all the routers colliding on the link causing
congestion and higher probability of packet loss. In addition, RFC congestion and higher probability of packet loss. In addition, RFC
2461 suggests that the RAs be multicast, and multicast RAs are rate 2461 suggests that the RAs be multicast, and multicast RAs are rate
limited to one message every 3 seconds. This implies that the limited to one message every 3 seconds. This implies that the
skipping to change at page 10, line 34 skipping to change at page 10, line 34
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 [3]. 4 seconds would be a safe number for the host the resulting RAs [3]. 4 seconds would be a safe number for the host
to wait for the solicited 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 MinRAWait.
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
an Incomplete Prefix List, i.e. the prefix list that misses some an 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
skipping to change at page 25, line 24 skipping to change at page 25, line 24
length field is used, it is possible to carry any variable length length field is used, it is possible to carry any variable length
identifier less than or equal to 128 bits in an LPO and store it in identifier less than or equal to 128 bits in an LPO and store it in
DNAHostPrefixList (Section 5.2.1). DNAHostPrefixList (Section 5.2.1).
Following a change of LinkID, the old LinkID MUST be included in RAs Following a change of LinkID, the old LinkID MUST be included in RAs
in an LPO for the following 1.5 hours. in an LPO for the following 1.5 hours.
Future specifications MUST NOT treat the information in an LPO as Future specifications MUST NOT treat the information in an LPO as
prefixes such as they would the prefixes found in a Prefix prefixes such as they would the prefixes found in a Prefix
Information Option. Future specifications MUST NOT assume that the Information Option. Future specifications MUST NOT assume that the
entries in a host's DNAHostPrefixList are actaul prefixes in use on entries in a host's DNAHostPrefixList are actual prefixes in use on
the link. the link.
5.1.8 Scheduling Fast Router Advertisements 5.1.8 Scheduling Fast Router Advertisements
RAs may need to be delayed to avoid collisions in the case that there RAs may need to be delayed to avoid collisions in the case that there
is more than one router on a link. The delay is calculated by is more than one router on a link. The delay is calculated by
determining a ranking for the router for the received RS, and determining a ranking for the router for the received RS, and
multiplying that by RASeparation. multiplying that by RASeparation.
A Host Token is needed from the RS to calculate the router's ranking. A Host Token is needed from the RS to calculate the router's ranking.
skipping to change at page 28, line 38 skipping to change at page 28, line 38
Hosts MUST make use of the following conceptual variables and they Hosts MUST make use of the following conceptual variables and they
SHOULD be configurable: SHOULD be configurable:
DNASameLinkDADFlag DNASameLinkDADFlag
Boolean value indicating whether or not a host should re-run DAD Boolean value indicating whether or not a host should re-run DAD
when DNA indicates that link change has not occurred. when DNA indicates that link change has not occurred.
Default: False Default: False
NUM_RS_RA_COMPLETE NumRSRAComplete
Number of RS/RA exchange messages necessary to declare the prefix Number of RS/RA exchange messages necessary to declare the prefix
list to be complete. list to be complete.
Default: 1 Default: 1
MAX_RA_WAIT MinRAWait
[Editor's note: This should be MIN_RA_WAIT, right? This is the Minimum time the host will have to wait before assuming receipt of
minimum time we are recommending the host should wait before all possible RAs.
assuming cpl?] Maximum time for the host will have to wait before
assuming receipt of all possible RAs.
Default: 4 seconds Default: 4 seconds
MAX_CACHE_TIME MaxCacheTime
[Editor's note: Do we want to keep this and the associated [Editor's note: Do we want to keep this and the associated
Section 5.2.4?] Maximum time for which link information can be Section 5.2.4?] Maximum time for which link information can be
stored in the hosts. stored in the hosts.
Default: 30 mins Default: 30 mins
5.2.3 Detecting Network Attachment Steps 5.2.3 Detecting Network Attachment Steps
An IPv6 host SHOULD follow the following steps when they receive a An IPv6 host SHOULD follow the following steps when they receive a
hint (see also Section 7) indicating the possibility of link change. hint (see also Section 7) indicating the possibility of link change.
[Editor's note: Check if DNA steps are correct] [Editor's note: Check if DNA steps are correct]
Try making use of prior information stored related to the links 1. Try making use of prior information stored related to the links
the host visited in the past (see Section 5.2.4). the host visited in the past (see Section 5.2.4).
If the prior information implies no link change, the host MAY If the prior information implies no link change, the host MAY
conduct reachability detection (see Section 5.2.7.4) to one of conduct reachability detection (see Section 5.2.7.4) to one
the default routers it is using, otherwise no action is needed. of the default routers it is using, otherwise no action is
needed.
If the prior information implies that there is a link change or If the prior information implies that there is a link change
there is no useful prior information available, follow the or there is no useful prior information available, follow the
procedure below. procedure below.
Mark all the IPv6 addresses in use as optimistic. 2. Mark all the IPv6 addresses in use as optimistic.
Set all Neighbor Cache entries for routers on its Default Router 3. Set all Neighbor Cache entries for routers on its Default Router
List to STALE. List to STALE.
Send router solicitation. (See Section 5.2.6). 4. Send router solicitation. (See Section 5.2.6).
Receive router advertisement(s). 5. Receive router advertisement(s).
Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add a 6. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add
Neighbor Cache Entry in the REACHABLE state if one does not a Neighbor Cache Entry in the REACHABLE state if one does not
currently exist. currently exist.
Process received router advertisement. (See Section 5.2.7). 7. Process received router advertisement. (See Section 5.2.7).
If the link has changed 8. If the link has changed
Change the IP configuration parameters of the host (see Change the IP configuration parameters of the host (see
Section 5.2.8). Section 5.2.8).
If the link has NOT changed 9. If the link has NOT changed
Restore the address configuration state of all the IPv6 Restore the address configuration state of all the IPv6
addresses known to be on the link. addresses known to be on the link.
Update default routers list and their reachability information 10. Update default routers list and their reachability information
(see Section 5.2.7.4). (see Section 5.2.7.4).
5.2.4 Making use of Prior Information 5.2.4 Making use of Prior Information
A device that has recently been attached to a particular wireless A device that has recently been attached to a particular wireless
base station may still have state regarding the IP configuration base station may still have state regarding the IP configuration
valid for use on that link. This allows a host to begin any valid for use on that link. This allows a host to begin any
configuration procedures before checking the ongoing validity and configuration procedures before checking the ongoing validity and
security of the parameters. security of the parameters.
skipping to change at page 30, line 43 skipping to change at page 30, line 43
If the host finds the prefix it is using in the stored record, a host If the host finds the prefix it is using in the stored record, a host
MAY conclude that it is on the same link, but SHOULD undertake MAY conclude that it is on the same link, but SHOULD undertake
reachability testing as described in Section 5.2.7.4. In this case, reachability testing as described in Section 5.2.7.4. In this case,
the host MUST undertake Duplicate Address Detection [7][5] to confirm the host MUST undertake Duplicate Address Detection [7][5] to confirm
that there are no duplicate addresses on the link. that there are no duplicate addresses on the link.
The host MUST age this cached information based on the possibility The host MUST age this cached information based on the possibility
that the link's configuration has changed and MUST NOT store that the link's configuration has changed and MUST NOT store
information beyond either the remaining router or address lifetime or information beyond either the remaining router or address lifetime or
(at the outside) MAX_CACHE_TIME time-units. (at the outside) MaxCacheTime time-units.
5.2.5 Selection of a Landmark Prefix 5.2.5 Selection of a Landmark Prefix
For each interface, hosts SHOULD choose a prefix to use as a Landmark For each interface, hosts SHOULD choose a prefix to use as a Landmark
Prefix in Router Solicitations. The following rules are used in Prefix in Router Solicitations. The following rules are used in
selecting the landmark prefix: selecting the landmark prefix:
The prefix MUST have a non-zero valid lifetime. If the valid The prefix MUST have a non-zero valid lifetime. If the valid
lifetime of a previously selected Landmark Prefix expires, a new lifetime of a previously selected Landmark Prefix expires, a new
Landmark Prefix MUST be selected. Landmark Prefix MUST be selected.
skipping to change at page 31, line 33 skipping to change at page 31, line 33
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 [3]. Since there is no natural limit on how limitations in [3]. 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 Thus if it handled the most recent link UP notification less than
MAX_RA_WAIT seconds ago, it can not immediately send one when it MinRAWait seconds ago, it can not immediately send one when it
processes a link 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 [3] RS messages is allowed to multicast up to MAX_RTR_SOLICITATIONS [3] RS messages
spaced RTR_SOLICITATION_INTERVAL apart. spaced RTR_SOLICITATION_INTERVAL apart.
Note that if link-layer notifications are reliable, a host can reset Note that if link-layer notifications are reliable, a host can reset
the number of sent Router Solicitations to 0, while still maintaining the number of sent Router Solicitations to 0, while still maintaining
RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is
skipping to change at page 32, line 29 skipping to change at page 32, line 29
sure that there are no corner cases]: sure that there are no corner cases]:
If the RA contains a Landmark Option that matches the Landmark If the RA contains a Landmark Option that matches the Landmark
Option in the last transmitted Router Solicitation, and the 'Y' Option in the last transmitted Router Solicitation, and the 'Y'
bit is set then that indicates that no link change has occurred bit is set then that indicates that no link change has occurred
and current configuration can be assumed to still be current. and current configuration can be assumed to still be current.
If the RA includes a LinkID that matches an entry in If the RA includes a LinkID that matches an entry in
DNAHostLinkIDList, then the host can conclude that no link change DNAHostLinkIDList, then the host can conclude that no link change
has occurred and the current configuration can be assumed to still has occurred and the current configuration can be assumed to still
be current.If the RA includes a LinkID that is not in be current.
DNAHostLinkIDList and no prefixes that match entries in
DNAHostPrefixList, then the host can conclude that it has changed
link and SHOULD initiate re-configuration using the information in
the received Router Advertisement.
If the RA includes a prefix that matches an entry in If the RA includes a prefix that matches an entry in
DNAHostPrefixList, then the host can conclude that no link change DNAHostPrefixList, then the host can conclude that no link change
has occurred and the current configuration can be assumed to still has occurred and the current configuration can be assumed to still
be current. be current.
If the RA is a Complete RA, as indicated by the "Complete" flag in If the RA is a Complete RA, as indicated by the "Complete" flag in
the RA header, and there are no prefixes included in it in either the RA header, and there are no prefixes included in it in either
a PIO or LPO that are also in the host's DNAHostPrefixList, then a PIO or LPO that are also in the host's DNAHostPrefixList, then
the host can conclude that it has changed link and SHOULD initiate the host can conclude that it has changed link and SHOULD initiate
re-configuration using the information in the received Router re-configuration using the information in the received Router
Advertisement. Advertisement.
If the host has the complete prefix list (CPL) and the RA doest If the RA is not a CompleteRA and includes a LinkID that is not in
NOT include any prefixes in either a PIO or LPO that matches a DNAHostLinkIDList and no prefixes that match entries in
prefix in CPL then the host can conclude that link change has DNAHostPrefixList, then the host can conclude that it has changed
occurred and use the information in the received RA to configure link and SHOULD initiate re-configuration using the information in
itself. the received Router Advertisement.
If the host has the complete prefix list (CPL) and the RA does NOT
include any prefixes in either a PIO or LPO that matches a prefix
in CPL then the host can conclude that link change has occurred
and use the information in the received RA to configure itself.
If the host doesn't have the complete prefix list (CPL), the If the host doesn't have the complete prefix list (CPL), the
received RA is not complete, contains no prefixes that are stored received RA is not complete, contains no prefixes that are stored
in DNAHostPrefixList, does not contain a Landmark Option that in DNAHostPrefixList, does not contain a Landmark Option that
matches a corresponding option in the most recent RS and contains matches a corresponding option in the most recent RS and contains
no LinkID, then the host SHOULD send RS/RA exchange until no LinkID, then the host SHOULD send RS/RA exchange until
num_RS_RA is equal to NUM_RS_RA_COMPLETE to create a new CPL and num_RS_RA is equal to NumRSRAComplete to create a new CPL and
compare it with the already known prefixes. If after compare it with the already known prefixes. If after
NUM_RS_RA_COMPLETE exchanges still no prefix received in either a NumRSRAComplete exchanges still no prefix received in either a PIO
PIO or LPO of the RAs match known prefixes, the host MUST conclude or LPO of the RAs match known prefixes, the host MUST conclude
link change. If a matching prefix is received in the RAs, then link change. If a matching prefix is received in the RAs, then
the host MUST conclude that no link change has occured. the host MUST conclude that no link change has occured.
5.2.7.1 Pseudocode 5.2.7.1 Pseudocode
IF (Received RA contains Landmark that matches the Landmark option in IF (Received RA contains Landmark that matches the Landmark option in
the last transmitted RS AND Landmark 'Y' bit is set) THEN the last transmitted RS AND Landmark 'Y' bit is set) THEN
{ {
No-link change has occured No-link change has occured
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (Received RA contains LinkID) THEN IF (Received RA contains LinkID AND LinkID matches an entry in
DNAHostLinkIDList) THEN
{ {
IF (LinkID matches an entry in DNAHostLinkIDList), THEN no-link No-link change has occured.
change has occured ELSE link-change.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (Receive RA contains a prefix matching a prefix in IF (Receive RA contains a prefix matching a prefix in
DNAHostPrefixList) THEN DNAHostPrefixList) THEN
{ {
skipping to change at page 34, line 17 skipping to change at page 34, line 20
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since this is a CompleteRA, implies link-change.*/ Since this is a CompleteRA, implies link-change.*/
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (Received RA contains LinkID AND LinkID matches none of the
entries in DNAHostLinkIDList) THEN
{
Link change has occured.
RETURN; // Don't have to do the following checks.
}
IF (DNAHostPrefixList is marked as complete (i.e. the completeness IF (DNAHostPrefixList is marked as complete (i.e. the completeness
criteria is already met)) THEN criteria is already met)) THEN
{ {
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since the DNAHostPrefixList is complete, implies link-change.*/ Since the DNAHostPrefixList is complete, implies link-change.*/
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done Wait for NumRSRAComplete exchanges of RS/RA message to be done since
since the previous link_up event. the previous link_up event.
IF (One of the received RA contains a prefix matching a prefix in IF (One of the received RA contains a prefix matching a prefix in
DNAHostPrefixList from before link UP event), THEN No link change has DNAHostPrefixList from before link UP event), THEN No link change has
occured ELSE link change has occured. occured ELSE link change has occured.
5.2.7.2 Maintaining the DNAHostPrefixList 5.2.7.2 Maintaining the DNAHostPrefixList
If a Router Advertisement does not indicate a link change, the host If a Router Advertisement does not indicate a link change, the host
updates its DNAHostPrefixList, adding any new prefixes if necessary. updates its DNAHostPrefixList, adding any new prefixes if necessary.
skipping to change at page 35, line 33 skipping to change at page 35, line 48
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
accomplished since the last time the host moved to a different link. accomplished since the last time the host moved to a different link.
The host declares "one successful RS/RA exchange" is accomplished The host declares "one successful RS/RA exchange" is accomplished
after it sends an RS, waits for MAX_RA_WAIT seconds and receives a after it sends an RS, waits for MinRAWait seconds and receives a
positive number of resulting RAs. At least one RA (with at least one positive number of resulting RAs. At least one RA (with at least one
prefix) should be received. After the RS, if a link UP event occurs prefix) should be received. After the RS, if a link UP event occurs
before MAX_RA_WAIT seconds expire, the host should not assume that a before MinRAWait seconds expire, the host should not assume that a
successful RS/RA exchange is accomplished. This counter is used to successful RS/RA exchange is accomplished. This counter is used to
determine when DNAHostPrefixList is considered to be complete. This determine when DNAHostPrefixList is considered to be complete. This
document considers it to be complete when NUM_RS_RA_COMPLETE number document considers it to be complete when NumRSRAComplete number of
of RS/RA exchanges have been completed or a RA message with the RS/RA exchanges have been completed or a RA message with the complete
complete bit set is received. The complete DNAHostPrefixList is also bit set is received. The complete DNAHostPrefixList is also refered
refered to as CPL ( Complete Prefix List). to as CPL ( Complete Prefix List).
After NUM_RS_RA_COMPLETE RS/ RA exchange, the host will generate the After NumRSRAComplete RS/ RA exchange, the host will generate the
Complete Prefix List if there is no packet loss. Even though some Complete Prefix List if there is no packet loss. Even though some
packet loss may cause an Incomplete Prefix List, there is a further packet loss may cause an Incomplete Prefix List, there is a further
chance for the host to get the missing prefixes before it receives chance for the host to get the missing prefixes before it receives
link UP notification, i.e. moves to another PoA. Even if the host link UP notification, i.e. moves to another PoA. Even if the host
moves to another PoA with Incomplete Prefix List,but if it has not moves to another PoA with Incomplete Prefix List,but if it has not
changed link, there is good chance that the first RA may contain a changed link, there is good chance that the first RA may contain a
prefix from its (incomplete) prefix list. Considering all those prefix from its (incomplete) prefix list. Considering all those
above, even if the host performs only one RS/ RA exchange, it will be 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, rather rare for the host to falsely assume a link change. Moreover,
even in case of false detection, there would be no connectivity even in case of false detection, there would be no connectivity
skipping to change at page 42, line 37 skipping to change at page 43, line 4
notification. notification.
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 DNAHostPrefixList, which now has P3 and P4, even though to the DNAHostPrefixList, which now has P3 and P4, even though
those prefixes are assigned to different links. those prefixes 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 MinRAWait seconds after sending an
an RS was in response to the RS. Basically this relies on the small 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 MinRAWait 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. Tentative options for IPv6 ND 6. Tentative options for IPv6 ND
6.1 Sending solicitations containing Tentative Options 6.1 Sending solicitations containing Tentative Options
Tentative Options may be sent in Router and Neighbour Solicitations, Tentative Options may be sent in Router and Neighbour Solicitations,
as described below. as described below.
skipping to change at page 53, line 22 skipping to change at page 53, line 37
This memo defines two new Neighbor Discovery [3] options, which must This memo defines two new Neighbor Discovery [3] options, which must
be assigned Option Type values within the option numbering space for be assigned Option Type values within the option numbering space for
Neighbor Discovery messages: Neighbor Discovery messages:
1. The Landmark option, described in Section 4.3; and 1. The Landmark option, described in Section 4.3; and
2. The Learned Prefix option, described in Section 4.4. 2. The Learned Prefix option, described in Section 4.4.
3. The tentative option, described in Section 4.5 3. The tentative option, described in Section 4.5
11. Open issues 11. Changes since -02
o Changed the Router Advertisment processing in Section 5.2.7 and
Section 5.2.7.1 to fix a mistake in the logic.
o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT,
MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added
an open issue whether these should be variables or constants.
o Fixed some typos.
12. Open issues
1. The protocol uses only the prefixes with lifetime greater than 1. The protocol uses only the prefixes with lifetime greater than
1.5 hours. 1.5 hour is decided with the assumption that 1.5 hours. 1.5 hour is decided with the assumption that
MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to
increase the value into hours or even days because it would be increase the value into hours or even days because it would be
difficult to waken all idle nodes in every 30 mins in cellular difficult to waken all idle nodes in every 30 mins in cellular
network. network.
2. There may be a link where no prefix is advertised. For example, 2. There may be a link where no prefix is advertised. For example,
an network administrator may not support stateless address an network administrator may not support stateless address
autoconfiguration for policy reason. Then it won't advertise any autoconfiguration for policy reason. Then it won't advertise any
skipping to change at page 53, line 45 skipping to change at page 54, line 25
through an AR and not allow direct communication among hosts through an AR and not allow direct communication among hosts
because of accounting. Then it won't advertise any prefix with because of accounting. Then it won't advertise any prefix with
L-bit set either. As of my knowledge the prefix without any bit L-bit set either. As of my knowledge the prefix without any bit
set won't be advertised, which would hurt DNA operation. set won't be advertised, which would hurt DNA operation.
3. Third, I propose we do away with 'Landmark Option with Y bit'. 3. Third, I propose we do away with 'Landmark Option with Y bit'.
The router can notify no-link change by simply putting the The router can notify no-link change by simply putting the
landmark prefix in either PIO or LPIO. Then we can remove the landmark prefix in either PIO or LPIO. Then we can remove the
check for landmark from Section 5.2.7. check for landmark from Section 5.2.7.
12. Contributors 4. Should variables NumRSRAComplete, MinRAWait, MaxCacheTime be kept
as variables or should they be constants?
13. Contributors
This document is the result of merging four different working group This document is the result of merging four different working group
documents. The draft-ietf-dna-protocol-01.txt authored by James documents. The draft-ietf-dna-protocol-01.txt authored by James
Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock
Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02
authored by JinHyeock Choi and Erik Normark provided the idea/text authored by JinHyeock Choi and Erik Normark provided the idea/text
for the complete prefix list mechanism described in this document. for the complete prefix list mechanism described in this document.
The best current practice for hosts draft (draft-ietf-dna-hosts-03) The best current practice for hosts draft (draft-ietf-dna-hosts-03)
authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and
the tentative options (draft-ietf-dna-tentative-00) authored by Greg the tentative options (draft-ietf-dna-tentative-00) authored by Greg
Daley, Erik Normark and Nick Moore were also adopted into this Daley, Erik Normark and Nick Moore were also adopted into this
document. document.
13. Acknowledgments 14. Acknowledgments
The design presented in this document grew out of discussions among The design presented in this document grew out of discussions among
the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, the members of the DNA design team (JinHyeock Choi, Tero Kauppinen,
James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland).
The spirited debates on the design, and the advantages and dis- The spirited debates on the design, and the advantages and dis-
advantages of various DNA solutions helped the creation of this advantages of various DNA solutions helped the creation of this
document. document.
Thanks to Syam Madanapalli who co-authored Thanks to Syam Madanapalli who co-authored
draft-jinchoi-dna-protocol2 from which this draft draws ideas, as draft-jinchoi-dna-protocol2 from which this draft draws ideas, as
skipping to change at page 54, line 40 skipping to change at page 55, line 24
Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli,
Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review
of draft-ietf-dna-protocol-01. of draft-ietf-dna-protocol-01.
Thanks to Gabriel Montenegro for his review of Thanks to Gabriel Montenegro for his review of
draft-pentland-dna-protocol. draft-pentland-dna-protocol.
Thanks also to other members of the DNA working group for their Thanks also to other members of the DNA working group for their
comments that helped shape this work. comments that helped shape this work.
14. References 15. References
14.1 Normative References 15.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] 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.
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006. IPv6", RFC 4429, April 2006.
14.2 Informative References 15.2 Informative References
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address [7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998. Autoconfiguration", RFC2462 2462, December 1998.
[8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998. December 1998.
 End of changes. 58 change blocks. 
82 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/