DNA WG JinHyeock. Choi
Internet-Draft Samsung AIT
Expires: October 23, 2005 Erik. Nordmark
Sun
April 21, 2005
DNA solution framework
draft-ietf-dna-soln-frame-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 23, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft captures the authors' opinions and is intended to serve as
input to the discussion for the solution in the DNA WG. It presents
a few assumptions for DNA solution. The draft proposes the solution
to be based on 1) link identity, 2) RS/RA exchange formed so that a
host can determine whether it has moved from a single RA, and 3)
Quick delivery of an RA. The draft sketches what rough shape DNA
solution could take, including the necessary interaction with
Choi & Nordmark Expires October 23, 2005 [Page 1]
Internet-Draft DNA solution framework April 2005
Duplicate Address Detection and the Multicast Listener Discovery
protocol. It also enumerate a few tasks to be worked on and issues
to be resolved for efficient DNA solution.
Table of Contents
1. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 4
2.1 DNA solution based on link identity detection . . . . . . 4
2.2 Using a RS/RA exchange to determine the link identity . . 4
2.3 Quick delivery of an RA . . . . . . . . . . . . . . . . . 5
3. DNA Solution Sketch . . . . . . . . . . . . . . . . . . . . . 6
3.1 Solution components . . . . . . . . . . . . . . . . . . . 6
3.2 Solution procedure . . . . . . . . . . . . . . . . . . . . 6
3.3 Work items . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Checking for link change with Link Identifier . . . . . . 10
4.2 RA optimized for DNA . . . . . . . . . . . . . . . . . . . 10
4.3 Quick delivery of an RA upon link-layer connection . . . . 11
4.4 Links without Link Identification support . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Normative References . . . . . . . . . . . . . . . . . . . 16
8.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19
Choi & Nordmark Expires October 23, 2005 [Page 2]
Internet-Draft DNA solution framework April 2005
1. DNA Overview
Upon establishing a new link-layer connection, a host implementing
the DNA solution should detect the identity of the currently attached
link to ascertain whether it is attached to the same link as before,
or attached to a different link. If the host is attached to a
different link, it also needs to acquire the IP configuration for the
new link. The DNA solution needs to be fast, precise, secure and
have little signaling overhead.[4]
Choi & Nordmark Expires October 23, 2005 [Page 3]
Internet-Draft DNA solution framework April 2005
2. Basic Assumptions
We propose to design DNA solution based upon the following
assumptions.
2.1 DNA solution based on link identity detection
When a host establishes a new link-layer connection, in order to
check whether its IP configuration is still valid, the host checks
for link change, i.e. determine whether it still remains attached to
the same link or not. The term 'link' used in this document is as
defined in [1]. NOTE that that definition is completely different
than the definition of the term 'link' in IEEE 802 standards.
If a link change has occurred, a host assumes that its IP
configuration is no longer valid. Thus it needs at least a new
default router and a new IP address. If it has remained attached to
the same link, the host assumes its IP configuration is still valid,
and performs no further DNA operations.
2.2 Using a RS/RA exchange to determine the link identity
A Router Advertisement message is necessary when the host has
attached to a different link, since the RA contains the new
configuration information. This means that the number of messages
needed for DNA can be minimized if the Router Advertisement message
also contains all the information needed to determine whether or not
there was a link change. In the general case, the host needs to send
a Router Solicitation message so that it can quickly receive a Router
Advertisement. Hence we end up with a suggested approach based on
using a single RS/RA exchange to both determine the link identity,
and to provide the host with the configuration information for a new
link.
See [5] for the DTs different approaches to handle this.
In order for a single RA message to be useful both to detect a link
change, and, should the host have attached to a different link,
useful to initiate the new IP configuration, the RA message needs to
include at least:
1) The information to indicate link change
2) Router address (to select new default router, in case of a link
change)
Choi & Nordmark Expires October 23, 2005 [Page 4]
Internet-Draft DNA solution framework April 2005
3) Prefix(es) (to form a new IP address, in case of a link change)
4) Link-layer address of a router (to immediately send a packet)
We need to investigate whether the above is sufficient.
2.3 Quick delivery of an RA
To quickly check for link change, a host has to receive an RA with
minimum latency. This is difficult due to the random delays for RAs
in response to RSs and rate limiting of multicast RAs in Neighbor
Discovery [1]. For fast DNA solution, we need to find a way to
quickly deliver an RA to a host upon a new link-layer connection.
Choi & Nordmark Expires October 23, 2005 [Page 5]
Internet-Draft DNA solution framework April 2005
3. DNA Solution Sketch
3.1 Solution components
For efficient DNA solution, we may need the following components.
1. RA message optimized for DNA, which 1) properly indicate link
change and 2) carries necessary information for a new IP
configuration.
2. A way to quickly deliver an RA to a host upon a new link-layer
connection.
3. Optimistic DAD [17] and TSLLAO [18] that is being specified in the
IPv6 WG.
4. A procedure to apply DAD during the DNA procedure that is both
efficient and safe should there be a duplicate.
5. A procedure for MLD so that the multicast groups are reported on a
new link.
6. A procedure that handles DHCPv6 address (and other) configuration
for those cases when stateless address autoconfiguration is not
used.
3.2 Solution procedure
With the above, the DNA procedure might be as follows:
Step [0] Network attachment
A host has established a new link-layer connection.
Step [1] Hint
The host receives a hint that a link change might have occurred.
This triggers the host to initiate DNA procedure. For instance, the
hint might consist of the link-layer (device driver) providing a link
Up event notification to the IP layer of the host.
Since the host doesn't know whether it is still attached to the same
link, it needs to take the conservative approach and assumes it might
have moved. Thus it switches to operating in optimistic DAD mode
[17] at this point in time (but since it might still be on the same
link, it would be overkill to immediately send a DAD probe). Since
there might be MLD snooping switches in the network, the host must
Choi & Nordmark Expires October 23, 2005 [Page 6]
Internet-Draft DNA solution framework April 2005
use MLD to join, at least the solicited node multicast addresses that
correspond to its IP addresses, at this point in time, so that it can
receive Neighbor Solicitation messages that might indicate that an
address is a duplicate.
Step [2] RA acquisition
The host acquires an RA optimized for DNA with minimum latency. This
procedure may be initiated either by the host or network.
Either an AP (which implements [13]) immediately sends an RA to the
host, or the host sends an RS to all-routers and one or more routers
on the link responds to the RS with an RA. The first RA from the
router(s) should not be delayed. Several approaches to accomplish
this have been considered by the design team - see [5].
The RS should have the link-local address of the host as the source
address. The RS message needs to contain the TSLLA option [18] to
allow for optimal delivery of the RA in the case when the router
supports TSLLAO, but should not contain a SLLAO option, since the
link-local address might be a duplicate and DAD has not yet been
completed.
If the router implements TSLLAO, the RA would be unicast to the host;
otherwise the RA would either be multicast to all-nodes, or the
router would perform an NS/NA exchange with the host before
unicasting the RA to the host.
Step [3] Link identity detection
Using the mechanism which will be selected by the WG (see [5] for
ones that are being considered), the host determines whether this is
the same link as before.
If it is the same, the host assumes that its IP configuration is
still valid. No further DNA operation is performed and all the host
needs to do is turn off the optimistic DAD mode. (Since the host
didn't move to a different link, we can rely on the DAD which was
performed when the host was first attached to this link. However,
there has been some discussion whether or not DAD should be redone if
a host, independently of DNA, has been disconnected from the link for
some time.)
If the host determines that it is attached to a new link, it
immediately initiates a new IP configuration. The RA contains enough
information to discard old default routers and prefixes, and
configure new ones. (Should there be no "addrconf" prefixes in the
RA, the host would presumably use DHCPv6 for address assignment which
Choi & Nordmark Expires October 23, 2005 [Page 7]
Internet-Draft DNA solution framework April 2005
would take one or two more roundtrips.)
At this point in time it also makes sense for the host to perform DAD
by sending a DAD probe for each configured IP address. When the DAD
probing has completed the host can turn off the optimistic DAD mode.
If neither the old link, nor the potentially new link, use the new
DNA solution for identifying the link, then the host needs to use
prefix based link determination [11] which might require multiple RAs
and even multiple RSs being sent before it can determine whether or
not it is attached to a new link.
Step [4] Multicast group reporting
Should the host have moved to a new link, it needs to send MLD
reports for all the multicast groups it belongs to, in order to
quickly re-establish reception for the multicast groups. (Note that
the solicited-node multicast groups must be handled earlier - as part
of the DAD procedure.) There might be cases when multicast reception
is critical, where it would be beneficial to send the MLD reports
earlier (during step 1) so that, in the case the host has moved to a
new link, any interruption in multicast reception is minimized, even
if this results in unneeded MLD report packets in the case when the
host did not move.
3.3 Work items
It's our opinion that DNA WG (or IPv6 WG in the case of Optimistic
DAD and TSLLAO) needs to work on the following subparts of the DNA
problem:
1. A link identification mechanism from the ones identified in [5]
2. Complete Prefix List for the case when the above new mechanism is
not available[11]
3. Immediate RA responses to RS from the ones identified in [5].
4. Optionally RAs that are sent by APs [13]
5. Optimistic DAD [17] and TSLLAO [18].
6. A procedure to apply DAD during the DNA procedure that is both
efficient and safe should there be a duplicate.
Choi & Nordmark Expires October 23, 2005 [Page 8]
Internet-Draft DNA solution framework April 2005
7. A procedure for MLD so that the multicast groups are reported on a
new link.
8. A procedure that triggers DHCPv6 address (and other) configuration
for those cases when stateless address autoconfiguration is not
used.
Choi & Nordmark Expires October 23, 2005 [Page 9]
Internet-Draft DNA solution framework April 2005
4. Issues
In this section, we enumerate the issues to be resolved for efficient
DNA solution. We don't claim that the list is exhaustive.
4.1 Checking for link change with Link Identifier
[This discussion on this section pre-dates the design team
discussion, thus it might no longer be relevant.]
Usually a host receives configuration information in one or more RA
(Router Advertisement) messages. But it's difficult for a host to
correctly check for link change using a single RA message. No
information in RA can properly indicate whether a link change has
occurred or not. Neither router address nor prefix can do.
It may be better to design a new way to represent a link, 'Link
Identifier'. Each link has its unique and explicit Link Identifier
and all routers attached to the link advertise the same Link
Identifier in their RAs. With an explicit Link Identifier, an RA can
represent a link identity and hosts can check for link change
immediately without resorting to approximate knowledge.
When a host receives an RA with the same Link Identifier, it still
remains at the same link. If it receives an RA with a different Link
Identifier, a link change has occurred and the host is attached to a
different link.
We need to investigate an efficient method to design an explicit Link
Identifier. We may define a new option for Link Identifier. In [9]
Erik Nordmark proposed a new option, Location Indication Option,
which can server as Link Identifier. Also Brett Pentland and all
submitted a draft on Link Identifier [10].
Other approaches can also be used, and many have been discussed in
the Design Team. What is important is that the host can tell whether
it remains on the same link, or has moved to a different link, from
the first Router Advertisement message it receives.
See [5] for different approaches being discussed in the Design Team
on how to handle this.
4.2 RA optimized for DNA
To design RA message optimized for DNA, we need to consider what
kinds of information it needs to contain. We already presented 4
necessary information in Section 2.2 and also it may be useful for an
RA to include the following:
Choi & Nordmark Expires October 23, 2005 [Page 10]
Internet-Draft DNA solution framework April 2005
1') A global IP address of a router
2') All prefixes that the router advertises
4.3 Quick delivery of an RA upon link-layer connection
Upon a new link-layer connection, it may take too long to receive a
RA. A host may passively wait until it receives a periodic RA or,
with link-layer hint, actively send an RS message and receive a
solicited RA in response.
For the first case, the time to receive a RA depends on RA
advertisement interval and it may take many minutes. Even in the
second case there is a delay. A router MUST wait random amount of
time between 0 and 0.5 sec before replying an RA [1]. And if the
router multicasts RAs in response to RSs, the MIN_DELAY_BETWEEN_RAS
in [1] is also a potential problem which must be looked into.
Otherwise this would add the worst-case delay of 3.5 seconds until an
RA is received.
To remedy this, currently two methods are proposed, FRD [13] and
FastRA [14], [15]. In FRD, an AP caches a suitable RA and sends it
immediately upon a new link-layer association. FastRA [14] allows a
router to send an RA without delay with some safety mechanism. [15]
defines a secured mechanism that allows routers to make decisions
about which router responds fastest, and additionally allows other
routers to avoid random delays.
Also see [5] for different approaches to handle this that have been
discussed in the Design Team.
4.4 Links without Link Identification support
A host may visit a link that doesn't support the new DNA solution for
link identification. There are a few cases to consider.
1 Moving from one link using DNA link identification to another link
using DNA link identification (and the link are identified as
being different).
2 Moving from a link using DNA link identification to a link which
is not using it.
3 Moving from a link not using DNA link identification to a link
which is using it.
Choi & Nordmark Expires October 23, 2005 [Page 11]
Internet-Draft DNA solution framework April 2005
4 Moving from a link not using DNA link identification to a link
which is also not using it.
In all those cases, the host needs to be able to perform efficient
DNA.
If the host can always tell from a single RA whether or not the link
is using DNA link identification, then the second and third case
above are easy, because the host must have moved to a different link.
This approach requires that 1) all the routers on a link are
configured uniformly to either use DNA link identification or not,
and 2) all the RAs contain at least a bit to indicate when DNA link
identification is used.
Choi & Nordmark Expires October 23, 2005 [Page 12]
Internet-Draft DNA solution framework April 2005
5. IANA Considerations
No new message formats or services are defined in this document.
Choi & Nordmark Expires October 23, 2005 [Page 13]
Internet-Draft DNA solution framework April 2005
6. Security Considerations
Because DNA schemes are based on Neighbor Discovery, its trust models
and threats are similar to the ones presented in [8]. Nodes
connected over wireless interfaces may be particularly susceptible to
jamming, monitoring and packet insertion attacks. Use of SEND [7] to
secure Neighbor Discovery are important in achieving reliable
detection of network attachment. DNA schemes SHOULD incorporate the
solutions developed in IETF SEND WG if available, where assessment
indicates such procedures are required.
Choi & Nordmark Expires October 23, 2005 [Page 14]
Internet-Draft DNA solution framework April 2005
7. Acknowledgment
The authors wish to express our appreciation to Greg Daley, Thomas
Narten, Pekka Nikander and Alper Yegin for their valuable feedback.
Also Thanks to Samita Chakrabarti, Youn-Hee Han, Gabriel Montenegro,
Nick Moore, Brett Pentland, Ed Remmell and Margaret Wasserman for
their contributions to this draft.
Choi & Nordmark Expires October 23, 2005 [Page 15]
Internet-Draft DNA solution framework April 2005
8. References
8.1 Normative References
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[4] Choi, J., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-04 (work in progress), December 2004.
8.2 Informative References
[5] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P.
Nikander, "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-06 (work in progress), July 2004.
[8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[9] Nordmark, E., "MIPv6: from hindsight to foresight?",
draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
November 2001.
[10] Pentland, B., "Router Advertisement Link Identification for
Mobile IPv6 Movement Detection",
draft-pentland-mobileip-linkid-03 (work in progress),
October 2004.
[11] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005.
[12] Choi, J., "Router Advertisement Issues for Movement Detection/
Detection of Network Attachment", draft-jinchoi-ipv6-cra-00
(work in progress), October 2003.
Choi & Nordmark Expires October 23, 2005 [Page 16]
Internet-Draft DNA solution framework April 2005
[13] Choi, J., "Fast Router Discovery with RA Caching",
draft-jinchoi-dna-frd-00 (work in progress), July 2004.
[14] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router
Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
progress), July 2004.
[15] Daley, G., "Deterministic Fast Router Advertisement
Configuration", draft-daley-dna-det-fastra-01 (work in
progress), October 2004.
[16] Narayanan, S., "Recommendations to achieve efficient Router
Reachability Detection in IPv6 networks",
draft-narayanan-dna-rrd-01 (work in progress), February 2005.
[17] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
draft-ietf-ipv6-optimistic-dad-05 (work in progress),
February 2005.
[18] Daley, G., "Tentative Source Link-Layer Address Options for
IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in
progress), February 2005.
[19] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-01 (work
in progress), February 2005.
[20] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-11 (work in progress), April 2005.
Authors' Addresses
JinHyeock Choi
Samsung AIT
Communication & N/W Lab
P.O.Box 111 Suwon 440-600
KOREA
Phone: +82 31 280 9233
Email: jinchoe@samsung.com
Choi & Nordmark Expires October 23, 2005 [Page 17]
Internet-Draft DNA solution framework April 2005
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
Email: erik.nordmark@sun.com
Choi & Nordmark Expires October 23, 2005 [Page 18]
Internet-Draft DNA solution framework April 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Choi & Nordmark Expires October 23, 2005 [Page 19]
