One document matched: draft-narayanan-dna-hosts-bcp-00.txt
DNA Working Group S. Narayanan
Internet-Draft Panasonic
Expires: August 12, 2005 G. Daley
Monash University CTIE
N. Montavont
LSIIT - ULP
February 11, 2005
Detecting Network Attachment in IPv6 - Best Current Practices for
hosts.
draft-narayanan-dna-hosts-bcp-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Hosts experiencing rapid link-layer changes may require further
configuration change detection procedures than more traditional fixed
hosts. DNA is defined as the process by which a host collects
appropriate information and detects the identity of its currently
attached link to ascertains the validity of its IP configuration.
Narayanan, et al. Expires August 12, 2005 [Page 1]
Internet-Draft DNAv6 BCP for hosts February 2005
This document details best current practice for Detecting Network
Attachment in IPv6 hosts using existing Neighbor Discovery
procedures. Since there is no explicit link identification mechanism
in the existing Neighbor Discovery for IP Version 6, the document
describes implicit mechanisms for identifying the current link.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
3. Background & Motivation for DNA . . . . . . . . . . . . . . . 5
4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 6
4.1 Validation of current configuration . . . . . . . . . . . 6
4.1.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Reachability detection . . . . . . . . . . . . . . . . . . 7
4.2.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Validation of current configuration . . . . . . . . . . . . . 8
5.1 Current protocols . . . . . . . . . . . . . . . . . . . . 8
5.1.1 Link Change and Router Discovery . . . . . . . . . . . 8
5.1.2 Complete Prefix list . . . . . . . . . . . . . . . . . 9
5.1.3 Neighbor cache . . . . . . . . . . . . . . . . . . . . 10
5.2 Additional information . . . . . . . . . . . . . . . . . . 10
5.2.1 Making use of Prior Information . . . . . . . . . . . 10
5.2.2 Transient Link Availability . . . . . . . . . . . . . 10
5.2.3 Further Procedures on Detection of Network
Attachment . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Recommendations . . . . . . . . . . . . . . . . . . . . . 11
5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 12
6. Reachability detection . . . . . . . . . . . . . . . . . . . . 13
6.1 Current protocols . . . . . . . . . . . . . . . . . . . . 14
6.1.1 Specific (Neighbor Solicitation) Tests . . . . . . . . 14
6.1.2 Non-Specific (Router Solicitation) Tests . . . . . . . 14
6.1.3 Trade-offs in Reachability Testing . . . . . . . . . . 15
6.1.4 Hybrid mechanism . . . . . . . . . . . . . . . . . . . 16
6.1.5 Authorization for routing . . . . . . . . . . . . . . 16
6.2 Additional information . . . . . . . . . . . . . . . . . . 16
6.2.1 Wireless channel . . . . . . . . . . . . . . . . . . . 16
6.3 Recommendations . . . . . . . . . . . . . . . . . . . . . 17
6.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 17
7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 18
7.1 Hint Reception and Processing . . . . . . . . . . . . . . 18
Narayanan, et al. Expires August 12, 2005 [Page 2]
Internet-Draft DNAv6 BCP for hosts February 2005
7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 19
7.3 Timer Based Hints . . . . . . . . . . . . . . . . . . . . 19
7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 20
7.5 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 20
7.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 21
8. Current Practice for Configuration Change Detection on
Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Router and Prefix Discovery . . . . . . . . . . . . . . . 22
8.2 Address Autoconfiguration . . . . . . . . . . . . . . . . 22
8.3 Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 23
8.4 Dynamic Host Configuration . . . . . . . . . . . . . . . . 24
8.5 Multicast Listener State . . . . . . . . . . . . . . . . . 24
8.6 Mobility Management . . . . . . . . . . . . . . . . . . . 25
9. Complications to Detecting Network Attachment . . . . . . . . 25
9.1 Tentative Addressing . . . . . . . . . . . . . . . . . . . 25
9.2 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 26
9.3 Router Configurations . . . . . . . . . . . . . . . . . . 26
9.4 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 27
9.5 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 27
9.6 Link Partition . . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . 27
10.1 Authorization and Detecting Network Attachment . . . . . . 28
10.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 29
12.2 Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 32
B. Example State Transition Diagram . . . . . . . . . . . . . . . 35
C. Analysis of Configuration Algorithms . . . . . . . . . . . . . 36
D. DNA With Fast Handovers for Mobile IPv6 . . . . . . . . . . . 39
E. DNA with Candidate Access Router Discovery . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . 40
Narayanan, et al. Expires August 12, 2005 [Page 3]
Internet-Draft DNAv6 BCP for hosts February 2005
1. Introduction
When operating in changing environments, IPv6 hosts may experience
variations in reachability or configuration state over time. For
hosts accessing the Internet over wireless media, such changes may be
caused by changes in wireless propagation or host motion.
Detecting Network Attachment (DNA) in IPv6 is the task of checking
for changes in the validity of a host's IP configuration [15].
Changes may occur on establishment or disconnection of a link-layer.
For newly connected interfaces, they may be on a link different from
the existing configuration of the node.
In these and other cases, IP addressing and default routing
configuration of the node may be invalid, which prevents packet
transfer. DNA uses IPv6 Neighbour Discovery to provide information
about the reachability and identity of the link, which may be used to
identify if change has occurred [1].
DNA focuses on determining whether the current configuration is
invalid, leaving the actual practice of re-configuration to other
subsystems.
This document presents the best current practices for IPv6 hosts to
address the task of Detecting Network Attachment in changing and
wireless environments.
1.1 Structure of this Document
Section 3 of this document provides a background and motivation for
Detecting Network Attachment.
Elaboration of specific practices for hosts in detecting network
attachment continues in Section 4, Section 5, Section 6, and Section
7. These sections describe how to safely determine network
attachment with minimal signaling, across a range of environments.
Section 10 Provides security considerations, and details a number of
issues which arise due to wireless connectivity and the changeable
nature of DNA hosts' Internet connections.
This document has a number of appendixes.
Appendix A lists the recommendations for systems wishing to support
Best Current Practice. Appendix B provides an example state machine
for DNA describing knowledge and belief based on the prior listed
recommendations. A brief analysis of two known configuration
algorithms LCS (Lazy Configuration Switching) and ECS (Eager
Narayanan, et al. Expires August 12, 2005 [Page 4]
Internet-Draft DNAv6 BCP for hosts February 2005
Configuration Switching) is presented in Appendix C. The final two
(Appendix D and Appendix E) look at existing experimental protocols
that may be used to provide DNA processes with access network
information before arrival on a new link.
2. Terms and Abbreviations
There is an existing DNA terminology draft [22]. At this stage, it
is unclear if this draft or the mobility terminology [23] draft need
to be referenced, or specific terms need to be placed in this
document.
While the mobility terminology draft may be applicable, the focus of
this draft upon mobile hosts may be distracting for DNA. Comments on
this issue are welcome.
3. Background & Motivation for DNA
Hosts on the Internet may be connected by various media. It has
become common that hosts have access through wireless media and are
mobile, and have a variety of interfaces through which internet
connectivity is provided. The frequency of configuration change for
wireless and nomadic devices are high due to the vagaries of wireless
propagation or the motion of the hosts themselves. Detecting Network
Attachment is a strategy to assist such rapid configuration changes
by determining whether they are required.
While DNA has applicability to both wireless and wireline access
networks, these two sets of networks bring different sets of
requirements to the problem. Verifying the validity of current IP
configuration is needed when either a wireless or wireline link-layer
is in use, but wireless hosts are more likely to change their
link-layer connection than wireline hosts.
Due to these frequent link-layer changes, an IP configuration change
detection mechanism for DNA needs to be efficient and rapid. Making
such detection procedures rapid helps to avoid unnecessary
configuration delays upon link-change.
In an wireless environment, there will typically be a trade-off
between configuration delays and the channel bandwidth utilized or
host's energy used to transmit packets. This trade-off affects
choices as to whether hosts probe for configuration information, or
wait for network information. DNA seeks to assist hosts by providing
information about network state, which may allow hosts to
appropriately make decisions regarding such trade-offs.
Even though DNA is restricted to determining whether change is
Narayanan, et al. Expires August 12, 2005 [Page 5]
Internet-Draft DNAv6 BCP for hosts February 2005
needed, in some circumstances the process of obtaining information
for the new configuration may occur simultaneously with the detection
to improve the efficiency of these two steps.
4. Detecting Network Attachment Steps
Two different situations may lead a node to engage a network
attachment detection procedure. Either a node receives an indication
that its link may have changed or it may detect that its current
configuration is not valid any more. The current configuration that
is crucial for proper IP communication are the IP address and the
default router address.
If the host detects that its configuration is not valid any more, for
example because a timer has expired, the node should engage in
detection of its network attachment in order to determine if it needs
a new address and a default router address.
If a host receives an indication (such as a link-layer hint) that its
link may have changed, it MUST confirm the accuracy of the hint.
This confirmation can be achieved by either verifying the validity of
its current IP configuration like current-prefix, default router, or
by confirming bi-drectional reachability with its default router.
Confirming bi-directional reachability with the default router
implicitly provides verification for the IP configuration. But, if
verification of the IP configuration, like current prefix, can be
achieved through the reception of unsolicited RA or CPL (See Section
5.1.2), then confirming partial reachability from the default router
is enough for DNA. Even though partial reachability to the default
router is enough for DNA purpose, a host SHOULD confirm
bi-directional reachability if it is in a wireless environment. If
one of these two actions do not succeed, initiation of new
configuration is required.
4.1 Validation of current configuration
When link change occurs, an IPv6 host is likely to have one or more
IPv6 configurations for the interface in its internal cache. Upon
initiation of DNA procedures (as specified in Section 7), the first
step for the host would be to verify if any of its link-unique
configurations is still valid. While certain of the configurations
are related to presence on a link, and may be invalidated (such as
MTU), a subset of IP configurations are are testably unique. The
configurations to be considered are only those that are uniquely tied
to a particular link (for example, global prefixes). If the host can
confirm the validity of one such configuration, it can reasonably
infer that it has not changed its link and can continue using the
current configuration.
Narayanan, et al. Expires August 12, 2005 [Page 6]
Internet-Draft DNAv6 BCP for hosts February 2005
Example relevant configurations include: the current IPv6 prefix and
address, default router information and neighbour cache entries.
Where a subset of these change without change of link or subnet, IPv6
Neighbour Discovery provides procedures to manage and detect such
changes [1]. Recommendations on how to use verification of these
configuration for DNA is discussed in Section 5.
The validity of a host's configuration can be inferred by determining
its presence on a particular link. The host can verify presence on a
particular link by learning the ranges of valid addresses and routers
associated with that link and comparing this information with its
cached configuration. Learning the routers available on the link and
the prefixes supported by them can be done either passively by
listening to the Router Advertisements (RA) periodically sent by
routers, or actively by sending Router Solicitation (RS) [1].
4.1.1 Issues
The following issues make configuration validation procedures
non-trivial and SHOULD be considered when implementing
recommendations made by this document.
Routers are not required to include all the prefixes they support
in a single router advertisement message [1].
The default router address is link-local address and hence may
only be unique within one link [1].
While neighbor cache entries are valid only on a single link,
link-local addresses may be duplicated across many links, and only
global addressing MAY be used to identify if there is a link
change.
4.2 Reachability detection
Even after validating one of the current configuration sets, if the
configuration validated is not the current default router, a host
SHOULD confirm partial reachability to the current router. In some
wireless environments, the host SHOULD confirm bi-directional
reachability, as confirming partial reachability may not be enough
for proper operation of the IP host.
Reachability state usually relies on timers associated with received
information. Reachability detection can be triggered when a host has
some indications that the link might have changed or when a timer
(for example router lifetime) is expired. Reachability detection is
critical, since if the current default router, is not reachable
Narayanan, et al. Expires August 12, 2005 [Page 7]
Internet-Draft DNAv6 BCP for hosts February 2005
anymore, the host will have to change its IP configuration to be able
to communicate.
As we will see, reachability detection can be very fast if the peer
is still reachable. However, when the peer is not reachable anymore,
unreachability detection relies on timeout after transmission of
solicitations. These timeouts introduce important delays. Section
Section 6 discusses reachability detection. To reduce the likelihood
of such long delays, reachability detection SHOULD be executed only
when a current configuration is validated successfully.
4.2.1 Issues
The following issues have an impact on the design of any reachability
detection mechanism:
Choosing between partial reachability versus bi-directional
reachability testing. In some wireless environments partial
reachability detection may not be enough to confirm operational IP
communication.
The dependence on long timeouts to detect unreachability MUST be
taken into account.
5. Validation of current configuration
5.1 Current protocols
Detecting changes in IP configuration requires either knowledge
gathered from the network upon attachment using such methods as
Router Discovery, or that known from prior information.
The current focus of work in DNA Working Group are procedures
subsequent to attachment. Some procedures that describe how
information may be gathered prior to arrival are summarized in
Section 5.2.
5.1.1 Link Change and Router Discovery
The identity of a link in IPv6 can be determined using the router
discovery procedure [1].
Monitoring the link-local source address of the Router Advertisement
is insufficient to prove that a device is still on the link, since a
router may share a single link-local address across multiple
interfaces. If the host can confirm its current prefix by receiving
a router advertisement containing its current prefix from its current
Narayanan, et al. Expires August 12, 2005 [Page 8]
Internet-Draft DNAv6 BCP for hosts February 2005
default router address, the host can assume to be on the same link.
Reception of a router advertisement from a particular router that
does not contain any prefixes in common with the previously
advertised set by the same router MAY be an indicator that link
change has occurred. Notably, IPv6 Neighbor Discovery [1] explicitly
allows such configurations to exist, and additionally allows omission
of prefix information options in unsolicited router advertisements.
This leads to the fact that the non-presence of the current default
router should be determined before considering that the link has
changed. This is even more important with mobile hosts, which update
their location according to their position in the Internet.
Considering that the current default router/prefix has changed upon
the reception of a new IPv6 prefix may lead to excessive binding
update transmission [5].
In order to determine validity of configuration in such topologies,
soliciting a router advertisement using a router solicitation message
is RECOMMENDED. In some wireless environments, following the
successful solicitation of router advertisement a IP host SHOULD
confirm bi-directional reachability with the router.
Additionally, during reception of unsolicited Router Advertisements
any additional information based on the underlying technology SHOULD
be used, where possible, to ensure that complete prefix information
of the router is received by the host (see Section 5.1.2). This may
limit the false detection of link change due to omitted prefixes.
5.1.2 Complete Prefix list
A link contains a set of mutually reachable interfaces on routers,
and media connecting them between which there is no forwarding hop.
Each link can be uniquely identified by the set of prefixes assigned
to it at a particular time.
Therefore the identity of the link may be determined by monitoring
the set of routers and IPv6 prefixes advertised on the link. Any
router advertising one of the prefixes previously received within an
advertisement may be assumed to belong to the same link, if the new
advertisement was received within the Valid Lifetime of the prefix
[1].
[24] proposes that, at each attached link, the host generates the
complete prefix list, that is, the prefix list containing all the
prefixes on the link, and when it receives a hint that indicates a
possible link change, it detects the identity of the link by
comparing a the prefix in a new received RA with the existing prefix
list. [24] describes how to generate the complete prefix list and to
Narayanan, et al. Expires August 12, 2005 [Page 9]
Internet-Draft DNAv6 BCP for hosts February 2005
robustly check for link change even in the presence of packet losses.
5.1.3 Neighbor cache
A host SHOULD NOT initiate a neighbor discovery procedure to confirm
the validity of an entry in its neighbor cache as a means to confirm
whether it is on the same link. But, reception of a neighbor
advertisement message that confirm an global address entry in the
neighbor cache SHOULD be used by the host as a confirmation of its
current configuration. Particularly, if such an confirmation is
received for a global address entry with the Router 'R' flag set
SHOULD be considered as a validation of its current configuration.
5.2 Additional information
5.2.1 Making use of Prior Information
A device that has recently been attached to a particular wireless
base station may still have state regarding the IP configuration
valid for use on that link. This allows a host to begin any
configuration procedures before checking the ongoing validity and
security of the parameters.
The experimental protocols FMIPv6 [19] and CARD [20] each provide
ways to generate such information using network-layer signaling,
before arrival on a link. These are respectively described in
Appendix D and Appendix E. Additionally, the issue is the same when
a host disconnects from one cell and returns to it immediately, or
movement occurs between a pair of cells (the ping-pong effect).
5.2.2 Transient Link Availability
Wireless Internet hosts can experience connectivity changes that may
or may not be associated with IP configuration change.
While some wireless base-station transitions are almost
instantaneous, other cell change procedures take hundreds of
milliseconds. In the interval between disconnection at one cell and
attachment at another, packets sent by the host may be discarded or
delayed.
In some cases, upper layer data with addressing incorrect for the new
link may remain queued for transmission in the link-layer. Any
signaling packets queued behind these packets will be delayed and
such delays could cause timer expiry and affect the successful
completion of reachability confirmation procedures. Also if
signaling packets are sent when the link is unavailable, the packet
may be discarded. This will lead to timer expiry in the case a
Narayanan, et al. Expires August 12, 2005 [Page 10]
Internet-Draft DNAv6 BCP for hosts February 2005
solicitation is sent.
If a host knows that connectivity has been lost at the link-layer, it
SHOULD pause transmission of upper-layer packets to the lower-layer,
until general data frames can be sent on the new cell. This may help
to avoid packet loss or the queuing of signaling packets for change
detection behind data frames. A host SHOULD also stop sending
signaling for the purpose of DNA to a link-layer it has been reliably
informed is unavailable. It is RECOMMENDED that implementers
prioritize DNA signaling packets over other data packets while
queuing them to the link-layer.
5.2.3 Further Procedures on Detection of Network Attachment
Detection of network attachment does not define or prescribe
configuration procedures. The actual configuration is therefore left
to the procedures which are invoked upon arrival on a new link.
While DNA does not undertake configuration, it does learn about the
state of the network using neighbor and router discovery. Where it
is safe to do so, such state SHOULD be made available to
configuration processes. Particularly, state gained from change
detection procedures for DNA SHOULD NOT be discarded.
5.3 Recommendations
An IP host SHOULD consider the reception of a RA with the current
prefix from the current default router address, even if it is the
link-local address of the router, as a validation of its current
configuration.
A host SHOULD use the reception of a RA from a known router's
global address (or link-local address/prefix pair) as a validation
of its current configuration.
A host SHOULD NOT use the reception of a RA with the link-local
address of its default router as a validation for its current
configuration.
A host SHOULD use the reception of a RA with a known prefix on the
link as an indication that it is on the same link.
A host SHOULD use the reception of a RA with a prefix not in its
known prefix list on the link as an indication that it has changed
link only if it follows the recommendations in [24].
Hosts which receive packets at a global address SHOULD use this as
an indication that the host is on the same link where the address
Narayanan, et al. Expires August 12, 2005 [Page 11]
Internet-Draft DNAv6 BCP for hosts February 2005
is valid, if the message was sent from or through a device which
is known to be fixed (such as a router).
A host SHOULD use the confirmation of a global address entry with
the Router 'R' flag set in its neighbor cache as an indication
that it is on the same link.
A host SHOULD accept a response from a previously known and
authorized router if it is received while awaiting completion of
authorization checks for a new router. Note that previously known
but unsecured routers MUST NOT override routers whose
authorization is being assessed, as their advertisement may
constitute a denial-of-service attack [12][7].
Extreme care MUST be taken in making use of existing prior
information. If the assumptions attached to the stored
configuration are incorrect the configuration cost may be
increased, or even cause disruption of services to other devices.
Hosts MUST NOT cause any disruption of the IP connectivity to
other devices due to the invalidity or staleness of their
configuration.
In the case that the host arrives back on the same link in time
less than the DAD completion time (minus a packet transmission and
propagation time), the host MAY reclaim the address by sending
Neighbor Advertisement messages as if another host had attempted
DAD while the host was away. This will prevent DAD completion by
another node upon NA reception.
If a host has not been present on a link to defend its address,
and has been absent for a full DAD delay (minus transmission time)
the host MUST undertake the full DAD procedure for each address
from that link it wishes to configure [3].
5.4 Conclusions
The first step in DNA Procedure SHOULD be to validate the current
configuration to find out if the host is on the same link or if it
has changed its link. If the current link is reliably identified to
be different from the link to which the current configuration belongs
the IP host SHOULD initiate configuration procedure to update its
configuration. After confirming the validity of current
configuration or completing the attachment to a new link, a IP host
SHOULD confirm reachability with the default router as discussed in
Section 6. If the attachment procedure also confirms bi-directional
reachability, as is the case when SEND is used as part of the router
discovery procedure, then reachability detection step can be skipped.
Narayanan, et al. Expires August 12, 2005 [Page 12]
Internet-Draft DNAv6 BCP for hosts February 2005
6. Reachability detection
If an IP node needs to confirm bi-directional reachability to its
default router either a NS-NA or an RS-RA message exchange can be
used to conduct reachability testing. It is notable that the choice
of whether the messages are addressed to multicast or unicast address
will have different reachability implications. The reachability
implications from the hosts' perspective for the four different
message exchanges defined by RFC 2461 [1] are presented in the table
below. The host can confirm bi-directional reachability from the
neighbor discovery or router discovery message exchanges except when
a multicast RA is received at the host for its RS message. In this
case, using IPv6 Neighbour Discovery procedures, the host cannot know
whether the multicast RA is in response to its solicitation message
or whether it is a periodic un-solicited transmission from the router
[1].
+-----------------+----+----+----+-----+
| Exchanges: |Upstream |Downstream|
+-----------------+----+----+----+-----+
| multicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| unicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| RS/multicast RA | Y | N |
+-----------------+----+----+----+-----+
| RS/unicast RA | Y | Y |
+-----------------+----+----+----+-----+
Successful exchange of the messages listed in the table indicate the
corresponding links to be operational. Lack of reception of response
from the router may indicate that reachability is broken for one or
both of the transmission directions or it may indicate an ordinary
packet loss event in either direction.
Three different methods for verifying bi-directional reachability
with the current router and at the same time receive new
configuration information if the current router is not available is
presented in Section 6.1.1, Section 6.1.2 and Section 6.1.4.
If bi-directional reachability can not be confirmed using one of the
three message exchanges, the host SHOULD attempt to find a better
connection with possibly another router in the link. Due to the
transient nature of wireless links, reachability may change during
communication after reachability is verified. If multiple routers
were available, the host MAY defer test of reachability until the
interface is to be actively used for transmission and reception.
Narayanan, et al. Expires August 12, 2005 [Page 13]
Internet-Draft DNAv6 BCP for hosts February 2005
Hosts should also be aware of particular issues regarding their own
wireless access technology which impinge on the reliability of
reachability tests. Particularly, where unicast and multicast
propagation behaviors are significantly different, hosts SHOULD
attempt to test both multicast and unicast reachability, to ensure
that each works. Hosts MAY defer such additional tests where either
communications method is not likely to be used soon.
6.1 Current protocols
6.1.1 Specific (Neighbor Solicitation) Tests
Bi-directional reachability can be verified using the Neighbor
Discovery test to the current access router. Since ND may involve
the use of two unicast messages exchanged between the host and the
access router, a successful ND procedure verifies bi-directional
reachability.
The IP node sends an NS message to the default router and waits for
the NA from the router. This mechanism is efficient if the current
default router is still reachable: only a round trip time between the
host and the router is needed to confirm reachability. Conversely,
if the default router is not available, the host will timeout without
receiving a NA. By default, the host can send three NS (one every
second) before considering that the router is not reachable.
However, if the host has indication that the link may have changed,
this delay may be reduced without significant damage for the network
by reducing the number of retries. If the current router is
considered unreachable (timeout on NS message), the host will have to
execute router discovery procedure to obtain new configuration and
reachability information. The host will send a RS message to the
All-Routers multicast address.
In summary, this method works well both when the current default
router is available and when the current default router is not
available. When the current default router is not available though,
the delay introduced in doing ND before switching to RD could become
a problem in deploying real-time applications in wireless networks.
Reducing the timer associated with the unreachability testing through
the exchange of NS/NA might be an issue. Sometimes this method is
referred to as Lazy Configuration Switching.
6.1.2 Non-Specific (Router Solicitation) Tests
Initiating the Router Discovery procedure can sometimes lead to
verification of bi-directional reachability. It does not always
confirm bi-directional reachability because if the router responds to
the RS with a multicast RA message, there is no way for the host to
Narayanan, et al. Expires August 12, 2005 [Page 14]
Internet-Draft DNAv6 BCP for hosts February 2005
identify whether the RA is in response to the RS or whether it is a
periodic unsolicited RA transmission. Even with multicast RA
response, if SEND is used, bi-directional reachability can be
confirmed because SEND uses a unique nonce to match request and
response messages [7]. If the router chooses to respond to a RS with
a unicast RA message, again, the host will be able to match the RS
and RA and hence confirm bi-directional reachability.
In order to test reachability, a node sends an RS message to the
All-Routers multicast address. A RA message in response to the RS
will be received from one or more available routers on the link.
This method will lead to quick configuration of the interface because
if the current default router is not accessible, new configuration
information can be received from the responding router. However,
this can lead to erroneous re-configuration of the interface because
a response from a new router doesn't necessarily mean that the
current router is not accessible. Based on IPv6 Neighbour Discovery
[1], the node may have to wait for up to MAX_RTR_SOLICITATIONS times
RTR_SOLICITATION_INTERVAL to confirm that the current default router
is not serving the default IPv6 prefix. By considering the default
values of [1], this induces a delay of almost 12 seconds.
6.1.3 Trade-offs in Reachability Testing
There are unique advantages and dis-advantages in using either the
Specific or the Non-specific test to confirm reachability.
Specific tests:
Advantages:
Confirmation of bi-directional reachability.
Single responder, with no induced delays.
Dis-advantages:
If the ND test fails, the host has no potential configuration
information it can use.
Non-Specific tests:
Advantages:
Even when the current access router is not reachable, an RA message
from any available router will provide information that can used to
configure the host.
Narayanan, et al. Expires August 12, 2005 [Page 15]
Internet-Draft DNAv6 BCP for hosts February 2005
Confirmation of bi-directional reachability if SEND is used or if the
router chooses to respond with an unicast RA message.
Dis-advantages:
If multicast RA response is received, the host may have to execute an
ND test to confirm bi-directional reachability. Such a test may be
avoided if upper layer confirmations are received within the DELAY
period prescribed by IPv6 Neighbor Discovery [1].
Even when the current access router is reachable, the response may
arrive from a different access router leading to erroneous
re-configuration of the host.
Potentially multiple responders.
Protocol induced response delays [1].
6.1.4 Hybrid mechanism
Send a NS to the current default router and a RS to the All-Routers
multicast address in parallel. If the response to the NS is received
within the timeout period, any response to the RS can be ignored. If
no NA is received, the RA received in response to the RS will be used
to configure the IP interface. The method works well in both cases
when the current router is still available and when not, and avoids
the delay of exchanging RS and RA after the ND timeouts. When the
current default router is available, the RS and RA messages are
unnecessarily transmitted, wasting network resources.
6.1.5 Authorization for routing
In addition to reachability information, routing authorization needs
to be determined for each router. In SEND [7], routing authorization
is delegated by certification authorities. Certificate authorities
delegate a portion of their routing authority to the router, tying
them to a public/private key-pair. While SEND Router Advertisement
packets contain the public key used to sign the message. Hosts need
to test the router's authority to provide routing for the prefixes
advertised in its Router Advertisement in order to ensure safe
configuration.
6.2 Additional information
6.2.1 Wireless channel
Wireless channel characteristics change both in space and time. Even
when a wireless host is not moving, its connectivity to the access
Narayanan, et al. Expires August 12, 2005 [Page 16]
Internet-Draft DNAv6 BCP for hosts February 2005
router can change due to factors like interference from other
objects, temperature etc. When the host is moving, the changes can
be more pronounced because of change in distance, introduction of new
objects in the LOS (line of sight) etc. The change to the
connectivity may affect both directions or it can be only in either
one of the directions. Hence, in wireless links, reachability in one
direction does not guarantee reachability in the other. Also, these
variations in the wireless channel can be very short lived, inducing
rapid change indications about the status of the link-layer. It is
important to consider the transient nature of the wireless links in
design the DNA mechanism for such channels. Using rate-limiting
techniques when reactiving to hints is recommended (See Section 7.
6.3 Recommendations
A host SHOULD try bi-directional reachability testing with its
default router only if it successfully validates its current
configuration or if it just re-configured the IP interface with
new default router address.
When in a wireless environment a host MAY confirm bi-directional
reachability before trying to use the current address and default
router address. Where delays induced by reachability testing will
interfere with packet transfer, this testing SHOULD be delayed for
STALE neighbour cache entries as in [1].
Link layer technologies where unicast transmissions and multicast/
broadcast transmissions are dealt with differently, the hosts MAY
have confirm both unicast and multi-cast reachability with the
default router to continue the use of the router.
Where a host wishes to configure an unsecured router, it SHOULD at
least confirm bidirectional reachability with the device, and it
MUST mark the device as unsecured [7].
The frequency of initiation of reachability testing MUST be
controlled in order to avoid flooding of the network.
Implementers are advised to build in rate-limiting mechanisms in
responding to the hints to avoid switching IP configuration
frequently when the quality of the wireless channel is fluctuating
(see Section 7.5).
6.4 Conclusions
During bi-directional reachability verification procedure, it is also
possible to collect information for the re-configuration of the
interface if the reachability verification fails. Hosts SHOULD make
Narayanan, et al. Expires August 12, 2005 [Page 17]
Internet-Draft DNAv6 BCP for hosts February 2005
best effort to validate the current configuration, verify
bi-direction reachability and collect configuration information with
minimal use of signaling messages.
7. Initiation of DNA Procedures
Link change detection procedures are initiated when information is
received either directly from the network or from other protocol
layers within the host. This information indicates that network
reachability or configuration is suspect and is called a hint.
Hints MAY be used to update a wireless host's timers or probing
behavior in such a way as to assist detection of network attachment.
Hints SHOULD NOT be considered to be authoritative for detecting IP
configuration change by themselves.
In some cases, hints will carry significant information (for example
a hint indicating PPP IPv6CP open state [4]), although details of the
configuration parameters may be available only after other IP
configuration procedures. Implementers are encouraged to treat hints
as though they may be incorrect, and require confirmation.
The signaling which causes a hint may be due to network-layer
messages such as unexpected Router Advertisements, multicast listener
queries or ICMPv6 error messages [1][9][6]. In these cases, the
authenticity of the messages MUST be verified before expending
resources to initiate DNA procedure.
Hosts MUST ensure that untrusted messages do not cause unnecessary
configuration changes, or significant consumption of host resources
or bandwidth. In order to achieve this aim, a host MAY implement
hysteresis mechanisms such as token buckets, hint weighting or
holddown timers in order to limit the effect of excessive hints (see
Section 7.5).
7.1 Hint Reception and Processing
When a host arrives on a new link, hints received due to external IP
packets will typically be due to multicast messages. A delay before
receiving these messages is likely as in most cases intervals between
All-Hosts multicast messages are tightly controlled [1][6].
Regardless of this, actions based on multicast reception from
untrusted sources are dangerous due to the threat of transmitter
impersonation. This issue is discussed further in Section 10.
State changes within the network-layer itself may initiate
link-change detection procedures. Existing subsystems for router and
neighbor discovery, address leasing and multicast reception maintain
Narayanan, et al. Expires August 12, 2005 [Page 18]
Internet-Draft DNAv6 BCP for hosts February 2005
their own timers and state variables. Changes to the state of one or
more of these mechanisms may hint that link change has occurred, and
initiate detection of network attachment.
7.2 Handling Hints from Other Layers
Timeouts and state change at other protocol layers may provide hints
of link change to detection of network attachment. Two examples of
such state change are TCP retransmission timeout and completion of
link-layer access procedures.
While hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [21]) or be inaccurate with regard to
network-layer state.
While these hints come from the host's own stack, the causes for such
hints may be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to
instigate hint delivery on a host or multiple hosts deliberately, in
order to prompt packet transmission, or configuration modification.
This ability to create hints may even extend to the parameters
supplied with a hint that give indications of the network's status.
Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY choose to adopt an
appropriate link change detection strategy based upon hints received
from other layers, with suitable caution and hysteresis, as described
in Section 7.5.
7.3 Timer Based Hints
When receiving messages from upper and lower layers, or when
maintaining reachability information for routers or hosts, timers may
expire due to non-reception of messages. In some cases the expiry of
these timers may be a good hint that DNA procedures are necessary.
Hosts SHOULD NOT start DNA procedures simply because a data link is
idle, in accordance with [1]. Hosts MAY act on hints associated with
non-reception of expected signaling or data.
Since DNA is likely to be used when communicating with devices over
wireless links, suitable resilience to packet loss SHOULD be
incorporated into either the hinting mechanism, or the DNA initiation
Narayanan, et al. Expires August 12, 2005 [Page 19]
Internet-Draft DNAv6 BCP for hosts February 2005
system. Notably, non-reception of data associated with end-to-end
communication over the Internet may be caused by reception errors at
either end or because of network congestion. Hosts SHOULD NOT act
immediately on packet loss indications, delaying until it is clear
that the packet losses aren't caused by transient events.
Use of the Advertisement Interval Option specified in [5] follows
these principles. Routers sending this option indicate the maximum
interval between successive router advertisements. Hosts receiving
this option monitor for multiple successive packet losses and
initiate change discovery.
7.4 Simultaneous Hints
While some link-layer hints may be generated by individual actions,
other events which generate hints may affect a number of devices
simultaneously. It is possible that hints arrive synchronously on
multiple hosts at the same time. For example, if a wireless base
station goes down, all the hosts on that base station are likely to
initiate link-layer configuration strategies after losing track of
the last beacon or pilot signal from the base station. As described
in [1][6], a host SHOULD delay randomly before acting on a widely
receivable advertisement, in order to avoid response implosion.
Since a host's detection of network attachment may include Router
Solicitations sent to multicast addresses, a host may receive
responses from each of multiple routers on a link. Therefore, Router
Solicitations may eventually cause additional bandwidth consumption,
and require additional constraint.
Where a host considers it may be on a new link and learns this from a
hint generated by a multicast message, the host SHOULD defer 0-1000ms
in accordance with [1][3]. Please note though that a single
desynchronization is required for any number of transmissions
subsequent to a hint, regardless of which messages need to be sent.
Additional delays are only required if in response to messages
received from the network which are themselves multicast, and it is
not possible to identify which of the receivers the packet is in
response to.
In link-layers where sufficient serialization occurs after an event
experienced by multiple hosts, each host MAY avoid the random delays
before sending solicitations specified in [1].
7.5 Hint Validity and Hysteresis
Anecdotal evidence from the initial Detecting Network Attachment BoF
Narayanan, et al. Expires August 12, 2005 [Page 20]
Internet-Draft DNAv6 BCP for hosts February 2005
indicated that hints received at the network layer often did not
correspond to changes in IP connectivity [18].
In some cases, hints could be generated at an elevated rate, which
didn't reflect actual changes in IP configuration. In other cases,
hints were received prior to the availability of the medium for
network-layer packets.
Additionally, since packet reception at the network and other layers
are a source for hints, it is possible for traffic patterns on the
link to create hints, through chance or malicious intent. Therefore,
it may be necessary to classify hint sources and types for their
relevance and recent behavior.
When experiencing a large number of hints, a host SHOULD employ
hysteresis techniques to prevent excessive use of network resources.
The host MAY change the weight of particular hints, to devalue them
if their accuracy has been poor, suggests invalid configurations, or
are suspicious (refer to Section 10).
It is notable, that such hysteresis may cause sub-optimal change
detection performance, and may themselves be used to block legitimate
hint reception.
7.6 Hint Management for Inactive Hosts
If a host does not expect to send or receive packets soon, it MAY
choose to defer detection of network attachment. This may preserve
resources on latent hosts, by removing any need for packet
transmission when a hint is received.
These hosts SHOULD delay 0-1000ms before sending a solicitation, and
MAY choose to wait up to twice the advertised Router Advertisement
Interval (plus the random delay) before sending a solicitation [5].
When deferring this signaling, the host therefore relies upon the
regular transmission of unsolicited advertisements for timely
detection of link change.
One benefit of inactive hosts' deferral of DNA procedures is that
herd-like host configuration testing is mitigated when base-station
failure or simultaneous motion occur. When latent hosts defer DNA
tests, the number of devices actively probing for data simultaneously
is reduced to those hosts which currently support existing data
sessions.
When a device begins sending packets, it will be necessary to test
bidirectional reachability with the router (whose current Neighbor
Narayanan, et al. Expires August 12, 2005 [Page 21]
Internet-Draft DNAv6 BCP for hosts February 2005
Cache state is STALE). As described in [1], the host will delay
before probing to allow for the probability that upper layer packet
reception confirms reachability.
In some circumstances, a node will not use an interface for a long
time before it chooses to send upper layer traffic. The reachability
information available to the host is therefore likely to be
out-of-date. On links where bidirectional reachability is not
inferred by multicast RA reception, a host transmitting upper-layer
data MAY initiate reachability detection without the delays specified
in IPv6 Neighbour Discovery [1]. Conversely, if packet transmission
is due to network state or received messages, then the full delays
described in [1] SHOULD be observed.
8. Current Practice for Configuration Change Detection on Hosts
Various protocols within IPv6 provide their own configuration
processes. While Detecting Network Attachment seeks to provide
efficient change detection without undertaking configuration, it is
necessary to describe these protocols and their relationship to each
other.
8.1 Router and Prefix Discovery
Router Discovery is designed to provide hosts with a set of locally
configurable prefixes and default routers. These may then be
configured by hosts for access to the Internet [1].
It allows hosts to discover routers and manage lists of eligible next
hop gateways, and is based on IPv6 Neighbor Discovery. When one of
the routers in the router list is determined to be no longer
reachable, its destination cache entry is removed, and new router is
selected from the list. If the currently configured router is
unreachable, it is quite likely that other devices on the same link
are no longer reachable.
On determining that link-change has occurred, the default router list
SHOULD have entries removed which are related to unreachable routers,
and consequently these routers' destination cache entries SHOULD be
removed [1]. If no eligible default routers are in the default
router list, Router Solicitations MAY be sent, in order to discover
new routers.
8.2 Address Autoconfiguration
Unicast source addresses are required to send all packets on the
Internet, except a restricted subset of local signaling such as
Narayanan, et al. Expires August 12, 2005 [Page 22]
Internet-Draft DNAv6 BCP for hosts February 2005
router and neighbor solicitations.
In dynamic environments, hosts need to undertake automatic
configuration of addresses, and select which addresses to use based
on prefix information advertised in Router Advertisements. Such
configurations may be based on either Stateless Address
Autoconfiguration [3] or DHCPv6 [13].
For any configured address, Duplicate Address Detection (DAD) MUST be
performed [3]. DAD defines that an address is treated tentatively
until either series of timeouts expire after probe transmissions or
an address owner defends its address. Tentative addresses cannot
modify peers' neighbor cache entries, nor can they receive packets.
As described in Section 9.1, messages used in DNA signaling should be
treated as unconfirmed, due to the chance of link change. Optimistic
DAD is designed to allow use of addressing while they are being
checked for validity. Careful use of these addresses may contribute
to faster DNA operation [8].
8.3 Neighbor Discovery
Neighbor caches allow for delivery of packets to peers on the same
link. Neighbor cache entries are created by router or neighbor
discovery signaling, and may be updated either by upper-layer
reachability confirmations or explicit neighbor discovery exchanges.
In order to determine which link-layer address a peer is at, nodes
send solicitations to the link-local solicited-node multicast address
of their peer. If hosts are reachable on this address, then they
will respond to the solicitation with a unicast response.
Information from these responses are stored in neighbour cache
entries.
When link change occurs, the reachability of all existing neighbor
cache entries is likely to be invalidated, if link change prevents
packet reception from an old link. For these links, the neighbor
cache entries SHOULD be removed when a host moves to a new link
(although it MAY be possible to keep keying and authorization
information for such hosts cached on a least-recently-used basis
[7]).
Reachability of a single node may support the likelihood of reaching
the rest of the link, for example if a particular access technology
relays such messages through wireless base stations.
Narayanan, et al. Expires August 12, 2005 [Page 23]
Internet-Draft DNAv6 BCP for hosts February 2005
8.4 Dynamic Host Configuration
Dynamic Host Configuration Procedures for IPv6 define their own
detection procedures [13]. In order to check if the current set of
configuration is valid, a host can send a 'Confirm' message with a
sample of its current configuration, which is able to be responded to
by any DHCP relay on a link.
If the replying relay knows it is not on the same link, it may
respond, indicating that the host's configuration is invalid.
Current use of this technique is hampered by the lack of wide scale
deployment of DHCPv6 and hence the detection mechanism doesn't work
when the host moves to a link which doesn't contain DHCP relays or
servers.
Upon link change, any configuration learned from DHCP which is link
or administrative domain specific may have become invalid.
Subsequent operation of DHCP on the new link may therefore be
necessary.
8.5 Multicast Listener State
Multicast routers on a link are aware of which groups are in use
within a link. This information is used to undertake initiation of
multicast routing for off-link multicast sources to the link [9][11].
When a node arrives on a link, it may need to send Multicast Listener
Discovery (MLD) reports, if the multicast stream is not already being
received on the link. If it is an MLDv2 node it SHOULD send state
change reports upon arrival on a link [11].
Since the identity of the link is tied to the presence and identity
of routers, initiation of these procedures may be undertaken when DNA
procedures have been completed. In the absence of received data
packets from a multicast stream, it is unlikely that a host will be
able to determine if the multicast stream is being received on a new
link, and will have to send state change reports, in addition to
responses to periodic multicast queries [9][11].
For link scoped multicast, reporting needs to be done to ensure that
packet reception in the link is available due to multicast snoopers.
Some interaction is possible when sending messages for the purpose of
DNA on a network where multicast snooping is in use. This issue is
described in Section 9.5.
While RFC2710 [9] specifies that routers may ignore messages from
unspecified source addresses RFC 3590 [10] indicates that for the
benefit of snooping switches such messages MAY be transmitted.
Narayanan, et al. Expires August 12, 2005 [Page 24]
Internet-Draft DNAv6 BCP for hosts February 2005
Since DNA procedures are likely to force link-local addresses to be
tentative, this means MLD messages may need to be transmitted with
unspecified source addresses while link-locals are tentative, in
order to complete DNA. This is discussed further in Section 9.5
8.6 Mobility Management
Mobile IPv6 provides global mobility signaling for hosts wishing to
preserve sessions when their configured address becomes topologically
incorrect [5]. This system relies upon signaling messages and tunnel
movement to provide reachability at a constant address, while
directing packets to its visited network.
The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures,
which themselves rely upon Neighbor Discovery, to initiate mobility
signaling. These procedures allow for some modification of Neighbor
Discovery to enable faster change or movement detection. While this
document references parameters defined in [5], hosts are not required
to undertake global mobility signaling or tunneling in order to
benefit from detecting network attachment.
9. Complications to Detecting Network Attachment
Detection of network attachment procedures can be delayed or may be
incorrect due to different factors. As the reachability testing
mainly relies on timeout, packet loss or different router
configurations may lead to erroneous conclusions. This section gives
some examples where complications may interfere with DNA processing.
9.1 Tentative Addressing
When a host connects to a new link, it needs to create a link-local
address. But as the link-local address must be unique on a link,
Duplication Address Detection (DAD) must be performed [3] by sending
NS targeted at the link-local address undergoing validation.
An address that is being validated is said to be a tentative address.
The host that only has a tentative address must not accept packets
intended to this destination, neither may send packets with it. If
the host does not get any reply to its DAD Neighbor Solicitations,
the tentative link-local address can be allocated to the interface of
the host. From that point, the link-local address can be used and
the prefix and router discovery can then take place.
Several NS's can be sent to perform DAD on a tentative link-local
address. However, the default number of transmissions of Neighbor
Solicitations is 1. If an NA is not received within one second after
Narayanan, et al. Expires August 12, 2005 [Page 25]
Internet-Draft DNAv6 BCP for hosts February 2005
the NS transmission, the tentative address is considered as unique.
However, if the NS or NA are lost for some reason, the tentative
address will be considered as unique while another node might have
the same address. Notably though, each additional transmission of an
NS introduces a delay of one second in the configuration
establishment, which has an important impact on IP configuration
latency.
While hosts performing DNA do not know if they have arrived on a new
link, they SHOULD treat their addresses as if they were. This means
that link-local addresses SHOULD be treated as tentative, and
globally unique addresses SHOULD NOT be used in a way which creates
neighbor cache state on their peers, while DNA procedures are
underway. The different treatment of IP addressing comes from the
fact that on the global addresses cannot have an address conflict if
they move to a topologically incorrect network where link-local
addresses may. Even though global addresses will not collide, the
incorrect creation of neighbor cache entries on legacy peers may
cause them some harm.
Optimistic Duplicate Address Detection allows addresses to be used
while they are being checked, without treating marking addresses as
tentative. Procedures ensure that persistent invalid neighbour cache
entries are not created. This may allow faster DNA procedures, by
avoiding use of unspecified source addresses in RS's and consequently
allowing unicast Router Advertisements responses [8].
9.2 Packet Loss
Generally, packet loss introduces significant delays in validation of
current configuration or discovery of new configuration. Because
most of the protocols rely on timeout to consider that a peer is not
reachable anymore, packet loss may lead to erroneous conclusions.
Additionally, packet loss rates for particular transmission modes
(multicast or unicast) may differ, meaning that particular classes of
DNA tests have higher chance of failure due to loss. Hosts SHOULD
attempt to verify tests through retransmission where packet loss is
prevalent.
9.3 Router Configurations
Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations.
Different timers and constants might be used by different routers,
such as the delay between Router Advertisements or delay before
replying to an RS. If a host is changing is IPv6 link, the new
router on that link may have a different configuration and may
introduce more delay than the previous default router of the host.
Narayanan, et al. Expires August 12, 2005 [Page 26]
Internet-Draft DNAv6 BCP for hosts February 2005
The time needed to discover the new link can then be longer than
expected by the host.
9.4 Overlapping Coverage
If a host can be attached to different links at the same time with
the same interface, the host will probably listen to different
routers, at least one on each link. To be simultaneously attached to
several links may be very valuable for a MN when it moves from one
access network to another. If the node can still be reachable
through its old link while configuring the interface for its new
link, packet loss can be minimized. Such a situation may happen in a
wireless environment if the link layer technology allows the MN to be
simultaneously attached to several points of attachment and if the
coverage area of access points are overlapping. For the purposes of
DNA, the different links should not be classified as a unique link.
Because if one router or an entire link where the node is attached
comes down doesn't mean that the other link is also down.
9.5 Multicast Snooping
When a host is participating in DNA on a link where multicast
snooping is in use, multicast packets may not be delivered to the
LAN-segment to which the host is attached until MLD signaling has
been performed [9][11][17]. Where DNA relies upon multicast packet
delivery (for example, if a router needs to send a Neighbor
Solicitation to the host), its function will be degraded until after
an MLD report is sent.
Where it is possible that multicast snooping is in operation, hosts
MUST send MLD group joins (MLD reports) for solicited nodes'
addresses swiftly after starting DNA procedures.
9.6 Link Partition
Link partitioning occurs when a link's internal switching or relaying
hardware fails, or if the internal communications within a link are
prevented due to topology changes or wireless propagation.
When a host is on a link which partitions, only a subset of the
addresses or devices it is communicating with may still be available.
Where link partitioning is rare (for example, with wired
communication between routers on the link), existing router and
neighbor discovery procedures may be sufficient for detecting change.
10. Security Considerations
Detecting Network Attachment is a mechanism which allows network
Narayanan, et al. Expires August 12, 2005 [Page 27]
Internet-Draft DNAv6 BCP for hosts February 2005
messages to change the node's belief about its IPv6 configuration
state. As such, it is important that the need for rapid testing of
link change does not lead to situations where configuration is
invalidated by malicious third parties, nor that information passed
to configuration processes exposes the host to other attacks.
Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats
which are applicable to those procedures also affect Detecting
Network Attachment. These threats are described in [12].
Some additional threats are outlined below.
10.1 Authorization and Detecting Network Attachment
Hosts connecting to the Internet over wireless media may be exposed
to a variety of network configurations with differing robustness,
controls and security.
When a host is determining if link change has occurred, it may
receive messages from devices with no advertised security mechanisms
purporting to be routers, nodes sending signed router advertisements
but with unknown delegation, or routers whose credentials need to be
checked [12]. Where a host wishes to configure an unsecured router,
it SHOULD at least confirm bidirectional reachability with the
device, and it MUST mark the device as unsecured as described in [7].
In any case, a secured router SHOULD be preferred over an unsecured
one, except where other factors (unreachability) make the router
unsuitable. Since secured routers' advertisement services may be
subject to attack, alternative (secured) reachability mechanisms from
upper layers, or secured reachability of other devices known to be on
the same link may be used to check reachability in the first
instance.
10.2 Addressing
While a DNA host is checking attachment, and observing DAD, it may
receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [7].
While this is a valid action in the case where a host collides with
another address owner after arrival on a new link, In the case that
the host returns immediately to the same link, such a DAD defense NA
message can only be a denial-of-service attempt.
If a non-SEND node forges a DAD defense for an address which is still
Narayanan, et al. Expires August 12, 2005 [Page 28]
Internet-Draft DNAv6 BCP for hosts February 2005
in peers' neighbor cache entries, a host may send a SEND protected
unicast neighbor solicitation without a source link-layer address
option to one its peers (which also uses SEND). If this peer is
reachable, it will not have registered the non-SEND DAD defense NA in
its neighbor cache, and will send a direct NA back to the soliciting
host. Such an NA reception disproves the DAD defense NA's validity.
Therefore, a SEND host performing DNA which receives a DAD defense
from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a
STALE or REACHABLE secure neighbor cache entry, omitting source
link-layer address options. In this case, the host should pick an
entry which is likely to have a corresponding entry on the peer. If
the host responds within a RetransTimer interval, then the DAD
defense was an attack, and the host SHOULD inform its systems
administrator without disabling the address.
11. Acknowledgments
JinHyeock Choi and Erik Nordmark have done lots of work regarding
inference of link identity through sets of prefixes. Bernard Aboba's
work on DNA for IPv4 significantly influenced this document.
12. References
12.1 Normative References
[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC2463 2463, December 1998.
[7] 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.
Narayanan, et al. Expires August 12, 2005 [Page 29]
Internet-Draft DNAv6 BCP for hosts February 2005
[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
draft-ietf-ipv6-optimistic-dad-02 (work in progress), September
2004.
12.2 Informative References
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[10] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[12] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[15] Choi, J., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-04 (work in progress), December 2004.
[16] Fikouras, N A., K"onsgen, A J. and C. G"org, "Accelerating
Mobile IP Hand-offs through Link-layer Information",
Proceedings of the International Multiconference on
Measurement, Modelling, and Evaluation of
Computer-Communication Systems (MMB) 2001, September 2001.
[17] Christensen, M., Kimball, K. and F. Solensky, "Considerations
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11
(work in progress), May 2004.
[18] Kniveton, T J. and B C. Pentland, "Session minutes of the
Detecting Network Attachment (DNA) BoF", Proceedings of the
fifty-seventh Internet Engineering Task Force Meeting IETF57,
July 2003.
[19] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-01 (work in progress), February
2004.
[20] Liebsch, M., "Candidate Access Router Discovery",
Narayanan, et al. Expires August 12, 2005 [Page 30]
Internet-Draft DNAv6 BCP for hosts February 2005
draft-ietf-seamoby-card-protocol-06 (work in progress), January
2004.
[21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std
802.11, 1999.
[22] Yamamoto, S., "Detecting Network Attachment Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004.
[23] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004.
[24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-jinchor-dna-cpl-00.txt (work in
progress), June 2004.
[25] Choi, J. and G. Daley, "Detecting Network Attachment in IPv6
Goals", draft-ietf-dna-goals-04.txt (work in progress),
December 2004.
Authors' Addresses
Sathya Narayanan
Panasonic Digital Networking Lab
Two Research Way, 3rd Floor
Princeton, NJ 08536
USA
Phone: 609 734 7599
EMail: sathya@Research.Panasonic.COM
URI:
Greg Daley
Centre for Telecommunications and Information Engineering
Department of Electrical adn Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 4655
EMail: greg.daley@eng.monash.edu.au
Narayanan, et al. Expires August 12, 2005 [Page 31]
Internet-Draft DNAv6 BCP for hosts February 2005
Nicolas Montavont
LSIIT - Univerity Louis Pasteur
Pole API, bureau C444
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 87
EMail: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Appendix A. Summary of Recommendations
The signaling which causes a hint may be due to network-layer
messages such as unexpected Router Advertisements, multicast listener
queries or ICMPv6 error messages [1][9][11][6]. In these cases,
caution must be exerted.
Hosts MUST ensure that untrusted messages do not cause unnecessary
configuration changes, or significant consumption of host resources
or bandwidth.
Care must be taken when there is a chance of an error or change in
the configuration. Otherwise, if the assumptions due to the stored
configuration are incorrect the configuration cost may be increased,
or even harm to other devices.
Hosts MUST ensure that they will cause no harm to other devices due
to the invalidity or staleness of their configuration.
If a host has not been present on a link to defend its address, and
has been absent for a full DAD delay (minus transmission time) the
host MUST undertake the full DAD procedure for each address from that
link it wishes to configure [3].
Hosts that travel in wireless IPv6 networks of unknown topology must
determine appropriate procedures in order to minimize detection
latency or preserve energy resources.
Hints SHOULD NOT be considered to be authoritative for detecting IP
configuration change by themselves.
Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers.
While hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change.
Narayanan, et al. Expires August 12, 2005 [Page 32]
Internet-Draft DNAv6 BCP for hosts February 2005
Hosts SHOULD NOT start DNA procedures simply because a data link is
idle, in accordance with [1]. Hosts MAY act on hints associated with
non-reception of expected signaling or data.
Since DNA is likely to be used when communicating with devices over
wireless links, suitable resilience to packet loss SHOULD be
incorporated into either the hinting mechanism, or the DNA initiation
system.
Hosts SHOULD NOT act immediately on packet loss indications, delaying
until it is clear that the packet losses aren't caused by transient
events.
It is possible that hints arrive synchronously on multiple hosts at
the same time. As described in [1][3], a host SHOULD delay randomly
before acting on a widely receivable advertisement, in order to avoid
response implosion.
Where a host considers it may be on a new link and learns this from a
hint generated by a multicast message, the host SHOULD defer 0-1000ms
in accordance with [1].
When experiencing a large number of hints, a host SHOULD employ
hysteresis techniques to prevent excessive use of network resources.
The host MAY change the weight of particular hints, to devalue them
if their accuracy has been poor, or suggests invalid configurations.
These (inactive) hosts SHOULD delay 0-1000ms before sending a
solicitation, and MAY choose to wait up to twice the advertised
Router Advertisement Interval (plus the random delay) before sending
[5].
A host MAY choose to adopt an appropriate link change detection
strategy based upon hints received from other layers, with suitable
caution and hysteresis.
If a host knows that connectivity has been lost at the link-layer, it
SHOULD pause transmission of upper-layer packets to the lower-layer,
until general data frames can be send on the new cell.
A host SHOULD also stop sending signaling for the purpose of DNA to a
link-layer it has been reliably informed is unavailable.
In order to determine validity of configuration in such topologies,
reachability testing MAY be required. Additionally, reception of
solicited Router Advertisements some heuristic SHOULD be used, where
possible, to ensure that complete prefix information is received by
the host. This may limit the false detection of link change due to
Narayanan, et al. Expires August 12, 2005 [Page 33]
Internet-Draft DNAv6 BCP for hosts February 2005
omitted prefixes.
If a host has recently received a solicited Router Advertisement from
the configured router, it SHOULD see all prefixes configured on the
router's interface at the time [1]. Subsequent reception of a Router
Advertisement with a prefix not in the set means that the current IP
configuration is invalid, and addressing and routing configuration
procedures SHOULD be started.
Also, some networks enforce IP address changes when link-layer change
occurs. Devices that are aware of such procedures SHOULD start IP
configuration immediately on attachment to a new link-layer.
While most wireless access networks today contain one advertising
router, hosts SHOULD NOT immediately assume that only one router is
on a link.
Importantly, a host SHOULD NOT change its configuration if a new
router advertises a prefix known to be used by another router on the
same IP link. For such cases, hosts SHOULD undertake reachability
testing with the previously configured router before updating their
routing configuration [1].
Additionally, use of only unsolicited Router Advertisements may cause
detection or configuration of links where routers are unable to
receive packets from the host. Reachability testing SHOULD be done
in accordance with [1].
In any case, a secured router SHOULD be preferred over an unsecured
one, except where other factors (unreachability) make the router
unsuitable.
When using the passive method, absence of Router Advertisements (RA)
from the current default router MAY require verification and
acquisition of configuration using one of the active mechanisms
Hints MAY be used to update a wireless host's timers or probing
behavior in such a way as to assist detection of network attachment.
A host MAY choose to adopt an appropriate link change detection
strategy based upon hints received from other layers, with suitable
caution and hysteresis.
Hosts MAY act on hints associated with non-reception of expected
signaling or data.
If a host does not expect to send or receive packets soon, it MAY
choose to defer detection of network attachment.
Narayanan, et al. Expires August 12, 2005 [Page 34]
Internet-Draft DNAv6 BCP for hosts February 2005
If no packet transmission on the wireless link has occurred, before
the new IP configuration is used for upper layer protocols, hosts MAY
choose not to delay the reachability probe to the router, if the
transmission time is unrelated to received multicast packets.
In the case that the host arrives back on the same link in time less
than the DAD completion time (minus a packet transmission and
propagation time), the host MAY reclaim the address by sending
Neighbor Advertisement messages as if another host had attempted DAD
while the host was away. This will prevent DAD completion by another
node upon NA reception.
Reception of Router Advertisements that do not contain any prefixes
in common with the previously advertised set MAY be an indicator that
link change has occurred. IPv6 Neighbor Discovery [1] explicitly
allows such configurations to exist though, and additionally allows
omission of prefix information options in unsolicited Router
Advertisements. In order to determine validity of configuration in
such topologies, reachability testing MAY be required.
Appendix B. Example State Transition Diagram
Below is an example state diagram which indicates relationships
between the practices in this document.
Narayanan, et al. Expires August 12, 2005 [Page 35]
Internet-Draft DNAv6 BCP for hosts February 2005
+---------+ +----------+
| Test |< - - - - -| Init |===>
|Reachable|<-\ | Config |\
+---------+ +----------+ \
| \ New ^ \
| ID | \
V \ | |
+---------+ +----------+ |
| *Idle | \--| Link ID | |
| |<==========| Check | |
+---------+Same ID +----------+ |
^ |Hint Creds^ |
Timer| |Recv OK | |
| | | |
| | | |
| V | |
+----------+ Hint +----------+ |
|Hysteresis| Recv | Authorize| |
| |<--\ | Check | |
+----------+ \-/ +----------+ |
| ^ | |
|Threshold RA | |Bad /
| Recv| |Auth /
V | V /
+----------+ Solicit +----------+L
| Init |=========>| Hint |
| DNA |<=========|Hysteresis|
+----------+ Timer +----------+
Appendix C. Analysis of Configuration Algorithms
Hosts that travel in wireless IPv6 networks of unknown topology must
determine appropriate procedures in order to minimize detection
latency or preserve energy resources. If a host is prepared to
accept any received Router Advertisement for configuring a default
router, then it will complete link change detection more quickly than
a device that explicitly checks for the current router's
unreachability.
This mechanism is called Eager Configuration Switching [16]. It may
cause unnecessary configuration operations, especially if unsolicited
advertisements from multiple routers on a link are received
containing disjoint sets of prefixes. In this case, a configuration
per distinct set will result [1].
Additionally, use of only unsolicited Router Advertisements may cause
Narayanan, et al. Expires August 12, 2005 [Page 36]
Internet-Draft DNAv6 BCP for hosts February 2005
detection or configuration of links where routers are unable to
receive packets from the host. Reachability testing SHOULD be done
in accordance with [1].
Another alternative, which reduces the problem associated with
disjoint prefixes, only allows eager switching after link-layer hint
indicating that a cell change has occurred. Although another router
on the link may respond faster than the currently configured default
router, it will not lead to erroneous detection if the router was
previously seen before the link-layer hint was processed.
An alternative mechanism is called Lazy Configuration Switching [16].
This algorithm checks that the currently configured router is
reachable before indicating configuration change. In this case, new
configuration will be delayed until a timeout occurs, if the
currently configured router is unreachable.
Since the duration of such a timeout will significantly extend the
duration to detect link change, this procedure is best used if the
cell change to link change ratio is very low.
For example, if the expected time to:
Successfully test reachability (with NS/NA) is N
Test unreachability with a timeout is T
Receive a Router Advertisement is R
Reconfigure the host is C
Then the probability of L3 link change given a L2 point of attachment
has changed is
p = (Number of L3 links)/(Number of L2 Point of attachment)
The probability of received RA being from a router different from the
current access router is
p1 = (sum of all (nr - 1)/ NR)
Where nr is the number of routers in each L3 link and NR is the total
number of routers in the whole network under study.
Note that if you don't have multiple routers in the same L3 link,
then all the (nr - 1) will be zero leading to
p1 = 0
Then the mean cost of Eager Configuration switching is:
Narayanan, et al. Expires August 12, 2005 [Page 37]
Internet-Draft DNAv6 BCP for hosts February 2005
Cost(ECS)= (R + C) * (p + p1)
And the cost of Lazy switching is:
Cost(LCS)= (T + R + C) * p + (1 - p) * N
The mean cost due to Lazy Configuration Switching is lower than that
of Eager Configuration Switching if:
( T + R + C ) * p + (1 - p) * N < (R + C) * (p + p1)
Using the indicative figures:
N=100ms
T=1000ms
R=100ms
C=500ms
The values for p where LCS is better than ECS are:
p * (1000 + 100 + 500 )ms + < (500 + 100)ms *
(1 - p)*100ms (p + p1)
1600ms * p + 100ms - 100ms * p < 600ms * (p + p1)
900ms * p + 100 ms < 600ms * p1
when p1 = 30%
900 * p + 100 < 180
900 * p < 80
p < 0.0888
For these parameters, the Lazy Configuration Switching has better
performance if the mean number of cells a device resides in before it
has a link change is > 11.
It may be noted that these costs are indicative of a system which
requires a retransmission timeout of 1000ms to test unreachability,
routers respond with unicast Router Advertisements, and DAD is
neglected or has only 100ms of cost.
If the reconfiguration cost is C=1000ms you will have
Narayanan, et al. Expires August 12, 2005 [Page 38]
Internet-Draft DNAv6 BCP for hosts February 2005
900 * p + 100 ms < 1100 * p1
if p1 = 30 %
900 * p < 230
p < 0.2555
For these parameters, the Lazy Configuration Switching has better
performance if the mean number of cells a device resides in before it
has a link change is between 3 & 4. This system describes a similar
one to that above, except that in this case, the delays due to DAD or
configuration are the default value of 1000ms.
Appendix D. DNA With Fast Handovers for Mobile IPv6
TBD
Appendix E. DNA with Candidate Access Router Discovery
TBD
Narayanan, et al. Expires August 12, 2005 [Page 39]
Internet-Draft DNAv6 BCP for hosts February 2005
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 (2005). 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.
Narayanan, et al. Expires August 12, 2005 [Page 40]
| PAFTECH AB 2003-2026 | 2026-04-23 04:04:49 |