IPv6 Internet Draft T. Hain Document: draft-hain-ipv6-sitelocal-01.txt Cisco Expires: November 2003 May 2003 Local Scope Address Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This memo will discuss the site network manager's requirements for an address range available for use in a local routing scope. Status of this Memo................................................1 Abstract...........................................................1 Introduction.......................................................2 What is a private use address space, and why is it discussed here?.3 Requirements for a local scope address space.......................4 Global routing impact..............................................5 Address range......................................................5 Site-local scope...................................................6 Applications of private address space today........................7 Potential applications of private address space....................8 Summary............................................................9 Security Considerations...........................................10 References........................................................10 Acknowledgments...................................................11 Author's Addresses................................................11 T. Hain Expiration - November 2003 [Page 1] Site-Local Requirements May 2003 Introduction There has been much discussion lately about the role of site-local addresses. This memo will discuss the requirements, architectural role of a limited scope address range for local use, as well as some real world deployment examples. Many network managers have developed a comfort level with private addresses in IPv4, and the first thing they look for in IPv6 is the comparable mechanism. Their absolute requirement for filtering will trump any complaints about broken applications. A common mechanism for accomplishing this is to designate some parts of the address space as limited to the scope of the local network or site. Well- known site-local address prefix provides an opportunity to move beyond the common IPv4 model where all nodes in a network use the same single scope of filtered space, by providing simultaneous support for site/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 with simultaneous use of local and global prefixes there is an opportunity to expand the functionality of the network. Most of the arguments against the use of the currently defined site- local address prefix amount to wanting applications to work even in the presence of this intentional filtering imposed by the network manager. These arguments to remove local scope addresses from the architecture is equivalent to; we should prevent you from doing harm to yourself by insisting that scissors were never invented, that way we don't have to keep telling you not to run with them. Filtering will exist in networks, so there will be domains of applicability, or local scopes. Applications that insist on passing topology information outside the domain of applicability will fail to operate correctly in this environment. 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. A "site" is, by intent, not rigorously defined (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 is located within a single geographic location, such as an office, an office complex, or a campus. As such, one common use instance of a site border will be the boundary between the IGP and EGP. Use of local scope 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 scope addresses available. T. Hain Expiration - November 2003 [Page 2] Site-Local Requirements May 2003 What is a private use address space, and why is it discussed here? For purposes of this discussion, a private use 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 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 scope 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 scope, must originate and stay within that scope, as there is no way to deliver packets from outside the defined scope. 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 | | | ---- B ---- - This alternate view correlates the public side of A & B where they share some aspect of the routing hierarchy. The result still T. Hain Expiration - November 2003 [Page 3] Site-Local Requirements May 2003 requires that any process that intends to provide C with topology information understands the topology to recognize the local and global scope 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 scopes 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 [2]. 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. Requirements for a local scope address space Easy to get - No public registration, payment, customer/provider relationship, or approval required. Network managers have stated, and historical experience has shown, that there is a need for address space that does not require public registration. Stable - Both during ISP changes, and for intermittently connected networks. The address space available for local use must not be subject to change by an external entity, and must not create a real or artificial lock-in to any provider. Private û Well known routing filter provides multiple levels of filtering to ensure a single error does not expose the network to global access. While the local use address space is generally for use within a network, it is often used in private interconnects. This may be to avoid exposing the relationship, or may be to provide a dedicated resource between the networks. In any case, the goal of restricting these addresses to a local scope is to prevent access from the public network. T. Hain Expiration - November 2003 [Page 4] Site-Local Requirements May 2003 There is a strong requirement for an easy-to-get, stable, private address space for use in local networks. In some cases this is simply to avoid the necessary costs associated with running a registration infrastructure, but in others it is to avoid exposing their internal network plans to competitors. Placing all local use address space in a common short prefix allows everyone to filter it which prevents unwanted exposure in the case of single point configuration errors. Global routing impact The strong demand for stable address space also applies to cases where network managers want global access. There is a concern that some network managers will demand that their service providers route the local scope address range globally. Unless they are specifically designed to be PI space, local scope addresses must stay local, and not be leaked into the global routing system. The issue is that without designed aggregation properties, accepting them will lead to a global routing table explosion. For this reason a PI mechanism with reasonable aggregation properties needs to be developed along side the local use address range. One approach is proposed in An IPv6 Provider-Independent Global Unicast Address Format [3]. While this does not aggregate to the same degree as the PA approach, it does provide a stable space that has modest aggregation properties. The local use address space has no aggregation properties, and must not be routed arbitrarily. Address range The address range provided for local use is an architecturally supported, end-user-controlled address space. The address range is set aside as a block that network managers can use without any registration, payment, or approval from external sources. Using the well-known prefix range for local usage provides a hint that a filtering policy has been applied somewhere in this network, though it does not by itself indicate where the boundaries are. Given the presence of a local scope address, 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. 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. T. Hain Expiration - November 2003 [Page 5] Site-Local Requirements May 2003 Local scope 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. Concurrent use of local & global scope 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. The boundaries of a site are intentionally undefined. 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 place to implement a scope boundary. 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 | 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 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 T. Hain Expiration - November 2003 [Page 6] Site-Local Requirements May 2003 issues raised by the limited routing scope 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 bogon 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). 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. 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 T. Hain Expiration - November 2003 [Page 7] Site-Local Requirements May 2003 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. 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. Potential applications of private address space A well-known prefix than 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. 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 (we won't bother with the rest of the network connected devices here). 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 SL 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 SL 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 T. Hain Expiration - November 2003 [Page 8] Site-Local Requirements May 2003 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), 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 SL 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 scope, and all nodes that should be accessed from the outside are accessible by name in the global scope. Applications that are expected to work across the border will have global scope addresses to use. Multi-party apps that use name-string referrals will work across the border, but those that use SL literals will fail by design (note: use of SL == expected to fail across border). Use of filtered global scope addresses makes it impossible for the application to know why it failed to connect. Summary Filtering creates a scoped address space, no matter where the bits come from. The point is that some addresses are only valid within the scope defined by the local network manager. In the simple case, hosts that are allowed external access have a policy that allows them to configure a global prefix along with the local one, while those that are not allowed global access have a policy that only allows configuring the local prefix. Address selection rules will prefer the smallest scope, so internal communications use the local scope and are forced to stay internal by the hard filter at the border. This puts the burden of policy application at the address assignment time (very infrequent) rather than deep parsing every packet to figure out which app sent it. T. Hain Expiration - November 2003 [Page 9] Site-Local Requirements May 2003 If an app chooses to assert a policy that is different from the network manager's filtering rules, it will fail. Having a well defined address space that is known to have filtering applied allows apps to have a hint about potential scope restrictions. That hint may or may not be helpful, but lack of it leaves the app in complete trial & error mode. Some application developers have figured out that having an architected space makes it easier for them to know when connectivity will be broken, but others have not. The arguments by those that have not figured it out are much more about disallowing 'broken connectivity' than they are about figuring out when that happens. Reality says that network managers want to, and will break connectivity when it is in their interest, and no amount of IETF documentation to the contrary will prevent that. We can choose to leave the network managers to figure out their own adhoc mechanisms, or we can put them in a structured space so that apps will have a chance to react appropriately. 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 SL provides. It is a clear address space that service providers can put in bogon filters, and enterprise managers can filter without having to go into detail about which specific devices on a subnet are allowed in or not. It does not comprise a full service security solution, and should not be sold as such. It is simply a way to clearly articulate the difference between public and private endpoints. At the same time the majority of sites that use SL, will simply treat them as a set of prefixes to be passed around in their IGP. Since it will require both parties to misconfigure BGP to get those prefixes leaked between enterprises, they will feel more secure about using them. For this simple reason we need to meet the network manager at his comfort zone and provide a familiar tool. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 draft-hain-ipv6-pi-addr-use-04.txt, Hain, T. 3 draft-hain-ipv6-pi-addr-04.txt, Hain, T., An IPv6 Provider- Independent Global Unicast Address Format T. Hain Expiration - November 2003 [Page 10] May 2003 Acknowledgments Daniel Senie, Tim Hartrick, Michel Py, and Stephen Sprunk provided valuable input in the creation of this document. Author's Addresses Tony Hain Cisco Systems, Inc. 500 108th Ave. NE, Bellevue, Wa. Email: alh-ietf@tndh.net <Lastname> Expiration November 2003 [Page 11]