DNA WG JinHyeock Choi
Internet-Draft Samsung AIT
Expires: January 10, 2005 Erik Nordmark
SUN Microsystems
July 12, 2004
DNA solution framework
draft-jinchoi-dna-soln-frame-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft captures the authors' personal 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 Identifier, 2) RA optimized for DNA
and 3) Quick delivery of an RA and sketches what rough shape DNA
solution will take. It also enumerate a few tasks to be worked on
and issues to be resolved for efficient DNA solution.
Choi & Nordmark Expires January 10, 2005 [Page 1]
Internet-Draft DNA solution framework July 2004
Table of Contents
1. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 4
2.1 DNA solution based on link identity detection . . . . . . 4
2.2 Checking for link change with Link Identifier . . . . . . 4
2.3 RA message optimized for DNA . . . . . . . . . . . . . . . 4
2.4 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 . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Link Identifier . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 Assign rule: Uniqueness . . . . . . . . . . . . . . . 8
4.1.2 Format . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3 Interpretation Rule: Explicit versus Implicit . . . . 8
4.1.4 Configuration method: Dynamic configuration . . . . . 8
4.1.5 Advertisement rule: When to be included in an RA? . . 9
4.1.6 Links without Link Identifier support . . . . . . . . 9
4.2 RA optimized for DNA . . . . . . . . . . . . . . . . . . . 9
4.3 Quick delivery of an RA upon link-layer connection . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14
8.2 Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Choi & Nordmark Expires January 10, 2005 [Page 2]
Internet-Draft DNA solution framework July 2004
1. DNA Overview
Upon establishing a new link-layer connection, DNA solution should
detect the identity of the currently attached link to ascertain the
validity of the existing IP configuration. They should recognize and
determine whether a link change has occurred and initiate the process
of acquiring a new configuration if necessary. DNA solution needs to
be fast, precise, secure and of little signaling overhead.[7]
Choi & Nordmark Expires January 10, 2005 [Page 3]
Internet-Draft DNA solution framework July 2004
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, to check whether
its IP configuration is still valid, a host checks for link change,
i.e. determine whether it still remains at the same link or not.
The term 'link' used in this document is as defined in [4].
If a link change has occurred, a host assumes that its IP
configuration is no longer valid. It needs new default router and IP
address. If it remains at the same link, a host assumes its IP
configuration is still valid. Its default router is still reachable
and IP address is still valid.
2.2 Checking for link change with Link Identifier
Usually a host receives the link information with RA (Router
Advertisement) messages. But it's difficult for a host to correctly
check for link change with 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 Link Identifier and all
routers in the link advertise the same Link Identifier in RAs. With
a 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 Link Identifier.
We may define a new option for Link Identifier. In [11] 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 [12].
2.3 RA message optimized for DNA
It will be nice for a host if, with the reception of just one RA
message, it can 1) check for link change and 2) collect necessary
Choi & Nordmark Expires January 10, 2005 [Page 4]
Internet-Draft DNA solution framework July 2004
information to initiate a new IP configuration. This will reduce
handoff delay and minimize signaling traffic.
For this, an RA message needs to include at least:
1) Link Identifier (to check for link change)
2) Router address (to select new default router, in case of a link
change)
3) Prefix (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 that the above is (necessary) and sufficient.
2.4 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 [4]. 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 January 10, 2005 [Page 5]
Internet-Draft DNA solution framework July 2004
3. DNA Solution Sketch
3.1 Solution components
For efficient DNA solution, we may need the following components.
1. Link Identifier to represent a link identity properly.
2. RA message optimized for DNA, which carries 1) Link Identifier
and 2) necessary information for a new IP configuration.
3. A way to quickly deliver an RA to a host upon a new link-layer
connection.
4. Optimistic DAD [17] and TSLLAO [18] that is being specified in
the IPv6 WG.
3.2 Solution procedure
With the above, DNA procedure may be like below.
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. The link-layer
(device driver) may provide link-up indication to the IP layer of the
host.
Since the host doesn't know whether it is still attached to the same
link, it takes 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). As a result of
this, the RS message contains the TSLLA option [18].
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 [14]) 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 RA from the router
would not be delayed; something which solves the problem identified
in [15], [16] would be needed. 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
Choi & Nordmark Expires January 10, 2005 [Page 6]
Internet-Draft DNA solution framework July 2004
with the host before unicasting the RA to the host.
Step [3] Link identity detection
The host compares the Link Identifier in the RA with the previous
stored one.
If it is the same, the host assumes that it still remains at the same
link. No further DNA operation is performed and all it needs to do
is turn off the optimistic DAD mode.
If the host receives a different Link Identifier, the host decides
that it has moved to a new link and 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 would take one or two more
roundtrips.) The host also needs to perform DAD by sending the DAD
probe. When the DAD probing has completed the host can turn off the
optimistic DAD mode.
If neither the old link and the potentially new link use Link
Identifier, then the host needs to use prefix based link
determination [13] which might require multiple RAs and even multiple
RSs being sent.
3.3 Work items
It's our opinion that DNA WG (or IPv6 WG in the case of DAD) needs to
work on the following subparts of the DNA problem:
1. Link Identifier [11], [12]
2. Prefix based Approach when Link Identifier is not available[13]
3. Immediate RA responses to RS [15], [16]
4. Optionally RAs that are sent by APs [14]
5. Optimistic DAD [17] and TSLLAO [18]
Choi & Nordmark Expires January 10, 2005 [Page 7]
Internet-Draft DNA solution framework July 2004
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 Link Identifier
A Link Identifier is included in an RA to indicate a link change.
Here are related issues.
4.1.1 Assign rule: Uniqueness
A Link Identifiers should be assigned in such a way that a host could
detect a link change if it moves from one link to another. Hence two
adjacent links should not have the same Link Identifier.
For this, there are two different ways.
1. We assign each link a globally unique Link Identifier.
2. We assign each link a locally unique Link Identifier. 'Locally
unique' means, no two adjacent links have the same Link
Identifier.
Though, in theory, local uniqueness is sufficient, it may entail
several complications. For simplicity's sake, it may be better to
assign a globally unique Link Identifier.
4.1.2 Format
For Link Identifier, we may define a new option. For example
'Location Indication Option' in [11] or 'Link ID Option' in [12]. We
need to investigate an efficient way.
4.1.3 Interpretation Rule: Explicit versus Implicit
We have to decide how a host interprets an RA without a Link
Identifier, i.e. will a host interpret the lack of the same Link
Identifier as confirmation that a link change has occurred?
4.1.4 Configuration method: Dynamic configuration
The multiple routers in a link should advertise the same Link
Identifier. We can manually configure all routers the same Link
Identifier. But it will be convenient to have a way to dynamically
configure the same Link Identifier to all routers.
Choi & Nordmark Expires January 10, 2005 [Page 8]
Internet-Draft DNA solution framework July 2004
4.1.5 Advertisement rule: When to be included in an RA?
A Link Identifier is advertised in an RA. We have to resolve whether
a Link Identifier should be included in all RA messages or in
specific ones.
It seems benefitial to include a Link Identifier at least in every RA
that is sent in response to an RS.
Also, if frequent multicast RAs are used as "beacons" (which might be
needed when the hosts do not receive a "link-up" indication from the
device driver), those beacons should also contain a Link Identifier.
It might be simplest to include a Link Identifier in every RA.
4.1.6 Links without Link Identifier support
A host may visit a link that doesn't support Link Identifier. There
are a few cases to consider.
1 Moving from one link using Link Identifier to another link using
Link Identifier (and the Link Identifiers are different).
2 Moving from a link using Link Identifier to a link which is not
using Link Identifier.
3 Moving from a link not using Link Identifier to a link which is
using Link Identifier.
4 Moving from a link not using Link Identifier to a link which is
not using Link Identifier.
Even in such cases, the host needs to be able to perform DNA.
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 informations in Sec 2.3 and also it may be useful for an RA
to include the following.
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 an
RA. A host may passively receive a periodic RA or, with link-layer
hint, actively send an RS message and receive a solicited RA.
For the first case, the time to receive a RA depends on RA
Choi & Nordmark Expires January 10, 2005 [Page 9]
Internet-Draft DNA solution framework July 2004
advertisement interval and it may take several seconds. Even with
solicitation, a router MUST wait random amount of time between 0 and
0.5 sec before replying an RA [4]. And if the router multicasts RAs
in response to RSs, the MIN_DELAY_BETWEEN_RAS in [4] is also a
potential problem which must be looked into. Otherwise this would
add the worse-case delay of 3 seconds until an RA is received.This
may result in service disruption.
To remedy this, currently two methods are proposed, FRD [14] and
FastRA [15], [16]. In FRD, an AP caches a suitable RA and sends it
immediately upon a new link-layer association. FastRA [15] allows a
router to send an RA without delay with some safety mechanism. [16]
defines a secured mechanism that allows routers to make decisions
about which router responds fastest, and additionally allows other
routers to avoid random delays.
Choi & Nordmark Expires January 10, 2005 [Page 10]
Internet-Draft DNA solution framework July 2004
5. IANA Considerations
No new message formats or services are defined in this document.
Choi & Nordmark Expires January 10, 2005 [Page 11]
Internet-Draft DNA solution framework July 2004
6. Security Considerations
Because DNA schemes are based on Neighbor Discovery, its trust models
and threats are similar to the ones presented in [10]. Nodes
connected over wireless interfaces may be particularly susceptible to
jamming, monitoring and packet insertion attacks. Use of [9] 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 January 10, 2005 [Page 12]
Internet-Draft DNA solution framework July 2004
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 January 10, 2005 [Page 13]
Internet-Draft DNA solution framework July 2004
8. References
8.1 Normative References
[1] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[2] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[7] Choi, J., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-00 (work in progress), June 2004.
8.2 Informative References
[8] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
(work in progress), April 2004.
[10] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[11] Nordmark, E., "MIPv6: from hindsight to foresight?",
draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
November 2001.
[12] Pentland, B., "Router Advertisement Link Identification for
Mobile IPv6 Movement Detection",
draft-pentland-mobileip-linkid-00 (work in progress), May 2003.
[13] Choi, J. and E. Nordmark, "DNA with unmodified routers:
Prefix list based approach", draft-jinchoi-dna-cpl-00.txt
(work in progress), July 2004.
Choi & Nordmark Expires January 10, 2005 [Page 14]
Internet-Draft DNA solution framework July 2004
[14] Choi, J. and D. Shin, "Fast Router Discovery with RA Caching in
AP", draft-jinchoi-mobileip-frd-00 (work in progress), February
2003.
[15] Kempf, J., Khalil, M. and B. Pentland, "IPv6 Fast Router
Advertisement", draft-mkhalil-ipv6-fastra-02 (work in
progress), October 2002.
[16] Daley, G., Pentland, B. and E. Nordmark, "Deterministic Fast
Router Advertisement Options, draft-daley-dna-det-fastra-00.
(work in progress), July 2004.
[17] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
draft-ietf-ipv6-optimistic-dad-01 (work in progress), June
2004.
[18] Daley, G., "Tentative Source Link-Layer Address Options for
IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in
progress), June 2004.
Authors' Addresses
JinHyeock Choi
Samsung AIT
i-Networking Lab
P.O.Box 111 Suwon 440-600
KOREA
Phone: +82 31 280 9233
EMail: jinchoe@samsung.com
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94043
USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Choi & Nordmark Expires January 10, 2005 [Page 15]
Internet-Draft DNA solution framework July 2004
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 (2004). 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 January 10, 2005 [Page 16]