Internet-Draft M. Wasserman Document: draft-wasserman-ipv6-sl-impact-00.txt Wind River Expires: June 2003 December 2002 The Impact of Site-Local Addressing in IPv6 1 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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. 2 Abstract Internet Protocol version 6 (IPv6) introduces a scoped unicast addressing architecture, including the concept of site-local addressing. Although site-local addresses were originally allocated for use in networks that were not yet connected to the Internet, there has been work underway for several years to expand the use of site-local addresses to globally connected IPv6 networks and nodes. The use of site-local addresses on globally connected networks and nodes raises complex technical issues for many parts of the TCP/IP protocol suite. Many of these issues are caused by the fact that IPv6 sites are private address spaces, and site-local addresses are unreachable or ambiguous outside of site boundaries. Site-local addresses also add significant complexity at the IP layer and at other layers of the protocol stack. In addition, many of the benefits of site-local addressing can be achieved using mechanisms that are significantly less complex and that cause fewer problems than IPv6 site-local addressing. This document makes a recommendation to limit the use of site-local addresses to isolated, single-site networks, and offers suggestions for less complicated mechanisms to achieve many of the benefits currently attributed to IPv6 site-local addressing. Wasserman Expires June 2003 1 Impact of Site-Local Addressing in IPv6 December 2002 3 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 4 Table of Contents 1 Status of this Memo.......................................1 2 Abstract..................................................1 3 Copyright Notice..........................................2 4 Table of Contents.........................................2 5 Terminology...............................................3 6 Introduction..............................................3 7 Technical Issues With Site-Local Addressing...............4 7.1 The Fundamental Issue.....................................4 7.1.1 Problems for Upper-Layer Protocols........................4 7.1.1.1 Similarities to NAT.......................................4 7.1.2 Problems for Site-Border Nodes............................5 7.1.2.1 Problems for All Site-Border Nodes........................6 7.1.2.2 Problems for Site-Border Routers..........................6 7.2 Routing Protocol Issues...................................7 7.3 DNS Issues................................................8 7.3.1 DNS Server Issues.........................................8 7.3.2 DNS Resolver & Address Selection Issues...................9 7.3.2.1 DNS Resolver Issues for All IPv6 Nodes....................9 7.3.2.2 DNS Resolver Issues for Site-Border Nodes................10 7.4 Transport Protocol Issues................................10 7.5 Network Management Issues................................11 7.6 Application Protocol Issues..............................12 7.7 Security Protocol Issues.................................13 8 Benefits of IPv6 Site-Local Addressing...................14 8.1 Benefits for Isolated Sites..............................14 8.2 Benefits for Globally Connected Sites....................14 8.2.1 Benefits for Newly-Connected Sites.......................14 8.2.2 Benefits for Intermittently Connected Sites..............15 8.2.3 Benefits for Renumbered Sites............................15 8.3 Access Control Benefits..................................16 8.4 Potential Benefits for Local Applications and Services...17 9 Alternatives to Site-Local Addressing....................18 10 Status of Site-Local Implementation and Deployment.......19 11 Recommendations..........................................20 12 Security Considerations..................................21 13 References...............................................22 14 Acknowledgements.........................................23 15 Author's Contact Information.............................23 Wasserman Expires February 2003 2 Impact of Site-Local Addressing in IPv6 December 2002 5 Terminology IPv6 Internet Protocol version 6 [RFC2460]. Site-Border Node An IPv6 node with interfaces in more than one site. SBR Site Border Router. An Site-Border Node that forwards packets. Multi-sited Host A Site-Border Node that does not forward packets. 6 Introduction The IPv6 scoped addressing architecture [SCOPARCH] introduces support for scoped unicast addressing, in which a typical IPv6 interface may have multiple unicast addresses for communication within different scopes: link-local, site-local and/or global. This document assumes that the reader has read the latest IPv6 Addressing Architecture and IPv6 Scoped Address Architecture Internet-Drafts [ADDRARCH, SCOPARCH] and is familiar with the concepts and terminology related to IPv6 scoped unicast addressing. The use of site-local addresses on globally connected networks and nodes raises many complex issues within IPv6, and for other parts of the Internet protocol suite, particularly routing protocols, the domain name system (DNS), transport protocols, network management systems and applications. This document describes many of those issues and attempts to analyze the root causes of the problems. This document also discusses the complexities that site-local addressing causes for IPv6 implementations, application programming interfaces (APIs) and user interfaces. Some complexities in these areas are caused by the use of any scoped unicast addressing, such as IPv6 link-local addressing, but there are additional issues caused by site-local addressing which are discussed in this document. Although several benefits have been attributed to site-local addressing, the problems and complexities caused by the use of site-local addressing far outweigh the benefits. In addition, many of those benefits can be achieved using mechanisms that cause fewer complexities and problems than site-local addressing. This document makes a recommendation that site-local addressing be limited to use on isolated networks and suggests less complicated mechanisms to achieve most of the benefits of site-local addressing. Wasserman Expires February 2003 3 Impact of Site-Local Addressing in IPv6 December 2002 7 Technical Issues With Site-Local Addressing There are many complex technical issues associated with the use of IPv6 site-local addresses on globally attached networks and nodes. This section discusses several of these issues, and points out known solutions or workarounds for these issues. 7.1 The Fundamental Issue When IPv6 site-local addresses are used on globally connected networks, they create private address spaces. Private address spaces have two properties that cause numerous problems and complexities at all layers of the Internet protocol suite: - The addresses are unreachable outside of the correct context. - The addresses may overlap other private address spaces, creating ambiguity. The complexities caused by the creation of private IPv6 site-local address spaces can be lumped into two major categories:(1) Problems for upper-layer protocols, and (2) problems for nodes that exist in two or more sites (site-border nodes). 7.1.1 Problems for Upper-Layer Protocols There are many upper-layer protocols that exchange IP address information. These protocols include FTP, DNS, SIP, SCTP, SNMP, routing protocols and many others. Most of these applications do not have enough knowledge of the site topology to make intelligent decisions about when to exchange site-local addresses and/or how to interpret site-local addresses that they receive. In many cases, that information may not be available to the local node, at all. The specific problems that IPv6 site-local addressing raises for each of these protocols are detailed in later sections. In general, though, any upper-layer protocol that would require an Application Level Gateway to traverse an IPv4 NAT may have problems with the use of IPv6 site-local addresses. 7.1.1.1 Similarities to NAT As you read through the problems caused by the use of IPv6 site- local addresses in globally connected networks, you will find that many of these problems are similar to the issues caused by IPv4 NAT. This is expected, as many NAT-related problems are caused by the use of ambiguous private address spaces. Some of the complexities of IPv4 NAT are avoided by the fact that IPv6 SBRs do not translate site-local addresses into global Wasserman Expires February 2003 4 Impact of Site-Local Addressing in IPv6 December 2002 addresses. Instead, traffic to and from site-local addresses is dropped at site boundaries, with an appropriate ICMP error message. SBRs do not modify addresses in forwarded IP headers, so the use of IPv6 site-local addresses does not conflict with end-to-end security or peer-to-peer communication. Unfortunately, dropping packets with site-local IPv6 source or destination addresses does not prevent site-local addresses from being sent outside of the local site in upper-layer protocol headers or data. This causes a set of problems and complexities for upper-layer protocols, some of which have been resolved in IPv4 NAT by the use of Application Level Gateways (ALGs). One possible solution to these problems would be to implement IPv6 ALGs on site- border routers, but this solution does not seem satisfactory, as it would require infrastructure updates for the deployment of new applications and would not work properly with end-to-end encryption. Without the deployment of IPv6 ALGs, however, IPv6 would require upper-layer protocols to make intelligent choices about when to exchange site-local addresses with other nodes and/or how to interpret site-local addresses that are received. This would require upper-layer protocols to have knowledge of the site topology of the network, and would significantly complicate the implementation of those protocols. 7.1.2 Problems for Site-Border Nodes In the IPv6 scoped addressing architecture, all links are in exactly one site and site borders run though nodes. Therefore, the use of site-local addressing in a global network requires the implementation of site-border nodes, including site-border routers (SBRs) and/or multi-sited hosts. Without these nodes, the entire global network would be a single site. Site-border nodes are very complex, at the IP layer and at other layers of the protocol stack. Any application or upper-layer protocol that may need to run on a site-border node will need to be aware of site-local addressing. And, because there is no hard definition for where a site border can be configured, any node that is capable of having multiple physical or logical interfaces may need to include site-border capability. This includes any host that may be simultaneously connected to a local network, and connected to a remote network via a virtual private network (VPN). It has been proposed that site-border nodes can be avoided in IPv6 networks by the use of firewalls at site borders. In that case, however, the firewall itself will be an SBR, and will need to be implemented, configured and managed accordingly. It is also unclear how this would eliminate the need for site-border hosts, as in the VPN scenario cited above. Wasserman Expires February 2003 5 Impact of Site-Local Addressing in IPv6 December 2002 7.1.2.1 Problems for All Site-Border Nodes Site-border nodes are simultaneously connected to two or more potentially overlapping private address spaces and must implement internal mechanisms to distinguish between those address spaces. This makes IPv6 implementations more complex and expensive, and it may cause problems for applications that are unaware of site-local addresses. Site-border nodes use zone identifiers to fully qualify non-global addresses. Zone IDs are local, artificial identifiers, typically small integers, that must be included with any non-global address to indicate the link or site with which the address is associated. Zone IDs are needed because the same address may occur in multiple zones and refer to multiple separate nodes. It is even possible that a single node will have the same scoped address configured on two interfaces in two separate zones, and those addresses must be treated independently. Users or applications that wish to use a site-local destination IP address will need to provide a zone ID to fully qualify the address. This zone ID will need to be specified in the user interface, provided by the DNS resolver, or determined by the application for any address received via other means. Because zone IDs are node-specific, not consistent across a zone, this will typically require an application to determine which interface a site-local address was received from, and to associate the site- scope zone ID of that interface with the received address. This will cause significant complexity in applications that pass address information at the application layer, such as FTP. Some people have commented that the same problems exist for link- local addresses, but this is not entirely true. Link-local addresses can use an existing identifier, the interface ID, as their qualifier, while site-local addresses require the configuration of an artificial zone ID. Also, it is not expected that link-local addresses will be put in the DNS, or passed around by applications running on multi-link networks. In general, link-local addresses will only be used for specialized purposes or on single-link networks, where they can be treated like global addresses. It is the recommendation of this document that site-local addresses be similarly restricted to use on single-site networks, where they can be treated like global addresses. 7.1.2.2 Problems for Site-Border Routers SBRs must ensure that site-local traffic is not forwarded outside of the site. This requires complex processing in the forwarding engine of an SBR. This is another situation where people argue that the complexity is already required for link-local addresses, but again that is not completely true. All IPv6 routers will need to check all forwarded Wasserman Expires February 2003 6 Impact of Site-Local Addressing in IPv6 December 2002 packets to determine if either the source or destination is link- local. If so, the packet will be discarded and an ICMP "scope exceeded" error message will be generated. This is more complex than the forwarding logic in simple IPv4 routers, but is not nearly as complex as the forwarding logic in an IPv6 SBR. First, the forwarding engine on an SBR must look at both the source and destination addresses to determine if either of them is link- local. If so, the packet will be discarded, as above. If the destination is not link-local, it must be either site-local or global. If the destination address is site-local, the router will look at the interface on which the packet was received to determine the site-local zone in which the packet originated, and will perform a lookup in the correct site-local forwarding table and forward the packet, as indicated. If the address is global, however, the router will lookup the destination in the global routing table. It will then use the inbound interface to determine the site-local zone in which the packet originated, and the outbound interface to determine the site-local zone in which the packet will be sent. If those zones do not match, then the packet is being forwarded across a site boundary. In this case, the router will need to re-examine the source address of the packet to determine if that address is site- local. If so, the packet will be discarded, and an ICMP "scope exceeded" error message will be generated. Otherwise, the packet will be forwarded, as indicated. This processing will need to be performed for every packet that is forwarded by an SBR, and this level of complexity will impact the performance, cost and reliability of all IPv6 routers with SBR capability. 7.2 Routing Protocol Issues There has been a lengthy discussion between the IPv6 WG and the routing area regarding the impact of IPv6 site-local addressing on routers and routing protocols. The currently defined IPv6 unicast routing protocols make no special provisions for site-local addressing. Site-local addresses are treated exactly like global IPv6 addresses for the purposes of route computation and advertisement. This is consistent with the use of these protocols on intra-site routers, or on single-site networks, but is not sufficient for an SBR. Some people have posited that building a site-border router is a simple matter of filtering site-local route advertisements at site borders. In truth, though, a RIP or OSPF SBR will need to maintain a separate site-local routing table for each connected site, in addition to a global table. Each site-local table will be populated using the site-local addresses advertised by peers within Wasserman Expires February 2003 7 Impact of Site-Local Addressing in IPv6 December 2002 one site, and the single global table will be populated based on global prefixes advertised by all peers. This requires significant implementation changes, and can not be accomplished by filtering. This will also have a significant impact on the route computation and forwarding performance of IPv6 SBRs. BGP and IS-IS SBRs will have a different set of complexities. These protocols are not capable of maintaining a boundary between two ambiguous address spaces within a single router. For these protocols, it will be necessary to create (logical or physical) "dummy sites" at site borders, links that are unnumbered in the site-local scope. As well as making routing computations more complex, these "dummy sites" will complicate network configuration and management. Site-local addressing substantially constrains the configuration of a network. Sites must be "convex" at both the site and global scopes [SCOPARCH], which effectively requires that site boundaries correspond with OSPF or IS-IS area boundaries and/or BGP AS boundaries. One of the major benefits attributed to site-local addressing is simple access control as described in section 8.3, but those access control boundaries would be required to coincide with routing protocol boundaries, which may not always be convenient. 7.3 DNS Issues In order to realize most of the benefits attributed to site-local addressing, site-local addresses would actually need to be used for site-local communication. Practically, this means that site-local addresses would need to be stored in the DNS, and returned in DNS responses when appropriate. This causes significant complexities for both DNS servers and DNS resolvers. 7.3.1 DNS Server Issues Like all upper-layer protocols that exchange address information, it would be necessary for DNS servers to have enough information about the site topology of the network to know when it would be appropriate to return a site-local address and when it would not. Unfortunately, DNS servers do not inherently have this type of information. In IPv4 enterprise networks that use NAT boxes, it is necessary to use private address information for all local communication to prevent local traffic from flowing through the NAT. In IPv4, the problem of receiving private address information from the DNS is typically resolved using a mechanism called "two-faced DNS" or split DNS, and it is likely that this mechanism could be used within IPv6 sites. Enterprise operators configure their split DNS servers with the prefixes of hosts within a particular site, and the DNS server matches the IP source address of received queries against the Wasserman Expires February 2003 8 Impact of Site-Local Addressing in IPv6 December 2002 configured prefixes to decide whether or not to return private address information. The split DNS solution requires configuration (usually manual configuration) of site topology information into DNS servers, so it makes the network more brittle in the face of routing topology changes. Split DNS also has the affect of tying the topology of the DNS to the routing topology of the network. Ideally, nodes would be able to access the DNS via any DNS server and receive consistent answers, however split DNS requires that nodes within a site use the local DNS server(s) in order to receive site-local responses. It also strongly encourages DNS servers to be deployed on a per- site basis, as it would be more complex to configure a single split DNS server to serve more than one private address space. Despite its operational and architectural short-comings, this solution might be satisfactory for enterprise networks, but it is unclear how it could be adapted for use by unmanaged home and small office networks. Today, these networks typically receive their DNS service from an ISP, but it is highly unlikely that ISPs will provide split DNS service for customers' site-local addresses. This will make it difficult or impossible for small networks to realize the benefits of site-local addressing without setting up a local DNS server or local name resolution service. It would also be difficult to realize the benefits of site-local addressing in intermittently connected sites, as described in section 8.2.2, without a locally accessible name resolution service. 7.3.2 DNS Resolver & Address Selection Issues Site-local addresses present a number of complexities and technical problems for DNS resolvers. Some of these issues affect all IPv6 nodes, but the most serious issues concern site-border nodes. 7.3.2.1 DNS Resolver Issues for All IPv6 Nodes Ideally, DNS resolvers would return an unordered list of IPv6 addresses corresponding to a particular DNS name, and that list could serve as a candidate list for destination addresses. The candidate list would be passed unmodified into the IP stack, where it would be compared with the list of available source addresses, and the most appropriate source/destination address pair would be selected. Unfortunately, the interfaces to the most popular TCP/IP stacks separate destination and source address selection, requiring an application to determine which destination address to try first. Most applications simply try the first address in the list returned by the DNS resolver. Other destination addresses will only be tried if the first address is unreachable. Because of this fact, it is necessary for DNS resolvers to make decisions about which IPv6 address will be preferred, and reorder the list of potential destination addresses to place the most Wasserman Expires February 2003 9 Impact of Site-Local Addressing in IPv6 December 2002 preferred address first. These preferences may be based on local policy and/or the availability of corresponding addresses on the local host. These mechanisms are described in the IPv6 Default Address Selection document [ADDRSEL]. DNS resolvers must also supply zone IDs for any site-local addresses that are included in the list of potential destination addresses. This information would most likely be determined by checking the interface on which the DNS response was returned, and using the site-local zone ID associated with that interface for each of the returned addresses. This practice has not been documented, however, and there may be flaws in this approach. Site-local addressing adds substantial complexity to the implementation of DNS resolvers, and there is at least one unresolved technical issue regarding how DNS resolvers should handle site-local addresses. 7.3.2.2 DNS Resolver Issues for Site-Border Nodes Site-border nodes have a more serious DNS resolver problem. As explained in the section 7.3.1, IPv6 site-local addressing requires the deployment of split DNS servers. These servers will return site-local addresses to queries that appear to come from within the site (based on source address) and will not return site-local addresses to queries from outside the site. This presents some significant problems for site-border nodes. For example, consider a site-border node, Node-1, in two sites: Site-A and Site-B. Node-1 will have a DNS server list, which may contain a DNS server in Site-A, DNS-A, and a DNS server in Site-B, DNS-B. How will Node-1 decide which DNS server to use for name resolution? Generally, IP nodes use the first DNS server in the server list, and only try subsequent DNS servers if the first fails to respond. So, if DNS-A is the first DNS server in the DNS server list on Node-1, Node-1 will send all queries to DNS-A and will not use DNS-B unless DNS-A fails to respond. So, Node-1 will never receive site-local addresses for nodes in Site-B. Node-1 will not realize the benefits of site-local addressing in Site-B, and will be unable to reach nodes in Site-B that have no global addresses. If site-local addresses are used as intended, site-border nodes are likely to be a common occurrence in IPv6. For example, a node may be present on a home network and be part of the home site, while using VPN to access a work site. If the node uses DNS names to access services in both sites, and both sites use site-local addresses for access control, then it would not be possible to simultaneously access a local service at home (such as a printer) and a local service at work (such as a file server). If global addresses were used instead, and advertised in the global DNS, this problem would not occur. 7.4 Transport Protocol Issues Wasserman Expires February 2003 10 Impact of Site-Local Addressing in IPv6 December 2002 Some transport protocols, such as SCTP and SIP, pass local IP addresses to other nodes. These protocols do not have sufficient knowledge of the site topology of the network to make wise decisions about whether to send site-local addresses, and it is entirely unclear where they could get that type of information, as it may not be available to the local host. If site-local addresses are leaked outside of the site in transport protocols, various problems may result. In addition to being unreachable from outside the site, the ambiguous nature of site- local addresses may result in unexpected errors (i.e. connection reset by peer) or the establishment of connections to unexpected end-points. There is an Internet-Draft that describes how SCTP should work with IPv6 [SCTPIPV6]. It specifies the process that would be used during SCTP initialization to determine the correct subset of local addresses to send to the remote endpoint from both the active and passive ends of the SCTP connection. This processing is more complex than the IPv4 method of sending all local addresses but, if adopted and implemented it should result in the proper operation of SCTP over IPv6. Other transport protocols that exchange IP addresses may require similar mechanisms. 7.5 Network Management Issues Scoped addressing causes particular problems for network management. A network management station (NMS) will use a network management protocol, such as SNMP, to access information in a running piece of networking equipment, such as a router. In some cases, NMS applications will collect information from multiple nodes, and attempt to correlate that information. When the internal data structures of a node contain site-local addresses, or when a node uses a site-local address to identify another node, those addresses may be sent to the NMS. However, the NMS has no way to know whether it is in the same site as a managed node. So, it has no way of knowing if a request sent to a particular site-local address will reach the desired target. For example, a network device may be running a two-party TCP application using site-local addresses. The NMS can look at the TCP connection table, and can see that a connection is active with a remote node at a particular site-local address, but it cannot know whether it is capable of reaching the remote node using that address. This problem also exists for link-local addresses, and site-local addresses do not introduce any additional problems. However, the impacts on network management should be taken into account before specifying any inherently site-local mechanisms or applications. Wasserman Expires February 2003 11 Impact of Site-Local Addressing in IPv6 December 2002 7.6 Application Protocol Issues Applications are extremely varied, and it can be difficult to say anything that applies to all types of applications. However, there are some generalizations that can be made about how IPv6 site-local addressing will impact application protocols. The application space can be broken down into several categories, each of which will be impacted differently by IPv6 site-local addressing: - Applications that do not exchange IP addresses at the application layer. - Two-party client/server applications that exchange IP addresses at the application layer. - Multi-party applications that exchange IP addresses at the application layer. All applications will be affected by IPv6 site-local addressing. Application user-interfaces will need to support the inclusion of a zone ID whenever an IP address is entered by the user, and applications may have to add a default zone ID to IP addresses when one is not provided. Applications may also need to specify a preference regarding the selection of site-local or global source and/or destination addresses. Particularly in a situation where access control may be based on the use of a site-local source address (see section 8.3), it may be necessary for applications to specifically request a site-local source address in order to access particular nodes or services. Any application that may run on a site-border node would need to associate any site-local addresses that it receives (in packets, from the IP stack, from DNS, etc.) with a site-local zone ID, to avoid any problems caused by ambiguous addresses. Simple client/server applications that do share IP addresses at the application layer will be more greatly affected by IPv6 site-local addressing. These applications will need to make intelligent choices regarding which addresses should and shouldn't be passed at the application layer to avoid leaking site-local addresses beyond site boundaries. The rules developed for SCTP [SCTPIPV6] may provide a suitable model for most applications, but application- specific mechanisms would need to be developed and deployed to avoid the leaking of site-local addresses. If site-local addresses are leaked, they may result in unexpected errors (i.e. connection reset by peer) or the establishment of connections with the wrong node. The robustness and security implications of this problem will differ from application to application. Multi-party applications that pass IP addresses at the application layer present a particular challenge. Even if a node can correctly determine which of its addresses to pass to a single remote node, Wasserman Expires February 2003 12 Impact of Site-Local Addressing in IPv6 December 2002 it will have no way of knowing where those addresses may eventually be sent. The best course of action for these applications might be to use only global addresses. However, this would prevent the use of these applications on isolated or intermittently connected networks that only have site-local addresses available, and might be incompatible with the use of site-local addresses for access control in some cases. 7.7 Security Protocol Issues Security protocols also use IP addresses to identify nodes, either to look up security information in tables, or as keys in automatic keying mechanisms. The impacts of IPv6 site-local addressing on these protocols still need to be explored. Wasserman Expires February 2003 13 Impact of Site-Local Addressing in IPv6 December 2002 8 Benefits of IPv6 Site-Local Addressing IPv6 site-local addressing has several benefits for both isolated and globally connected IPv6 sites. Site-local addresses also provide potential benefits for inherently local applications and services. 8.1 Benefits for Isolated Sites A primary advantage of site-local addressing is that the operator of an isolated site, a site that has no IPv6 connectivity to the Internet or any other network, can use IPv6 without obtaining global IPv6 addresses from a registry or service provider. This can be particularly convenient for test networks and other special- purpose networks. Routers in an isolated network can be configured to advertise site- local prefixes that include appropriate subnet ID information, and nodes can use IPv6 autoconfiguration [AUTOCONF] to automatically generate site-local addresses. Site-local addresses can then be used to communicate across the entire attached network. When used within isolated, single-site IPv6 networks, it is not necessary for implementations to treat site-local addresses any differently than global addresses, as site-local addresses are global to the attached network. So, this use of site-local addresses does not raise any architectural or operational issues. It is recommended that site-local addresses be retained in the IPv6 addressing architecture, and that they be restricted to this use. 8.2 Benefits for Globally Connected Sites There are also several advantages to allowing the use of site-local addresses in globally connected sites. These advantages can be grouped into the following categories: (1) Benefits for sites that are newly-connected to the Internet, (2) benefits for sites that are intermittently connected to the Internet, and (3) benefits for sites whose global prefixes are renumbered. It should be noted, however, that most of these benefits will only be realized if site-local addresses are actually used for communication that is local to the site. Practically, this means that IPv6 site-local addresses will need to reside in the DNS, creating a number of complexities that are described in section 7.3. 8.2.1 Benefits for Newly-Connected Sites When an isolated site gains connectivity to the IPv6 Internet, it could be useful for nodes to maintain their site-local addresses, in addition to their new global addresses. This would allow long- lived connections to remain active, and would prevent cached, logged or stored IP address information from becoming invalid. Wasserman Expires February 2003 14 Impact of Site-Local Addressing in IPv6 December 2002 The need for site-local addresses in this situation could be avoided by using global addresses on any network that may later require connectivity to the Internet. However, the current provider-allocated method of IPv6 address allocation makes it impossible to get an IPv6 address allocation without committing to a particular service provider and paying for connectivity, which makes the use of global addresses on isolated networks impractical. The limited scope of site-local addresses is not an advantage in the newly-connected network situation. Easily obtainable, provider-independent global addresses would actually be preferred, but are not available. 8.2.2 Benefits for Intermittently Connected Sites The simultaneous use of site-local and global addressing could also be beneficial in sites that are intermittently connected to the Internet, such as some home and small business networks. If these sites do not have stable IPv6 addresses, their global IPv6 prefixes may time out and become invalid during a period when they are not connected to the Internet. Using site-local addresses for local traffic would allow local connections to survive the expiration of global address prefixes. Of course, this benefit will not actually be realized without a local split DNS server that will return site-local addresses in response to local name lookups. This is another situation where site-local addresses are being used as a substitute for stable, provider-independent addresses. The complexity of split DNS and scoped addressing might be avoided by the availability stable, provider-independent addressing. 8.2.3 Benefits for Renumbered Sites A much-touted advantage of site-local addressing is that it will allow site-local, long-lived IPv6 connections to survive renumbering of global prefixes. Although enterprises renumber their own networks rather frequently, these are voluntary events. Involuntary global prefix renumbering could happen when an ISP goes out of business, requiring a switch to a new ISP, or when an ISP renumbers its internal network, changing the prefixes assigned to customers. Once again, stable, provider-independent addressing would be a preferable solution to this problem. The use of site-local addresses to minimize the impact of global renumbering necessitates the split DNS and application-layer complexities discussed in previous sections, and the scoped nature of site-local addresses does not provide any inherent advantage in this situation. Also, an enterprise will still need to reconfigure its routers, firewalls, etc. with new global prefixes to reestablish global connectivity. Wasserman Expires February 2003 15 Impact of Site-Local Addressing in IPv6 December 2002 Although the use of site-local addresses for long-lived connections may help them to survive global prefix renumbering, there is a potential risk to using site-local addresses for long-lived connections. Those connections may fail when a site becomes partitioned, even if global connectivity is still available between the partitions. To make a wise decision about whether to use site-local or global addresses for long-lived intra-site connections, it is necessary to weigh the expected frequency of renumbering against the expected frequency of site partitioning. Since the frequency of these events will vary widely between sites, there is no single answer that would be best for all sites. The default IPv6 address selection rules [ADDRSEL] currently prefer site-local addresses for site-local communication, but this preference can be overridden by local configuration. It should also be noted that there are many reasons why a long- lived connection might fail, including network outages, system restarts or local network reconfiguration. So, any application that depends upon the maintenance of a long-lived connection will still need to include a mechanism to re-initiate a lost connection. That mechanism should include performing a new DNS query (or equivalent name to address mapping) to allow the connection to be reestablished after renumbering. 8.3 Access Control Benefits Site-local addressing can be used as a simple mechanism for providing one level of access control within a network. Because site-local addresses are not reachable from outside the site, they can be used to control access to local applications and services, such file servers and printers. Some people have predicted the availability of inherently local applications, services or devices that will only be accessible at site-local addresses, or when reached using a site-local source address. However, the nature of scoped addressing sharply limits the usefulness of site-local addresses as an access control mechanism. Sites cannot be nested and cannot overlap, so they only provide a single level of access control. This does not map well to enterprise access control needs, which may include different levels of access control at the extranet, intranet, department and individual node levels. And, as discussed in section 7.2, the site-local access control boundaries would need to be configured to coincide with routing protocol area or AS boundaries, which is not a good match for most situations. A more flexible mechanism for providing simple access control in IPv6 has been proposed by Steve Bellovin [ACCESSPFX]. This mechanism allows for many levels of access control, and does not necessitate the use of split DNS and/or cause the other complexities associated with site-local addressing. Wasserman Expires February 2003 16 Impact of Site-Local Addressing in IPv6 December 2002 8.4 Potential Benefits for Local Applications and Services There is a proposal to use IPv6 well-known site-local unicast addresses to reach local DNS servers. If adopted, this proposal could have benefits for both isolated and globally connected IPv6 sites. However, there are other mechanisms that could be used to locate DNS servers (DHCP, SLP, Router Advertisements) that do not rely on the use of site-local addresses. There is also the potential for the development of inherently local applications and services that are aware of, and take advantage of, the scoped nature of site-local addressing. Site-local addressing has been defined for years, though, and there are no applications or services that fall into this category. Wasserman Expires February 2003 17 Impact of Site-Local Addressing in IPv6 December 2002 9 Alternatives to Site-Local Addressing As indicated above, the advantages of site-local addressing fall into two categories: - Those that could be better served by the existence of stable, provider-independent addresses. - A limited access control mechanism, for which there is already a superior alternative. So, it is recommended that the IPv6 WG pursue an alternative access control mechanism, and that the IETF determine how we can provide stable, provider-independent addressing in IPv6. It is important to note that IPv6 site-local addresses are not globally routable, so it might not be necessary to replace them with globally routable, provider-independent addresses. However, we should think long and hard before continuing the IPv4 model where the only way for small enterprises and home users to achieve global client connectivity using a stable, provider independent addresses is to use NAT. Wasserman Expires February 2003 18 Impact of Site-Local Addressing in IPv6 December 2002 10 Status of Site-Local Implementation and Deployment IPv6 site-local addresses have been defined in the IPv6 addressing architecture for many years, and their use on globally connected networks and nodes has been defined in the scoped addressing Internet-Draft for at least four years. However, there are very few implementations that actually provide any special treatment for site-local addresses. Those implementations that do exist are research and test implementations and do not include much upper Layer protocol support, such as routing protocols or applications. The remainder of the IETF has not embraced site-local addressing, so the needs of site-local addresses have not been reflected in the IPv6 versions of most routing protocols, transport protocols or applications. Perhaps due to the lack of implementations, there is no significant deployment of IPv6 routers that advertise site-local prefixes. So, limiting site-local addresses to use on isolated, single-site networks would have very little impact on existing implementations, and no impact on existing deployment. It would also have minimal impact on IETF IPv6 documents, outside of those owned by the IPv6 WG. Wasserman Expires February 2003 19 Impact of Site-Local Addressing in IPv6 December 2002 11 Recommendations The use of site-local addresses on globally connected networks and nodes will substantially complicate the specification and implementation of IPv6, particularly for IPv6-compatible upper- layer protocols. There are also several significant, unresolved technical issues with site-local addressing, particularly regarding site-border nodes and DNS. There are a lot of clever people in the IPv6 community, so it is likely that we could find resolutions or workarounds to the technical issues presented by site-local addressing. We could also develop the complex software required to make them work. But, why would we want to do that? IPv6 site-local addressing adds significant complexity and cost to IPv6, and it does not provide sufficient benefit to justify that cost. Every benefit of site-local addressing can be better provided by a simpler, less problematic, and less expensive mechanisms. So, this document recommends that IPv6 site-local addresses be limited to use on isolated, single-site networks. Limiting the use of IPv6 site-local addresses in this fashion will eliminate virtually all of the complexities and issues associated with site- local addressing, and will still allow site-local addresses to be used in isolated networks where globally routable IPv6 prefixes may not be available. In particular, an update to the IPv6 addressing architecture should be published, indicating that site-local addresses are reserved for use on isolated networks. Then, site-local addressing should be removed from the scoped addressing architecture. The scoped addressing architecture should still be published, to explain the use of link-local addresses and how address scopes work for IPv6 multicast. If there is significant concern that site-local addresses will be misused despite this restriction, we could instead list them as completely reserved in the IPv6 addressing architecture, and recommend that they be included in the set of IPv6 addresses that should never appear on the wire ("Martian" addresses). Wasserman Expires February 2003 20 Impact of Site-Local Addressing in IPv6 December 2002 12 Security Considerations This document does not define or modify a protocol. However, it does present choices that are available to the IETF community regarding IPv6 site-local addressing, and those choices do have some security implications. In particular, some access control benefits have been attributed to site-local addressing. If site-local addresses are restricted to use in isolated sites, it will not be possible to use site-local addresses for access control. On the other hand, the use of site-local addresses on globally connected networks and nodes may cause some problems or complexities for security protocols, similar to the problems and complexities caused for other protocols. The impact of site-local addressing on security protocols has not been fully explored in this document, due to the author's limited knowledge of those protocols. Further input is requested. There are some security-related topics discussed in sections 7.7 and 8.3 of this document. Wasserman Expires February 2003 21 Impact of Site-Local Addressing in IPv6 December 2002 13 References [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [SCOPARCH] S. Deering, et. al, "IPv6 Scoped Address Architecture", draft- ietf-ipngwg-scoping-arch-04.txt, June 2002. [ADDRARCH] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipngwg-addr-arch-v3-11.txt, October 2002. [ADDRSEL] R. Draves, "Default Address Selection for IPv6", draft-ietf- ipv6-default-addr-select-09.txt, August 2002. [SCTPIPV6] R. Stewart, S. Deering, "IPv6 addressing and Stream Control Transmission Protocol", draft-stewart-tsvwg-sctpipv6-01.txt, April 2002. [ACCESSPFX] S. Bellovin, "Access Control Prefix Router Advertisement Option for IPv6", draft-bellovin-ipv6-accessprefix-00.txt, November 2002. Wasserman Expires February 2003 22 Impact of Site-Local Addressing in IPv6 December 2002 14 Acknowledgements This document reflects information and ideas obtained from many people over several years of discussing these issues. 15 Author's Contact Information Comments or questions regarding this document should be sent to: Margaret Wasserman Wind River 10 Tara Blvd., Suite 330 Phone: (603) 897-2067 Nashua, NH 03062 USA Email: mrw@windriver.com Wasserman Expires February 2003 23