DNA WG                                                    JinHyeock Choi
Internet-Draft                                               Samsung AIT
Expires: December 10, 2004                                    Greg Daley
                                                  CTIE Monash University
                                                           June 11, 2004

               Detecting Network Attachment in IPv6 Goals

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 10, 2004.

Copyright Notice

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


   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.  While
   checking for link change, 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 December 10, 2004                [Page 1]

Internet-Draft                 DNA Goals                       June 2004

   Detecting Network Attachment (DNA).

   Rapid attachment detection is required when a host has on-going data
   traffic.  Current DNA schemes are inadequate to support real-time
   applications.  The existing procedures for advertising network
   information incur reception delays and do not provide enough
   information to properly determine the identity of links.  For
   to-be-defined, efficient DNA schemes, a way to correctly represent a
   link change, a complete and consistent procedure for network
   information advertisement and a rapid delivery of the advertisements
   will be necessary.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Detecting Network Attachment in Existing IPv6 Systems  . . . .  5
   3.  Problems in Detecting Network Attachment . . . . . . . . . . .  7
     3.1   Wireless link properties . . . . . . . . . . . . . . . . .  7
     3.2   Inadequacies in RA information . . . . . . . . . . . . . .  7
     3.3   Delays . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Goals for Detecting Network Attachment . . . . . . . . . . . . 10
     4.1   Goals list . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 15
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 15
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . 17

Choi & Daley           Expires December 10, 2004                [Page 2]

Internet-Draft                 DNA Goals                       June 2004

1.  Introduction

   When a host has established a new link-layer connection, it can send
   and receive some IP 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

   When a link-layer connection is established or re-established, the
   host doesn't 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.  A 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.

   While other information for IP connectivity (such as DNS server
   configuration) is also important, obtaining most of such information
   depends on the determination of correct global addressing and valid
   default router configuration.

   Hence, to determine the need of a further configuration, a host needs
   to check at least that:

    1) Whether it knows a (partially) reachable default router.
    2) Whether it possesses a valid IP address.

   Partial reachability indicates that the host is able to receive
   packets from the router, but not necessarily vice versa.

   To examine the status of the existing configuration, a host may check
   whether a 'link change' has occurred.

   Today a link change necessitates an IP configuration change.
   Whenever the 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 a host only needs to check for link change to
   examine the validity of its IP configuration.

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

Choi & Daley           Expires December 10, 2004                [Page 3]

Internet-Draft                 DNA Goals                       June 2004

   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,
   detects the identity of its currently attached link, and ascertains
   the validity of its IP configuration, is called Detecting Network
   Attachment (DNA).

   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.

Choi & Daley           Expires December 10, 2004                [Page 4]

Internet-Draft                 DNA Goals                       June 2004

2.  Detecting Network Attachment in Existing IPv6 Systems

   When a host changes its attachment point, for efficiency, a host
   should examine whether its IP configuration is still valid before
   initiating the process of acquiring a new IP configuration.

   DNA process aims to examine whether a host's current IP configuration
   is still valid.  To achieve this goal, DNA process checks whether the
   host is still at the same link.  Also, DNA process collects necessary
   information for a new IP configuration.

   For this, the following mechanisms and data are available to hosts:

    1) Router Solicitation/Router Advertisement (RS/RA) messages
    2) Neighbor Solicitation/Neighbor Advertisement (NS/NA) messages
    3) Information provided by the link-layer

   Currently there is no way to represent the identity of links such
   that link changes can be detected instantly.  The information in the
   above messages cannot be used to unambiguously identify links.
   Section 3 gives the detail.

   Though the set of all the assigned prefixes may be used to represent
   a link identity, it is difficult for a host to attain and retain all
   the prefixes with certainty.  Moreover there may be  links without
   any advertised prefix.

   Hence, to check for link change, as of today, a host must resort to
   guessing, based on Router Discovery and Neighbor Unreachability
   Detection (NUD).  A host can examines whether 1) its existing default
   router is still reachable and 2) its IP addresses are still valid.

   After a network attachment, a host receives new (solicited or
   unsolicited) RAs and compares them with the previously received ones.
   It checks whether the information in the new RAs, the prefixes and
   the router addresses, matches with the stored ones, the configured IP
   addresses and the default router addresses.

   If Router Discovery fails to update the existing router's
   information, it indicates that the router is unreachable and should
   not be used.

   For Internet connectivity, a host needs to have an IP address whose
   prefix is assigned on the current link.  To check the validity of its
   IP addresses, a host examines whether the prefix of its IP addresses
   are present in the Prefix Information Option of received RAs.

   Even if an address prefix is valid, an individual address is known to

Choi & Daley           Expires December 10, 2004                [Page 5]

Internet-Draft                 DNA Goals                       June 2004

   be valid only after the Duplicate Address Detection (DAD) procedure
   [5] has been completed.

   If RAs indicate that a subnet change has occured, the invalidity of
   other IP subnet information is implied.

   At the same time, from the received RAs, a host may collect some of
   the necessary information for a new configuration: a prefix to form a
   new IP address and router addresses to select a new default router.

   For rapid attachment detection, it is necessary for a host to receive
   an RA quickly enough.

   A host may also use NS/NA exchange to examine the reachability of the
   existing default router.  Upon detecting a new link-layer connection,
   the host may probe the router with an NS message.  If it receives an
   appropriate NA message, the router is still reachable.  Otherwise, if
   the host receives no replies to Neighbor Solicitations, it may assume
   that its default router is no longer reachable.

   If a host receives a message from a router with which it has
   previously been able to exchange packets, then the Neighbor Discovery
   procedure may be used to establish full bi-directional reachability.

   In some environments, link-layer information regarding IP
   connectivity may be considered as a strong hint that change of
   link-layer attachment implies change of IP subnet.  While this is
   sometimes the case, not all IP implementations at the network layer
   will be able to understand the indication from the link-layers, nor
   will those indications necessarily be always sufficient to make a
   proper decision.

   If the information from the link layer is available, but it is not
   considered authoritative, the information may still be used as a
   'Link-layer hint'.  Link-layer hints are indications from lower
   layers that IP connectivity may have changed.  With suitable
   hysteresis, these hints may be used to initiate IP based reachability

Choi & Daley           Expires December 10, 2004                [Page 6]

Internet-Draft                 DNA Goals                       June 2004

3.  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 the
   information contained in RA messages is not adequate for efficient
   DNA.  Third, Router Discovery or NUD may take too long and result in
   service disruption.

3.1  Wireless link properties

   1) Unclear boundary

   Unlike wired environments, what constitutes wireless link is variable
   in both time and space.  It doesn't have clear boundaries.  This may
   be illustrated by the fact that a host may contact multiple (802.11)
   access points at the same time.  Moreover reachability on a wireless
   link is very volatile, which may make link detection hard.

   2) Asymmetric reachability

   In some wireless environments, it may be possible to receive
   periodically multicast advertisement information without being able
   to send IP packets to the network.  In these cases, it is
   insufficient to rely upon reception of unsolicited advertisement
   information as confirmation of router reachability.

3.2  Inadequacies in RA information

   Usually a host receives the information necessary for IP
   configuration from RA messages.  Based on the current definition [4],
   the information contained in RA messages is inadequate to represent a
   link change.  RA messages are not designed to represent link
   identities and have inherent ambiguities.

   1) Link local scope of Router Address

   Usually a router address is contained in the source address field of
   RA messages.  That router address is link-local scope and its
   uniqueness can't be guaranteed out side of a link.

   So if it happens that two different router interfaces have the same
   link-local address, a host can't detect that it has moved from one
   interface to another by checking the router address in RA messages.

   On the other hand, a host can't be sure that its default router is
   reachable, even if it can communicate with the router that has the
   same address as its existing router address.  That router may be a
   different one, which happens to have the same link-local address as

Choi & Daley           Expires December 10, 2004                [Page 7]

Internet-Draft                 DNA Goals                       June 2004

   its default router address.

   2) Omission of Prefix Information Option

   To check the validity of its IP address, a host should examine
   whether the prefix of its IP address is advertised on the link to
   which it is currently attached.

   The host checks whether the prefix of its IP addresses are present in
   the Prefix Information Option of incoming RA messages.  But an
   unsolicited RA message can omit some prefixes for convenience, for
   example to save bandwidth [4].

   Hence, the host can't be sure that the prefix of its current IP
   address is not supported on the current link, even though the prefix
   is not contained in a received RA.

3.3  Delays

   The following issues cause DNA delay that may result in communication

   1) Delay for receiving a hint

   For rapid attachment detection, hints can be used to tell a host that
   a link change might have happened.  This hint itself doesn't confirm
   a link change, but can be used to initiate the appropriate

   Hints come in various forms, and differ in how they indicate a new
   attachment.  They can be link-layer indications, 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 a new network attachment as a hint for a possible link
   change.  With link-layer support, a host can receive a hint almost

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

   Without the schemes such as above, a host must receive a new RA from
   a new router to detect a possible link change.  The detection time

Choi & Daley           Expires December 10, 2004                [Page 8]

Internet-Draft                 DNA Goals                       June 2004

   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, the host is expected to arrive on average half way
   through the interval.  This is approximately 1.75 seconds with [4]
   advertisement rates.

   2) Delay for checking current default router Unreachability

   When a host examines the reachability of the current default router,
   a certain delay occurs if the current default router is not

   Usually it's easier to detect a node's presence than its absence.  A
   host sends a solicitation message and, upon the receipt of a reply,
   it can assume that it's there.

   To be sure that a node is absent, time needs to be taken to ensure
   that the lack of a reply is not due to another reasons (for example,
   packet loss, MAC latency, or processing delay).  So it takes time to
   verify the unreachability of the current router.

   After a host moves to another link, if it uses NUD for detection, it
   will take more than 3 seconds to recognize that the current router is
   no longer reachable [4].

   3) 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 to send an RS and for a router
   to wait to reply an RA.

   Before a host sends an initial solicitation, it SHOULD delay the
   transmission for a random amount of time between 0 and
   MAX_RTR_SOLICITATION_DELAY (1 second).  Also Router Advertisements
   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 December 10, 2004                [Page 9]

Internet-Draft                 DNA Goals                       June 2004

4.  Goals for Detecting Network Attachment

   DNA solutions should be 1) Precise, 2) Sufficiently fast and 3) Of
   limited signaling.  The solutions should correctly determine whether
   a link change has occurred.  They also should be sufficiently fast
   lest there should be service disruption.  They should not flood the
   link with related signaling.

   It will be necessary to investigate the usage of available tools, NS/
   NA messages, RS/RA messages, link-layer hints and other features.
   This will allow precise description of procedures for efficient DNA

4.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 rapidly,
      with minimal latency.

   G3 In the case where a host has not changed a link or subnet, 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

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

   G8 A host configured for DNA should not expose itself to additional
      man in the middle or identity revealing attacks.

   G9 A host or router configured for DNA should not expose itself or
      other devices on the link to additional denial of service attacks.

Choi & Daley           Expires December 10, 2004               [Page 10]

Internet-Draft                 DNA Goals                       June 2004

   G10 The Routers supporting DNA should work appropriately with hosts
      using unmodified configuration schemes, such as [4] and [6].

   G11 The Hosts supporting DNA should be able to work with unmodified
      routers and hosts which do not support DNA schemes.

Choi & Daley           Expires December 10, 2004               [Page 11]

Internet-Draft                 DNA Goals                       June 2004

5.  IANA Considerations

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

Choi & Daley           Expires December 10, 2004               [Page 12]

Internet-Draft                 DNA Goals                       June 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 [8] 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.

   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 duplicates or stale.  This may reduce the effective
   window for attackers replaying otherwise authentic data.

   It may be dangerous to receive link-change indications from
   link-layer and network-layer, if they are received from devices which
   are insufficiently authenticated.  In particular, indications 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 December 10, 2004               [Page 13]

Internet-Draft                 DNA Goals                       June 2004

7.  Acknowledgment

   Erik Nordmark has contributed significantly [11] 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 and Alper Yegin for
   their contributions to this draft.

Choi & Daley           Expires December 10, 2004               [Page 14]

Internet-Draft                 DNA Goals                       June 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]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
        RFC 3315, July 2003.

   [7]  Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
        Roadmap", RFC 2411, November 1998.

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

8.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]  Nordmark, E., "MIPv6: from hindsight to foresight?",
         draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
         November 2001.

Choi & Daley           Expires December 10, 2004               [Page 15]

Internet-Draft                 DNA Goals                       June 2004

Authors' Addresses

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

   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

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

Choi & Daley           Expires December 10, 2004               [Page 16]

Internet-Draft                 DNA Goals                       June 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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Choi & Daley           Expires December 10, 2004               [Page 17]