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]