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

Versions: 00                                                            
DNA WG                                                    JinHyeock Choi
Internet-Draft                                               Samsung AIT
Expires: January 10, 2005                                  Erik Nordmark
                                                        SUN Microsystems
                                                           July 12, 2004


                         DNA solution framework
                  draft-jinchoi-dna-soln-frame-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 January 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This draft captures the authors' personal 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 Identifier, 2) RA optimized for DNA
   and 3) Quick delivery of an RA and sketches what rough shape DNA
   solution will take.  It also enumerate a few tasks to be worked on
   and issues to be resolved for efficient DNA solution.




Choi & Nordmark         Expires January 10, 2005                [Page 1]


Internet-Draft           DNA solution framework                July 2004


Table of Contents

   1.  DNA Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Basic Assumptions  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   DNA solution based on link identity detection  . . . . . .  4
     2.2   Checking for link change with Link Identifier  . . . . . .  4
     2.3   RA message optimized for DNA . . . . . . . . . . . . . . .  4
     2.4   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 . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1   Link Identifier  . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1   Assign rule: Uniqueness  . . . . . . . . . . . . . . .  8
       4.1.2   Format . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.3   Interpretation Rule: Explicit versus Implicit  . . . .  8
       4.1.4   Configuration method: Dynamic configuration  . . . . .  8
       4.1.5   Advertisement rule: When to be included in an RA?  . .  9
       4.1.6   Links without Link Identifier support  . . . . . . . .  9
     4.2   RA optimized for DNA . . . . . . . . . . . . . . . . . . .  9
     4.3   Quick delivery of an RA upon link-layer connection . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 14
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16





















Choi & Nordmark         Expires January 10, 2005                [Page 2]


Internet-Draft           DNA solution framework                July 2004


1.  DNA Overview

   Upon establishing a new link-layer connection, DNA solution should
   detect the identity of the currently attached link to ascertain the
   validity of the existing IP configuration.  They should recognize and
   determine whether a link change has occurred and initiate the process
   of acquiring a new configuration if necessary.  DNA solution needs to
   be fast, precise, secure and of little signaling overhead.[7]











































Choi & Nordmark         Expires January 10, 2005                [Page 3]


Internet-Draft           DNA solution framework                July 2004


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, to check whether
   its IP configuration is still valid, a host checks for link change,
   i.e.  determine whether it still remains at the same link or not.
   The term 'link' used in this document is as defined in [4].

   If a link change has occurred, a host assumes that its IP
   configuration is no longer valid.  It needs new default router and IP
   address.  If it remains at the same link, a host assumes its IP
   configuration is still valid.  Its default router is still reachable
   and IP address is still valid.

2.2  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.  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 Link Identifier and all
   routers in the link advertise the same Link Identifier in RAs.  With
   a 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 Link Identifier.
   We may define a new option for Link Identifier.  In [11] 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 [12].

2.3  RA message optimized for DNA

   It will be nice for a host if, with the reception of just one RA
   message, it can 1) check for link change and 2) collect necessary



Choi & Nordmark         Expires January 10, 2005                [Page 4]


Internet-Draft           DNA solution framework                July 2004


   information to initiate a new IP configuration.  This will reduce
   handoff delay and minimize signaling traffic.

   For this, an RA message needs to include at least:

   1) Link Identifier (to check for link change)
   2) Router address (to select new default router, in case of a link
      change)
   3) Prefix (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 that the above is (necessary) and sufficient.

2.4  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 [4].  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 January 10, 2005                [Page 5]


Internet-Draft           DNA solution framework                July 2004


3.  DNA Solution Sketch

3.1  Solution components

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

   1.  Link Identifier to represent a link identity properly.
   2.  RA message optimized for DNA, which carries 1) Link Identifier
      and 2) necessary information for a new IP configuration.
   3.  A way to quickly deliver an RA to a host upon a new link-layer
      connection.
   4.  Optimistic DAD [17] and TSLLAO [18] that is being specified in
      the IPv6 WG.

3.2  Solution procedure

   With the above, DNA procedure may be like below.

   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.  The link-layer
   (device driver) may provide link-up indication to the IP layer of the
   host.

   Since the host doesn't know whether it is still attached to the same
   link, it takes 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).  As a result of
   this, the RS message contains the TSLLA option [18].

   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 [14]) 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 RA from the router
   would not be delayed; something which solves the problem identified
   in [15], [16] would be needed.  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



Choi & Nordmark         Expires January 10, 2005                [Page 6]


Internet-Draft           DNA solution framework                July 2004


   with the host before unicasting the RA to the host.

   Step [3] Link identity detection

   The host compares the Link Identifier in the RA with the previous
   stored one.

   If it is the same, the host assumes that it still remains at the same
   link.  No further DNA operation is performed and all it needs to do
   is turn off the optimistic DAD mode.

   If the host receives a different Link Identifier, the host decides
   that it has moved to a new link and 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 would take one or two more
   roundtrips.) The host also needs to perform DAD by sending the DAD
   probe.  When the DAD probing has completed the host can turn off the
   optimistic DAD mode.

   If neither the old link and the potentially new link use Link
   Identifier, then the host needs to use prefix based link
   determination [13] which might require multiple RAs and even multiple
   RSs being sent.

3.3  Work items

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

   1.  Link Identifier [11], [12]
   2.  Prefix based Approach when Link Identifier is not available[13]
   3.  Immediate RA responses to RS [15], [16]
   4.  Optionally RAs that are sent by APs [14]
   5.  Optimistic DAD [17] and TSLLAO [18]















Choi & Nordmark         Expires January 10, 2005                [Page 7]


Internet-Draft           DNA solution framework                July 2004


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  Link Identifier

   A Link Identifier is included in an RA to indicate a link change.
   Here are related issues.

4.1.1  Assign rule: Uniqueness

   A Link Identifiers should be assigned in such a way that a host could
   detect a link change if it moves from one link to another.  Hence two
   adjacent links should not have the same Link Identifier.

   For this, there are two different ways.

   1.  We assign each link a globally unique Link Identifier.
   2.  We assign each link a locally unique Link Identifier.  'Locally
      unique' means, no two adjacent links have the same Link
      Identifier.

   Though, in theory, local uniqueness is sufficient, it may entail
   several complications.  For simplicity's sake, it may be better to
   assign a globally unique Link Identifier.

4.1.2  Format

   For Link Identifier, we may define a new option.  For example
   'Location Indication Option' in [11] or 'Link ID Option' in [12].  We
   need to investigate an efficient way.

4.1.3  Interpretation Rule: Explicit versus Implicit

   We have to decide how a host interprets an RA without a Link
   Identifier, i.e.  will a host interpret the lack of the same Link
   Identifier as confirmation that a link change has occurred?

4.1.4  Configuration method: Dynamic configuration

   The multiple routers in a link should advertise the same Link
   Identifier.  We can manually configure all routers the same Link
   Identifier.  But it will be convenient to have a way to dynamically
   configure the same Link Identifier to all routers.






Choi & Nordmark         Expires January 10, 2005                [Page 8]


Internet-Draft           DNA solution framework                July 2004


4.1.5  Advertisement rule: When to be included in an RA?

   A Link Identifier is advertised in an RA.  We have to resolve whether
   a Link Identifier should be included in all RA messages or in
   specific ones.

   It seems benefitial to include a Link Identifier at least in every RA
   that is sent in response to an RS.

   Also, if frequent multicast RAs are used as "beacons" (which might be
   needed when the hosts do not receive a "link-up" indication from the
   device driver), those beacons should also contain a Link Identifier.

   It might be simplest to include a Link Identifier in every RA.

4.1.6  Links without Link Identifier support

   A host may visit a link that doesn't support Link Identifier.  There
   are a few cases to consider.

   1  Moving from one link using Link Identifier to another link using
      Link Identifier (and the Link Identifiers are different).
   2  Moving from a link using Link Identifier to a link which is not
      using Link Identifier.
   3  Moving from a link not using Link Identifier to a link which is
      using Link Identifier.
   4  Moving from a link not using Link Identifier to a link which is
      not using Link Identifier.

   Even in such cases, the host needs to be able to perform DNA.

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 informations in Sec 2.3 and also it may be useful for an RA
   to include the following.

   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 an
   RA.  A host may passively receive a periodic RA or, with link-layer
   hint, actively send an RS message and receive a solicited RA.

   For the first case, the time to receive a RA depends on RA



Choi & Nordmark         Expires January 10, 2005                [Page 9]


Internet-Draft           DNA solution framework                July 2004


   advertisement interval and it may take several seconds.  Even with
   solicitation, a router MUST wait random amount of time between 0 and
   0.5 sec before replying an RA [4].  And if the router multicasts RAs
   in response to RSs, the MIN_DELAY_BETWEEN_RAS in [4] is also a
   potential problem which must be looked into.  Otherwise this would
   add the worse-case delay of 3 seconds until an RA is received.This
   may result in service disruption.

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




































Choi & Nordmark         Expires January 10, 2005               [Page 10]


Internet-Draft           DNA solution framework                July 2004


5.  IANA Considerations

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
















































Choi & Nordmark         Expires January 10, 2005               [Page 11]


Internet-Draft           DNA solution framework                July 2004


6.  Security Considerations

   Because DNA schemes are based on Neighbor Discovery, its trust models
   and threats are similar to the ones presented in [10].  Nodes
   connected over wireless interfaces may be particularly susceptible to
   jamming, monitoring and packet insertion attacks.  Use of [9] 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 January 10, 2005               [Page 12]


Internet-Draft           DNA solution framework                July 2004


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 January 10, 2005               [Page 13]


Internet-Draft           DNA solution framework                July 2004


8.  References

8.1  Normative References

   [1]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
        February 2004.

   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
        BCP 79, RFC 3668, February 2004.

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

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

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

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

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

8.2  Informative References

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

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

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

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

   [12]  Pentland, B., "Router Advertisement Link Identification for
         Mobile IPv6 Movement  Detection",
         draft-pentland-mobileip-linkid-00 (work in progress), May 2003.

   [13]  Choi, J. and E. Nordmark, "DNA with unmodified routers:
         Prefix list based approach", draft-jinchoi-dna-cpl-00.txt
         (work in progress), July 2004.



Choi & Nordmark         Expires January 10, 2005               [Page 14]


Internet-Draft           DNA solution framework                July 2004


   [14]  Choi, J. and D. Shin, "Fast Router Discovery with RA Caching in
         AP", draft-jinchoi-mobileip-frd-00 (work in progress), February
         2003.

   [15]  Kempf, J., Khalil, M. and B. Pentland, "IPv6 Fast Router
         Advertisement", draft-mkhalil-ipv6-fastra-02 (work in
         progress), October 2002.

   [16]  Daley, G., Pentland, B. and E. Nordmark, "Deterministic Fast
         Router Advertisement Options, draft-daley-dna-det-fastra-00.
         (work in progress), July 2004.

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

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


Authors' Addresses

   JinHyeock Choi
   Samsung AIT
   i-Networking Lab
   P.O.Box 111 Suwon 440-600
   KOREA

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


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

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










Choi & Nordmark         Expires January 10, 2005               [Page 15]


Internet-Draft           DNA solution framework                July 2004


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 (2004).  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 January 10, 2005               [Page 16]