draft-ietf-dna-hosts-00.txt   draft-ietf-dna-hosts-01.txt 
DNA Working Group S. Narayanan DNA Working Group S. Narayanan
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: October 18, 2005 G. Daley Expires: December 25, 2005 G. Daley
Monash University CTIE Monash University CTIE
N. Montavont N. Montavont
LSIIT - ULP LSIIT - ULP
April 19, 2005 June 23, 2005
Detecting Network Attachment in IPv6 - Best Current Practices for Detecting Network Attachment in IPv6 - Best Current Practices for hosts.
hosts. draft-ietf-dna-hosts-01.txt
draft-ietf-dna-hosts-00.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 18, 2005. This Internet-Draft will expire on December 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
Hosts experiencing rapid link-layer changes may require further IP Hosts experiencing rapid link-layer changes may require efficient IP
configuration change detection procedures than more traditional fixed configuration change detection procedures than traditional fixed
hosts. DNA is defined as the process by which a host collects hosts. DNA is defined as the process by which a host collects
appropriate information and detects the identity of its currently appropriate information and detects the identity of its currently
attached link to ascertains the validity of its IP configuration. attached link to ascertains the validity of its IP configuration.
This document details best current practice for Detecting Network This document details best current practice for Detecting Network
Attachment in IPv6 hosts using existing Neighbor Discovery Attachment in IPv6 hosts using existing Neighbor Discovery
procedures. Since there is no explicit link identification mechanism procedures. Since there is no explicit link identification mechanism
in the existing Neighbor Discovery for IP Version 6, the document in the existing Neighbor Discovery for IP Version 6, the document
describes implicit mechanisms for identifying the current link. describes implicit mechanisms for identifying the current link.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 1.1 Structure of this Document . . . . . . . . . . . . . . . . 5
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
3. Background & Motivation for DNA . . . . . . . . . . . . . . . 5 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 6
3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 6
4.1 Making use of Prior Information . . . . . . . . . . . . . 6
4.2 Duplicate Address Detection . . . . . . . . . . . . . . . 7
4.3 Link identification . . . . . . . . . . . . . . . . . . . 8
4.3.1 Same link . . . . . . . . . . . . . . . . . . . . . . 8
4.3.2 Link change . . . . . . . . . . . . . . . . . . . . . 8
4.4 Multicast Listener State . . . . . . . . . . . . . . . . . 8
4.5 Reachability detection . . . . . . . . . . . . . . . . . . 9
5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 10
5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 10
5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 10
5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 11
5.4 Timer Based Hints . . . . . . . . . . . . . . . . . . . . 12
5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 12
5.6 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 13
5.7 Hint Management for Inactive Hosts . . . . . . . . . . . . 13
6. IP Hosts Configuration . . . . . . . . . . . . . . . . . . . . 14
6.1 Router and Prefix list . . . . . . . . . . . . . . . . . . 14
6.2 IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1 Autoconfiguration . . . . . . . . . . . . . . . . . . 15
6.2.2 Dynamic Host Configuration . . . . . . . . . . . . . . 15
6.3 Neighbor cache . . . . . . . . . . . . . . . . . . . . . . 16
6.4 Mobility Management . . . . . . . . . . . . . . . . . . . 16
7. Complications to Detecting Network Attachment . . . . . . . . 17 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 7
7.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Making use of Prior Information . . . . . . . . . . . . . 7
7.2 Router Configurations . . . . . . . . . . . . . . . . . . 17 4.2 Duplicate Address Detection . . . . . . . . . . . . . . . 8
7.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 17 4.3 Link identification . . . . . . . . . . . . . . . . . . . 9
7.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 18 4.3.1 Same link . . . . . . . . . . . . . . . . . . . . . . 9
7.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 18 4.3.2 Link change . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4.4 Multicast Listener State . . . . . . . . . . . . . . . . . 10
8.1 Authorization and Detecting Network Attachment . . . . . . 19 4.5 Reachability detection . . . . . . . . . . . . . . . . . . 10
8.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11
5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12
5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12
5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 13
5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13
5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 14
5.6 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 14
5.7 Hint Management for Inactive Hosts . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 6. IP Hosts Configuration . . . . . . . . . . . . . . . . . . . . 15
6.1 Router and Prefix list . . . . . . . . . . . . . . . . . . 15
6.2 IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 16
6.2.1 Autoconfiguration . . . . . . . . . . . . . . . . . . 16
6.2.2 Dynamic Host Configuration . . . . . . . . . . . . . . 16
6.3 Neighbor cache . . . . . . . . . . . . . . . . . . . . . . 17
6.4 Mobility Management . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Complications to Detecting Network Attachment . . . . . . . . 18
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 7.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18
11.2 Informative References . . . . . . . . . . . . . . . . . . . 21 7.2 Router Configurations . . . . . . . . . . . . . . . . . . 18
7.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 18
7.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 19
7.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1 Authorization and Detecting Network Attachment . . . . . . 20
8.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Example State Transition Diagram . . . . . . . . . . . . . . . 23 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
B. Analysis of Configuration Algorithms . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
11.2 Informative References . . . . . . . . . . . . . . . . . . 22
C. DNA With Fast Handovers for Mobile IPv6 . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
D. DNA with Candidate Access Router Discovery . . . . . . . . . . 26 A. Example State Transition Diagram . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
When operating in changing environments, IPv6 hosts may experience When operating in changing environments, IPv6 hosts may experience
variations in reachability or configuration state over time. For variations in reachability or configuration state over time. For
hosts accessing the Internet over wireless media, such changes may be hosts accessing the Internet over wireless media, such changes may be
caused by changes in wireless propagation or host motion. caused by changes in wireless propagation or host motion.
Detecting Network Attachment (DNA) in IPv6 is the task of checking Detecting Network Attachment (DNA) in IPv6 is the task of checking
for changes in the validity of a host's IP configuration [15]. for changes in the validity of a host's IP configuration [15].
Changes may occur on establishment or disconnection of a link-layer. Changes may occur on establishment or disconnection of a link-layer.
For newly connected interfaces, they may be on a link different from For newly connected interfaces, they may be on a link different from
the existing configuration of the node. the existing configuration of the node.
In these and other cases, IP addressing and default routing In these and other cases, IP addressing and default routing
configuration of the node may be invalid, which prevents packet configuration of the node may become invalid preventing packet
transfer. DNA uses IPv6 Neighbour Discovery to provide information transfer. DNA uses IPv6 Neighbour Discovery to provide information
about the reachability and identity of the link. about the reachability and identity of the link.
DNA focuses on determining whether the current configuration is DNA focuses on determining whether the current configuration is
valid, leaving the actual practice of re-configuration to other valid, leaving the actual practice of re-configuration to other
subsystems, if the current configuration is invalid. subsystems, if the current configuration is invalid.
This document presents the best current practices for IPv6 hosts to This document presents the best current practices for IPv6 hosts to
address the task of Detecting Network Attachment in changing and address the task of Detecting Network Attachment in changing and
wireless environments. wireless environments.
1.1 Structure of this Document 1.1 Structure of this Document
Section 3 of this document provides a background and motivation for Section 3 of this document provides background and motivation for
Detecting Network Attachment. Detecting Network Attachment.
Elaboration of specific practices for hosts in detecting network Elaboration of specific practices for hosts in detecting network
attachment continues in Section 4, while Section 5 discuss the attachment continues in Section 4, while Section 5 discuss the
initiation of DNA procedures. Section 4 describes how to safely initiation of DNA procedures.
determine network attachment with minimal signaling, across a range
of environments.
Section 8 Provides security considerations, and details a number of Section 6 describes interactions with other protocols, particularly
upon link-change, while Section 7 describes environmental challenges
to detection of network attachment.
Section 8 provides security considerations, and details a number of
issues which arise due to wireless connectivity and the changeable issues which arise due to wireless connectivity and the changeable
nature of DNA hosts' Internet connections. nature of DNA hosts' Internet connections.
This document has a number of appendixes. 2. Terms and Abbreviations
Access network: A network where hosts are present. Especially, a
network used for the support of visiting wireless hosts.
Appendix A provides an example state machine for DNA describing Attachment: The process of entering a new cell. Attachment (and
knowledge and belief based on the prior listed recommendations. A detachment) may cause a link-change.
brief analysis of two known configuration algorithms LCS (Lazy
Configuration Switching) and ECS (Eager Configuration Switching) is
presented in Appendix B. The final two (Appendix C and Appendix D)
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 Cell: A system constituted by the propagation range of a wireless
base station and its serviced hosts. Dependent on topology, one
or many cells may be part of the same link.
There is an existing DNA terminology draft [22]. At this stage, it Hint: An indication from other subsystems or protocol layers that
is unclear if this draft or the mobility terminology [23] draft need link-change may have occurred.
to be referenced, or specific terms need to be placed in this
document.
While the mobility terminology draft may be applicable, the focus of Link: A link is the range across which communications can pass
this draft upon mobile hosts may be distracting for DNA. Comments on without being forwarded through a router [1].
this issue are welcome.
Link-Change: Link-Change occurs when a host moves from a point-of-
attachment on a link, to another point-of-attachment where it is
unable to reach devices belonging to a link, without being
forwarded through a router.
Point-of-Attachment: A link-layer base-station, VLAN or port through
which a device attempts to reach the network. Changes to a
host's point-of-attachment may cause link-change.
Reachability Detection: Determination that a device (such as a
router) is currently reachable, over both a wireless medium, and
any attached fixed network. This is typically achieved using
Neighbor Unreachability Detection procedure [1].
Wireless Medium: A physical layer which incorporates free space
electromagnetic or optical propagation. Such media are
susceptible to mobility and interference effects, potentially
resulting in high packet loss probabilities.
3. Background & Motivation for DNA 3. Background & Motivation for DNA
Hosts on the Internet may be connected by various media. It has Hosts on the Internet may be connected by various media. It has
become common that hosts have access through wireless media and are become common that hosts have access through wireless media and are
mobile, and have a variety of interfaces through which internet mobile, and have a variety of interfaces through which internet
connectivity is provided. The frequency of configuration change for connectivity is provided. The frequency of configuration change for
wireless and nomadic devices are high due to the vagaries of wireless wireless and nomadic devices are high due to the vagaries of wireless
propagation or the motion of the hosts themselves. Detecting Network propagation or the motion of the hosts themselves. Detecting Network
Attachment is a strategy to assist such rapid configuration changes Attachment is a strategy to assist such rapid configuration changes
skipping to change at page 6, line 13 skipping to change at page 7, line 33
identity difficult: identity difficult:
Routers are not required to include all the prefixes they support Routers are not required to include all the prefixes they support
in a single router advertisement message [1]. in a single router advertisement message [1].
The default router address is link-local address and hence may The default router address is link-local address and hence may
only be unique within one link [1]. only be unique within one link [1].
While neighbor cache entries are valid only on a single link, While neighbor cache entries are valid only on a single link,
link-local addresses may be duplicated across many links, and only link-local addresses may be duplicated across many links, and only
global addressing MAY be used to identify if there is a link global addressing can be used to identify if there is a link
change. change.
4. Detecting Network Attachment Steps 4. Detecting Network Attachment Steps
4.1 Making use of Prior Information 4.1 Making use of Prior Information
A device that has recently been attached to a particular wireless A device that has recently been attached to a particular wireless
base station may still have state regarding the IP configuration base station may still have state regarding the IP configuration
valid for use on that link. This allows a host to begin any valid for use on that link. This allows a host to begin any
configuration procedures before checking the ongoing validity and configuration procedures before checking the ongoing validity and
security of the parameters. security of the parameters.
The experimental protocols FMIPv6 [19] and CARD [20] each provide The experimental protocols FMIPv6 [19] and CARD [20] each provide
ways to generate such information using network-layer signaling, ways to generate such information using network-layer signaling,
before arrival on a link. These are respectively described in before arrival on a link. Additionally, the issue is the same when a
Appendix C and Appendix D. Additionally, the issue is the same when host disconnects from one cell and returns to it immediately, or
a host disconnects from one cell and returns to it immediately, or
movement occurs between a pair of cells (the ping-pong effect). movement occurs between a pair of cells (the ping-pong effect).
A IP host MAY store L2 to L3 mapping information for the links for a A IP host MAY store L2 to L3 mapping information for the links for a
period of time in order to use the information in the future. For period of time in order to use the information in the future. When a
example, in 802.11 networks, IP hosts MAY store the L2 address of the host attaches itself to a point-of-attachment for which it has an L2
access points and the corresponding list of prefixes available for to L3 mapping, if the stored record doesn't contain the prefix the
future use. When a host attaches itself to a new L2 link, if the host is using, the host SHOULD conclude that it has changed link and
corresponding stored prefix list doesn't contain the prefix it is initiate a new configuration procedure.
using, the host SHOULD conclude that it has changed link and initiate
new configuration procedure. If the host finds the prefix it is If the host finds the prefix it is using in the stored record, a host
using in the stored list of prefixes, a host MAY conclude that it is MAY conclude that it is on the same link, but SHOULD undertake
on the same link. In this case, the host MUST undertake Duplicate reachability testing as described in Section 4.5. In this case, the
Address Detection [3][8] to confirm that there are no duplicate host MUST undertake Duplicate Address Detection [3][8] to confirm
addresses on the link. that there are no duplicate addresses on the link.
The host MUST age this cached information based on the possibility The host MUST age this cached information based on the possibility
that the link's configuration has changed and MUST NOT store that the link's configuration has changed and MUST NOT store
information beyond either the remaining router or address lifetime or information beyond either the remaining router or address lifetime or
(at the outside) MAC_CACHE_TIME time-units. (at the outside) MAC_CACHE_TIME time-units.
Extreme care MUST be taken in making use of existing prior If the assumptions attached to the stored configuration are incorrect
information. If the assumptions attached to the stored configuration the configuration cost may be increased, or even cause disruption of
are incorrect the configuration cost may be increased, or even cause services to other devices. Hosts MUST NOT cause any disruption of
disruption of services to other devices. Hosts MUST NOT cause any the IP connectivity to other devices due to the invalidity or
disruption of the IP connectivity to other devices due to the staleness of their configuration.
invalidity or staleness of their configuration.
4.2 Duplicate Address Detection 4.2 Duplicate Address Detection
When a host connects to a new link, it needs to create a link-local 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, address. But to ensure that the link-local address is unique on a
Duplication Address Detection (DAD) MUST be performed [3] by sending link, Duplication Address Detection (DAD) MUST be performed [3] by
NS targeted at the link-local address undergoing validation. sending NS targeted at the link-local address undergoing validation.
Optimistic Duplicate Address Detection allows addresses to be used Optimistic Duplicate Address Detection allows addresses to be used
while they are being checked, without marking addresses as tentative. while they are being checked, without marking addresses as tentative.
Procedures defined in optimistic DAD [8] ensure that persistent Procedures defined in optimistic DAD [8] ensure that persistent
invalid neighbour cache entries are not created. This may allow invalid neighbour cache entries are not created. This may allow
faster DNA procedures, by avoiding use of unspecified source faster DNA procedures, by avoiding use of unspecified source
addresses in RS's and consequently allowing unicast Router addresses in RS's and consequently allowing unicast Router
Advertisements responses [8]. It is RECOMMENDED that hosts follow Advertisements responses [8]. It is RECOMMENDED that hosts follow
the recommendations of optimistic DAD [8] to reduce the DAD delay. the recommendations of optimistic DAD [8] to reduce the DAD delay.
While hosts performing DNA do not know if they have arrived on a new Link-local addresses SHOULD be treated as either optimistic or
link, they SHOULD treat their addresses as if they were. This means
that link-local addresses SHOULD be treated as either optimistic or
tentative, and globally unique addresses SHOULD NOT be used in a way tentative, and globally unique addresses SHOULD NOT be used in a way
which creates neighbor cache state on their peers, while DNA which creates neighbor cache state on their peers, while DNA
procedures are underway. The different treatment of IP addressing procedures are underway.
comes from the fact that on the global addresses cannot have an
address conflict if they move to a topologically incorrect network While hosts performing DNA do not know if they have arrived on a new
where link-local addresses may. Even though global addresses will link, they SHOULD treat their addresses as if they were. The
not collide, the incorrect creation of neighbor cache entries on different treatment of IP addressing comes from the fact that on the
legacy peers may cause them some harm. 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.
In the case that the host has not changed link and if the time In the case that the host has not changed link and if the time
elapsed since the hint is less than the DAD completion time (minus a elapsed since the hint is less than the DAD completion time (minus a
packet transmission and propagation time), the host MAY reclaim the packet transmission and propagation time), the host MAY reclaim the
address by sending Neighbor Advertisement messages as if another host address by sending Neighbor Advertisement messages as if another host
had attempted DAD while the host was away. This will prevent DAD had attempted DAD while the host was away. This will prevent DAD
completion by another node upon NA reception. completion by another node upon NA reception.
If a host has not been present on a link to defend its address, and 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 has been absent for a full DAD delay (minus transmission time) the
host MUST undertake the full DAD procedure for each address from that host MUST undertake the full DAD procedure for each address from that
link it wishes to configure [3][8]. link it wishes to configure [3][8].
4.3 Link identification 4.3 Link identification
4.3.1 Same link 4.3.1 Same link
An IP host MUST conclude that it is on the same link if any of the An IP host MUST conclude that it is on the same link if any of the
following events happen. following events happen.
Reception of a RA with the prefix known to be on the link from the Reception of a RA with the prefix known to be on the link from one
current default router address, even if it is the link-local of its default router address, even if it is the link-local
address of the router. address of the router.
Reception of a RA from a known router's global address. Reception of a RA from a known router's global address, present in
a Prefix Information Option containing the R-"Router Address" flag
Reception of data packets addressed to its current global address [5].
if the message was sent from or through a device which is known to
be fixed (such as a router).
A host SHOULD conclude that it is on the same link if any of the A host SHOULD conclude that it is on the same link if any of the
following events happen. following events happen.
Reception of a RA with a known prefix on the link. Reception of a RA with a prefix that is known to be on the current
link.
Reception of data packets addressed to its current global address
if the message was sent from or through a device which is known to
be fixed (such as a router).
Confirmation of a global address entry with the Router 'R' flag Confirmation of a global address entry with the Router 'R' flag
set in its neighbor cache. set in its neighbor cache[1].
4.3.2 Link change 4.3.2 Link change
A host makes use of Router Discovery messages to determine that it
has moved to a new link. Since the content of an existing received
RA is not sufficient to identify the absence of any other prefix,
additional inference is required for fast and accurate link-change
detection.
Complete Prefix Lists provide a robust mechanism for link-change
detection with even unmodified non-DNA routers if link-layer
indications are available [24][18]. These procedures provide
mechanisms to build confidence that a host knows all of a link's
prefixes and so may rapidly identify a newly received RA as being
from a different link.
A host SHOULD maintain a complete prefix list as recommended by A host SHOULD maintain a complete prefix list as recommended by
[24] to identify if the link has changed. [24] to identify if the link has changed.
4.4 Multicast Listener State 4.4 Multicast Listener State
Multicast routers on a link are aware of which groups are in use Multicast routers on a link are aware of which groups are in use
within a link. This information is used to undertake initiation of within a link. This information is used to undertake initiation of
multicast routing for off-link multicast sources to the link [9][11]. 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 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 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 received on the link. If it is an MLDv2 node it SHOULD send state
change reports upon arrival on a link [11]. change reports upon arrival on a link [11].
Since the identity of the link is tied to the presence and identity Since the identity of the link is tied to the presence and identity
of routers, initiation of these procedures may be undertaken when DNA of routers, initiation of these procedures may be undertaken when DNA
procedures have been completed. In the absence of received data procedures have been completed. In the absence of received data
packets from a multicast stream, it is unlikely that a host will be 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 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 link, and will have to send state change reports, in addition to
responses to periodic multicast queries [9][11]. responses to periodic multicast queries [9][11].
For link scoped multicast, reporting needs to be done to ensure that For link scoped multicast, reporting needs to be done to ensure that
packet reception in the link is available due to multicast snoopers. packet reception in the link is available due to multicast snoopers.
Some interaction is possible when sending messages for the purpose of Some interaction is possible when sending messages for the purpose of
DNA on a network where multicast snooping is in use. This issue is DNA on a network where multicast snooping is in use. This issue is
described in Section 7.4. described in Section 7.4.
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.
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 7.4
4.5 Reachability detection 4.5 Reachability detection
If an IP node needs to confirm bi-directional reachability to its 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 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 used to conduct reachability testing. It is notable that the choice
of whether the messages are addressed to multicast or unicast address of whether the messages are addressed to multicast or unicast address
will have different reachability implications. The reachability will have different reachability implications. The reachability
implications from the hosts' perspective for the four different implications from the hosts' perspective for the four different
message exchanges defined by RFC 2461 [1] are presented in the table message exchanges defined by RFC 2461 [1] are presented in the table
below. The host can confirm bi-directional reachability from the below. The host can confirm bi-directional reachability from the
skipping to change at page 9, line 46 skipping to change at page 11, line 25
or whether it is a periodic un-solicited transmission from the router or whether it is a periodic un-solicited transmission from the router
[1]. [1].
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| Exchanges: |Upstream |Downstream| | Exchanges: |Upstream |Downstream|
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| multicast NS/NA | Y | Y | | multicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| unicast NS/NA | Y | Y | | unicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| RS/multicast RA | Y | N | | RS/multicast RA | N | Y |
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| RS/unicast RA | Y | Y | | RS/unicast RA | Y | Y |
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
Successful exchange of the messages listed in the table indicate the Successful exchange of the messages listed in the table indicate the
corresponding links to be operational. Lack of reception of response corresponding links to be operational. Lack of reception of response
from the router may indicate that reachability is broken for one or from the router may indicate that reachability is broken for one or
both of the transmission directions or it may indicate an ordinary both of the transmission directions or it may indicate an ordinary
packet loss event in either direction. packet loss event in either direction.
Whenever a host receives a hint (see Section 5, after identifying the Link-change detection incorporates message reception which may itself
link, it SHOULD verify partial reachability from its default router create neighbour reachability state. When this is the case, a host
to itself. SHOULD rely upon existing Neighbor Discovery procedures in order to
provide and maintain reachability detection [1].
5. Initiation of DNA Procedures 5. Initiation of DNA Procedures
Link change detection procedures are initiated when information is Link change detection procedures are initiated when information is
received either directly from the network or from other protocol received either directly from the network or from other protocol
layers within the host. This information indicates that network layers within the host. This information indicates that network
reachability or configuration is suspect and is called a hint. reachability or configuration is suspect and is called a hint.
Hints MAY be used to update a wireless host's timers or probing 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. behavior in such a way as to assist detection of network attachment.
skipping to change at page 10, line 41 skipping to change at page 12, line 21
Hosts MUST ensure that untrusted hints do not cause unnecessary Hosts MUST ensure that untrusted hints do not cause unnecessary
configuration changes, or significant consumption of host resources configuration changes, or significant consumption of host resources
or bandwidth. In order to achieve this aim, a host MAY implement or bandwidth. In order to achieve this aim, a host MAY implement
hysteresis mechanisms such as token buckets, hint weighting or hysteresis mechanisms such as token buckets, hint weighting or
holddown timers in order to limit the effect of excessive hints (see holddown timers in order to limit the effect of excessive hints (see
Section 5.6). Section 5.6).
5.1 Actions Upon Hint Reception 5.1 Actions Upon Hint Reception
Upon reception of a hint that link change detection may have Upon reception of a hint that link change detection may have
occurred, a host MAY send Router Solicitation messages to determine occurred, a host SHOULD send Router Solicitation messages to
the routers and prefixes which exist on a link. determine the routers and prefixes which exist on a link. Hosts
SHOULD apply rate limiting and/or hysteresis to this behaviour as
appropriate to the link technology subject to the reliability of the
hints.
Router Advertisements received as a result of such solicitation have Router Advertisements received as a result of such solicitation have
a role in determining if existing configuration is valid, and may be a role in determining if existing configuration is valid, and may be
used to construct prefix lists for a new link [24]. used to construct prefix lists for a new link [24].
5.2 Hints Due to Network Layer Messages 5.2 Hints Due to Network Layer Messages
Hint reception may be due to network-layer messages such as Hint reception may be due to network-layer messages such as
unexpected Router Advertisements, multicast listener queries or unexpected Router Advertisements, multicast listener queries or
ICMPv6 error messages [1][9][6]. In these cases, the authenticity of ICMPv6 error messages [1][9][6]. In these cases, the authenticity of
the messages MUST be verified before expending resources to initiate the messages MUST be verified before expending resources to initiate
DNA procedure. DNA procedure.
When a host arrives on a new link, hints received due to external IP 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 packets will typically be due to multicast messages. Actions based
receiving these messages is likely as in most cases intervals between on multicast reception from untrusted sources are dangerous due to
All-Hosts multicast messages are tightly controlled [1][6]. the threat of multicast response flooding. This issue is discussed
Regardless of this, actions based on multicast reception from further in Section 8.
untrusted sources are dangerous due to the threat of transmitter
impersonation. This issue is discussed further in Section 8.
State changes within the network-layer itself may initiate State changes within the network-layer itself may initiate link-
link-change detection procedures. Existing subsystems for router and change detection procedures. Existing subsystems for router and
neighbor discovery, address leasing and multicast reception maintain neighbor discovery, address leasing and multicast reception maintain
their own timers and state variables. Changes to the state of one or 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 more of these mechanisms may hint that link change has occurred, and
initiate detection of network attachment. initiate detection of network attachment.
5.3 Handling Hints from Other Layers 5.3 Handling Hints from Other Layers
Timeouts and state change at other protocol layers may provide hints Events at other protocol layers may provide hints of link change to
of link change to network attachment detection systems. Two examples network attachment detection systems. Two examples of such events
of such state change are TCP retransmission timeout and completion of are TCP retransmission timeout and completion of link-layer access
link-layer access procedures. procedures [18].
While hints from other protocol layers originate from within the While hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change. protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [21]) or be inaccurate with regard to example 802.11 WEP Encryption [21]) or be inaccurate with regard to
network-layer state. network-layer state.
While these hints come from the host's own stack, the causes for such While these hints come from the host's own stack, such hints may
hints may be due to packet reception or non-reception events at the actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to originating layers. As such, it may be possible for other devices to
instigate hint delivery on a host or multiple hosts deliberately, in instigate hint delivery on a host or multiple hosts deliberately, in
order to prompt packet transmission, or configuration modification. 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 Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY choose to adopt an hints from other protocol layers. A host MAY adopt an appropriate
appropriate link change detection strategy based upon hints received link change detection strategy based upon hints received from other
from other layers, with suitable caution and hysteresis, as described layers, with suitable caution and hysteresis, as described in
in Section 5.6. Section 5.6.
5.4 Timer Based Hints
When receiving messages from upper and lower layers, or when 5.4 Timer and Loss Based Hints
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 Other hints may be received due to timer expiry, particularly In some
idle, in accordance with [1]. Hosts MAY act on hints associated with cases the expiry of these timers may be a good hint that DNA
non-reception of expected signaling or data. procedures are necessary.
Since DNA is likely to be used when communicating with devices over Since DNA is likely to be used when communicating with devices over
wireless links, suitable resilience to packet loss SHOULD be wireless links, suitable resilience to packet loss SHOULD be
incorporated into either the hinting mechanism, or the DNA initiation incorporated into the DNA initiation system. Notably, non-reception
system. Notably, non-reception of data associated with end-to-end of data associated with end-to-end communication over the Internet
communication over the Internet may be caused by reception errors at may be caused by reception errors at either end or because of network
either end or because of network congestion. Hosts SHOULD NOT act congestion. Hosts SHOULD NOT act immediately on packet loss
immediately on packet loss indications, delaying until it is clear indications, delaying until it is clear that the packet losses aren't
that the packet losses aren't caused by transient events. caused by transient events.
Use of the Advertisement Interval Option specified in [5] follows Use of the Advertisement Interval Option specified in [5] follows
these principles. Routers sending this option indicate the maximum these principles. Routers sending this option indicate the maximum
interval between successive router advertisements. Hosts receiving interval between successive router advertisements. Hosts receiving
this option monitor for multiple successive packet losses and this option monitor for multiple successive packet losses and
initiate change discovery. initiate change discovery.
5.5 Simultaneous Hints 5.5 Simultaneous Hints
While some link-layer hints may be generated by individual actions, Some events which generate hints may affect a number of devices
other events which generate hints may affect a number of devices simultaneously.
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 For example, if a wireless base station goes down, all the hosts on
that base station are likely to initiate link-layer configuration that base station are likely to initiate link-layer configuration
strategies after losing track of the last beacon or pilot signal from strategies after losing track of the last beacon or pilot signal from
the base station. the base station.
As described in [1][6], a host SHOULD delay randomly before acting on As described in [1][6], a host SHOULD delay randomly before acting on
a widely receivable advertisement, in order to avoid response a widely receivable advertisement, in order to avoid response
implosion. implosion.
Where a host considers it may be on a new link and learns this from a 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 hint generated by a multicast message, the host SHOULD defer 0-1000ms
in accordance with [1][3]. Please note though that a single in accordance with [1][3]. Please note though that a single
desynchronization is required for any number of transmissions desynchronization is required for any number of transmissions
subsequent to a hint, regardless of which messages need to be sent. 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 In link-layers where sufficient serialization occurs after an event
experienced by multiple hosts, each host MAY avoid the random delays experienced by multiple hosts, each host MAY avoid the random delays
before sending solicitations specified in [1]. before sending solicitations specified in [1].
5.6 Hint Validity and Hysteresis 5.6 Hint Validity and Hysteresis
Anecdotal evidence from the initial Detecting Network Attachment BoF In some cases, hints can be generated by lower-layer protocols at an
indicated that hints received at the network layer often did not elevated rate, which do not reflect actual changes in IP
correspond to changes in IP connectivity [18]. configuration. In other cases, hints may also be received prior to
the availability of the medium for network-layer packets.
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 Additionally, since packet reception at the network and other layers
are a source for hints, it is possible for traffic patterns on the are a source for hints, it is possible for traffic patterns on the
link to create hints, through chance or malicious intent. Therefore, link to create hints, through chance or malicious intent. Therefore,
it may be necessary to classify hint sources and types for their it may be necessary to classify hint sources and types for their
relevance and recent behavior. relevance and recent behavior.
When experiencing a large number of hints, a host SHOULD employ When experiencing a large number of hints, a host SHOULD employ
hysteresis techniques to prevent excessive use of network resources. hysteresis techniques to prevent excessive use of network resources.
The host MAY change the weight of particular hints, to devalue them The host MAY change the weight of particular hints, to devalue them
skipping to change at page 13, line 52 skipping to change at page 15, line 16
If a host does not expect to send or receive packets soon, it MAY If a host does not expect to send or receive packets soon, it MAY
choose to defer detection of network attachment. This may preserve choose to defer detection of network attachment. This may preserve
resources on latent hosts, by removing any need for packet resources on latent hosts, by removing any need for packet
transmission when a hint is received. transmission when a hint is received.
These hosts SHOULD delay 0-1000ms before sending a solicitation, and These hosts SHOULD delay 0-1000ms before sending a solicitation, and
MAY choose to wait up to twice the advertised Router Advertisement MAY choose to wait up to twice the advertised Router Advertisement
Interval (plus the random delay) before sending a solicitation [5]. 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 One benefit of inactive hosts' deferral of DNA procedures is that
herd-like host configuration testing is mitigated when base-station herd-like host configuration testing is mitigated when base-station
failure or simultaneous motion occur. When latent hosts defer DNA failure or simultaneous motion occur. When latent hosts defer DNA
tests, the number of devices actively probing for data simultaneously tests, the number of devices actively probing for data simultaneously
is reduced to those hosts which currently support active data is reduced to those hosts which currently support active data
sessions. sessions.
When a device begins sending packets, it will be necessary to test When a device begins sending packets, it will be necessary to test
bidirectional reachability with the router (whose current Neighbor bidirectional reachability with the router (whose current Neighbor
Cache state is STALE). As described in [1], the host will delay Cache state is STALE). As described in [1], the host will delay
before probing to allow for the probability that upper layer packet before probing to allow for the probability that upper layer packet
reception confirms reachability. 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.
6. IP Hosts Configuration 6. IP Hosts Configuration
Various protocols within IPv6 provide their own configuration Various protocols within IPv6 provide their own configuration
processes. A host will have collected various configuration processes. A host will have collected various configuration
information using these protocols during its presence on a link. information using these protocols during its presence on a link.
Following is the list of steps the host needs to take if a Following is the list of steps the host needs to take if a link-
link-change has occured. change has occured.
Invalidationof router and prefix list Invalidationof router and prefix list
Invalidation of IPv6 addresses Invalidation of IPv6 addresses
Removing neighbor cache entries Removing neighbor cache entries
Completion of DAD for Link-Local Addresses.
Initiating mobility signaling Initiating mobility signaling
The following sub-sections eloborate on these steps. The following sub-sections elaborate on these steps.
6.1 Router and Prefix list 6.1 Router and Prefix list
Router Discovery is designed to provide hosts with a set of locally Router Discovery is designed to provide hosts with a set of locally
configurable prefixes and default routers. These may then be configurable prefixes and default routers. These may then be
configured by hosts for access to the Internet [1]. configured by hosts for access to the Internet [1].
It allows hosts to discover routers and manage lists of eligible next It allows hosts to discover routers and manage lists of eligible next
hop gateways, and is based on IPv6 Neighbor Discovery. When one of hop gateways, and is based on IPv6 Neighbor Discovery. When one of
the routers in the router list is determined to be no longer the routers in the router list is determined to be no longer
reachable, its destination cache entry is removed, and new router is reachable, its destination cache entry is removed, and new router is
selected from the list. If the currently configured router is selected from the list. If a currently configured router is
unreachable, it is quite likely that other devices on the same link unreachable, it is quite likely that other devices on the same link
are no longer reachable. are no longer reachable.
On determining that link-change has occurred, the default router list On determining that link-change has occurred, the default router list
SHOULD have entries removed which are related to unreachable routers, SHOULD have entries removed which are related to unreachable routers,
and consequently these routers' destination cache entries SHOULD be and consequently these routers' destination cache entries SHOULD be
removed [1]. If no eligible default routers are in the default removed [1]. If no eligible default routers are in the default
router list, Router Solicitations MAY be sent, in order to discover router list, Router Solicitations MAY be sent, in order to discover
new routers. new routers.
skipping to change at page 17, line 17 skipping to change at page 18, line 17
which themselves rely upon Neighbor Discovery, to initiate mobility which themselves rely upon Neighbor Discovery, to initiate mobility
signaling. These procedures allow for some modification of Neighbor signaling. These procedures allow for some modification of Neighbor
Discovery to enable faster change or movement detection. When a host Discovery to enable faster change or movement detection. When a host
identifies that it is on a new link, if it is Mobile-IPv6 enabled identifies that it is on a new link, if it is Mobile-IPv6 enabled
host, it MAY initiate mobility signaling with its home agent and host, it MAY initiate mobility signaling with its home agent and
correspondent node. correspondent node.
7. Complications to Detecting Network Attachment 7. Complications to Detecting Network Attachment
Detection of network attachment procedures can be delayed or may be Detection of network attachment procedures can be delayed or may be
incorrect due to different factors. As the reachability testing incorrect due to different factors. This section gives some examples
mainly relies on timeout, packet loss or different router where complications may interfere with DNA processing.
configurations may lead to erroneous conclusions. This section gives
some examples where complications may interfere with DNA processing.
7.1 Packet Loss 7.1 Packet Loss
Generally, packet loss introduces significant delays in validation of Generally, packet loss introduces significant delays in validation of
current configuration or discovery of new configuration. Because current configuration or discovery of new configuration. Because
most of the protocols rely on timeout to consider that a peer is not most of the protocols rely on timeout to consider that a peer is not
reachable anymore, packet loss may lead to erroneous conclusions. reachable anymore, packet loss may lead to erroneous conclusions.
Additionally, packet loss rates for particular transmission modes Additionally, packet loss rates for particular transmission modes
(multicast or unicast) may differ, meaning that particular classes of (multicast or unicast) may differ, meaning that particular classes of
DNA tests have higher chance of failure due to loss. Hosts SHOULD DNA tests have higher chance of failure due to loss. Hosts SHOULD
attempt to verify tests through retransmission where packet loss is attempt to verify tests through retransmission where packet loss is
prevalent. prevalent.
7.2 Router Configurations 7.2 Router Configurations
Each router can have its own configuration with respect to sending Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations. RA, and the treatment of router and neighbor solicitations.
skipping to change at page 17, line 40 skipping to change at page 18, line 39
DNA tests have higher chance of failure due to loss. Hosts SHOULD DNA tests have higher chance of failure due to loss. Hosts SHOULD
attempt to verify tests through retransmission where packet loss is attempt to verify tests through retransmission where packet loss is
prevalent. prevalent.
7.2 Router Configurations 7.2 Router Configurations
Each router can have its own configuration with respect to sending Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations. RA, and the treatment of router and neighbor solicitations.
Different timers and constants might be used by different routers, Different timers and constants might be used by different routers,
such as the delay between Router Advertisements or delay before such as the delay between Router Advertisements or delay before
replying to an RS. If a host is changing is IPv6 link, the new replying to an RS. If a host is changing its IPv6 link, the new
router on that link may have a different configuration and may router on that link may have a different configuration and may
introduce more delay than the previous default router of the host. introduce more delay than the previous default router of the host.
The time needed to discover the new link can then be longer than The time needed to discover the new link can then be longer than
expected by the host. expected by the host.
7.3 Overlapping Coverage 7.3 Overlapping Coverage
If a host can be attached to different links at the same time with If a host can be attached to different links at the same time with
the same interface, the host will probably listen to different the same interface, the host will probably listen to different
routers, at least one on each link. To be simultaneously attached to 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 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 access network to another. If the node can still be reachable
through its old link while configuring the interface for its new through its old link while configuring the interface for its new
link, packet loss can be minimized. Such a situation may happen in a link, packet loss can be minimized.
wireless environment if the link layer technology allows the MN to be
simultaneously attached to several points of attachment and if the Such a situation may happen in a wireless environment if the link
coverage area of access points are overlapping. For the purposes of layer technology allows the MN to be simultaneously attached to
DNA, the different links should not be classified as a unique link. several points of attachment and if the coverage area of access
Because if one router or an entire link where the node is attached points are overlapping.
comes down doesn't mean that the other link is also down.
For the purposes of DNA, it is necessary to treat each of these
points-of-attachment separately, otherwise incorrect conclusions of
link-change may be made even if another of the link-layer connections
is valid.
7.4 Multicast Snooping 7.4 Multicast Snooping
When a host is participating in DNA on a link where multicast When a host is participating in DNA on a link where multicast
snooping is in use, multicast packets may not be delivered to the snooping is in use, multicast packets may not be delivered to the
LAN-segment to which the host is attached until MLD signaling has LAN-segment to which the host is attached until MLD signaling has
been performed [9][11][17]. Where DNA relies upon multicast packet been performed [9][11][17]. Where DNA relies upon multicast packet
delivery (for example, if a router needs to send a Neighbor delivery (for example, if a router needs to send a Neighbor
Solicitation to the host), its function will be degraded until after Solicitation to the host), its function will be degraded until after
an MLD report is sent. an MLD report is sent.
skipping to change at page 19, line 19 skipping to change at page 20, line 22
Hosts connecting to the Internet over wireless media may be exposed Hosts connecting to the Internet over wireless media may be exposed
to a variety of network configurations with differing robustness, to a variety of network configurations with differing robustness,
controls and security. controls and security.
When a host is determining if link change has occurred, it may When a host is determining if link change has occurred, it may
receive messages from devices with no advertised security mechanisms receive messages from devices with no advertised security mechanisms
purporting to be routers, nodes sending signed router advertisements purporting to be routers, nodes sending signed router advertisements
but with unknown delegation, or routers whose credentials need to be but with unknown delegation, or routers whose credentials need to be
checked [12]. Where a host wishes to configure an unsecured router, checked [12]. Where a host wishes to configure an unsecured router,
it SHOULD at least confirm bidirectional reachability with the it SHOULD confirm bidirectional reachability with the device, and it
device, and it MUST mark the device as unsecured as described in [7]. MUST mark the device as unsecured as described in [7].
In any case, a secured router SHOULD be preferred over an unsecured In any case, a secured router SHOULD be preferred over an unsecured
one, except where other factors (unreachability) make the router one, except where other factors (unreachability) make the router
unsuitable. Since secured routers' advertisement services may be unsuitable. Since secured routers' advertisement services may be
subject to attack, alternative (secured) reachability mechanisms from subject to attack, alternative (secured) reachability mechanisms from
upper layers, or secured reachability of other devices known to be on upper layers, or secured reachability of other devices known to be on
the same link may be used to check reachability in the first the same link may be used to check reachability in the first
instance. instance.
8.2 Addressing 8.2 Addressing
While a DNA host is checking attachment, and observing DAD, it may While a DNA host is checking for link-change, and observing DAD, it
receive a DAD defense NA from an unsecured source. may receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [7]. for the first configured address [7].
While this is a valid action in the case where a host collides with 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 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 the host returns immediately to the same link, such a DAD defense NA
message can only be a denial-of-service attempt. message can only be a denial-of-service attempt.
If a non-SEND node forges a DAD defense for an address which is still If a non-SEND node forges a DAD defense for an address which is still
in peers' neighbor cache entries, a host may send a SEND protected in peers' neighbor cache entries, a host may send a SEND protected
unicast neighbor solicitation without a source link-layer address unicast neighbor solicitation without a source link-layer address
option to one its peers (which also uses SEND). If this peer is option to one of its peers (which also uses SEND). If this peer is
reachable, it will not have registered the non-SEND DAD defense NA in 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 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. host. Such an NA reception disproves the DAD defense NA's validity.
Therefore, a SEND host performing DNA which receives a DAD defense Therefore, a SEND host performing DNA which receives a DAD defense
from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a
STALE or REACHABLE secure neighbor cache entry, omitting source STALE or REACHABLE secure neighbor cache entry, omitting source link-
link-layer address options. In this case, the host should pick an layer address options. In this case, the host should pick an entry
entry which is likely to have a corresponding entry on the peer. If which is likely to have a corresponding entry on the peer. If the
the host responds within a RetransTimer interval, then the DAD host responds within a RetransTimer interval, then the DAD defense
defense was an attack, and the host SHOULD inform its systems was an attack, and the host SHOULD inform its systems administrator
administrator without disabling the address. without disabling the address.
9. Constants 9. Constants
MAC_CACHE_TIME: 30 minutes MAC_CACHE_TIME: 30 minutes
10. Acknowledgments 10. Acknowledgments
JinHyeock Choi and Erik Nordmark have done lots of work regarding Thanks to JinHyeock Choi and Erik Nordmark for their significant
inference of link identity through sets of prefixes. Bernard Aboba's contributions. Bernard Aboba's work on DNA for IPv4 strongly
work on DNA for IPv4 significantly influenced this document. influenced this document.
11. References 11. References
11.1 Normative References 11.1 Normative References
[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address [3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, [4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998. December 1998.
[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[6] Conta, A. and S. Deering, "Internet Control Message Protocol [6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC2463 2463, December 1998. Specification", RFC2463 2463, December 1998.
[7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 Neighbor Discovery (SEND)", RFC 3971, March 2005.
(work in progress), April 2004.
[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", [8] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
draft-ietf-ipv6-optimistic-dad-02 (work in progress), September draft-ietf-ipv6-optimistic-dad-02 (work in progress),
2004. September 2004.
11.2 Informative References 11.2 Informative References
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[10] Haberman, B., "Source Address Selection for the Multicast [10] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September 2003. Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[12] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[15] Choi, J., "Detecting Network Attachment in IPv6 Goals", [15] Choi, J., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-04 (work in progress), December 2004. draft-ietf-dna-goals-04 (work in progress), December 2004.
[16] Fikouras, N A., K"onsgen, A J. and C. G"org, "Accelerating [16] Fikouras, N A., K"onsgen, A J., and C. G"org, "Accelerating
Mobile IP Hand-offs through Link-layer Information", Mobile IP Hand-offs through Link-layer Information",
Proceedings of the International Multiconference on Proceedings of the International Multiconference on
Measurement, Modelling, and Evaluation of Measurement, Modelling, and Evaluation of Computer-
Computer-Communication Systems (MMB) 2001, September 2001. Communication Systems (MMB) 2001, September 2001.
[17] Christensen, M., Kimball, K. and F. Solensky, "Considerations [17] Christensen, M., Kimball, K., and F. Solensky, "Considerations
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12
(work in progress), May 2004. (work in progress), February 2005.
[18] Kniveton, T J. and B C. Pentland, "Session minutes of the [18] Yegin, A., "Link-layer Event Notifications for Detecting
Detecting Network Attachment (DNA) BoF", Proceedings of the Network Attachments", draft-ietf-dna-link-information-00 (work
fifty-seventh Internet Engineering Task Force Meeting IETF57, in progress), September 2004.
July 2003.
[19] Koodli, R., "Fast Handovers for Mobile IPv6", [19] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-01 (work in progress), February draft-ietf-mipshop-fast-mipv6-03 (work in progress),
2004. October 2004.
[20] Liebsch, M., "Candidate Access Router Discovery", [20] Liebsch, M., "Candidate Access Router Discovery",
draft-ietf-seamoby-card-protocol-06 (work in progress), January draft-ietf-seamoby-card-protocol-08 (work in progress),
2004. September 2004.
[21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control [21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE
802.11, 1999. Std 802.11, 1999.
[22] Yamamoto, S., "Detecting Network Attachment Terminology", [22] Yamamoto, S., "Detecting Network Attachment Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004. draft-yamamoto-dna-term-00 (work in progress), February 2004.
[23] Manner, J. and M. Kojo, "Mobility Related Terminology", [23] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress), draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004. February 2004.
[24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix [24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-jinchor-dna-cpl-00.txt (work in list based approach", draft-j-dna-cpl-00 (work in progress),
progress), June 2004. October 2005.
[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 Authors' Addresses
Sathya Narayanan Sathya Narayanan
Panasonic Digital Networking Lab Panasonic Digital Networking Lab
Two Research Way, 3rd Floor Two Research Way, 3rd Floor
Princeton, NJ 08536 Princeton, NJ 08536
USA USA
Phone: 609 734 7599 Phone: 609 734 7599
EMail: sathya@Research.Panasonic.COM Email: sathya@Research.Panasonic.COM
URI: URI:
Greg Daley Greg Daley
Centre for Telecommunications and Information Engineering Centre for Telecommunications and Information Engineering
Department of Electrical adn Computer Systems Engineering Department of Electrical adn Computer Systems Engineering
Monash University Monash University
Clayton, Victoria 3800 Clayton, Victoria 3800
Australia Australia
Phone: +61 3 9905 4655 Phone: +61 3 9905 4655
EMail: greg.daley@eng.monash.edu.au Email: greg.daley@eng.monash.edu.au
Nicolas Montavont Nicolas Montavont
LSIIT - Univerity Louis Pasteur LSIIT - Univerity Louis Pasteur
Pole API, bureau C444 Pole API, bureau C444
Boulevard Sebastien Brant Boulevard Sebastien Brant
Illkirch 67400 Illkirch 67400
FRANCE FRANCE
Phone: (33) 3 90 24 45 87 Phone: (33) 3 90 24 45 87
EMail: montavont@dpt-info.u-strasbg.fr Email: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/ URI: http://www-r2.u-strasbg.fr/~montavont/
Appendix A. Example State Transition Diagram Appendix A. Example State Transition Diagram
Below is an example state diagram which indicates relationships Below is an example state diagram which indicates relationships
between the practices in this document. between the practices in this document.
+---------+ +----------+ +---------+ +----------+
| Test |< - - - - -| Init |===> | Test |< - - - - -| Init |===>
|Reachable|<-\ | Config |\ |Reachable|<-\ | Config |\
skipping to change at page 23, line 45 skipping to change at page 24, line 45
| V | | | V | |
+----------+ Hint +----------+ | +----------+ Hint +----------+ |
|Hysteresis| Recv | Authorize| | |Hysteresis| Recv | Authorize| |
| |<--\ | Check | | | |<--\ | Check | |
+----------+ \-/ +----------+ | +----------+ \-/ +----------+ |
| ^ | | | ^ | |
|Threshold RA | |Bad / |Threshold RA | |Bad /
| Recv| |Auth / | Recv| |Auth /
V | V / V | V /
+----------+ Solicit +----------+L +----------+ Solicit +----------+L
| Init |=========>| Hint | | Init |=========>|Await |
| DNA |<=========|Hysteresis| | DNA |<=========|Rtr Advert|
+----------+ Timer +----------+ +----------+ Timer +----------+
Appendix B. 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
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:
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
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 C. DNA With Fast Handovers for Mobile IPv6
TBD
Appendix D. DNA with Candidate Access Router Discovery
TBD
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/