Network Working Group                                        S. Krishnan
Internet-Draft                                                  Ericsson
Updates: 4861 (if approved)                                     G. Daley
Intended status: Standards Track                                G. Daley
Expires: July 25, 2010                                  NetStar Networks
Expires: April 29,
                                                        January 21, 2010                                 October 26, 2009

       Simple procedures for Detecting Network Attachment in IPv6
                        draft-ietf-dna-simple-11
                        draft-ietf-dna-simple-12

Abstract

   Detecting Network Attachment allows hosts to assess if its existing
   addressing or routing configuration is valid for a newly connected
   network.  This document provides simple procedures for detecting
   network attachment in IPv6 hosts, and procedures for routers to
   support such services.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, July 25, 2010.

Copyright Notice

   Copyright (c) 2009 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   Detecting Network Attachment allows hosts to assess if its existing
   addressing or routing configuration is valid for a newly connected
   network.

   This  Code Components extracted from this document provides simple procedures for detecting network
   attachment must
   include Simplified BSD License text as described in IPv6 hosts, Section 4.e of
   the Trust Legal Provisions and procedures for routers to support such
   services. are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Link Identification model  . . . . . . . . . . . . . . . .  4
     2.4.  DNA Overview . . . . . . . . . . . . . . . . . . . . . . .  4
     2.5.  Working Assumptions  . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Host Operations  . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Host data structures . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  SDAT Maintenance . . . . . . . . . . . . . . . . . . .  6
     4.2.  Steps involved in detecting link change  . . . . . . . . .  6  7
     4.3.  Link-Layer Indication  . . . . . . . . . . . . . . . . . .  7
     4.4.  Sending Neighbor Discovery probes  . . . . . . . . . . . .  7
     4.5.  Contents of the Neighbor Discovery messages  . . . . . . .  8  9
       4.5.1.  Neighbor Solicitation messages . . . . . . . . . . . .  8  9
       4.5.2.  Router Solicitation messages . . . . . . . . . . . . .  8  9
     4.6.  DHCPv6 operation . . . . . . . . . . . . . . . . . . . . .  9 10
     4.7.  Response Gathering . . . . . . . . . . . . . . . . . . . .  9 10
       4.7.1.  Conflicting results  . . . . . . . . . . . . . . . . . 10 11
     4.8.  Further Host Operations  . . . . . . . . . . . . . . . . . 11
     4.9.  Recommended retransmission behavior  . . . . . . . . . . . 11 12
   5.  Pseudocode for Simple DNA  . . . . . . . . . . . . . . . . . . 13
   6.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Relationship to DNAv4  . . . . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Issues with confirming manually assigned addresses  . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Hosts require procedures to simply and reliably identify if they have
   moved to a different IP network than the one to which they have had been recently connected.  In
   order to detect change, router and neighbor discovery messages are
   used to collect reachability and configuration information.  This
   information is used to detect whether the existing router and address
   prefixes are likely to be present.

   This document incorporates feedback from host and router operating
   systems implementors, which seeks to make implementation and adoption
   of IPv6 change detection procedures simple for general use.

2.1.  Goals

   The goal of this document is to specify a simple procedure for
   detecting network attachment (Simple DNA) that has the following
   characteristics.

   o  Routers do not have to be modified to support this scheme.

   o  The most common use cases are optimized.

   o  In the worst case, detection latency is equal to that of standard
      neighbor discovery so that performance is never degraded.

   o  False positives are not acceptable.  A host should not MUST NOT conclude that
      there is no link change when there is one.

   o  False negatives are acceptable.  A host can conclude that there is MAY fail to identify a
      previously visited link change when there is none. correctly and attempt to acquire fresh
      addressing and configuration information.

2.2.  Applicability

   The Simple DNA protocol provides substantial benefits over standard
   neighbor discovery procedures [RFC4861] in some scenarios and does
   not provide any benefit at all in certain other scenarios.  This is
   intentional as Simple DNA was designed for simplicity rather than
   completeness.  In particular, the Simple DNA protocol provides
   maximum benefits when a host moves between a small set of known
   links.  When a host moves to a completely new link that is previously
   unknown, the performance of the Simple DNA protocol will be identical
   to that using standard neighbor discovery procedures [RFC4861].  In
   this case the main benefit of the Simple DNA protocol is to
   immediately flush out the inoperable addresses and configuration
   instead of timing them out.  The Simple DNA procedure provides
   support for addresses configured using either IPv6 Stateless Address
   Autoconfiguration [RFC4862] or DHCPv6 [RFC3315].  It does not support
   manually configured addresses since they are not widely used and can
   cause unpredictable results and/or aggressive probing behavior
   [Appendix A].

2.3.  Link Identification model

   Earlier methods of detecting network attachment, e.g. the procedure
   defined in [I-D.ietf-dna-protocol], relied on detecting whether the
   host was still connected to the same link.  If the host was attached
   to the same link, all information related to the link such as the
   routers, prefixes and configuration parameters was considered to be
   valid.  The Simple DNA protocol follows an alternate approach where
   it relies on probing each previously known router to determine
   whether to use information learnt from THAT router.  This allows
   simple DNA to probe routers learnt from multiple earlier attachments
   to optimize movement between a known set of links.

2.4.  DNA Overview

   Detecting Network Attachment is performed by hosts after detecting a
   link-layer "up" indication.  The host simultaneously sends multicast
   Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs)
   in order to determine whether previously encountered routers are
   present on the link.

   Hosts implementing simple DNA may also send DHCPv6 packets, as
   described in Section 4.6.  Since simple DNA does not modify the
   DHCPv6 protocol or state machine, the operation of DHCPv6 is
   unchanged.

   Routers that follow the standard neighbor discovery procedure
   described in [RFC4861] will delay the router advertisement by a
   random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms)
   as described in Section 6.2.6 of [RFC4861].  Hosts implementing
   simple DNA can detect the presence of a previously encountered router
   using unicast Neighbor Solicitations.  As a result, where the host
   with a valid configuration is returning to a previously encountered
   link, delays in the sending of a Router Advertisement (RA) will not
   delay configuration as long as NS probing is successful.  However in
   situations where the host is attaching to a link for the first time,
   or where it does not have a valid IP address on the link, it will be
   dependent on the receipt of an RA for stateless auto-configuration.
   In these situations delays in the receipt of an RA can be significant
   and may result in service disruption.

   As a result, in addition to implementing simple DNA, it is desirable
   that routers adopt procedures which allow for fast unicast Router
   Advertisement (RA) messages.

2.5.  Working Assumptions

   There are a series of assumptions about the network environment which
   underpin these procedures.

   o  The combination of the link layer address and the link local IPv6
      address of a router is unique across links.

   o  Hosts receive indications when a link-layer comes up.  Without
      this, they would not know when to commence the DNA procedure.

   If these assumptions do not hold, host change detection systems will
   not function optimally.  In that case, they may occasionally detect
   change spuriously, or experience some delay in detecting network
   attachment.  The delays so experienced will be no longer than those
   caused by following the standard neighbor discovery procedure
   described in [RFC4861].

3.  Terminology

   +---------------------+---------------------------------------------+
   |         Term        |                  Definition                 |
   +---------------------+---------------------------------------------+
   |  Valid IPv6 address | An IPv6 address configured on the node that |
   |                     |   has a valid lifetime greater than zero.   |
   |                     |                                             |
   |    Operable IPv6    | An IPv6 address configured on the node that |
   |       address       |   can be used safely on the current link.   |
   +---------------------+---------------------------------------------+

                      Table 1: Simple DNA Terminology

4.  Host Operations

   When a host has an existing configuration for IP address prefixes and
   next hop routing, it may be disconnected from its link-layer, and
   then subsequently reconnect the link-layer on the same interface.

   When the link-layer becomes available again, it is important to
   determine whether the existing addressing and routing configuration
   are still valid.

   In order to determine this, the host performs the detecting network
   attachment procedure.

4.1.  Host data structures

   In order to correctly perform the procedure described in this
   document the host needs to maintain a data structure called the
   Simple DNA address table (SDAT).  This  The host needs to maintain this
   data structure is maintained
   by the host on a per for each interface basis. on which it performs Simple DNA.
   Each entry in the SDAT table consists of at least the following
   parameters.

   o  IPv6 address and its related parameters like valid lifetime. lifetime,
      preferred lifetime etc.

   o  Prefix from which the address was formed.

   o  Link-local IPv6 address address(es) of the router router(s) that advertised the
      prefix.

   o  Link-layer (MAC) address address(es) of the router router(s) that advertised the
      prefix.

   o  DHCP Unique IDentifier (DUID) in case DHCPv6  Flag indicating whether the address was obtained using SLAAC or
      DHCPv6.

   o  DHCP specific information in case DHCPv6 [RFC3315] was used to
      acquire the address.  This information includes DUID, IA_ID, a
      flag indicating IA_NA/IA_TA, configuration information such as DNS
      server address, NTP server address [RFC3315]. etc.

4.1.1.  SDAT Maintenance

   The host SHOULD maintain the SDAT table by periodically cleaning out
   entries whose valid lifetimes have expired.  The host MAY also
   maintain the table by allowing SDAT entries from "n" previously
   visited links.  When the host attaches to a previously unknown link
   and the SDAT already contains entries from the previous "n" attached
   links,it will discard all the SDAT entries corrsponding to the least
   recently attached link.

4.2.  Steps involved in detecting link change

   The steps involved in basic detection of network attachment are:

   o  Link-Layer Indication

   o  Sending of neighbor discovery or and/or DHCPv6 probes

   o  Response gathering and assessment

   These steps are described below.

4.3.  Link-Layer Indication

   In order to start Detection of network attachment procedures, a host
   typically requires a link-layer indication that the medium has become
   available [RFC4957].

   After the indication is received, the host considers all currently
   configured (non-tentative) IP addresses to be deprecated until the
   change detection process completes.  It SHOULD MUST also set all Neighbor
   Cache entries for the routers on its Default Router List to STALE.
   This is done to speed up the acquisition of a new default router when
   link change has occurred.

4.4.  Sending Neighbor Discovery probes

   When a host receives a link-layer "up" indication, it SHOULD
   immediately send both a Router Solicitation (as specified in as
   specified in section 6.3.7 of [RFC4861]) and if it retains at least
   one valid IPv6 address, one or more unicast Neighbor Solicitations.
   The Router Solicitation is sent to the All-routers multicast address
   using a link-local address as the source address [RFC4861].  Even if
   the host is in possession of more than one valid IPv6 address, it
   MUST send only one router solicitation using a valid link-local
   address as the source address.

   For the purpose of sending neighbor solicitations to previous
   routers, the host first identifies the set of operable valid IPv6 addresses
   (candidate set) that it wishes to use.  If the addresses obtained
   from a previous router are no longer valid, the host does not include
   these addresses in the candidate set for NS based probing.

   For each of the addresses in the candidate set, the host looks up the
   SDAT to find out the link-local and MAC addresses of the router router(s)
   that advertised the prefix used to form the address.  It then sends
   an unicast Neighbor Solicitations to each router's link-local address
   it obtained from the lookup on the SDAT.  The host SHOULD MUST NOT send
   unicast Neighbor Solicitations to a test node corresponding to an
   IPv6 address that is no longer valid.

   Please note that the Neighbor Solicitations SHOULD be sent in
   parallel with the Router Solicitations. Solicitation.  Since sending NSs is just an
   optimization, doing the NSs and RSs the RS in parallel ensures that the
   procedure does not run slower than it would if it only used an RS.

   NOTE: A Simple DNA implementation MUST limit its probing to at most
   six previously seen routers

4.5.  Contents of the Neighbor Discovery messages

4.5.1.  Neighbor Solicitation messages

   This section describes the contents of the neighbor solicitation
   probe messages sent during the probing procedure.

   Source Address:           A link-local address assigned to the
                             probing host.

   Destination Address:      The link-local address of the router being
                             probed as learnt from the SDAT.

   Hop Limit:                255

   ND Options:

   Target Address:           The link-local address of the router being
                             probed as learnt from the SDAT.

   Link Layer Header:

   Destination Address:      The link-layer (MAC) address of the router
                             being probed as learnt from the SDAT.

   The probing node SHOULD include a Source link-layer address option in
   the probe messages if the address was obtained using DHCPv6 and the
   lease has not expired.  Otherwise the probing node SHOULD NOT include the Source link-layer address option
   in the probe messages.

4.5.2.  Router Solicitation messages

   This section describes the contents of the router solicitation probe
   message sent during the probing procedure.

   Source Address:           A link-local address assigned to the
                             probing host.

   Destination Address:      The all-routers multicast address.

   Hop Limit:                255

   The probing node SHOULD NOT include the Source link-layer address
   option in the probe messages.

4.6.  DHCPv6 operation

   Simple DNA does not require a host to implement DHCPv6, nor does it
   imply any changes to the DHCPv6 protocol or state machine.  Hosts MAY
   attempt to obtain IPv6 configuration via DHCPv6 in parallel with
   simple DNA probing.  This ensures that the simple DNA procedure will
   not result in additional delay in the case where reachability tests
   fail, or where a DHCPv6 exchange completes more quickly than the
   reachability tests.

   In situations where both simple DNA and DHCPv6 are used on the same
   link, it is possible that simple DNA probing will complete
   successfully, and then DHCPv6 will complete later with a different
   result.  If this happens, the procedure described in Section 4.7.1
   are utilized.

   Where the

   The host attempts to obtain IPv6 configuration verify its DHCPv6-obtained information in
   parallel with simple DNA, on DNA.  On receiving a link-layer "up" indication, it sends a
   DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers.  This message
   contains an Identity Association for either a Temporary Address
   (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315].  Where an
   existing valid address is being tested for operability, this address
   should be placed in the Identity Association's IAADDR element, and
   the DUID associated with that address should be copied to the DHCP
   SOLICIT from the SDAT.

   In order to quickly acquire a new address in the case that link
   change has occurred, this SOLICIT message MAY contain the Rapid-
   Commit option.

   Where the Rapid-Commit option has not been used, a present DHCP
   server will respond with an ADVERTISE message.  The IP address
   contained in the Identity Association (IA_TA or IA_NA) will contain
   an IP Address which is operable for the link.

   Where Rapid-Commit option has been sent, a DHCPv6 server link-layer "up" indication,
   it will respond
   with REPLY.  In addition to being operable, this address is allocated initiate a DHCPv6 exchange as specified in [RFC3315] in order
   to verify whether the host for the lease duration indicated in addresses and configuration obtained using
   DHCPv6 are still usable on the Identity
   Association. link.

4.7.  Response Gathering

   When a responding Neighbor Advertisement is received from a test
   node, the host MUST verify that both the IPv6 and link layer (MAC)
   addresses of the test node match the expected values before utilizing
   the configuration associated with the detected network (prefixes, MTU
   etc.).

   On reception of a Router Advertisement or advertising DHCPv6 message
   (a REPLY or ADVERTISE) which that contains prefixes that
   intersect with those previously advertised by a known router, the
   host utilizes the configuration associated with the detected network.

   When

   If the host receives an a router advertisement from a router containing
   only prefixes
   which that are disjoint from known advertised prefixes, the host MUST
   determine whether prefixes associated with the solicited advertisement corresponds to any of
   same router in the routers probed via NS.  If it does, SDAT, then the host SHOULD MUST conclude that the IPv6
   addresses corresponding to that router are no longer valid.  Since
   any NS probes to that router will no longer provide useful
   information, further probing of that router SHOULD MUST be aborted.
   Furthermore, the host MUST remove all the SDAT entries corresponding
   to this router.

   Where the conclusions obtained from the Neighbor Solicitation/
   Advertisement from a given router and the RS/RA exchange with the
   same router differ, the results obtained from the RS/RA will be
   considered definitive.  In case the Neighbor Advertisement was
   secured using SEND and the Router Advertisement was not, the host
   MUST wait for SEND_NA_GRACE_TIME to see if a SEND-secured RA is
   received.  If a SEND-secured RA is not received, the conclusions
   obtained from the NS/NA exchange will be considered definitive.

   When the host receives a Router Advertisement in reply to the Router
   Solicitation it sent, from a given router,
   the host SHOULD MUST look for a Neighbor Cache entry for the sending router
   and SHOULD MUST mark that router's Neighbor Cache Entry as REACHABLE if one
   was found.  The host SHOULD MUST add a new Neighbor Cache Entry in the
   REACHABLE state for the sending router if one does not currently
   exist.

4.7.1.  Conflicting results

   It is possible that the DHCPv6 exchanges and the neighbor discovery
   based probes complete with conflicting results.  In this case, the
   host SHOULD use the following rules to determine the final result.

   o  If the DHCPv6 exchange was authenticated, use the result from
      DHCPv6.

   o  If the DHCPv6 exchange was not authenticated and the neighbor
      discovery exchange was protected by SEND [RFC3971], use the result
      from the neighbor discovery probe.

   o  If both the DHCPv6 and neighbor discovery exchanges were not
      authenticated, use the result from DHCPv6.

   In situations where Neighbor Solicitation probes and Router
   Solicitation probes are used on the same link, it is possible that
   the NS probe will complete successfully, and then the RS probe will
   complete later with a different result.  If this happens, the
   implementation SHOULD abandon the results obtained from the NS probe
   of the router that responded to the RS and the implementation SHOULD
   behave as if the NS probe did not successfully complete.  If the
   confirmed address was assigned manually, the implementation SHOULD
   NOT unconfigure the manually assigned address and SHOULD log an error
   about the mismatching prefix.

4.8.  Further Host Operations

   Operations subsequent to detecting network attachment depend upon
   whether change was detected.

   After confirming the reachability of the associated router using an
   NS/NA pair, the host performs the following steps.

   o  The host SHOULD rejoin any solicited nodes' multicast groups for
      addresses it continues to use.

   o  The host SHOULD select a default router as described in Section
      6.3.6 of [RFC4861].

   If the host has determined that there has been no link change, it
   SHOULD NOT perform duplicate address detection on the addresses that
   have been confirmed to be operable.

   If the NS based probe with a router did not complete or if the RS
   based probe on the same router completed with different prefixes than
   the ones in the SDAT the host MUST unconfigure all the existing
   addresses received from the given router, and MUST begin address configuration
   techniques, as indicated in the a received Router Advertisement
   [RFC4861][RFC4862].

4.9.  Recommended retransmission behavior

   Where the NS probe does not complete successfully, it usually implies
   that the host is not attached to the network whose configuration is
   being tested.  In such circumstances, there is typically little value
   in aggressively retransmitting unicast neighbor solicitations that do
   not elicit a response.

   Where unicast Neighbor Solicitations and Router Solicitations are
   sent in parallel, one strategy is to forsake retransmission of
   Neighbor Solicitations and to allow retransmission only of Router
   Solicitations or DHCPv6.  In order to reduce competition between
   unicast Neighbor Solicitations and Router Solicitations and DHCPv6
   retransmissions, a DNAv6 implementation that retransmits may utilize
   the retransmission strategy described in the DHCPv6 specification
   [RFC3315], scheduling DNAv6 retransmissions between Router
   Solicitation
   Solicitations or DHCPv6 retransmissions.

   If a response is received to any unicast Neighbor Solicitation,
   Router Solicitation or DHCPv6 message, pending retransmissions MUST
   be canceled [RFC3315][RFC3736].  A Simple DNA implementation SHOULD
   NOT retransmit a Neighbor Solicitation more than twice.  To provide
   damping in the case of spurious Link Up indications, the host SHOULD
   NOT perform the Simple DNA procedure more than once a second.

5.  Pseudocode for Simple DNA

       /* Link up indication received on INTERFACE */
       /* Start Simple DNA process */

       /* Mark All Addresses as deprecated */
       Configured_Address_List=Get_Address_List(INTERFACE);
       foreach Configured_Address in Configured_Address_List
       {
         if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
         {
           Set_Address_State(Configured_Address,AS_DEPRECATED);
         }
       }

       /* Mark all routers' NC entries as STALE to speed up */
       /* acquisition of new router if link change has occurred */
       foreach Router_Address in DEFAULT_ROUTER_LIST
       {
         NCEntry=Get_Neighbor_Cache_Entry(Router_Address);
         Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE);
       }

       /* Thread A : Send Router Solicitation */
       RS_Target_Address=FF02::2;
       RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
       Send_Router_Solicitation(RS_Source_Address,RS_Target_Address);

       /* Thread B : Send Neighbor Solicitation(s) */
       Previously_Known_Router_List=Get_Router_List_from_SDAT();
       NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);

       foreach Router_Address in Previously_Known_Router_List
       {
         if (Get_Any_Valid_Address_from_SDAT(Router_Address))
         {
           Send_Neighbor_Solicitation(NS_Source_Address,Router_Address);
         }
       }

       /* Thread C : Response collection */

       /* Received Router Advertisement processing */
       /* Only for RAs received as response to DNA RSs */

       L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
       L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
       SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
       foreach SDAT_Entry in SDAT_Entry_List
       {
         if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry)))
         {
           /* Address is operable. Configure on Interface */
           /* Rejoin solicited-node multicast group for address */
         }
         else
         {
           /* If address is configured on interface, remove it */
           /* This could be because of a NA arriving before RA */
         }
       }

       /* Mark router as reachable */
       NCEntry=Get_Neighbor_Cache_Entry(L3_Source);
       if (NCEntry is not NULL)
       {
         Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE);
       }
       else
       {
         Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE);
       }

       /* Ignore further NAs from this router */
       Add_Router_to_NA_Ignore_List(L3_Source);

       /* Received Neighbor Advertisement processing */
       /* Only for NAs received as response to DNA NSs */

       L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
       L2_Source=Get_L2_Source(RECEIVED_MESSAGE);

       if (Is_Router_on_NA_Ignore_List(L3_Source)) {
         /* Ignore message and wait for next message */
         continue;
       }

       SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));

       foreach SDAT_Entry in SDAT_Entry_List
       {
           /* Address is operable. Configure on Interface */
       }

                    Figure 1: Pseudocode for Simple DNA

   NOTE: This section does not include any pseudo-code for sending of
   the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the
   simple DNA process.

6.  Constants

      SEND_NA_GRACE_TIME

         Definition: An optional period to wait after Neighbor
         Solicitation before adopting a non-SEND RA's link change
         information.

         Value: 40 milliseconds

7.  Relationship to DNAv4

   DNAv4 [RFC4436] specifies a set of steps that optimize the (common)
   case of re-attachment to an IPv4 network that one has been connected
   to previously by attempting to re-use a previous (but still valid)
   configuration.  This document shares the same goal as DNAv4 (that of
   minimizing the handover latency in moving between points of
   attachment) but differs in the steps it performs to achieve this
   goal.  Another difference is that this document also supports
   stateless autoconfiguration of addresses in addition to addresses
   configured using DHCPv6.

8.  IANA Considerations

   There are no changes to IANA registries required in this document.

9.  Security Considerations

   A host may receive Router Advertisements from non-SEND devices, after
   receiving a link-layer indications.  While it is necessary to assess
   quickly whether a host has moved to another network, it is important
   that the host's current secured SEND [RFC3971] router information is
   not replaced by an attacker which spoofs an RA and purports to change
   the link.

   As such, the host SHOULD send a Neighbor Solicitation to the existing
   SEND router upon link-up indication as described above in
   Section 4.3.  The host SHOULD then ensure that unsecured router
   information does not cause deletion of existing SEND state, within
   MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to
   respond.

   If the current default router is a SEND-secured router, the host
   SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a
   new default router.

   Even if SEND signatures on RAs are used, it may not be immediately
   clear if the router is authorized to make such advertisements.  As
   such, a host SHOULD NOT treat such devices as secure until and unless
   authorization delegation discovery is successful.

   Unless SEND or other form of secure address configuration is used,
   the DNA procedure does not in itself provide positive, secure
   authentication of the router(s) on the network, or authentication of
   the network itself, as e.g. would be provided by mutual
   authentication at the link layer.  Therefore when such assurance is
   not available, the host MUST NOT make any security-sensitive
   decisions based on the DNA procedure alone.  In particular, it MUST
   NOT decide that it has moved from an untrusted to a trusted network,
   and MUST NOT make any security decisions that depend on the
   determination that such a transition has occurred.

10.  Acknowledgments

   This document is the product of a discussion the authors had with
   Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF
   69.  The authors would like to thank them for clearly detailing the
   requirements of the solution and the goals it needed to meet and for
   helping to explore the solution space.  The authors would like to
   thank the authors and editors of the complete DNA specification for
   detailing the overall problem space and solutions.  The authors would
   like to thank Jari Arkko for driving the evolution of a simple and
   probabilistic DNA solution.  The authors would like to thank Bernard
   Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier,
   Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes and Hoenes, Frederic Rossi Rossi, Ralph
   Droms, Ted Lemon, Erik Nordmark, Lars Eggert, Brian Carpenter and
   Yaron Sheffer for performing reviews on the document and providing
   valuable comments to drive the document forward.

11.  References

11.1.  Normative References

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

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

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

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

11.2.  Informative References

   [I-D.ietf-dna-protocol]
              Narayanan, S., "Detecting Network Attachment in IPv6
              Networks (DNAv6)", draft-ietf-dna-protocol (work in
              progress), June 2007.

   [RFC4957]  Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
              and A. Yegin, "Link-Layer Event Notifications for
              Detecting Network Attachments", RFC 4957, August 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4436]  Aboba, B., Carlson, J., and S. Cheshire, "Detecting
              Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.

Appendix A.  Issues with confirming manually assigned addresses

   Even though DNAv4 [RFC4436] supports verification of manually
   assigned addresses this feature of DNAv4 has not been widely
   implemented or used.  There are two major issues that come up with
   confirming manually assigned addresses using Simple DNA.

   o  When DHCPv6 or SLAAC addresses are used for probing, there is no
      need to aggressively retransmit lost probes.  This is because the
      address configuration falls back to vanilla DHCPv6 or SLAAC and
      the host will eventually obtain an address.  This is not the case
      with manually assigned addresses.  If the probes are lost, the
      host runs the risk of ending up with no addresses at all.  Hence
      agressive retransmissions are necessary.

   o  Another issue comes up when the host moves between two networks,
      one where manual addressing is being used (say NET1)and the other
      where dynamic addressing (stateless autoconfig or DHCPv6) is being
      used (say NET2).  Since the host can obtain a dynamic address in
      some situations, it will need to send simple DNA probes and may
      also engage in a DHCPv6 exchange.  In a situation where the host
      moves to NET1 and the NS probes are lost and in addition an RA is
      not received, the host will not be able to confirm that it
      attached to NET1, and therefore that it should use the manual
      configuration for that network.  As a result, if DHCPv6 is enabled
      on NET1, then the host could mistakenly obtain a dynamic address
      and configuration instead of using the manual configuration.  To
      prevent this problem, simple DNA probing needs to continue even
      after the DHCPv6 exchange has completed, and DNA probes need to
      take precedence over DHCPv6, contrary to the advice provided in
      Section 4.7.1

   Given these issues, it is NOT RECOMMENDED to use manual addressing
   with Simple DNA.

Authors' Addresses

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com

   Greg Daley
   NetStar Networks
   Level 9/636 St Kilda Rd
   Melbourne, Victoria  3004
   Australia

   Phone: +61 3 8532 4042
   Email: gdaley@netstarnetworks.com