Network Working Group                                        S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                G. Daley
Expires: August 28, 2008                                NetStar Networks
                                                       February 25, 2008


       Simple procedures for Detecting Network Attachment in IPv6
                      draft-krishnan-dna-simple-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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.



Krishnan & Daley         Expires August 28, 2008                [Page 1]


Internet-Draft         Simple procedures for DNAv6         February 2008


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  DNA Roles  . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Host Operations  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Host data structures . . . . . . . . . . . . . . . . . . .  5
     3.2.  Link-Layer Indication  . . . . . . . . . . . . . . . . . .  5
     3.3.  Optimistic DAD . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Sending RS and NS probes . . . . . . . . . . . . . . . . .  6
     3.5.  Response Gathering . . . . . . . . . . . . . . . . . . . .  6
     3.6.  Further Host Operations  . . . . . . . . . . . . . . . . .  7
     3.7.  Recommended retransmission behavior  . . . . . . . . . . .  7
   4.  Router Operations  . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 13


























Krishnan & Daley         Expires August 28, 2008                [Page 2]


Internet-Draft         Simple procedures for DNAv6         February 2008


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


2.  Introduction

   Hosts require procedures to simply and reliably identify if they have
   moved to a different IP network to the one which they have been
   recently connected.  In order to detect change, router and neighbour
   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.

   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  Handle only the simplest and most likely use cases.

   o  Work at least as quickly as standard neighbor discovery.

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

   o  False negatives are acceptable.  A host can conclude that there is
      a link change when there is none

2.1.  DNA Roles

   Detecting Network Attachment is performed by hosts by sending IPv6
   neighbour discovery and router discovery messages to routers after
   connecting to a network.

   It is desirable that routers adopt procedures which allow for fast
   unicast Router Advertisement (RA) messages.  Routers that follow the
   standard neighbor discovery procedure described in [2] 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 [2].  This delay can be significant and may result in service



Krishnan & Daley         Expires August 28, 2008                [Page 3]


Internet-Draft         Simple procedures for DNAv6         February 2008


   disruption.  Please note that support for fast unicast RAs is not
   necessary since the simple dna procedure can continue to work using
   the NS/NA exchange, which will complete earlier than the RA arrives.

   The host detects that the link-layer may have changed, and then
   simultaneously probes the network with Router Solicitations (RSs) and
   Neighbour Solicitations (NSs).  The host uses advertisements to
   determine if the routers it currently has configured are still
   available.

2.2.  Applicability

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

   If systems do not meet these assumptions or if systems seek
   deterministic change detection operations they are directed to follow
   the complete dna procedure as defined in [6].


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






Krishnan & Daley         Expires August 28, 2008                [Page 4]


Internet-Draft         Simple procedures for DNAv6         February 2008


3.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).  Each entry in the SDAT table
   consists of at least the following parameters

   o  IPv6 address and its related parameters like valid lifetime

   o  Prefix from which the address was formed

   o  Link local IPv6 address of the router that advertised the prefix

   o  Link layer (MAC) address of the router that advertised the prefix

   o  DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire
      the address

   The steps involved in basic detection of network attachment are:

   o  Link-Layer Indication

   o  Optimistic DAD

   o  Sending RS and NS probes

   o  Response gathering and assessment

   These steps are described below.

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

   When the indication is received, the host marks all currently
   configured (non-tentative) IP addresses to Optimistic state [5].

3.3.  Optimistic DAD

   All Router Solicitations and unicast Neighbour Solicitations sent for
   DNA purposes while addresses are in optimistic state SHOULD include
   the Tentative Option [4].

   This allows for DAD-safe transmission of unicast response to
   solicitation, even if the router has no existing Neighbour Cache
   entry for the solicitor.



Krishnan & Daley         Expires August 28, 2008                [Page 5]


Internet-Draft         Simple procedures for DNAv6         February 2008


3.4.  Sending RS and NS probes

   When a host receives a link-layer "up" indication, it SHOULD
   immediately send both a Router Solicitation 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 containing one of the host's optimistic unicast
   source address [2][5].  If the host is in possession of more than one
   valid IPv6 address, it MUST send only one router solicitation using
   any one of its valid IPv6 addresses as the source address..

   For the purpose of sending neighbor solicitations to previous
   routers, the host first needs to pick a subset of operable IPv6
   addresses (candidate set) that it wishes to use.  How this subset of
   addresses is picked is based on host configuration. e.g.  The host
   may select configured addresses from each of zero, one or two
   previously connected links.  If the addresses obtained from a
   previous router are no longer valid, the host does 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 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 NOT send
   unicast Neighbor Solicitations to a test node corresponding to an
   IPv6 address that is no longer valid.

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

   Be aware that each unicast solicitation which is not successful may
   cause packet flooding in bridged networks, if the networks are not
   properly configured.  This is further described in Section 6.  Where
   flooding may cause performance issues within the LAN, host SHOULD
   limit the number of unicast solicitations.

3.5.  Response Gathering

   When a responding Neighbour 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 which contains prefixes which



Krishnan & Daley         Expires August 28, 2008                [Page 6]


Internet-Draft         Simple procedures for DNAv6         February 2008


   intersect with those previously advertised by a known router, the
   host utilizes the configuration associated with the detected network.

   When the host receives a router advertisement containing only
   prefixes which are disjoint from known advertised prefixes, the host
   MUST determine whether the solicited router advertisement corresponds
   to any of the routers probed via NS.  If it does, then the host
   SHOULD 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, probing of that router SHOULD be
   aborted.

   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.

3.6.  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 should assess whether it can use the existing
   configured addresses using Optimistic Duplicate Address Detection
   [5].

   Also, the host SHOULD rejoin any solicited nodes' multicast groups
   for addresses it continues to use, and select a default router [2].

   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 received Router
   Advertisement [2] [8] .

3.7.  Recommended retransmission behavior

   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



Krishnan & Daley         Expires August 28, 2008                [Page 7]


Internet-Draft         Simple procedures for DNAv6         February 2008


   about the mismatching prefix.

   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
   [RFCDHCPv6], scheduling DNAv6 retransmissions between Router
   Solicitation or DHCPv6 retransmissions.

   If a response is received to any unicast Neighbor Solicitation,
   Router Solicitation or DHCPv6 message, pending retransmissions MUST
   be canceled.  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
   the Simple DNA procedure more than once a second.


4.  Router Operations

   Hosts checking their network attachment are unsure of their address
   status, and may be using Tentative link-layer addressing information
   in their router or neighbour solicitations.

   A router which desires to support hosts' DNA operations MUST process
   Tentative Options from unicast source addressed Router and Neighbour
   Solicitations, as described in [4] .


5.  Constants

   These constants are described as in [6].

      UNICAST_RA_INTERVAL

         Definition: The interval corresponding to the maximum average
         rate of Router Solicitations that the router is prepared to
         service with unicast responses.  This is the interval at which
         the token bucket controlling the unicast responses is
         replenished.



Krishnan & Daley         Expires August 28, 2008                [Page 8]


Internet-Draft         Simple procedures for DNAv6         February 2008


         Value: 50 milliseconds

      MAX_UNICAST_RA_BURST

         Definition: The maximum size burst of Router Solicitations that
         the router is prepared to service with unicast responses.  This
         is the maximum number of tokens allowed in the token bucket
         controlling the unicast responses.

         Value: 20

      SEND_NA_GRACE_TIME

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

         Value: 40 milliseconds


6.  Open Issues

   This section documents issues that are still outstanding within the
   document, and the simple DNA solution in general.

      Rate limitation for solicitations.

      Hosts MAY implement hysteresis mechanisms to pace solicitations
      where necessary to prevent damage to a particular medium.
      Implementors should be aware that when such hysteresis is
      triggered, Detecting Network Attachment may be slowed, which may
      affect application traffic.


7.  IANA Considerations

   There are no changes to IANA registries required in this document


8.  Security Considerations

   When providing fast responses to router solicitations, it is possible
   to cause collisions with other signaling packets on contention based
   media.  This can cause repeated packet loss or delay when multiple
   routers are present on the link.

   As such the fast router advertisement system is NOT RECOMMENDED in
   this form for media which are susceptible to collision loss.  Such



Krishnan & Daley         Expires August 28, 2008                [Page 9]


Internet-Draft         Simple procedures for DNAv6         February 2008


   environments may be better served using the procedures defined in
   [6].

   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 [3] 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 Neighbour Solicitation to the
   existing SEND router upon link-up indication as described above in
   Section 3.2.  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.

   The host MAY delay SEND_NA_GRACE_TIME after transmission before
   adopting a new default router, if it is operating on a network where
   there is significant threat of RA spoofing.

   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.

   It is easy for hosts soliciting without SEND to deplete a SEND
   router's fast advertisement token buckets, and consume additional
   bandwidth.  As such, a router MAY choose to preserve a portion of
   their token bucket to serve solicitations with SEND signatures.


9.  Acknowledgments

   This document is the product of a discussion between 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, Sathya Narayan and Frederic Rossi for
   performing reviews on the document and providing valuable comments to
   drive the document forward.





Krishnan & Daley         Expires August 28, 2008               [Page 10]


Internet-Draft         Simple procedures for DNAv6         February 2008


10.  References

10.1.  Normative References

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

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

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

   [4]  Daley, G., Nordmark, E., and N. Moore, "Tentative Options for
        IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 (work in
        progress), July 2007.

   [5]  Moore, N., "Optimistic Duplicate Address Detection for IPv6",
        RFC RFC4429, April 2006.

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

10.2.  Informative References

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

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


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








Krishnan & Daley         Expires August 28, 2008               [Page 11]


Internet-Draft         Simple procedures for DNAv6         February 2008


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

   Phone: +61 405 494849
   Email: gdaley@netstarnetworks.com











































Krishnan & Daley         Expires August 28, 2008               [Page 12]


Internet-Draft         Simple procedures for DNAv6         February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Krishnan & Daley         Expires August 28, 2008               [Page 13]