[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
DNA Working Group                                           S. Narayanan
Internet-Draft                                                 Panasonic
Expires: December 21, 2004                                      G. Daley
                                                  Monash University CTIE
                                                            N. Montavont
                                                             LSIIT - ULP
                                                           June 22, 2004


     Detecting Network Attachment in IPv6 - Best Current Practices
                     draft-narayanan-dna-bcp-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 21, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Hosts experiencing rapid link-layer changes may require further
   configuration change detection procedures than more traditional fixed
   hosts.  Detecting Network Attachment is a set of strategies for
   determining configuration validity in wireless or rapidly changing
   environments.  This document details best current practice for
   Detecting Network Attachment in IPv6 hosts using Neighbor Discovery



Narayanan, et al.      Expires December 21, 2004                [Page 1]


Internet-Draft                 DNAv6 BCP                       June 2004


   procedures.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Structure of this Document . . . . . . . . . . . . . . . .  4

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

   3.  Background & Motivation for DNA  . . . . . . . . . . . . . . .  5

   4.  Current Practice for Hosts Supporting DNA  . . . . . . . . . .  6
     4.1   IP configurations relevant to DNA  . . . . . . . . . . . .  6
       4.1.1   Router and Prefix Discovery  . . . . . . . . . . . . .  6
       4.1.2   Address Configuration  . . . . . . . . . . . . . . . .  7
       4.1.3   Neighbor Caches  . . . . . . . . . . . . . . . . . . .  8
       4.1.4   Multicast Listener State . . . . . . . . . . . . . . . 10
       4.1.5   Mobility Management  . . . . . . . . . . . . . . . . . 10
       4.1.6   Other Configuration  . . . . . . . . . . . . . . . . . 11
     4.2   Validation using Neighbor Discovery  . . . . . . . . . . . 11
     4.3   Further Procedures on Detection of Network Attachment  . . 12

   5.  Detecting Network Attachment Steps . . . . . . . . . . . . . . 12
     5.1   Validity of configuration  . . . . . . . . . . . . . . . . 12
     5.2   Reachability detection . . . . . . . . . . . . . . . . . . 13

   6.  Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 15
     6.1   Hint Reception and Processing  . . . . . . . . . . . . . . 17
     6.2   Handling Hints from Other Layers . . . . . . . . . . . . . 17
     6.3   Timer Based Hints  . . . . . . . . . . . . . . . . . . . . 17
     6.4   Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 18
     6.5   Hint Validity and Hysteresis . . . . . . . . . . . . . . . 19
     6.6   Hint Management for Inactive Hosts . . . . . . . . . . . . 19

   7.  Validation of configuration  . . . . . . . . . . . . . . . . . 20
     7.1   Making use of Prior Information  . . . . . . . . . . . . . 20
     7.2   Transient Link Availability  . . . . . . . . . . . . . . . 21
     7.3   Link Change and Router Discovery . . . . . . . . . . . . . 21
     7.4   Validating configuration in Constrained Topologies . . . . 22
     7.5   Validating configuration in Arbitrary Topologies . . . . . 23
     7.6   Dealing with Incomplete Information  . . . . . . . . . . . 23
     7.7   Configuration Algorithms . . . . . . . . . . . . . . . . . 24

   8.  Reachability Detection . . . . . . . . . . . . . . . . . . . . 27
     8.1   Wireless propagation . . . . . . . . . . . . . . . . . . . 28
     8.2   Asymmetric Reachability  . . . . . . . . . . . . . . . . . 28
     8.3   Specific (Neighbor Solicitation) Tests . . . . . . . . . . 28
     8.4   Non-Specific (Router Solicitation) Tests . . . . . . . . . 29



Narayanan, et al.      Expires December 21, 2004                [Page 2]


Internet-Draft                 DNAv6 BCP                       June 2004


     8.5   Trade-offs in Reachability Testing . . . . . . . . . . . . 29

   9.  Complications to Detecting Network Attachment  . . . . . . . . 30
     9.1   Tentative Addressing . . . . . . . . . . . . . . . . . . . 30
     9.2   Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 31
     9.3   Router Configurations  . . . . . . . . . . . . . . . . . . 31
     9.4   Overlapping Coverage . . . . . . . . . . . . . . . . . . . 31
     9.5   Multicast Snooping . . . . . . . . . . . . . . . . . . . . 32

   10.   Current Practice for Routers supporting DNA  . . . . . . . . 32
     10.1  Router Advertisement Intervals . . . . . . . . . . . . . . 32
     10.2  Unicast Response Transmission  . . . . . . . . . . . . . . 34
     10.3  Point-to-Point Links . . . . . . . . . . . . . . . . . . . 34
     10.4  Prefix Advertisement . . . . . . . . . . . . . . . . . . . 34
     10.5  Secured Neighbor Discovery . . . . . . . . . . . . . . . . 35

   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 35
     11.1  Replay or impersonation of messages. . . . . . . . . . . . 35
     11.2  Authorization and Detecting Network Attachment . . . . . . 36
     11.3  Addressing . . . . . . . . . . . . . . . . . . . . . . . . 36

   12.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 37

   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 37
   13.1  Normative References . . . . . . . . . . . . . . . . . . . . 37
   13.2  Informative References . . . . . . . . . . . . . . . . . . . 38

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39

   A.  Summary of Recommendations . . . . . . . . . . . . . . . . . . 40

   B.  Example State Transition Diagram . . . . . . . . . . . . . . . 43

   C.  DNA With Fast Handovers for Mobile IPv6  . . . . . . . . . . . 43

   D.  DNA with Candidate Access Router Discovery . . . . . . . . . . 43

       Intellectual Property and Copyright Statements . . . . . . . . 44













Narayanan, et al.      Expires December 21, 2004                [Page 3]


Internet-Draft                 DNAv6 BCP                       June 2004


1.  Introduction

   When operating in changing environments, IPv6 hosts may experience
   variations in reachability or configuration state over time.  For
   hosts accessing the Internet over wireless media, such changes may be
   caused by changes in wireless propagation or host motion.

   Detecting Network Attachment (DNA) in IPv6 is the task of checking
   for changes in the validity of a host's IP configuration.  Changes
   may occur on establishment or disconnection of a link-layer.  For
   newly connected interfaces, they may be on a different link to the
   existing configuration's routers.

   In these and other cases, IP addressing and default routing
   configuration may be invalid, which prevents packet transfer.

   DNA focuses on determining whether the current configuration is
   invalid, leaving the actual practice of re-configuration to other
   subsystems.

   This document presents the best current practices for IPv6 hosts to
   address the task of Detecting Network Attachment in changing and
   wireless environments.

1.1  Structure of this Document

   Section 3 of this document provides a background and motivation for
   Detecting Network Attachment.  Section 4 provides an overview of DNA
   practices for hosts, and their place within the change detection and
   configuration cycle.

   Elaboration of specific practices for hosts continues in Section 5,
   Section 6, Section 7, and Section 8.  These sections describe how to
   safely determine network attachment with minimal signaling, across a
   range of environments.

   Topological and host-based challenges which govern the operation of
   DNA procedures are detailed in Section 9.

   Router based configurations which assist hosts' ability to detect
   network attachment are described in Section 10.

   Section 11 Provides security considerations, and details a number of
   issues which arise due to wireless connectivity and the changeable
   nature of DNA hosts' internet connections.

   This document has a number of appendixes.




Narayanan, et al.      Expires December 21, 2004                [Page 4]


Internet-Draft                 DNAv6 BCP                       June 2004


   Appendix A lists the recommendations for systems wishing to support
   Best Current Practice.  Appendix B provides an example state machine
   for DNA describing knowledge and belief based on the prior listed
   recommendations.  The final two (Appendix C and Appendix D) look at
   existing experimental protocols that may be used to provide DNA
   processes with access network information before arrival on a new
   link.

2.  Terms and Abbreviations

   There is an existing DNA terminology draft [20].  At this stage, it
   is unclear if this draft or the mobility terminology [21] draft need
   to be referenced, or specific terms need to be placed in this
   document.

   While the mobility terminology draft may be applicable, the focus of
   this draft upon mobile hosts may be distracting for DNA.  Comments on
   this issue are welcome.

3.  Background & Motivation for DNA

   Hosts on the Internet may be connected by various media.  It has
   become common that hosts have access through wireless media or are
   mobile, and have a variety of interfaces, which may be used to
   provide internet connectivity.  The frequency of configuration change
   for wireless and nomadic devices are elevated, due to the vagaries of
   wireless propagation or the motion of the hosts themselves.
   Detecting Network Attachment is a strategy to assist such rapid
   configuration changes by determining when they are required, or not.

   While DNA has applicability to wireless and wireline access networks,
   these two sets of networks bring different sets of requirements to
   the problem.

   Verifying the validity of current IP configuration is needed when
   either a wireless or wireline link-layer is in use.  Conversely,
   wireless hosts are more likely to change their link-layer
   connections.

   Due to these frequent link-layer changes, an IP configuration change
   detection mechanism for DNA needs to be efficient and rapid.

   Making such detection procedures rapid helps to avoid unnecessary
   configuration delays upon link-change.

   For wireless devices, there will typically be a trade-off between
   configuration delays and the energy or bandwidth required to transmit
   for configuration validity tests or re-configuration.  DNA seeks to



Narayanan, et al.      Expires December 21, 2004                [Page 5]


Internet-Draft                 DNAv6 BCP                       June 2004


   assist hosts by providing information about network state, which may
   allow hosts to appropriately make decisions regarding such tradeoffs.

   Even though DNA is restricted to determining whether change is
   needed, the process of obtaining information for the new
   configuration may occur simultaneously with the detection to improve
   the efficiency of these two steps.

4.  Current Practice for Hosts Supporting DNA

   Various protocols within IPv6 provide their own configuration
   processes.  While Detecting Network Attachment seeks to provide
   efficient change detection without undertaking configuration, it is
   necessary to describe these protocols and their relationship to each
   other.

   Each of the protocols has a role to play in configuration of hosts,
   but many maintain their own change discovery mechanisms.  In rapidly
   changing and wireless environments it is necessary to rationalize the
   discovery techniques on a minimal subset of procedures and messages,
   sufficient to determine change validity and authorization.

   This section aims to allow appropriate background for discussing the
   best existing procedures for use in Detecting Network Attachment.

   The following discussion describes how these discovery processes
   interrelate, and indicates how IPv6 Neighbor Discovery can be used
   not only to detect link-change, but assist in determining
   requirements for other configuration.

4.1  IP configurations relevant to DNA

   Each of the following subsystems is described in terms of the
   configuration detection or change detection mechanisms which they
   support, the reliance of the service on other configuration and a
   summary of the relevant configuration procedures undertaken upon
   change discovery.

   Indications are provided as to their performance and applicability to
   DNA.

   This discussion continues in Section 4.2.

4.1.1  Router and Prefix Discovery

   Router Discovery is designed to provide hosts with a set of locally
   configurable prefixes and default routers.  These may then be
   configured by hosts for access to the Internet [1].



Narayanan, et al.      Expires December 21, 2004                [Page 6]


Internet-Draft                 DNAv6 BCP                       June 2004


   It allows hosts to discover routers and manage lists of eligible next
   hop gateways, and is based on IPv6 Neighbor Discovery.  When one of
   the routers in the router list is determined to be no longer
   reachable, its destination cache entry is removed, and new router is
   selected from the list.

   As indicated below in Section 4.1.3, router reachability is
   principally managed through the validity of the neighbor cache entry
   and the advertised ValidLifetime of the router.  Before the router is
   actively used, though, a router advertisement can place a router into
   the default router list for 30 days after being received [1].

   Clearly, if router reachability is to be used for the purposes of
   link change detection in volatile environments, practical and fast
   means for determining reachability and unreachability need to be used
   (see Section 8).

   As described in Section 6, detection of network attachment may be
   initiated by such events as missed Router Advertisements (see Section
   4.1.5) or lack of expected response packets passing through a router.
   If the currently configured router is unreachable, it is quite likely
   that other devices on the same link are no longer reachable.

   On determining that link-change has occurred, the default router list
   SHOULD have entries removed which are related to unreachable routers,
   and consequently these routers' destination cache entries SHOULD be
   removed [1].  If no eligible default routers are in the default
   router list, Router Solicitations may be sent, in order to discover
   new routers.

4.1.2  Address Configuration

   Unicast addresses are required to send all packets on the Internet,
   except a restricted subset of local signaling such as router and
   neighbor solicitations.

   Reception of packets at a global address, which have been received
   from off-link are likely to be an indication of router reachability.
   On broadcast media where packets interpreted by all nodes though, a
   host may receive incorrectly believe it has a valid address if it
   arrives on a link where the packets from this data stream are in
   transit.  This may happen for example if there is no unique
   link-layer addressing in a network.

   In such cases, hosts MUST NOT assume that they are receiving packets
   at a topologically correct address unless they can uniquely identify
   the last hop transmitter of the packets as a configured router.




Narayanan, et al.      Expires December 21, 2004                [Page 7]


Internet-Draft                 DNAv6 BCP                       June 2004


   As indicated below (in Section 4.1.3), where such information feeds
   into neighbor cache reachability state, even packets which don't pass
   through a router may indicate validity of an address, through
   indication that a set of neighbors is present (including appropriate
   routers).

   In dynamic environments, hosts need to undertake automatic
   configuration of addresses, and select which addresses to use based
   on prefix information advertised in Router Advertisements.  Such
   configurations may be based on either Stateless Address
   Autoconfiguration [3] or DHCPv6 [12].

   For any configured address, Duplicate Address Detection (DAD) MUST be
   performed [3].  DAD defines that an address is treated tentatively
   until either series of timeouts expire after probe transmissions or
   an address owner defends its address.  Tentative addresses cannot
   modify peers' neighbor cache entries, nor can they receive packets.

   Additionally, IPv6 requires configuration of link-local addresses
   which are to be used for signaling within a link.  Possession of a
   non-tentative link-local address allows transmission of all neighbor
   and router discovery messages, as well as unicast reception of
   configuration data.  It is notable that while Stateless Address
   Autoconfiguration needs only DAD, DHCPv6 relies upon having a
   non-tentative link-local address to send its messages.

   IPv6 routing assumes that IP subnets are available at a single
   location, for any particular global prefix [13].  When a host leaves
   a link, it therefore leaves its global prefix behind and cannot
   receive packets on the link using that address.  Link-local
   addresses, while being available on every link also may change if a
   link changes.  This is because the scope of the individual address's
   uniqueness is confined to a single link, and tests for uniqueness
   MUST be undertaken for each link upon which a host arrives.

   When undertaking DNA procedures, the host may suspect that it doesn't
   have valid configuration.  In this case, it SHOULD undertake
   Duplicate Address Detection (DAD) for the link-local address, or
   treat it as tentative until the host determines if its configuration
   is valid or not (or the DAD procedure completes).

   The motivations and implications for this practice are described in
   Section 9.1.

4.1.3  Neighbor Caches

   Neighbor caches allow for delivery of packets to peers on the same
   link.  Neighbor cache entries are created by router or neighbor



Narayanan, et al.      Expires December 21, 2004                [Page 8]


Internet-Draft                 DNAv6 BCP                       June 2004


   discovery signaling, and may be updated either by upper-layer
   reachability confirmations or explicit neighbor discovery exchanges.

   In order to determine which link-layer address a peer is at, nodes
   send solicitations to the link-local solicited-node multicast address
   of their peer.  If hosts are reachable on this address, then they
   will respond to the solicitation with a unicast response.

   This reliance on multicast packet delivery may mean that MLD
   (Multicast Listener Discovery) reporting needs to be completed before
   solicited-node's packet reception can occur (see Section 4.1.4), if
   multicast delivery within a link requires group signaling.

   By default, neighbor cache entries exist for at least 30 seconds
   after reachability confirmation, before becoming STALE.  They may
   exist for a number for any length of time in the STALE state until
   they are used, and then a Neighbor Unreachability Detection test is
   performed (taking up to 8 seconds).  After this, a neighbor cache
   entry is deleted.

   When link change occurs, the reachability of all existing neighbor
   cache entries is likely to be invalidated, if link change prevents
   packet reception from an old link.  For these links, the neighbor
   cache entries SHOULD be removed when a host moves to a new link
   (although it MAY be possible to keep keying and authorization
   information for such hosts cached on a least-recently-used basis
   [7]).

   For some wireless media, it may be possible to reach all the nodes on
   two different access networks simultaneously.  In this case, neighbor
   cache entries for a link entries MAY be removed when routers on the
   link are no-longer directly reachable.

   In both forms of networks, the reachability of the set of routers on
   a link is a good indicator for reachability to the rest of the link.
   Hosts communicating using a particular medium SHOULD be aware of the
   reachability conditions which prevail for a particular medium, and
   make decisions accordingly.

   Detecting that link change has occurred can be performed by actively
   probing reachability with neighboring nodes or routers.  (This is
   detailed in Section 8).

   Reachability of a single node may support the likelihood of reaching
   the rest of the link, for example if a particular access technology
   relays such messages through wireless base stations.

   Even for such networks, link partitions may still cause router



Narayanan, et al.      Expires December 21, 2004                [Page 9]


Internet-Draft                 DNAv6 BCP                       June 2004


   unreachability, and hosts SHOULD check for router unreachability in
   the case that they lack expected packet receptions through or from a
   router.

4.1.4  Multicast Listener State

   Multicast routers on a link are aware of which groups are in use
   within a link.  This information is used to undertake initiation of
   multicast routing for off-link multicast sources to the link [8][10].

   When a node arrives on a link, it may need to send Multicast Listener
   Discovery (MLD) reports, if the multicast stream is not already being
   received on the link.  If it is an MLDv2 node it SHOULD send state
   change reports upon arrival on a link [10].

   Since the identity of the link is tied to the presence and identity
   of routers, initiation of these procedures may be undertaken when DNA
   procedures have been completed.  In the absence of received data
   packets from a multicast stream, it is unlikely that a host will be
   able to determine if the multicast stream is being received on a new
   link, and will have to send state change reports, in addition to
   responses to periodic multicast queries [8][10].

   For link scoped multicast, reporting needs to be done to ensure that
   packet reception in the link is available due to multicast snoopers.
   Some interaction is possible when sending messages for the purpose of
   DNA on a network where multicast snooping is in use.  This issue is
   described in Section 9.5.

   While [8] specifies that routers may ignore messages from unspecified
   source addresses [9] indicates that for the benefit of snooping
   switches such messages MAY be transmitted.

   Since DNA procedures are likely to force link-local addresses to be
   tentative, this means MLD messages may need to be transmitted with
   unspecified source addresses while link-locals are tentative, in
   order to complete DNA.  This is discussed further in Section 9.5

4.1.5  Mobility Management

   Mobile IPv6 provides global mobility signaling for hosts wishing to
   preserve sessions when their configured address becomes topologically
   incorrect [5].  This system relies upon signaling messages and tunnel
   movement to provide reachability at a constant address, while
   directing packets to its visited network.

   [5] defines 'movement detection' procedures, which themselves rely
   upon Neighbor Discovery, to initiate mobility signaling.  These



Narayanan, et al.      Expires December 21, 2004               [Page 10]


Internet-Draft                 DNAv6 BCP                       June 2004


   procedures allow for some modification of Neighbor Discovery to
   enable faster change or movement detection.  While this document will
   reference parameters defined in [5], hosts are not required to
   undertake global mobility signaling or tunneling in order to benefit
   from detecting network attachment.

   Of benefit is an option which allows routers to advertise the
   regularity of their unsolicited advertisements.  This can be used to
   determine if multiple advertisements have been missed by a host.  In
   these circumstances, DNA procedures may be initiated as described in
   Section 6.

   After change detection occurs, a MIPv6 mobile node still needs to
   undertake global address configuration, and then mobility signaling
   as specified in [5].

4.1.6  Other Configuration

   When attempting to access the Internet, several other configuration
   services may be required, dependent on the requirements of the access
   networks.

   In this case, it is likely that configuration parameters can be
   passed to hosts using DHCPv6 [12].  The availability of such
   additional configuration information can be advertised using Router
   Advertisements [1].

   IPv6 Stateless Address Autoconfiguration [3] describes an
   OtherConfigFlag which is set when either the 'O' or the 'M' flags are
   set in the Router Advertisement header.  Hosts use the
   OtherConfigFlag to determine if they need to undertake further
   (non-addressing related) DHCPv6 procedures.

   If the Advertisement's 'O' flag was set, but not the 'M' flag, the
   host sends a DHCPv6 Information-Request message asking for such
   configuration.

   This signaling may occur after completion of DNA procedures.

4.2  Validation using Neighbor Discovery

   Most of the procedures required for detection of network attachment
   (router reachability, prefix validity) are provided in [1].

   Handling rapid change may require specific initiation and
   interpretation of message exchange procedures, but may be achieved
   without new messages or options.




Narayanan, et al.      Expires December 21, 2004               [Page 11]


Internet-Draft                 DNAv6 BCP                       June 2004


   Timing of messages and performance constraints will be described in
   this document, and explicit indications of practical differences
   between particular settings for these timers will be provided.

4.3  Further Procedures on Detection of Network Attachment

   Detection of network attachment does not define or prescribe
   configuration procedures.  The actual configuration is therefore left
   to the procedures which are invoked upon arrival on a new link.

   While DNA does not undertake configuration, it does learn about the
   state of the network using neighbor and router discovery.  Where it
   is safe to do so, such state SHOULD be made available to
   configuration processes.

   Particularly, state gained from change detection procedures SHOULD
   NOT be discarded, such that discovery processes need to be undertaken
   for each configuration protocol used.

5.  Detecting Network Attachment Steps

   Two different situations may lead a node to engage a network
   attachment detection procedure.  Either a node receives an indication
   that its link may have changed or it may detect that is configuration
   is not valid any more.

   If a host receives an indication (such as a link-layer hint) that its
   link may have changed, it has to verify the validity of its current
   configuration and confirm the reachability with its default router.
   If one of these two actions do not succeed, initiation of new
   configuration is required.

   If the host detects that its configuration is not valid any more, for
   example because a timer has expired, the node should engage in
   detection of its network attachment in order determine to what extent
   it needs to create a new configuration.

   While the initiation of the DNA procedures is described in the next
   section, the different steps involved in detecting network attachment
   are described below.  Once the DNA procedure is engaged, two major
   steps are to be done: check the validity of the current configuration
   and confirm the reachability with the default router.  Depending on
   the method used, these two steps could be performed independently or
   during the same procedure.

5.1  Validity of configuration

   When link change occurs, an IPv6 host is likely to have one or more



Narayanan, et al.      Expires December 21, 2004               [Page 12]


Internet-Draft                 DNAv6 BCP                       June 2004


   IPv6 configurations for the interface in its internal cache.  Upon
   initiation of DNA procedures (as specified in Section 6), the first
   step for the host would be to verify if any of these configurations
   is still valid.

   The validity of a host's configuration can be inferred by determining
   its presence on a particular link.  The host can verify presence on a
   particular link by learning the ranges of valid addresses and routers
   associated with that link and comparing this information with its
   cached configuration.  Learning the routers available on the link and
   the prefix supported by them can be done either passively by
   listening to the Router Advertisements (RA) periodically sent by
   routers, or actively by sending Router Solicitation (RS) [1].
   Otherwise, the host may send Neighbor Solicitation (NS) in order to
   check if its current default router is still reachable [1].

   Router Discovery is used initially to begin gathering a set of
   prefixes associated with a link, and determine the preference and
   authorization of default routers [1], [7].  Neighbor Solicitations in
   this case provide only a confirmation of reachability of a currently
   configured router, as detailed in Section 8.

   In addition to reachability information, routing authorization needs
   to be determined for each router.  In SEND [7], routing authorization
   is delegated by certification authorities.  Certificate authorities
   delegate a portion of their routing authority to the router, tying
   them to a public/private key-pair.  While SEND Router Advertisement
   packets contain the public key used to sign the message, the routing
   certificate is not present in that message.  Hosts need to test the
   router's authority to provide routing for the source addresses
   advertised in its Router Advertisement in order to ensure safe
   configuration.

   It might be noticed that the reception of a new Router Advertisement
   on a link does not necessarily mean that the current default prefix
   of a host is not valid anymore.  Several prefixes as well as several
   routers might be present on a link.  This leads to the fact that the
   non-presence of the current default router should be determined
   before considering that the link has changed.  This is even more
   important with mobile hosts, which update their localization
   according to their position in the Internet.  Considering that the
   current default router/prefix has changed upon the reception of a new
   IPv6 prefix may lead to excessive Binding Update transmission.
   Reachability detection is discussed in the next subsection.

5.2  Reachability detection

   Reachability information usually relies on timers associated with



Narayanan, et al.      Expires December 21, 2004               [Page 13]


Internet-Draft                 DNAv6 BCP                       June 2004


   received information.  Reachability detection can be triggered when a
   host has some indications that the link might have changed or when a
   timer is expired.  Reachability detection is very critical, since if
   the peer, e.g.  the current default router, is not reachable anymore,
   the host will have to change its IP configuration to be able to
   communicate.  As we will see, reachability detection can be very fast
   if the peer is still reachable.  However, when the peer is not
   reachable anymore, the unreachability detection relies on timeout
   after transmission of solicitations.  These timeouts introduce
   important delays.

   Presence of the current router can be validated by an unsolicited
   Router Advertisement (RA) received on the link.  To send RAs, a
   router uses three main timers : MaxRtrAdvInterval, MinRtrAdvInterval
   and MIN_DELAY_BETWEEN_RAS [1].  By default, MinRtrAdvinterval is 0.33
   times MaxRtrAdvInterval (i.e.  200 sec.  if MaxRtrAdvInterval is 600
   sec.).  A host can send a Router Solicitation if it detects that it
   didn't get an RA during 3 times MaxRtrAdvInterval.  So, if we
   consider default values, a host might wait for 30 minutes before
   sending an RS.  We can also notice that by default, the AR can not
   send a new multicast RA within 3 seconds after having sent one.  The
   reply of a RS must also be delayed for a random time between 0 and
   MaxRADelayTime (0.5 sec by default).  The specification of Mobile
   IPv6 [5] identified that these defaults are too long to support
   mobility of host and proposes to reduce the RA transmission between
   30 and 70ms and to allow a host to send a RS if it didn't receive a
   RA within the last second.

   Absence of RA from the current default router MAY require
   verification and acquisition of configuration using one of the active
   mechanisms listed below.  Non-presence will be detected either when
   RA from the router is not received for a period of time or by
   neighbor reachability test.  Three different possible message
   exchanges can be used to test reachability and actively learn about
   the on-link information and they are presented below.

   1.  Neighbor Discovery:

   The IP node sends NS message to the default router and waits for the
   NA from the router.  This mechanism is efficient if the current
   default router is still reachable : only a round trip time between
   the host and the router is needed to validate the configuration.
   This method will allow the node to find out whether the current
   configuration information is valid.  Conversely, if the default
   router is not available, the host will timeout without receiving a
   NA.  By default, the host can send three NS (one every second) before
   considering that the pair is not reachable.  However, if the host has
   indication that the link may have changed, this delay may be reduced



Narayanan, et al.      Expires December 21, 2004               [Page 14]


Internet-Draft                 DNAv6 BCP                       June 2004


   without significant damage for the network.  If the current router is
   considered unreachable (timeout on NS message), the host will have to
   execute router discovery procedure to obtain new configuration and
   reachability information.  The host will send a RS message to the
   All-Routers multicast address.  In summary, this method works well
   both when the current default router is available and when the
   current default router is not available.  When the current default
   router is not available though, the delay introduced in doing ND
   before switching RD could become a problem in deploying real time
   applications in wireless networks.  Reducing the timer associated
   with the unreachability testing through the exchange of NS/NA might
   be an issue.

   2.  Router Discovery:

   Send a RS message to the All-Routers multicast address.  A RA message
   in response to the RS will be received from one of the available
   routers on the link.  This method will lead to quick configuration of
   the interface because if the current default router is not
   accessible, new configuration information can be received from the
   responding router.  But, this can lead to erroneous re-configuration
   of the interface because a response from a new router doesn't
   necessarily mean that the current router is not accessible.  In
   RFC2461 [1], the node may have to wait for 3 times MAX_RA_DELAY_TIME
   to confirm that the current default router is not serving the default
   IPv6 prefix.  By considering the default values of RFC2461, 3 times
   MAX_RA_DELAY_TIME is 30 minutes, while with the values defined in
   MIPv6, this time is 1 second (due to the shorter Router Advertisement
   frequency).

   3.  Neighbor Discovery and Router Discovery in parallel:

   Send a NS to the current default router and a RS to the All-Routers
   multicast address in parallel.  If the response to the NS is received
   within the timeout period, any response to the RS can be ignored.  If
   no NA is received, the RA received in response to the RS will be used
   to configure the IP interface.  The method works well in both cases
   when the current router is still available and when not, and avoids
   the delay of exchanging RS and RA after the ND timeouts.  When the
   current default router is available, the RS and RA messages are
   unnecessarily transmitted, wasting network resources.

6.  Initiation of DNA Procedures

   Link change detection procedures are initiated when information is
   received either directly from the network or from other protocol
   layers within the host.  This information indicates that network
   reachability or configuration is suspect and is called a hint.



Narayanan, et al.      Expires December 21, 2004               [Page 15]


Internet-Draft                 DNAv6 BCP                       June 2004


   Hints MAY be used to update a wireless host's timers or probing
   behavior in such a way as to assist detection of network attachment.

   Hints SHOULD NOT be considered to be authoritative for detecting IP
   configuration change by themselves.

   In some cases, hints will carry significant information (for example
   a hint indicating PPP IPv6CP open state [4]), although details of the
   configuration parameters may be available only after other IP
   configuration procedures.  Implementers are encouraged to treat hints
   as though they may be incorrect, and require confirmation.

   The signaling which causes a hint may be due to network-layer
   messages such as unexpected Router Advertisements, multicast listener
   queries or ICMPv6 error messages [1][8][6].  In these cases, caution
   must be exerted.

   Hosts MUST ensure that untrusted messages do not cause unnecessary
   configuration changes, or significant consumption of host resources
   or bandwidth.

   In order to achieve this aim, a host MAY implement hysteresis
   mechanisms such as token buckets, hint weighting or holddown timers
   in order to limit the effect of excessive hints (see Section 6.5).

   Transport and Link-Layers may also provide hints, caused by state
   change in their own layer.  Two examples of such state change are TCP
   retransmission timeout and completion of link-layer access
   procedures.

   While hints from other protocol layers originate from within the
   host's own stack, the network layer SHOULD NOT treat hints from other
   protocol layers as authoritative indications of link change.

   This is because state changes within other protocol layers may be
   triggered by untrusted messages, come from compromised sources (for
   example 802.11 WEP Encryption [19]) or be inaccurate with regard to
   network-layer state.  In most cases, additional procedures such as
   those defined in Section 7.3 and Section 8 will be required to
   confirm changes in network layer configuration.

   State changes within the network-layer itself may initiate
   link-change detection procedures.  Existing subsystems for router and
   neighbor discovery, address leasing and multicast reception maintain
   their own timers and state variables.  Changes to the state of one or
   more of these mechanisms may hint that link change has occurred, and
   initiate detection of network attachment.




Narayanan, et al.      Expires December 21, 2004               [Page 16]


Internet-Draft                 DNAv6 BCP                       June 2004


6.1  Hint Reception and Processing

   Hints received due to external IP packets will typically be due to
   multicast messages, when a host has arrived on a new link.  A delay
   before receiving these messages is likely as in most cases intervals
   between All-Hosts multicast messages are tightly controlled [1][6].

   Regardless of this, actions based on multicast reception from
   untrusted sources are dangerous due to the threat of transmitter
   impersonation.  This issue is discussed further in Section 11.

6.2  Handling Hints from Other Layers

   Timeouts and state change at other protocol layers may provide hints
   of link change to detection of network attachment.  While the hints
   come from the host's own stack, the causes for such hints may be due
   to packet reception or non-reception events at the originating
   layers.

   As such, it may be possible for other devices to instigate hint
   delivery on a host or multiple hosts deliberately, in order to prompt
   packet transmission, or configuration modification.  This ability to
   create hints may even extend to the parameters supplied with a hint
   that give indications of the network's status.

   Therefore, hosts SHOULD NOT change their configuration state based on
   hints from other protocol layers.  A host MAY choose to adopt an
   appropriate link change detection strategy based upon hints received
   from other layers, with suitable caution and hysteresis, as described
   in Section 6.5.

6.3  Timer Based Hints

   When receiving messages from upper and lower layers, or when
   maintaining reachability information for routers or hosts, timers may
   expire due to non-reception of messages.  In some cases the expiry of
   these timers may be a good hint that DNA procedures are necessary.

   Hosts SHOULD NOT start DNA procedures simply because a data link is
   idle, in accordance with [1].  Hosts MAY act on hints associated with
   non-reception of expected signaling or data.

   Since DNA is likely to be used when communicating with devices over
   wireless links, suitable resilience to packet loss SHOULD be
   incorporated into either the hinting mechanism, or the DNA initiation
   system.

   Notably, non-reception of data associated with end-to-end



Narayanan, et al.      Expires December 21, 2004               [Page 17]


Internet-Draft                 DNAv6 BCP                       June 2004


   communication over the Internet may be caused by reception errors at
   either end or because of network congestion.  Hosts SHOULD NOT act
   immediately on packet loss indications, delaying until it is clear
   that the packet losses aren't caused by transient events.

   Use of the Advertisement Interval Option specified in [5] 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.

6.4  Simultaneous Hints

   It is possible that hints arrive synchronously on multiple hosts at
   the same time.  As described in [1][6] , a host SHOULD delay randomly
   before acting on a widely receivable advertisement, in order to avoid
   response implosion.

   Since a host's detection of network attachment may include Router
   Solicitations sent to multicast addresses, a host may receive
   responses from each of multiple routers on a link.  Therefore, Router
   Solicitations may eventually cause additional bandwidth consumption,
   and require additional constraint.

   Where a host considers it may be on a new link and learns this from a
   hint generated by a multicast message, the host SHOULD defer 0-1000ms
   in accordance with [1][3].  Please note though that a single
   desynchronization is required for any number of transmissions
   subsequent to a hint, regardless of which messages need to be sent.

   Additional delays are only required if in response to messages
   received from the network which are themselves multicast, and it is
   not possible to identify which of the receivers the packet is in
   response to.

   While some link-layer hints may be generated by individual actions,
   other events which generate hints may affect a number of devices
   simultaneously.

   For example, if a wireless base station goes down, all the hosts on
   that base station are likely to initiate link-layer configuration
   strategies after losing track of the last beacon or pilot signal from
   the base station.

   Hence there is some chance of network layer message synchronization,
   if each device attempts the same link-layer procedures.  Such
   synchronization effects are reliant upon the nature of the particular
   link-layer technology.



Narayanan, et al.      Expires December 21, 2004               [Page 18]


Internet-Draft                 DNAv6 BCP                       June 2004


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

6.5  Hint Validity and Hysteresis

   Anecdotal evidence from the initial Detecting Network Attachment BoF
   indicated that hints received at the network layer often did not
   correspond to changes in IP connectivity [16].

   In some cases, hints could be generated at an elevated rate, which
   didn't reflect actual changes in IP configuration.  In other cases,
   hints were received prior to the availability of the medium for
   network-layer packets.

   Additionally, since packet reception at the network and other layers
   are a source for hints, it is possible for traffic patterns on the
   link to create hints, through chance or malicious intent.

   Therefore, it may be necessary to classify hint sources and types for
   their relevance and recent behavior.

   When experiencing a large number of hints, a host SHOULD employ
   hysteresis techniques to prevent excessive use of network resources.
   The host MAY change the weight of particular hints, to devalue them
   if their accuracy has been poor,  suggests invalid configurations, or
   are suspicious  (refer to Section 11).

   It is notable, that such hysteresis may cause sub-optimal change
   detection performance, and may themselves be used to block legitimate
   hint reception.  It is notable that mechanisms that cause hints to
   not be acted upon may affect the timeliness of detection of network
   attachment, in the case that they subsequently work correctly.

6.6  Hint Management for Inactive Hosts

   If a host does not expect to send or receive packets soon, it MAY
   choose to defer detection of network attachment.  This may preserve
   resources on latent hosts, by removing any need for packet
   transmission when a hint is received.

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

   When deferring this signaling, the host therefore relies upon the
   regular transmission of unsolicited advertisements for timely
   detection of link change.  It is notable that when hosts take this



Narayanan, et al.      Expires December 21, 2004               [Page 19]


Internet-Draft                 DNAv6 BCP                       June 2004


   approach the effect of simultaneous configuration is limited to those
   hosts actively polling for information.

   When a device begins sending packets, it will be necessary to test
   bidirectional reachability with the router (whose current Neighbor
   Cache state is STALE).  As described in [1], the host will delay
   before probing to allow for the probability that upper layer packet
   reception confirms reachability.

   If no packet transmission on the wireless link has occurred, before
   the new IP configuration is used for upper layer protocols, hosts MAY
   choose not to delay the reachability probe to the router, if the
   transmission time is unrelated to received multicast packets.

   This is because the initial delay is unlikely to be synchronized with
   other devices on this link, and timely liveness detection for the
   configuration may then be required.

7.  Validation of configuration

   Detecting changes in IP configuration requires either knowledge
   gathered from the network upon attachment using such methods as
   Router Discovery, or that known from prior information.

   The current foci of work in DNA Working Group are procedures
   subsequent to attachment.  Some procedures that describe how
   information may be gathered prior to arrival are summarized below.

7.1  Making use of Prior Information

   A device that has recently been attached to a particular wireless
   base station may still have state regarding the IP configuration
   valid for use on that link.  This allows a host to begin any
   configuration procedures before checking the ongoing validity and
   security of the parameters.  The experimental protocols FMIPv6 [17]
   and CARD [18] each provide ways to generate such information using
   network-layer signaling, before arrival on a link.  These are
   respectively described in Appendix C and Appendix D.  Additionally,
   the issue is the same when you disconnect from one L2 Access Point
   and return to it immediately, or movement between a pair of access
   points (the ping-pong effect).

   Care must be taken when there is a chance of an error or change in
   the configuration.  Otherwise, if the assumptions due to the stored
   configuration are incorrect the configuration cost may be increased,
   or even harm to other devices.

   Hosts MUST ensure that they will cause no harm to other devices due



Narayanan, et al.      Expires December 21, 2004               [Page 20]


Internet-Draft                 DNAv6 BCP                       June 2004


   to the invalidity or staleness of their configuration.

   In the case that the host arrives back on the same link in time less
   than the DAD completion time (minus a packet transmission and
   propagation time), the host MAY reclaim the address by sending
   Neighbor Advertisement messages as if another host had attempted DAD
   while the host was away.  This will prevent DAD completion by another
   node upon NA reception.

   If a host has not been present on a link to defend its address, and
   has been absent for a full DAD delay (minus transmission time) the
   host MUST undertake the full DAD procedure for each address from that
   link it wishes to configure [3].

7.2  Transient Link Availability

   Wireless Internet hosts can experience connectivity changes that may
   or may not be associated with IP configuration change.

   While some wireless base-station transitions are almost
   instantaneous, other cell change procedures take hundreds of
   milliseconds.  In the interval between disconnection at one cell and
   attachment at another, packets sent by the host may be discarded or
   delayed.

   In some cases, upper layer data with addressing incorrect for the new
   link may remain queued for transmission in the link-layer.  The
   subsequent queuing of signaling packets can affect timers, and
   therefore the success of reachability confirmation procedures if DNA
   procedures are aware of link-detachment and attachment.  Also if
   signaling packets are sent when the link is unavailable, the packet
   may be discarded.  This will lead to timer expiry in the case a
   solicitation is sent.

   If a host knows that connectivity has been lost at the link-layer, it
   SHOULD pause transmission of upper-layer packets to the lower-layer,
   until general data frames can be send on the new cell.  This may help
   to avoid packet loss or the queuing of signaling packets for change
   detection behind data frames.  A host SHOULD also stop sending
   signaling for the purpose of DNA to a link-layer it has been reliably
   informed is unavailable.  It is suggested that implementers utilize
   possible prioritization of the DNA signaling packets over other data
   packets while queuing them to the link-layer.

7.3  Link Change and Router Discovery

   Determining the identity of a link in IPv6 relies upon Router
   Discovery.  A link contains a set of mutually reachable interfaces on



Narayanan, et al.      Expires December 21, 2004               [Page 21]


Internet-Draft                 DNAv6 BCP                       June 2004


   routers, and media connecting them between which there is no
   forwarding hop.

   Monitoring the link-local source address of the Router Advertisement
   is insufficient to prove that a device is still on an IP link, since
   a router may share a single link-local address across multiple
   interfaces.

   Therefore the identity of the link may be determined by monitoring
   the set of routers and IPv6 prefixes advertised on the link.  Any
   router advertising one of the prefixes previously received within an
   advertisement may be assumed to belong to the same link, if the new
   advertisement was received within the Valid Lifetime of the prefix
   [1].

   Reception of Router Advertisements that do not contain any prefixes
   in common with the previously advertised set MAY be an indicator that
   link change has occurred.  IPv6 Neighbor Discovery [1] explicitly
   allows such configurations to exist though, and additionally allows
   omission of prefix information options in unsolicited Router
   Advertisements.

   In order to determine validity of configuration in such topologies,
   reachability testing MAY be required.  Additionally, during reception
   of unsolicited Router Advertisements some heuristic SHOULD be used,
   where possible, to ensure that complete prefix information is
   received by the host.  This may limit the false detection of link
   change due to omitted prefixes.

7.4  Validating configuration in Constrained Topologies

   In environments where only one router may exist within an IP link,
   changed router and prefix advertisement implies link change.  A
   mobile host implementation MAY use the knowledge of such environment,
   for example when it is on a PPP link or on a base-station/router, to
   infer link change every time a new prefix advertisement is received.
   If a host has recently received a solicited Router Advertisement from
   the configured router, it SHOULD see all prefixes configured on the
   router's interface at the time [1].  Subsequent reception of a Router
   Advertisement with a prefix not in the set MAY mean that the current
   IP configuration is invalid, and addressing and routing configuration
   procedures MAY be started.

   Also, some networks enforce IP address changes when link-layer change
   occurs.  Devices that are aware of such procedures SHOULD start IP
   configuration immediately on attachment to a new link-layer.





Narayanan, et al.      Expires December 21, 2004               [Page 22]


Internet-Draft                 DNAv6 BCP                       June 2004


7.5  Validating configuration in Arbitrary Topologies

   Many multi-access LAN-like media in the Internet may be bridged into
   arbitrary topologies on the wired network.  For these environments,
   many wireless cells may be on the same IP hop, and multiple routers
   may be reachable from each cell.

   While most wireless access networks today contain one advertising
   router, hosts SHOULD NOT immediately assume that only one router is
   on a link.

   Importantly, a host SHOULD NOT change its configuration if a new
   router advertises a prefix known to be used by another router on the
   same IP link.  For such cases, hosts SHOULD undertake reachability
   testing with the previously configured router before updating their
   routing configuration [1].

7.6  Dealing with Incomplete Information

   When determining if network attachment has occurred, it may be
   difficult to determine if a received multicast Router Advertisement
   is in response to a solicitation, or not.

   In this case it is also difficult for Router Advertisement receivers
   to determine which solicitation caused transmission of the RA.
   Timing issues before Router Advertisement responses and between
   multicast advertisements may make it difficult to match Router
   Solicitations and Advertisements using timing.

   These issues are only relevant if Secured Neighbor Discovery (SEND)
   is not in use, since SEND provides explicit copies of Nonces, which
   allow response matching [7].

   The delays between Router Advertisements on each router depend on
   random delays and the recentness of advertisement by the routers.
   Therefore, it is difficult for a device that is newly arrived on a
   link to determine if more routers are present on a link when it
   receives the first advertisement.

   When the host still has to wait for other packet reception and
   processing to complete (such as for the router's delegation chain
   authorization [7]), it is useful to continue monitoring Router
   Advertisement packets in case the next responding router is one
   currently known to the host.

   A host SHOULD accept a response from a previously known and
   authorized router if it is received while awaiting completion of
   authorization checks for a new router.  Note that previously known



Narayanan, et al.      Expires December 21, 2004               [Page 23]


Internet-Draft                 DNAv6 BCP                       June 2004


   but unsecured routers MUST NOT override routers whose authorization
   is being assessed, as their advertisement may constitute a denial of
   service attack.

7.7  Configuration Algorithms

   Hosts that travel in wireless IPv6 networks of unknown topology must
   determine appropriate procedures in order to minimize detection
   latency or preserve energy resources.  If a host is prepared to
   accept any received Router Advertisement for configuring a default
   router, then it will complete link change detection more quickly than
   a device that explicitly checks for the current router's
   unreachability.

   This mechanism is called Eager Configuration Switching [14].  It may
   cause unnecessary configuration operations, especially if unsolicited
   advertisements from multiple routers on a link are received
   containing disjoint sets of prefixes.  In this case, a configuration
   per distinct set will result [1].

   Additionally, use of only unsolicited Router Advertisements may cause
   detection or configuration of links where routers are unable to
   receive packets from the host.  Reachability testing SHOULD be done
   in accordance with [1].

   Another alternative, which reduces the problem associated with
   disjoint prefixes, only allows eager switching after link-layer hint
   indicating that a cell change has occurred.  Although another router
   on the link may respond faster than the currently configured default
   router, it will not lead to erroneous detection if the router was
   previously seen before the link-layer hint was processed.

   An alternative mechanism is called Lazy Configuration Switching [14].
   This algorithm checks that the currently configured router is
   reachable before indicating configuration change.  In this case, new
   configuration will be delayed until a timeout occurs, if the
   currently configured router is unreachable.

   Since the duration of such a timeout will significantly extend the
   duration to detect link change, this procedure is best used if the
   cell change to link change ratio is very low.

   For example:

   If the expected time to:

      Successfully test reachability (with NS/NA) is N
      Test unreachability with a timeout is T



Narayanan, et al.      Expires December 21, 2004               [Page 24]


Internet-Draft                 DNAv6 BCP                       June 2004


      Receive a Router Advertisement is R
      Reconfigure the host is C


   The probability of link change is


         p = (# of L3 links)/(# of L2 Point of attachment)


   The probability of received RA being from a router different from the
   current access router is


         p1 = (sum of all (nr - 1)/ NR)


   Where nr is the number of routers in each L3 link and NR is the total
   number of routers.

   Note that if you don't have multiple routers in the same L3 link,
   then all the (nr - 1) will be zero leading to


         p1 = 0


   Then the mean cost of Eager Configuration switching is:


         Cost(ECS)= R + ( (p + p1) * C )


   And the cost of Lazy switching is:


         Cost(LCS)= (T + R + C) * p + (1 - p) * N


   The mean cost due to Lazy Configuration Switching is lower than that
   of Eager Configuration Switching if:


         ( T + R + C ) * p  + (1 - p) * N < R + C * (p + p1)


   Using the indicative figures:




Narayanan, et al.      Expires December 21, 2004               [Page 25]


Internet-Draft                 DNAv6 BCP                       June 2004


   N=100ms

   T=1000ms

   R=250ms

   C=100ms

   The values for p where LCS is better than ECS are:


         p * (1000 + 250 + 100)ms +           < 250ms +
                          (1 - p)*100ms                 (p + p1)*100ms

         1350ms * p + 100ms - 100ms * p       < 250ms + 100 * (p + p1)

         1250ms * p - 100 * (p + p1)          < 150ms


   when p1 = 0

         1150 ms * p             < 150
         p                       < 150/1150
         p                       < 0.131
         p                      ~< 0.125 (=0.130)

   when p1 = 20%

         1250 * p - 100 * p - 20 < 150
         1150 * p                < 170
         p                       < 170/1150
         p                       < 0.147

   For these parameters, the Lazy Configuration Switching has better
   performance if the mean number of cells a device resides in before it
   has a link change is > 8.

   It may be noted that these costs are indicative of a system which
   requires a retransmission timeout of 1000ms to test unreachability,
   routers respond with unicast Router Advertisements, and DAD is
   neglected or has only 100ms of cost.

   If the reconfiguration cost is C=1000ms you will have


         2150 * p - 1000 * (p + p1) < 150

   if p1 = 20 %



Narayanan, et al.      Expires December 21, 2004               [Page 26]


Internet-Draft                 DNAv6 BCP                       June 2004


         1150 * p - 200 < 150
         1150 * p       < 350
         p              < 0.304

   For these parameters, the Lazy Configuration Switching has better
   performance if the mean number of cells a device resides in before it
   has a link change is between 3 & 4.

   This system describes a similar one to that above, except that in
   this case, the delays due to DAD or configuration are the default
   value of 1000ms.

8.  Reachability Detection

   The three different methods suggested for validating current
   configuration have implied reachability confirmations in the messages
   exchanged.  This section identifies the reachability implications
   from the hosts' perspective for the four different message exchanges
   that are possible.  The table below presents this implication for the
   two directions involved, upstream referring to the direction from the
   host to the router and downstream from the router to the host.  The
   host can confirm bi-directional reachability from any of the three
   message exchanges except when a multicast RA is received at the host
   for its RS message.  In this case, 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.

         +-----------------+----+----+----+-----+
         |   Exchanges:    |Upstream |Downstream|
         +-----------------+----+----+----+-----+
         | multicast NS/NA |    Y    |    Y     |
         +-----------------+----+----+----+-----+
         | unicast   NS/NA |    Y    |    Y     |
         +-----------------+----+----+----+-----+
         | RS/multicast RA |         |    Y     |
         +-----------------+----+----+----+-----+
         | RS/unicast RA   |    Y    |    Y     |
         +-----------------+----+----+----+-----+

   Successful exchange of the messages listed in the table indicate the
   corresponding links to be operational.  Lack of reception of response
   from the router may indicate that reachability is broken for one or
   both of the transmission directions or it may indicate ordinary
   packet loss event in either direction.

   If bi-directional reachability can not be confirmed using one of the
   three message exchanges, the host SHOULD attempt to find a better
   connection with possibly another router in the link.  Because of the



Narayanan, et al.      Expires December 21, 2004               [Page 27]


Internet-Draft                 DNAv6 BCP                       June 2004


   transient nature of the wireless link, the reachability may change
   during communication after reachability is verified.  If multiple
   routers were available, the host MAY defer test of reachability until
   the interface is to be actively used for transmission and reception.

   Hosts should also be aware of particular issues regarding their own
   wireless access technology which impinge on the reliability of
   reachability tests.  Particularly, where unicast and multicast
   propagation behaviors are significantly different, hosts SHOULD
   attempt to test both multicast and unicast reachability, to ensure
   that each works.  Hosts MAY defer such additional tests where either
   communications method is not likely to be used soon.

8.1  Wireless propagation

   Wireless channel characteristics change both in space and time.  Even
   when a wireless host is not moving, its connectivity to the access
   router can change due to factors like interference from other
   objects, temperature etc.  When the host is moving, the changes can
   be more pronounced because of change in distance, introduction of new
   objects in the LOS (line of sight) etc.  The change to the
   connectivity may affect both directions or it can be only in either
   one of the directions.  Hence, in wireless links, reachability in one
   direction does not guarantee reachability in the other.  Also, these
   variations in the wireless channel can be very short lived, creating
   rapid hints about the status of the link-layer.  It is important to
   consider the transient nature of the wireless links in design the DNA
   mechanism for such channels.

8.2  Asymmetric Reachability

   As mentioned in the previous section, wireless channels can provide
   asymmetric reachability that requires reachability testing on both
   directions.  Even previously verified bi-directional reachability can
   not guaranteed at a later time if there are other (higher layer or
   link-layer) hints implying the loss of bi-directional reachability.

   The frequency of initiation of reachability testing MUST be
   controlled in order to avoid flooding of the network.  Implementers
   are advised to build in rate-limiting mechanisms to responding to the
   hints to avoid switching IP configuration frequently when the quality
   of the wireless channel is fluctuating (see Section 6.5).

8.3  Specific (Neighbor Solicitation) Tests

   Bi-directional reachability can be verified using the Neighbor
   Discovery test to the current access router.  Since ND involves the
   use of two unicast messages exchanged between the host and the access



Narayanan, et al.      Expires December 21, 2004               [Page 28]


Internet-Draft                 DNAv6 BCP                       June 2004


   router, a successful ND procedure verifies bi-directional
   reachability.

8.4  Non-Specific (Router Solicitation) Tests

   Initiating Router Discovery procedure can sometimes lead to
   verification of the bi-directional reachability.  It does not always
   confirm bi-directional reachability because if the router responds
   for the RS with a multicast RA message, there is no way for the host
   to identify whether the RA is in response to the RS or whether it is
   a periodic RA transmission.  Even with multicast RA response, if SEND
   is used, bi-directional reachability can confirmed because SEND uses
   a unique NONCE to match request and response messages [7].  If the
   router chooses to respond to a RS with a unicast RA message, again,
   the host will be able to match the RS and RA and hence confirm
   bi-directional reachability.

8.5  Trade-offs in Reachability Testing

   There unique advantages and dis-advantages in using either the
   Specific or the Non-specific test to confirm reachability.

   Specific tests:

   Advantages:

   Confirmation of bi-directional reachability.

   Dis-advantages:

   If the ND test fails, the host has no potential configuration
   information it can use.

   Non-Specific tests:

   Advantages:

   Even when the current access router is not reachable, an RA message
   from any available router will provide information that can used to
   configure the host.

   Confirmation of bi-directional reachability if SEND is used or if the
   router chooses to respond with an unicast RA message.

   Dis-advantages:

   If multicast RA response is received, the host may have to execute an
   ND test to confirm bi-directional reachability.  Such a test may be



Narayanan, et al.      Expires December 21, 2004               [Page 29]


Internet-Draft                 DNAv6 BCP                       June 2004


   avoided if upper layer confirmations are received within the DELAY
   period prescribed by IPv6 Neighbor Discovery [1].

   Even when the current access router is reachable, the response may
   arrive from a different access router leading to erroneous
   re-configuration of the host.

9.  Complications to Detecting Network Attachment

   Detection of network attachment procedures can be delayed or may be
   incorrect due to different factors.  As the reachability testing
   mainly relies on timeout, packet loss or different router
   configurations may lead to erroneous conclusions.  This section gives
   some examples where complications may interfere with DNA processing.

9.1  Tentative Addressing

   When a host connects to a new link, it needs to create a link-local
   address.  But as the link-local address must be unique on a link,
   Duplication Address Detection (DAD) must be performed [3] by sending
   NS to the target link-local address.  An address that is being
   validated is said to be a tentative address.  The host that only has
   a tentative address must not accept packets intended to this
   destination, neither may they send packets with it.  If the host does
   not get any reply to its DAD Neighbor Solicitations, the tentative
   link-local address can be allocated to the interface of the host.
   From that point, the link-local address can be used and the prefix
   and router discovery can then take place.

   Several NS's can be sent to perform DAD on a tentative link local
   address.  However, the default number of transmissions of Neighbor
   Solicitations is 1.  If an NA is not received within one second after
   the NS transmission, the tentative address is considered as unique.
   However, if the NS or NA are lost for some reason, the tentative
   address will be considered as unique while another node might have
   the same address.  Notably though, each additional transmission of an
   NS introduces a delay of one second in the configuration
   establishment, which has an important impact on IP configuration
   latency.

   While hosts performing DNA do not know if they have arrived on a new
   link, they SHOULD treat their addresses as if they were.  This means
   that link-local addresses SHOULD be treated as tentative, and
   globally unique addresses SHOULD NOT be used in a way which creates
   neighbor cache state on their peers, while DNA procedures are
   underway.  The different treatment of IP addressing comes from the
   fact that on the global addresses cannot have an address conflict if
   they move to a topologically incorrect network where link-local



Narayanan, et al.      Expires December 21, 2004               [Page 30]


Internet-Draft                 DNAv6 BCP                       June 2004


   addresses may.  Even though global addresses will not collide, the
   incorrect creation of neighbor cache entries on legacy peers may
   cause them some harm.

9.2  Packet Loss

   Generally, packet loss while a host is validating or discovering an
   IP configuration introduces significant delays.  Because most of the
   protocols rely on timeout to consider that a peer is not reachable
   anymore, packet loss may lead to erroneous conclusions.  Assume a
   wireless host that connects to a new access point attached to the
   same IPv6 subnet.  The connexion establishment with the new access
   point generates a link-layer hint trigger which tells the mobile node
   that it may have moved to a new IPv6 link.  Upon the reception of
   this trigger, the mobile node may want to check reachability with its
   current router and sends a NS.  If the NS or the NA in response is
   lost, the mobile node could conclude that it has changed link and
   that its current default router is unreachable.

9.3  Router Configurations

   Each router can have its own configuration with respect to sending
   RA, and the treatment of router and neighbor solicitations.
   Different timers and constants might be used by different routers,
   such as the delay between Router Advertisements or delay before
   replying to an RS.  If a host is changing is IPv6 link, new router on
   that link may have a different configuration and may introduce more
   delay than the previous default router of the host.  The time needed
   to discover the new link can then be longer than expected by the
   host.

9.4  Overlapping Coverage

   If a host can be attached to different links at the same time with
   the same interface, the host will probably listen to different
   routers, at least one on each link.  To be simultaneously attached to
   several links may be very valuable for a MN when it moves from one
   access network to another.  If the node can still be reachable
   through its old link while configuring the interface for its new
   link, packet loss can be minimized.  Such a situation may happen in a
   wireless environment if the link layer technology allows the MN to be
   simultaneously attached to several points of attachment and if the
   coverage area of access points are overlapping.  For the DNA purpose,
   the different links should not be classified as a unique link.
   Because if one router or an entire link where the node is attached
   comes down, it doesn't mean that the other link are also down.  In
   particular, the routers on the other links might still be reachable
   for the host.



Narayanan, et al.      Expires December 21, 2004               [Page 31]


Internet-Draft                 DNAv6 BCP                       June 2004


9.5  Multicast Snooping

   When a host is participating in DNA on a link where multicast
   snooping is in use, multicast packets may not be delivered to the
   LAN-segment to which the host is attached until MLD signaling has
   been performed [8][10][15].  Where DNA relies upon multicast packet
   delivery (for example, if a router needs to send a Neighbor
   Solicitation to the host), its function will be degraded until after
   an MLD report is sent.

   Where it is possible that multicast snooping is in operation, hosts
   should consider sending MLD group joins (MLD reports) for solicited
   nodes' addresses swiftly after starting DNA procedures.

10.  Current Practice for Routers supporting DNA

   This section provides guidance for those routers which wish to
   support hosts undertaking detection of network attachment using
   existing router and neighbor discovery techniques.

   It should be noted that many deployed routers will not support these
   recommendations, and that hosts SHOULD NOT rely on their being in
   place, unless they have particular reason to do so.

10.1  Router Advertisement Intervals

   The router discovery mechanism defined in RFC 2461 [1] recommends a
   set of interval timers that affect the performance of the router
   discovery procedure.  The following table summarizes the values and
   their effect.

         +-----------------------+----+----+----+-----+----+-----+
         |   Timer               |Maximum  |Default   |Minimum   |
         +-----------------------+----+----+----+-----+----+-----+
         | MaxRtrAdvInterval     |  1800   |   600    |    4     |
         +-----------------------+----+----+----+-----+----+-----+
         | MinRtrAdvInterval     |   594   |   198    |    3     |
         +-----------------------+----+----+----+-----+----+-----+
         |Avg. Multicast RA time |  1197   |   399    |   3.5    |
         +-----------------------+----+----+----+-----+----+-----+
         |RA MCast response time |   3.5   |    NA    |    0     |
         +-----------------------+----+----+----+-----+----+-----+
         |RA Ucast response time |   0.5   |    NA    |    0     |
         +-----------------------+----+----+----+-----+----+-----+


   Assuming Poisson arrival of router solicitation messages at the rate
   of 0.05 messages per second, the average multicast RA response time



Narayanan, et al.      Expires December 21, 2004               [Page 32]


Internet-Draft                 DNAv6 BCP                       June 2004


   can be calculated as follows

   Probability of at least one arrival in MIN_DELAY_BETWEEN_RAS time is:


         (p) = 1 - exp (lambda * t) (i.e. 1 - P[X(t) == 0])


   where lambda is the arrival rate of RS messages and t is
   MIN_DELAY_BETWEEN_RAS

   Given a Poisson occurrences in an interval, these occurrences are
   uniformly located in that interval.  Hence the delay introduced by
   arrival in MIN_DELAY_BETWEEN_RAS time is p * t/2.  Adding 0.250 for
   the random delay introduced, the average multicast RA response time
   is 0.458938 seconds.

   The average unicast RA response time of course is 0.250 seconds.

   The table gets modified as follows based on the recommendation of RFC
   3775 [5]

         +-----------------------+----+----+----+-----+----+-----+
         |   Timer               |Maximum  |Default   |Minimum   |
         +-----------------------+----+----+----+-----+----+-----+
         | MaxRtrAdvInterval     |  1800   |   600    |  0.07    |
         +-----------------------+----+----+----+-----+----+-----+
         | MinRtrAdvInterval     |   594   |   198    |  0.03    |
         +-----------------------+----+----+----+-----+----+-----+
         |Avg. Multicast RA time |  1197   |   399    |  0.05    |
         +-----------------------+----+----+----+-----+----+-----+
         |RA MCast response time |  0.5    |    NA    |    0     |
         +-----------------------+----+----+----+-----+----+-----+
         |RA UCast response time |  0.5    |    NA    |    0     |
         +-----------------------+----+----+----+-----+----+-----+

   Assuming Poisson arrival of router solicitation messages at the rate
   of 0.05 messages per second, the average multicast RA response time =
   0.250022 seconds.  The average unicast RA response time is the same
   0.250 seconds.  Changing the minimum values for these protocol
   constants as recommended by RFC 3775 [5] reduces the average time
   delay introduced by both solicited and un-solicited Router
   Advertisements.  But, adopting these values for the unsolicited
   Router Advertisements will increase the bandwidth overhead for these
   RA messages.  With the minimum allowed average for un-solicited
   Router Advertisements there would be 20 message per second, assuming
   the minimum packet size for an RA with one prefix as 88 bytes, the
   bandwidth used the RAs alone will be 14 kbps.  If SEND packets are



Narayanan, et al.      Expires December 21, 2004               [Page 33]


Internet-Draft                 DNAv6 BCP                       June 2004


   used for these Router Advertisements, with the keys and certificates
   the average packet size and hence the bandwidth used will increase
   dramatically.

10.2  Unicast Response Transmission

   The IPv6 Neighbor Discovery RFC allows the routers to respond to RS
   message with a unicast RA, but does not mandate it [1].  The
   advantage in responding with an unicast RA message is to allow the IP
   host to infer bi-directional reachability from the RS-RA exchange.
   The dis-advantage is that the router will not be able to aggregate
   its response for multiple RS messages received during the wait
   period.

   It is important to note that the MIN_DELAY_BETWEEN_RAS restriction
   required by the Neighbor Discovery RFC is applicable only to
   multicast RAs [1].  Routers MAY choose to respond to RS messages with
   a unicast RA response to reduce the response delay if it sent a
   multicast RA within the last MIN_DELAY_BETWEEN_RAS seconds.  This
   difference may not be very high if the value (0.03) suggested in
   Mobile IPv6 is implemented [5].

10.3  Point-to-Point Links

   IPv6 Neighbor Discovery RFC mandates the delay of RA responses by
   stating (in section 6.2.6 of [1]):


      "In all cases, Router Advertisements sent in response to a
       Router Solicitation MUST be delayed by a random time
       between 0 and MAX_RA_DELAY_TIME seconds."


   Cases where the router is on a point-to-point link, this restriction
   is too stringent as the router in question will be the only router on
   the link.  Routers on such point-to-point links MAY avoid the delay
   by not waiting for the prescribed random time before responding for
   the Router Solicitation message.

10.4  Prefix Advertisement

   A router MAY choose to split the options in the RA and send multiple
   RAs to reduce bandwidth overhead or to reduce the size of the RA to
   below the link MTU (see section 6.2.3 of [1]).

   If such a choice is made, average multicast RA time discussed in
   Section 10.1 increases for each subset of the prefixes included in
   the split RA messages.  Routers SHOULD consistently include one of



Narayanan, et al.      Expires December 21, 2004               [Page 34]


Internet-Draft                 DNAv6 BCP                       June 2004


   the prefixes in each of its RA messages to provide the host with a
   unique identifier based on the combination of link-local address and
   the constant prefix, to identify the router every time a RA message
   is received from the router.

   TBD: Checking for consistency?

10.5  Secured Neighbor Discovery

   Routers supporting DNA SHOULD provide secured router discovery
   services [7].

   This requires not only digitally signed messaging from hosts to
   provide immutability of neighbour discovery messages on the access
   link, but delegated authority from the network infrastructure to
   route particular prefixes.

   This delegation chain is transmitted and received in Delegation Chain
   Solicitation and Delegation Chain Advertisement Messages.  These
   messages are rate limited in a similar fashion to Router
   Advertisements and RS/RA exchanges [7].

   The certificates can be used by hosts to identify routers and their
   owner organizations, as well as to determine their authorization to
   route for the advertised prefixes.

11.  Security Considerations

   Detecting Network Attachment is a mechanism which allows network
   messages to change the node's belief about its configuration state.
   As such, it is important that the need for rapid testing of link
   change does not lead to situations where configuration is invalidated
   by malicious third parties, nor that information passed to
   configuration processes exposes the host to attack.

   Since DNA relies heavily upon IPv6 Neighbor Discovery, the threats
   which are applicable to those procedures also affect Detecting
   Network Attachment.  These threats are described in [11].

   Some additional threats are outlined below.

11.1  Replay or impersonation of messages.

   If a host receives a series of messages which authenticate the
   transmission of Router Advertisements, but aren't sent in response to
   the host's own solicitation, there is no guarantee that the router is
   actually present on the link.




Narayanan, et al.      Expires December 21, 2004               [Page 35]


Internet-Draft                 DNAv6 BCP                       June 2004


   If an attacking device can replay advertisements elsewhere, such a
   router may be accepted based on the freshness of its timestamps in
   accordance with [7], until the host attempts bidirectional
   reachability tests with the false router.

   Where the bidirectional reachability attempts may be replayed by the
   attacker between a pair of links, a device with the ability to forge
   link-layer addresses may be able to fool both the router and host to
   believing they are directly adjacent.

   Additionally, when moving between several different networks, timing
   state as perceived by routers and hosts may become mismatched.  In
   this case it may be possible to allow a wider window of attacks by
   determining if a host has a delayed clock, and replaying signaling
   messages.

   Additionally, if hosts' clocks can be made to slow down or speed up,
   secured neighbor discovery messages can be forced outside the valid
   window, and prevent correctly configured SEND messages from being
   processed.  In this case, it may be possible to bid down the host to
   choose an unsecured Router Advertisement that doesn't perform SEND to
   a valid router that does.

11.2  Authorization and Detecting Network Attachment

   Hosts connecting to the Internet over wireless media may be exposed
   to a variety of network configurations with differing robustness,
   controls and security.

   When a host is determining if link change has occurred, it may
   receive messages from devices with no advertised security mechanisms
   purporting to be routers, nodes sending signed router advertisements
   but with unknown delegation, or routers whose credentials need to be
   checked [11].  Where a host wishes to configure an unsecured router,
   it SHOULD at least confirm bidirectional reachability with the
   device, and it MUST mark the device as unsecured as described in [7].

   In any case, a secured router SHOULD be preferred over an unsecured
   one, except where other factors (unreachability) make the router
   unsuitable.  Since secured routers' advertisement services may be
   subject to attack, alternative (secured) reachability mechanisms from
   upper layers, or secured reachability of other devices known to be on
   the same link may be used to check reachability in the first
   instance.

11.3  Addressing

   While a DNA host is checking attachment, and observing DAD, it may



Narayanan, et al.      Expires December 21, 2004               [Page 36]


Internet-Draft                 DNAv6 BCP                       June 2004


   receive a DAD defense NA from an unsecured source.

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

   While this is a valid action in the case where a host collides with
   another address owner after arrival on a new link, In the case that
   the host returns immediately to the same link, such a DAD defense NA
   message can only be a denial-of-service attempt.

   If a non-SEND node forges a DAD defense for an address which is still
   in peers' neighbor cache entries, a host may send a SEND protected
   unicast neighbor solicitation without a source link-layer address
   option to one its peers (which also uses SEND).  If this peer is
   reachable, it will not have registered the non-SEND DAD defense NA in
   its neighbor cache, and will send a direct NA back to the soliciting
   host.  Such an NA reception disproves the DAD defense NA's validity.

   Therefore, a SEND host performing DNA which receives a DAD defense
   from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a
   STALE or REACHABLE secured neighbor cache entry, omitting source
   link-layer address options.  In this case, the host should pick an
   entry which is likely to have a corresponding entry on the peer.  If
   the host responds within a RetransTimer interval, then the DAD
   defense was an attack, and the host SHOULD inform its systems
   administrator without disabling the address.

12.  Acknowledgments

   JinHyeock Choi has done lots of work regarding inference of link
   identity through sets of prefixes.  Bernard Aboba's work on DNA for
   IPv4 significantly influenced this document.

13.  References

13.1  Normative References

   [1]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC2462 2462, December 1998.

   [4]  Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
        December 1998.



Narayanan, et al.      Expires December 21, 2004               [Page 37]


Internet-Draft                 DNAv6 BCP                       June 2004


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

   [6]  Conta, A. and S. Deering, "Internet Control Message Protocol
        (ICMPv6) for the Internet Protocol Version 6 (IPv6)
        Specification", RFC2463 2463, December 1998.

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

13.2  Informative References

   [8]   Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [9]   Haberman, B., "Source Address Selection for the Multicast
         Listener Discovery (MLD) Protocol", RFC 3590, September 2003.

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

   [11]  Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [12]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

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

   [14]  Fikouras, N A., K"onsgen, A J. and C. G"org, "Accelerating
         Mobile IP Hand-offs through Link-layer Information",
         Proceedings of the International Multiconference on
         Measurement, Modelling, and Evaluation of
         Computer-Communication Systems (MMB) 2001, September 2001.

   [15]  Christensen, M., Kimball, K. and F. Solensky, "Considerations
         for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11
         (work in progress), May 2004.

   [16]  Kniveton, T J. and B C. Pentland, "Session minutes of the
         Detecting Network Attachment (DNA) BoF", Proceedings of the
         fifty-seventh Internet Engineering Task Force Meeting IETF57,
         July 2003.

   [17]  Koodli, R., "Fast Handovers for Mobile IPv6",



Narayanan, et al.      Expires December 21, 2004               [Page 38]


Internet-Draft                 DNAv6 BCP                       June 2004


         draft-ietf-mipshop-fast-mipv6-01 (work in progress), February
         2004.

   [18]  Liebsch, M., "Candidate Access Router Discovery",
         draft-ietf-seamoby-card-protocol-06 (work in progress), January
         2004.

   [19]  O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control
         (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std
         802.11, 1999.

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

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


Authors' Addresses

   Sathya Narayanan
   Panasonic Digital Networking Lab
   Two Research Way, 3rd Floor
   Princeton, NJ  08536
   USA

   Phone: 609 734 7599
   EMail: sathya@Research.Panasonic.COM
   URI:


   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










Narayanan, et al.      Expires December 21, 2004               [Page 39]


Internet-Draft                 DNAv6 BCP                       June 2004


   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/

Appendix A.  Summary of Recommendations

   The signaling which causes a hint may be due to network-layer
   messages such as unexpected Router Advertisements, multicast listener
   queries or ICMPv6 error messages [1][8][10][6].  In these cases,
   caution must be exerted.

   Hosts MUST ensure that untrusted messages do not cause unnecessary
   configuration changes, or significant consumption of host resources
   or bandwidth.

   Care must be taken when there is a chance of an error or change in
   the configuration.  Otherwise, if the assumptions due to the stored
   configuration are incorrect the configuration cost may be increased,
   or even harm to other devices.

   Hosts MUST ensure that they will cause no harm to other devices due
   to the invalidity or staleness of their configuration.

   If a host has not been present on a link to defend its address, and
   has been absent for a full DAD delay (minus transmission time) the
   host MUST undertake the full DAD procedure for each address from that
   link it wishes to configure [3].

   A host SHOULD accept a response from a previously known and
   authorized router if it is received while awaiting completion of
   authorization checks for a new router.  Note that previously known
   but unsecured routers MUST NOT override routers whose authorization
   is being assessed, as their advertisement may constitute a denial of
   service attack.

   Hosts that travel in wireless IPv6 networks of unknown topology must
   determine appropriate procedures in order to minimize detection
   latency or preserve energy resources.

   Where a host wishes to configure an unsecured router, it SHOULD at
   least confirm bidirectional reachability with the device, and it MUST



Narayanan, et al.      Expires December 21, 2004               [Page 40]


Internet-Draft                 DNAv6 BCP                       June 2004


   mark the device as unsecured [7].

   Hints SHOULD NOT be considered to be authoritative for detecting IP
   configuration change by themselves.

   Therefore, hosts SHOULD NOT change their configuration state based on
   hints from other protocol layers.

   While hints from other protocol layers originate from within the
   host's own stack, the network layer SHOULD NOT treat hints from other
   protocol layers as authoritative indications of link change.

   Hosts SHOULD NOT start DNA procedures simply because a data link is
   idle, in accordance with [1].  Hosts MAY act on hints associated with
   non-reception of expected signaling or data.

   Since DNA is likely to be used when communicating with devices over
   wireless links, suitable resilience to packet loss SHOULD be
   incorporated into either the hinting mechanism, or the DNA initiation
   system.

   Hosts SHOULD NOT act immediately on packet loss indications, delaying
   until it is clear that the packet losses aren't caused by transient
   events.

   It is possible that hints arrive synchronously on multiple hosts at
   the same time.  As described in [1][3], a host SHOULD delay randomly
   before acting on a widely receivable advertisement, in order to avoid
   response implosion.

   Where a host considers it may be on a new link and learns this from a
   hint generated by a multicast message, the host SHOULD defer 0-1000ms
   in accordance with [1].

   When experiencing a large number of hints, a host SHOULD employ
   hysteresis techniques to prevent excessive use of network resources.
   The host MAY change the weight of particular hints, to devalue them
   if their accuracy has been poor, or suggests invalid configurations.

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

   A host MAY choose to adopt an appropriate link change detection
   strategy based upon hints received from other layers, with suitable
   caution and hysteresis.




Narayanan, et al.      Expires December 21, 2004               [Page 41]


Internet-Draft                 DNAv6 BCP                       June 2004


   If a host knows that connectivity has been lost at the link-layer, it
   SHOULD pause transmission of upper-layer packets to the lower-layer,
   until general data frames can be send on the new cell.

   A host SHOULD also stop sending signaling for the purpose of DNA to a
   link-layer it has been reliably informed is unavailable.

   In order to determine validity of configuration in such topologies,
   reachability testing MAY be required.  Additionally, reception of
   solicited Router Advertisements some heuristic SHOULD be used, where
   possible, to ensure that complete prefix information is received by
   the host.  This may limit the false detection of link change due to
   omitted prefixes.

   If a host has recently received a solicited Router Advertisement from
   the configured router, it SHOULD see all prefixes configured on the
   router's interface at the time [1].  Subsequent reception of a Router
   Advertisement with a prefix not in the set means that the current IP
   configuration is invalid, and addressing and routing configuration
   procedures SHOULD be started.

   Also, some networks enforce IP address changes when link-layer change
   occurs.  Devices that are aware of such procedures SHOULD start IP
   configuration immediately on attachment to a new link-layer.

   While most wireless access networks today contain one advertising
   router, hosts SHOULD NOT immediately assume that only one router is
   on a link.

   Importantly, a host SHOULD NOT change its configuration if a new
   router advertises a prefix known to be used by another router on the
   same IP link.  For such cases, hosts SHOULD undertake reachability
   testing with the previously configured router before updating their
   routing configuration [1].

   Additionally, use of only unsolicited Router Advertisements may cause
   detection or configuration of links where routers are unable to
   receive packets from the host.  Reachability testing SHOULD be done
   in accordance with [1].

   In any case, a secured router SHOULD be preferred over an unsecured
   one, except where other factors (unreachability) make the router
   unsuitable.

   When using the passive method, absence of Router Advertisements (RA)
   from the current default router MAY require verification and
   acquisition of configuration using one of the active mechanisms




Narayanan, et al.      Expires December 21, 2004               [Page 42]


Internet-Draft                 DNAv6 BCP                       June 2004


   Hints MAY be used to update a wireless host's timers or probing
   behavior in such a way as to assist detection of network attachment.

   A host MAY choose to adopt an appropriate link change detection
   strategy based upon hints received from other layers, with suitable
   caution and hysteresis.

   Hosts MAY act on hints associated with non-reception of expected
   signaling or data.

   If a host does not expect to send or receive packets soon, it MAY
   choose to defer detection of network attachment.

   If no packet transmission on the wireless link has occurred, before
   the new IP configuration is used for upper layer protocols, hosts MAY
   choose not to delay the reachability probe to the router, if the
   transmission time is unrelated to received multicast packets.

   In the case that the host arrives back on the same link in time less
   than the DAD completion time (minus a packet transmission and
   propagation time), the host MAY reclaim the address by sending
   Neighbor Advertisement messages as if another host had attempted DAD
   while the host was away.  This will prevent DAD completion by another
   node upon NA reception.

   Reception of Router Advertisements that do not contain any prefixes
   in common with the previously advertised set MAY be an indicator that
   link change has occurred.  IPv6 Neighbor Discovery [1] explicitly
   allows such configurations to exist though, and additionally allows
   omission of prefix information options in unsolicited Router
   Advertisements.  In order to determine validity of configuration in
   such topologies, reachability testing MAY be required.

Appendix B.  Example State Transition Diagram

   TBD

Appendix C.  DNA With Fast Handovers for Mobile IPv6

   TBD

Appendix D.  DNA with Candidate Access Router Discovery

   TBD







Narayanan, et al.      Expires December 21, 2004               [Page 43]


Internet-Draft                 DNAv6 BCP                       June 2004


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 (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Narayanan, et al.      Expires December 21, 2004               [Page 44]