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

Versions: 00                                                            
DNA WG                                                   JinHyeock. Choi
Internet-Draft                                               Samsung AIT
Expires: October 23, 2005                                 Erik. Nordmark
                                                                     Sun
                                                          April 21, 2005


                         DNA solution framework
                    draft-ietf-dna-soln-frame-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 October 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This draft captures the authors' opinions and is intended to serve as
   input to the discussion for the solution in the DNA WG.  It presents
   a few assumptions for DNA solution.  The draft proposes the solution
   to be based on 1) link identity, 2) RS/RA exchange formed so that a
   host can determine whether it has moved from a single RA, and 3)
   Quick delivery of an RA.  The draft sketches what rough shape DNA
   solution could take, including the necessary interaction with



Choi & Nordmark         Expires October 23, 2005                [Page 1]


Internet-Draft           DNA solution framework               April 2005


   Duplicate Address Detection and the Multicast Listener Discovery
   protocol.  It also enumerate a few tasks to be worked on and issues
   to be resolved for efficient DNA solution.

Table of Contents

   1.  DNA Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Basic Assumptions  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   DNA solution based on link identity detection  . . . . . .  4
     2.2   Using a RS/RA exchange to determine the link identity  . .  4
     2.3   Quick delivery of an RA  . . . . . . . . . . . . . . . . .  5
   3.  DNA Solution Sketch  . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Solution components  . . . . . . . . . . . . . . . . . . .  6
     3.2   Solution procedure . . . . . . . . . . . . . . . . . . . .  6
     3.3   Work items . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1   Checking for link change with Link Identifier  . . . . . . 10
     4.2   RA optimized for DNA . . . . . . . . . . . . . . . . . . . 10
     4.3   Quick delivery of an RA upon link-layer connection . . . . 11
     4.4   Links without Link Identification support  . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1   Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2   Informative References . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 19























Choi & Nordmark         Expires October 23, 2005                [Page 2]


Internet-Draft           DNA solution framework               April 2005


1.  DNA Overview

   Upon establishing a new link-layer connection, a host implementing
   the DNA solution should detect the identity of the currently attached
   link to ascertain whether it is attached to the same link as before,
   or attached to a different link.  If the host is attached to a
   different link, it also needs to acquire the IP configuration for the
   new link.  The DNA solution needs to be fast, precise, secure and
   have little signaling overhead.[4]










































Choi & Nordmark         Expires October 23, 2005                [Page 3]


Internet-Draft           DNA solution framework               April 2005


2.  Basic Assumptions

   We propose to design DNA solution based upon the following
   assumptions.

2.1  DNA solution based on link identity detection

   When a host establishes a new link-layer connection, in order to
   check whether its IP configuration is still valid, the host checks
   for link change, i.e. determine whether it still remains attached to
   the same link or not.  The term 'link' used in this document is as
   defined in [1].  NOTE that that definition is completely different
   than the definition of the term 'link' in IEEE 802 standards.

   If a link change has occurred, a host assumes that its IP
   configuration is no longer valid.  Thus it needs at least a new
   default router and a new IP address.  If it has remained attached to
   the same link, the host assumes its IP configuration is still valid,
   and performs no further DNA operations.

2.2  Using a RS/RA exchange to determine the link identity

   A Router Advertisement message is necessary when the host has
   attached to a different link, since the RA contains the new
   configuration information.  This means that the number of messages
   needed for DNA can be minimized if the Router Advertisement message
   also contains all the information needed to determine whether or not
   there was a link change.  In the general case, the host needs to send
   a Router Solicitation message so that it can quickly receive a Router
   Advertisement.  Hence we end up with a suggested approach based on
   using a single RS/RA exchange to both determine the link identity,
   and to provide the host with the configuration information for a new
   link.

   See [5] for the DTs different approaches to handle this.

   In order for a single RA message to be useful both to detect a link
   change, and, should the host have attached to a different link,
   useful to initiate the new IP configuration, the RA message needs to
   include at least:

   1) The information to indicate link change

   2) Router address (to select new default router, in case of a link
      change)






Choi & Nordmark         Expires October 23, 2005                [Page 4]


Internet-Draft           DNA solution framework               April 2005


   3) Prefix(es) (to form a new IP address, in case of a link change)

   4) Link-layer address of a router (to immediately send a packet)

   We need to investigate whether the above is sufficient.

2.3  Quick delivery of an RA

   To quickly check for link change, a host has to receive an RA with
   minimum latency.  This is difficult due to the random delays for RAs
   in response to RSs and rate limiting of multicast RAs in Neighbor
   Discovery [1].  For fast DNA solution, we need to find a way to
   quickly deliver an RA to a host upon a new link-layer connection.






































Choi & Nordmark         Expires October 23, 2005                [Page 5]


Internet-Draft           DNA solution framework               April 2005


3.  DNA Solution Sketch

3.1  Solution components

   For efficient DNA solution, we may need the following components.

   1. RA message optimized for DNA, which 1) properly indicate link
      change and 2) carries necessary information for a new IP
      configuration.

   2. A way to quickly deliver an RA to a host upon a new link-layer
      connection.

   3. Optimistic DAD [17] and TSLLAO [18] that is being specified in the
      IPv6 WG.

   4. A procedure to apply DAD during the DNA procedure that is both
      efficient and safe should there be a duplicate.

   5. A procedure for MLD so that the multicast groups are reported on a
      new link.

   6. A procedure that handles DHCPv6 address (and other) configuration
      for those cases when stateless address autoconfiguration is not
      used.


3.2  Solution procedure

   With the above, the DNA procedure might be as follows:

   Step [0] Network attachment

   A host has established a new link-layer connection.

   Step [1] Hint

   The host receives a hint that a link change might have occurred.
   This triggers the host to initiate DNA procedure.  For instance, the
   hint might consist of the link-layer (device driver) providing a link
   Up event notification to the IP layer of the host.

   Since the host doesn't know whether it is still attached to the same
   link, it needs to take the conservative approach and assumes it might
   have moved.  Thus it switches to operating in optimistic DAD mode
   [17] at this point in time (but since it might still be on the same
   link, it would be overkill to immediately send a DAD probe).  Since
   there might be MLD snooping switches in the network, the host must



Choi & Nordmark         Expires October 23, 2005                [Page 6]


Internet-Draft           DNA solution framework               April 2005


   use MLD to join, at least the solicited node multicast addresses that
   correspond to its IP addresses, at this point in time, so that it can
   receive Neighbor Solicitation messages that might indicate that an
   address is a duplicate.

   Step [2] RA acquisition

   The host acquires an RA optimized for DNA with minimum latency.  This
   procedure may be initiated either by the host or network.

   Either an AP (which implements [13]) immediately sends an RA to the
   host, or the host sends an RS to all-routers and one or more routers
   on the link responds to the RS with an RA.  The first RA from the
   router(s) should not be delayed.  Several approaches to accomplish
   this have been considered by the design team - see [5].

   The RS should have the link-local address of the host as the source
   address.  The RS message needs to contain the TSLLA option [18] to
   allow for optimal delivery of the RA in the case when the router
   supports TSLLAO, but should not contain a SLLAO option, since the
   link-local address might be a duplicate and DAD has not yet been
   completed.

   If the router implements TSLLAO, the RA would be unicast to the host;
   otherwise the RA would either be multicast to all-nodes, or the
   router would perform an NS/NA exchange with the host before
   unicasting the RA to the host.

   Step [3] Link identity detection

   Using the mechanism which will be selected by the WG (see [5] for
   ones that are being considered), the host determines whether this is
   the same link as before.

   If it is the same, the host assumes that its IP configuration is
   still valid.  No further DNA operation is performed and all the host
   needs to do is turn off the optimistic DAD mode.  (Since the host
   didn't move to a different link, we can rely on the DAD which was
   performed when the host was first attached to this link.  However,
   there has been some discussion whether or not DAD should be redone if
   a host, independently of DNA, has been disconnected from the link for
   some time.)

   If the host determines that it is attached to a new link, it
   immediately initiates a new IP configuration.  The RA contains enough
   information to discard old default routers and prefixes, and
   configure new ones.  (Should there be no "addrconf" prefixes in the
   RA, the host would presumably use DHCPv6 for address assignment which



Choi & Nordmark         Expires October 23, 2005                [Page 7]


Internet-Draft           DNA solution framework               April 2005


   would take one or two more roundtrips.)

   At this point in time it also makes sense for the host to perform DAD
   by sending a DAD probe for each configured IP address.  When the DAD
   probing has completed the host can turn off the optimistic DAD mode.

   If neither the old link, nor the potentially new link, use the new
   DNA solution for identifying the link, then the host needs to use
   prefix based link determination [11] which might require multiple RAs
   and even multiple RSs being sent before it can determine whether or
   not it is attached to a new link.

   Step [4] Multicast group reporting

   Should the host have moved to a new link, it needs to send MLD
   reports for all the multicast groups it belongs to, in order to
   quickly re-establish reception for the multicast groups.  (Note that
   the solicited-node multicast groups must be handled earlier - as part
   of the DAD procedure.)  There might be cases when multicast reception
   is critical, where it would be beneficial to send the MLD reports
   earlier (during step 1) so that, in the case the host has moved to a
   new link, any interruption in multicast reception is minimized, even
   if this results in unneeded MLD report packets in the case when the
   host did not move.

3.3  Work items

   It's our opinion that DNA WG (or IPv6 WG in the case of Optimistic
   DAD and TSLLAO) needs to work on the following subparts of the DNA
   problem:

   1. A link identification mechanism from the ones identified in [5]

   2. Complete Prefix List for the case when the above new mechanism is
      not available[11]

   3. Immediate RA responses to RS from the ones identified in [5].

   4. Optionally RAs that are sent by APs [13]

   5. Optimistic DAD [17] and TSLLAO [18].

   6. A procedure to apply DAD during the DNA procedure that is both
      efficient and safe should there be a duplicate.







Choi & Nordmark         Expires October 23, 2005                [Page 8]


Internet-Draft           DNA solution framework               April 2005


   7. A procedure for MLD so that the multicast groups are reported on a
      new link.

   8. A procedure that triggers DHCPv6 address (and other) configuration
      for those cases when stateless address autoconfiguration is not
      used.













































Choi & Nordmark         Expires October 23, 2005                [Page 9]


Internet-Draft           DNA solution framework               April 2005


4.  Issues

   In this section, we enumerate the issues to be resolved for efficient
   DNA solution.  We don't claim that the list is exhaustive.

4.1  Checking for link change with Link Identifier

   [This discussion on this section pre-dates the design team
   discussion, thus it might no longer be relevant.]

   Usually a host receives configuration information in one or more RA
   (Router Advertisement) messages.  But it's difficult for a host to
   correctly check for link change using a single RA message.  No
   information in RA can properly indicate whether a link change has
   occurred or not.  Neither router address nor prefix can do.

   It may be better to design a new way to represent a link, 'Link
   Identifier'.  Each link has its unique and explicit Link Identifier
   and all routers attached to the link advertise the same Link
   Identifier in their RAs.  With an explicit Link Identifier, an RA can
   represent a link identity 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.

   We need to investigate an efficient method to design an explicit Link
   Identifier.  We may define a new option for Link Identifier.  In [9]
   Erik Nordmark proposed a new option, Location Indication Option,
   which can server as Link Identifier.  Also Brett Pentland and all
   submitted a draft on Link Identifier [10].

   Other approaches can also be used, and many have been discussed in
   the Design Team.  What is important is that the host can tell whether
   it remains on the same link, or has moved to a different link, from
   the first Router Advertisement message it receives.

   See [5] for different approaches being discussed in the Design Team
   on how to handle this.

4.2  RA optimized for DNA

   To design RA message optimized for DNA, we need to consider what
   kinds of information it needs to contain.  We already presented 4
   necessary information in Section 2.2 and also it may be useful for an
   RA to include the following:



Choi & Nordmark         Expires October 23, 2005               [Page 10]


Internet-Draft           DNA solution framework               April 2005


   1') A global IP address of a router

   2') All prefixes that the router advertises


4.3  Quick delivery of an RA upon link-layer connection

   Upon a new link-layer connection, it may take too long to receive a
   RA.  A host may passively wait until it receives a periodic RA or,
   with link-layer hint, actively send an RS message and receive a
   solicited RA in response.

   For the first case, the time to receive a RA depends on RA
   advertisement interval and it may take many minutes.  Even in the
   second case there is a delay.  A router MUST wait random amount of
   time between 0 and 0.5 sec before replying an RA [1].  And if the
   router multicasts RAs in response to RSs, the MIN_DELAY_BETWEEN_RAS
   in [1] is also a potential problem which must be looked into.
   Otherwise this would add the worst-case delay of 3.5 seconds until an
   RA is received.

   To remedy this, currently two methods are proposed, FRD [13] and
   FastRA [14], [15].  In FRD, an AP caches a suitable RA and sends it
   immediately upon a new link-layer association.  FastRA [14] allows a
   router to send an RA without delay with some safety mechanism. [15]
   defines a secured mechanism that allows routers to make decisions
   about which router responds fastest, and additionally allows other
   routers to avoid random delays.

   Also see [5] for different approaches to handle this that have been
   discussed in the Design Team.

4.4  Links without Link Identification support

   A host may visit a link that doesn't support the new DNA solution for
   link identification.  There are a few cases to consider.

   1  Moving from one link using DNA link identification to another link
      using DNA link identification (and the link are identified as
      being different).

   2  Moving from a link using DNA link identification to a link which
      is not using it.

   3  Moving from a link not using DNA link identification to a link
      which is using it.





Choi & Nordmark         Expires October 23, 2005               [Page 11]


Internet-Draft           DNA solution framework               April 2005


   4  Moving from a link not using DNA link identification to a link
      which is also not using it.

   In all those cases, the host needs to be able to perform efficient
   DNA.

   If the host can always tell from a single RA whether or not the link
   is using DNA link identification, then the second and third case
   above are easy, because the host must have moved to a different link.

   This approach requires that 1) all the routers on a link are
   configured uniformly to either use DNA link identification or not,
   and 2) all the RAs contain at least a bit to indicate when DNA link
   identification is used.





































Choi & Nordmark         Expires October 23, 2005               [Page 12]


Internet-Draft           DNA solution framework               April 2005


5.  IANA Considerations

   No new message formats or services are defined in this document.
















































Choi & Nordmark         Expires October 23, 2005               [Page 13]


Internet-Draft           DNA solution framework               April 2005


6.  Security Considerations

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









































Choi & Nordmark         Expires October 23, 2005               [Page 14]


Internet-Draft           DNA solution framework               April 2005


7.  Acknowledgment

   The authors wish to express our appreciation to Greg Daley, Thomas
   Narten, Pekka Nikander and Alper Yegin for their valuable feedback.
   Also Thanks to Samita Chakrabarti, Youn-Hee Han, Gabriel Montenegro,
   Nick Moore, Brett Pentland, Ed Remmell and Margaret Wasserman for
   their contributions to this draft.












































Choi & Nordmark         Expires October 23, 2005               [Page 15]


Internet-Draft           DNA solution framework               April 2005


8.  References

8.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., "Detecting Network Attachment in IPv6 Goals",
        draft-ietf-dna-goals-04 (work in progress), December 2004.

8.2  Informative References

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

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

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

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

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

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

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

   [12]  Choi, J., "Router Advertisement Issues for Movement Detection/
         Detection of Network  Attachment", draft-jinchoi-ipv6-cra-00
         (work in progress), October 2003.



Choi & Nordmark         Expires October 23, 2005               [Page 16]


Internet-Draft           DNA solution framework               April 2005


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

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

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

   [16]  Narayanan, S., "Recommendations to achieve efficient Router
         Reachability Detection in IPv6  networks",
         draft-narayanan-dna-rrd-01 (work in progress), February 2005.

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

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

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

   [20]  Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
         draft-ietf-dhc-dna-ipv4-11 (work in progress), April 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










Choi & Nordmark         Expires October 23, 2005               [Page 17]


Internet-Draft           DNA solution framework               April 2005


   Erik Nordmark
   Sun Microsystems
   17 Network Circle
   Menlo Park, CA 94025
   USA

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











































Choi & Nordmark         Expires October 23, 2005               [Page 18]


Internet-Draft           DNA solution framework               April 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 & Nordmark         Expires October 23, 2005               [Page 19]