IPv6 Working Group T. Hain Internet-Draft Cisco Systems, Inc. Expires: February 26, 2004 F. Templin Nokia August 28, 2003 Goals for an Addressing Scheme to Support Local Communications within Sites draft-hain-templin-ipv6-limitedrange-02.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 February 26, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IPv6 addressing architecture specifies global and local-use unicast addressing schemes, but provides no operational guidelines for their use. There is a perceived need for an addressing scheme that supports local communications within sites. Of special interest are "active sites", e.g., sites that are intermittently-connected or disconnected from the global Internet, sites that frequently change provider points of attachment, sites that temporarily or permanently merge with other sites, multi-homed sites, etc. This memo will discuss goals for an addressing scheme to support local communications within sites. Hain & Templin Expires February 26, 2004 [Page 1] Internet-Draft Local Communication Addressing Goals August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Easy to Acquire . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Stable . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Multiple Link Support . . . . . . . . . . . . . . . . . . . 4 3.4 Well-known Prefix . . . . . . . . . . . . . . . . . . . . . 4 3.5 Globally Unique . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Usable in the Absence of a Provider . . . . . . . . . . . . 5 3.7 Applicable in Managed/Unmanaged Environments . . . . . . . . 6 3.8 Compatible with Site Naming System . . . . . . . . . . . . . 6 3.9 Compatible with VPN . . . . . . . . . . . . . . . . . . . . 6 3.10 Multiple Addressing . . . . . . . . . . . . . . . . . . . . 6 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Border Filtering . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Maintaining Confidentiality of the Address Space . . . . . . 7 4.3 Test Networks . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 Address Caching . . . . . . . . . . . . . . . . . . . . . . 7 4.5 Mobile Router with Personal Area Network . . . . . . . . . . 7 4.6 Mobile Ad-hoc Networks (MANETs) . . . . . . . . . . . . . . 8 4.7 Asset Protection in Enterprise Networks . . . . . . . . . . 9 4.8 Home Networks . . . . . . . . . . . . . . . . . . . . . . . 9 5. Perceived Advantages of Limited Range Addressing Solutions . 10 6. Appeal for Alternative Proposals . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 Normative References . . . . . . . . . . . . . . . . . . . . 11 Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 13 Hain & Templin Expires February 26, 2004 [Page 2] Internet-Draft Local Communication Addressing Goals August 2003 1. Introduction The IPv6 addressing architecture [RFC3513] specifies global and local-use unicast addresses. Global addresses are understood to have unlimited range 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 intended for use only within the range of a single link/site, but their specification does not address operational considerations and does not account for the esoteric nature of terms such as "site". There is a perceived need for an addressing scheme that supports local communications within sites. Of special interest are "active sites", e.g., sites that are intermittently-connected or disconnected from the global Internet, sites that frequently change provider points of attachment, sites that temporarily or permanently merge with other sites, multi-homed sites, etc. This memo will discuss goals for an addressing scheme to support local communications within sites in the context of real world deployment scenarios. 2. Terminology site: an entity autonomously operating a network using IP and, in particular, determining the addressing plan and routing policy for that network. This is the same definition as [RFC3582]. active site: a site that may be intermittently-connected or disconnected from the global Internet, may frequently change provider points of attachment, may have multiple concurrent provider points of attachment, may temporarily or permanently merge with other sites, etc. range: domain of applicability. limited range: a range bounded by, e.g., routing policies, filters, etc. PI: Provider Independent PA: Provider Aggregated Hain & Templin Expires February 26, 2004 [Page 3] Internet-Draft Local Communication Addressing Goals August 2003 VPN: Virtual Private Network 3. Goals There is a perceived need for an addressing scheme that supports local communications within sites. One obvious solution alternative is an easy-to-get, stable, PI space for use within a limited range as this is consistent with current practices familiar to IPv4 network managers. The following sections present goals that should be met by any solution proposal. Proposals should be brought forward in a timely fashion so that their merits can be evaluated with respect to these goals. 3.1 Easy to Acquire Some portion of the address space should be made available that requires no public registration, payment, customer/provider relationship, or approval. These addresses should be architecturally supported and end-user-controlled. 3.2 Stable Applications that enable local communications should use addresses that support session stability (i.e., connection survivability) during intermittent connectivity, site mergers, change to a new provider, etc. In particular, session stability should not be affected by renumbering events [BAKER]. 3.3 Multiple Link Support Addresses for local communications within sites should support operation over multiple links, e.g., via L3 routing, L2 bridging or some combination thereof. As such, subnetting consistent with the recommendations in ([RFC3177], section 3) should be supported. 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 addresses have a single link range of operation and will not meet this goal. 3.4 Well-known Prefix Placing portions of the address space in a common short prefix allows everyone to filter it which prevents unwanted exposure in the case of single point configuration errors. In this solution alternative, the Hain & Templin Expires February 26, 2004 [Page 4] Internet-Draft Local Communication Addressing Goals August 2003 common prefix should not end up in the global routing system, even accidentally. Addressing scheme proposals that use a well-known prefix provide applications that choose to check with a hint that a filtering policy has been applied somewhere in the network, though it does not by itself indicate where the boundaries are. Proposals should state clearly how filtering, privacy, etc will be supported. 3.5 Globally Unique Addresses used by sites should be globally unique such that site mergers will not result in collisions. Global uniqueness is based on the statistical properties of address allocations, therefore proposals should specify a suitable means for random prefix generation. Addressing scheme proposals should also provide a suitable means for conflict resolution, e.g., certification through a central registry, distributed database, etc. Sufficient global uniqueness is needed to support, e.g.: o VPNs between enterprises o dynamically created VPNs in support of temporary virtual organizations o service provider co-location of hosts that reside in the address space of multiple customers o formation of virtual organizations (Grids) among enterprises o mergers and acquisitions of enterprises such that address spaces do not collide Achieving these goals does not require absolute uniqueness, but an extremely low probability of collisions resulting in conflict is desired. Proposals should therefore provide statistical analysis of the uniqueness properties of the addressing scheme. 3.6 Usable in the Absence of a Provider Active sites need addresses that can be used when there is no active link to a provider. In the case of intermittently-connected sites, provider access may be unavailable for long periods but this should not disrupt local communications within the site. In the case of sites moving to new provider points of attachment, frequent renumbering events may occur but, again, local communications should not be disrupted. Hain & Templin Expires February 26, 2004 [Page 5] Internet-Draft Local Communication Addressing Goals August 2003 PI addresses provide one solution alternative genre that also appliies to cases where network managers want global access. The issue is that PI addresses with no designed aggregation properties may lead to global routing table explosion (if advertised outside the site) given current routing technologies. For this reason, PI addressing scheme proposals should either provide reasonable aggregation properties or a detailed analysis of their interactions with global routing technologies. PA and other non-PI proposals should explain how the proposed addressing schemes will support local communications in the presence of intermittent and/or disconnected provider access. 3.7 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 unmanaged operation. Addressing scheme proposals should provide general applicability in any environment - be it managed or unmanaged. 3.8 Compatible with Site Naming System Addresses for local communications within sites should be compatible with the site's naming system. Examples include DNS, multicast name resolution, static configuration, etc. In practice, it is expected that addresses will be resolved only within the range of operation of the naming system. 3.9 Compatible with VPN Proposed addressing schemes should support VPN connections between multiple sites, e.g., to form geographically-extended organizations. Prefix delegations in effect at each constituent site should remain valid when connected via VPN. 3.10 Multiple Addressing Proposals that support concurrent use of limited & global range addresses allow nodes in the site to implement individual security policies about global visibility. This moves the security policy decision from the edge to the originating device, which allows the application which has enough information decide the appropriate action. In the case of devices that move between subnets, it also mitigates the need for continuous changes of access controls at the edge. Proposals that do not support multiple addressing should state clearly how security policies can be enforced. In particular, they Hain & Templin Expires February 26, 2004 [Page 6] Internet-Draft Local Communication Addressing Goals August 2003 should clearly state how the originating devices can implement security policies without the need for edge intervention when only a single address is available. 4. Scenarios Many anticipated IPv6 deployment scenarios require an addressing scheme that meets the goals outlined in Section 3. Such an addressing scheme should have general application and should minimally satisfy the example scenarios outlined in the following subsections: 4.1 Border Filtering Network managers limit specific applications to internal use, so they configure them to only work with a filtered address range. This simplifies the border filter to an address prefix, rather than needing to employ deep packet inspection to track a potentially dynamic range of ports. 4.2 Maintaining Confidentiality of the Address Space Private space may be used to avoid exposing to competitors what internal networks they are deploying and which office is coordinating that effort. Network managers also don't have to expose business plans to a registrar for evaluation for networks that are not attached to the global Internet. Some have stated that if they are required to register for public space for every internal use network, they are more likely to pick random numbers than tip off the competition. 4.3 Test Networks Another significant use of private address space is test networks. Frequently these are large, elaborate networks with a mix of public and private address space. Use of random unallocated space runs the risk of collision with legitimate addresses on remote networks. 4.4 Address Caching Applications that cache IP addresses in ACLs or configurations are susceptible to operational problems due to site renumbering. Examples include license servers that use IP addresses, firewalls within the site, web site access mechanisms to allow access to only certain subnets, etc. Stable addressing for local communications within sites is needed to satisfy such scenarios. 4.5 Mobile Router with Personal Area Network Hain & Templin Expires February 26, 2004 [Page 7] Internet-Draft Local Communication Addressing Goals August 2003 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 should be supported 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 address prefixes used in each PAN should be globally unique to avoid collisions and provide a means for verifying ownership to resolve conflicts. 4.6 Mobile Ad-hoc Networks (MANETs) Numerous aspects of MANETs provide challenges for addressing schemes that support local communications. The following scenarios provide some specific examples: 4.6.1 Nomadic Nodes that form Temporal MANETs Nomadic nodes with no pre-defined group affiliation are in actuality singleton sites that may from time to time merge with other such "sites" as they move about to form MANETs. Such MANETs may exist only temporarily in space/time, but should allow local communications between nodes even during rapidly-changing MANET dynamics. Therefore each such nomadic node should have a pre-configured address that can be injected into the intra-MANET routing protocol during the duration of its visit to any such temporal MANET. 4.6.2 Groups of Nodes that Travel Together As with the mobile PAN in Section 4.2, mobile ad-hoc networks of nodes that travel together as a group may have long periods of intermittent/disconnected access to the global Internet. Such applications as 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. An addressing scheme is needed for the continuous support of local communications in such mobile ad-hoc networks. 4.6.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 speedometer reading). The addressing scheme should provide a means for denoting both public and private components, e.g., for Hain & Templin Expires February 26, 2004 [Page 8] Internet-Draft Local Communication Addressing Goals August 2003 filtering at site borders. Research ships at sea intermittently connect via INMARSAT, or when in port, the shipboard network is connected to shore via Ethernet. Of utmost importance is that the systems on board the ship all function, providing data collection and analysis without interruption. Static addressing is used on most intra-ship network components and servers. It's quite expensive to operate a research ship, so eliminating points of failure is important. Scientists on board collaborate with colleagues back home by sharing of data and email. Currently private address space is employed for several reasons: 1) it provides the ability to allocate significant address space to each ship without needing to worry about how many computers will be on a given cruise. 2) it provides separate address space for each ship. 3) it simplifies filtering to ensure shipboard traffic is not permitted to transmit out or bring up expensive satellite links. 4.7 Asset Protection in Enterprise Networks Enterprise networks that protect private corporate assets (e.g., printers, faxes, robotics, sensors, etc.) require an addressing scheme that remains stable even when VPN connections from outside sites occur. Such VPN connections may arise from home users, corporate mergers and acquisitions, bridging remote sites together, etc. Prefixes used for protecting private assets should not end up in the global routing system, even by accident. 4.8 Home Networks Home networks with intermittent access to a service provider require an addressing scheme that supports local communications even when the service is unavailable. The 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. An example chain of events that may arise in Home Networks and other scenarios is: o site A sets up a local network with no ISP connection; the network should "just work" out of the box o site A later connects to an ISP for external connectivity, but uses filtering to avoid exposing internal addressing to the outside o in the meantime, site B performs corresponding actions Hain & Templin Expires February 26, 2004 [Page 9] Internet-Draft Local Communication Addressing Goals August 2003 o sometime later, sites A and B connect, e.g., via VPN, shared link, etc. The sites can send local traffic to each other as well as traffic out either of the sites' ISPs o sometime later, site A disconnects from its ISP and site B's ISP is used o sometime later, site A disconnects from site B o sometime later, site A registers with a new ISP Such chains of events should not disrupt local communications within sites A and B. 5. Perceived Advantages of Limited Range Addressing Solutions Limited range addressing solutions allow filtering, and filtering creates addressing boundaries no matter where the bits come from. The point is that some addresses are only valid within the range defined by the local network manager. In the simple case, hosts that are allowed external access have a policy that allows them to configure both global and limited range prefixes, while those that are not allowed global access have a policy that only allows limited range. Address selection policy tables might need modifications to enable the selection of limited range address space over global addresses. Given such modifications, address selection rules will prefer the smallest range so internal communications are forced to stay internal by the hard filter at the border. If an application chooses to assert a policy that is different from the network manager's filtering rules, it will fail. Having a well defined limited range address space that is known to have filtering applied allows applications to have a hint about potential range restrictions. We can choose to leave the network managers to figure out their own adhoc mechanisms, or we can put them in a structured limited range address space so that applications will have a chance to react appropriately. 6. Appeal for Alternative Proposals A limited range addressing scheme would seem a logical choice to satisfy the requirements and real-life scenarios outlined in this document, but the authors recognize that it may not be the ONLY choice. Alternative solution proposals should be made available in a timely fashion through full disclosure to the public domain so that their merits can be evaluated. Such proposals should state clearly Hain & Templin Expires February 26, 2004 [Page 10] Internet-Draft Local Communication Addressing Goals August 2003 how they address the goals outlined in this document and should include mathematical formulas analyzing the likelyhood of duplicate address assignment, analysis of effects on address selection, filtering/privacy considerations, etc. 7. IANA Considerations This document does not introduce any IANA requirements. 8. Security Considerations The concept of route filtering is frequently used as a tool to aid in network security, so having a well-known range to filter enhances the deployment of that tool. Access control is one aspect of what limited range addressing provides. It is a clear address space that service providers can put in filters, and enterprise managers can filter without having to go into detail about which specific devices on a subnet are allowed. It does not comprise a full service security solution, and should not be represented as such. 9. Acknowledgements The authors acknowledge the contributions of numerous posts on the ipng mailing list [IPNG] that led to a better understanding of the issues. The following individuals are noted for their contributions: Brian Carpenter, Tim Hartrick, Eliot Lear, Chirayu Patel, Michel Py, Pekka Savola, Daniel Senie, Stephen Sprunk, Michael Thomas, and Andrew White. 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. [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. Hain & Templin Expires February 26, 2004 [Page 11] Internet-Draft Local Communication Addressing Goals August 2003 [RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003. Authors' Addresses Tony Hain Cisco Systems, Inc. 500 108th Ave. NE Bellevue, WA EMail: alh-ietf@tndh.net Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 Phone: +1 650 625 2331 EMail: ftemplin@iprg.nokia.com Appendix A. Change Log Changes since draft-01: o Changed document ID; title o Changed "Requirements" "to "Goals" in several places o Incorporated comments from Chirayu Patel, Pekka Savola o Expanded "scenarios" section with several new subsections, including nomadic nodes in MANETs. o Removed appendices o Updated reference for RFC3582. Changes since draft-00: o Changed title, and removed linkage of requirements and the particular solution alternative referred to as "limited range addressing" in the previous draft. Thanks to Eliot Lear and Michael Thomas for suggesting the change. o Added real life example scenario from Andrew White Hain & Templin Expires February 26, 2004 [Page 12] Internet-Draft Local Communication Addressing Goals August 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 Hain & Templin Expires February 26, 2004 [Page 13] Internet-Draft Local Communication Addressing Goals August 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. Hain & Templin Expires February 26, 2004 [Page 14]