IPv6 Working Group T. Hain Internet-Draft Cisco Systems, Inc. Expires: January 30, 2004 F. Templin Nokia August 1, 2003 Limited Range Addressing Requirements draft-hain-templin-ipv6-limitedrange-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 January 30, 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 or requirements for their use. There is a strong requirement for addressing that is limited to a bounded domain of applicability, or range. This memo will discuss requirements for limited range addressing. Hain & Templin Expires January 30, 2004 [Page 1] Internet-Draft Limited Range Addressing Requirements August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Limited Range Addressing Requirements . . . . . . . . . . . 3 3.1 Easy to Acquire . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Stable . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Multiple Link Support . . . . . . . . . . . . . . . . . . . 4 3.4 Well-known Prefix . . . . . . . . . . . . . . . . . . . . . 4 3.5 Global Uniqueness . . . . . . . . . . . . . . . . . . . . . 5 3.6 Provider Independence . . . . . . . . . . . . . . . . . . . 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. Limited Range Addressing Scenarios . . . . . . . . . . . . . 7 4.1 Applications of Private Address Space Today . . . . . . . . 7 4.2 Mobile Router with Personal Area Network . . . . . . . . . . 7 4.3 Mobile Ad-hoc Networks that Travel Together . . . . . . . . 8 4.4 Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 8 4.5 Asset Protection in Enterprise Networks . . . . . . . . . . 8 4.6 Home Networks . . . . . . . . . . . . . . . . . . . . . . . 8 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 A. Filtering Considerations . . . . . . . . . . . . . . . . . . 11 B. Routing Considerations . . . . . . . . . . . . . . . . . . . 11 C. Multiple Addressing Considerations . . . . . . . . . . . . . 13 D. Potential Applications of Limited Range Address Space . . . 15 Intellectual Property and Copyright Statements . . . . . . . 17 Hain & Templin Expires January 30, 2004 [Page 2] Internet-Draft Limited Range Addressing Requirements August 2003 1. Introduction The IPv6 addressing architecture [RFC3513] specifies global and local-use unicast address formats. 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 aspects of terms such as "site". There is a strong requirement for addressing that is limited to the range of a single site or a collection of sites that may from time to time be interconnected via VPN, private links, etc. This memo will discuss the requirements of limited range addressing 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 [MULTI6]. range: domain of applicability. identifier range: range within which an address uniquely identifies an entity. Addresses that may possibly identify multiple entities within a limited range are said to be ambiguous. locator range: filtering and/or routing functions set by operational policy that determine a limited range. 3. Limited Range Addressing Requirements There is a strong requirement for an easy-to-get, stable, private address space for use within a limited range. Reasons include: o avoid costs associated with running a registration infrastructure o avoid exposing internal network plans to competitors o stable addressing for intermittently connected/disconnected sites Hain & Templin Expires January 30, 2004 [Page 3] Internet-Draft Limited Range Addressing Requirements August 2003 Many network managers have developed a comfort level with private addresses in IPv4 and expect a comparable mechanism in IPv6. A common mechanism for accomplishing this is to designate some parts of the address space for use within a limited range. The following sections present requirements for limited range addressing in IPv6 3.1 Easy to Acquire A portion of the address space must be made available that requires no public registration, payment, customer/provider relationship, or approval. Network managers have stated, and historical experience has shown, that there is a need for address space that does not require public registration. This address range must be architecturally supported and end-user-controlled. 3.2 Stable Applications require limited range addresses that remain stable during intermittent connectivity, site mergers, change to a new provider, etc. In particular, applications that cache limited range addresses should not be affected by renumbering events [BAKER]. The limited range addressing scheme should also support stable communications within sites that are mobile. In particular, limited rage addresses should remain stable as the site moves to new topological points of attachment or geographical coordinates. 3.3 Multiple Link Support The limited range addressing scheme should support communications 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 addressing has a single link range of operation and will not meet this requirement. 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. Using this well-known prefix provides a hint that a filtering policy has been applied somewhere in the network, though it does not by Hain & Templin Expires January 30, 2004 [Page 4] Internet-Draft Limited Range Addressing Requirements August 2003 itself indicate where the boundaries are. Given the presence of the well-known prefix, an application that chooses to check can infer that there is an explicit filter somewhere in the network. That filter may or may not be between it and the application peer. 3.5 Global Uniqueness /48 prefixes used by sites [RFC3177] 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, therefore a suitable means for random prefix generation must be specified. Sufficient global uniqueness is required to support: o VPNs between enterprises both of which use limited range addresses o dynamically created VPNs in support of temporary virtual organizations o service provider co-location of hosts that reside in the limited range space of multiple customers o formation of virtual organizations (Grids) among enterprises using limited range space o mergers and acquisitions of enterprises such that limited range spaces do not collide Achieving these goals does not require absolute uniqueness, but an extremely low probability of collisions resulting in conflict is required. The limited range addressing scheme must also provide a means for conflict resolution, e.g., certification through a central registry, distributed database, etc. 3.6 Provider Independence Intermittently-connected sites and sites that move between different provider points of attachment require limited range addresses that are provider independent. The limited range addresses must not create a real or artificial lock-in to any provider. In the case of intermittently-connected sites, provider aggregated prefixes may be unavailable for long periods but this must not disrupt local communications within the site. In the case of movement to new providers, frequent site renumbering events may occur but, again, local communications must not be affected. The strong demand for stable address space also applies to cases Hain & Templin Expires January 30, 2004 [Page 5] Internet-Draft Limited Range Addressing Requirements August 2003 where network managers want global access. There is a concern that some network managers will demand that their service providers route limited range addresses globally. The issue is that the limited range addressing scheme has no designed aggregation properties, thus accepting them may lead to global routing table explosion given current routing technologies. For this reason: o a PI mechanism with reasonable aggregation properties should be investigated alongside the limited range addressing scheme. o a feasibility study for routing technologies with better scaling properties should be undertaken. 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. The limited range addressing scheme must provide general applicability in any environment - be it managed or unmanaged. 3.8 Compatible with Site Naming System Addresses derived from the limited range addressing scheme must be compatible with the naming system used within range. Examples include DNS, multicast name resolution, static configuration, etc. In practice, it is expected that limited range addresses will be resolved only within the range of operation of the naming system. 3.9 Compatible with VPN The limited range addressing scheme should support VPN connections between multiple sites, e.g., to form geographically-extended organizations. The limited-use prefixes delegations in effect at each constituent site must remain valid when connected via VPN. 3.10 Multiple Addressing A well-known address prefix provides an opportunity to move beyond the common IPv4 model where all nodes in a network use the same single range of filtered space, by providing simultaneous support for local and global space. To gain the acceptance of network managers, tools they use as security measures must start from exactly the same point they are in IPv4. Then through simultaneous use of local and global prefixes there is an opportunity to expand the functionality of the network. Hain & Templin Expires January 30, 2004 [Page 6] Internet-Draft Limited Range Addressing Requirements August 2003 Concurrent use of limited & global range addresses allows neighboring nodes on a network to have individual policies about global visibility. This moves the policy decision from the edge to the originating device, which allows the application which has enough information decide the appropriate action, rather than the alternative brute force edge approach one-size-fits-all policy. In the case of devices that move between subnets, it also mitigates the need for continuous changes of access controls at the edge. 4. Limited Range Addressing Scenarios Many anticipated IPv6 deployment scenarios require a limited range addressing scheme that meets the requirements outlined in Section 3. Some examples follow: 4.1 Applications of Private Address Space Today 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. Private space is 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. 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.2 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 range 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 range address prefixes active in each PAN should be globally unique to avoid collisions and provide a means for verifying ownership to resolve conflicts. Hain & Templin Expires January 30, 2004 [Page 7] Internet-Draft Limited Range Addressing Requirements August 2003 4.3 Mobile Ad-hoc Networks that Travel Together As with the mobile PAN in Section 4.2, 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 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 range addressing scheme is needed for the continuous support of local communications in such mobile ad-hoc networks. 4.4 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). A limited range addressing scheme should provide a means for denoting both public and private components for 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.5 Asset Protection in Enterprise Networks Enterprise networks that protect private corporate assets (e.g., printers, faxes, robotics, sensors, etc.) require a limited range 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 together remote sites, etc. 4.6 Home Networks Hain & Templin Expires January 30, 2004 [Page 8] Internet-Draft Limited Range Addressing Requirements August 2003 Home networks with intermittent access to a service provider require a limited range addressing scheme that supports local communications even when the service is unavailable. The limited range 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. Summary Filtering creates a limited range address space, 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 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. IANA Considerations This requirements document does not introduce any IANA requirements, though mechanisms that meet these requirements may. 7. 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. Hain & Templin Expires January 30, 2004 [Page 9] Internet-Draft Limited Range Addressing Requirements August 2003 8. Acknowledgements The authors acknowledge the contributions of numerous postings on the ipng mailing list [IPNG] that led to a fuller community understanding of limited range addressing issues leading to these requirements. In particular Brian Carpenter, Daniel Senie, Tim Hartrick, Michel Py, and Stephen Sprunk provided valuable input on early versions of this document. 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. [HAIN] Hain, T., "Application and Use of the IPv6 Provider Independent Global Unicast Address Format", draft-hain-ipv6-pi-addr-use-04 (work in progress), April 2003. [IPNG] "IPng mailing list archive: ftp://playground.sun.com/pub/ ipng/mail-archive". [MULTI6] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", draft-ietf-multi6-multihoming-requirements-07 (work in progress), June 2003. [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 3177, September 2001. Authors' Addresses Tony Hain Cisco Systems, Inc. 500 108th Ave. NE Bellevue, WA EMail: alh-ietf@tndh.net Hain & Templin Expires January 30, 2004 [Page 10] Internet-Draft Limited Range Addressing Requirements August 2003 Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 Phone: +1 650 625 2331 EMail: ftemplin@iprg.nokia.com Appendix A. Filtering Considerations The only difference between a individual network defined non- routable global prefix and a well-known local use prefix is the coordination and verification of filters. Any prefix can be used in a local-only context, but the ability to detect a configuration error which leads to open routing is limited unless it is well- known. The concept of address scoping is nothing more than a formalization of the existing deployments of limited route announcements, or explicit filtering. Defining a well-known address range for local use allows broad deployment of filters at the edge of the public network without additional site specific coordination. A defined prefix for local use uniquely identifies addresses that have a limited administrative domain of applicability. This prefix provides a network manager with a stable address range, as well as establishes a clear filter to limit introduction into the public network. As such, one common use instance of a site border will be the boundary between the IGP and EGP. Use of limited range addresses for connections external to a site is strongly discouraged, because it is difficult to know when applications will encounter the boundary of the domain of reference. When applications are expected to work across the site boundary, care should be taken to ensure all participating nodes have global addresses available. Appendix B. Routing Considerations The term 'site' is not rigorously defined by intent (just as Areas are not rigorously defined in an IGP), but is typically expected to cover a region of topology that belongs to a single organization, and may be located within a single geographic location, such as an office, an office complex, or a campus. An organization should probably start with the assumption that a site boundary is exactly congruent with an IGP area or IGP/EGP boundary, but they may choose to restrict it further, or expand it when it makes sense for their network. The concepts of sites and IGP areas are similar in that they are about limiting how much information is exposed across administrative borders. In any case a policy boundary will exist at any attachment point to the public Internet, so that is a very likely Hain & Templin Expires January 30, 2004 [Page 11] Internet-Draft Limited Range Addressing Requirements August 2003 place to implement at least part of the site boundary. A limited range address space is any set of addresses that can not be reached from a significant portion of the public Internet. The reasons for lack of ability to reach these addresses are based on policy local to the network(s) using them vs. policy at an arbitrary remote network. The implementation mechanism used to accomplish that policy could be simply restricting the range of routing announcements, or explicit access controls in a device along the path. In either of those cases, the result is a local range with a well defined boundary controlled by the network manager using the addresses. A consequence of the implemented policy is that any packets destined for locations within the limited range, must originate and stay within that range, as there is no way to deliver packets from outside the defined range. As a simple example, take the case below where A & B have a choice of addresses that they can use to reach each other, but C can only reach the Public addresses of either. ---- A ---- | | L P o u c b a l ---- C l i | c | | ---- B ---- One of the requirements of this network environment is that any process that intends to provide C with topology information for reaching A or B, needs to understand the topology so that it can provide C with correct and useful information. An alternate way to draw the example network is: ---- A ---- - | | | L G P o l u c o b a b - R - l ---- C l a i | l c | | | Hain & Templin Expires January 30, 2004 [Page 12] Internet-Draft Limited Range Addressing Requirements August 2003 ---- B ---- - This alternate view correlates the public side of A & B where they share some aspect of the routing hierarchy. The result still requires that any process that intends to provide C with topology information understands the topology to recognize the local and global range differences to provide useful information. To simplify subsequent discussion, the labels will be changed using that same view. The local prefix will be shown as P(l), while the global public prefix will be shown as P(g). ---- A ---- - | | | | | P | | u | | b P(l) P(g) - R - l ---- C | | i | | c | | | ---- B ---- - This sequence of network drawings has been presented to show that limited ranges exist in many IPv4 network deployments today. Additional discussion of the policies that drive these deployments can be found in a discussion on deployment and use of a proposed Provider Independent (PI) address space [HAIN]. Any specific PI mechanism is not the issue here, so much as the policies that drive deployment of an address space that is not controlled by the public network service provider. Further discussion of the requirements for site controlled space follow in the next section. Applications that insist on passing topology information outside the domain of applicability will fail to operate correctly in this environment. Appendix C. Multiple Addressing Considerations While the earlier examples showed a physical separation between the local and global topology, the scenario is identical between multiple interfaces with a single address, and individual interfaces with multiple addresses. This characteristic results in another view of the example network: A ---- - | | | P Hain & Templin Expires January 30, 2004 [Page 13] Internet-Draft Limited Range Addressing Requirements August 2003 | u | b P(l)&P(g) - R - l ---- C | i | c | | B ---- - This configuration is not typical in IPv4 networks, because implementing multiple addresses per interface is operationally challenging, making it relatively difficult. In this view, the router R either informs the public network of only the global prefix A & B are using, or if the local use prefix is a subset of the global prefix, R explicitly controls access to the local use portion. Either way, C can only reach A(g) & B(g), while A & B can reach either P(g) or P(l). In any case, the issues raised by the limited routing range of P(l) are the same as they were in the multiple interface case we started with, and completely independent of the allocation source of P(l). Adding a little more detail to the drawing, shows the distinction between the customer premise equipment (CPE) router, and the provider edge (PE) router: A ---- - | | | P | u | b P(l)&P(g) - R(cpe) - R(pe) - l ---- C | i | c | | B ---- - Again, the issues don't change, this simply allows discussion about how P(g) & P(l) are handled at each of those points. Placing all the local use prefixes under a common shorter prefix allows the service provider to have a common filter at all R(pe) borders. This additional level of filtering provides a backup in the case that R(cpe) is misconfigured in a way that would allow access to P(l) from the public network. Accomplishing the same degree of isolation when P(l) is a subset of P(g), would require a unique configuration for every R(pe), and would explicitly expose P(l) to global access in the case of a configuration error in R(cpe). Hain & Templin Expires January 30, 2004 [Page 14] Internet-Draft Limited Range Addressing Requirements August 2003 Appendix D. Potential Applications of Limited Range Address Space A well-known prefix that can be embedded in appliances so they are easy to sell to the average consumer and a simple filter limits access to the home network. Such a prefix would also simplify the case of file system mounts between nodes on an intermittently connected network. If the mount dropped every time a connect event caused addresses to change, the consumer would quickly find another product. For example, company X has 125,000 employees globally, with regular reorganizations causing constant office shuffles between regions. Each employee has a laptop, which will have global access, and a network connected printer which will not have global access. There are 100 touch-points to the Internet, with the 3 primary ones running multiple OC-48 access loops. The 'explicit filter lists at the border' model requires keeping 100 tables in sync in the face of constant change, and parsing a 125,000 entry list at OC-48 rates for every packet at 3 of the borders. The 'well-known limited range address filter at the border' model requires the organization to tell their printer manufacturer to preconfigure all the devices they buy to only accept and auto-configure limited range prefixes from the RA (likely a widely demanded item), and put in a 2 entry list that remains static at every border. In addition, it is reasonable and expected that the peer across the border will maintain a matching version of the filter list. The compromise model of 'using 2 public prefixes per segment' allows for a 2 entry static list at every border, which may or may not be considered reasonable to match by the border peer. It does not provide the printer manufacturer a preconfiguration option that matches other customers, and even if it was done, as soon as Company X changes providers, they have to manually touch every printer for the new configuration. To make the name service simple in these 3 cases, Company X chooses to run back-to-back normal dns servers. The primary set facing internally to accommodate dynamic updates, with a slave set facing externally. A periodic process will replicate the information from the source-of-truth internal facing servers to the external ones, but the security team requires it to scrub out all records for internal-only nodes. For model 1, the scrubbing process would have to contact the border filter list (after deciding which was the current source of truth), Hain & Templin Expires January 30, 2004 [Page 15] Internet-Draft Limited Range Addressing Requirements August 2003 then parse through it for all 250,000 entries to decide which are replicated. For model 2, the scrubbing process simply has to drop records with the limited range address prefix and replicate all others. For model 3, the scrubbing process has to look for the set of prefixes that identify private-use, and replicate all others. Once any one of these processes completes, all nodes are accessible by name in the internal range, and all nodes that should be accessed from the outside are accessible by name in the global range. Applications that are expected to work across the border will have global addresses to use. Multi-party apps that use name-string referrals will work across the border, but those that use limited range literals will fail by design (note: use of limited range addresses == expected to fail across border). Use of filtered global addresses makes it impossible for the application to know why it failed to connect. Hain & Templin Expires January 30, 2004 [Page 16] Internet-Draft Limited Range Addressing Requirements 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 January 30, 2004 [Page 17] Internet-Draft Limited Range Addressing Requirements 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 January 30, 2004 [Page 18]