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

Versions: (draft-jinchoi-dna-goals) 00 01 02 03 04 RFC 4135

DNA WG                                                    JinHyeock Choi
Internet-Draft                                               Samsung AIT
Expires: March 31, 2005                                       Greg Daley
                                                  CTIE Monash University
                                                      September 30, 2004


               Detecting Network Attachment in IPv6 Goals
                      draft-ietf-dna-goals-02.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 March 31, 2005.

Copyright Notice

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

Abstract

   At the time a host establishes a new link-layer connection, it may or
   may not have a valid IP configuration for Internet connectivity.  The
   host may check for link change, i.e.  determine whether a link change
   has occurred, and then, based on the result, it can automatically
   decide whether its IP configuration is still valid or not.  During
   link identity detection, the host may also collect necessary
   information to initiate a new IP configuration for the case that the
   IP subnet has changed.  In this memo, this procedure is called



Choi & Daley             Expires March 31, 2005                 [Page 1]

Internet-Draft                 DNA Goals                  September 2004


   Detecting Network Attachment (DNA).  DNA schemes should be precise,
   sufficiently fast, secure and of limited signaling.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problems in Detecting Network Attachment . . . . . . . . . . .  5
     2.1   Wireless link properties . . . . . . . . . . . . . . . . .  5
     2.2   Link identity detection with a single RA . . . . . . . . .  5
     2.3   Delays . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Goals for Detecting Network Attachment . . . . . . . . . . . .  8
     3.1   Goals list . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15































Choi & Daley             Expires March 31, 2005                 [Page 2]

Internet-Draft                 DNA Goals                  September 2004


1.  Introduction

   When a host has established a new link-layer connection, it can send
   and receive some IPv6 packets at the link, particularly those used
   for configuration.  On the other hand, the host has full Internet
   connectivity only when it is able to exchange packets with arbitrary
   destinations.

   When a link-layer connection is established or re-established, the
   host may not know whether its existing IP configuration is still
   valid for Internet connectivity.  A subnet change might have occurred
   when the host changed its attachment point.

   In practice, the host doesn't know which of its addresses are valid
   on the newly attached link.  The host knows neither if its existing
   default router is on this link, nor whether its neighbor cache
   entries are valid.  Correct configuration of each of these components
   are necessary in order to send packets on and off the link.

   To examine the status of the existing configuration, a host may check
   whether a 'link change' has occurred.  The term 'link' used in this
   document is as defined in RFC 2461 [4].  The notion 'link' is not
   identical with the notion 'subnet' as defined in RFC 3753 [7].  For
   example, there may be more than one subnets on a link and a host
   connected to a link may be part of one or more of the subnets on the
   link.

   Today, a link change necessitates an IP configuration change.
   Whenever a host detects that it has remained at the same link, it can
   usually assume its IP configuration is still valid.  Otherwise, the
   existing one is no longer valid and a new configuration must be
   acquired.  Hence, to examine the validity of an IP configuration, all
   that is required is that the host checks for link change.

   In the process of checking for link change, a host may collect some
   of the necessary information for a new IP configuration, such as
   on-link prefixes.  So, when an IP subnet change has occurred, the
   host can immediately initiate the process of getting a new IP
   configuration.  This may reduce handoff delay and minimize signaling.

   Rapid attachment detection is required for a device that changes
   subnet while having on-going sessions.  This may be the case if a
   host is connected intermittently, is a mobile node, or has urgent
   data to transmit upon attachment to a link.

   The process by which a host collects the appropriate information and
   detects the identity of its currently attached link to ascertains the
   validity of its IP configuration, is called Detecting Network



Choi & Daley             Expires March 31, 2005                 [Page 3]

Internet-Draft                 DNA Goals                  September 2004


   Attachment (DNA).

   DNA schemes are typically run per interface.  When a host has
   multiple interfaces, the host separately checks for link changes on
   each interface.

   It is important to note that DNA process does not include the actual
   IP configuration procedure.  For example, with respect to DHCP, the
   DNA process may determine that the host needs to get some
   configuration information from a DHCP server.  However, the process
   of actually retrieving the information from a DHCP server falls
   beyond the scope of DNA.

   This draft considers the DNA procedure only from the IPv6 point of
   view, unless otherwise explicitly mentioned.  Hence, the term "IP" is
   to be understood to denote IPv6, by default.  For the IPv4 case,
   refer [13].


































Choi & Daley             Expires March 31, 2005                 [Page 4]

Internet-Draft                 DNA Goals                  September 2004


2.  Problems in Detecting Network Attachment

   There are a number of issues that make DNA complicated.  First,
   wireless connectivity is not as clear-cut as wired one.  Second, it's
   difficult for a single RA message to indicate a link change.  Third,
   Router Discovery may take too long and result in service disruption.

2.1  Wireless link properties

   Unlike wired environments, what constitutes a wireless link is
   variable both in time and space.  Wireless links do not have clear
   boundaries.  This may be illustrated by the fact that a host may be
   within the coverage area of multiple (802.11) access points at the
   same time.  Moreover, connectivity on a wireless link can be very
   volatile, which may make link identity detection hard.  For example,
   it takes time for a host to check for link change.  If the host
   ping-pongs between two links and doesn't stay long enough at a given
   link, it can't complete the DNA procedure.

2.2  Link identity detection with a single RA

   Usually a host gets the information necessary for IP configuration
   from RA messages.  Based on the current definition [4], it's
   difficult for a host to check for link change upon a single RA
   reception.

   To detect link identity, a host may compare the information in an RA,
   such as router address or prefixes, with the locally stored
   information.

   The host may use received router addresses to check for link change.
   The router address in the source address field of an RA is of
   link-local scope, however, so its uniqueness is not guaranteed
   outside of a link.  If it happens that two different router
   interfaces on different links have the same link-local address, the
   host can't detect that it has moved from one link to another by
   checking the router address in RA messages.

   The set of all the global prefixes assigned to a link can represent
   link identity.  The host may compare the prefixes in an incoming RA
   with the currently stored ones.  An unsolicited RA message, however,
   can omit some prefixes for convenience [4] and it's not easy for a
   host to attain and retain all the prefixes on a link with certainty.
   Hence, neither the absence of a previously known prefix nor the
   presence of a previously unknown prefix in the RA guarantees that a
   link change has occurred.





Choi & Daley             Expires March 31, 2005                 [Page 5]

Internet-Draft                 DNA Goals                  September 2004


2.3  Delays

   The following issues cause DNA delay that may result in communication
   disruption.

   1) Delay for receiving a hint

   Hint is an indication that a link change might have occurred.  This
   hint itself doesn't confirm a link change, but initiates appropriate
   DNA procedures to detect the identity of the currently attached link.

   Hints come in various forms, and differ in how they indicate a
   possible link change.  They can be link-layer event notifications
   [12], the lack of RA from the default router, or the receipt of a new
   RA.  The time taken to receive a hint also varies.

   As soon as a new link-layer connection has been made, the link-layer
   may send a link up notification to the IP layer.  A host may
   interpret the new link-layer connection as a hint for a possible link
   change.  With link-layer support, a host can receive such a hint
   almost instantly.

   Mobile IPv6 [9] defines the use of RA Interval Timer expiry for a
   hint.  A host keeps monitoring for periodic RAs and interprets the
   lack of them as a hint.  It may implement its own policy to determine
   the number of missing RAs needed to interpret that as a hint.  Hence,
   the delay depends on the Router Advertisement interval.

   Without schemes such as the ones above, a host must receive a new RA
   from a new router to detect a possible link change.  The detection
   time then also depends on the Router advertisement frequency.

   Periodic RA beaconing transmits packets within an interval varying
   randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.
   Because a network attachment is unrelated to the advertisement time
   on the new link, hosts are expected to arrive, on average, half way
   through the interval.  This is approximately 1.75 seconds with
   Neighbor Discovery [4] advertisement rates.

   2) Random delay execution for RS/ RA exchange

   Router Solicitation and Router Advertisement messages are used for
   Router Discovery.  According to [4], it is sometimes necessary for a
   host to wait a random amount of time before it may send an RS, and
   for a router to wait before it may reply with an RA.

   Before a host sends an initial solicitation, it SHOULD delay the
   transmission for a random amount of time between 0 and



Choi & Daley             Expires March 31, 2005                 [Page 6]

Internet-Draft                 DNA Goals                  September 2004


   MAX_RTR_SOLICITATION_DELAY (1 second).  Furthermore, any Router
   Advertisement sent in response to a Router Solicitation MUST be
   delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5
   seconds).















































Choi & Daley             Expires March 31, 2005                 [Page 7]

Internet-Draft                 DNA Goals                  September 2004


3.  Goals for Detecting Network Attachment

   The DNA working group has been chartered to define an improved scheme
   for detecting IPv6 network attachment.  In this section, we define
   the goals that any such solutions should aim to fulfil.

   DNA solutions should correctly determine whether a link change has
   occurred.  Additionally, they should be sufficiently fast so that
   there would be no or at most minimal service disruption.  They should
   neither flood the link with related signaling nor introduce new
   security holes.

   When defining new solutions, it is necessary to investigate the usage
   of available tools, NS/NA messages, RS/RA messages, link-layer event
   notifications [12], and other features.  This will allow precise
   description of procedures for efficient DNA Schemes.

3.1  Goals list

   G1 DNA schemes 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.

   G2 When upper-layer protocol sessions are being supported, DNA
      schemes should detect the identity of an attached link with
      minimal latency lest there should be service disruption.

   G3 In the case where a host has not changed a link, DNA schemes
      should not falsely assume a link change and an IP configuration
      change should not occur.

   G4 DNA schemes should not cause undue signaling on a link.

   G5 DNA schemes should make use of existing signaling mechanisms where
      available.

   G6 DNA schemes should make use of signaling within the link
      (particularly link-local scope messages), since communication
      off-link may not be achievable in the case of a link change.

   G7 DNA schemes should be compatible with security schemes such as
      Secure Neighbour Discovery [8].







Choi & Daley             Expires March 31, 2005                 [Page 8]

Internet-Draft                 DNA Goals                  September 2004


   G8 DNA schemes should not introduce new security vulnerabilities.
      The node supporting DNA schemes should not expose itself or others
      on a link to additional man in the middle, identity revealing, or
      denial of service attacks.

   G9 The nodes, such as routers or hosts, supporting DNA schemes should
      work appropriately with unmodified nodes, such as routers or
      hosts, which do not support DNA schemes.

   G10 Hosts, in particular wireless environments, may perceive routers
      reachable on different links.  DNA schemes should take into
      consideration the case where a host is attached to more than one
      link at the same time.






































Choi & Daley             Expires March 31, 2005                 [Page 9]

Internet-Draft                 DNA Goals                  September 2004


4.  IANA Considerations

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
















































Choi & Daley             Expires March 31, 2005                [Page 10]

Internet-Draft                 DNA Goals                  September 2004


5.  Security Considerations

   Because DNA schemes are based on Neighbor Discovery, its trust models
   and threats are similar to the ones presented in RFC 3756 [10].
   Nodes connected over wireless interfaces may be particularly
   susceptible to jamming, monitoring, and packet insertion attacks.

   With unsecured DNA schemes, it is inadvisable for a host to adjust
   its security based on which network it believes it is attached to.
   For example, it would be inappropriate for a host to disable its
   personal firewall based on the belief that it had connected to a home
   network.

   Even in the case where authoritative information (routing and prefix
   state) are advertised, wireless network attackers may still prevent
   soliciting nodes from receiving packets.  This may cause unnecessary
   IP configuration change in some devices.  Such attacks may be used to
   make a host preferentially select a particular configuration or
   network access.

   Devices receiving confirmations of reachability (for example from
   upper-layer protocols) should be aware that unless these indications
   are sufficiently authenticated, reachability may falsely be asserted
   by an attacker.  Similarly, such reachability tests, even if known to
   originate from a trusted source, should be ignored for reachability
   confirmation if the packets are not fresh, or have been replayed.
   This may reduce the effective window for attackers replaying
   otherwise authentic data.

   It may be dangerous to receive link-change notifications from
   link-layer and network-layer, if they are received from devices which
   are insufficiently authenticated.  In particular, notifications that
   authentication has completed at the link-layer may not imply that a
   security relationship is available at the network-layer.  Additional
   authentication may be required at the network layer to justify
   modification of IP configuration.















Choi & Daley             Expires March 31, 2005                [Page 11]

Internet-Draft                 DNA Goals                  September 2004


6.  Acknowledgment

   Erik Nordmark has contributed significantly to work predating this
   draft.  Also Ed Remmell's comments on the inconsistency of RA
   information were most illuminating.  The authors wish to express our
   appreciation to Pekka Nikander for valuable feedback.  We gratefully
   acknowledge the generous assistance we received from Shubhranshu
   Singh for clarifying the structure of the arguments.  Thanks to Brett
   Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim
   Bound and Jari Arkko for their contributions to this draft.









































Choi & Daley             Expires March 31, 2005                [Page 12]

Internet-Draft                 DNA Goals                  September 2004


7.  References

7.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]  Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
        Roadmap", RFC 2411, November 1998.

   [7]  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
        3753, June 2004.

   [8]  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.2  Informative References

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

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

   [11]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

   [12]  Yegin, A., "Link-layer Event Notifications for Detecting
         Network Attachments", draft-ietf-dna-link-information-00 (work
         in progress), September 2004.

   [13]  Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
         draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004.




Choi & Daley             Expires March 31, 2005                [Page 13]

Internet-Draft                 DNA Goals                  September 2004


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


   Greg Daley
   CTIE Monash University
   Centre for Telecommunications and Information Engineering
   Monash University
   Clayton 3800 Victoria
   Australia

   Phone: +61 3 9905 4655
   EMail: greg.daley@eng.monash.edu.au






























Choi & Daley             Expires March 31, 2005                [Page 14]

Internet-Draft                 DNA Goals                  September 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 & Daley             Expires March 31, 2005                [Page 15]


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