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]