DNA Working Group                                               J. Kempf
Internet-Draft                            DoCoMo Communications Labs USA
Expires: December 27, 2006                                      S. Narayanan
                                                               Panasonic
                                                             E. Nordmark
                                                        Sun Microsystems
                                                        B. Pentland, Narayanan, Ed.
                                                  Monash University CTIE
                                                                JH. Choi
                                                             Samsung AIT
                                                           June 25,
Internet-Draft                                                 Panasonic
Expires: April 23, 2007                                 October 20, 2006

         Detecting Network Attachment in IPv6 Networks (DNAv6)
                     draft-ietf-dna-protocol-01.txt
                     draft-ietf-dna-protocol-02.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 December 27, 2006. April 23, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Efficient detection of network attachment in IPv6 needs the following
   two
   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
   responding to router solicitation messages imposed by RFC 2461 makes to
   it difficult to receive an RA quickly.  In this memo, an integrated solution is
   presented.  Monitoring of prefixes by both 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 used presented.  A more efficient link-identification mechanism
   requiring the DNAv6 routers to achieve monitor the link identification while router advertisements are sent
   rapidly for advertised
   prefixes to assist the hosts in link identification combined with a deterministic order by combining
   fast router solicitation
   source addresses with hash-based advertisement mechanism that selects the order of
   response for the router tokens. deterministicly is also presented.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5

   2.   Terms and Abbreviations  . . . . . . . . . . . . . . . . . .   5

   3.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   5   6
     3.1  Link Identification  . . . . . . . . . . . . . . . . . . .   5   6
     3.2  Fast Router Advertisement  . . . . . . . . . . . . . . . .   7   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  . . . . . . . . . . . . . . . . . . . . . .   8  13
     4.1  Router Advertisement . . . . . . . . . . . . . . . . . . .   8  13
     4.2  Prefix Information Option LinkID Bit . . . . . . . . . . .   9  14
     4.3  Landmark Option  . . . . . . . . . . . . . . . . . . . . .  10  14
     4.4  Learned Prefix Option  . . . . . . . . . . . . . . . . . .  12  16
     4.5  Tentative option . . . . . . . . . . . . . . . . . . . . .  18

   5.   DNA Operation  . . . . . . . . . . . . . . . . . . . . . . .  13  19
     5.1  DNA Router Operation . . . . . . . . . . . . . . . . . . .  13  19
       5.1.1  Data Structures  . . . . . . . . . . . . . . . . . . .  14  19
       5.1.2  Router Configuration Variables . . . . . . . . . . . .  15  20
       5.1.3  Bootstrapping DNA Data Structures  . . . . . . . . . .  16  21
       5.1.4  Processing Router Advertisements . . . . . . . . . . .  16  22
       5.1.5  Processing Router Solicitations  . . . . . . . . . . .  17  22
       5.1.6  Complete Router Advertisements . . . . . . . . . . . .  18  23
       5.1.7  LinkID . . . . . . . . . . . . . . . . . . . . . . . .  18  24
       5.1.8  Scheduling Fast Router Advertisements  . . . . . . . .  19  25
       5.1.9  Scheduling Unsolicited Router Advertisements . . . . .  20  26
       5.1.10   Removing a Prefix from an Interface  . . . . . . . .  20  26
       5.1.11   Prefix Reassignment  . . . . . . . . . . . . . . . .  21  26
     5.2  DNA Host Operation . . . . . . . . . . . . . . . . . . . .  21  27
       5.2.1  Data Structures  . . . . . . . . . . . . . . . . . . .  21  27
       5.2.2  Host Configuration Variables . . . . . . . . . . . . .  22  28
       5.2.3  Selection of a Landmark Prefix . .  Detecting Network Attachment Steps . . . . . . . . . .  22  29
       5.2.4  Sending Router Solicitations . .  Making use of Prior Information  . . . . . . . . . . .  23  30
       5.2.5  Selection of a Landmark Prefix . . . . . . . . . . . .  30
       5.2.6  Sending Router Solicitations . . . . . . . . . . . . .  31
       5.2.7  Processing Router Advertisements . . . . . . . . . . .  23
       5.2.6  32
       5.2.8  DNA and Address Configuration  . . . . . . . . . . . .  25

   6.   Backward Compatibility  37
     5.3  DNA without a 'link UP' notification . . . . . . . . . . .  41

   6.   Tentative options for IPv6 ND  . . . . . . . . . .  29 . . . . .  42
     6.1  Non-DNA Host  Sending solicitations containing Tentative Options . . . .  42
       6.1.1  Sending Neighbour Solicitations with DNA Routers Tentative
              Options  . . . . . . . . . . . . . .  29
     6.2  DNA Host . . . . . . . . .  43
       6.1.2  Sending Router Solicitations with Non-DNA Routers Tentative Options  .  43
     6.2  Receiving Tentative Options  . . . . . . . . . . . . .  29

   7.   Security Considerations . .  43
       6.2.1  Receiving Neighbour Solicitations containing
              Tentative Options  . . . . . . . . . . . . . . . .  29
     7.1  Attacks on the Token Bucket . .  44
       6.2.2  Receiving Router Solicitations containing Tentative
              Options  . . . . . . . . . . . . . . .  29
     7.2  Attacks on . . . . . . . .  45

   7.   Initiation of DNA Hosts Procedures . . . . . . . . . . . . . . . .  45
     7.1  Hints Due to Network Layer Messages  . . .  29

   8.   IANA Considerations . . . . . . . .  46
     7.2  Handling Hints from Other Layers . . . . . . . . . . . .  30

   9.   Acknowledgments .  46
     7.3  Timer and Loss Based Hints . . . . . . . . . . . . . . . .  47
     7.4  Simultaneous Hints . . . . .  30
   10.  References . . . . . . . . . . . . . . .  47
     7.5  Hint Management for Inactive Hosts . . . . . . . . . .  31
     10.1   Normative References . .  48

   8.   Complications to Detecting Network Attachment  . . . . . . .  48
     8.1  Packet Loss  . . . . . . . . .  31
     10.2   Informative References . . . . . . . . . . . . . .  48
     8.2  Router Configurations  . . .  31

        Authors' Addresses . . . . . . . . . . . . . . .  48
     8.3  Overlapping Coverage . . . . . .  32

   A.   How the Goals are Met? . . . . . . . . . . . . .  49
     8.4  Multicast Snooping . . . . . .  33

        Intellectual Property and Copyright Statements . . . . . . .  35

1.  Introduction

   The proposed scheme in this memo is built upon the following
   solutions catalogued in [16]: Complete RA is used for . . . . . . .  49
     8.5  Link Partition . . . . . . . . . . . . . . . . . . . . . .  49

   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  50
     9.1  Attacks on the link
   identification, and Hash-based Token Bucket  . . . . . . . . . . . . . . .  50
     9.2  Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . .  50
     9.3  Tentative options  . . . . . . . . . . . . . . . . . . . .  50
     9.4  Authorization and Detecting Network Attachment . . . . . .  51
     9.5  Addressing . . . . . . . . . . . . . . . . . . . . . . . .  52
     9.6  Hint Management Security . . . . . . . . . . . . . . . . .  52

   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  53

   11.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . .  53

   12.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .  53

   13.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  54

   14.  References . . . . . . . . . . . . . . . . . . . . . . . . .  54
     14.1   Normative References . . . . . . . . . . . . . . . . . .  54
     14.2   Informative References . . . . . . . . . . . . . . . . .  55

        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  56

   A.   How the Goals are Met? . . . . . . . . . . . . . . . . . . .  58

   B.   Sending directed advertisements without the neighbour
        cache  . . . . . . . . . . . . . . . . . . . . . . . . . . .  59

        Intellectual Property and Copyright Statements . . . . . . .  60

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.

   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
   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
   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
   recommends that NUM_RS_RA_COMPLETE 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].

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 MAX_RA_WAIT.

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

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)
      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
   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.

   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.

     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
      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)
   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
   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
      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
   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.

   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 is used
   already scheduled for transmission in the next MulticastRADelay the
   RA MUST be sent to achieve fast the link-scoped all-nodes multicast address at the
   current time plus MulticastRADelay.

   If a unicast response to RS messages.  Aspects of prefix-based LinkID and
   Requested Landmark are included to allow for is not possible but there is a decrease multicast RA
   already scheduled for transmission in the packet
   sizes associated with next MulticastRADelay, then
   the Router Solicitation MUST be silently discarded.

5.1.6  Complete RA.

   The rest 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 document refers learned prefixes as will fit is added.

   It may not be possible to this approach by include all of the term "DNAv6".

2.  Terms prefixes in use on the
   link due to MTU or administrative limitations.  If all Prefix
   Information Options and Abbreviations

   There 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 an existing DNA terminology draft [13].  This draft does not
   introduce any new terminology not already used by existing drafts.

   The term "link" 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 used as defined not in RFC 2460 [2].  NOTE: this is
   completely different from
   the term "link" as used by IEEE 802, etc.

3.  Overview

   The DNA protocol presented router's DNARouterPrefixList and not in this document tries to achieve the
   following objectives:

   o  Eliminate router's
   AdvPrefixList then the delays introduced by RFC 2461 router SHOULD include a Landmark Option with
   the "N" flag set.  If there are known to be prefixes that are not
   included in discovering the
      configuration.

   o  Make Router Advertisement, then the Complete flag MUST NOT
   be set.

   Note that although it may not be possible for the hosts to accurately detect fit all of the identity prefixes
   into an RA, the LinkID MUST be included.

5.1.7  LinkID

   One of their current link from a single RA.

   DNAv6 assumes that the host's wireless prefixes in use on a link interface software and
   hardware is capable chosen to be the LinkID.

   The LinkID is the numerically smallest prefix stored in either of delivering
   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 'link up' event notification when
   layer 2 on PIO or LPO as
   appropriate.  If the host prefix is configured and sufficiently stable for IP
   traffic.  This event notification acts as included in a hint to 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 layer 3 DNA
   procedures to check whether or not LPO "I" flag MUST be set.

5.1.7.1  Changing the host LinkID

   When either a new prefix is attached added to the same a link as before.  DNAv6 also assumes that an interface on the host is
   never connected to two links at numerically
   smaller than all those previously advertised or the same time.  In lifetime of the case
   prefix that is currently being used as the
   layer 2 technology LinkID falls below 1.5
   hours, a new LinkID is capable of having multiple attachments (for
   instance, multiple layer 2 associations or connections) at determined.  In order to ensure that there is
   overlap between consecutive RAs on the same
   time, DNAv6 requires link, the individual layer-2 associations old LinkID must
   continue to be
   represented as separate (virtual interfaces) to layer 3 and DNAv6 in
   particular.

3.1  Link Identification

   DNAv6 identifies a link by advertised for some time alongside the set new LinkID.

   For the purposes of prefixes propagating information, it is assumed that are assigned to after
   three advertisements of a change, all routers have been made aware of
   the link, which change.

   If the instant that a router sends its first unsolicited
   advertisement is quite natural time T, then by T + 1 hour at least three such
   advertisements will have been made and doesn't require introducing any 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 form
   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 identifier.  However, this choice implies that LinkID, the
   protocol needs to old LinkID MUST be robust against changes included in RAs
   for the set of prefixes
   assigned 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 link, including the case when
   LinkID that is not a link prefix.

   Information from the Learned Prefix Option is renumbered only stored in
   DNAHostPrefixList, and
   the prefix is later reassigned to only used for DNA purposes.  Because a different link.  The protocol
   handles this during graceful renumbering (when the valid lifetime of
   the prefix
   length field is allowed to decrease to zero before used, it is removed and
   perhaps reassigned to a different link), it describes how possible to remove
   and reassign prefixes earlier than this without carry 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 variable length
   identifier less than or equal to both verify whether the host has changed link, 128 bits in an LPO and if store it
   has, provide the host with the configuration information for the new
   link.  The base method for detecting link in
   DNAHostPrefixList (Section 5.2.1).

   Following a change involves getting
   routers to listen to all of LinkID, 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 old LinkID MUST be included in RAs
   in an LPO for the
   prefixes a router would advertise itself as per RFC 2461, and also, following 1.5 hours.

   Future specifications MUST NOT treat the information in an LPO as
   prefixes learned from other routers on such as they would the link that are not
   being advertised by itself.  These learned prefixes are included found in a
   new Learned Prefix Option in
   Information Option.  Future specifications MUST NOT assume that the Router Advertisement.

   A host receiving one of these "Complete RAs" - so marked by
   entries in a flag -
   then knows all of the host's DNAHostPrefixList are actaul 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, and link.  The delay is calculated by inference all
   those that are not.  By comparing this with previously received
   prefixes
   determining a ranking for the host can correctly decide whether it router for the received RS, and
   multiplying that by RASeparation.

   A Host Token is connected needed from the RS to calculate the
   same link router's ranking.
   The first 64 bits of an SHA-1 hash of the source address of the RS
   MUST be used as previously, or whether this Router Advertisement is from
   a new link.  Unlike CPL [15], the RS host does not have 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 wait for
   multiple advertisements before making a decision.

   Though frequently all routers on a link will advertise
   the same set
   of prefixes and thus experience no cost first entry in making the RAs complete,
   there sorted list is potential for ranked zero, the RAs second, one,
   and so on.

      Note: it is not necessary for a router to be large when there are many
   prefixes advertised.  Two mechanisms are defined that allow certain
   RAs actually sort the whole
      list.  Each router just needs to be reduced determine its own position in size.

   One uses a technique called a "landmark", where the host chooses one
   of
      sorted list.

   If Rank < FastRAThreshold, then the prefixes 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.

   If Rank >= FastRAThreshold, then the RA MUST be replaced with a landmark prefix,
   Complete RA, if it is not one already, and then includes this scheduled for multicast
   transmission as in the RFC 2461.

5.1.9  Scheduling Unsolicited Router Solicitation message in the form of a question "am I still
   connected to the link which has this prefix?". Advertisements

   Unsolicited router advertisements MUST be scheduled as per RFC 2461.

   The landmark is
   carried "F" flag in a new option, called the Landmark Option.

   In the case when RA header MUST be set.

   They MAY be Complete RAs or MAY include only a subset of the host is still attached to
   configured prefixes, but MUST include the same link, which
   might occur when LinkID.

   This ensures that there will be overlap in the host has changed 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 using one layer 2 access
   point an Interface

   When a prefix is to another, but stop being advertised in a PIO in RAs by an
   interface before the access points are on expiry of the same link, prefix's valid lifetime, then the
   Router Advertisement(s)
   router should treat it receives will contain as though it has just learned a "yes, that prefix that is
   not explicitly configured on this link" answer, and no other information.  Thus, such RA
   messages are quite small.

   In it.  After sending the case when last RA
   containing the landmark prefix is unknown to in a PIO, the responding
   router, router MUST add the host will receive a "No" answer prefix to its landmark question,
   and also the information
   DNARouterPrefixList and set it needs to configure itself for the new
   link.  The routers try to include as much information as possible expire in
   such messages, so that 1.5 hours or at the host can be informed
   expiry of all the prefixes
   assigned last advertised valid lifetime, whichever is earlier.
   This ensures that to hosts there will be overlap in the new link as soon prefixes in
   the RAs they see and prevent them from incorrectly interpreting
   changed prefixes as possible.

   A second mechanism for reducing packet sizes applies to unsolicited
   Router Advertisements.  By selecting one prefix on movement.

5.1.10.1  Early Removal of the link LinkID Prefix

   If the LinkID prefix is to be the
   "link identifier", and making sure withdrawn early from a link, that it is included in every
   advertisement, it is possible to omit some prefixes.  Such
   advertisements will not inform
   before the expiry of its previously advertised valid lifetime, it
   MUST be advertised for at least 1.5 hours with a host valid lifetime of
   less than 1.5 hours.  This ensures that all of the prefixes at once,
   but in general these unsolicited advertisements will not be other routers are
   notified to begin the first
   advertisement received on a link.  Inclusion process of changing the link identifier
   prefix simply ensures that there is LinkID as well, and
   hosts will always see overlap between the sets of prefixes advertised by each router on a link in consecutive RAs
   and that hosts will thus not incorrectly interpret one of these incomplete RAs as mistake an RA for an indication of movement.

   The Router Advertisement messages are, in general, larger than the
   solicitations, and with multiple routers on the link there will be
   multiple advertisements sent change.

5.1.11  Prefix Reassignment

   A prefix whose lifetime has expired after counting down in real time
   for each solicitation.  This
   amplification can at least 1.5 hours may be used by an attacker reassigned to cause another link immediately
   after expiry.  If a Denial of Service
   attack.  Such attacks are limited by applying prefix is withdrawn from a rate limit on link without counting
   down to the
   unicast Router Advertisements sent directly in response expiry of its valid lifetime, it SHOULD NOT be reassigned
   to each
   solicitation, and using multicast RAs when another link for at least 1.5 hours or until the rate limit original expiry
   time, whichever is
   exceeded.

   In order earlier.  This gives sufficient time for the other
   routers be able that have learned the prefix to both respond 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 landmark
   questions
   old and send the complete RAs, the routers need new links failing to track detect the
   prefixes movement.

   When the host is sure that other routers advertise on the link.  This process prefix list is
   initialized complete, a false
   movement assumption may happen due to renumbering when a router new prefix
   is enabled, by sending a Router
   Solicitation and collecting the resulting RAs, and then multicasting
   a few introduced in RAs more rapidly at about the same time as already suggested in RFC 2461.  This
   process ensures the host handles the
   'link UP' event.  We may solve the renumbering problem with high probability that all minor
   modification like below.

   When a router starts advertising a new prefix, for the routers have time being,
   every time the router advertises a new prefix in an RA, it includes
   at least one old prefix in the same notion of RA.  The old prefix assures that
   the set host doesn't falsely assume a link change because of prefixes a new
   prefix.  After a while, hosts will recognize the new prefix as the
   one assigned to the link.

3.2  Fast Router Advertisement

   According to RFC 2461 a solicited Router Advertisement should have current link and update its prefix list.

   In this way, we may provide a
   random delay between 0 fast and 500 milliseconds, 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 avoid the
   advertisements 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 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, "Prefix List" and multicast RAs are rate
   limited will be referred to one message every 3 seconds.  This implies that
   here as the
   response "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 RS might be delayed up host is not able to 3.5 seconds.

   DNAv6 avoids store this delay by using information for every prefix,
   there is a different mechanism to ensure risk that
   two routers will not respond at exactly the same time while allowing
   one of the routers on the link host will incorrectly decide that it has
   moved to respond immediately.  Since a new link, when it receives advertisements from a non-DNA
   router.

   Prefix entries in the
   hosts might DNAHostPrefixList expire and MUST be likely to use the first responding router as the first
   choice from their default router list, removed
   1.5 hours after they are last seen in a received Router Advertisement
   (in either a PIO or LPO) or at the mechanism also ensures
   that expiry of the same router doesn't respond first to valid lifetime of
   the RSs from different
   hosts.

   The mechanism prefix, whichever is based on the routers earlier.

   Hosts MUST also maintain a list of all LinkIDs seen on the link determining (from
   the same RAs that are used current
   Link.  This list will be referred to as "DNAHostLinkIDList".  This
   list is identical in section Section 3.1 structure to determine all
   the DNAHostPrefixList but contains
   LinkIDs instead of prefixes.

   At this time LinkIDs are also prefixes assigned but in future may be able to the link), the link-local addresses of all
   the
   be identifiers other routers on than prefixes.  A list is stored rather than a
   single entry to allow for changes in the LinkID used on a link.  With this loosely consistent list,
   each router can independently compute some function of

   Entries are expired from DNAHostLinkIDList in the (link-
   local) source address 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 RS following conceptual variables and each 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

   NUM_RS_RA_COMPLETE

      Number of RS/RA exchange messages necessary to declare the routers' link-local
   addresses.  The results of that function are then compared prefix
      list to create
   a ranking, and be complete.

      Default: 1

   MAX_RA_WAIT

      [Editor's note: This should be MIN_RA_WAIT, right?  This is the ranking determines
      minimum time we are recommending the delay each router host should wait before
      assuming cpl?]  Maximum time for the host will use
   when responding have to wait before
      assuming receipt of all possible RAs.

      Default: 4 seconds

   MAX_CACHE_TIME

      [Editor's note: Do we want to keep this and the RS.  The router associated
      Section 5.2.4?]  Maximum time for which is ranked as #0 will
   respond with a zero delay.

   If link information can be
      stored in the routers become out-of-sync with respect to their learned
   router lists, two or more routers may respond with hosts.

      Default: 30 mins

5.2.3  Detecting Network Attachment Steps

   An IPv6 host SHOULD follow the same delay,
   but over time following steps when they receive a
   hint (see also Section 7) indicating the routers will converge on their lists possibility of learned
   routers on link change.
   [Editor's note: Check if DNA steps are correct]

      Try making use of prior information stored related to the link.

4.  Message Formats

   This memo defines two new flags for inclusion links
      the host visited in the router
   advertisement message and two new options.

4.1  Router Advertisement

   DNAv6 modifies past (see Section 5.2.4).

         If the format of prior information implies no link change, the Router Advertisement message by
   defining a bit host MAY
         conduct reachability detection (see Section 5.2.7.4) to indicate that the router sending one of
         the message default routers it is
   participating in using, otherwise no action is needed.

         If the DNAv6 protocol as well as prior information implies that there is a flag to indicate link change or
         there is no useful prior information available, follow the
   completeness of
         procedure below.

      Mark all the set of prefixes included IPv6 addresses in the Router
   Advertisement.  The new message format is use 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| optimistic.

      Set all Neighbor Cache entries for routers on its Default Router Lifetime         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reachable Time                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Retrans Timer                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +   Options ...
    +-+-+-+-+-+-+-+-+-+-+-+-

   FastRA (F)

      The FastRA (F) bit indicates that the
      List to STALE.

      Send router sending the RA is
      participating solicitation.  (See Section 5.2.6).

      Receive router advertisement(s).

      Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add a
      Neighbor Cache Entry in the DNAv6 protocol.  Other routers should include
      this REACHABLE state if one does not
      currently exist.

      Process received router in calculating response delay tokens.

   Complete (C)

      The Complete (C) bit indicates that advertisement.  (See Section 5.2.7).

      If the Router Advertisement
      contains PIOs for all prefixes explicitly configured on link has changed

         Change the
      sending router, and, if other routers on IP configuration parameters of the host (see
         Section 5.2.8).

      If the link are advertising
      additional prefixes, a Learned Prefix Option containing has NOT changed

         Restore the address configuration state of all
      additional prefixes that the router has heard from other routers IPv6
         addresses known to be on the link.

   Reserved (R)

      The reserved field is reduced from 3 bits to 1 bit.

4.2  Prefix Information Option LinkID Bit

   DNAv6 modifies the format

      Update default routers list and their reachability information
      (see Section 5.2.7.4).

5.2.4  Making use of the Prefix Prior Information Option by
   defining a bit to indicate

   A device that has recently been attached to a particular wireless
   base station may still have state regarding 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 IP configuration
   valid for use on that link.  This allows a host to begin any
   configuration procedures before checking the prefix in the Prefix field ongoing validity and
   security 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 parameters.

   The Landmark Option is used by hosts in a Router Solicitation message experimental protocols  CARD [13] and FMIPv6 [14] each provide
   ways to ask the routers generate such information using network-layer signaling,
   before arrival on a link if link.  Additionally, the specified prefix issue is being
   advertised by some router on the link.  It is used by routers in same when a
   Router Advertisement
   host disconnects from one cell and returns to reply 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 corresponding question
   period of time in order to use the information in the future.  When a Router
   Solicitation, indicating whether
   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 referred to the
   host is being
   advertised by any router on using, 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 host SHOULD conclude that it has changed link and
   initiate a new configuration procedure.

   If the length of host finds the prefix it is using in the stored record, a host
   MAY conclude that it is on the option same link, but SHOULD undertake
   reachability testing as described in
      units of 8 octets.  Set Section 5.2.7.4.  In this case,
   the host MUST undertake Duplicate Address Detection [7][5] to 2 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 3.

   Pref Length

      An 8 bit unsigned integer representing address lifetime or
   (at the number outside) MAX_CACHE_TIME time-units.

5.2.5  Selection of bits in the a Landmark Prefix

   For each interface, hosts SHOULD choose a prefix to be used for matching.

   Yes (Y)

      The Yes (Y) bit, when included in use as a Landmark Option
   Prefix in a Router
      Advertisement, indicates that Solicitations.  The following rules are used in
   selecting the landmark prefix:

      The prefix referred to in MUST have a non-zero valid lifetime.  If the Prefix
      field valid
      lifetime of this option is being advertised by one or more routers on
      the current link.  In a previously selected Landmark Option in Prefix expires, a Router Solicitation,
      this bit new
      Landmark Prefix MUST be set to zero and ignored by receivers.

   No (N) selected.

      The No (N) bit, when included in a Landmark Option in a Router
      Advertisement, indicates prefix MUST be one of those that the prefix referred hosts has used to in assign
      a non-link-local address to itself

      The prefix SHOULD be chosen as the Prefix
      field of this option one with the longest preferred
      lifetime, but it is not being advertised by any router on necessary to switch to different prefix if
      the preferred lifetime of the current link.  In landmark prefix changes.

5.2.6  Sending Router Solicitations

   Upon the occurrence of a Landmark Option in Layer 2 link-up event notification, hosts
   SHOULD send a Router Solicitation, Solicitation.  Hosts SHOULD apply rate limiting
   and/or hysteresis to this
      bit MUST be set behaviour as appropriate to zero and ignored by receivers.

   Reserved

      A 38 bit unused field.  It MUST be initialised the link
   technology subject to zero by the
      sender, and ignored by reliability of the receiver.

   Prefix

      A prefix being used by hints.

   When 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 receives a router to indicate
   prefixes that are being advertised in PIOs by other routers on the
   link, but not by itself.

     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 link UP notification from its link layer, it
   sets time_last_linkUP_received to the length of current time.

   The host also uses this to trigger sending an RS, subject to the option rate
   limitations in
      units of 8 octets.

   I

      LinkID (I) flag.  When set indicates [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 first prefix 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
   MAX_RA_WAIT seconds ago, it can not immediately send one when it
   processes a link UP notification.

   If the RS does not result 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 host receiving at least one RA with
   at least one valid prefix, then the prefix lengths of host can retransmit the following prefixes.
      The Prefix Len fields 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 ordered reliable, a host can reset
   the same as number of sent Router Solicitations to 0, while still maintaining
   RTR_SOLICITATION_INTERVAL between RSs.  Resetting the Prefix fields count is
   necessary so that after each link up notification, the first Prefix Len field represents the prefix length of
      the host is
   allowed to send MAX_RTR_SOLICITATIONS to reliably discover the,
   possibly new, prefix contained list.

   Hosts SHOULD include a Landmark Option (LO) in the first prefix field, and so on.

   Padding

      Zero padding sufficient to align RS message with
   the following prefix field on an
      8-octet boundary.

   Prefix

      One or more fields (N) each containing a 128-bit address
      representing a landmark prefix that has been heard chosen based on the rules in Section 5.2.5.

   Hosts SHOULD include a tentative source link but is not
      explicitly configured on this router.

   Description

      This layer address option
   (TO) in the RS message Section 6.  The router solicitation message is
   sent to the All_Routers_Multicast address and the source address MUST only
   be included in a Router Advertisement.  This
      option contains prefixes that are being advertised on the link but
      are not explicitly configured on local address of the sending router. host.

   The router host MUST NOT include any prefixes with a zero valid lifetime consider its link local address to be in the
      LPO.

5.  DNA Operation

5.1  DNA Router Operation

   Routers MUST collect information about
   "Optimistic" state for duplicate address detection [5] until either
   the other routers returned RA confirms that are
   advertising on the link.

5.1.1  Data Structures

   The routers maintain a set of conceptual data structures for each
   interface host has not switched to track the prefixes advertised by other routers on a new link
   or, if an link change has occurred, the
   link, and also host has performed optimistic
   duplicate address detection for the set of DNA routers (the routers that will quickly
   respond to RSs) on address.

5.2.7  Processing Router Advertisements

   When the link.

   For each interface, routers maintain host receives a list of all prefixes learned
   from other routers on Router Advertisement, the link but not explicitly configured on host checks for
   the
   router's own interface.  The list will be referred to following conditions in this
   document as "DNARouterPrefixList".  Prefixes the given order and derives the
   associated conclusions given below [Editor's note: Review and make
   sure that there 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 no corner cases]:

      If the contents of DNARouterPrefixList.  For each prefix RA contains a Landmark Option that matches the router MUST store sufficient information to identify Landmark
      Option in the prefix 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 know when to remove still be current.

      If the prefix RA includes a LinkID that matches an entry from in
      DNAHostLinkIDList, then the list.  This may host can conclude that no link change
      has occurred and the current configuration can be achieved by storing assumed to still
      be current.If the following information:

   1.  Prefix

   2.  Prefix length

   3.  Prefix valid lifetime

   4.  Expiry time

   The expiry time for RA includes a LinkID that is not in
      DNAHostLinkIDList and no prefixes that match entries in DNARouterPrefixList is 1.5 hours
   (three times
      DNAHostPrefixList, then the maximum value of host can conclude that it has changed
      link and SHOULD initiate re-configuration using the Router Advertisement interval)
   after information in
      the last received Router Advertisement affecting Advertisement.

      If the entry, or RA includes a prefix that matches an entry in
      DNAHostPrefixList, then the scheduled expiry of host can conclude that no link change
      has occurred and the prefix valid lifetime, whichever current configuration can be assumed to still
      be current.

      If the RA is
   earlier.

   For each interface, routers also maintain a list of Complete RA, as indicated by the other routers
   advertising on "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 link.  The list will be referred to information in this memo
   as "DNARouterList".  For each router from which a Router
   Advertisement is received with the FastRA flag set, received Router
      Advertisement.

      If the following
   information MUST be stored:

   1.  Link-local source address of advertising router

   2.  Token equal to host has the first 64 bits of an SHA-1 hash of complete prefix list (CPL) and the above
       address

   3.  Expiry time

   Each router MUST RA doest
      NOT include itself any prefixes in either a PIO or LPO that matches a
      prefix in CPL then the DNARouterList host can conclude that link change has
      occurred and generate a
   token for itself as described above based on use the link-local address
   used in its RA messages.

   The expiry time for entries information in DNARouterList is 1.5 hours after the
   last received Router Advertisement affecting RA to configure
      itself.

      If the entry.

5.1.2  Router Configuration Variables

   A DNAv6 router MUST allow for host doesn't have the following conceptual variables to
   be configured by complete prefix list (CPL), the system management.  Default values
      received RA is not complete, contains no prefixes that are set to
   ease configuration load.

   UnicastRAInterval

      The interval stored
      in DNAHostPrefixList, does not contain a Landmark Option that
      matches a corresponding to option in the maximum average rate of Router
      Solicitations that most recent RS and contains
      no LinkID, then the router host SHOULD send RS/RA exchange until
      num_RS_RA is prepared equal to service NUM_RS_RA_COMPLETE to create a new CPL and
      compare it with unicast
      responses.  This is the interval at which already known prefixes.  If after
      NUM_RS_RA_COMPLETE 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 token bucket
      controlling RAs, then
      the unicast responses is replenished.

      Default: 50 milliseconds

   MaxUnicastRABurst

      The maximum size burst of Router Solicitations host MUST conclude that no link change has occured.

5.2.7.1  Pseudocode

   IF (Received RA contains Landmark that matches the router Landmark option in
   the last transmitted RS AND Landmark 'Y' bit is
      prepared set) THEN

   {

      No-link change has occured

      RETURN; // Don't have to service with unicast responses.  This is do the maximum
      number of tokens allowed following checks.

   }

   IF (Received RA contains LinkID) THEN

   {

      IF (LinkID matches an entry in the token bucket controlling the
      unicast responses.

      Default: 20

   RASeparation

      The separation between responses from different routers on the
      same link DNAHostLinkIDList), THEN no-link
      change has occured ELSE link-change.

      RETURN; // Don't have to do the following checks.

   }

   IF (Receive RA contains a single Router Solicitation.

      Default: 20 milliseconds

   MulticastRADelay

      The delay to be introduced when scheduling prefix matching a multicast RA prefix in
      response
   DNAHostPrefixList) THEN

   {

      No link change has occured.

      RETURN; // Don't have to a RS message when do the token bucket following checks.

   }
   IF (Receive RA 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 CompleteRA) THEN

   {

      /* We already checked if there are any matching prefix before.
      Since this is a router first starts up, it SHOULD transmit up
   to MAX_RTR_SOLICITATIONS Router Solicitations separated by
   RTR_SOLICITATION_INTERVAL [3] in order CompleteRA, implies link-change.*/

      Link change has occured.

      RETURN; // Don't have to quickly learn of do the other
   routers and prefixes active on the link.

   Upon startup, a router interface SHOULD also send a few unsolicited
   Router Advertisements following checks.

   }

   IF (DNAHostPrefixList is marked as recommended in Section 6.2.4 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 NUM_RS_RA_COMPLETE exchanges of RFC 2461
   [3], in order RS/RA message to inform others routers on be done
   since the link previous link_up event.

   IF (One of its presence.

   During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) *
   RTR_SOLICITATION_INTERVAL + RetransTimer [3]), received RA contains a router interface
   both sends unsolicited Router Advertisements and responds to Router
   Solicitations, but with prefix matching a few restrictions on prefix in
   DNAHostPrefixList from before link UP event), THEN No link change has
   occured ELSE link change has occured.

5.2.7.2  Maintaining the message content. DNAHostPrefixList

   If a Router Advertisements MUST NOT include Advertisement does not indicate a link change, the host
   updates its DNAHostPrefixList, adding any DNA specific options
   except that new prefixes if necessary.

   If the FastRA flag MUST be set.  The FastRA Router Advertisement has the C 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
   because set, then the router may have incomplete information during bootstrap.

   During host SHOULD
   make the bootstrap period, DNAHostPrefixList match the Complete flag contents of the advertisement
   and mark it as complete (i.e. it becomes CPL).  Any new prefixes are
   added and any prefixes in Router
   Advertisements MUST NOT be set.

   During the bootstrap period, list that are absent in the timing of Router Advertisement
   transmission is as specified
   advertisement are removed.  Expiry times on prefixes are updated if
   the prefix was contained in RFC 2461.

5.1.4  Processing Router Advertisements

   When a router receives a Router Advertisement, PIO, but not if it first validates was contained in an
   LPO.

   If the
   RA Router Advertisement does not have the C flag set, then the
   host SHOULD add any new prefixes and update expiry times as per above,
   but SHOULD NOT remove any entries from DNAHostPrefixList.

   When initiating reconfiguration due to link change, the rules host MUST
   remove all prefixes in RFC 2461, the DNAHostPrefixList and then performs repopulate it with
   the actions
   specified prefixes in RFC 2461.  In addition, each valid Router Advertisement
   is processed as follows:

   If the FastRA flag is set Prefix Information Options and Learned Prefix
   Option, if any, in the RA, RA.

   In addition, the router checks if host maintains previous DNAHostPrefixList.  It is
   per interface since there are some security issues when merging
   across interfaces.

   The operations on DNAHostPrefixList is an
   entry to create a new one, discard
   one, and merge two of them together.  The issues with merging are
   discussed in its DNARouterList.  Thus it looks up the source address of next sub-section.

   For each interface, the host maintains the last time a valid RA was
   received (called time_last_RA_received in that list and, if not found, a new entry is added to
   DNARouterList, including the source address this document), which
   actually ignores RAs without prefix options, and a token equal to the
   first 64 bits of an SHA-1 hash of the source address.  The entry's
   expiry last time is updated.

   Regardless of a link
   UP notification was received from the state of link layer on the FastRA flag, each PIO host (called
   time_last_linkUP_received in the this document).  Together these two
   conceptual variables serve to identify when a RA is
   examined.  If 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 prefix is not in host also maintains a counter (called
   num_RS_RA) which counts how many successful RS/RA exchanges have been
   accomplished since the router's DNARouterPrefixList
   and not in last time the router's AdvPrefixList [3], it host moved to a different link.
   The host declares "one successful RS/RA exchange" is added to the
   DNARouterPrefixList, accomplished
   after it sends an RS, waits for MAX_RA_WAIT seconds and its expiry time is set.

5.1.5  Processing Router Solicitations

   The usual response to receives a Router Solicitation SHOULD
   positive number of resulting RAs.  At least one RA (with at least one
   prefix) should be received.  After the RS, if a unicast RA.
   However, to keep control of link UP event occurs
   before MAX_RA_WAIT seconds expire, the rate of unicast RAs sent, host should not assume that a token
   bucket
   successful RS/RA exchange is used.  The token bucket accomplished.  This counter is filled at one token every
   UnicastRAInterval.  A maximum of MaxUnicastRABurst tokens are stored.

   When a Router Solicitation used to
   determine when DNAHostPrefixList is received, the router checks if considered to be complete.  This
   document considers it is
   possible to send be complete when NUM_RS_RA_COMPLETE number
   of RS/RA exchanges have been completed or a unicast response.  A unicast response requires
   that RA message with the following conditions to be met:

   o  A unicast send token
   complete bit set is available.

   o received.  The source address of the Router Solicitation complete DNAHostPrefixList is NOT also
   refered to as CPL ( Complete Prefix List).

   After NUM_RS_RA_COMPLETE RS/ RA exchange, the
      unspecified address (::).

   If a unicast response is possible and host will generate the Router Solicitation
   contains a Landmark Option whose prefix
   Complete Prefix List if there is included in
   DNARouterPrefixList or AdvPrefixList, the router SHOULD send no packet loss.  Even though some
   packet loss may cause an
   abbreviated Router Advertisement.

   This abbreviated advertisement includes only Incomplete Prefix List, there is a further
   chance for the Landmark Option,
   with host to get the "Y" flag set, plus 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 base first RA header and any SEND options
   as appropriate.  The FastRA flag MUST be set.  The Complete flag MUST
   NOT be set.  This is may contain a
   prefix from its (incomplete) prefix list.  Considering all those
   above, even if the host performs only one exception where the LinkID MAY RS/ RA exchange, it will be
   omitted as
   rather rare for the Y flag implies that host to falsely assume a link change 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 not occured been collecting information about a potentially
   different link in its Current DNAHostPrefixList, and it discovers
   that the previously received LinkID is still current.

   If there it is NO Landmark Option in fact the received Router Solicitation or same link as another DNAHostPrefixList, then
   it contains needs to merge the information in the two objects to produce a Landmark Option whose prefix is NOT included
   single new object.  Since the DNAHostPrefixList contains the most
   recent information, any information contained in
   DNARouterPrefixList or AdvPrefixList 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 a unicast response is not
   possible, then default
   routers, the router SHOULD generate a Complete RA as specified union of these are used in Section 5.1.6.  The 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 include be updated with
   the LinkID, ONLY the linkIDs from the router advertisment.[Editor's note: Do
   we have say something about storing old LinkID list as described in Section 5.1.7.

   If 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 is possible, then to a token is removed and multicast
   RS indicates that the
   Router Advertisement host has bi-directional reachability with the
   routers that responded.  Such reachability is scheduled necessary for transmission the host
   to use a router as specified in
   Section 5.1.8.

   If a unicast response is not possible and there is no multicast RA
   already scheduled for transmission default router, in order to have packets routed
   off the next MulticastRADelay host's current link.  It is notable that the
   RA MUST be sent to choice of
   whether the link-scoped all-nodes messages are addressed to multicast or unicast address at
   will have different reachability implications.  The reachability
   implications from the
   current time plus MulticastRADelay.

   If a unicast response is not possible but there is a multicast RA
   already scheduled hosts' perspective for transmission the four different
   message exchanges defined by RFC 2461 [3] are presented in the next MulticastRADelay, then table
   below.  The host can confirm bi-directional reachability from the Router Solicitation MUST be silently discarded.

5.1.6  Complete Router Advertisements

   A CompleteRA is formed as follows:

   Starting with
   neighbor discovery or router discovery message exchanges except when
   a Router Advertisement with all fixed options (MTU,
   Advertisement Interval, flags, etc.), the FastRA flag multicast RA is set.  As
   many Prefix Information Options received at the host for explicitly configured prefixes as
   will fit are added 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 Advertisement. 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 there is
   sufficient room, a Learned Prefix Option as defined in Section 4.4
   containing as many the destination address of the learned prefixes as will fit received RA is added.

   It may not be possible to include all of a unicast address,
   the prefixes in use on host knows the
   link due to MTU or administrative limitations.  If all Prefix
   Information Options router heard its RS, and a Learned Prefix Option containing all of the
   learned prefixes were included in therefore that the RA, then host
   has reachability with the Complete flag 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 Advertisement header is set.

   If it is not possible List to generate a Complete STALE.  When the host receives an RA but in
   reply to the Router
   Solicitation RS, the host SHOULD mark that this Router Advertisement is in response to, if
   any, includes a Landmark Option containing router's Neighbor Cache
   Entry [3] as REACHABLE, or add a prefix that is not Neighbor Cache Entry in the router's DNARouterPrefixList and
   REACHABLE state if one does not currently exist.

   The host SHOULD also update its Default Router List in the router's
   AdvPrefixList then following
   fashion.  If any of the routers returning RAs are already on the
   default router list, the host SHOULD include a Landmark Option use the information in the RA to
   update the Default Route List entry with the "N" flag set.  If there are known new information.  The
   host SHOULD add entries to be prefixes the Default Router List for any routers
   returning RAs that are not
   included in on the list.  The host SHOULD confine
   selection of a router from the Default Router Advertisement, then List to those routers
   whose Neighbor Cache entries are in the Complete flag MUST NOT
   be set. REACHABLE state.  Note that although it may not be possible to fit all of the prefixes
   into an RA,
   the LinkID MUST Default Router List SHOULD be included.

5.1.7  LinkID

   One updated as described here
   regardless of whether the prefixes RA indicates that the host has changed to a
   new IP link, since changes in use router reachability are possible on a
   some link is chosen to be the LinkID.

   The LinkID is types even if 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 host remains on the right with
   zeros same IP link.

   Note that this procedure does not prevent a MN from sending packets
   to make them 128 bit unsigned integers.

   The prefix may be included in its current default router while the RA solicitation is in either a PIO or LPO as
   appropriate.  If
   progress and if reachability with the prefix current default router is included
   unchanged, there should be no change in a PIO, then default router after the "I" flag
   in that PIO MUST be set. RA
   solicitation completes.  If the prefix current default router is included in an LPO, then
   the prefix MUST be placed in the first prefix field in still
   reachable, it will forward the LPO, packets.

5.2.8  DNA and
   the LPO "I" flag MUST be set.

5.1.7.1  Changing the LinkID Address Configuration

   [Editor's note: Nothing has changed in this section] When either a host
   moves to a new prefix is added to point of attachment, a link that is numerically
   smaller than all those previously advertised or potential exists for a change
   in the lifetime validity of the
   prefix its unicast and multicast addresses on that is currently being used as the LinkID falls below 1.5
   hours, a new LinkID is determined.
   network interface.  In order to ensure that there this section, host processing for address
   configuration is
   overlap between consecutive RAs on the link, 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 old LinkID must
   continue to be advertised DNA
   host MUST support optimistic Duplicate Address Detection for some time alongside
   autoconfiguring global unicast addresses.

5.2.8.2  DNA and the new LinkID.

   For Address Autoconfiguration State Machine

   When a link level event occurs on a network interface indicating that
   the purposes host has moved from one point of propagating information, attachment to another, it is assumed that after
   three advertisements of a change, all routers have been made aware of
   the change.

   If the instant
   possible 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 change in the new
   LinkID.

   1.5 hours after first sending an advertisement reachability of the addresses
   associated with that interface may occur.  Upon detection of such a new LinkID it
   is safe to consider the old LinkID gone
   link event and omit prior to sending the corresponding
   prefix from RAs if desired.

   Following RS initiating a DNA exchange, a
   DNA host MUST change the state of LinkID, addresses associated with the old LinkID MUST be included
   interface in RAs
   for the following 1.5 hours.

5.1.7.1.1  Non-Prefix LinkIDs

   Although this memo only discusses LinkIDs that way (address state designations follow RFC
   2461):

   o  Addresses in the "Preferred" state are prefixes, a future
   specification or ammendment may describe a mechanism moved to select a
   LinkID that is not a prefix.

   Information from the Learned Prefix Option is only stored "Optimistic"
      state, but the host defers sending out an NS to initiate Duplicate
      Address Detection.

   o  Addresses in
   DNAHostPrefixList, and 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 only used unnecessary for DNA purposes.  Because a
   length field is used, nodes that support optimistic Duplicate Address
      Detection.

   A host MUST keep track of which "Preferred" addresses are moved to
   the "Optimistic" state, so it is possible to carry any variable length
   identifier less than or equal know which addresses
   were in the "Preferred" state and which were in the "Optimistic"
   state prior to 128 bits 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 an LPO the "Preferred"
   state prior to switching to "Optimistic" and store it 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
   DNAHostPrefixList (Section 5.2.1).

   Following a change of LinkID, the old LinkID "Optimistic" state,
   it MUST be included in RAs
   in utilize such an LPO for address as the following 1.5 hours.

   Future specifications source address.  If the host
   currently has no unicast link local addresses, it MUST NOT treat construct one
   and put it into the information in an LPO as
   prefixes such "Optimistic" state and note this address as they would the prefixes found
   having been in a Prefix
   Information Option.  Future specifications MUST NOT assume the "Optimistic" state previously, but defer sending
   the NS to confirm.  Note that the
   entries in presence of a host's DNAHostPrefixList are actaul prefixes in use duplicate unicast
   link local address on the link.

5.1.8  Scheduling Fast Router Advertisements

   RAs may need link will not interfere with the ability of
   the link to be delayed route a unicast DNA RA from the router back to avoid collisions the host
   nor will it result in corruption of the case that there router's neighbor cache,
   because the TSLLA option is more than one router on a link.  The delay included in the RS and is calculated utilized by
   determining a ranking for the
   router for 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 RS, and
   multiplying RAs that by RASeparation.

   A Host Token is needed from it has moved to a new
   link, the RS host MUST immediately move all unicast global addresses to calculate
   the router's ranking.
   The first 64 bits of an SHA-1 hash of "Deprecated" state and configure new addresses using the source address of subnet
   prefixes obtained from the RS
   MUST be used as RA.  For all unicast link local addresses,
   the RS host token.

   A router's ranking is determined by taking the XOR of MUST initiate NS signaling for optimistic Duplicate Address
   Detection to confirm the RS Host
   Token and each uniqueness of the stored Router Tokens.  The results of these XOR
   operations are sorted lowest to highest.  The router corresponding to unicast link local
   addresses on the first entry in new link.

   If the sorted list is ranked zero, host determines from the second, one,
   and so on.

      Note: received RAs that it is has not necessary for a router moved to actually sort
   a new link (i.e. the whole
      list.  Each router just needs to determine its own position in link has not changed) and the
      sorted list.

   If Rank < FastRAThreshold, previous state of
   an address was "Optimistic", then the RA host MUST be scheduled for
   transmission in Rank * RASeparation milliseconds.  When send an NS to confirm
   that the router address is
   ranked as zero, unique on the resulting delay link.  This is zero, thus required because
   optimistic Duplicate Address Detection may not have completed on the RA SHOULD be
   sent immediately.
   previous point of attachment, so the host may not have confirmed
   address uniqueness.  If Rank >= FastRAThreshold, then the RA 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 be replaced with a
   Complete RA, forgo sending an NS to confirm uniqueness 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
   value of the
   configured prefixes, but MUST include DNASameLinkDAD flag is False.  If, however, the LinkID.

   This ensures that there will be overlap in
   DNASameLinkDAD flag is True, the sets of prefixes
   contained in consecutive RAs host MUST perform optimistic
   duplicate address detection on a its unicast link from local and unicast
   global addresses to determine address uniqueness.

5.2.8.3  DNA routers, and thus an
   absence of that overlap can be used Statefully Configured Addresses

   The DHCPv6 specification [16] requires hosts to infer link change.

5.1.10  Removing a Prefix from an Interface

   When send a prefix is to stop being advertised in DHCPv6 CONFIRM
   message when a PIO change in RAs by an
   interface before the expiry point of attachment is detected.  Since the prefix's valid lifetime, then
   DNA protocol provides the
   router should treat it same level of movement detection as though the
   DHCPv6 CONFIRM, it has just learned a prefix that is RECOMMENDED that DNA hosts not explicitly configured on it.  After sending the last RA
   containing utilize the prefix in
   DHCPv6 CONFIRM message when a PIO, the router MUST add the prefix to the
   DNARouterPrefixList and set it DNA RA is received, to expire in 1.5 hours or at avoid excessive
   signaling.  If, however, a non-DNA RA is received, the
   expiry of host SHOULD
   use the last advertised valid lifetime, whichever is earlier.

   This ensures that DHCPv6 CONFIRM message as described in RFC 3315 [16] rather
   than wait for additional RAs to hosts there perform CPL, since this will be overlap in the prefixes in reduce
   the RAs they see and prevent them from incorrectly interpreting
   changed prefixes as movement.

5.1.10.1  Early Removal amount of time required for the LinkID Prefix host to confirm whether or not it
   has moved to a new link.  If the LinkID prefix is CONFIRM message validates the
   addresses, the host can continue to be withdrawn early from use them.

   When a link, that DNA RA is
   before received and 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 received RA indicates that all of the other routers are
   notified host
   has not moved to begin a new link, the process of changing host SHOULD apply the LinkID as well, and
   hosts will always see overlap between same rules to
   interpreting the prefixes 'M' flag in consecutive RAs the received RA and thus not mistake any subsequently
   received RAs as in Section 5.5.3 of RFC 2461 [3].  That is, if 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 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 a link without counting
   down
   True to False, the expiry host should continue to run DHCPv6.  If, however,
   the value of its valid lifetime, the ManagedFlag remains the same both before and after
   the change in point of attachment on the same link has been
   confirmed, it SHOULD is NOT RECOMMENDED that the host run DHCPv6 to obtain
   new addresses, since the old addresses will continue to be reassigned valid.

   If the DNA RA indicates that the host has moved to another a new link for at least 1.5 hours or until the original expiry
   time, whichever is earlier.  This gives sufficient time for other
   routers
   DHCPv6 CONFIRM indicates that have learned the prefix addresses are invalid, the host
   MUST move its old addresses to expire it, the "Deprecated" state and for hosts that
   have seen advertisements from those routers MUST run
   DHCPv6 to expire obtain new addresses.  Normally, the prefix DHCPv6 operation is
   4-message exchange, however, this exchange allows for redundancy
   (multiple DHCPv6 servers) without wasting addresses, as
   well.

   Earlier reassignment may result in hosts that move from between addresses are
   only provisionally assigned to a host until the
   old host chooses and new links failing
   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 detect shorten the movement.

5.2 exchange from 4 messages
   to 2 messages.

5.2.8.4  Packet Delivery During DNA Host Operation

   Hosts collect information about

   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 prefixes mobility management protocols (if any) available on to the host's
   stack.

5.2.8.5  Multicast Address Configuration

   Multicast routers on a link to are aware of which they groups are connected to facilitate change detection.

5.2.1  Data Structures

   Hosts MUST maintain in use
   within a list of prefixes advertised on the link.  This information is separate from the RFC 2461 "Prefix List" and will be referred used to
   here as the "DNAHostPrefixList".  All prefixes SHOULD be stored,
   however an upper bound MUST be placed on the number stored undertake initiation of
   multicast routing for off-link multicast sources to prevent
   overflow.  For each prefix stored the host MUST store the following
   information:

   1.  Prefix

   2.  Prefix length
   3.  Expiry time link [9][17].

   If a host is not able to store this information for every prefix,
   there is a risk the returning RAs indicate that the host will incorrectly decide that it has not moved to a new
   link, when it receives advertisements from a non-DNA
   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 no further action is required for multicast addresses to which
   the valid lifetime of host has subscribed using MLD Report [17].  In particular, the prefix, whichever is earlier.

   Hosts
   host MUST also maintain a list of all LinkIDs seen on the current
   Link.  This list will be referred NOT perform MLD signaling for any multicast addresses
   unless such signaling was not performed prior to as "DNAHostLinkIDList".  This
   list movement to the new
   point of attachment.  For example, if an address is identical in structure put into the
   "Optimistic" state prior to DNAHostPrefixList but contains
   LinkIDs instead of prefixes.

   At this time LinkIDs are also prefixes movement but in future may be able to
   be identifiers other than prefixes.  A list the MLD Report for the
   Solicited_Node_Multicast_Address is stored rather than a
   single entry not sent prior to allow for changes in movement to a
   new point of attachment, the LinkID used host MUST send the MLD Report on a link.

   Entries are expired from DNAHostLinkIDList in the same way as
   DNAHostPrefixList.

   Hosts new
   point of attachment prior to performing optimistic Duplicate Address
   Detection.  The host SHOULD also maintain a "Landmark Prefix" as described in
   Section 5.2.3.

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 procedure described below for
   sending an MLD Report.

   If, on the other hand, the DNA RA indicates that link change the host has not occurred.

      Default: False

5.2.3  Selection of a Landmark Prefix

   For each interface, hosts SHOULD choose a prefix moved
   to use as a Landmark
   Prefix in Router Solicitations.  The following rules are used in
   selecting new link, the landmark prefix:

      The prefix host MUST have a non-zero valid lifetime.  If the valid
      lifetime of a previously selected Landmark Prefix expires, issue a new
      Landmark Prefix MUST be selected.

      The prefix MLD Report to the router for
   subscribed multicast addresses.  MLD signaling for the
   Solicited_Node_Multicast_Addresses [7] MUST be one of those that the hosts has used sent prior to assign
      a non-link-local
   performing signaling for optimistic DAD.

   To avoid lengthy delays in address to itself

      The prefix SHOULD be chosen as the one with the longest preferred
      lifetime, but reconfiguration, it is not necessary to switch to different prefix if RECOMMENDED
   that the preferred lifetime of host send the current landmark prefix changes.

5.2.4  Sending Router Solicitations

   Upon MLD Report for newly configured addresses
   immediately, as soon as the occurrence of a Layer 2 link-up event notification, hosts
   SHOULD send addresses have been constructed, rather
   than waiting for a Router Solicitation. random backoff.

   Hosts SHOULD apply rate limiting
   and/or hysteresis to this behaviour as appropriate to the link
   technology subject to MUST defer MLD signaling until after the reliability results of the hints.

   Hosts SHOULD include DNA have
   confirmed whether or not a Landmark Option (LO) 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 RS message with issues section of CPL.  If we keep this, the landmark prefix chosen based on section should be
   generalised to make it applicable to the rules whole DNAv6, right now its
   specific to CPL only ]

   If the host implementation does not provide any link-layer event
   notifications [20], and in Section 5.2.3.

   Hosts SHOULD include particular, a tentative source link layer address option
   (TSLLAO) in UP notification, the RS message [7].  The router solicitation message is
   sent
   host needs additional logic to try to decide whether a received RA
   applies to the All_Routers_Multicast address and "old" link or a "new" link.

   In this case there is an increased risk that the source address MUST host get confused,
   thus it isn't clear whether this should be the link local address part of the host.
   recommendation, or whether we should just require that hosts which
   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 MUST consider its link local address begins to be in collect the
   "Optimistic" state for duplicate address detection [6] until either prefixes on a
   link.  But before the returned RA confirms that prefix list generation is completed, without
   its knowledge, the host has not switched moves to a new link
   or, if an link change has occurred, the host has performed optimistic
   duplicate address detection for link.  Unaware that now it is
   at the address.

5.2.5  Processing Router Advertisements

   When different link, the host receives a Router Advertisement, keeps collecting prefixes from the host checks for
   received RAs to generate the conditions and derives prefix list.  This results in the associated conclusions given below: prefix
   list containing prefixes from two different links.  If the RA contains host uses
   this prefix list, it fails to detect a Landmark Option with the "Y" flag set that
      matches the Landmark Option in the last transmitted Router
      Solicitation, then that indicates that no link change has occurred
      and current configuration can be assumed change.

   A possible way to still be current.

      If the RA includes any prefixes in either a PIO or LPO that
      matches prevent this situation for implementations without
   a prefix in DNAHostPrefixList then the host can conclude
      that no link change has occurred and current configuration can be
      assumed UP notification, is to still be current.

      If treat the arrival of a RA includes with 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
   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 Complete
   new Candidate Link object with the information extracted from that
   RA, and then send an RS as indicated by the "Complete" flag specified in
      the RA header, and Section 5.2.6.

   However, there are no prefixes included in it in either is still a PIO or LPO that are also in the hosts DNAHostPrefixList, then risk for confusion because the host can conclude that it has changed link and SHOULD initiate
      re-configuration using the information in not
   tell from the received Router
      Advertisement.

      If RAs whether they were solicited by the RA is not a CompleteRA, but includes a LinkID host.  (RFC 2461
   recommends that solicited RAs be multicast.)  The danger is not
      in DNAHostLinkIDList and no prefixes that match entries in
      DNAHostPrefixList, then
   exemplified by this:

   1.  Assume the host can conclude that it has changed
      link a DNAHostPrefixList with prefixes P1 and SHOULD initiate re-configuration using the information in
      the received Router Advertisement.

      If the received RA P2.

   2.  The host changes link layer attachment, but there is not complete, contains no prefixes that are
      stored in DNAHostPrefixList, does not contain a Landmark Option
      that matches link UP
       notification.

   3.  The host receives an RA with a corresponding option in the most recent RS and
      contains no LinkID, then disjoint set of prefixes: prefix
       P3.  This causes the host SHOULD use CPL logic to decide
      whether or not to reconfigure as described in [15].

5.2.5.1  Maintaining the DNAHostPrefixList

   If a Router Advertisement does not indicate form 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 DNAHostPrefixList with P3
       and send an RS.

   4.  The host again changes link layer attachment, and no link UP
       notification.

   5.  The host SHOULD
   make the DNAHostPrefixList match the contents receives one of the advertisement.
   Any new prefixes are added and any prefixes in the list that are
   absent in the advertisement are removed.  Expiry times periodic multicast RAs on prefixes
   are updated if the link,
       which contains prefix was contained in a PIO, but P4.  It can not if it tell whether this RA was
   contained in an LPO.

   If
       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 does not have messages.
   However, the C flag set, then probability of this occurring can be limited by limiting
   the window of exposure.  The simplest approach is for the host SHOULD add any new prefixes and update expiry times as above,
   but SHOULD NOT remove to
   assume that any entries from DNAHostPrefixList.

   When initiating reconfiguration due RA received within MAX_RA_WAIT seconds after sending
   an RS was in response to link change, the host MUST
   remove all prefixes in RS.  Basically this relies on the DNAHostPrefixList small
   probability of both moving again in that MAX_RA_WAIT second interval,
   and repopulate it with receiving one of the prefixes in periodic RAs.  If the Prefix Information 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 and Learned Prefix
   Option, if any,

   Tentative Options may be sent in the RA.

5.2.5.2 Router Reachability Detection and Default Router Selection

   The receipt of Neighbour Solicitations,
   as described below.

   In a unicast RA from 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 router in response to node MUST NOT send a multicast
   RS indicates that the host has bi-directional reachability with Tentative Option in the
   routers that responded.  Such reachability same
   message where a Source Link-Layer Address Option is necessary for the host sent.

6.1.1  Sending Neighbour Solicitations with Tentative Options

   Neighbour Solicitations sent to use unicast addresses MAY contain a router as
   Tentative Option.

   Since delivery of a default router, in order packet to have packets routed
   off the host's current link.  If the a unicast destination address requires prior
   knowledge of the
   received RA is a unicast destination's hardware address, the host knows the router heard its
   RS, and therefore that the host has unicast Neighbour
   Solicitation packets may only be sent to destinations for which a
   neighbour cache entry already exists.

   For example, if checking bidirectional reachability with the router.

   Prior to sending a DNA RS in response router, it
   may be possible to an indication of link
   change, the host SHOULD set all Neighbor Cache entries for routers on
   its Default Router List send a Neighbour Solicitation with Tentative
   Option to STALE.  When the host receives an RA router's advertised address.

   As discussed in
   reply to [3], the RS, peer device may not have a cache entry even
   if the soliciting host SHOULD mark that router's Neighbor Cache
   Entry [3] as REACHABLE, 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 add Optimistic
   address MAY be sent with a Neighbor Cache Entry Tentative Option [5].

   An extension which allows Router Solicitations to be sent with a TO
   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
   REACHABLE state solicitation to create STALE neighbour
   cache entries if one does not currently exist.

   The host SHOULD also doesn't exist, but only 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 an entry if the information
   link-layer address in the RA to
   update the Default Route List entry with option matches the new information.  The
   host SHOULD add entries entry.

   Additionally, messages containing TO may be used to the Default Router List 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 routers
   returning RAs that are not on other received message, the list.  The host SHOULD confine
   selection presence of a router from the Default Router List to those routers
   whose Neighbor Cache entries are in the REACHABLE state.  Note option is silently
   ignored, that is, the Default Router List SHOULD be updated packet is processed as described here
   regardless of whether if the RA indicates option was not
   present.

   It is REQUIRED that the host has changed to a
   new IP link, since changes same validation algorithms for Neighbour and
   Router Solicitations received with TO as in router reachability are possible on
   some link types even if the host remains on IPv6 Neighbour
   Discovery specification [3], are used.

   In the same IP link.

   Note case that this procedure does not prevent a MN from sending packets 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 its current default router while believe that the host will remain tentative after receiving a
   responding advertisement.

   Tentative Options do not overwrite existing neighbour cache entries
   where the RA solicitation is in
   progress and if reachability with link-layer addresses of the current default router option and entry differ.

   If a solicitation from a unicast source address is
   unchanged, there should be received where no change in default router after
   difference exists between the RA
   solicitation completes.  If TO and an existing neighbour cache
   entry, the current default router is still
   reachable, option MUST be treated as if it will forward the packets.

5.2.6  DNA were an SLLAO after
   message validation, and Address Configuration

   When processed accordingly.

   In the case that a host moves cache entry is unable to a new point be created or updated due
   to existence of attachment, a potential exists
   for conflicting neighbour cache entry, it MUST NOT
   update the neighbour cache entry.

   An extension which allows a change in direct advertisement to the validity of its unicast and multicast addresses
   on that network interface.  In this section, soliciting
   host processing for
   address configuration without modifying the neighbour cache entry is specified. described in
   Appendix B.

6.2.1  Receiving Neighbour Solicitations containing Tentative Options

   The section considers Tentative Option is only [Editor's note: This only is not right?
   TO is allowed in both
   statelessly NS and statefully configured addresses.

5.2.6.1  Duplicate Address Detection

   A DNA host MUST support optimistic Duplicate Address Detection [6] RS? right?] allowed in Neighbour
   Solicitations with specified source addresses for autoconfiguring unicast link local addresses.  If which SLLAO is not
   required.

   A Neighbour Solicitation message received with a DNA host uses TO and an
   unspecified source address autoconfiguration [8] for global unicast addresses, the DNA
   host MUST support optimistic Duplicate Address Detection for
   autoconfiguring global unicast addresses.

5.2.6.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 be silently discarded.

   Upon reception of attachment to another, it is
   possible that a change Tentative Option in a Neighbour Solicitation for
   which the reachability of receiver has the addresses
   associated with that interface may occur.  Upon detection of such Target Address configured, a
   link event and prior node checks
   to sending the RS initiating a DNA exchange, see if there is a
   DNA host MUST change neighbour cache entry with conflicting link-
   layer address.

   If no such entry exists, the state neighbour cache of addresses associated with the
   interface 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 following way (address state designations follow RFC
   2461):

   o  Addresses node processes
   the solicitation as defined in Section 7.2.4 of [3], except that the "Preferred" state
   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 moved either sent to the "Optimistic"
      state, but the host defers sending out an NS all-nodes multicast address, or may be sent to initiate Duplicate
      Address Detection.

   o  Addresses in
   the "Optimistic" state remain solicitation's source address if it is a unicast address.

   Including a Tentative Option in the "Optimistic"
      state, but the host defers sending out an NS solicitation allows a router to
   choose to send a packet directly to initiate Duplicate
      Address Detection.

   o  Addresses in the "Deprecated" state remain in the "Deprecated"
      state.

   o  No addresses should be link-layer address even in the "Tentative" state, since
   situations where this state
      is unnecessary for nodes that support optimistic Duplicate Address
      Detection.

   A host MUST keep track of which "Preferred" addresses are moved to would not normally be possible.

   For Router Solicitations with unicast source addresses, neighbour
   caches SHOULD be updated with the "Optimistic" state, so it link-layer address from a Tentative
   Option if there is possible 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 know which addresses
   were
   that stored in the "Preferred" state and which were in neighbour cache, the "Optimistic"
   state prior to node processes the change
   solicitation as defined in point Section 6.2.6 of attachment.

   In order to perform the DNA transaction, [3], except that the DNA host SHOULD select
   one
   Neighbour Cache entry MUST NOT be modified.

7.  Initiation of the unicast link local addresses that was DNA Procedures

   Link change detection procedures defined in the "Preferred"
   state prior to switching to "Optimistic" document are
   initiated when "link UP" event notification.  This event indicates
   that network reachability or configuration is suspect and utilize is called a
   hint.  In this section, other possible hints that can imply that as the
   source address on the DNA RS.  If the host had no "Preferred" unicast
   link local address but did have an address
   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 the "Optimistic" state,
   it MUST utilize such an address a way as the source address.  If the host
   currently has no unicast link local addresses, it MUST construct one
   and put it into the "Optimistic" 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 note 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 address as
   having been aim, a host MAY implement
   hysteresis mechanisms such as token buckets, hint weighting or
   holddown timers in the "Optimistic" state previously, but defer sending
   the NS order to confirm.  Note that limit the presence effect of a duplicate unicast
   link local address on the link will not interfere with 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 ability authenticity
   of the link messages MUST be verified before expending resources to route a unicast
   initiate DNA RA 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 the router back untrusted sources are dangerous due to
   the host
   nor will it result in corruption threat of the router's neighbor cache,
   because the TSLLA option multicast response flooding.  This issue is included discussed
   further in Section 9.

   State changes within the RS and is utilized by the network-layer itself may initiate link-
   change detection procedures.  Existing subsystems for router on the RA frame without changing the and
   neighbor cache.

   When discovery, address leasing and multicast reception maintain
   their own timers and state variables.  Changes to the host receives unicast state of one or multicast RAs
   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
   are TCP retransmission timeout and completion of link-layer access
   procedures [20].

   While hints from other protocol layers originate from within the router, if
   host's own stack, the host determines 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 received RAs that host's own stack, such hints may
   actually be due to packet reception or non-reception events at the
   originating layers.  As such, it has moved may be possible for other devices to
   instigate hint delivery on a new
   link, the host MUST immediately move all unicast global addresses or multiple hosts deliberately, in
   order to
   the "Deprecated" prompt packet transmission, or configuration modification.

   Therefore, hosts SHOULD NOT change their configuration state and configure new addresses using the subnet
   prefixes obtained based on
   hints from the RA.  For all unicast link local addresses,
   the other protocol layers.  A host MUST initiate NS signaling for optimistic Duplicate Address
   Detection to confirm the uniqueness of the unicast MAY adopt an appropriate
   link local
   addresses on the new link.

   If the host determines change detection strategy based upon hints received from the other
   layers, with suitable caution and hysteresis.

7.3  Timer and Loss Based Hints

   Other hints may be received RAs that it has not moved due to
   a new link (i.e. the link has not changed) and timer expiry, particularly In some
   cases the previous state expiry of
   an address was "Optimistic", then the host MUST send an NS to confirm these timers may be a good hint that the address DNA
   procedures are necessary.

   Since DNA is unique on likely to be used when communicating with devices over
   wireless links, suitable resilience to packet loss SHOULD be
   incorporated into the link.  This is required because
   optimistic Duplicate Address Detection DNA initiation system.  Notably, non-reception
   of data associated with end-to-end communication over the Internet
   may not have completed 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
   previous point packet losses aren't
   caused by transient events.

   Use of attachment, so the host 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 not have confirmed
   address uniqueness.  If affect a number of devices
   simultaneously.

   For example, if a wireless base station goes down, all the previous state hosts on
   that base station are likely to initiate link-layer configuration
   strategies after losing track of an address was
   "Preferred", whether the last beacon or not pilot signal from
   the base station.

   As described in [3][10], a host initiates optimistic Duplicate
   Address Detection depends SHOULD delay randomly before acting
   on the configurable DNASameLinkDADFlag
   flag.  A host MUST forgo sending an NS a widely receivable advertisement, in order to confirm uniqueness if the
   value of the DNASameLinkDAD flag is False.  If, however, the
   DNASameLinkDAD flag is True, the avoid response
   implosion.

   Where a host MUST perform optimistic
   duplicate address detection considers it may be on its unicast a new link local and unicast
   global addresses 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 determine address uniqueness.

5.2.6.3  DNA and Statefully Configured Addresses

   The DHCPv6 specification [9] requires hosts a hint, regardless of which messages need to send 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 DHCPv6 CONFIRM
   message 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 change in point of attachment hint is detected.  Since received.

   These hosts SHOULD delay 0-1000ms before sending a solicitation, and
   MAY choose to wait up to twice the
   DNA protocol provides advertised Router Advertisement
   Interval (plus the same level random delay) before sending a solicitation [6].

   One benefit of movement detection as the
   DHCPv6 CONFIRM, it inactive hosts' deferral of DNA procedures is RECOMMENDED that DNA hosts not utilize the
   DHCPv6 CONFIRM message
   herd-like host configuration testing is mitigated when a base-station
   failure or simultaneous motion occur.  When latent hosts defer DNA RA
   tests, the number of devices actively probing for data simultaneously
   is received, reduced to avoid excessive
   signaling.  If, however, those hosts which currently support active data
   sessions.

   When a non-DNA RA is received, the host SHOULD
   use device begins sending packets, it will be necessary to test
   bidirectional reachability with the DHCPv6 CONFIRM message as router (whose current Neighbor
   Cache state is STALE).  As described in RFC 3315 [9] rather
   than wait for additional RAs to perform CPL, since this will reduce [3], the amount of time required host will delay
   before probing to allow for the host probability that upper layer packet
   reception confirms reachability.

8.  Complications to confirm whether Detecting Network Attachment

   Detection of network attachment procedures can be delayed or not it
   has moved may be
   incorrect due to a different factors.  This section gives some examples
   where complications may interfere with DNA processing.

8.1  Packet Loss

   Generally, packet loss introduces significant delays in validation of
   current configuration or discovery of new link.  If the CONFIRM message validates the
   addresses, configuration.  Because
   most of the host can continue protocols rely on timeout to use them.

   When 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 RA tests have higher chance of failure due to loss.  Hosts SHOULD
   attempt to verify tests through retransmission where packet loss is received
   prevalent.

8.2  Router Configurations

   Each router can have its own configuration with respect to sending
   RA, and the received RA indicates that 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
   has not moved 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 a discover the new link, link can then be longer than
   expected by the host.

8.3  Overlapping Coverage

   If a host SHOULD apply the same rules can be attached to
   interpreting the 'M' flag in different links at 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 same time with
   the 'M' flag set, then the 'M' flag value is copied
   into the ManagedFlag, and if same interface, the ManagedFlag changes 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 False one
   access network to
   True another.  If the host should run DHCPv6, but 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 ManagedFlag changes from
   True to False, link
   layer technology allows the host should continue MN to run DHCPv6.  If, however,
   the value be simultaneously attached to
   several points of the ManagedFlag remains the same both before attachment and after if the change in point coverage area of attachment on access
   points are overlapping.

   For the same link has been
   confirmed, purposes of DNA, it is NOT RECOMMENDED that the host run DHCPv6 to obtain
   new addresses, since the old addresses will continue necessary to treat each of these
   points-of-attachment separately, otherwise incorrect conclusions of
   link-change may be valid.

   If the DNA RA indicates that made even if another of the link-layer connections
   is valid.

8.4  Multicast Snooping

   When a host has moved to is participating in DNA on a new link or the
   DHCPv6 CONFIRM indicates that where multicast
   snooping is in use, multicast packets may not be delivered to the addresses are invalid,
   LAN-segment to which the host
   MUST move its old addresses 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 the "Deprecated" state and MUST run
   DHCPv6 send a Neighbor
   Solicitation to obtain new addresses.  Normally, the DHCPv6 operation host), its function will be degraded until after
   an MLD report is
   4-message exchange, however, this exchange allows sent.

   Where it is possible that multicast snooping is in operation, hosts
   MUST send MLD group joins (MLD reports) for redundancy
   (multiple DHCPv6 servers) without wasting addresses, as 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
   only provisionally assigned
   prevented due to topology changes or wireless propagation.

   When a host until the host chooses and
   requests one is on a link which partitions, only a subset of the provisionally assigned addresses.  If
   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 DNA 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 supports on the Rapid Commit Option [9], link could easily drain the host SHOULD use token bucket(s) of the
   Rapid Commit Option in order to shorten
   router(s) on the exchange from 4 link by continuously sending RS messages
   to 2 messages.

5.2.6.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
   link.  For example, if a host sends one RS message every
   UnicastRAInterval, and send a additional RS every third
   UnicastRAInterval, the host's
   stack.

5.2.6.5  Multicast Address Configuration

   If token bucket in the returning RAs indicate that router(s) on the host has 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 moved to clear
   whether arrival of such RS messages can be recognized by the router
   as a new
   link, no further action DoS attack.  This attack can also be mitigated by aggregating
   responses.  Since only one aggregation is required for multicast addresses possible in this interval
   due to which MIN_DELAY_BETWEEN_RAS restriction, the host has subscribed using MLD Report [10].  In particular, 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 MUST NOT perform MLD signaling for any multicast addresses
   unless to obtain trustworthy responses from
   routers, such signaling was not performed prior threats are relevant to movement DNAv6.  In order to the new
   point counter
   such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure
   router discovery.

9.3  Tentative options

   The use 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 Tentative Option in Neighbour and Router Solicitation
   messages acts in a similar manner to SLLAO, updating neighbour cache
   entries, in a
   new point of attachment, the host MUST send the MLD Report on the new
   point way which causes packet transmission.

   Particular care should be taken that transmission of attachment prior 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 performing optimistic Duplicate Address
   Detection.  The host SHOULD use the procedure described below for
   sending another node by an MLD Report.

   If,
   advertising node (a reflector), without creating any ongoing state on
   the other hand, the DNA RA indicates that reflector.

   This is attack requires one solicitation for each advertisement and
   the host advertisement has moved to a new link, the host MUST issue a new MLD Report go to a unicast MAC destination.  That said,
   the router for
   subscribed multicast addresses.  MLD signaling for size of the
   Solicited_Node_Multicast_Addresses [8] MUST advertisement may 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 significantly larger than waiting for a random backoff.

   Hosts MUST defer MLD signaling until after the results of DNA have
   confirmed whether
   solicitation, or not a link change has occurred.

6.  Backward Compatibility

6.1  Non-DNA Host with DNA Routers

   The RS message sent by non-DNA hosts will not contain any of the new
   options defined by this document.  The host will receive attacker and reflector may be on a Complete
   RA in response to medium with
   greater available bandwidth than the solicitation message and process it as per RFC
   2461.  This means that victim.

   For link-layers where it will drop the unrecognised Learned Prefix
   option, but process the included PIOs and non-DNA flags normally.

6.2  DNA Host with Non-DNA Routers

   The routers will behave based in isn't possible to spoof the recommendations link-layer
   source address this allows a slightly increased risk of RFC 2461 [3] 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 ignore the new options defined lall-nodes multicast.  SEND specifies guidelines to hosts
   receiving unsolicited advertisements in order to mitigate such
   attacks [4].

   While this memo.  Hosts will receive
   RA message without is the FastRA flag in same effect as experienced when accepting SLLAO
   from non-SEND nodes, the RA header set and will
   fallback lack of created neighbour cache entries on CPL for link identification.  Obviously,
   the objective advertiser may make such attacks more difficult to trace.

   Modification of
   receiving fast response for RS message can not be achieved.

   This case can occur on a link with no DNA routers or Neighbour Discovery messages on the network is
   possible, unless SEND is used. [4] provides a link protocol specification
   in which soliciting nodes sign ND messages with a
   mix of private key and use
   addresses generated from this key.

   Even if SEND is used, the two.  In 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 latter, usually original transmitters of these solicitation
   messages may occur.

   SEND defines use of Timestamp values to protect a response device from attack
   through replay of previously sent messages.  Although this applies to
   Neighbour and Router Solicitation messages, granularity of the DNA
   router(s) will
   timestamp allows the messages to be received first used for up to five minutes [4].

   All Router and CPL will just 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 the
   non-DNA Router Advertisement unknown delegation, or routers whose credentials need to be
   checked [12].  Where a host wishes to configure an unsecured router,
   it SHOULD confirm that no movement has taken
   place since the previous DNA advertisement.

7.  Security Considerations

7.1  Attacks on bidirectional reachability with the Token Bucket

   A host on device, and it
   MUST mark the link could easily drain 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 token bucket(s) router
   unsuitable.  Since secured routers' advertisement services may be
   subject to attack, alternative (secured) reachability mechanisms from
   upper layers, or secured reachability of the
   router(s) other devices known to be on
   the same link by continuously sending RS messages on may be used to check reachability in the
   link.  For example, if first
   instance.

9.5  Addressing

   While a DNA host sends one RS message every
   UnicastRAInterval, is checking for link-change, and send observing DAD, it
   may receive a additional RS every third
   UnicastRAInterval, DAD defense NA from an unsecured source.

   SEND says that DAD defenses MAY be accepted even from non SEND nodes
   for the token bucket first configured address [4].

   While deconfiguring the address is a valid action in the router(s) 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 will
   drain
   change to network attachment detection systems.  Two examples of such
   events are TCP retransmission timeout and completion of link-layer
   access procedures [20].

   While hints from other protocol layers originate from within MaxUnicastRABurst * UnicastRAInterval * 3 time-units.
   For the recommended values
   host's own stack, the network layer SHOULD NOT treat hints from other
   protocol layers as authoritative indications of UnicastRAInterval and
   MaxUnicastRABurst, this value is 3000 milliseconds.  It link change.

   This is not clear
   whether arrival of such RS messages can because state changes within other protocol layers may be recognized
   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 router
   as a DoS attack.  This attack can also host's own stack, such hints may
   actually be mitigated by aggregating
   responses.  Since only one aggregation is possible in this interval due to MIN_DELAY_BETWEEN_RAS restriction, packet reception or non-reception events at the routers
   originating layers.  As such, it may not be able
   protect the tokens in the bucket.

7.2  Attacks possible for other devices to
   instigate hint delivery 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 or multiple hosts deliberately, in
   order to counter
   such threats, DNAv6 prompt packet transmission, or configuration modification.

   Therefore, hosts SHOULD support RFC 3971 (SEND) secure
   router discovery.

8. 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 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.  Open issues

   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 4.3; 5.2.7.

12.  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

   2. JinHyeock
   Choi was used as the base for the merger.  The Learned Prefix option, draft-ietf-dna-cpl-02
   authored by JinHyeock Choi and Erik Normark provided the idea/text
   for the complete prefix list mechanism described in Section 4.4.

9. 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.

13.  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.

   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 this document. 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.

10.

14.  References

10.1

14.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]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

   [5]  Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, "SEcure
        Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
        (work in progress), July 2004.

   [6] RFC 3971, March 2005.

   [5]  Moore, N., "Optimistic Duplicate Address Detection (DAD) for
        IPv6",
        draft-ietf-ipv6-optimistic-dad-05 (work in progress),
        February 2005.

   [7]  Daley, G., "Tentative Source Link-Layer Address Options for IPv6
        Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work RFC 4429, April 2006.

14.2  Informative References

   [6]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        progress),
         IPv6", RFC 3775, June 2004.

10.2  Informative References

   [8]

   [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.

   [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.

   [10]

   [17]  Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", RFC 3810, June 2004.

   [11]

   [18]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.

   [19]  Choi, J., "Detecting Network Attachment in IPv6 Goals",
         draft-ietf-dna-goals-04 (work in progress), December 2004.

   [12]  Narayanan, S., Daley, G., JH. and N. Montavont, "Detecting G. Daley, "Goals of Detecting Network Attachment
         in IPv6 - Best Current Practices",
         draft-narayanan-dna-bcp-00 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), June September 2004.

   [13]

   [21]  Yamamoto, S., "Detecting Network Attachment Terminology",
         draft-yamamoto-dna-term-00 (work in progress), February 2004.

   [14]

   [22]  Manner, J. and M. Kojo, "Mobility Related Terminology",
         draft-ietf-seamoby-mobility-terminology-06 (work in progress),
         February 2004.

   [15]

   [23]  Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
         list based approach", draft-ietf-dna-cpl-00 (work in progress),
         April 2005.

   [16]  Pentland, B., "An Overview of Approaches to Detecting Network
         Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
         progress), February 2005.

Authors' Addresses

   James Kempf
   DoCoMo Communications Labs USA
   USA

   Phone:
   Email: kempf@docomolabs-usa.com

   Sathya Narayanan (editor)
   Panasonic Digital Networking Lab Princeton Laboratory
   Two Research Way, 3rd Floor
   Princeton, NJ  08536  08540
   USA

   Phone: +1 609 734 7599
   Email: sathya@Research.Panasonic.COM
   URI:

   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 (editor)
   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

   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 [11] [19] contains a list of goals identified by G1
   to G10.  This is also enumerated in the solutions discussion document
   [16] generated by the DNA design team.  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.

   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.

   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.

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.