DNA Working Group S. Narayanan, Ed. Internet-Draft Panasonic Expires: April 26, 2007 October 23, 2006 Detecting Network Attachment in IPv6 Networks (DNAv6) draft-ietf-dna-protocol-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Efficient detection of network attachment in IPv6 needs the following three components: a method for hosts to detect link change in the presence of unmodified (non-DNAv6) routers, a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibility offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in Narayanan, et al. Expires April 26, 2007 [Page 1] Internet-Draft DNAv6 October 2006 responding to router solicitation messages imposed by RFC 2461 makes it difficult to receive an RA quickly. In this memo, a mechanism that requires the hosts to monitor all the prefixes advertised on the link and use it for link identification in the presence of non-DNAv6 routers is presented. A more efficient link-identification mechanism requiring the DNAv6 routers to monitor the link for advertised prefixes to assist the hosts in link identification combined with a fast router advertisement mechanism that selects the order of response for the router deterministicly is also presented. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 9 3.3 Complete Prefix List generation . . . . . . . . . . . . . 10 3.4 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 11 3.5 Tentative Source Link-Layer Address option (TO) . . . . . 12 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 13 4.2 Prefix Information Option LinkID Bit . . . . . . . . . . . 14 4.3 Landmark Option . . . . . . . . . . . . . . . . . . . . . 14 4.4 Learned Prefix Option . . . . . . . . . . . . . . . . . . 16 4.5 Tentative option . . . . . . . . . . . . . . . . . . . . . 18 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 19 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 19 5.1.2 Router Configuration Variables . . . . . . . . . . . . 20 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 21 5.1.4 Processing Router Advertisements . . . . . . . . . . . 22 5.1.5 Processing Router Solicitations . . . . . . . . . . . 22 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 23 5.1.7 LinkID . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 25 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 26 5.1.10 Removing a Prefix from an Interface . . . . . . . . 26 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 26 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 27 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 27 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 28 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 29 5.2.4 Making use of Prior Information . . . . . . . . . . . 30 Narayanan, et al. Expires April 26, 2007 [Page 2] Internet-Draft DNAv6 October 2006 5.2.5 Selection of a Landmark Prefix . . . . . . . . . . . . 30 5.2.6 Sending Router Solicitations . . . . . . . . . . . . . 31 5.2.7 Processing Router Advertisements . . . . . . . . . . . 32 5.2.8 DNA and Address Configuration . . . . . . . . . . . . 38 5.3 DNA without a 'link UP' notification . . . . . . . . . . . 41 6. Tentative options for IPv6 ND . . . . . . . . . . . . . . . 43 6.1 Sending solicitations containing Tentative Options . . . . 43 6.1.1 Sending Neighbour Solicitations with Tentative Options . . . . . . . . . . . . . . . . . . . . . . . 43 6.1.2 Sending Router Solicitations with Tentative Options . 43 6.2 Receiving Tentative Options . . . . . . . . . . . . . . . 44 6.2.1 Receiving Neighbour Solicitations containing Tentative Options . . . . . . . . . . . . . . . . . . 45 6.2.2 Receiving Router Solicitations containing Tentative Options . . . . . . . . . . . . . . . . . . . . . . . 45 7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . 45 7.1 Hints Due to Network Layer Messages . . . . . . . . . . . 46 7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 46 7.3 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 47 7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 47 7.5 Hint Management for Inactive Hosts . . . . . . . . . . . . 48 8. Complications to Detecting Network Attachment . . . . . . . 48 8.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 49 8.2 Router Configurations . . . . . . . . . . . . . . . . . . 49 8.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 49 8.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 49 8.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 50 9. Security Considerations . . . . . . . . . . . . . . . . . . 50 9.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 50 9.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 50 9.3 Tentative options . . . . . . . . . . . . . . . . . . . . 51 9.4 Authorization and Detecting Network Attachment . . . . . . 52 9.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 52 9.6 Hint Management Security . . . . . . . . . . . . . . . . . 52 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53 11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 53 12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 Narayanan, et al. Expires April 26, 2007 [Page 3] Internet-Draft DNAv6 October 2006 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 15.1 Normative References . . . . . . . . . . . . . . . . . . 55 15.2 Informative References . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 58 B. Sending directed advertisements without the neighbour cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . 61 Narayanan, et al. Expires April 26, 2007 [Page 4] Internet-Draft DNAv6 October 2006 1. Introduction This memo defines a mechanism for an IPv6 host to detect link-change in the presence of unmodified (non-DNAv6) routers and proposes new extensions to "IPv6 Neighbor Discovery" [3] to increase the efficiency of link-change detection in the presence of DNAv6 enabled routers. The new extensions use complete RA for link identification, and Hash-based Fast RA to achieve fast response to RS messages. Aspects of prefix-based LinkID and Requested Landmark are included to allow for a decrease in the packet sizes associated with Complete RA. This memo also defines a new Tentative option (TO) which is designed to replace the existing Source Link-Layer Address Options available in IPv6 Neighbor Discovery when the host is performing Optimistic DAD. The rest of the document refers to the proposed mechanisms by the term "DNAv6". 2. Terms and Abbreviations There is an existing DNA terminology draft [21]. [Editor's note: Do we have to bring in the terms from this draft?] This draft does not introduce any new terminology not already used by existing drafts. The term "link" is used as defined in RFC 2460 [2]. NOTE: this is completely different from the term "link" as used by IEEE 802, etc. Access network: A network where hosts are present. Especially, a network used for the support of visiting wireless hosts. Attachment: The process of entering a new cell. Attachment (and detachment) may cause a link-change. Cell: A system constituted by the propagation range of a wireless base station and its serviced hosts. Dependent on topology, one or many cells may be part of the same link. Hint: An indication from other subsystems or protocol layers that link-change may have occurred. Link-Change: Link-Change occurs when a host moves from a point-of- attachment on a link, to another point-of-attachment where it is unable to reach devices belonging to the previous link, without being forwarded through a router. Narayanan, et al. Expires April 26, 2007 [Page 5] Internet-Draft DNAv6 October 2006 Point-of-Attachment: A link-layer base-station, VLAN or port through which a device attempts to reach the network. Changes to a host's point-of-attachment may cause link-change. Reachability Detection: Determination that a device (such as a router) is currently reachable, over both a wireless medium, and any attached fixed network. This is typically achieved using Neighbor Unreachability Detection procedure [3]. Wireless Medium: A physical layer which incorporates free space electromagnetic or optical propagation. Such media are susceptible to mobility and interference effects, potentially resulting in high packet loss probabilities. 3. Overview The DNA protocol presented in this document tries to achieve the following objectives: o Eliminate the delays introduced by RFC 2461 in discovering the configuration. o Make it possible for the hosts to accurately detect the identity of their current link from a single RA in the presence of either DNAv6 enabled routers or non-DNAv6 routers. DNAv6 assumes that the host's wireless link interface software and hardware is capable of delivering a 'link up' event notification when layer 2 on the host is configured and sufficiently stable for IP traffic. This event notification acts as a hint to the layer 3 DNA procedures to check whether or not the host is attached to the same link as before. DNAv6 also assumes that an interface on the host is never connected to two links at the same time. In the case that the layer 2 technology is capable of having multiple attachments (for instance, multiple layer 2 associations or connections) at the same time, DNAv6 requires the individual layer-2 associations to be represented as separate (virtual interfaces) to layer 3 and DNAv6 in particular. 3.1 Link Identification DNAv6 identifies a link by the set of prefixes that are assigned to the link, which is quite natural and doesn't require introducing any new form of identifier. However, this choice implies that the protocol needs to be robust against changes in the set of prefixes assigned to a link, including the case when a link is renumbered and the prefix is later reassigned to a different link. The protocol Narayanan, et al. Expires April 26, 2007 [Page 6] Internet-Draft DNAv6 October 2006 handles this during graceful renumbering (when the valid lifetime of the prefix is allowed to decrease to zero before it is removed and perhaps reassigned to a different link), it describes how to remove and reassign prefixes earlier than this without any incorrect behaviour, and will also recover in case where a prefix is reassigned without following the draft recommendations. DNAv6 is based on using a Router Solicitation/Router Advertisement exchange to both verify whether the host has changed link, and if it has, provide the host with the configuration information for the new link. The base method for detecting link change involves getting routers to listen to all of the prefixes that are being advertised by other routers on the link. They can then respond to solicitations with complete prefix information. This information consists of the prefixes a router would advertise itself as per RFC 2461, and also, the prefixes learned from other routers on the link that are not being advertised by itself. These learned prefixes are included in a new Learned Prefix Option in the Router Advertisement. A host receiving one of these "Complete RAs" - so marked by a flag - then knows all of the prefixes in use on a link, and by inference all those that are not. By comparing this with previously received prefixes the host can correctly decide whether it is connected to the same link as previously, or whether this Router Advertisement is from a new link. If the link contains all non-DNAv6 routers, then the host relies on the completeness (which the host always keeps track) of its own prefix list to make a decision; i.e. if its own prefix list is known to be 'complete', the host can make a decision by comparing the received prefixes with its prefix list, if its own prefix is not yet 'complete', the host will wait for the completeness criteria to be met before making the comparison. Though frequently all routers on a link will advertise the same set of prefixes and thus experience no cost in making the RAs complete, there is potential for the RAs to be large when there are many prefixes advertised. Two mechanisms are defined that allow certain RAs to be reduced in size. One uses a technique called a "landmark", where the host chooses one of the prefixes as a landmark prefix, and then includes this in the Router Solicitation message in the form of a question "am I still connected to the link which has this prefix?". The landmark is carried in a new option, called the Landmark Option. In the case when the host is still attached to the same link, which might occur when the host has changed from using one layer 2 access Narayanan, et al. Expires April 26, 2007 [Page 7] Internet-Draft DNAv6 October 2006 point to another, but the access points are on the same link, the Router Advertisement(s) it receives will contain a "yes, that prefix is on this link" answer, and no other information. Thus, such RA messages are quite small. In the case when the landmark prefix is unknown to the responding router, the host will receive a "No" answer to its landmark question, and also the information it needs to configure itself for the new link. The routers try to include as much information as possible in such messages, so that the host can be informed of all the prefixes assigned to the new link as soon as possible. A second mechanism for reducing packet sizes applies to unsolicited Router Advertisements. By selecting one prefix on the link to be the "link identifier", and making sure that it is included in every advertisement, it is possible to omit some prefixes. Such advertisements will not inform a host of all of the prefixes at once, but in general these unsolicited advertisements will not be the first advertisement received on a link. Inclusion of the link identifier simply ensures that there is overlap in the information advertised by each router on a link and that hosts will thus not incorrectly interpret one of these incomplete RAs as an indication of movement. Even though this document recommends the use of a prefix as the "link identifier", future specifications can use this option to support non-prefix link identifiers. The Router Advertisement messages are, in general, larger than the solicitations, and with multiple routers on the link there will be multiple advertisements sent for each solicitation. This amplification can be used by an attacker to cause a Denial of Service attack. Such attacks are limited by applying a rate limit on the unicast Router Advertisements sent directly in response to each solicitation, and using multicast RAs when the rate limit is exceeded. In order for the routers be able to both respond to the landmark questions and send the complete RAs, the routers need to track the prefixes that other routers advertise on the link. This process is initialized when a router is enabled, by sending a Router Solicitation and collecting the resulting RAs, and then multicasting a few RAs more rapidly as already suggested in RFC 2461. This process ensures with high probability that all the routers have the 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 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 'completeness' associated with its prefix list. This document Narayanan, et al. Expires April 26, 2007 [Page 8] Internet-Draft DNAv6 October 2006 recommends that NumRSRAComplete RS/RA exchanges SHOULD be done for the prefix list to be considered 'complete'. 3.2 Fast Router Advertisement According to RFC 2461 a solicited Router Advertisement should have a random delay between 0 and 500 milliseconds, to avoid the advertisements from all the routers colliding on the link causing congestion and higher probability of packet loss. In addition, RFC 2461 suggests that the RAs be multicast, and multicast RAs are rate limited to one message every 3 seconds. This implies that the response to a RS might be delayed up to 3.5 seconds. DNAv6 avoids this delay by using a different mechanism to ensure that two routers will not respond at exactly the same time while allowing one of the routers on the link to respond immediately. Since the hosts might be likely to use the first responding router as the first choice from their default router list, the mechanism also ensures that the same router doesn't respond first to the RSs from different hosts. The mechanism is based on the routers on the link determining (from the same RAs that are used in Section 3.1 to determine all the prefixes assigned to the link), the link-local addresses of all the other routers on the link. With this loosely consistent list, each router can independently compute some function of the (link-local) source address of the RS and each of the routers' link-local addresses. The results of that function are then compared to create a ranking, and the ranking determines the delay each router will use when responding to the RS. The router which is ranked as #0 will respond with a zero delay. If the routers become out-of-sync with respect to their learned router lists, two or more routers may respond with the same delay, but over time the routers will converge on their lists of learned routers on the link. 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 receives an RA containing one or more prefixes and none of the prefixes in it matches the previously known prefixes for the link, then it is assumed to be a new link. 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 different links must be disjoint [18]. Narayanan, et al. Expires April 26, 2007 [Page 9] Internet-Draft DNAv6 October 2006 3.3 Complete Prefix List generation To efficiently check for link change, a host always maintains the list of all known prefixes on the link. This procedure of attaining and retaining the Complete Prefix List is initialized when the host is powered on. The host forms the prefix list at any PoA (Point of Attachment), that is, this process starts independently of any movement. Though the procedure may take some time, that doesn't matter unless the host moves very fast. A host can generate the Complete Prefix List with reasonable certainty if it remains attached to a link sufficiently long. It will take approximately 4 seconds, when it actively performs 1 RS/ RA exchange. If it passively relies on unsolicited RA messages instead, it may take much more time. First the host sends an RS to All-Router multicast address. Assuming there is no packet loss, every router on the link would receive the RS and usually reply with an RA containing all the prefixes that the router advertises. However, RFC 2461 mandates certain delays for the RA transmissions. 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 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 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 seconds, the host would receive all the RAs and know all the prefixes. Thus we pick 4 seconds as the value for MinRAWait. 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 an Incomplete Prefix List, i.e. the prefix list that misses some prefix on the link. To remedy this deficiency, the host may perform multiple RS/ RA exchanges to collect all the assigned prefixes. After one RS/ RA exchange, to corroborate the completeness of 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 [3]. The host takes the union of the prefixes from all the RAs to generate the prefix list. The more RS/ RA exchange the host performs, the more probable that the resulting prefix list is complete. To ascertain whether its existing prefix list is complete or not, the host can set its own policy. The host may take into consideration the estimated packet loss rate of the link and the number of RS/ RA Narayanan, et al. Expires April 26, 2007 [Page 10] Internet-Draft DNAv6 October 2006 exchanges it performed or should have performed while it was attached to the link. In general, the higher the error rate, the longer time and more RA transmissions from the routers are needed to assure the completeness of the prefix list. 3.4 Erroneous Prefix Lists The host may generate either 1) an Incomplete Prefix List, i.e. the prefix list that does not include all the prefixes that are assigned to the link or 2) the Superfluous Prefix List, i.e. the prefix list that contains some prefix that is not assigned to the link. It should be noted that 1) and 2) are not exclusive. The host may generate the prefix list that excludes some prefix on the link but includes the prefix not assigned to the link. Its important to note that these erroneous prefix list possibility is significantly reduced with a single DNAv6 router on the link that is sending CompleteRA messages. Severe packet losses during prefix list generation may cause an Incomplete Prefix List. Or the host may have undergone a link change before finishing the procedure of the Complete Prefix List generation. Later we will deal with the case that the host can't be sure of the completeness of the prefix list. Even if the host falsely assumes that an Incomplete Prefix List is complete, the effect of that assumption is that the host might later think it has moved to a different link when in fact it has not. In case that a link change happens, even if the host has an Incomplete Prefix List, it will detect a link change. Hence an Incomplete Prefix List doesn't cause a connection disruption. But it may cause extra signaling messages, for example Binding Update messages in [6] The Superfluous Prefix List presents a more serious problem. Without the assumed 'link UP' event notification from the link-layer, the host can't perceive that it has changed its attachment point, i.e. it has torn down an old link-layer connection and established a new one. We further discuss the issues, should this assumption be removed, in Section 5.3. With the assumed 'link UP' notification, and the assumption of different concurrent layer 2 connections being represented as different (virtual) interfaces to the DNA module the host will never Narayanan, et al. Expires April 26, 2007 [Page 11] Internet-Draft DNAv6 October 2006 treat RAs from different links as being part of the same link. Hence it will not create a Superfluous Prefix List. 3.5 Tentative Source Link-Layer Address option (TO) DNAv6 protocol requires the host to switch its IPv6 addresses to 'optimistic' state as recommended by Optimistic DAD [5] after receiving a link-up notification until a decision on the link-change possibility is made. Optimistic DAD [5] prevents usage of Source Link-Layer Address options (SLLAOs) in Router and Neighbour Solicitation messages from a tentative address (while Duplicate Address Detection is occurring). This is because receiving a Neighbour Solicitation (NS) or Router Solicitation (RS) containing an SLLAO would otherwise overwrite an existing cache entry, even if the cache entry contained the legitimate address owner, and the solicitor was a duplicate address. Neighbour Advertisement (NA) messages don't have such an issue, since the Advertisement message contains a flag which explicitly disallows overriding of existing cache entries, by the target link-layer address option carried within. The effect of preventing SLLAOs for tentative addresses is that communications with these addresses are sub-optimal for the tentative period. Sending solicitations without these options causes an additional round-trip for neighbour discovery if the advertiser does not have an existing neighbour cache entry for the solicitor. In some cases, multicast advertisements will be scheduled, where neighbour discovery is not possible on the advertiser. The Tentative Option (TO) functions in the same role as the Source Link-Layer Address option defined for [3], but it MUST NOT override an existing neighbour cache entry. The differing neighbour cache entry MUST NOT be affected by the reception of the Tentative Option. This ensures that tentative addresses are unable to modify legitimate neighbour cache entries. In the case where an entry is unable to be added to the neighbour cache, a node MAY send responses direct to the link-layer address specified in the TO. For these messages, no Neighbour Cache entry may be created, although response messages may be directed to a particular unicast address. Narayanan, et al. Expires April 26, 2007 [Page 12] Internet-Draft DNAv6 October 2006 4. Message Formats This memo defines two new flags for inclusion in the router advertisement message and three new options. 4.1 Router Advertisement DNAv6 modifies the format of the Router Advertisement message by defining a bit to indicate that the router sending the message is participating in the DNAv6 protocol as well as a flag to indicate the completeness of the set of prefixes included in the Router Advertisement. The new message format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|Pr |F|C|R| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Options ... +-+-+-+-+-+-+-+-+-+-+-+- FastRA (F) The FastRA (F) bit indicates that the router sending the RA is participating in the DNAv6 protocol. Other routers should include this router in calculating response delay tokens. Complete (C) The Complete (C) bit indicates that the Router Advertisement contains PIOs for all prefixes explicitly configured on the sending router, and, if other routers on the link are advertising additional prefixes, a Learned Prefix Option containing all additional prefixes that the router has heard from other routers on the link. Reserved (R) Narayanan, et al. Expires April 26, 2007 [Page 13] Internet-Draft DNAv6 October 2006 The reserved field is reduced from 3 bits to 1 bit. 4.2 Prefix Information Option LinkID Bit DNAv6 modifies the format of the Prefix Information Option by defining a bit to indicate that the enclosed prefix is currently being used as the Link Identifier. The new message format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|I|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LinkID (I) The LinkID (I) bit indicates that the prefix in the Prefix field of this option is currently being used as the Link Identfier (LinkID). Reserved1 The Reserved1 field is reduced from 6 bits to 5 bits. 4.3 Landmark Option The Landmark Option is used by hosts in a Router Solicitation message to ask the routers on a link if the specified prefix is being advertised by some router on the link. It is used by routers in a Router Advertisement to reply to a corresponding question in a Router Narayanan, et al. Expires April 26, 2007 [Page 14] Internet-Draft DNAv6 October 2006 Solicitation, indicating whether the prefix referred to is being advertised by any router on the link. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Pref Length |Y|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Landmark Prefix ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 8 bit unsigned integer indicating the length of the option in units of 8 octets. Set to 2 or 3. Pref Length An 8 bit unsigned integer representing the number of bits in the prefix to be used for matching. Yes (Y) The Yes (Y) bit, when included in a Landmark Option in a Router Advertisement, indicates that the prefix referred to in the Prefix field of this option is being advertised by one or more routers on the current link. In a Landmark Option in a Router Solicitation, this bit MUST be set to zero and ignored by receivers. No (N) The No (N) bit, when included in a Landmark Option in a Router Advertisement, indicates that the prefix referred to in the Prefix field of this option is not being advertised by any router on the current link. In a Landmark Option in a Router Solicitation, this bit MUST be set to zero and ignored by receivers. Narayanan, et al. Expires April 26, 2007 [Page 15] Internet-Draft DNAv6 October 2006 Reserved A 38 bit unused field. It MUST be initialised to zero by the sender, and ignored by the receiver. Prefix A prefix being used by the host currently for a global IPv6 address, padded at the right with zeros. If the prefix length is less than 65 bits, only 64 bits need be included, otherwise 128 bits are included. 4.4 Learned Prefix Option The Learned Prefix Option (LPO) is used by a router to indicate prefixes that are being advertised in PIOs by other routers on the link, but not by itself. Narayanan, et al. Expires April 26, 2007 [Page 16] Internet-Draft DNAv6 October 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Reserved | Prefix Len 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Prefix Len N | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix 2 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix N + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 8 bit unsigned integer indicating the length of the option in units of 8 octets. I Narayanan, et al. Expires April 26, 2007 [Page 17] Internet-Draft DNAv6 October 2006 LinkID (I) flag. When set indicates that the first prefix in this option is the LinkID for this link. Prefix Len One or more fields (N) each consisting of an 8-bit unsigned integer representing the prefix lengths of the following prefixes. The Prefix Len fields are ordered the same as the Prefix fields so that the first Prefix Len field represents the prefix length of the prefix contained in the first prefix field, and so on. Padding Zero padding sufficient to align the following prefix field on an 8-octet boundary. Prefix One or more fields (N) each containing a 128-bit address representing a prefix that has been heard on the link but is not explicitly configured on this router. Description This option MUST only be included in a Router Advertisement. This option contains prefixes that are beingF advertised on the link but are not explicitly configured on the sending router. The router MUST NOT include any prefixes with a zero valid lifetime in the LPO. 4.5 Tentative option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (Requires IANA Allocation) suggest 17 (0x11) Narayanan, et al. Expires April 26, 2007 [Page 18] Internet-Draft DNAv6 October 2006 Length The length of the option (including the type and length fields) in units of 8 octets. Link-Layer Address The variable length link-layer address. Description The Tentative option contains the link-layer address of the sender of the packet. It is used in the Neighbour Solicitation and Router Solicitation packets. 5. DNA Operation 5.1 DNA Router Operation Routers MUST collect information about the other routers that are advertising on the link. 5.1.1 Data Structures The routers maintain a set of conceptual data structures for each interface to track the prefixes advertised by other routers on the link, and also the set of DNA routers (the routers that will quickly respond to RSs) on the link. For each interface, routers maintain a list of all prefixes learned from other routers on the link but not explicitly configured on the router's own interface. The list will be referred to in this document as "DNARouterPrefixList". Prefixes are learned by their reception within Prefix Information Options [3] in Router Advertisements. Prefixes in Learned Prefix Options (see Section 4.4) MUST NOT update the contents of DNARouterPrefixList. For each prefix the router MUST store sufficient information to identify the prefix and to know when to remove the prefix entry from the list. This may be achieved by storing the following information: 1. Prefix 2. Prefix length 3. Prefix valid lifetime Narayanan, et al. Expires April 26, 2007 [Page 19] Internet-Draft DNAv6 October 2006 4. Expiry time The expiry time for entries in DNARouterPrefixList is 1.5 hours (three times the maximum value of the Router Advertisement interval) after the last received Router Advertisement affecting the entry, or the scheduled expiry of the prefix valid lifetime, whichever is earlier. For each interface, routers also maintain a list of the other routers advertising on the link. The list will be referred to in this memo as "DNARouterList". For each router from which a Router Advertisement is received with the FastRA flag set, the following information MUST be stored: 1. Link-local source address of advertising router 2. Token equal to the first 64 bits of an SHA-1 hash of the above address 3. Expiry time Each router MUST include itself in the DNARouterList and generate a token for itself as described above based on the link-local address used in its RA messages. The expiry time for entries in DNARouterList is 1.5 hours after the last received Router Advertisement affecting the entry. 5.1.2 Router Configuration Variables A DNAv6 router MUST allow for the following conceptual variables to be configured by the system management. Default values are set to ease configuration load. UnicastRAInterval The interval corresponding to the maximum average rate of Router Solicitations that the router is prepared to service with unicast responses. This is the interval at which the token bucket controlling the unicast responses is replenished. Default: 50 milliseconds MaxUnicastRABurst Narayanan, et al. Expires April 26, 2007 [Page 20] Internet-Draft DNAv6 October 2006 The maximum size burst of Router Solicitations that the router is prepared to service with unicast responses. This is the maximum number of tokens allowed in the token bucket controlling the unicast responses. Default: 20 RASeparation The separation between responses from different routers on the same link to a single Router Solicitation. Default: 20 milliseconds MulticastRADelay The delay to be introduced when scheduling a multicast RA in response to a RS message when the token bucket is empty. Default: 3000 milliseconds FastRAThreshold The maximum number of fast responses that a host should receive when soliciting for Router Advertisements. Default: 3 5.1.3 Bootstrapping DNA Data Structures When an interface on a router first starts up, it SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations separated by RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other routers and prefixes active on the link. Upon startup, a router interface SHOULD also send a few unsolicited Router Advertisements as recommended in Section 6.2.4 of RFC 2461 [3], in order to inform others routers on the link of its presence. During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface both sends unsolicited Router Advertisements and responds to Router Solicitations, but with a few restrictions on the message content. Router Advertisements MUST NOT include any DNA specific options except that the FastRA flag MUST be set. The FastRA flag is set so that other routers will know to include this router in their timing calculations for fast RA transmission. Other DNA options are omitted Narayanan, et al. Expires April 26, 2007 [Page 21] Internet-Draft DNAv6 October 2006 because the router may have incomplete information during bootstrap. During the bootstrap period, the Complete flag in Router Advertisements MUST NOT be set. During the bootstrap period, the timing of Router Advertisement transmission is as specified in RFC 2461. 5.1.4 Processing Router Advertisements When a router receives a Router Advertisement, it first validates the RA as per the rules in RFC 2461, and then performs the actions specified in RFC 2461. In addition, each valid Router Advertisement is processed as follows: If the FastRA flag is set in the RA, the router checks if there is an entry in its DNARouterList. Thus it looks up the source address of the RA in that list and, if not found, a new entry is added to DNARouterList, including the source address and a token equal to the first 64 bits of an SHA-1 hash of the source address. The entry's expiry time is updated. Regardless of the state of the FastRA flag, each PIO in the RA is examined. If the prefix is not in the router's DNARouterPrefixList and not in the router's AdvPrefixList [3], it is added to the DNARouterPrefixList, and its expiry time is set. 5.1.5 Processing Router Solicitations The usual response to a Router Solicitation SHOULD be a unicast RA. However, to keep control of the rate of unicast RAs sent, a token bucket is used. The token bucket is filled at one token every UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored. When a Router Solicitation is received, the router checks if it is possible to send a unicast response. A unicast response requires that the following conditions to be met: o A unicast send token is available. o The source address of the Router Solicitation is NOT the unspecified address (::). If a unicast response is possible and the Router Solicitation contains a Landmark Option whose prefix is included in DNARouterPrefixList or AdvPrefixList, the router SHOULD send an abbreviated Router Advertisement. Narayanan, et al. Expires April 26, 2007 [Page 22] Internet-Draft DNAv6 October 2006 This abbreviated advertisement includes only the Landmark Option, with the "Y" flag set, plus the base RA header and any SEND options as appropriate. The FastRA flag MUST be set. The Complete flag MUST NOT be set. This is the one exception where the LinkID MAY be omitted as the Y flag implies that link change has not occured and that the previously received LinkID is still current. If there is NO Landmark Option in the received Router Solicitation or it contains a Landmark Option whose prefix is NOT included in DNARouterPrefixList or AdvPrefixList or a unicast response is not possible, then the router SHOULD generate a Complete RA as specified in Section 5.1.6. The Router Advertisement MUST include the LinkID, as described in Section 5.1.7. If a unicast response is possible, then a token is removed and the Router Advertisement is scheduled for transmission as specified in Section 5.1.8. If a unicast response is not possible and there is no multicast RA already scheduled for transmission in the next MulticastRADelay the RA MUST be sent to the link-scoped all-nodes multicast address at the current time plus MulticastRADelay. If a unicast response is not possible but there is a multicast RA already scheduled for transmission in the next MulticastRADelay, then the Router Solicitation MUST be silently discarded. 5.1.6 Complete Router Advertisements A CompleteRA is formed as follows: Starting with a Router Advertisement with all fixed options (MTU, Advertisement Interval, flags, etc.), the FastRA flag is set. As many Prefix Information Options for explicitly configured prefixes as will fit are added to the Router Advertisement. If there is sufficient room, a Learned Prefix Option as defined in Section 4.4 containing as many of the learned prefixes as will fit is added. It may not be possible to include all of the prefixes in use on the link due to MTU or administrative limitations. If all Prefix Information Options and a Learned Prefix Option containing all of the learned prefixes were included in the RA, then the Complete flag in the Router Advertisement header is set. If it is not possible to generate a Complete RA but the Router Solicitation that this Router Advertisement is in response to, if any, includes a Landmark Option containing a prefix that is not in the router's DNARouterPrefixList and not in the router's Narayanan, et al. Expires April 26, 2007 [Page 23] Internet-Draft DNAv6 October 2006 AdvPrefixList then the router SHOULD include a Landmark Option with the "N" flag set. If there are known to be prefixes that are not included in the Router Advertisement, then the Complete flag MUST NOT be set. Note that although it may not be possible to fit all of the prefixes into an RA, the LinkID MUST be included. 5.1.7 LinkID One of the prefixes in use on a link is chosen to be the LinkID. The LinkID is the numerically smallest prefix stored in either of DNARouterPrefixList or AdvPrefixList whose lifetime is greater than 1.5 hours. For comparing prefixes, they are padded to the right with zeros to make them 128 bit unsigned integers. The prefix may be included in the RA in either a PIO or LPO as appropriate. If the prefix is included in a PIO, then the "I" flag in that PIO MUST be set. If the prefix is included in an LPO, then the prefix MUST be placed in the first prefix field in the LPO, and the LPO "I" flag MUST be set. 5.1.7.1 Changing the LinkID When either a new prefix is added to a link that is numerically smaller than all those previously advertised or the lifetime of the prefix that is currently being used as the LinkID falls below 1.5 hours, a new LinkID is determined. In order to ensure that there is overlap between consecutive RAs on the link, the old LinkID must continue to be advertised for some time alongside the new LinkID. For the purposes of propagating information, it is assumed that after three advertisements of a change, all routers have been made aware of the change. If the instant that a router sends its first unsolicited advertisement is time T, then by T + 1 hour at least three such advertisements will have been made and all routers can be assumed to have received it. Thus by time T + 1.5 hours, all routers on the link should have also sent at least one advertisement with the new LinkID. 1.5 hours after first sending an advertisement with a new LinkID it is safe to consider the old LinkID gone and omit the corresponding prefix from RAs if desired. Following a change of LinkID, the old LinkID MUST be included in RAs Narayanan, et al. Expires April 26, 2007 [Page 24] Internet-Draft DNAv6 October 2006 for the following 1.5 hours. 5.1.7.1.1 Non-Prefix LinkIDs Although this memo only discusses LinkIDs that are prefixes, a future specification or ammendment may describe a mechanism to select a LinkID that is not a prefix. Information from the Learned Prefix Option is only stored in DNAHostPrefixList, and is only used for DNA purposes. Because a 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 DNAHostPrefixList (Section 5.2.1). Following a change of LinkID, the old LinkID MUST be included in RAs in an LPO for the following 1.5 hours. Future specifications MUST NOT treat the information in an LPO as prefixes such as they would the prefixes found in a Prefix Information Option. Future specifications MUST NOT assume that the entries in a host's DNAHostPrefixList are actual prefixes in use on the link. 5.1.8 Scheduling Fast Router Advertisements 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 determining a ranking for the router for the received RS, and multiplying that by RASeparation. A Host Token is needed from the RS to calculate the router's ranking. The first 64 bits of an SHA-1 hash of the source address of the RS MUST be used as the RS host token. A router's ranking is determined by taking the XOR of the RS Host Token and each of the stored Router Tokens. The results of these XOR operations are sorted lowest to highest. The router corresponding to the first entry in the sorted list is ranked zero, the second, one, and so on. Note: it is not necessary for a router to actually sort the whole list. Each router just needs to determine its own position in the sorted list. If Rank < FastRAThreshold, then the RA MUST be scheduled for transmission in Rank * RASeparation milliseconds. When the router is ranked as zero, the resulting delay is zero, thus the RA SHOULD be sent immediately. Narayanan, et al. Expires April 26, 2007 [Page 25] Internet-Draft DNAv6 October 2006 If Rank >= FastRAThreshold, then the RA MUST be replaced with a Complete RA, if it is not one already, and scheduled for multicast transmission as in RFC 2461. 5.1.9 Scheduling Unsolicited Router Advertisements Unsolicited router advertisements MUST be scheduled as per RFC 2461. The "F" flag in the RA header MUST be set. They MAY be Complete RAs or MAY include only a subset of the configured prefixes, but MUST include the LinkID. This ensures that there will be overlap in the sets of prefixes contained in consecutive RAs on a link from DNA routers, and thus an absence of that overlap can be used to infer link change. 5.1.10 Removing a Prefix from an Interface When a prefix is to stop being advertised in a PIO in RAs by an interface before the expiry of the prefix's valid lifetime, then the router should treat it as though it has just learned a prefix that is not explicitly configured on it. After sending the last RA containing the prefix in a PIO, the router MUST add the prefix to the DNARouterPrefixList and set it to expire in 1.5 hours or at the expiry of the last advertised valid lifetime, whichever is earlier. This ensures that to hosts there will be overlap in the prefixes in the RAs they see and prevent them from incorrectly interpreting changed prefixes as movement. 5.1.10.1 Early Removal of the LinkID Prefix If the LinkID prefix is to be withdrawn early from a link, that is before the expiry of its previously advertised valid lifetime, it MUST be advertised for at least 1.5 hours with a valid lifetime of less than 1.5 hours. This ensures that all of the other routers are notified to begin the process of changing the LinkID as well, and hosts will always see overlap between the prefixes in consecutive RAs and thus not mistake an RA for an indication of link change. 5.1.11 Prefix Reassignment A prefix whose lifetime has expired after counting down in real time for at least 1.5 hours may be reassigned to another link immediately after expiry. If a prefix is withdrawn from a link without counting down to the expiry of its valid lifetime, it SHOULD NOT be reassigned to another link for at least 1.5 hours or until the original expiry time, whichever is earlier. This gives sufficient time for other Narayanan, et al. Expires April 26, 2007 [Page 26] Internet-Draft DNAv6 October 2006 routers that have learned the prefix to expire it, and for hosts that have seen advertisements from those routers to expire the prefix as well. Earlier reassignment may result in hosts that move from between the old and new links failing to detect the movement. When the host is sure that the prefix list is complete, a false movement assumption may happen due to renumbering when a new prefix is introduced in RAs at about the same time as the host handles the 'link UP' event. We may solve the renumbering problem with minor modification like below. When a router starts advertising a new prefix, for the time being, every time the router advertises a new prefix in an RA, it includes at least one old prefix in the same RA. The old prefix assures that the host doesn't falsely assume a link change because of a new prefix. After a while, hosts will recognize the new prefix as the one assigned to the current link and update its prefix list. In this way, we may provide a fast and robust solution. If a host can make the Complete Prefix List with certainty, it can check for link change fast. Otherwise, it can fall back on a slow but robust scheme. It is up to the host to decide which scheme to use. 5.2 DNA Host Operation Hosts collect information about the prefixes available on the link to which they are connected to facilitate change detection. 5.2.1 Data Structures Hosts MUST maintain a list of prefixes advertised on the link. This is separate from the RFC 2461 "Prefix List" and will be referred to here as the "DNAHostPrefixList". All prefixes SHOULD be stored, however an upper bound MUST be placed on the number stored to prevent overflow. For each prefix stored the host MUST store the following information: 1. Prefix 2. Prefix length 3. Expiry time If a host is not able to store this information for every prefix, there is a risk that the host will incorrectly decide that it has moved to a new link, when it receives advertisements from a non-DNA Narayanan, et al. Expires April 26, 2007 [Page 27] Internet-Draft DNAv6 October 2006 router. Prefix entries in the DNAHostPrefixList expire and MUST be removed 1.5 hours after they are last seen in a received Router Advertisement (in either a PIO or LPO) or at the expiry of the valid lifetime of the prefix, whichever is earlier. Hosts MUST also maintain a list of all LinkIDs seen on the current Link. This list will be referred to as "DNAHostLinkIDList". This list is identical in structure to DNAHostPrefixList but contains LinkIDs instead of prefixes. At this time LinkIDs are also prefixes but in future may be able to be identifiers other than prefixes. A list is stored rather than a single entry to allow for changes in the LinkID used on a link. Entries are expired from DNAHostLinkIDList in the same way as DNAHostPrefixList. Hosts SHOULD also maintain a "Landmark Prefix" as described in Section 5.2.5. 5.2.2 Host Configuration Variables Hosts MUST make use of the following conceptual variables and they SHOULD be configurable: DNASameLinkDADFlag Boolean value indicating whether or not a host should re-run DAD when DNA indicates that link change has not occurred. Default: False NumRSRAComplete Number of RS/RA exchange messages necessary to declare the prefix list to be complete. Default: 1 MinRAWait Minimum time the host will have to wait before assuming receipt of all possible RAs. Narayanan, et al. Expires April 26, 2007 [Page 28] Internet-Draft DNAv6 October 2006 Default: 4 seconds MaxCacheTime [Editor's note: Do we want to keep this and the associated Section 5.2.4?] Maximum time for which link information can be stored in the hosts. Default: 30 mins 5.2.3 Detecting Network Attachment Steps An IPv6 host SHOULD follow the following steps when they receive a hint (see also Section 7) indicating the possibility of link change. [Editor's note: Check if DNA steps are correct] 1. Try making use of prior information stored related to the links the host visited in the past (see Section 5.2.4). If the prior information implies no link change, the host MAY conduct reachability detection (see Section 5.2.7.4) to one of the default routers it is using, otherwise no action is needed. If the prior information implies that there is a link change or there is no useful prior information available, follow the procedure below. 2. Mark all the IPv6 addresses in use as optimistic. 3. Set all Neighbor Cache entries for routers on its Default Router List to STALE. 4. Send router solicitation. (See Section 5.2.6). 5. Receive router advertisement(s). 6. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the REACHABLE state if one does not currently exist. 7. Process received router advertisement. (See Section 5.2.7). 8. If the link has changed Change the IP configuration parameters of the host (see Section 5.2.8). Narayanan, et al. Expires April 26, 2007 [Page 29] Internet-Draft DNAv6 October 2006 9. If the link has NOT changed Restore the address configuration state of all the IPv6 addresses known to be on the link. 10. Update default routers list and their reachability information (see Section 5.2.7.4). 5.2.4 Making use of Prior Information A device that has recently been attached to a particular wireless base station may still have state regarding the IP configuration valid for use on that link. This allows a host to begin any configuration procedures before checking the ongoing validity and security of the parameters. The experimental protocols CARD [13] and FMIPv6 [14] each provide ways to generate such information using network-layer signaling, before arrival on a link. Additionally, the issue is the same when a host disconnects from one cell and returns to it immediately, or movement occurs between a pair of cells (the ping-pong effect). A IP host MAY store L2 to L3 mapping information for the links for a period of time in order to use the information in the future. When a host attaches itself to a point-of-attachment for which it has an L2 to L3 mapping, if the stored record doesn't contain the prefix the host is using, the host SHOULD conclude that it has changed link and initiate a new configuration procedure. 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 reachability testing as described in Section 5.2.7.4. In this case, the host MUST undertake Duplicate Address Detection [7][5] to confirm that there are no duplicate addresses on the link. The host MUST age this cached information based on the possibility that the link's configuration has changed and MUST NOT store information beyond either the remaining router or address lifetime or (at the outside) MaxCacheTime time-units. 5.2.5 Selection of a Landmark Prefix For each interface, hosts SHOULD choose a prefix to use as a Landmark Prefix in Router Solicitations. The following rules are used in selecting the landmark prefix: Narayanan, et al. Expires April 26, 2007 [Page 30] Internet-Draft DNAv6 October 2006 The prefix MUST have a non-zero valid lifetime. If the valid lifetime of a previously selected Landmark Prefix expires, a new Landmark Prefix MUST be selected. The prefix MUST be one of those that the hosts has used to assign a non-link-local address to itself The prefix SHOULD be chosen as the one with the longest preferred lifetime, but it is not necessary to switch to different prefix if the preferred lifetime of the current landmark prefix changes. 5.2.6 Sending Router Solicitations Upon the occurrence of a Layer 2 link-up event notification, hosts SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting and/or hysteresis to this behaviour as appropriate to the link technology subject to the reliability of the hints. When the host receives a link UP notification from its link layer, it sets time_last_linkUP_received to the current time. 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 frequently the link UP notifications might be generated, we take the conservative approach that even if the host establishes new link layer connectivity very often, under no circumstances should it send Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL. Thus if it handled the most recent link UP notification less than MinRAWait seconds ago, it can not immediately send one when it processes a link UP notification. 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 is allowed to multicast up to MAX_RTR_SOLICITATIONS [3] RS messages 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. Hosts SHOULD include a Landmark Option (LO) in the RS message with the landmark prefix chosen based on the rules in Section 5.2.5. Hosts SHOULD include a tentative source link layer address option Narayanan, et al. Expires April 26, 2007 [Page 31] Internet-Draft DNAv6 October 2006 (TO) in the RS message Section 6. The router solicitation message is sent to the All_Routers_Multicast address and the source address MUST be the link local address of the host. The host MUST consider its link local address to be in the "Optimistic" state for duplicate address detection [5] until either the returned RA confirms that the host has not switched to a new link or, if an link change has occurred, the host has performed optimistic duplicate address detection for the address. 5.2.7 Processing Router Advertisements When the host receives a Router Advertisement, the host checks for the following conditions in the given order and derives the associated conclusions given below [Editor's note: Review and make sure that there are no corner cases]: If the RA contains a Landmark Option that matches the Landmark Option in the last transmitted Router Solicitation, and the 'Y' bit is set then that indicates that no link change has occurred and current configuration can be assumed to still be current. If the RA includes a LinkID that matches an entry in DNAHostLinkIDList, then the host can conclude that no link change has occurred and the current configuration can be assumed to still be current. If the RA includes a prefix that matches an entry in DNAHostPrefixList, then the host can conclude that no link change has occurred and the current configuration can be assumed to still be current. 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 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 re-configuration using the information in the received Router Advertisement. If the RA is not a CompleteRA and includes a LinkID that is not in 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 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 Narayanan, et al. Expires April 26, 2007 [Page 32] Internet-Draft DNAv6 October 2006 and use the information in the received RA to configure itself. If the host doesn't have the complete prefix list (CPL), the received RA is not complete, contains no prefixes that are stored in DNAHostPrefixList, does not contain a Landmark Option that matches a corresponding option in the most recent RS and contains no LinkID, then the host SHOULD send RS/RA exchange until num_RS_RA is equal to NumRSRAComplete to create a new CPL and compare it with the already known prefixes. If after NumRSRAComplete exchanges still no prefix received in either a PIO or LPO of the RAs match known prefixes, the host MUST conclude link change. If a matching prefix is received in the RAs, then the host MUST conclude that no link change has occured. 5.2.7.1 Pseudocode IF (Received RA contains Landmark that matches the Landmark option in the last transmitted RS AND Landmark 'Y' bit is set) THEN { No-link change has occured RETURN; // Don't have to do the following checks. } IF (Received RA contains LinkID AND LinkID matches an entry in DNAHostLinkIDList) THEN { No-link change has occured. RETURN; // Don't have to do the following checks. } IF (Receive RA contains a prefix matching a prefix in DNAHostPrefixList) THEN { No link change has occured. RETURN; // Don't have to do the following checks. Narayanan, et al. Expires April 26, 2007 [Page 33] Internet-Draft DNAv6 October 2006 } IF (Receive RA is a CompleteRA) THEN { /* We already checked if there are any matching prefix before. Since this is a CompleteRA, implies link-change.*/ Link change has occured. 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 criteria is already met)) THEN { /* We already checked if there are any matching prefix before. Since the DNAHostPrefixList is complete, implies link-change.*/ Link change has occured. RETURN; // Don't have to do the following checks. } Wait for NumRSRAComplete exchanges of RS/RA message to be done since the previous link_up event. IF (One of the received RA contains a prefix matching a prefix in DNAHostPrefixList from before link UP event), THEN No link change has occured ELSE link change has occured. Narayanan, et al. Expires April 26, 2007 [Page 34] Internet-Draft DNAv6 October 2006 5.2.7.2 Maintaining the DNAHostPrefixList If a Router Advertisement does not indicate a link change, the host updates its DNAHostPrefixList, adding any new prefixes if necessary. If the Router Advertisement has the C flag set, then the host SHOULD make the DNAHostPrefixList match the contents of the advertisement and mark it as complete (i.e. it becomes CPL). Any new prefixes are added and any prefixes in the list that are absent in the advertisement are removed. Expiry times on prefixes are updated if the prefix was contained in a PIO, but not if it was contained in an LPO. If the Router Advertisement does not have the C flag set, then the host SHOULD add any new prefixes and update expiry times as above, but SHOULD NOT remove any entries from DNAHostPrefixList. When initiating reconfiguration due to link change, the host MUST remove all prefixes in the DNAHostPrefixList and repopulate it with the prefixes in the Prefix Information Options and Learned Prefix Option, if any, in the RA. In addition, the host maintains previous DNAHostPrefixList. It is per interface since there are some security issues when merging across interfaces. The operations on DNAHostPrefixList is to create a new one, discard one, and merge two of them together. The issues with merging are discussed in the next sub-section. For each interface, the host maintains the last time a valid RA was received (called time_last_RA_received in this document), which actually ignores RAs without prefix options, and the last time a link UP notification was received from the link layer on the host (called time_last_linkUP_received in this document). Together these two conceptual variables serve to identify when a RA containing disjoint prefixes can't be due to being attached to a new link, because there 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 accomplished since the last time the host moved to a different link. The host declares "one successful RS/RA exchange" is accomplished 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 prefix) should be received. After the RS, if a link UP event occurs before MinRAWait seconds expire, the host should not assume that a successful RS/RA exchange is accomplished. This counter is used to Narayanan, et al. Expires April 26, 2007 [Page 35] Internet-Draft DNAv6 October 2006 determine when DNAHostPrefixList is considered to be complete. This document considers it to be complete when NumRSRAComplete number of RS/RA exchanges have been completed or a RA message with the complete bit set is received. The complete DNAHostPrefixList is also refered to as CPL ( Complete Prefix List). After NumRSRAComplete RS/ RA exchange, the host will generate the Complete Prefix List if there is no packet loss. Even though some packet loss may cause an Incomplete Prefix List, there is a further chance for the host to get the missing prefixes before it receives link UP notification, i.e. moves to another PoA. Even if the host 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 prefix from its (incomplete) prefix list. Considering all those above, even if the host performs only one RS/ RA exchange, it will be rather rare for the host to falsely assume a link change. Moreover, even in case of false detection, there would be no connectivity disruption, because Incomplete Prefix List causes only additional signaling. 5.2.7.2.1 Merging DNAHostPrefixList When a host has been collecting information about a potentially different link in its Current DNAHostPrefixList, and it discovers that it is in fact the same link as another DNAHostPrefixList, then it needs to merge the information in the two objects to produce a single new object. Since the DNAHostPrefixList contains the most recent information, any information contained in it will override the information in the old DNAHostPrefixList, for example the remaining lifetimes for the prefixes. When the two objects contain different pieces of information, for instance different prefixes or default routers, the union of these are used in the resulting merged object. 5.2.7.3 Maintaining DNAHostLinkIDList If a Router Advertisement does not indicate a link change, the host updates its DNAHostLinkIDList, adding any new LinkIDs if necessary. If the link has changed, the DNAHostLinkIDList MUST be updated with the ONLY the linkIDs from the router advertisment.[Editor's note: Do we have say something about storing old LinkID list as prior information for future use]. 5.2.7.4 Router Reachability Detection and Default Router Selection The receipt of a unicast RA from a router in response to a multicast RS indicates that the host has bi-directional reachability with the routers that responded. Such reachability is necessary for the host to use a router as a default router, in order to have packets routed Narayanan, et al. Expires April 26, 2007 [Page 36] Internet-Draft DNAv6 October 2006 off the host's current link. It is notable that the choice of whether the messages are addressed to multicast or unicast address will have different reachability implications. The reachability implications from the hosts' perspective for the four different message exchanges defined by RFC 2461 [3] are presented in the table below. The host can confirm bi-directional reachability from the neighbor discovery or router discovery message exchanges except when a multicast RA is received at the host for its RS message. In this case, using IPv6 Neighbour Discovery procedures, the host cannot know whether the multicast RA is in response to its solicitation message or whether it is a periodic un-solicited transmission from the router [3]. +-----------------+----+----+----+-----+ | Exchanges: |Upstream |Downstream| +-----------------+----+----+----+-----+ | multicast NS/NA | Y | Y | +-----------------+----+----+----+-----+ | unicast NS/NA | Y | Y | +-----------------+----+----+----+-----+ | RS/multicast RA | N | Y | +-----------------+----+----+----+-----+ | RS/unicast RA | Y | Y | +-----------------+----+----+----+-----+ If the destination address of the received RA is a unicast address, the host knows the router heard its RS, and therefore that the host has reachability with the router. Prior to sending a DNA RS in response to an indication of link change, the host SHOULD set all Neighbor Cache entries for routers on its Default Router List to STALE. When the host receives an RA in reply to the RS, the host SHOULD mark that router's Neighbor Cache Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the REACHABLE state if one does not currently exist. The host SHOULD also update its Default Router List in the following fashion. If any of the routers returning RAs are already on the default router list, the host SHOULD use the information in the RA to update the Default Route List entry with the new information. The host SHOULD add entries to the Default Router List for any routers returning RAs that are not on the list. The host SHOULD confine selection of a router from the Default Router List to those routers whose Neighbor Cache entries are in the REACHABLE state. Note that the Default Router List SHOULD be updated as described here regardless of whether the RA indicates that the host has changed to a new IP link, since changes in router reachability are possible on some link types even if the host remains on the same IP link. Narayanan, et al. Expires April 26, 2007 [Page 37] Internet-Draft DNAv6 October 2006 Note that this procedure does not prevent a MN from sending packets to its current default router while the RA solicitation is in progress and if reachability with the current default router is unchanged, there should be no change in default router after the RA solicitation completes. If the current default router is still reachable, it will forward the packets. 5.2.8 DNA and Address Configuration [Editor's note: Nothing has changed in this section] When a host moves to a new point of attachment, a potential exists for a change in the validity of its unicast and multicast addresses on that network interface. In this section, host processing for address configuration is specified. The section considers both statelessly and statefully configured addresses. 5.2.8.1 Duplicate Address Detection A DNA host MUST support optimistic Duplicate Address Detection [5] for autoconfiguring unicast link local addresses. If a DNA host uses address autoconfiguration [7] for global unicast addresses, the DNA host MUST support optimistic Duplicate Address Detection for autoconfiguring global unicast addresses. 5.2.8.2 DNA and the Address Autoconfiguration State Machine When a link level event occurs on a network interface indicating that the host has moved from one point of attachment to another, it is possible that a change in the reachability of the addresses associated with that interface may occur. Upon detection of such a link event and prior to sending the RS initiating a DNA exchange, a DNA host MUST change the state of addresses associated with the interface in the following way (address state designations follow RFC 2461): o Addresses in the "Preferred" state are moved to the "Optimistic" state, but the host defers sending out an NS to initiate Duplicate Address Detection. o Addresses in the "Optimistic" state remain in the "Optimistic" state, but the host defers sending out an NS to initiate Duplicate Address Detection. o Addresses in the "Deprecated" state remain in the "Deprecated" state. o No addresses should be in the "Tentative" state, since this state is unnecessary for nodes that support optimistic Duplicate Address Narayanan, et al. Expires April 26, 2007 [Page 38] Internet-Draft DNAv6 October 2006 Detection. A host MUST keep track of which "Preferred" addresses are moved to the "Optimistic" state, so it is possible to know which addresses were in the "Preferred" state and which were in the "Optimistic" state prior to the change in point of attachment. In order to perform the DNA transaction, the DNA host SHOULD select one of the unicast link local addresses that was in the "Preferred" state prior to switching to "Optimistic" and utilize that as the source address on the DNA RS. If the host had no "Preferred" unicast link local address but did have an address in the "Optimistic" state, it MUST utilize such an address as the source address. If the host currently has no unicast link local addresses, it MUST construct one and put it into the "Optimistic" state and note this address as having been in the "Optimistic" state previously, but defer sending the NS to confirm. Note that the presence of a duplicate unicast link local address on the link will not interfere with the ability of the link to route a unicast DNA RA from the router back to the host nor will it result in corruption of the router's neighbor cache, because the TSLLA option is included in the RS and is utilized by the router on the RA frame without changing the neighbor cache. When the host receives unicast or multicast RAs from the router, if the host determines from the received RAs that it has moved to a new link, the host MUST immediately move all unicast global addresses to the "Deprecated" state and configure new addresses using the subnet prefixes obtained from the RA. For all unicast link local addresses, the host MUST initiate NS signaling for optimistic Duplicate Address Detection to confirm the uniqueness of the unicast link local addresses on the new link. If the host determines from the received RAs that it has not moved to a new link (i.e. the link has not changed) and the previous state of an address was "Optimistic", then the host MUST send an NS to confirm that the address is unique on the link. This is required because optimistic Duplicate Address Detection may not have completed on the previous point of attachment, so the host may not have confirmed address uniqueness. If the previous state of an address was "Preferred", whether or not the host initiates optimistic Duplicate Address Detection depends on the configurable DNASameLinkDADFlag flag. A host MUST forgo sending an NS to confirm uniqueness if the value of the DNASameLinkDAD flag is False. If, however, the DNASameLinkDAD flag is True, the host MUST perform optimistic duplicate address detection on its unicast link local and unicast global addresses to determine address uniqueness. Narayanan, et al. Expires April 26, 2007 [Page 39] Internet-Draft DNAv6 October 2006 5.2.8.3 DNA and Statefully Configured Addresses The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM message when a change in point of attachment is detected. Since the DNA protocol provides the same level of movement detection as the DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive signaling. If, however, a non-DNA RA is received, the host SHOULD use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather than wait for additional RAs to perform CPL, since this will reduce the amount of time required for the host to confirm whether or not it has moved to a new link. If the CONFIRM message validates the addresses, the host can continue to use them. When a DNA RA is received and the received RA indicates that the host has not moved to a new link, the host SHOULD apply the same rules to interpreting the 'M' flag in the received RA and any subsequently received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA is received with the 'M' flag set, then the 'M' flag value is copied into the ManagedFlag, and if the ManagedFlag changes from False to True the host should run DHCPv6, but if the ManagedFlag changes from True to False, the host should continue to run DHCPv6. If, however, the value of the ManagedFlag remains the same both before and after the change in point of attachment on the same link has been confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain new addresses, since the old addresses will continue to be valid. If the DNA RA indicates that the host has moved to a new link or the DHCPv6 CONFIRM indicates that the addresses are invalid, the host MUST move its old addresses to the "Deprecated" state and MUST run DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 4-message exchange, however, this exchange allows for redundancy (multiple DHCPv6 servers) without wasting addresses, as addresses are only provisionally assigned to a host until the host chooses and requests one of the provisionally assigned addresses. If the DNA host supports the Rapid Commit Option [16], the host SHOULD use the Rapid Commit Option in order to shorten the exchange from 4 messages to 2 messages. 5.2.8.4 Packet Delivery During DNA The specification of packet delivery before, during, and immediately after DNA when a change in point of attachment occurs is out of scope for this document. The details of how packets are delivered depends on the mobility management protocols (if any) available to the host's stack. Narayanan, et al. Expires April 26, 2007 [Page 40] Internet-Draft DNAv6 October 2006 5.2.8.5 Multicast Address Configuration Multicast routers on a link are aware of which groups are in use within a link. This information is used to undertake initiation of multicast routing for off-link multicast sources to the link [9][17]. If the returning RAs indicate that the host has not moved to a new link, no further action is required for multicast addresses to which the host has subscribed using MLD Report [17]. In particular, the host MUST NOT perform MLD signaling for any multicast addresses unless such signaling was not performed prior to movement to the new point of attachment. For example, if an address is put into the "Optimistic" state prior to movement but the MLD Report for the Solicited_Node_Multicast_Address is not sent prior to movement to a new point of attachment, the host MUST send the MLD Report on the new point of attachment prior to performing optimistic Duplicate Address Detection. The host SHOULD use the procedure described below for sending an MLD Report. If, on the other hand, the DNA RA indicates that the host has moved to a new link, the host MUST issue a new MLD Report to the router for subscribed multicast addresses. MLD signaling for the Solicited_Node_Multicast_Addresses [7] MUST be sent prior to performing signaling for optimistic DAD. To avoid lengthy delays in address reconfiguration, it is RECOMMENDED that the host send the MLD Report for newly configured addresses immediately, as soon as the addresses have been constructed, rather than waiting for a random backoff. Hosts MUST defer MLD signaling until after the results of DNA have confirmed whether or not a link change has occurred. 5.3 DNA without a 'link UP' notification [Editor's note: Do we need this section? The question is raised in the issues section of CPL. If we keep this, the section should be generalised to make it applicable to the whole DNAv6, right now its specific to CPL only ] If the host implementation does not provide any link-layer event notifications [20], and in particular, a link UP notification, the host needs additional logic to try to decide whether a received RA applies to the "old" link or a "new" link. 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 recommendation, or whether we should just require that hosts which Narayanan, et al. Expires April 26, 2007 [Page 41] Internet-Draft DNAv6 October 2006 implement this draft have a 'link UP' notification. If there is no 'link UP' notification when the host might have moved, the host would collect the prefixes from multiple links into a single DNAHostPrefixList, and would never detect movement. Here is an example. The host begins to collect the prefixes on a link. But before the prefix list generation is completed, without its knowledge, the host moves to a new link. Unaware that now it is at the different link, the host keeps collecting prefixes from the received RAs to generate the prefix list. This results in the prefix list containing prefixes from two different links. If the host uses this prefix list, it fails to detect a link change. A possible way to prevent this situation for implementations without a link UP notification, is to treat the arrival of a RA with a disjoint set of prefixes as a hint, as specified below. 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 new Candidate Link object with the information extracted from that RA, and then send an RS as specified in Section 5.2.6. 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 recommends that solicited RAs be multicast.) The danger is exemplified by this: 1. Assume the host has a DNAHostPrefixList with prefixes P1 and P2. 2. The host changes link layer attachment, but there is no link UP notification. 3. The host receives an RA with a disjoint set of prefixes: prefix P3. This causes the host to form a new DNAHostPrefixList with P3 and send an RS. 4. The host again changes link layer attachment, and no link UP notification. 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 response to the RS it send above. The host ends up adding this to the DNAHostPrefixList, which now has P3 and P4, even though those prefixes are assigned to different links. There doesn't appear to be a way to solve this problem without changes to the routers and the Router Advertisement messages. Narayanan, et al. Expires April 26, 2007 [Page 42] Internet-Draft DNAv6 October 2006 However, the probability of this occurring can be limited by limiting the window of exposure. The simplest approach is for the host to assume that any RA received within MinRAWait seconds after sending an RS was in response to the RS. Basically this relies on the small probability of both moving again in that MinRAWait second interval, 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 bullet-proof. 6. Tentative options for IPv6 ND 6.1 Sending solicitations containing Tentative Options Tentative Options may be sent in Router and Neighbour Solicitations, as described below. In a case where it is safe to send a Source Link-Layer Address Option, a host SHOULD NOT send a TO, since the message may bemisinterpreted by legacy nodes. Importantly, a node MUST NOT send a Tentative Option in the same message where a Source Link-Layer Address Option is sent. 6.1.1 Sending Neighbour Solicitations with Tentative Options Neighbour Solicitations sent to unicast addresses MAY contain a Tentative Option. Since delivery of a packet to a unicast destination requires prior knowledge of the destination's hardware address, unicast Neighbour Solicitation packets may only be sent to destinations for which a neighbour cache entry already exists. For example, if checking bidirectional reachability to a router, it may be possible to send a Neighbour Solicitation with Tentative Option to the router's advertised address. As discussed in [3], the peer device may not have a cache entry even if the soliciting host does, in which case reception of the Tentative Option may create a neighbour cache entry, without the need for neighbour discovering the original solicitor. 6.1.2 Sending Router Solicitations with Tentative Options Any Router Solicitation from a Preferred, Deprecated or Optimistic address MAY be sent with a Tentative Option [5]. An extension which allows Router Solicitations to be sent with a TO Narayanan, et al. Expires April 26, 2007 [Page 43] Internet-Draft DNAv6 October 2006 from the unspecified address is described in Appendix B. 6.2 Receiving Tentative Options Receiving a Tentative Option allows nodes to unicast responses to solicitations without performing neighbour discovery. It does this by allowing the solicitation to create STALE neighbour cache entries if one doesn't exist, but only update an entry if the link-layer address in the option matches the entry. Additionally, messages containing TO may be used to direct advertisements to particular link-layer destinations without updating neighbour cache entries. This is described in Appendix B. Use of Tentative Options is only defined for Neighbour and Router Solicitation messages. In any other received message, the presence of the option is silently ignored, that is, the packet is processed as if the option was not present. It is REQUIRED that the same validation algorithms for Neighbour and Router Solicitations received with TO as in the IPv6 Neighbour Discovery specification [3], are used. In the case that a solicitation containing a Tentative Option is received, The only processing differences occur in checking and updating the neighbour cache entry. Particularly, there is no reason to believe that the host will remain tentative after receiving a responding advertisement. Tentative Options do not overwrite existing neighbour cache entries where the link-layer addresses of the option and entry differ. If a solicitation from a unicast source address is received where no difference exists between the TO and an existing neighbour cache entry, the option MUST be treated as if it were an SLLAO after message validation, and processed accordingly. In the case that a cache entry is unable to be created or updated due to existence of a conflicting neighbour cache entry, it MUST NOT update the neighbour cache entry. An extension which allows a direct advertisement to the soliciting host without modifying the neighbour cache entry is described in Appendix B. Narayanan, et al. Expires April 26, 2007 [Page 44] Internet-Draft DNAv6 October 2006 6.2.1 Receiving Neighbour Solicitations containing Tentative Options The Tentative Option is only [Editor's note: This only is not right? TO is allowed in both NS and RS? right?] allowed in Neighbour Solicitations with specified source addresses for which SLLAO is not required. A Neighbour Solicitation message received with a TO and an unspecified source address MUST be silently discarded. Upon reception of a Tentative Option in a Neighbour Solicitation for which the receiver has the Target Address configured, a node checks to see if there is a neighbour cache entry with conflicting link- layer address. If no such entry exists, the neighbour cache of the receiver SHOULD be updated, as if the Tentative Option was a SLLAO. Sending of the solicited Neighbour Advertisement then proceeds normally, as defined in section 7.2.4 of [3]. If there is a conflicting neighbour cache entry, the node processes the solicitation as defined in Section 7.2.4 of [3], except that the Neighbour Cache entry MUST NOT be modified. 6.2.2 Receiving Router Solicitations containing Tentative Options In IPv6 Neighbour Discovery [3], responses to Router Solicitations are either sent to the all-nodes multicast address, or may be sent to the solicitation's source address if it is a unicast address. Including a Tentative Option in the solicitation allows a router to choose to send a packet directly to the link-layer address even in situations where this would not normally be possible. For Router Solicitations with unicast source addresses, neighbour caches SHOULD be updated with the link-layer address from a Tentative Option if there is no differing neighbour cache entry. In this case, Router Advertisement continues as in Section 6.2.6 of [3]. For received solicitations with a differing link-layer address to that stored in the neighbour cache, the node processes the solicitation as defined in Section 6.2.6 of [3], except that the Neighbour Cache entry MUST NOT be modified. 7. Initiation of DNA Procedures Link change detection procedures defined in the document are Narayanan, et al. Expires April 26, 2007 [Page 45] Internet-Draft DNAv6 October 2006 initiated when "link UP" event notification. This event indicates that network reachability or configuration is suspect and is called a hint. In this section, other possible hints that can imply that the configuration is suspect are presented and discussed. [Editor's note: Is this section useful?] Hints MAY be used to update a wireless host's timers or probing behavior in such a way as to assist detection of network attachment. Hints SHOULD NOT be considered to be authoritative for detecting IP configuration change by themselves. In some cases, hints will carry significant information (for example a hint indicating PPP IPv6CP open state [8]), although details of the configuration parameters may be available only after other IP configuration procedures. Implementers are encouraged to treat hints as though they may be incorrect, and require confirmation. Hosts MUST ensure that untrusted hints do not cause unnecessary configuration changes, or significant consumption of host resources or bandwidth. In order to achieve this aim, a host MAY implement hysteresis mechanisms such as token buckets, hint weighting or holddown timers in order to limit the effect of excessive hints. 7.1 Hints Due to Network Layer Messages Hint reception may be due to network-layer messages such as unexpected Router Advertisements, multicast listener queries or ICMPv6 error messages [3][9][10]. In these cases, the authenticity of the messages MUST be verified before expending resources to initiate DNA procedure. When a host arrives on a new link, hints received due to external IP packets will typically be due to multicast messages. Actions based on multicast reception from untrusted sources are dangerous due to the threat of multicast response flooding. This issue is discussed further in Section 9. State changes within the network-layer itself may initiate link- change detection procedures. Existing subsystems for router and neighbor discovery, address leasing and multicast reception maintain their own timers and state variables. Changes to the state of one or more of these mechanisms may hint that link change has occurred, and initiate detection of network attachment. 7.2 Handling Hints from Other Layers Events at other protocol layers may provide hints of link change to network attachment detection systems. Two examples of such events Narayanan, et al. Expires April 26, 2007 [Page 46] Internet-Draft DNAv6 October 2006 are TCP retransmission timeout and completion of link-layer access procedures [20]. While hints from other protocol layers originate from within the host's own stack, the network layer SHOULD NOT treat hints from other protocol layers as authoritative indications of link change. This is because state changes within other protocol layers may be triggered by untrusted messages, come from compromised sources (for example 802.11 WEP Encryption [15]) or be inaccurate with regard to network-layer state. While these hints come from the host's own stack, such hints may actually be due to packet reception or non-reception events at the originating layers. As such, it may be possible for other devices to instigate hint delivery on a host or multiple hosts deliberately, in order to prompt packet transmission, or configuration modification. Therefore, hosts SHOULD NOT change their configuration state based on hints from other protocol layers. A host MAY adopt an appropriate link change detection strategy based upon hints received from other layers, with suitable caution and hysteresis. 7.3 Timer and Loss Based Hints Other hints may be received due to timer expiry, particularly In some cases the expiry of these timers may be a good hint that DNA procedures are necessary. Since DNA is likely to be used when communicating with devices over wireless links, suitable resilience to packet loss SHOULD be incorporated into the DNA initiation system. Notably, non-reception of data associated with end-to-end communication over the Internet may be caused by reception errors at either end or because of network congestion. Hosts SHOULD NOT act immediately on packet loss indications, delaying until it is clear that the packet losses aren't caused by transient events. Use of the Advertisement Interval Option specified in [6] follows these principles. Routers sending this option indicate the maximum interval between successive router advertisements. Hosts receiving this option monitor for multiple successive packet losses and initiate change discovery. 7.4 Simultaneous Hints Some events which generate hints may affect a number of devices simultaneously. Narayanan, et al. Expires April 26, 2007 [Page 47] Internet-Draft DNAv6 October 2006 For example, if a wireless base station goes down, all the hosts on that base station are likely to initiate link-layer configuration strategies after losing track of the last beacon or pilot signal from the base station. As described in [3][10], a host SHOULD delay randomly before acting on a widely receivable advertisement, in order to avoid response implosion. Where a host considers it may be on a new link and learns this from a hint generated by a multicast message, the host SHOULD defer 0-1000ms in accordance with [3][7]. Please note though that a single desynchronization is required for any number of transmissions subsequent to a hint, regardless of which messages need to be sent. In link-layers where sufficient serialization occurs after an event experienced by multiple hosts, each host MAY avoid the random delays before sending solicitations specified in [3]. 7.5 Hint Management for Inactive Hosts If a host does not expect to send or receive packets soon, it MAY choose to defer detection of network attachment. This may preserve resources on latent hosts, by removing any need for packet transmission when a hint is received. These hosts SHOULD delay 0-1000ms before sending a solicitation, and MAY choose to wait up to twice the advertised Router Advertisement Interval (plus the random delay) before sending a solicitation [6]. One benefit of inactive hosts' deferral of DNA procedures is that herd-like host configuration testing is mitigated when base-station failure or simultaneous motion occur. When latent hosts defer DNA tests, the number of devices actively probing for data simultaneously is reduced to those hosts which currently support active data sessions. When a device begins sending packets, it will be necessary to test bidirectional reachability with the router (whose current Neighbor Cache state is STALE). As described in [3], the host will delay before probing to allow for the probability that upper layer packet reception confirms reachability. 8. Complications to Detecting Network Attachment Detection of network attachment procedures can be delayed or may be incorrect due to different factors. This section gives some examples where complications may interfere with DNA processing. Narayanan, et al. Expires April 26, 2007 [Page 48] Internet-Draft DNAv6 October 2006 8.1 Packet Loss Generally, packet loss introduces significant delays in validation of current configuration or discovery of new configuration. Because most of the protocols rely on timeout to consider that a peer is not reachable anymore, packet loss may lead to erroneous conclusions. Additionally, packet loss rates for particular transmission modes (multicast or unicast) may differ, meaning that particular classes of DNA tests have higher chance of failure due to loss. Hosts SHOULD attempt to verify tests through retransmission where packet loss is prevalent. 8.2 Router Configurations Each router can have its own configuration with respect to sending RA, and the treatment of router and neighbor solicitations. Different timers and constants might be used by different routers, such as the delay between Router Advertisements or delay before replying to an RS. If a host is changing its IPv6 link, the new router on that link may have a different configuration and may introduce more delay than the previous default router of the host. The time needed to discover the new link can then be longer than expected by the host. 8.3 Overlapping Coverage If a host can be attached to different links at the same time with the same interface, the host will probably listen to different routers, at least one on each link. To be simultaneously attached to several links may be very valuable for a MN when it moves from one access network to another. If the node can still be reachable through its old link while configuring the interface for its new link, packet loss can be minimized. Such a situation may happen in a wireless environment if the link layer technology allows the MN to be simultaneously attached to several points of attachment and if the coverage area of access points are overlapping. For the purposes of DNA, it is necessary to treat each of these points-of-attachment separately, otherwise incorrect conclusions of link-change may be made even if another of the link-layer connections is valid. 8.4 Multicast Snooping When a host is participating in DNA on a link where multicast Narayanan, et al. Expires April 26, 2007 [Page 49] Internet-Draft DNAv6 October 2006 snooping is in use, multicast packets may not be delivered to the LAN-segment to which the host is attached until MLD signaling has been performed [9][17] [11]. Where DNA relies upon multicast packet delivery (for example, if a router needs to send a Neighbor Solicitation to the host), its function will be degraded until after an MLD report is sent. Where it is possible that multicast snooping is in operation, hosts MUST send MLD group joins (MLD reports) for solicited nodes' addresses swiftly after starting DNA procedures. 8.5 Link Partition Link partitioning occurs when a link's internal switching or relaying hardware fails, or if the internal communications within a link are prevented due to topology changes or wireless propagation. When a host is on a link which partitions, only a subset of the addresses or devices it is communicating with may still be available. Where link partitioning is rare (for example, with wired communication between routers on the link), existing router and neighbor discovery procedures may be sufficient for detecting change. 9. Security Considerations 9.1 Attacks on the Token Bucket A host on the link could easily drain the token bucket(s) of the router(s) on the link by continuously sending RS messages on the link. For example, if a host sends one RS message every UnicastRAInterval, and send a additional RS every third UnicastRAInterval, the token bucket in the router(s) on the link will drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. For the recommended values of UnicastRAInterval and MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear whether arrival of such RS messages can be recognized by the router as a DoS attack. This attack can also be mitigated by aggregating responses. Since only one aggregation is possible in this interval due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able protect the tokens in the bucket. 9.2 Attacks on DNA Hosts RFC 3756 outlines a collection of threats involving rouge routers. Since DNAv6 requires a host to obtain trustworthy responses from routers, such threats are relevant to DNAv6. In order to counter such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure router discovery. Narayanan, et al. Expires April 26, 2007 [Page 50] Internet-Draft DNAv6 October 2006 9.3 Tentative options The use of the Tentative Option in Neighbour and Router Solicitation messages acts in a similar manner to SLLAO, updating neighbour cache entries, in a way which causes packet transmission. Particular care should be taken that transmission of messages complies with existing IPv6 Neighbour Discovery Procedures, so that unmodified hosts do not receive invalid messages. An attacker may cause messages may be sent to another node by an advertising node (a reflector), without creating any ongoing state on the reflector. This is attack requires one solicitation for each advertisement and the advertisement has to go to a unicast MAC destination. That said, the size of the advertisement may be significantly larger than the solicitation, or the attacker and reflector may be on a medium with greater available bandwidth than the victim. For link-layers where it isn't possible to spoof the link-layer source address this allows a slightly increased risk of reflection attacks from nodes which are on-link. Additionally, since a SEND host must always advertise using SEND options and signatures, a non-SEND attacker may cause excess computation on both a victim node and a router by causing SEND advertisement messages to be transmitted to a particular MAC address and the lall-nodes multicast. SEND specifies guidelines to hosts receiving unsolicited advertisements in order to mitigate such attacks [4]. While this is the same effect as experienced when accepting SLLAO from non-SEND nodes, the lack of created neighbour cache entries on the advertiser may make such attacks more difficult to trace. Modification of Neighbour Discovery messages on the network is possible, unless SEND is used. [4] provides a protocol specification in which soliciting nodes sign ND messages with a private key and use addresses generated from this key. Even if SEND is used, the lifetime of a neighbour cache entry may be extended by continually replaying a solicitation message to a particular router or hosts. Since this may be achieved for any Neighbour or Router Solicitation message, corresponding advertisements to the original transmitters of these solicitation messages may occur. Narayanan, et al. Expires April 26, 2007 [Page 51] Internet-Draft DNAv6 October 2006 SEND defines use of Timestamp values to protect a device from attack through replay of previously sent messages. Although this applies to Neighbour and Router Solicitation messages, granularity of the timestamp allows the messages to be used for up to five minutes [4]. All Router and Neighbour Solicitations using SEND contain a Nonce option, containing a random identifier octet string. Since SEND messages are digitally signed, and may not be easily modified, replay attacks will contain the same Nonce option, as was used in the original solicitation. 9.4 Authorization and Detecting Network Attachment When a host is determining if link change has occurred, it may receive messages from devices with no advertised security mechanisms purporting to be routers, nodes sending signed router advertisements but with unknown delegation, or routers whose credentials need to be checked [12]. Where a host wishes to configure an unsecured router, it SHOULD confirm bidirectional reachability with the device, and it MUST mark the device as unsecured as described in [4]. In any case, a secured router SHOULD be preferred over an unsecured one, except where other factors (unreachability) make the router unsuitable. Since secured routers' advertisement services may be subject to attack, alternative (secured) reachability mechanisms from upper layers, or secured reachability of other devices known to be on the same link may be used to check reachability in the first instance. 9.5 Addressing While a DNA host is checking for link-change, and observing DAD, it may receive a DAD defense NA from an unsecured source. SEND says that DAD defenses MAY be accepted even from non SEND nodes for the first configured address [4]. While deconfiguring the address is a valid action in the case where a host collides with another address owner after arrival on a new link, In the case that the host returns immediately to the same link, such a DAD defense NA message can only be a denial-of-service attempt. 9.6 Hint Management Security Events originating at other protocol layers may provide hints of link change to network attachment detection systems. Two examples of such events are TCP retransmission timeout and completion of link-layer access procedures [20]. Narayanan, et al. Expires April 26, 2007 [Page 52] Internet-Draft DNAv6 October 2006 While hints from other protocol layers originate from within the host's own stack, the network layer SHOULD NOT treat hints from other protocol layers as authoritative indications of link change. This is because state changes within other protocol layers may be triggered by untrusted messages, come from compromised sources (for example 802.11 WEP Encryption [15]) or be inaccurate with regard to network-layer state. While these hints come from the host's own stack, such hints may actually be due to packet reception or non-reception events at the originating layers. As such, it may be possible for other devices to instigate hint delivery on a host or multiple hosts deliberately, in order to prompt packet transmission, or configuration modification. Therefore, hosts SHOULD NOT change their configuration state based on hints from other protocol layers. A host MAY adopt an appropriate link change detection strategy based upon hints received from other layers, with suitable caution and hysteresis. 10. IANA Considerations This memo defines two new Neighbor Discovery [3] options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery messages: 1. The Landmark option, described in Section 4.3; and 2. The Learned Prefix option, described in Section 4.4. 3. The tentative option, described in Section 4.5 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 Narayanan, et al. Expires April 26, 2007 [Page 53] Internet-Draft DNAv6 October 2006 1. The protocol uses only the prefixes with lifetime greater than 1.5 hours. 1.5 hour is decided with the assumption that MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to increase the value into hours or even days because it would be difficult to waken all idle nodes in every 30 mins in cellular network. 2. There may be a link where no prefix is advertised. For example, an network administrator may not support stateless address autoconfiguration for policy reason. Then it won't advertise any prefix with A-bit set. Also it may want all traffic going through an AR and not allow direct communication among hosts because of accounting. Then it won't advertise any prefix with L-bit set either. As of my knowledge the prefix without any bit set won't be advertised, which would hurt DNA operation. 3. Third, I propose we do away with 'Landmark Option with Y bit'. The router can notify no-link change by simply putting the landmark prefix in either PIO or LPIO. Then we can remove the check for landmark from Section 5.2.7. 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 documents. The draft-ietf-dna-protocol-01.txt authored by James Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock 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 for the complete prefix list mechanism described in this document. The best current practice for hosts draft (draft-ietf-dna-hosts-03) authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and the tentative options (draft-ietf-dna-tentative-00) authored by Greg Daley, Erik Normark and Nick Moore were also adopted into this document. 14. Acknowledgments The design presented in this document grew out of discussions among the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). The spirited debates on the design, and the advantages and dis- advantages of various DNA solutions helped the creation of this document. Narayanan, et al. Expires April 26, 2007 [Page 54] Internet-Draft DNAv6 October 2006 Thanks to Syam Madanapalli who co-authored draft-jinchoi-dna-protocol2 from which this draft draws ideas, as well as providing feedback on draft-pentland-dna-protocol from which most of the text for this draft comes. Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol and for helping to work out how to merge the two drafts into this one. Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review of draft-ietf-dna-protocol-01. Thanks to Gabriel Montenegro for his review of draft-pentland-dna-protocol. Thanks also to other members of the DNA working group for their comments that helped shape this work. 15. References 15.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006. 15.2 Informative References [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [7] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462 2462, December 1998. [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. Narayanan, et al. Expires April 26, 2007 [Page 55] Internet-Draft DNAv6 October 2006 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [10] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC2463 2463, December 1998. [11] Christensen, M., Kimball, K., and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 (work in progress), February 2005. [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [13] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005. [14] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [15] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999. [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005. [20] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-00 (work in progress), September 2004. [21] Yamamoto, S., "Detecting Network Attachment Terminology", draft-yamamoto-dna-term-00 (work in progress), February 2004. [22] Manner, J. and M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-06 (work in progress), February 2004. Narayanan, et al. Expires April 26, 2007 [Page 56] Internet-Draft DNAv6 October 2006 [23] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix list based approach", draft-ietf-dna-cpl-00 (work in progress), April 2005. Authors' Addresses Sathya Narayanan (editor) Panasonic Princeton Laboratory Two Research Way, 3rd Floor Princeton, NJ 08540 USA Phone: +1 609 734 7599 Email: sathya@Research.Panasonic.COM James Kempf DoCoMo Communications Labs USA USA Phone: Email: kempf@docomolabs-usa.com Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Mountain View, CA USA Phone: +1 650 786 2921 Email: erik.nordmark@sun.com Brett Pentland Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 5245 Email: brett.pentland@eng.monash.edu.au Narayanan, et al. Expires April 26, 2007 [Page 57] Internet-Draft DNAv6 October 2006 JinHyeock Choi Samsung Advanced Institute of Technology PO Box 111 Suwon 440-600 Korea Phone: +82-31-280-8194 Email: jinchoe@samsung.com Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical adn Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 Email: greg.daley@eng.monash.edu.au Nicolas Montavont LSIIT - Univerity Louis Pasteur Pole API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 Email: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Nick 'Sharkey' Moore Email: sharkey@zoic.org Appendix A. How the Goals are Met? The DNA goals document [19] contains a list of goals identified by G1 to G10. This section discusses how the proposed scheme addresses each of these goals. G1 The Complete RA contains the complete list of prefixes advertised on the link allowing the host to determine whether link change has occurred and to re-configure if necessary. Narayanan, et al. Expires April 26, 2007 [Page 58] Internet-Draft DNAv6 October 2006 G2 Under normal circumstances the host will receive a RA response within round-trip time and some processing time on the router. If the first RA message is lost, if another router is on the link, a second RA should arrive within a slot time and so on. G3 Non movement scenarios will be correctly identified because the landmark will be confirmed by the router(s) on the link or the Complete RA will have prefixes that have already been seen, indicating non-movement. G4 A single RS/RA message exchange is initiated in response to a hint that link change may have occurred. G5 The existing RS/RA signalling is used along with unsolicited RA messages. Some new options and flags are proposed. G6 Only link scope signaling is used. G7 SEND can be used to protect the RS and RA messages exchanged. G8 If SEND is not deployed, then a rogue device could cause a host to think its configuration is invalid by sending an RA that answers the RS question incorrectly. A similar effect is already possible, however, by a rogue device sending an RA with valid prefixes with zero lifetimes. G9 The CPL logic allows a graceful fallback position for dealing with non-DNA routers and non DNA hosts will still receive the benefit of receiving an RA response from its current router faster than RFC 2461. G10 This technique is carried out on an interface by interface basis. A host with multiple interfaces can get information about changes to configuration on each interface, but would need a higher level process to decide how the information from the various interfaces relates to each other. Appendix B. Sending directed advertisements without the neighbour cache In the case where an entry is unable to be added to the neighbour cache, a node MAY send responses direct to the link-layer address specified in the Tentative Option. Also, RS packets sent without a specificed source address may potentially contain a Tentative Option. In this case the unicast link-layer address from the solicitation MAY be extracted from the Tentative Option and used as the destination of the link-layer frame for a responding Router Advertisment. Narayanan, et al. Expires April 26, 2007 [Page 59] Internet-Draft DNAv6 October 2006 Sending such a packet MUST NOT consult the neighbour or destination caches for address. Such packets SHOULD scheduled as if they were unicast advertisements as specified in [3]. If an implementation can not send a Router Advertisement using information from the Tentative Option i.e, without consulting the neighbour cache, then it SHOULD behave as if the Tentative Option was not present in the solicitation message. Narayanan, et al. Expires April 26, 2007 [Page 60] Internet-Draft DNAv6 October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan, et al. Expires April 26, 2007 [Page 61]