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

Versions: 00 01                                                         
DNA Working Group                                           S. Narayanan
Internet-Draft                                                 Panasonic
Expires: November 4, 2005                                    E. Nordmark
                                                        Sun Microsystems
                                                             B. Pentland
                                                  Monash University CTIE
                                                             May 3, 2005


         Detecting Network Attachment in IPv6 Networks (DNAv6)
                   draft-pentland-dna-protocol-00.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on November 4, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Efficient detection of network attachment in IPv6 needs the following
   two components: a method for the host to query routers on the link to
   identify the link (Link Identification) and a method for the routers
   on the link to consistently respond to such a query with minimal
   delay (Fast RA).  Solving the link identification based strictly on



Narayanan, et al.       Expires November 4, 2005                [Page 1]


Internet-Draft                    DNAv6                         May 2005


   RFC 2461 is difficult because of the flexibilities offered to routers
   in terms of prefixes advertised in a router advertisement (RA)
   message.  Similarly, the random delay in responding to router
   solicitation messages imposed by RFC 2461 makes to it difficult to
   achive fast RA.  A known set of solutions to these two problems were
   identified and catalogued by the DNA design team.  In this memo, an
   integrated solution is presented, based on a sub-set of the
   catalogued solutions.  This integrated solution consolidates most of
   the advantages of all known solutions while addressing most of the
   disadvantages.









































Narayanan, et al.       Expires November 4, 2005                [Page 2]


Internet-Draft                    DNAv6                         May 2005


Table of Contents

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

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

   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   What Identifies a Link?  . . . . . . . . . . . . . . . . .  6
     3.2   Link Identification  . . . . . . . . . . . . . . . . . . .  6
     3.3   Fast Router Advertisment . . . . . . . . . . . . . . . . .  7

   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1   Router Advertisement . . . . . . . . . . . . . . . . . . .  8
     4.2   Landmark Option  . . . . . . . . . . . . . . . . . . . . .  9
     4.3   DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10

   5.  DNA Operation  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1   DNA Router Operation . . . . . . . . . . . . . . . . . . . 11
       5.1.1   Data Structures  . . . . . . . . . . . . . . . . . . . 11
       5.1.2   Router Configuration Variables . . . . . . . . . . . . 12
       5.1.3   Bootstrapping DNA Data Structures  . . . . . . . . . . 13
       5.1.4   Processing Router Advertisements . . . . . . . . . . . 13
       5.1.5   Processing Router Solicitations  . . . . . . . . . . . 13
       5.1.6   Complete Router Advertisements . . . . . . . . . . . . 15
       5.1.7   Scheduling Fast Router Advertisements  . . . . . . . . 15
       5.1.8   Scheduling Unsolicited Router Advertisements . . . . . 16
     5.2   DNA Host Operation . . . . . . . . . . . . . . . . . . . . 16
       5.2.1   Data Structures  . . . . . . . . . . . . . . . . . . . 16
       5.2.2   Selection of a Landmark Prefix . . . . . . . . . . . . 17
       5.2.3   Sending Router Solicitations . . . . . . . . . . . . . 17
       5.2.4   Processing Router Advertisements . . . . . . . . . . . 17

   6.  Backward Compatability . . . . . . . . . . . . . . . . . . . . 18
     6.1   Non DNA Host with DNA Routers  . . . . . . . . . . . . . . 18
     6.2   DNA Host with Non-DNA Routers  . . . . . . . . . . . . . . 18

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     7.1   Amplification Effect . . . . . . . . . . . . . . . . . . . 19
     7.2   Attacks on the Token Bucket  . . . . . . . . . . . . . . . 19
     7.3   Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 20

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20

   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 20

   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 21

   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 22



Narayanan, et al.       Expires November 4, 2005                [Page 3]


Internet-Draft                    DNAv6                         May 2005


     11.1  Normative References . . . . . . . . . . . . . . . . . . . 22
     11.2  Informative References . . . . . . . . . . . . . . . . . . 22

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23

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

       Intellectual Property and Copyright Statements . . . . . . . . 25











































Narayanan, et al.       Expires November 4, 2005                [Page 4]


Internet-Draft                    DNAv6                         May 2005


1.  Introduction

   The proposed scheme in this memo is built upon the following
   solutions catalogued in [12]: Complete RA and Requested Landmark are
   used for the link identification, and Hash-based Fast RA is used to
   achieve fast response to RS messages.  The reasoning behind these
   choices will become evident as the whole scheme and its advantages
   are understood.

2.  Terms and Abbreviations

   There is an existing DNA terminology draft [9].  This draft does not
   introduce any new terminology not already used by existing drafts.

   The term "link" is used as defined in RFC 2460 [2].  NOTE: this is
   completely different from the term "link" as used by IEEE 802, etc.

3.  Overview

   The DNA protocol presented in this document tries to achieve the
   following objectives:

   o  Eliminate the delays introduced by RFC 2461 in discovering the
      configuration

   o  Make it possible for the hosts to accurately detect the identity
      of their current link from a single RA

   o  Keep the packets relatively small in size.

   The approach described in this memo is based on the combination of
   Requested Landmark and CompleteRA for link identification and the
   hash-based Fast RA mechanism.  The rest of the document refers to
   this approach by the term "DNAv6".

   DNAv6 assumes that the host's wireless link interface software and
   hardware is capable of delivering a 'link up' event notification when
   layer 2 on the host is configured and sufficiently stable for IP
   traffic.  This event notification acts as a hint to the layer 3 DNA
   procedures to check whether or not the host is attached to the same
   link as before.  DNAv6 also assumes that an interface on the host is
   never connected to two links at the same time.  In the case that the
   layer 2 technology is capable of having multiple attachments (for
   instance, multiple layer 2 associations or connections) at the same
   time, DNAv6 requires the individual layer-2 associations to be
   represented as separate (virtual interfaces) to layer 3 and DNAv6 in
   particular.




Narayanan, et al.       Expires November 4, 2005                [Page 5]


Internet-Draft                    DNAv6                         May 2005


3.1  What Identifies a Link?

   DNAv6 identifies a link by the set of prefixes that are assigned to
   the link, which is quite natural and doesn't require introducing any
   new form of identifier.  However, this choice implies that the
   protocol needs to be robust against changes in the set of prefixes
   assigned to a link, including the case when a link is renumbered and
   the prefix is later reassigned to a different link.  The protocol
   handles this quite well during graceful renumbering (when the valid
   lifetime of the prefix is allowed to decrease to zero before it is
   removed and perhaps reassigned to a different link), however, it can
   also cope with "flash" renumbering and reassignment but not in an
   optimized fashion.

3.2  Link Identification

   DNAv6 is based on using a Router Solicitation/Router Advertisement
   exchange to both verify whether the host has changed link, and if it
   has, provide the host with the configuration information for the new
   link.  This uses a technique called a "landmark", where the host
   chooses one of the prefixes as a landmark prefix, and then includes
   this in the Router Solicitation message in the form of a question "am
   I still connected to the link which has this prefix?".  The landmark
   is carried in a new option, called the Landmark Option.

   In the case when the host is still attached to the same link, which
   might occur when the host has changed from using one layer 2 access
   point to another, but the access points are on the same link, the
   Router Advertisement(s) it receives will contain a "yes, that prefix
   is on this link" answer, and no other information.  Thus, such RA
   messages are quite small.

   In the case when the landmark prefix is unknown to the responding
   router, the host will receive a "No" answer to its landmark question,
   and also the information it needs to configure itself for the new
   link.  The routers try to include as much information as possible in
   such messages, so that the host can be informed of all the prefixes
   assigned to the new link as soon as possible.

   The router advertisement messages are larger than the solicitations,
   and with multiple routers on the link there will be multiple
   advertisements sent for each solicitation.  This amplification can be
   used by an attacker to cause a Denial of Service attack.  Such
   attacks are limited by applying a rate limit on the unicast Router
   Advertisements sent directly in response to each solicitation, and
   using multicast RAs when the rate limit is exceeded.

   When the multicast method is used, there are no explicit answers to



Narayanan, et al.       Expires November 4, 2005                [Page 6]


Internet-Draft                    DNAv6                         May 2005


   the landmark questions, instead the router(s) include information so
   that the hosts themselves can answer their landmark questions.  This
   information consists of the prefixes a router would advertise itself
   as per RFC 2461, and also, the prefixes learned from other routers on
   the link that are not being advertised by itself.  These learned
   prefixes are included in a new DNA Option in the Router
   Advertisement.

   When the resulting multicast RA carries all the prefixes known to the
   router, the RA is marked as "complete" using a new bit in the
   message.  When a host receives a complete multicast RA, the host can
   easily decide whether it is attached to the same link or not from the
   single RA.  Thus, unlike CPL [11], the host does not have to wait for
   multiple advertisements before making a decision.

   In order for the routers be able to both respond to the landmark
   questions and send the complete RAs, the routers need to track the
   prefixes that other routers advertise on the link.  This process is
   initialized when a router is enabled, by sending a Router
   Solicitation and collecting the resulting RAs, and then multicasting
   a few RAs more rapidly as already suggested in RFC 2461.  This
   process ensures with high probability that all the routers have the
   same notion of the set of prefixes assigned to the link.

3.3  Fast Router Advertisment

   According to RFC 2461 a solicited Router Advertisement should have a
   random delay between 0 and 500 milliseconds, to avoid the
   advertisements from all the routers colliding on the link causing
   congestion and higher probability of packet loss.  In addition, RFC
   2461 suggests that the RAs be multicast, and multicast RAs are rate
   limited to one message every 3 seconds.  This implies that the
   response to a RS might be delayed up to 3.5 seconds.

   DNAv6 avoids this delay by using a different mechanism to ensure that
   two routers will not respond at exactly the same time while allowing
   one of the routers on the link to respond immediately.  Since the
   hosts might be likely to use the first responding router as the first
   choice from their default router list, the mechanism also ensures
   that the same router doesn't respond first to the RSs from different
   hosts.

   The mechanism is based on the routers on the link determining (from
   the same RAs that are used in section Section 3.1 to determine all
   the prefixes assigned to the link), the link-local addresses of all
   the other routers on the link.  With this loosely consistent list,
   each router can independently compute some function of the (link-
   local) source address of the RS and each of the routers' link-local



Narayanan, et al.       Expires November 4, 2005                [Page 7]


Internet-Draft                    DNAv6                         May 2005


   addresses.  The results of that function are then compared to create
   a ranking, and the ranking determines the delay each router will use
   when responding to the RS.  The router which is ranked as #0 will
   respond with a zero delay.

   If the routers become out-of-sync with respect to their learned
   router lists, two or more routers may respond with the same delay,
   but over time the routers will converge on their lists of learned
   routers on the link.

4.  Message Formats

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


4.1  Router Advertisement

   DNAv6 modifies the format of the Router Advertisement message by
   adding a flag bit to indicate that the router sending the message is
   participating in the DNAv6 protocol as well as a flag to indicate the
   completeness of the set of prefixes included in the Router
   Advertisement.  The new message format is as follows:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Cur Hop Limit |M|O|H|Pr |D|C|R|       Router Lifetime         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reachable Time                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Retrans Timer                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +   Options ...
    +-+-+-+-+-+-+-+-+-+-+-+-

   DNA (D)

      The DNA (D) bit indicates that the router sending the RA is
      participating in the DNAv6 protocol.  Other routers should include
      this router in calculating response delay tokens.







Narayanan, et al.       Expires November 4, 2005                [Page 8]


Internet-Draft                    DNAv6                         May 2005


   Complete (C)

      The Complete (C) bit indicates that the Router Advertisement
      contains PIOs for all prefixes explicitly configured on the
      sending router, and, if other routers on the link are advertising
      additional prefixes, a DNA Option containing all additional
      prefixes that the router has heard from other routers on the link.

   Reserved (R)

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


4.2  Landmark Option

   The Landmark Option is used by hosts in a Router Solicitation message
   to ask the routers on a link if the specified prefix is being
   advertised by some router on the link.  It is used by routers in a
   Router Advertisement to reply to a corresponding question in a Router
   Solicitation, indicating whether the prefix referred to is being
   advertised by any router on the link.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     | Pref Length   |Y|N|           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           +
    |                           Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                          Landmark Prefix                      ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBA

   Length

      8 bit unsigned integer indicating the length of the option in
      units of 8 octets.  Set to 2 or 3.

   Pref Length






Narayanan, et al.       Expires November 4, 2005                [Page 9]


Internet-Draft                    DNAv6                         May 2005


      An 8 bit unsigned integer representing the number of bits in the
      prefix to be used for matching.

   Yes (Y)

      The Yes (Y) bit, when included in a Landmark Option in a Router
      Advertisement, indicates that the prefix referred to in the Prefix
      field of this option is being advertised by one or more routers on
      the current link.  In a Landmark Option in a Router Solicitation,
      this bit MUST be set to zero and ignored by receivers.

   No (N)

      The No (N) bit, when included in a Landmark Option in a Router
      Advertisement, indicates that the prefix referred to in the Prefix
      field of this option is not being advertised by any router on the
      current link.  In a Landmark Option in a Router Solicitation, this
      bit MUST be set to zero and ignored by receivers.

   Reserved

      A 38 bit unused field.  It MUST be initialised to zero by the
      sender, and ignored by the receiver.

   Prefix

      A prefix being used by the host currently for a global IPv6
      address, padded at the right with zeros.  If the prefix length is
      less than 65 bits, only 64 bits need be included, otherwise 128
      bits are included.


4.3  DNA Option

   The DNA Option (DNAO) is used by a router to indicate prefixes that
   are being advertised in PIOs by other routers on the link, but not
   itself.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     | Learned Prefixes ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    ~                                                               ~
    |                                                ... Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Narayanan, et al.       Expires November 4, 2005               [Page 10]


Internet-Draft                    DNAv6                         May 2005


   Type

      TBA

   Length

      8 bit unsigned integer indicating the length of the option in
      units of 8 octets.

   Learned Prefixes

      Zero or more fields each consisting of an 8-bit prefix length
      followed by a 128-bit address representing a prefix that has been
      heard on the link but is not explicitly configured on this router.

   Padding

      Zero padding to make the option an integer multiple of 8 octets.

   Description

      This option MUST only be included in a Router Advertisement.  This
      option contains prefixes that are being advertised on the link but
      are not explicitly configured on the sending router.  The router
      MUST NOT include any prefixes with a zero valid lifetime in the
      DNAO.

      NOTE: Some discussion is needed on the best format for this
      option.


5.  DNA Operation

5.1  DNA Router Operation

   Routers MUST collect information about the other routers that are
   advertising on the link.

5.1.1  Data Structures

   The routers maintain a set of conceptual data structures for each
   interface to track the prefixes advertised by other routers on the
   link, and also the set of DNA routers (the routers that will quickly
   respond to RAs) on the link.  For each interface, routers maintain a
   list of all prefixes advertised on the link.  The list will be
   referred to in this document as "DNAPrefixList".  For each prefix the
   router MUST store the following information:




Narayanan, et al.       Expires November 4, 2005               [Page 11]


Internet-Draft                    DNAv6                         May 2005


   1.  Prefix

   2.  Prefix length

   3.  Valid lifetime

   4.  Time last refreshed

   For each interface, routers also maintain a list of the other routers
   advertising on the link.  The list will be referred to in this memo
   as "DNARouterList".  For each router from which a Router
   Advertisement is received with the DNA flag set, the following
   information MUST be stored:

   1.  Source address of advertising router

   2.  Token equal to the first 64 bits of an SHA-1 hash of the above
       address

   Each router MUST include itself in the DNARouterList and generate a
   token for itself as describe above based on the link-local address
   used in its RA messages.

5.1.2  Router Configuration Variables

   A DNAv6 router MUST allow for the following conceptual variables to
   be configured by the system management.  Default values are set to
   ease configuation load.

   UnicastRAInterval

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

      Default: 50 milliseconds

   MaxUnicastRABurst

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







Narayanan, et al.       Expires November 4, 2005               [Page 12]


Internet-Draft                    DNAv6                         May 2005


      Default: 20

   RASeparation

      The separation between responses from different routers on the
      same link to a single Router Solicitation.

      Default: 20 milliseconds

   MulticastRADelay

      The delay to be introduced when scheduling a multicast RA in
      response to a RS message when the token bucket is empty.

      Default: 3000 milliseconds


5.1.3  Bootstrapping DNA Data Structures

   When an interface on a router first starts up, it SHOULD transmit up
   to MAX_RTR_SOLICITATIONS Router Solicitations separated by
   RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other
   routers and prefixes active on the link.

5.1.4  Processing Router Advertisements

   When a router receives a Router Advertisement, it first validates the
   RA per the rules in RFC 2461, and then performs the actions specified
   in RFC 2461.  In addition, each valid Router Advertisement is
   processed as follows:

   If the DNA flag is set in the RA, the router checks if there is an
   entry in its DNARouterList.  Thus it looks up the source address of
   the RA in that list and, if not found, a new entry is added to
   DNARouterList, including the source address and a token equal to the
   first 64 bits of an SHA-1 hash of the source address.  The entry's
   'Time last refreshed' is updated.

   Regardless of the state of the DNA flag, each PIO in the RA is
   examined.  If the prefix is not in the router's AdvPrefixList [3] and
   not already in the DNAPrefixList, it is added to the DNAPrefixList,
   along with the lifetime and refresh information.

5.1.5  Processing Router Solicitations

   The usual response to an RS SHOULD be a unicast RA.  To keep control
   of the number of unicast RAs sent, a token bucket is used to limit
   the rate at which they are sent.  The token bucket is filled at one



Narayanan, et al.       Expires November 4, 2005               [Page 13]


Internet-Draft                    DNAv6                         May 2005


   token every UnicastRAInterval.  A maximum of MaxUnicastRABurst tokens
   are stored.

   The router interface switches bewteen two states with respect to
   Router Solicitation response, depending on the availablity of tokens
   in the token bucket.  The states are called UnicastSender and
   MulticastSender.  The interface MUST be initialised to the
   UnicastSender state and the token bucket to full.

   If the interface is in the UnicastSender state then the router checks
   whether there are any unicast send tokens available.  If a unicast
   send token is available:

      If the source address of the Router Solicitation is the
      Unspecified Address or if it does not contain a landmark option,
      then the router builds a CompleteRA and schedules it for multicast
      transmission as per RFC 2461.  The interface MUST remain in the
      UnicastSender state.

      If the source address of the RS is NOT the unspecified address,
      AND the RS message contains a Landmark option, the router consumes
      one unicast send token and then builds a Router Advertisement as
      follows:

         The DNA flag is set.

         If the RS contains a Landmark Option whose prefix matches one
         of those in the interface's stored prefix list, then the
         Landmark option with the Landmark prefix is included in the RA
         but with the Yes flag set.  At this point the RA is ready for
         transmission, and is scheduled as specified in Section 5.1.7.

         If the RS contains a Landmark Option whose prefix does not
         match any of those in the interface's stored prefix list, then
         the Landmark option with the Landmark prefix is included in the
         RA but with the No flag set.  All fixed options (MTU,
         Advertisement Interval, flags, etc.) are added to the Router
         Advertisement.  Prefix Information Options for any explicitly
         configured prefixes SHOULD be added to the Router
         Advertisement, while the DNAO for learned prefixes MUST not be
         added.  If there is insufficent room to fit all of the PIOs, an
         additional Router Advertisement is built after consuming
         another token, if available.  At this point the Router
         Advertisment is ready for transmission, and is scheduled as
         specified in Section 5.1.7.

   If the interface is in UnicastSender state and a unicast send token
   is not available in the token bucket, the router MUST start a timer



Narayanan, et al.       Expires November 4, 2005               [Page 14]


Internet-Draft                    DNAv6                         May 2005


   (MulticastTimer) to expire after MulticastRADelay.  The interface
   MUST transition to the MulticastSender state.

   If a Router Solicitation is received when the interface is in the
   MulticastSender state, then the Router Solicitation MUST be dropped.
   A multicast Router Advertisement has already been scheduled.

   When the MulticastTimer expires, the router MUST schedule a multicast
   RA for transmission.  This multicast RA SHOULD be constructed as a
   CompleteRA, as specified in Section 5.1.6.  After transmission of
   this multicast Router Advertisement in MulticastSenderState, the
   interface MUST transision to the UnicastSender state.

5.1.6  Complete Router Advertisements

   A CompleteRA is formed as follows:

   Starting with a Router Advertisement with all fixed options (MTU,
   Advertisement Interval, flags, etc.), the DNA flag is set.  As many
   Prefix Information Options for explicitly configured prefixes as will
   fit are added to the Router Advertisement.  If there is sufficient
   room, a DNA option as defined in Section 4.3 containing as many of
   the learned prefixes as will fit is added.

   It may not be possible to include all of the prefixes in use on the
   link due to MTU or administrative limitations.  If all Prefix
   Information Options and a DNA Option containing all of the learned
   prefixes were included in the RA, then the Complete flag in the
   Router Advertisement header is set.

5.1.7  Scheduling Fast Router Advertisements

   RAs may need to be delayed to avoid collisions in the case that there
   is more than one router on a link.  The delay is calculated by
   determining a ranking for the router for the received RS, and
   multiplying that by RASeparation.

   A token is needed from the RS to calculate the router's ranking.  The
   low order 64 bits of the RS source address MUST be used as the RS
   token.

   A router's ranking is determined by taking the XOR of the RS token
   and each of the stored router tokens.  The result of this XOR
   operation is a 64-bit number.  For the purpose of comparison it is
   treated as an unsigned integer.  The lowest result is ranked zero,
   the second, one, and so on.

   The RA MUST be scheduled for transmission in Rank * RASeparation



Narayanan, et al.       Expires November 4, 2005               [Page 15]


Internet-Draft                    DNAv6                         May 2005


   milliseconds.  When the router is ranked as zero, the resulting delay
   is zero, thus the RA SHOULD be sent immediately.

5.1.8  Scheduling Unsolicited Router Advertisements

   The unsolicited router advertisements scheduled as per RFC 2461
   SHOULD be a complete RA.  This recommendation is made to keep the
   multicast RA messages transmitted on the link looking the same,
   whether they are the multicast RA messages transmitted in
   MulticastSender state of the proposed DNAv6 protocol or the
   unsolicited RA messages transmitted based on RFC 2461.

5.2  DNA Host Operation

   Hosts collect information about the prefixes available on the link to
   which they are connected to facilitate change detection.

5.2.1  Data Structures

   Hosts MUST maintain a list of prefixes advertised on the link.  This
   is separate from the RFC 2461 "Prefix List" and will be referred to
   here as the "DNAPrefixList".  All prefixes SHOULD be stored, however
   an upper bound MUST be placed on the number stored to prevent
   overflow.  For each prefix stored the host MUST store the following
   information:

   1.  Prefix

   2.  Prefix length

   3.  Valid lifetime

   4.  Time last refreshed

   If a host is not able to store this information for every prefix,
   there is a risk that the host will incorrectly decide that it has
   moved to a new link, when it receives advertisements from a non-DNA
   router.

   Prefix information entry MUST be removed from the DNAPrefixList when
   its valid lifetime expires or if the entry has not been refreshed in
   the last 1.5 hours.

   Hosts MUST also maintain a "Landmark Prefix" as described in
   Section 5.2.2.






Narayanan, et al.       Expires November 4, 2005               [Page 16]


Internet-Draft                    DNAv6                         May 2005


5.2.2  Selection of a Landmark Prefix

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

      The prefix MUST have a non-zero valid lifetime.

      The prefix MUST be one the host is using for one of its non-link-
      local IPv6 addresses.

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


5.2.3  Sending Router Solicitations

   Upon the occurance of a Layer 2 link-up event notification, hosts
   SHOULD send a Router Solicitation.  Hosts SHOULD apply rate limiting
   and/or hysteresis to this behaviour as appropriate to the link
   technology subject to the reliability of the hints.

   Hosts SHOULD include a Landmark Option (LO) in the RS message with
   the landmark prefix chosen based on the rules in section
   Section 5.2.2.

   Hosts MUST include a tentative source link layer address option
   (TSLLAO) in the RS message [13].  The router solicitation message is
   sent to the All_Routers_Multicast address and the source address MUST
   be the link local address of the host.

   The host MUST consider its link local address to be in the
   "Optimistic" state for duplicate address detection [6] until either
   the returned RA confirms that the host has not switched to a new link
   or, if an link switch has occured, the host has performed optimistic
   duplicate address detection for the address.

5.2.4  Processing Router Advertisements

   When the host receives a router advertisment, the host checks for the
   conditions and derives the associated conclusions given below:

   If the received router advertisement message was sent unicast to the
   host:

      If the unicast Router Advertisement contains a Landmark option
      that matches the Landmark Option in the last transmitted Router



Narayanan, et al.       Expires November 4, 2005               [Page 17]


Internet-Draft                    DNAv6                         May 2005


      Solicitation, and the 'Y' bit is set in the received Landmark
      option, then that indicates that no link change has occured and
      current configuration can be assumed to be still current.

      Instead if the 'N' bit is set in the received landmark option, a
      change of link is indicated and the host SHOULD initiate
      reconfiguration using the information in the Router Advertisement.

      Since the host received a unicast RA from the router, the host
      knows the router heard its RS, hence it SHOULD mark that router as
      REACHABLE from a Neighbor Unreachability Perspective.

   If a Router Advertisement is received with a multicast destination
   address and the DNA flag is set, check if the received RA is a
   completeRA by checking the complete (C) bit in the RA message.

      If the RA is a complete RA and the landmark prefix is not included
      in either a PIO or DNAO, then the host can conclude that it has
      changed link and SHOULD initiate re-configuration using the
      information in the received router advertisement.

      If the RA is a complete RA and the the landmark prefix is included
      in either a PIO or DNAO, then the host can conclude that it has
      not changed link.

      If the received RA is not complete then the host SHOULD use CPL
      logic to decide whether or not to reconfigure as described in
      [11].

   If the DNA flag is not set then the host SHOULD use CPL logic to
   decide whether or not to reconfigure as described in [11].

   When initiating reconfiguration due to link change, the host MUST
   remove all prefixes in the DNAPrefixList and repopulate it with the
   prefixes in the Prefix Information Options in the RA.

6.  Backward Compatability

6.1  Non DNA Host with DNA Routers

   The RS message sent by non-DNA hosts will not contain any of the new
   options defined by this document.  The host will receive a multicast
   RA in response to the solicitation message and process it as per RFC
   2461.

6.2  DNA Host with Non-DNA Routers

   The routers will behave based in the recommendations of RFC 2461 [3]



Narayanan, et al.       Expires November 4, 2005               [Page 18]


Internet-Draft                    DNAv6                         May 2005


   and ignore the new options defined in this memo.  Hosts will receive
   RA message without the DNA bit in the RA header set and will fallback
   on CPL for link identification.  Obviously, the objective of
   receiving fast response for RS message can not be achieved.

7.  Security Considerations

   The two security threats discussed in Section 7.1 and Section 7.2 are
   part of the discussion catalogued as Issue 14 in Section 9.

7.1  Amplification Effect

   With N routers on a link, each RS message sent on the link will have
   N RA responses sent on the link within (N-1) * RASeparation time.
   The rate control mechanism specified by this memo only controls the
   rate of RA messages generated by each of the routers.  But, since
   there is no theoretical restriction on the number of routers on the
   link, this amplification can deteriote the performance of the nodes
   on the link.  The routers could mitigate this effect by aggregating
   multiple RA messages into a single multicast RA message.  When a RS
   message is received, except for the router chosen to respond first,
   all the other routers have a delay introduced before they respond to
   the RS message.  Also, when the token bucket is empty ( see
   Section 7.2), the routers will have to wait for a token to be
   generated before responding.  If multiple RS messages are received
   during this wait time, the routers MAY choose to aggregate the
   responses to a single multicast RA message.  Aggregation can be done
   by creating a completeRA message as specified by Section 5.1.6.  But,
   since MIN_DELAY_BETWEEN_RAS restriction for multicast RA messages is
   inherited by this document, such aggregations are only possible every
   MIN_DELAY_BETWEEN_RAS (3 seconds).

7.2  Attacks on the Token Bucket

   A host on the link could easily drain the token bucket(s) of the
   router(s) on the link by continously sending RS messages on the link.
   For example, if a host sends one RS message every UnicastRAInterval,
   and send a additional RS every third UnicastRAInterval, the token
   bucket in the router(s) on the link will drain within
   MaxUnicastRABurst * UnicastRAInterval * 3 time-units.  For the
   recommended values of UnicastRAInterval and MaxUnicastRABurst, this
   value is 3000 milli-seconds.  It is not clear whether arrival of such
   RS messages can be recognized by the router as a DoS attack.  This
   attack can also be mitigated by aggregating responses.  Since only
   one aggregation is possible in this interval due to
   MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able
   protect the tokens in the bucket.




Narayanan, et al.       Expires November 4, 2005               [Page 19]


Internet-Draft                    DNAv6                         May 2005


7.3  Attacks on DNA Hosts

   RFC 3756 outlines a collection of threats involving rouge routers.
   Since DNAv6 requires a host to obtain trustworthy responses from
   routers, such threats are relevent to DNAv6.  In order to counter
   such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router
   discovery.

8.  IANA Considerations

   This memo defines two new Neighbor Discovery [3] options, which must
   be assigned Option Type values within the option numbering space for
   Neighbor Discovery messages:

   1.  The Landmark option, described in Section 4.2; and

   2.  The DNA option, described in Section 4.3.


9.  Open Issues

   A list of open issues in the proposed design has been identified and
   catalogued at:
   http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASolution1.
   The following is a sample of the open issues, please refer to the
   above link for details.

   Issue 006: Congestion control in hosts

      The draft currently does not discuss congestion control in hosts
      and thus if there is no response to an RS, a host will follow RFC
      2461 and send MAX_RTR_SOLICITATIONS separated by
      RTR_SOLICITATION_INTERVAL (default 3 RSs at 4 sec. intervals).
      Should we specify some kind of exponential backoff to improve
      response performance for DNAv6 routers or should we try to
      maintain compatibility with RFC 2461?

   Issue 007: Timers on info stored by hosts

      The draft doesn't currently specify how hosts should age the
      information they collect about prefixes active on a link.

   Issue 009: LNOLO vs matched prefix

      If there is a landmark option with 'N' bit set in an RA, and *in
      the same RA* there is PIO that matches another prefix that the
      host believes is on the current link, what should the host
      conclude?



Narayanan, et al.       Expires November 4, 2005               [Page 20]


Internet-Draft                    DNAv6                         May 2005


   Issue 0010: Host response to inconsistent information

      What does the host do if it receives multiple RAs that have
      conflicting information?

   Issue 0012: Network renumbering - guidelines for deployment

      What does the draft need to say about network renumbering?
      Recommendations about not flash renumbering?  Explanation of
      effects of flash renumbering?

   Issue 0013:  Lifetime of learned prefixes and routers

      Since the maximum possible values for lifetimes of routers and
      prefixes could be very high, should we put an upper limit on how
      long learned prefixes and routers information can be stored by
      routers?

   Issue 0014:  TBF vs RDA

      Since the current text, using TBF (Token Bucked Flow control),
      allows the router to immediately respond to a RS message, it is
      possible for an attacker to empty the token buckets and move the
      router into MulticastSender state thereby denying other legitimate
      nodes quick link detection.  RDA (Random drop approach) recommends
      that the router should do some random unicast responding even in
      MulticastSender without becoming completely silent.

   Issue 0015:  DAD Interaction

      Need to add text to address DAD.

   Issue 0016:  MLD Interaction

      Need to add text to address MLD.


10.  Acknowledgments

   The design presented in this document was generated by discussions
   among the members of the DNA design team (JinHyeock Choi, Tero
   Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett
   Pentland).  The spirited debates on the design, advantages and dis-
   advantages of various DNA solutions helped creation of this document.

11.  References





Narayanan, et al.       Expires November 4, 2005               [Page 21]


Internet-Draft                    DNAv6                         May 2005


11.1  Normative References

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

   [2]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

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

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

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

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

11.2  Informative References

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

   [8]   Narayanan, S., Daley, G., and N. Montavont, "Detecting Network
         Attachment in IPv6 - Best Current Practices",
         draft-narayanan-dna-bcp-00 (work in progress), June 2004.

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

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

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

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

   [13]  Daley, G., "Tentative Source Link-Layer Address Options for
         IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in



Narayanan, et al.       Expires November 4, 2005               [Page 22]


Internet-Draft                    DNAv6                         May 2005


         progress), June 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:


   Erik Nordmark
   Sun Microsystems, Inc.
   17 Network Circle
   Mountain View, CA
   USA

   Phone: +1 650 786 2921
   Email: erik.nordmark@sun.com


   Brett Pentland
   Centre for Telecommunications and Information Engineering
   Department of Electrical and Computer Systems Engineering
   Monash University
   Clayton, Victoria  3800
   Australia

   Phone: +61 3 9905 5245
   Email: brett.pentland@eng.monash.edu.au

Appendix A.  How the Goals are Met?

   The DNA goals document [7] contains a list of goals identified by G1
   to G10.  This is also enumerated in the solutions discussion document
   [12] generated by the DNA design team.  This section discusses how
   the proposed scheme addresses each of these goals.

   G1 The answer to the landmark question confirms whether link change
      has occured and if it has the RA contains sufficient information
      for the host to commence re-configuration.  If a multicast RA is
      used it contains a complete list of prefixes advertised on the
      link allowing the host to determine whether link change has



Narayanan, et al.       Expires November 4, 2005               [Page 23]


Internet-Draft                    DNAv6                         May 2005


      occured and to re-configure if necessary.

   G2 Under normal circumstances the host will receive a RA response
      within round-trip time and some processing time on the router.  If
      the first RA message is lost, if another router is on the link, a
      second RA should arrive within a slot time and so on.

   G3 Non movement scenarios will be correctly identified because the
      landmark will be confirmed by the router(s) on the link.

   G4 A single RS/RA message exchange is initiated in response to a hint
      that link change may have occured.

   G5 The existing RS/RA signalling is used along with unsolicited RA
      messages.  Some new options and flags are proposed.

   G6 Only link scope signaling is used.

   G7 SEND can be used to protect the RS and RA messages exchanged.

   G8 If SEND is not deployed, then a rogue device could cause a host to
      think its configuration is invalid by sending an RA that answers
      the RS question incorrectly.  A similar effect is already
      possible, however, by a rogue device sending an RA with valid
      prefixes with zero lifetimes.

   G9 The CPL logic allows a graceful fallback position for dealing with
      non-DNA routers and non DNA hosts will still receive the benefit
      of receiving an RA response from its current router faster than
      RFC 2461.

   G10 This technique is carried out on an interface by interface basis.
      A host with multiple interfaces can get information about changes
      to configuration on each interface, but would need a higher level
      process to decide how the information from the various interfaces
      relates to each other.















Narayanan, et al.       Expires November 4, 2005               [Page 24]


Internet-Draft                    DNAv6                         May 2005


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 (2005).  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 November 4, 2005               [Page 25]