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

Versions: 00

                                                           JinHyeock Choi
Internet Draft                                                Samsung AIT
Expires: August 2004                                           Greg Daley
                                                   Monash University CTIE
                                                            February 2004


                 Detecting Network Attachment in IPv6 Goals
                       draft-jinchoi-dna-goals-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC 2026].

   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.

   Definitions of requirements keywords are in accordance with the IETF
   Best Current Practice - [RFC 2119]


Abstract

   Upon establishing a new link-layer connection, a host may or may not
   have valid IP configuration for Internet Connectivity. A host may
   determine whether its IP configuration is valid by checking Network
   Layer link change. With the information gathered, a host may decide
   if their own configuration needs to be updated and initiate a new
   configuration in case of link change. This procedure is described as
   Detecting Network Attachment.

   Rapid attachment detection is required for devices, which connect to
   or disconnect from IP networks while they have existing upper-layer
   protocol sessions. Current schemes for detecting link change are
   inadequate to support real-time applications. The existing procedures
   for transmission routing and prefix configuration information lead to


Choi, Daley             Expires - August 2004                [Page 1]

Internet-Draft               DNAv6 Goals                     Feb 2004


   ambiguous link determination and reception delays. For efficient
   detection of network attachment, a way to correctly represent link
   change, complete and consistent routing information advertisement and
   rapid advertisement delivery to hosts will be necessary.


Table of Contents

   1. Introduction...................................................2
   2. The Tasks of Network Attachment Detection......................3
   3. Application of Network Attachment Detection....................4
   4. Network Attachment Detection in Existing IPv6 Systems..........5
   5. Problems for Network Attachment Detection......................7
      5.1 Wireless link properties...................................7
      5.2 The Inadequacy of RA information...........................7
      5.3 Time delay.................................................8
   6. The Goals of Network Attachment Detection.....................10
      6.1 Potential Solution space..................................10
      6.2 Goals list................................................11
   7. IANA Consideration............................................12
   8. Security Consideration........................................12
   References.......................................................13
   Acknowledgments..................................................13
   Author's Addresses...............................................14


1. Introduction

   Link change may occur when a new link-layer connection is established.
   At this stage, a node should be able to send and receive some IP
   packets within a link, particularly those used for configuration
   purposes. Subsequently Internet Connectivity occurs when a node is
   able to send packets to arbitrary Internet destinations.

   Though link-layer connection is made, a node may or may not have
   valid IP configuration for Internet Connectivity. Hence, the node has
   to check the validity of its IP configuration.

   For this, the node may check 'L3 link change'. When the node remains
   at the same link, it can assume its IP configuration is still valid.
   Otherwise, its configuration is no longer valid and the node needs to
   gather the necessary information to allow Internet usage from this
   new IP subnet.

   The process by which a device determines that it has joined a new
   link, and checks its IP configuration is called Detecting Network
   Attachment (DNA). DNA checks the validity of current IP configuration


Choi, Daley             Expires - August 2004                [Page 2]

Internet-Draft               DNAv6 Goals                     Feb 2004


   by gathering information and, if necessary, initiate configuration
   based on gathered information.

   It is important to note that DNA does not incorporate actual IP
   configuration. For example, with respect to DHCP, it's the detection
   system's task to get the confirmation that a node needs to perform
   DHCP. It's not DNA's job to actually retrieve the information from a
   DHCP server.

   Rapid attachment detection is required when a host has existing upper
   layer protocols sessions. This may be the case if a host is
   connected intermittently, is a mobile host or has urgent data to
   transmit upon attachment to a link.


2. The Tasks of Network Attachment Detection

   Detecting Network Attachment aims to determine whether a host's
   existing IP configuration is valid by checking L3 link change, upon
   establishing a new link-layer connection. Valid IP configuration
   consists of several components, which impact on packet delivery to
   and from the Internet. While checking link change, a host may be able
   to get the necessary information for new IP configuration
   simultaneously.

   Initially, when a host has just made a link-layer connection, it may
   or may not belong to a new subnet. A host is unaware which of its
   addresses are topologically correct for this network, and whether
   duplicates of these addresses are already in use on this link or
   subnet.

   Additionally, a host doesn't know whether its currently configured
   default router is on this link, or whether its neighbor cache entries
   for the router and peers on the link are valid.

   Correct configuration of each of these components is necessary in
   order to send packets off the current link.

   While other information required for IP connections (such as DNS
   server configuration) are important, most of these requirements
   depend on the determination of correct global addressing, and valid
   default router configuration.

   Therefore, in order to determine if a host requires further
   configuration, it needs to check at least that:

   1) It has an (at least partially) a reachable default router.


Choi, Daley             Expires - August 2004                [Page 3]

Internet-Draft               DNAv6 Goals                     Feb 2004


   2) It has valid IP addressing.

   Partial reachability indicates that the router is at least visible to
   the host, although full bi-directional reachability is required for
   packet transfer.

   A host can check link change to determine the validity of it IP
   configuration. Today, L3 link change implies IP subnet change. If a
   host has moved to a new subnet, its IP configuration is no longer
   valid. Otherwise, a host still has valid IP configuration.

   Usually a host detects subnet change with Router Advertisement
   messages. After Network Attachment, a host receives a new Router
   Advertisement and compares it with the previously received ones. It
   checks whether the information in a new RA, the advertised prefixes
   and router addresses, matches the currently stored information,
   current IP address and default router address.

   The validity of other IP subnet related configuration is implied by
   Router Advertisements, if RA reception implies subnet change.
   Particularly, Dynamic Host Configuration protocols [DHCPv6] are
   explicitly indicated in RA messages, and multicast group membership
   is needed if the host is no linger in reach of a querier
   router[MLDv1][MLDv2].

   For rapid attachment detection, it is necessary to receive an RA
   quickly enough after a new link-layer connection is established,
   although by default this is not sufficient for link change detection
   (see Chapter 5).

   From a received RA, a host can get the necessary information for new
   IP configuration, the prefixes and router addresses. With the
   information, a host can immediately initiate new IP configuration,
   forming a new IP address and selecting a new default router, if it
   turns out that it has moved to a new link.


3. Application of Network Attachment Detection

   For efficiency, before initiating a new IP configuration, a host
   should check whether its current IP configuration is still valid.

   In case a host has moved to a new IP subnet, its IP configuration is
   no longer valid.  Hence a modification to IP configuration will be
   necessary and a host has to gather necessary information for new
   configuration.

   Automatic configuration mechanisms in IPv6 allow the host to:


Choi, Daley             Expires - August 2004                [Page 4]

Internet-Draft               DNAv6 Goals                     Feb 2004


   1) Choose a suitable default router
   2) Configure per-link information such as address reachability times,
      maximum transfer units &etc.
   3) Configure link-local and global unicast addresses.
   4) Join multicast groups
   5) Determine authentication state for off-link communications.

   While Detecting Network Attachment does not prescribe any particular
   mechanisms for configuration, it aims to support each requirement by
   determining if this configuration is required and providing necessary
   information, for example on-link prefixes.

   This may help to minimize signaling to those occasions where IP
   subnet or link change has occurred. Also, DNA may provide timely
   indications which may be used by IP subsystems to initiate
   configuration signaling.


4. Network Attachment Detection in Existing IPv6 Systems

   IPv6 has a rich set of features provided by Neighbor Discovery, which
   are supported in all hosts and most networks [RFC-2461]. In order to
   maintain mappings between IP layer and hardware (link-layer)
   addresses, IPv6 Neighbor Discovery maintains a cache of reachable
   devices.

   When a node changes its point of attachment, it may or may not have
   moved to a location where these devices are no longer reachable. To
   check its IP layer connectivity and gather the necessary information,
   a node may use any of the following features:

   1) Neighbor Solicitation/Neighbor Advertisement (NS/NA) exchange
   2) Router Solicitation/Router Advertisement (RS/RA) exchange
   3) Link-layer (L2) Information

   If a host can exchange neighbor information with any one of the nodes
   in its neighbor cache, for the interface which changed attachment,
   this is an indication that this host is reachable. A definition of
   this procedure in [RFC 2461] is called Neighbor Unreachability
   Detection (NUD). It prescribes transmission behaviors for hosts
   determining unreachability.

   Additionally, in many IPv6 networks, routers advertise their
   availability through Router Advertisement messages. While a host may
   not receive an unsolicited router advertisement message when Network
   Attachment occurs, it can check reachability to routers by performing
   router discovery [RFC-2461]. Router discovery which fails to update


Choi, Daley             Expires - August 2004                [Page 5]

Internet-Draft               DNAv6 Goals                     Feb 2004


   the currently configured router's information indicates that the
   router is unreachable, and should not be used.

   In some environments, link-layer topology information is signaled to
   wireless hosts.  For some subsets of these technologies, 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 stacks will be aware of
   this signaling at the network-layer, nor will indications from link-
   layers necessarily always be accurate. Because of this, attachment
   change detection at the network layer may be required in any case.

   If 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
   checks.

   Currently there is no way to represent a link such that subnet change
   can be detected instantly. No information in the above messages can
   identify a link. Neither Router address nor Prefix nor Link-layer
   information will do.

   Though the set of all the assigned prefixes can represent a link,
   it's difficult for a host to attain and retain all the prefixes with
   certainty. Moreover there may be a link without a prefix.

   Hence, to detect link change, a host has to resort to guessing
   based on the router address and advertised prefixes in the router
   advertisements and Neighbor Unreachability Detection.

   Upon Network Attachment, a host has to check at least the (partial)
   reachability of the current default router and the validity of
   current IP address.

   A host probes the current default router with Neighbor Solicitation.
   If it receives a no reply, it means its current default router is no
   longer reachable. If a host receives a message from a router where it
   has previously been able to exchange packets, then existing neighbor
   discovery (ND) procedures may be used to ensure full bi-directional
   reachability.

   The Internet routing system is expected to deliver packets sent to a
   valid address to their intended recipients. Because packet is
   forwarded with prefix based routing, a host should have an IP address


Choi, Daley             Expires - August 2004                [Page 6]

Internet-Draft               DNAv6 Goals                     Feb 2004


   whose prefix is advertised on the link to which it is currently
   attached. To determine if its IP address is valid, a host has to
   check whether the prefix of its IP address is in the Prefix
   Information Option of received Router Advertisements[RFC-2461].

   Address validity though may only be assured if Duplicate Address
   Detection (DAD) is undertaken for them [RFC-2462]. This is the case,
   even if a host has only momentarily been disconnected from a network.
   It is possible that in the short interval where the host has been
   disconnected, another node has performed DAD, and configured an
   address. Thus undertaking DAD may be required even if host has an IP
   address whose prefix is supported on the current link.


5. Problems for Network Attachment Detection

   The following make DNA complicated. Firstly, wireless connectivity is
   not as clear-cut as in the wired case. Secondly, the information
   contained in RA messages is not adequate for efficient DNA.  Today,
   RA messages can't represent a link and have inherent ambiguities.
   Thirdly, Router Discovery or NUD may take too much time and result in
   service disruption.


5.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 be able to attach to
   multiple wireless links at the same time.  Moreover reachability on a
   wireless link is very volatile which can make link detection hard.


   2) Asymmetric reachability

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


5.2 The Inadequacy of RA information

   Usually a node gets the information necessary for IP configuration
   from Router Advertisement messages.  Based on current definition


Choi, Daley             Expires - August 2004                [Page 7]

Internet-Draft               DNAv6 Goals                     Feb 2004


   [RFC2461], the information contained in RA is inadequate for
   efficient DNA.

   1) Link local scope of Router Address

   The router address contained in a Router Advertisement message is
   link-local scope.  Hence 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 Router
   Advertisement messages.

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


   2) Omission of Prefix Information Option

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

   For this, a host checks whether the prefix of its IP address is in
   the Prefix Information Option of Router Advertisement messages. But
   an unsolicited Router Advertisement message can omit some prefixes
   for convenience, for example to save bandwidth.

   Hence, a 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 Router Advertisement message.


5.3 Time delay

   For DNA, the following issues cause a delay, which may result in
   communication disruption.


   1) Delay for receiving a hint

   In order to speed up network attachment detection, hints can be
   used tell a host that they may have attached to a new subnet. This


Choi, Daley             Expires - August 2004                [Page 8]

Internet-Draft               DNAv6 Goals                     Feb 2004


   hint itself doesn't confirm new attachment, but can be used to
   initiate appropriate procedures.

   Hints come in various forms, and vary in how they can indicate a new
   network attachment.  The hints can be link-layer indications, the
   receipt of a new RA or the lack of RA from current default router.
   Additionally, the time taken to receive a hint varies. With Link-
   layer support, it can be done instantly.

   Alternatively a host can monitor periodic RA beacons. [MIPv6] defines
   use of RA Interval Timer expiry as a hint. A host may implement its
   own policy to determining the number of missing RAs, which it will
   interpret as a hint for possible movement.  Hence the detection delay
   depends on the Router Advertisement interval.

   Without schemes such as above, a host must receive a new RA from a
   new router to detect possible movement. The detection time also
   depends on the frequency of Router Advertisements.

   Periodic RA beaconing transmits packets within an interval varying
   randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. In
   [RFC 2461] minimums for these values are 3 and 4 seconds,
   respectively.  Since MN movement is unrelated to the advertisement
   time on the new network, the MN is expected to arrive on average half
   way through the interval. This is about 1.75 seconds with [RFC 2461]
   advertisement rates.


   2) Delay for checking current default router Unreachability

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

   Usually it's easier to check 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 system is absent, time needs to be taken to ensure
   that lack of reply is not due to another reason (For example: Packet
   Loss, MAC latency, or processing delay) So it takes time to determine
   the unreachability of the current default router.

   If a host uses NUD to check the reachability of current default
   router, it will take more than 3 seconds to detect its unreachability
   in the case where a host has moved to another IP subnet.




Choi, Daley             Expires - August 2004                [Page 9]

Internet-Draft               DNAv6 Goals                     Feb 2004


   3) Random delay execution for RS/ RA exchange

   Router Solicitation and Router Advertisement messages are used for
   Router Discovery.  According to Neighbor Discovery [RFC 2461], it is
   sometimes necessary for a host to delay a transmission for a random
   amount of time for Router Solicitation and for routers to delay
   before Router Advertisement.

   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).  Moreover 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).


6. The Goals of Network Attachment Detection

6.1 Potential Solution space

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

   After a host establishes a new link-layer connection, if it receives
   a RA message which correctly indicates link change, a host can check
   the validity of its IP configuration with no further action.

   Subsequently, in case of link change, if the RA message contains all
   the necessary information for new IP configuration, a host can
   initiate new configuration immediately.

   For efficient DNA schemes, it's desirable to have a RA message
   optimized for DNA, which can indicate link change and contains the
   necessary information for new IP configuration.

   Moreover, after network attachment, a host has to get a DNA optimized
   RA quickly to reduce handoff latency. Current Router Discovery may
   take too much time and result in the disconnection of on-going
   session.

   To design adequate DNA schemes, we'd better investigate how to 1)
   design a RA optimized for DNA and 2) deliver a DNA optimized RA to a
   host sufficiently fast.



Choi, Daley             Expires - August 2004               [Page 10]

Internet-Draft               DNAv6 Goals                     Feb 2004


   For this, 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 Schemes.

6.2 Goals list

   G1. DNA schemes should ascertain the validity of current IP
   configuration by detecting currently attached link. It should
   recognize and determine whether IP configuration change is needed and
   initiate a new configuration if necessary.

   G2. When upper-layer protocol sessions are being supported, DNA
   schemes should detect link change rapidly, with minimal latency

   G3. In the case where a host has not changed link or subnet, IP
   configuration change should not occur.

   G4. Detection of network attachment should not cause undue signaling
   on a wireless link.

   G5. Solutions for detecting network attachment should make use of
   existing signaling mechanisms where available.

   G6. Detection of Network Attachment should make use of signaling
   within the link (particuarly link-local scope messages) since
   communication off-link may not be achievable in the case of link
   change.

   G7. DNA schemes should be safe with respect to Duplicate Address
   Detection[RFC2462]. That is, hosts which undertake DNA should not
   infringe upon existing hosts' address configuration when arriving on
   a new link.

   G8. DNA Solutions should be compatible with IP security subsystems
   such as Secure Neighbour Discovery[SEND] and IPsec[RFC2411]

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

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

   G11. Routers Supporting DNA should work appropriately with hosts
   using unmodified configuration schemes, such as router
   discovery[RFC2461] and [DHCPv6].



Choi, Daley             Expires - August 2004               [Page 11]

Internet-Draft               DNAv6 Goals                     Feb 2004


   G12. Hosts supporting DNA should be able to work with unmodified
   routers and hosts which do not support DNA solutions.


7. IANA Consideration

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


8. Security Consideration

   Nodes connected over wireless interfaces may be particularly
   susceptible to jamming, monitoring and packet insertion attacks.  Use
   of [SEND] to protect link-layer to network-layer mappings and routing
   information exchange are important in achieving reliable detection of
   network attachment.

   Since DNA schemes are based on Neighbor Discovery, its trust models
   and threats are similar to the ones presented in [SEND-psreq]. DNA
   schemes SHOULD incorporate the solutions developed in IETF SEND
   Working Group if available, where assessment indicates such
   procedures are required.

   Even in the case where authoritative routing and prefix state is
   advertised, wireless network attackers may still prevent packet
   reception at soliciting nodes. This may trigger routing configuration
   change in some devices, when otherwise it is unnecessary.  Such
   attacks may be used to make a host preferentially select a particular
   comfiguration 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.

   Reception of link-change indications from L2 and L3 are dangerous 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. This is due to the potentially inconsistent
   semantic interpretation of such authentication at link-layer.

   Additional authentication or proof of identity may be required at the
   network layer to justify modification of IP configuration. In some
   cases, there is a significant performance cost in verifying


Choi, Daley             Expires - August 2004               [Page 12]

Internet-Draft               DNAv6 Goals                     Feb 2004


   configuration authority, which may impact on application performance.
   Implementors are cautioned that in the case such checks are deferred,
   they may be subject to short term man-in-the-middle and denial-of-
   service attacks, or implicated in denial-of-service attacks against
   innocent third parties. Particular care should be taken so that this
   doesn't occur.


References

   [RFC 2026] S. Bradner, "The Internet Standards Process ?Revision 3",
      BCP 9, RFC 2026, October 1996.

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

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

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

   [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6",
      Internet Draft (work in progress), June 2003.

   [MDO] G. Daley, J. Choi, "Movement Detection Optimization in Mobile
      IPv6", Internet Draft (work in progress), May 2003.

   [cRA] J. Choi, G. Daley, " Router Advertisement Issues for
      Movement Detection/ Detection of Network Attachment ", Internet
      Draft (work in progress), October 2003.

   [LinkID] B. Pentland, G. Daley, J. Choi, "Router Advertisement Link
      Identification for Mobile IPv6 Movement Detection", Internet Draft
      (work in progress), May 2003.

   [SEND-01] J. Arkko et al.," SEcure Neighbor Discovery (SEND)",
      Internet Draft (work in progress), January 2004.

   [Hindsight] E. Nordmark, "MIPv6: from hindsight to foresight?",
      Internet Draft, November 2001.


Acknowledgments

   Erik Nordmark has contributed significantly to work predating this
   draft on the ambiguity in On-link prefix. Also Ed Remmell's comments
   on the inconsistency of RA information were most illuminating. Thanks


Choi, Daley             Expires - August 2004               [Page 13]

Internet-Draft               DNAv6 Goals                     Feb 2004


   for Brett Pentland, Nick Moore and Youn-Hee Han for their
   contribution for this draft.


Author's Addresses

   JinHyeock Choi
   i-Networking Lab Samsung AIT
   P.O. Box 111 Suwon
   440-600 Korea
   Email: athene@sait.samsung.co.kr


   Greg Daley
   Centre for Telecommunications and Information Engineering
   Department of Electrical and Computer Systems Engineering
   Monash University
   Clayton 3800 Victoria
   Australia
   Email: greg.daley@eng.monash.edu.au



Choi, Daley             Expires - August 2004               [Page 14]


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