Network Working Group F. Templin Internet-Draft Nokia Expires: December 17, 2003 June 18, 2003 Requirements for Limited-Scope Unicast Addressing in IPv6 draft-templin-lsareqts-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 December 17, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IPv6 addressing architecture specifies global and local-use unicast addressing schemes. Recent consensus call in the IPng working group has deprecated site-local addressing due in part to its inherent ambiguity. This document outlines requirements for use in evaluating candidate proposals for a replacement scheme. Templin Expires December 17, 2003 [Page 1] Internet-Draft Limited-Scope Addressing Requirements June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Limited-Scope Addressing Requirements . . . . . . . . . . . . . 3 4. Scenarios Requiring Limited-Scope Addressing . . . . . . . . . . 5 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 Informative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . 8 Templin Expires December 17, 2003 [Page 2] Internet-Draft Limited-Scope Addressing Requirements June 2003 1. Introduction The IPv6 addressing architecture [RFC3513] specifies global and local-use unicast address formats. Global addresses are understood to have unlimited scope and may be used as the source and destination addresses in packets that originate from any point on the connected global IPv6 Internet. Local-use addresses are assumed valid only within the scope of a single link/site, where the term site is understood to imply an administrative (rather than physical) boundary. Recent consensus call in the IPng working group has deprecated site-local addressing due in part to its inherent ambiguity. Many have suggested that an unambiguous replacement addressing scheme of limited-scope (i.e., not necessarily local-scope) is needed. This document outlines requirements for use in evaluating candidate proposals for a limited-scope addressing scheme to serve as a replacement for site-local. 2. Terminology The term "limited-scope" was introduced by [BC]. 3. Limited-Scope Addressing Requirements Link-local addresses in IPv6: "are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present" ([RFC3513], section 2.5.6). By definition, link-local addressing has a single link scope of operation and is not intended for general purpose use. Therefore, sites comprising multiple links also need an addressing scheme that supports general-purpose operation within a limited scope. The following subsections present characteristics that must be supported by such a limited-scope addressing scheme: 3.1 Multiple link Support The limited-scope addressing scheme should support end-to-end operation of general-purpose applications over multiple links within an administratively-defined scope. Multiple link operation within the site may entail routing, bridging or some combination thereof. As such, the limited-scope addressing scheme should allow subnetting. For consistency with global-use address assignment policies, it is recommended that the limited-scope addressing scheme observe the recommendations in ([RFC3177], section 3), i.e., prefer /48 prefix delegation with 16 bits remaining for limited-scope subnetting. Templin Expires December 17, 2003 [Page 3] Internet-Draft Limited-Scope Addressing Requirements June 2003 3.2 Unambiguous Limited-scope addresses must have a well-known leading token in the first N bits of the prefix that can be configured in filters at site borders. Moreover, prefixes must be globally-unique such that site mergers will not result in collisions. Global uniqueness is based on the statistical properties of the prefix assignment scheme, therefore a suitable random number generator must be specified. The length N of the well-known leading token should be as small as possible to allow maximal additional prefix bits for random number assignment. Since prefix duplication between sites may occur (e.g., due to configuration errors, etc.), the limited-scope addressing scheme should provide a means for conflict resolution when duplicate assignments are detected. Examples include a central registry, distributed database, etc. 3.3 Stable The limited-scope addressing scheme should provide applications with addresses that remain stable even during disruptive events such as site mergers, partitions, change to a new provider, etc. In particular, applications that cache limited-scope addresses (e.g., in protocol control blocks, etc.) should not be impacted by site-wide renumbering events. (See: [BAKER] for a discussion on the inherent complexity of site-wide renumbering and its impact on applications.) 3.4 Portable The limited-scope addressing scheme should support continuous operation of applications within sites that are mobile (i.e., in the geographical and/or topological sense). As the site moves to a different topological point of attachment or a different geographical location, any limited-scope address prefixes in use should remain stable. 3.5 Provider Independent Intermittently-connected sites and sites that move between different provider points of attachment require limited-scope addresses that are independent of provider assignments. In the case of intermittently-connected sites, provider aggregated prefixes may be unavailable for long periods but this must not disrupt limited scope communications within the site. In the case of movement to new providers, frequent site renumbering events may occur but, again, limited-scope communications must continue to make progress. Templin Expires December 17, 2003 [Page 4] Internet-Draft Limited-Scope Addressing Requirements June 2003 3.6 Applicable in Managed/Unmanaged Environments Some sites (e.g., large enterprises) may have network management teams responsible for address planning while others (e.g., home networks and personal area networks) may require zero configuration operation with no network management support. The limited-scope addressing scheme must provide general applicability in any environment - be it managed or unmanaged. 3.7 Compatible with Site Naming System Addresses derived from the limited-scope addressing scheme must be compatible with the naming system used within scope. Examples include DNS, multicast name resolution, static configuration, etc. In practice, it is expected that limited-scope addresses will be resolved only within the scope of operation of the naming system. 3.8 Compatible with VPN The limited-scope addressing scheme should support VPN connections between multiple sites to form a geographically-extended organization. The limited-use prefixes delegations in effect at each constituent site must remain valid when connected via VPN. 4. Scenarios Requiring Limited-Scope Addressing Many anticipated IPv6 deployment scenarios require a limited-scope addressing scheme that meets the requirements outlined in Section 3. Some examples follow: 4.1 Mobile Router with Personal Area Network Multiaccess terminals that serve as routers between the operator and a personal area network (PAN) of the user's locally-connected devices are seen as a near-term deployment scenario. Access to the operator may be intermittent, yet local communications within the PAN must be supported through limited-scope addressing even when no connection to the global Internet is available. As mobile users travel about, multiple PANs may come together in a common space such that two or more PANs merge. As such, the limited-scope address prefixes active in each PAN should be globally unique to avoid collisions and provide a means for verifying ownership to resolve conflicts. 4.2 Mobile Ad-hoc Networks that Travel Together As with the mobile PAN Section 4.1, mobile ad-hoc networks that travel together as a group may have long periods of intermittent/ disconnected access to the global Internet. Such applications as Templin Expires December 17, 2003 [Page 5] Internet-Draft Limited-Scope Addressing Requirements June 2003 disaster relief, coordinated missions, and expeditionary forces may comprise numerous ad-hoc networks that may merge, partition, or lose global connectivity from time to time. A limited-scope addressing scheme is needed for the continuous support of local communications in such mobile ad-hoc networks. 4.3 Vehicular Networks Vehicular networks may connect elements in an automobile to provide sensory and situational awareness data to the driver. Periodic contact with roadside Internet access points, other vehicles, etc. may entail sharing public information (e.g., road conditions encountered) while protecting private information (e.g., the vehicle's current speedometer reading). A limited-scope addressing scheme should provide a means for denoting both public and private components for filtering at site borders. 4.4 Asset Protection in Enterprise Networks Enterprise networks that protect private corporate assets (e.g., printers, faxes, robotics, sensors, etc.) require a limited-scope addressing scheme that supports multiple-link operation. The addressing scheme must remain stable even when VPN connections from outside sites occur. Such VPN connections may arise from home users, corporate mergers and acquisitions, bridging together remote sites, etc. 4.5 Home Networks Home networks with intermittent access to a service provider require a limited-scope addressing scheme that supports local communications event when the server is unavailable. The limited-scope addressing scheme should also protect private assets from exposure to the global Internet and should allow continuous operation when VPN connections to the office or other extended sites are used. 5. Conclusions A limited-scope addressing scheme is needed to replace the now-deprecated site-local scheme from [RFC3513]. Candidate schemes must be evaluated against the requirements outlined in Section 3 to determine their applicability. The IETF should move quickly to identify the scheme that best satisfies the requirements and take action to adopt the scheme through the standardization process. 6. IANA Considerations This document introduces no IANA Considerations. Templin Expires December 17, 2003 [Page 6] Internet-Draft Limited-Scope Addressing Requirements June 2003 7. Security Considerations This document introduces no Security Considerations. 8. Acknowledgements The author acknowledges the contributions of numerous authors through recent postings on the ipng mailing list [IPNG] that led to a fuller community understanding of the site-local addressing issues and the need for a replacement. Normative References [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. Informative References [BAKER] Baker, F., "Procedures for Renumbering an IPv6 Network without a Flag Day", draft-baker-ipv6-renumber-procedure-00 (work in progress), April 2003. [BC] "Message from Brian Carpenter to the ipng mailing list (message ID 3ECE1421.1B157C4D@hursley.ibm.com)", May 2003. [IPNG] "IPng mailing list archive: ftp://playground.sun.com/pub/ ipng/mail-archive". [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 3177, September 2001. Author's Address Fred Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 650 625 2331 EMail: ftemplin@iprg.nokia.com Templin Expires December 17, 2003 [Page 7] Internet-Draft Limited-Scope Addressing Requirements June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Templin Expires December 17, 2003 [Page 8] Internet-Draft Limited-Scope Addressing Requirements June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Templin Expires December 17, 2003 [Page 9]