[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

DNA WG                                                   JinHyeock. Choi
Internet-Draft                                               Samsung AIT
Expires: December 30, 2005                             Syam. Madanapalli
                                                             Samsung ISO
                                                           June 28, 2005


              DNA Solution: Link Identifier based approach
                   draft-jinchoi-dna-protocol2-01.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 December 30, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   DNA solution consists of 1)link identity detection with a single RA
   and 2)quick RA acquisition.  This draft presents the first component
   based on Link Identifier.  It describes a way for link identity
   detection with prefix based Link Identifier, 'linkid prefix'.  While
   this document doesn't include the second component, any quick RA
   acquisition scheme will work with the proposal.  The draft is the
   result of DNA DT discussion.



Choi & Madanapalli      Expires December 30, 2005               [Page 1]


Internet-Draft                linkid prefix                    June 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Checking for link change with Link Identifier  . . . . . .  3
     1.2   Link Identifier based on Prefix  . . . . . . . . . . . . .  3
     1.3   Protocol overview  . . . . . . . . . . . . . . . . . . . .  4
   2.  New Terms  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Linkid prefix  . . . . . . . . . . . . . . . . . . . . . .  5
     2.2   LEAST_VALID_LIFETIME . . . . . . . . . . . . . . . . . . .  5
     2.3   Linkid lifetime  . . . . . . . . . . . . . . . . . . . . .  5
     2.4   Linkid Prefix list (LinkidPrefixList)  . . . . . . . . . .  6
     2.5   LPIO (Learned Prefix Information Option) . . . . . . . . .  7
     2.6   Identifier bit (I-bit) . . . . . . . . . . . . . . . . . .  7
   3.  Router Operations  . . . . . . . . . . . . . . . . . . . . . .  8
     3.1   Data Structures  . . . . . . . . . . . . . . . . . . . . .  8
     3.2   Collecting the prefixes  . . . . . . . . . . . . . . . . .  8
     3.3   Selecting the linkid prefix  . . . . . . . . . . . . . . .  9
     3.4   Advertising the linkid prefix  . . . . . . . . . . . . . .  9
     3.5   Graceful linkid prefix change  . . . . . . . . . . . . . .  9
       3.5.1   When a new linkid prefix is added. . . . . . . . . . . 10
       3.5.2   When the linkid prefix lifetime decreases to
               LEAST_VALID_LIFETIME.  . . . . . . . . . . . . . . . . 10
       3.5.3   When the linkid prefix is removed while its
               lifetime is greater than LEAST_VALID_LIFETIME. . . . . 10
       3.5.4   When the Linkid prefix (Learned Prefix) is not
               advertised in the last 1.5 hours . . . . . . . . . . . 12
   4.  Host Operations  . . . . . . . . . . . . . . . . . . . . . . . 13
     4.1   Managing the LinkidPrefixList  . . . . . . . . . . . . . . 13
     4.2   Checking for link change . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.1   Issue 001: LPIO format . . . . . . . . . . . . . . . . . . 17
     7.2   Issue 002: Advertising old linkid prefix . . . . . . . . . 17
     7.3   Issue 003: Flash renumbering and early reassignment  . . . 18
     7.4   Issue 004: DAD Interaction . . . . . . . . . . . . . . . . 18
     7.5   Issue 005: MLD Interaction . . . . . . . . . . . . . . . . 18
     7.6   Issue 006: Sending RA before completing prefix
           collection . . . . . . . . . . . . . . . . . . . . . . . . 18
     7.7   Issue 007: Linkid prefix option for RS message . . . . . . 18
     7.8   Issue 008: Linkid Selection Scheme . . . . . . . . . . . . 19
   8.  Comparison with landmark based approach  . . . . . . . . . . . 20
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2  Informative References . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24



Choi & Madanapalli      Expires December 30, 2005               [Page 2]


Internet-Draft                linkid prefix                    June 2005


1.  Introduction

   Upon establishing a new link-layer connection, a host should detect
   the identity of the currently attached link to ascertain the validity
   of the existing IP configuration.  If the host is attached to a
   different link, it also needs to acquire the IP configuration for the
   new link [4].

   DNA solution should be able to 1) check for link change with a single
   RA (Router Advertisement) and 2) get the RA with minimum latency [8].
   This draft presents only the first component, link identity
   detection.  But the proposed Link Identifier based scheme can work
   with any existing quick RA acquisition method, such as FRD in [16],
   FastRA in [17] or Hash based scheme in [13].

1.1  Checking for link change with Link Identifier

   Usually a host receives the link information with RA (Router
   Advertisement) messages.  But it's difficult for a host to correctly
   check for link change with a single RA message.

   It may be better to design a new way to represent a link, 'Link
   Identifier'.  Each link has its unique Link Identifier and all
   routers in the link advertise the same Link Identifier in RAs.  With
   a Link Identifier, an RA can represent link identity properly and
   hosts can check for link change immediately without resorting to
   approximate knowledge.

   When a host receives an RA with the same Link Identifier, it still
   remains at the same link.  If it receives an RA with a different Link
   Identifier, a link change has occurred and the host is attached to a
   different link.

1.2  Link Identifier based on Prefix

   We may define a new option for linkid.  In [14] Erik Nordmark
   proposed a new option, Location Indication Option and Brett Pentland
   submitted a draft on linkid [15].

   Global prefix is another possible candidate for use as linkid (Link
   Identifier).  If all routers on the link advertise the same prefix as
   the linkid, the prefix can properly represent the link identity.

   Prefixes would have the advantage of being globally unique and
   requires no additional RA bytes if a router is already advertising
   the prefix.  Only an added flag is needed to indicate that it is also
   a linkid (Link Identifier).  Linkid may need to change as the
   prefixes used on a link change.



Choi & Madanapalli      Expires December 30, 2005               [Page 3]


Internet-Draft                linkid prefix                    June 2005


1.3  Protocol overview

   The routers on the link collects the prefixes on the link and, as the
   linkid, pick the smallest prefix among the prefixes with lifetime
   greater than 3 hours.  We call such a prefix 'linkid prefix'.

   The routers advertise the linkid prefix in every RA.

   If the linkid prefix belongs to the advertising router, it includes
   the linkid prefix in PIO (Prefix Information Option) with identifier
   bit (I-bit) set, which indicates that the prefix is the linkid.

   If not, the router includes the linkid prefix in LPIO (Learned Prefix
   Information Option) with identifier bit (I-bit) set, which also
   indicates that the prefix is the linkid.

   The routers use a single linkid prefix at any given time, but due to
   the possibility that the linkid prefix changing (e.g., when a link is
   renumbered), the hosts track the list of linkid prefixes they've
   received in the last 1.5 hours to generate "the linkid prefix list
   (LinkidPrefixList)".

   Take notice that the above doesn't mean that multiple linkid prefixes
   are assigned on a link at the same time.  Not like prefix, the linkid
   is supposed to be unique at a given moment and the LinkidPrefixList
   would have only one element for the most of time.

   Whenever the host receives an RA with a linkid prefix, a host
   extracts the prefix to store it in the LinkidPrefixList.

   If the host receives an RA with a linkid prefix and the RA also
   includes a linkid prefix the host knows of, it assumes that it still
   remains at the same link.

   If the host receives an RA with a linkid prefix and the RA doesn't
   include a linkid prefix the host knows of, it assumes that it has
   moved to a new link.  The host also discards the existing
   LinkidPrefixList and starts a new one.

   This is rather intuitive description and Sec 4 gives more rigorous
   and detailed one.










Choi & Madanapalli      Expires December 30, 2005               [Page 4]


Internet-Draft                linkid prefix                    June 2005


2.  New Terms

2.1  Linkid prefix

   A prefix which plays the role of linkid (Link Identifier).

2.2  LEAST_VALID_LIFETIME

   Only a prefix with valid lifetime greater than LEAST_VALID_LIFETIME
   can be a linkid prefix.  When the lifetime of a linkid prefix becomes
   less than LEAST_VALID_LIFETIME, it can no longer be a Link
   Identifier.

   For the time being, we set the LEAST_VALID_LIFETIME as 3 hours.

   LEAST_VALID_LIFETIME is introduced to gracefully change the linkid
   prefix as described in Sec 3.4.

2.3  Linkid lifetime

   RFC 2461  [1] defines default valid lifetime as 30 days and default
   preferred lifetime as 7 days, which may be too long for a linkid
   prefix.

   Hence, for a linkid prefix, a host keeps a separate lifetime, 'linkid
   lifetime'.

   For each linkid prefix, whenever a host receives an RA with the
   prefix, the host sets the linkid lifetime as 1.5 hour and starts
   timer.

   When linkid lifetime expires, the host no longer uses the prefix as a
   linkid.  But the host may keep the prefix as an ordinary prefix until
   its valid lifetime expires.

   According to RFC 2461  [1], the maximum of MaxRtrAdvInterval is 1800
   secs.  Hence, because all RAs are supposed to carry the linkid
   prefix, linkid lifetime expiration means that the host has lost at
   least 3 RAs.

   Linkid lifetime is introduced to gracefully change the linkid prefix
   as described in Sec 3.4.  It is also intended to deal with flash
   renumbering and early reassignment as below.

   When a linkid prefix is removed from a link, it is recommended that
   the linkid prefix should not be re-assigned to other link in 3 hours.

   The above means that if a host sees the valid prefix which was a



Choi & Madanapalli      Expires December 30, 2005               [Page 5]


Internet-Draft                linkid prefix                    June 2005


   linkid and its linkid lifetime is still left, the host still remains
   at the same link.

   Sub-sec 7.3 gives the detailed analysis.

2.4  Linkid Prefix list (LinkidPrefixList)

   A host keeps the linkid prefix list (LinkidPrefixList) per a link.
   The LinkidPrefixList is the set of linkid prefixes the host has
   received in the last 1.5 hours.

   If the host has declared the movement to a different link, it needs
   to discard the LinkidPrefixList from the old link.

   When the host receives a prefix with identifier bit (I-bit) set, it
   keeps the prefix in the LinkidPrefixList for the next 1.5 hours.

   Take notice that the prefix in the LinkidPrefixList may not be the
   linkid anymore.  Also it's possible for the LinkidPrefixList has more
   than one prefix.

   This is for graceful linkid prefix change.  When a linkid prefix is
   changed in a link, there may be some flapping for a while.  A router
   may advertise the new linkid prefix, whereas the other one the old
   one.  Hence hosts can confuse this as frequent link changes.

   To prevent this, hosts keep the LinkidPrefixList and assume they are
   still at the same link, if they see the prefix in the
   LinkidPrefixList.

   We illuminate the role of the LinkidPrefixList with the following
   example.  Assume a link with two routers R1 and R2.  R1 advertise the
   linkid prefix P1 and R2 advertises the prefix P2.  At this stage,
   hosts would have the LinkidPrefixList {P1}.

   R2 starts advertising a new prefix P3, which happens to be the
   smallest one, hence a new linkid prefix.  R2 sends an RA with P3
   (with I-bit set) and P1 (without I-bit set).  A host sees the RA with
   a new linkid prefix but will not assume a link change because of P1.
   The host simply adds P3 to its LinkidPrefixList and the
   LinkidPrefixList becomes {P1, P3}.

   Then because of packet loss R1 doesn't receive the RA and sends an RA
   with P1 (with I-bit set) but without P3.  The host sees an another RA
   with a different linkid prefix but will not assume a link change
   because of P1.  The LinkidPrefixList is still {P1, P3}

   Afterwards R1 belatedly notices a linkid change and starts



Choi & Madanapalli      Expires December 30, 2005               [Page 6]


Internet-Draft                linkid prefix                    June 2005


   advertising P3 as the linkid prefix.  Again the host doesn't assume a
   link change because of P1 and the LinkidPrefixList is {P1, P3}.

   During the whole transition period, the prefix P1 in the
   LinkidPrefixList plays the role of assuring hosts of no link change.

2.5   LPIO (Learned Prefix Information Option)

   When routers advertise learned prefixes, they use LPIO instead of
   ordinary PIO.

   LPIO format is TBD but it at least needs to include

   o  prefix length

   o  prefix

   o  Identifier bit (I-bit) (indicating the prefix in the LPIO is the
      linkid)

   Sub-sec 7.1 gives the detailed discussion about LPIO format.

2.6  Identifier bit (I-bit)

   A bit in PIO or LPIO which indicates that the prefix in this option
   is the linkid prefix.

   Identifer bit (I-bit) format is TBD.























Choi & Madanapalli      Expires December 30, 2005               [Page 7]


Internet-Draft                linkid prefix                    June 2005


3.  Router Operations

3.1  Data Structures

   The routers maintains a set of prefixes advertised by other routers
   in the link (called as "learned prefix list (LearnedPrefixList)") per
   interface.  For each learned prefix, routers maintain the following
   information

   o  Prefix

   o  Prefix Length

   o  Valid Life Time

   o  Last Refreshed Time

   For each linkid prefix, routers also need to maintain the time when
   the prefix stops being advertised as the linkid prefix.  This time
   needs to be maintained for both learned prefixes and the prefixes
   advertised by the router.

   Note that an implementation need not have the data structures as
   described above as long as the external behavior is consistent with
   that described in this document.

3.2  Collecting the prefixes

   To select the linkid prefix, routers should collect all the prefixes
   on the link.

   A router, when it boots or is configured to act as a router (Sec
   6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to gather
   prefixes.

   Sending one RS and waiting for 4 seconds might suffice; optionally
   retransmitting the RS once or twice and waiting a total of 8 or 12
   seconds gives higher confidence.

   From the received RAs, the router extracts only the valid prefixes in
   PIO and generate the "learned prefix list (LearnedPrefixList)".  It
   is noted that the prefixes the router advertises itself (the
   AdvPrefixList in RFC 2461 [1]) are not included in the
   LearnedPrefixList.

   The router takes the union of the learned prefix list and the
   prefixes the router itself advertises to generate the complete prefix
   list as defined in [9]



Choi & Madanapalli      Expires December 30, 2005               [Page 8]


Internet-Draft                linkid prefix                    June 2005


   Once that process is complete, the router will send RAs and respond
   to RSs, but not before that.

   After initial RS/ RA exchange, the router can send a few closely
   spaced RAs as specified in RFC 2461 [1] to quickly spread its own
   information on the link.

   Whenever a router receives a new prefix in PIO, it will update its
   learned prefix list.

   Take notice that, for prefix list generation, a router only takes the
   prefixes in PIO into consideratoin.

3.3  Selecting the linkid prefix

   Among the prefixes 1) whose valid lifetime is greater than
   LEAST_VALID_LIFETIME, i.e. 3 hours and 2) which is received within
   1.5 hours in case of a learned prefix, the router picks the smallest
   prefix as the linkid prefix.

   * There are other ways to determine the linkid prefix.  We may choose
   any subset of the complete prefix list and pick the smallest or
   greatest one of it.

   When a router receives a new prefix in PIO, (with or without
   identifier bit (I-bit) set), if the prefix is smaller than the
   current linkid prefix and has valid lifetime greather than 3 hours,
   the router selects the new prefix as a new linkid prefix.

   In case the new prefix smaller than the current linkid prefix is
   advertised in LPIO, the router doesn't change the linkid prefix.

3.4  Advertising the linkid prefix

   Whenever a router sends an RA, whether solicited or unsolicited, it
   includes the linkid prefix in it.  Hence, all RAs carry the linkid
   prefix.

   When a router advertises the linkid prefix, if the linkid prefix is
   explicitly configured on the router, it sends it in PIO with I-bit
   set.

   If not, the router sends the linkid prefix in LPIO with I-bit set.

3.5  Graceful linkid prefix change

   Basic idea is, when a router changes a linkid prefix, for the time
   being, it sends both 1) new linkid prefix with I-bit set and 2) old



Choi & Madanapalli      Expires December 30, 2005               [Page 9]


Internet-Draft                linkid prefix                    June 2005


   linkid prefix without I-bit set to notify hosts that only linkid has
   been changed without a link change.

3.5.1  When a new linkid prefix is added.

   When a router starts advertising a new prefix, if the prefix happens
   to be the smallest one in the link, a linkid prefix needs to be
   changed.

   First the router sends to all-node multicast address an RA with 1)
   new linkid prefix with I-bit set and 2) old linkid prefix without
   I-bit set several times.

   Upon receiving this RA, because new prefix is smaller than the
   current linkid prefix, routers would change the linkid prefix to the
   new one.

   Old linkid prefix (whether its I-bit set or not) assures hosts that
   they still remain at the same link.  So hosts would simply update its
   LinkidPrefixList without any outward activity, such as sending an RS.

3.5.2  When the linkid prefix lifetime decreases to
       LEAST_VALID_LIFETIME.

   When the valid lifetime of the linkid prefix becomes
   LEAST_VALID_LIFETIME, i.e. 3 hours, it is no longer a linkid.

   A router decreases the prefix lifetime in real-time and at the moment
   the prefix lifetime becomes 3 hours, the router selects a new linkid
   prefix and stops advertising the I-bit on the (old) linkid prefix.

   For the time being, when the router sends RA, it includes 1) new
   linkid prefix with I-bit set and 2) old linkid prefix without I-bit
   set to assure hosts that they still remain at the same link.

3.5.3  When the linkid prefix is removed while its lifetime is greater
       than LEAST_VALID_LIFETIME.

   A router may want to remove the linkid prefix before the valid
   lifetime decreases to 3 hours.

   When a router stops advertising a linkid prefix, it removes the
   prefix in two steps as below.

   First the router picks the second smallest prefix as the new linkid
   prefix.

   It sends to all node multcast address an RA with 1) new linkid prefix



Choi & Madanapalli      Expires December 30, 2005              [Page 10]


Internet-Draft                linkid prefix                    June 2005


   with I-bit set and 2) old linkid prefix with 2 hours as valid
   lifetime & without I-bit set.

   Upon receiving this RA, routers would see the (old) linkid prefix in
   PIO with the valid lifetime less than LEAST_VALID_LIFETIME.  Hence
   they also would select the second smallest one as the new linkid and
   starts advertising it with I-bit set.

   When hosts receives this RA, they would have non-zero linkid lifetime
   for the (old) linkid prefix, becuase, at least, two RAs with (old)
   linkid prefix were sent within 1 hour according to MaxRtrAdvInterval
   value defined in [1].  Therefore, hosts would update its linkid
   prefix but would not assume a link change because of (old) linkid
   prefix.

   Upon sending such an RA several times, once the router is sure that
   all routers have changed their linkid, it can remove the (old) prefix
   linkid entirely by advertising the prefix with zero lifetime value.

   For example, assume a router R advertise the linkid prefix P1 and the
   second smallest prefix is P2.

   When the valid lifetime of P1 is 7 days, R wants to remove P1 from
   the link.

   If R immediately advertises an RA with 1) P1 with zero lifetime and
   2) P2 with I-bit set, hosts may treat this as a link change, because
   they would discard P1 entirely when seeing it with zero lifetime.

   So instead, R removes P1 in two steps.  First, R advertises an RA
   with 1) P1 with lifetime 2 hours and 2) P2 with I-bit set.

   Then hosts would know this is just a linkid change without a link
   change from (old) linkid prefix P1.  Also other routers would know P1
   is no longer linkid prefix, because P1 has lifetime less than
   LEAST_VALID_LIFETIME.

   After a while, when R is sure that all nodes on the link have
   perceived linkid change, it can safely remove P1 by advertising it
   with zero lifetime.

   Also it's recommended that once a prefix has been advertised with a
   lifetime that results in a prefix invalidation at time Ti, then the
   router should advertise the prefix with a valid lifetime=0 until time
   Ti has passed.






Choi & Madanapalli      Expires December 30, 2005              [Page 11]


Internet-Draft                linkid prefix                    June 2005


3.5.4  When the Linkid prefix (Learned Prefix) is not advertised in the
       last 1.5 hours

   If the Linkid prefix advertised by the router is learned prefix and
   it was not refreshed in the last 1.5 hours, the router will select
   new Linkid prefix and advertises the previous Linkid prefix as old
   linkid for next 1.5 hours.












































Choi & Madanapalli      Expires December 30, 2005              [Page 12]


Internet-Draft                linkid prefix                    June 2005


4.  Host Operations

4.1  Managing the LinkidPrefixList

   While routers manage a single linkid prefix, hosts track all the
   linkid prefixes it has seen in the last 1.5 hours to keep the linkid
   prefix list (LinkidPrefixList) per a link.

   When the host has decides it has moved to a different link, it
   discards the LinkidPrefixList from the old link.

   If a host has no linkid prefix, i.e. its LinkidPrefixList is empty,
   it sends an RS according to the procedure defined in RFC 2461 [1] to
   acquire one.

   After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no
   RA with a linkid prefix arrives, the host assumes it is at a non-
   supporting link and falls back on CPL [9].

   Whenever a host receives an RA, it checks whether the RA includes a
   prefix with identifier bit (I-bit) set.

   If the RA contains such a prefix, the host extracts the prefix and
   sets its linkid lifetime as 1.5 hour and starts timer.

   The linkid lifetime for the prefix should decrement in real time that
   is, at any point in time they will be the remaining lifetime.  An
   implementation could handle that by recording the 'expire' time for
   the information, or by periodically decrementing the remaining
   lifetime.

   Then the host check for link change as described in Sub-sec 4.2.  If
   the host assumes a link change, it discards the current
   LinkidPrefixList and makes a new LinkidPrefixList with the new prefix
   with I-bit set.  If not, the host adds the new linkid prefix to the
   current LinkidPrefixList (unless the prefix already belongs to the
   LinkidPrefixList).

   The host keeps a linkid prefix in the LinkidPrefixList as long as it
   has non-zero linkid lifetime and valid (prefix) lifetime.

   When the linkid lifetime for the prefix expires, the prefix becomes
   an ordinary prefix.  Hosts remove it from the LinkidPrefixList but
   keep it until its valid lifetime expires.

   Take notice that, when the LinkidPrefixList becomes empty, i.e. the
   linkid lifetime of all prefixes in the LinkidPrefixList expires, the
   host doesn't assume a link change.



Choi & Madanapalli      Expires December 30, 2005              [Page 13]


Internet-Draft                linkid prefix                    June 2005


   A prefix in the LinkidPrefixList may become invalid (as a prefix).
   The prefix may be advertised with zero lifetime or the host moves to
   an another link.  In those cases, the host discards the prefix just
   like an ordinary prefix according to RFC 2461  [1].

4.2  Checking for link change

   When a host doesn't have a linkid prefix, i.e. its LinkidPrefixList
   is empty, it relies on CPL [9] to check for link change.

   When a host with a linkid prefix receives a hint of a possible link
   change, such as Link Up event notification [10], it may send an RS to
   all-router multicast address to get an RA with a linkid prefix.

   After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no
   RA with a linkid prefix arrives, the host assumes it is at a non DNA
   link and falls back on CPL [9].

   When a host with a linkid prefix receives an RA, whether solicited or
   unsolicited, that includes a prefix with I-bit set, the host compares
   its LinkidPrefixList with the set of prefixes in the RA.

   If there is a common prefix, i.e. the RA also includes the prefix in
   the LinkidPrefixList, the host assumes that it still remains at the
   same link.

   Note that the common prefix need not be the linkid prefix in the RA.

   If not, the host assumes that it has moved to a new link, discards
   its LinkidPrefixList and starts a new one.





















Choi & Madanapalli      Expires December 30, 2005              [Page 14]


Internet-Draft                linkid prefix                    June 2005


5.  IANA Considerations

   This draft will define one new Neighbor Discovery [1] option and a
   new flag in PIO (Prefix Information Option), which must be assigned
   Option Type values within the option numbering space for Neighbor
   Discovery messages:

   1.  LPIO (Learned Prefix Information Option), described in Sec 2.

   2.  Identifier bit (I-bit) in PIO (Prefix Information Option),
   described in Sec 2.








































Choi & Madanapalli      Expires December 30, 2005              [Page 15]


Internet-Draft                linkid prefix                    June 2005


6.  Security Considerations

   Because this DNA proposal is based on Neighbor Discovery, its trust
   models and threats are similar to the ones presented in [7].  Nodes
   connected over wireless interfaces may be particularly susceptible to
   jamming, monitoring and packet insertion attacks.  Use of SEND [6] to
   secure Neighbor Discovery are important in achieving reliable
   detection of network attachment.  This DNA proposal SHOULD
   incorporate the solutions developed in IETF SEND WG if available,
   where assessment indicates such procedures are required.









































Choi & Madanapalli      Expires December 30, 2005              [Page 16]


Internet-Draft                linkid prefix                    June 2005


7.  Open Issues

7.1  Issue 001: LPIO format

   For LPIO format, there are two approaches under consideration:

   1.  A minimalist DNA approach - just carry what DNA needs

   2.  A complete copy of the PIO (Prefix Information Option)

   For the first case, we can use the following option similar to
   landmark option in [13] that includes only prefix length, prefix and
   identifier bit (I-bit).


     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   |I|             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             +
    |                           Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                          Linkid Prefix                        ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For the second case, we can reuse PIO format with a different code.
   The learning router would not assume it knows anything about the PIO
   it received but blindly send it (after only changing the option code
   to "LPIO").

   The choice has to do with guessing how the PIO might evolve over time
   (new flags etc and their semantics).  Perhaps the second approach
   might help as the PIO content evolves but, at this point, it is hard
   to tell.

   We don't see much utility for a middle ground where LPIO includes
   some things which DNA doesn't need, but doesn't include everything
   that was in the PIO.

7.2  Issue 002: Advertising old linkid prefix

   When a router changes a linkid prefix, to notify hosts that only
   linkid has been changed without a link change, the router sends both
   1) new linkid prefix with I-bit set and 2) old linkid prefix without
   I-bit set for a while.  It is needed to set a normative value about
   how long the router keeps advertising old linkid prefix after linkid



Choi & Madanapalli      Expires December 30, 2005              [Page 17]


Internet-Draft                linkid prefix                    June 2005


   change.  The value under consideration is 1.5 hour.

7.3  Issue 003: Flash renumbering and early reassignment

   A useful definition of flash renumbering is that the prefix is
   removed from a link earlier than its latest advertised expiry time.
   We define "flash renumbering and early reassignment", as the above
   plus the prefix being assign to another link before the latest
   advertised expiry time on the old link.

   Flash renumbering and early reassignment does have potential impact
   on DNA, (when using prefixes to identify links), because the host
   might move "in parallel" with the reassigned prefix, and therefor
   fails to detect movement when it in fact moved.  Note that the prefix
   might have been advertised with a zero valid lifetime on the link,
   but the host might not notice this since it might already have
   disconnected from the old link when these RAs were sent.

   To resolve this issue, this draft proposes that, when a linkid prefix
   is removed from a link, the linkid prefix should not be re-assigned
   to other link in 3 hours.  With the above, a host would not see the
   same linkid prefix in two different links because linkid lifetime is
   1.5 hour.

7.4  Issue 004: DAD Interaction

   The draft needs to describe the DNA interaction with DAD such as what
   steps a host should go through with respect to DAD.  The procedure
   under consideration is described in Sec 3 in [8]

7.5  Issue 005: MLD Interaction

   The draft needs to describe the DNA interaction with MLD such as what
   steps a host should go through with respect to MLD.  The procedure
   under consideration is described in Sec 3 in [8]

7.6  Issue 006: Sending RA before completing prefix collection

   According to Sec 6.1, routers can't respond at all to RSs before
   completion of the soliciting phase.  Brett Pentland proposed to relax
   this restriction.

7.7  Issue 007: Linkid prefix option for RS message

   Right now, when a host sends an RS, it doesn't notify its linkid
   prefix.  But it may be useful for a host to select a prefix in its
   linkid prefix list to put it in an RS, so that, upon reception of the
   linkid prefix, routers can determine whether the host remains at the



Choi & Madanapalli      Expires December 30, 2005              [Page 18]


Internet-Draft                linkid prefix                    June 2005


   same link and send only the minimal information in case of non-link
   change.

   For this, we may define new linkid prefix options for RS messages as
   below.


     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     | Prefix Length |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                           Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                          Linkid prefix                        ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Further analysis such as trade-off between bandwidth saving and added
   complexity is necessary to ascertain the usefulness of this linkid
   prefix option.

7.8  Issue 008: Linkid Selection Scheme

   Right now, routers select the smallest prefix among the prefixes on a
   link as the linkid prefix.  However, there are other ways to select
   the linkid from the complete prefix list.  In fact any deterministic
   selecting algorithm can do.

   Syam Madanapalli suggested that routers use the longest valid prefix
   time as the selector for the linkid prefix because this way linkid
   will be valid for more time.  Greg Daley proposed to select the most
   (natively) advertised prefix as the linkid because it's guaranteed to
   produce the minimum number of additionally advertised prefixes.
















Choi & Madanapalli      Expires December 30, 2005              [Page 19]


Internet-Draft                linkid prefix                    June 2005


8.  Comparison with landmark based approach

   We present a bit of comparison between linkid based approach in this
   draft and landmark based approach defined in [13].

   C1 Linkid scheme does not add any extra options in an RS, whereas
      landmark scheme adds a new landmark option in an RS.

   C2 In linkid scheme, when solicited, routers can send either unicast
      RA or multicast RA.  Whereas, in landmark scheme, the usual
      response to an RS should be an unicast RA.  Hence a soliciting RS
      should carry TSLLAO [19] and a mechanism is needed to limit the
      rate at which unicast RAs are sent.

   C3 Linkid scheme works well when a link has lots of prefixes; in
      particular when there are so many prefixes that all the PIOs &
      LPIOs can not fit in one RA to form a Complete RA.

   C4 When a prefix is added or removed in a link, routers may give
      conflicting information about link identity.  Linkid scheme can
      correctly check for link change even under such an inconsistency.






























Choi & Madanapalli      Expires December 30, 2005              [Page 20]


Internet-Draft                linkid prefix                    June 2005


9.  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).  Design Team members privide enlightening feedback and
   sometimes even more.  Parts of this draft are direct cut and paste
   from the Design Team mailing list.











































Choi & Madanapalli      Expires December 30, 2005              [Page 21]


Internet-Draft                linkid prefix                    June 2005


10.  References

10.1  Normative References

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

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

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

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

10.2  Informative References

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

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

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

   [8]   Choi, J. and E. Nordmark, "DNA solution framework",
         draft-ietf-dna-soln-frame-00 (work in progress), April 2005.

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

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

   [11]  Aboba, B., "Detecting Network Attachment (DNA) in IPv4",
         draft-ietf-dhc-dna-ipv4-12 (work in progress), June 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]  Narayanan, S., "Detecting Network Attachment in IPv6 Networks
         (DNAv6)", draft-pentland-dna-protocol-00 (work in progress),



Choi & Madanapalli      Expires December 30, 2005              [Page 22]


Internet-Draft                linkid prefix                    June 2005


         May 2005.

   [14]  Nordmark, E., "MIPv6: from hindsight to foresight?",
         draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
         November 2001.

   [15]  Pentland, B., "Router Advertisement Link Identification for
         Mobile IPv6 Movement  Detection",
         draft-pentland-mobileip-linkid-03 (work in progress),
         October 2004.

   [16]  Choi, J., "Fast Router Discovery with RA Caching",
         draft-jinchoi-dna-frd-00 (work in progress), July 2004.

   [17]  Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router
         Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
         progress), July 2004.

   [18]  Daley, G., "Deterministic Fast Router Advertisement
         Configuration", draft-daley-dna-det-fastra-01 (work in
         progress), October 2004.

   [19]  Daley, G., "Tentative Source Link-Layer Address Options for
         IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in
         progress), February 2005.


Authors' Addresses

   JinHyeock Choi
   Samsung AIT
   Communication & N/W Lab
   P.O.Box 111 Suwon 440-600
   KOREA

   Phone: +82 31 280 9233
   Email: jinchoe@samsung.com


   Syam Madanapalli
   Samsung ISO
   3/1 Millers Road
   Bangalore 560 052
   INDIA

   Phone: +91-8-51197777
   Email: syam@samsung.com




Choi & Madanapalli      Expires December 30, 2005              [Page 23]


Internet-Draft                linkid prefix                    June 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.




Choi & Madanapalli      Expires December 30, 2005              [Page 24]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/