draft-ietf-dna-hosts-02.txt   draft-ietf-dna-hosts-03.txt 
DNA Working Group S. Narayanan DNA Working Group S. Narayanan
Internet-Draft Panasonic Internet-Draft G. Daley
Expires: April 27, 2006 G. Daley Expires: November 11, 2006 Panasonic
Monash University CTIE
N. Montavont N. Montavont
LSIIT - ULP GET - ENST Bretagne
October 24, 2005 May 10, 2006
Detecting Network Attachment in IPv6 - Best Current Practices for hosts. Detecting Network Attachment in IPv6 - Best Current Practices for hosts.
draft-ietf-dna-hosts-02.txt draft-ietf-dna-hosts-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 36
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 April 27, 2006. This Internet-Draft will expire on November 11, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Hosts experiencing rapid link-layer changes may require efficient IP Hosts experiencing rapid link-layer changes may require efficient IP
configuration change detection procedures than 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 ascertain the validity of its IP configuration. attached link to ascertain 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 40 skipping to change at page 2, line 38
5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11
5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12 5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12
5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12 5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12
5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 12 5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 12
5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13 5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13
5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 13 5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 13
5.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 14 5.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 14
6. Complications to Detecting Network Attachment . . . . . . . . 14 6. Complications to Detecting Network Attachment . . . . . . . . 14
6.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Router Configurations . . . . . . . . . . . . . . . . . . 15 6.2 Router Configurations . . . . . . . . . . . . . . . . . . 15
6.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 15 6.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 15
6.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 15 6.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 15
6.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 16 6.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1 Authorization and Detecting Network Attachment . . . . . . 16 7.1 Authorization and Detecting Network Attachment . . . . . . 16
7.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 4, line 13 skipping to change at page 4, line 13
Intellectual Property and Copyright Statements . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 21
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 [14].
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 such cases, IP addressing and default routing configuration of the In such cases, IP addressing and default routing configuration of the
node may become invalid preventing packet transfer. DNA uses IPv6 node may become invalid preventing packet transfer. DNA uses IPv6
Neighbour Discovery to provide information about the reachability and Neighbour Discovery to provide information about the reachability and
identity of the link. 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
1.1 Structure of this Document 1.1 Structure of this Document
Section 3 of this document provides 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. initiation of DNA procedures.
Section 7 provides security considerations, and details a number of Section 7 provides security considerations, and details a number of
skipping to change at page 7, line 28 skipping to change at page 7, line 35
(see Section 4.6). (see Section 4.6).
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 [18] and CARD [19] 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. Additionally, the issue is the same when a before arrival on a link. Additionally, the issue is the same when a
host disconnects from one cell and returns to it immediately, or 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. When a period of time in order to use the information in the future. When a
host attaches itself to a point-of-attachment for which it has an L2 host attaches itself to a point-of-attachment for which it has an L2
to L3 mapping, if the stored record doesn't contain the prefix the to L3 mapping, if the stored record doesn't contain the prefix the
host is using, the host SHOULD conclude that it has changed link and host is using, the host SHOULD conclude that it has changed link and
skipping to change at page 8, line 42 skipping to change at page 8, line 48
4.2.2 Link change 4.2.2 Link change
A host makes use of Router Discovery messages to determine that it 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 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, RA is not sufficient to identify the absence of any other prefix,
additional inference is required for fast and accurate link-change additional inference is required for fast and accurate link-change
detection. detection.
Complete Prefix Lists provide a robust mechanism for link-change Complete Prefix Lists provide a robust mechanism for link-change
detection if link-layer indications are available [24][18]. These detection if link-layer indications are available [22][17]. These
procedures provide mechanisms to build confidence that a host knows procedures provide mechanisms to build confidence that a host knows
all of a link's prefixes and so may rapidly identify a newly received all of a link's prefixes and so may rapidly identify a newly received
RA as being from a different link. 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. [22] to identify if the link has changed.
4.3 IP Hosts Configuration 4.3 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 link- Following is the list of steps the host needs to take if a link-
change has occured. change has occured.
Invalidation of router and prefix list: On determining that link- Invalidation of router and prefix list: On determining that link-
skipping to change at page 9, line 51 skipping to change at page 10, line 9
4.4 Duplicate Address Detection 4.4 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 to ensure that the link-local address is unique on a address. But to ensure that the link-local address is unique on a
link, Duplication Address Detection (DAD) MUST be performed [3] by link, Duplication Address Detection (DAD) MUST be performed [3] by
sending 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 ensure that persistent invalid
invalid neighbour cache entries are not created. This may allow neighbour cache entries are not created. This may allow faster DNA
faster DNA procedures, by avoiding use of unspecified source procedures, by avoiding use of unspecified source addresses in RS's
addresses in RS's and consequently allowing unicast Router and consequently allowing unicast Router Advertisements responses.
Advertisements responses [8]. It is RECOMMENDED that hosts follow It is RECOMMENDED that hosts follow the recommendations of optimistic
the recommendations of optimistic DAD [8] to reduce the DAD delay. DAD to reduce the DAD delay [8]
4.5 Multicast Listener State 4.5 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] multicast routing for off-link multicast sources to the link [9]
[11]. [10].
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 [10].
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.
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 6.4. described in Section 6.4.
4.6 Reachability detection 4.6 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
skipping to change at page 12, line 16 skipping to change at page 12, line 22
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 SHOULD send Router Solicitation messages to occurred, a host SHOULD send Router Solicitation messages to
determine the routers and prefixes which exist on a link. Hosts determine the routers and prefixes which exist on a link. Hosts
SHOULD apply rate limiting and/or hysteresis to this behaviour as SHOULD apply rate limiting and/or hysteresis to this behaviour as
appropriate to the link technology subject to the reliability of the appropriate to the link technology subject to the reliability of the
hints. 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 [22].
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
skipping to change at page 12, line 44 skipping to change at page 12, line 50
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
Events at other protocol layers may provide hints of link change to Events at other protocol layers may provide hints of link change to
network attachment detection systems. Two examples of such events network attachment detection systems. Two examples of such events
are TCP retransmission timeout and completion of link-layer access are TCP retransmission timeout and completion of link-layer access
procedures [18]. procedures [17].
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 [20]) or be inaccurate with regard to
network-layer state. network-layer state.
While these hints come from the host's own stack, such hints may While these hints come from the host's own stack, such hints may
actually 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.
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 adopt an appropriate hints from other protocol layers. A host MAY adopt an appropriate
skipping to change at page 15, line 46 skipping to change at page 16, line 6
For the purposes of DNA, it is necessary to treat each of these For the purposes of DNA, it is necessary to treat each of these
points-of-attachment separately, otherwise incorrect conclusions of points-of-attachment separately, otherwise incorrect conclusions of
link-change may be made even if another of the link-layer connections link-change may be made even if another of the link-layer connections
is valid. is valid.
6.4 Multicast Snooping 6.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][10] [16]. 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.
Where it is possible that multicast snooping is in operation, hosts Where it is possible that multicast snooping is in operation, hosts
MUST send MLD group joins (MLD reports) for solicited nodes' MUST send MLD group joins (MLD reports) for solicited nodes'
addresses swiftly after starting DNA procedures. addresses swiftly after starting DNA procedures.
6.5 Link Partition 6.5 Link Partition
skipping to change at page 16, line 30 skipping to change at page 16, line 38
Detecting Network Attachment is a mechanism which allows network Detecting Network Attachment is a mechanism which allows network
messages to change the node's belief about its IPv6 configuration messages to change the node's belief about its IPv6 configuration
state. As such, it is important that the need for rapid testing of state. As such, it is important that the need for rapid testing of
link change does not lead to situations where configuration is link change does not lead to situations where configuration is
invalidated by malicious third parties, nor that information passed invalidated by malicious third parties, nor that information passed
to configuration processes exposes the host to other attacks. to configuration processes exposes the host to other attacks.
Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats
which are applicable to those procedures also affect Detecting which are applicable to those procedures also affect Detecting
Network Attachment. These threats are described in [12]. Network Attachment. These threats are described in [11].
Some additional threats are outlined below. Some additional threats are outlined below.
7.1 Authorization and Detecting Network Attachment 7.1 Authorization and Detecting Network Attachment
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 [11]. Where a host wishes to configure an unsecured router,
it SHOULD confirm bidirectional reachability with the device, and it it SHOULD confirm bidirectional reachability with the 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.
skipping to change at page 18, line 9 skipping to change at page 18, line 18
[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., Zill, B., and P. Nikander, "SEcure [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", [8] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
draft-ietf-ipv6-optimistic-dad-02 (work in progress), IPv6", RFC 4429, April 2006.
September 2004.
10.2 Informative References 10.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] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
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. (MLDv2) for IPv6", RFC 3810, June 2004.
[12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [11] 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. [12] 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) [13] 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", [14] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
draft-ietf-dna-goals-04 (work in progress), December 2004. in IPv6", RFC 4135, August 2005.
[16] Fikouras, N A., K"onsgen, A J., and C. G"org, "Accelerating [15] 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 Computer- Measurement, Modelling, and Evaluation of Computer-
Communication Systems (MMB) 2001, September 2001. Communication Systems (MMB) 2001, September 2001.
[17] Christensen, M., Kimball, K., and F. Solensky, "Considerations [16] Christensen, M., Kimball, K., and F. Solensky, "Considerations
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12
(work in progress), February 2005. (work in progress), February 2005.
[18] Yegin, A., "Link-layer Event Notifications for Detecting [17] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 (work Network Attachments", draft-ietf-dna-link-information-00 (work
in progress), September 2004. in progress), September 2004.
[19] Koodli, R., "Fast Handovers for Mobile IPv6", [18] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
draft-ietf-mipshop-fast-mipv6-03 (work in progress), July 2005.
October 2004.
[20] Liebsch, M., "Candidate Access Router Discovery", [19] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim,
draft-ietf-seamoby-card-protocol-08 (work in progress), "Candidate Access Router Discovery (CARD)", RFC 4066,
September 2004. July 2005.
[21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control [20] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE
Std 802.11, 1999. Std 802.11, 1999.
[22] Yamamoto, S., "Detecting Network Attachment Terminology", [21] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004. RFC 3753, June 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 [22] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix
list based approach", draft-j-dna-cpl-00 (work in progress), list based approach", draft-ietf-dna-cpl-02 (work in progress),
October 2005. January 2006.
Authors' Addresses Authors' Addresses
Sathya Narayanan Sathya Narayanan
Panasonic Digital Networking Lab Panasonic Princeton 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 Panasonic Princeton Lab
Department of Electrical adn Computer Systems Engineering Two Research Way, 3rd Floor
Monash University Princeton, NJ 08536
Clayton, Victoria 3800 USA
Australia
Phone: 609 734 7334
Email: gregd@Research.Panasonic.COM
URI:
Phone: +61 3 9905 4655
Email: greg.daley@eng.monash.edu.au
Nicolas Montavont Nicolas Montavont
LSIIT - Univerity Louis Pasteur GET - ENST Bretagne
Pole API, bureau C444 Departement RSM
Boulevard Sebastien Brant 2, rue de la chataigneraie
Illkirch 67400 Cesson-Sevigne 35576
FRANCE FRANCE
Phone: (33) 3 90 24 45 87 Phone: (33) 2 99 12 70 23
Email: montavont@dpt-info.u-strasbg.fr Email: nicolas.montavont@enst-bretagne.fr
URI: http://www-r2.u-strasbg.fr/~montavont/ URI: http://www.rennes.enst-bretagne.fr/~montavont/
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
skipping to change at page 21, line 41 skipping to change at page 21, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 42 change blocks. 
76 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/