Network Working Group                                        S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                G. Daley
Expires: May 10, 2008                                   NetStar Networks
                                                        November 7, 2007

       Simple procedures for Detecting Network Attachment in IPv6

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


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

   This document provides simple procedures for detecting network
   attachment in IPv6 hosts, and procedures for routers to support such

Krishnan & Daley          Expires May 10, 2008                  [Page 1]

Internet-Draft         Simple procedures for DNAv6         November 2007

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.  Link-Layer Indication  . . . . . . . . . . . . . . . . . .  5
     3.2.  Optimistic DAD . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Router Solicitation  . . . . . . . . . . . . . . . . . . .  5
     3.4.  Neighbour Solicitation . . . . . . . . . . . . . . . . . .  5
     3.5.  Response Gathering . . . . . . . . . . . . . . . . . . . .  6
     3.6.  Further Host Operations  . . . . . . . . . . . . . . . . .  7
       3.6.1.  Actions upon return to a link  . . . . . . . . . . . .  7
       3.6.2.  Actions upon arrival at a new link . . . . . . . . . .  7
   4.  Router Operations  . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Tentative Option Processing  . . . . . . . . . . . . . . .  7
     4.2.  Fast Unicast Response to Router Solicitation . . . . . . .  8
       4.2.1.  Fast Router Advertisement Transmission . . . . . . . .  8
     4.3.  Additional Router Procedures . . . . . . . . . . . . . . .  8
   5.  Constants  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Remaining Issues . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Krishnan & Daley          Expires May 10, 2008                  [Page 2]

Internet-Draft         Simple procedures for DNAv6         November 2007

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 feedback received mentioned that the complete dna protocol, as it
   exists, is too complex to implement.  As a reaction, some OS vendors
   started shipping their own version of DNAv6 (it is pretty much a
   version of DNAv4 adapted to IPv6).  The implementers who brought up
   the complexity concerns, identified the following issues with the
   complete dna proposal as the main obstacles to deployment

   o  Router changes are NECESSARY

   o  Handling of corner cases adds complexity to most likely use cases

   o  Some of the DNA Goals are not really necessary/useful

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.

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

   The host detects that the link-layer may have changed, and then
   probes the network with Router Solicitations (RSs) and Neighbour

Krishnan & Daley          Expires May 10, 2008                  [Page 3]

Internet-Draft         Simple procedures for DNAv6         November 2007

   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  All the prefixes advertised on the link need to fit into a single
      RA.  This implies that the number of prefixes on the link needs to
      be limited. e.g. 15 prefixes per link.  If all the prefixes on the
      link do not fit into a single RA, the prefixes that are left out
      of the first RA will be advertised in another RA.  A host
      receiving such an RA from another router on the link will
      incorrectly assume that it has changed links.

   o  All routers on the link advertise the same subnet prefixes.

   o  The number of advertising routers on the link needs to be limited
      to the number defined in MAX_ROUTERS_FOR_SIMPLE_DNA.

   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 undertakes detecting network

Krishnan & Daley          Expires May 10, 2008                  [Page 4]

Internet-Draft         Simple procedures for DNAv6         November 2007

   The steps involved in basic detection of network attachment are:

   o  Link-Layer Indication

   o  Optimistic DAD

   o  Router Solicitation

   o  Neighbour Solicitations to prior router(s)

   o  Response gathering and assessment

   These steps are described below.

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

3.3.  Router Solicitation

   The primary mechanism used to detect network attachment in IPv6 is
   router solicitation and advertisement.  When a host receives a link-
   layer indication, it SHOULD immediately send a Router Solicitation to
   the All-routers address containing one of the host's optimistic
   unicast source address [2][5].

3.4.  Neighbour Solicitation

   The host will have configuration for addresses configured from
   prefixes advertised on one or more routers.

   In order to gain a quick confirmation that a host has returned to one
   of the links associated with these existing prefixes, the host can

Krishnan & Daley          Expires May 10, 2008                  [Page 5]

Internet-Draft         Simple procedures for DNAv6         November 2007

   send Neighbour Solicitations.

   The host may select one of its configured next hop routers from each
   of zero, one or two previously connected links, and send a unicast
   Neighbour Solicitation to each of these [2][5].  If the addresses
   obtained from a previous router are no longer valid, the host SHOULD
   NOT send a Neighbour Solicitation to that router.

   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

   The Simple IPv6 DNA assessment on the host relies upon tying
   advertised prefixes to the advertising routers.  Reception of an
   advertisement from a router which is known to advertise a prefix can
   be used to indicate that the node has reconnected to a link it was
   previously connected to.

   Where a responding Neighbour Advertisement is received from a
   previously configured router, the host MUST verify if the hardware
   address of the router matches the one that was previously known.  If
   it does, the host can decide that it hasn't changed networks, and MAY
   continue to use the link configuration information (prefixes, MTU
   etc.) with high probability.

   Reception of a Router Advertisement which contains prefixes which
   intersect with those previously advertised by a known router
   indicates that the host has returned to that link with high
   likelihood.In this case the host can decide that it hasn't changed
   networks, and MAY continue to use the existing prefixes with high

   Additionally, where a host receives a solicited router advertisement
   after sending an RS for the purpose of detecting network attachment,
   and this prefix contains only prefixes which are disjoint from known
   advertised prefixes, the host SHOULD conclude with high probability
   that it has moved to a different link.

Krishnan & Daley          Expires May 10, 2008                  [Page 6]

Internet-Draft         Simple procedures for DNAv6         November 2007

3.6.  Further Host Operations

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

3.6.1.  Actions upon return to a link

   Upon arrival at a previously visited link, 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].

3.6.2.  Actions upon arrival at a new link

   Upon arrival on a new link, the host should unconfigure its existing
   addresses and routers, and begin address configuration techniques, as
   indicated in the received Router Advertisement [2][8].

   The host SHOULD keep information about prefixes advertised by routers
   from the prior link, for the purposes of subsequent change detection

4.  Router Operations

   Routers wishing to support host change detection need to provide them
   with quick responses to queries.  Basic support for DNA for IPv6
   requires two basic operations.

   These procedures allow for a host to receive immediate response to a
   router solicitation, and may simplify a host's internal change
   detection operations.

   The simple IPv6 DNA router components are:

   1.  Tentative Option processing

   2.  Fast Unicast Response to Solicitation with Token Buckets

   These are described in the following sections.

4.1.  Tentative Option Processing

   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.

Krishnan & Daley          Expires May 10, 2008                  [Page 7]

Internet-Draft         Simple procedures for DNAv6         November 2007

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

4.2.  Fast Unicast Response to Router Solicitation

   In order to provide fast response to router solicitation the router
   removes the random delay before sending a unicast response to a
   Router Solicitation.

4.2.1.  Fast Router Advertisement Transmission

   To control the rate at which Router Advertisements are sent, the
   router maintains a token bucket per-interface, whereby fast RAs are
   only transmitted when a token is available [6].

   The bucket receives a token every UNICAST_RA_INTERVAL, unless the
   bucket already contains MAX_UNICAST_RA_BURST tokens.

   When the router receives a Router Solicitation containing a unicast
   source address it SHOULD send a unicast router advertisement to the
   solicitor's address without delay if there are remaining tokens in
   the bucket.  Each such transmission consumes one token.

   When there are no remaining tokens, the router SHOULD send a
   solicited Router Advertisement, as described in RFC 4861 [2].

4.3.  Additional Router Procedures

   As described, the system used here may not be applicable to all
   environments.  Therefore the fast response advertisement mechanisms
   for simple IPv6 DNA MUST be configurable.  When disabled the host
   would revert to existing IPv6 Neighbour discovery behaviour [2].

5.  Constants

   These constants are described as in [6].


         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

Krishnan & Daley          Expires May 10, 2008                  [Page 8]

Internet-Draft         Simple procedures for DNAv6         November 2007

         Value: 50 milliseconds


         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


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

         Value: 40 milliseconds

6.  Remaining Issues

   These issues are still outstanding within the document, and the
   simple DNA solution in general.

      Identification of Fast advertising Simple DNA routers to other

         Other protocols attempt to desynchronize Router Advertisements
         while still allowing fast RA response [6].

         In an environment where it is safe to use Simple DNA, it may
         not be necessary to worry about sending RAs at the same time as
         other routers.

         In the case where this specification's Fast Advertisements
         cause problems due to contention with more sophisticated RA
         delivery schemes, it SHOULD be turned off as described in
         Section 4.3.

      Rate limitation for solicitations.

         In some circumstances, the rate of transmissions for
         solicitations may need to be restricted or limited.  This
         depends highly upon the movement pattern and quality of link-
         layer indications.  Hysteresis mechanisms which slow or prevent
         solicitation operations may be necessary to prevent damage to
         the local network environment.

Krishnan & Daley          Expires May 10, 2008                  [Page 9]

Internet-Draft         Simple procedures for DNAv6         November 2007

         Particularly, transmission of unicast solicitations may cause
         packet flooding across a bridged network if received on a
         network where the link-layer unicast destination is unknown.
         This shouldn't cause wireless link utilization, where base
         stations maintain state about attached subscribers.

         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
   environments may be better served using the procedures defined in

   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

   As such, the host SHOULD send a Neighbour Solicitation to the
   existing SEND router upon link-up indication as described above in
   Section 3.1.  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

   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.

Krishnan & Daley          Expires May 10, 2008                 [Page 10]

Internet-Draft         Simple procedures for DNAv6         November 2007

   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.

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

Krishnan & Daley          Expires May 10, 2008                 [Page 11]

Internet-Draft         Simple procedures for DNAv6         November 2007

        (DNAv6)", draft-ietf-dna-protocol (work in progress), June 2007.

10.2.  Informative References

   [7]  Yegin, A., "Link-layer Event Notifications for Detecting Network
        Attachments", draft-ietf-dna-link-information-03 (work in
        progress), October 2005.

   [8]  Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 4862, December 1998.

Authors' Addresses

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

   Phone: +1 514 345 7900 x42871

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

   Phone: +61 405 494849

Krishnan & Daley          Expires May 10, 2008                 [Page 12]

Internet-Draft         Simple procedures for DNAv6         November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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

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

   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


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

Krishnan & Daley          Expires May 10, 2008                 [Page 13]