Internet-Draft M. Wasserman Document: draft-wasserman-ipv6-sl-impact-02.txt Wind River Expires: September 2003 March 2003 The Impact of Site-Local Addressing in Internet Protocol, Version 6 (IPv6) 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. 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 defined 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 their originating site. Site- local addresses also add significant complexity at the IP layer and at other layers of the protocol stack. Although there are several benefits attributed to site-local addressing, some of those benefits can be more easily achieved through less problematic mechanisms. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Wasserman Expires June 2003 1 Impact of Site-Local Addressing in IPv6 March 2003 Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Copyright Notice..................................................1 Table of Contents.................................................2 1 Terminology...............................................4 2 Introduction..............................................4 3 Technical Issues With Site-Local Addressing...............5 3.1 The Fundamental Issue.....................................5 3.1.1 Problems for Other Protocols..............................5 3.1.1.1 Similarities to NAT.......................................6 3.1.2 Problems for Site-Border Nodes............................6 3.1.2.1 Problems for All Site-Border Nodes........................7 3.1.2.2 Problems for Site-Border Routers..........................8 3.2 Routing Protocol Issues...................................9 3.3 DNS Issues...............................................10 3.3.1 DNS Server Issues........................................10 3.3.2 DNS Resolver Issues......................................11 3.3.2.1 DNS Resolver Issues for All IPv6 Nodes...................11 3.3.2.2 DNS Resolver Issues for Site-Border Nodes................12 3.4 Mobile IPv6 Issues.......................................12 3.5 Transport and Session Protocol Issues....................14 3.6 Network Management Issues................................15 3.7 Application Protocol Issues..............................15 3.8 Security Protocol Issues.................................16 3.8.1 IP Security Issues.......................................17 3.8.2 Key Exchange Protocol Issues.............................17 3.8.3 Security Certificate Issues..............................17 4 Benefits of IPv6 Site-Local Addressing...................19 4.1 Addressing Benefits for Isolated Sites...................19 4.2 Single-site Networks.....................................19 4.3 Networks behind NATs.....................................19 4.4 Addressing Benefits for Globally Connected Sites.........19 4.4.1 Benefits for Newly-Connected Sites.......................20 4.4.2 Benefits for Intermittently Connected Sites..............20 4.4.3 Benefits for Renumbered Sites............................21 4.5 Access Control Benefits..................................21 4.5.1 Site-Local Access Control and Tunneling..................22 4.6 Potential Benefits for Local Applications and Services...23 5 Status of Site-Local Implementation and Deployment.......24 6 Conclusions..............................................25 7 Security Considerations..................................26 8 Change Log...............................................27 9 References...............................................28 9.1 Normative References.....................................28 Wasserman Expires September 2003 2 Impact of Site-Local Addressing in IPv6 March 2003 9.2 Informative References...................................28 10 Acknowledgements.........................................29 11 Author's Contact Information.............................29 12 Appendix A: "Limited Use" Proposal......................29 Wasserman Expires September 2003 3 Impact of Site-Local Addressing in IPv6 March 2003 1 Terminology IPv6 Internet Protocol, Version 6 [RFC2460] Site-Border Node An IPv6 node with interfaces in more than one site SBR Site Border Router, a Site-Border Node that forwards packets Multi-sited Host A Site-Border Node that does not forward packets NAT Network Address Translation 2 Introduction The IPv6 addressing architecture [ADDRARCH] introduces the concept of 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. The concept of scoped unicast addressing is further specified in an Internet-Draft currently under development in the IPv6 WG, the IPv6 Scoped Addressing Architecture [SCOPARCH]. This document assumes that the reader has read the latest IPv6 Addressing Architecture and IPv6 Scoped Address Architecture Internet-Drafts and is familiar with the concepts and terminology related to IPv6 scoped 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), mobile IP, transport protocols, network management systems, applications and security protocols. This document describes many of those issues and attempts to analyze the root causes of the problems. This document also discusses the complexities that the use of site- local addressing causes for IPv6 implementations, particularly for upper-layer protocols and applications. Some complexities are caused by the use of any scoped unicast addressing, such as IPv6 link-local addressing, but there are additional complexities caused by site-local addressing which are discussed in detail in this document. Several benefits have been attributed to site-local addressing, but most of those benefits can be achieved through other mechanisms that cause fewer complexities and problems than site-local addressing. This document describes the benefits of site-local addressing, and suggests alternative methods to achieve those benefits. In an appendix, this document makes a recommendation to limit the use of site-local addresses to non-globally connected networks. Wasserman Expires September 2003 4 Impact of Site-Local Addressing in IPv6 March 2003 3 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 many of those issues, and points out known solutions or workarounds for some of them. 3.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 their original context. - The addresses may overlap other private address spaces, creating ambiguity. Private addresses cause problems whenever they are sent outside of the context in which they are reachable. This is called private address leaking, and it can occur in IP headers, extension headers or options, routing protocols, DNS replies, upper-layer protocols or data. Private address leaking will cause various problems, depending upon how and where the addresses are leaked. Leaking of ambiguous private addresses causes further problems, as the leaked addresses may appear to identify unexpected nodes in the receiving networks. This can cause serious robustness or security issues for upper-layer protocols that use site-local addresses to identify remote nodes, as this may lead to communication with unexpected end-points. With ambiguous private addresses, it can also be difficult to find the source of the leaked address, as it is not possible to associate an ambiguous private address with a particular administrative domain. The major issues and complexities caused by the use of IPv6 site- local addresses on globally connected networks can be lumped into two major categories: (1) Problems for other parts of the protocol stack, and (2) problems for nodes that exist in two or more sites (site-border nodes). 3.1.1 Problems for Other Protocols There are many TCP/IP networking protocols that exchange IP address information. These protocols include FTP, DNS, SIP, SCTP, SNMP, routing protocols, mobile IP, security protocols and many others, including many non-IETF protocols. Most of these protocols do not have enough knowledge of the site topology to make intelligent decisions about when to exchange site-local addresses and/or how to Wasserman Expires September 2003 5 Impact of Site-Local Addressing in IPv6 March 2003 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 addresses raise for each of these protocols are detailed in later sections. In general, though, any protocol that would require an Application Level Gateway (ALG) to traverse an IPv4 NAT may have problems with the use of IPv6 site-local addresses. 3.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 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 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. 3.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. Wasserman Expires September 2003 6 Impact of Site-Local Addressing in IPv6 March 2003 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 may include any node that can be connected to a home network, while simultaneously being connected to an office network via a virtual private network (VPN) tunnel. 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 tunnel scenario cited above. 3.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 multiple 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 (zone IDs) 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 necessary 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 site-local 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 identifier 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, and may not always produce the correct results when combined with mechanisms that create complex, multi-layer routing topologies, such as mobile IP or IP-in-IP tunneling. Wasserman Expires September 2003 7 Impact of Site-Local Addressing in IPv6 March 2003 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 name or number, as their qualifier, while site-local addresses require the configuration of an artificial zone ID. It is also unlikely 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 exactly like global addresses. 3.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 some have argued 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 packets to determine if either the source or destination is link-local. If so, the packet will be discarded and an appropriate ICMP error message will be generated. This is more complex than the forwarding logic in a simple IPv4 router, 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 destination address is global, the router will perform a lookup 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 that case, the router will need to re-examine the source address of the packet to determine if the source 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 Wasserman Expires September 2003 8 Impact of Site-Local Addressing in IPv6 March 2003 performance, cost and reliability of all IPv6 routers with SBR capability. 3.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 isolated, 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 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. Implementation experience with OSPF on an SBR indicates that, in order to populate a single global table and separate site-local tables, it may be necessary to use separate link-state advertisements (LSAs) for site-local vs. global routes. If so, this would also have implications for non-site-border OSPF routers, as the current definition of OSPF for IPv6 makes no distinction between global and site-local routes in LSAs. BGP and IS-IS SBRs have a different set of complexities. These protocols are not capable of maintaining a boundary between two ambiguous address spaces within a single router. In BGP and IS-IS, the area borders or autonomous system (AS) borders are on the link, not inside a router. Also, these protocols are not capable of dealing with the concept that the same address prefix may be in use on multiple attached networks, indicating separate subnets. To enable BGP and IS-IS SBRs, it will be necessary to create (logical or physical) "dummy sites" at site borders. "Dummy sites" are single logical or physical links that are unnumbered in the site-local scope. These "dummy sites" will allow a site-border BGP or IS-IS SBR to exist in only one site-local address scope, so that a single router will not receive ambiguous site-local prefixes. Filters will be installed, so that site-local traffic will never be forwarded across the "dummy site", and site-local addresses will not be advertised to peers on that link. As well as making routing Wasserman Expires September 2003 9 Impact of Site-Local Addressing in IPv6 March 2003 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 4.5, but the need for sites to be "convex" requires those access control boundaries to coincide with routing protocol boundaries, which may not always be convenient. 3.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. 3.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 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- Wasserman Expires September 2003 10 Impact of Site-Local Addressing in IPv6 March 2003 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 other 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 4.4.2, without a locally accessible name resolution service. Split DNS also interacts poorly with Mobile IPv6, as described in section 3.4. 3.3.2 DNS Resolver 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. 3.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 APIs 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, as 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 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]. The current address selection rules prefer site-local destinations, so that site-local addresses will be used, if available. The DNS resolver must also specify a zone ID for any site-local addresses that are included in the address list returned to the Wasserman Expires September 2003 11 Impact of Site-Local Addressing in IPv6 March 2003 calling application. This information would most likely be determined by checking the interface on which the DNS response was returned, and associating the site-scope zone ID of that interface with each site-local address that was received in the DNS response. This practice has not been documented, however, and there are flaws in this approach. For example, this mechanism would not work properly when a local caching resolver is used. In this common configuration, the DNS resolver called by the application uses the loopback interface to send DNS requests to a caching resolver running on the local machine. In this situation, the DNS resolver would be unable to correctly determine the zone ID that should be associated with any site-local addresses that are returned, as all responses will appear to come from the loopback interface. So, site-local addressing adds substantial complexity to the implementation of DNS resolvers, and there are technical issues regarding how DNS resolvers should associate zone IDs with site- local addresses. 3.3.2.2 DNS Resolver Issues for Site-Border Nodes Site-border nodes have an even more serious DNS-related problem. As explained in the section 3.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. 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 a VPN tunnel 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. 3.4 Mobile IPv6 Issues Wasserman Expires September 2003 12 Impact of Site-Local Addressing in IPv6 March 2003 There are some serious issues caused by the interaction of IPv6 site-local addressing and Mobile IPv6 (MIPv6) [MIPV6]. In particular, nodes that implement MIPv6 have no way of knowing whether they will be moved, nor do they know the extent of their expected mobility. They are unaware of site borders, and have no way to detect when they have been moved across a site border. The use of site-local addresses in the MIPv6 home address option may cause security concerns. If site-local addresses are used as an access control mechanism, it is important that MIPv6 implementations do not represent packets to upper layers as being addressed to or from site-local addresses if those packets may actually have originated outside of the local site. To prevent this, MIPv6 implementations should discard packets with a site- local home address option unless the source address of the packet is site-local or link-local. So, if a MIPv6-capable node establishes a connection that uses a site-local source address, that connection would be lost when the MIPv6 node moves outside of the local site. Use of a site-local destination address would also result in a lost connection, an unexpected error (i.e. connection reset by peer) or in packets being sent to an unexpected end-point. MIPv6 would also interact poorly with the split DNS mechanism described in section 3.3.2.1. MIPv6 nodes may continue to use their home DNS server while roaming. If the DNS requests appear to come from inside the local site, the DNS server will return site- local addresses for local nodes, even though the MIPv6 node may currently be outside the site. Even if this could be avoided, a MIPv6 node may issue a DNS request while inside the site, roam to another site, and then attempt to establish a connection. In some cases, this would result in connection delays, as the MIPv6 tries one or more site-local addresses followed by a global address. In other cases, this could result in unexpected errors (i.e. connection reset by remote peer) or the establishment of a connection to an unexpected end-point. So, to maximize the chance that connections will survive and that packets will continue to reach their intended destinations when a MIPv6 node roams, MIPv6 nodes should not configure site-local addresses for their local interfaces and should not use site-local destination addresses. This would require that MIPv6 nodes ignore site-local prefixes in IPv6 router advertisements, and that a different set of default address selection rules be used on MIPv6- capable nodes than is currently defined for other IPv6 nodes. Although these rules would prevent lost connections while roaming, they do have several negative implications for MIPv6-capable nodes. In particular, MIPv6-capable nodes could not access any site-local nodes or services that are protected by the site-local access control mechanism defined in section 4.5, perhaps even when they are at home. MIPv6 nodes would also be unable to realize the other advantages attributed to site-local addressing, and would be unable Wasserman Expires September 2003 13 Impact of Site-Local Addressing in IPv6 March 2003 to communicate with nodes that do not have global addresses configured. These rules would also add complexity to the implementation and administration of MIPv6 nodes, and might present a barrier to the deployment of MIPv6. Other mobility solutions, such as layer two mobility or IP-in-IP tunneling mechanisms may have similar concerns. In particular, care should be taken not to allow traffic that is actually from outside the site to be sent on the local network using either site- local source or destination addresses, as this could be used to undermine a site-local access control mechanism. 3.5 Transport and Session Protocol Issues Some transport and session protocols, such as SCTP and SIP, involve passing the IP address(es) of the local node to remote 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 unclear where they could get that type of information, as it may not be available on the local node. If site-local addresses are leaked outside of the site in transport or session 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. The security and reliability implications of sending packets to unexpected end-points will vary depending upon what application-layer protocol is in use. 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 a safe subset of local addresses to send to the remote end-point from both the active and passive ends of an IPv6 SCTP connection. In particular, each node sends only those local addresses that are equal or greater in scope than the addresses that were originally used to establish the communication. In general, this mechanism should allow SCTP to make appropriate choices regarding when to send site-local addresses to the remote end-point. However, this processing is more complex than the IPv4 method of sending all local addresses. It also may not interact well with mechanisms that modify the actual addresses used to transmit the packet before the packets are seen by upper layers, such as Mobile IP, local tunnel end-points or some IPv6 transition mechanisms. It will also be necessary to define similar mechanisms for other transport and session layer protocols that exchange IP addresses. Wasserman Expires September 2003 14 Impact of Site-Local Addressing in IPv6 March 2003 3.6 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 to know if it can reach the indicated nodes using site-local addresses. 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 same remote node using that site-local address. This problem also exists for link-local addresses. However, the inclusion of site-local addresses in the DNS, preferring them in address selection rules, and using them for access control could result in site-local addresses being used much more widely than link-local addresses. The impact on network management should also be considered when specifying any inherently site-local mechanisms or applications. 3.7 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 Wasserman Expires September 2003 15 Impact of Site-Local Addressing in IPv6 March 2003 applications will 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 4.5), it may be necessary for applications to specifically request a site-local source address in order to access particular nodes or services. Applications will be further complicated by the need to run on site-border nodes. 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 a user-interface, from an API call, from DNS, etc.) with a site-local zone ID, to avoid any problems caused by ambiguous addresses. Any node that can simultaneously be connected to a home network and a work network, perhaps via a VPN tunnel, may be a site-border node. So, most common application implementations will need to be aware of site borders and be capable of functioning properly on a site- border node. 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 two-party 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, that 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 sending packets to an unexpected end-point 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, 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. 3.8 Security Protocol Issues Like all protocols that use IP addresses to identify remote nodes or exchange IP addresses at upper-layers, security protocols will Wasserman Expires September 2003 16 Impact of Site-Local Addressing in IPv6 March 2003 be impacted by the use of IPv6 site-local addresses on globally connected networks. IP Security (IPsec) uses IP addresses to identify nodes and to associate security information with packets. IP addresses are passed by key exchange protocols, and IP addresses are exchanged within security certificates. So, the use of IPv6 site-local addressing on globally attached network and nodes will cause complexity and technical issues for each of these mechanisms. 3.8.1 IP Security Issues IP Security (IPsec) implementations include tables that use IP addresses as keys, such as the SA and SPI tables. Because a site- local IP address does not uniquely identify a node, it will be necessary to have a separate table for each attached site, or to include the site identifier as an additional key associated with each address. 3.8.2 Key Exchange Protocol Issues Key exchange protocols pass around information that is used to populate security tables. In order for appropriate security policies to be enforced for site-local communication, keys will need to be distributed for site-local IPv6 addresses. However, key exchange protocols are unaware of site boundaries, and it is unclear how they will determine how far site-local keying information should be distributed. 3.8.3 Security Certificate Issues The use of site-local IPv6 addresses in security certificates could cause several problems. An address-based certificate attests to the ownership of some IP address. An administrative entity will own a site-local address block in one site, but not in all sites. So, outside the originating site, a certificate that contains a site-local address may appear to apply to a different node than originally intended. Certificates containing site-local addresses should not be put in the LDAP directory, or they could be distributed to many users outside of the originating site. Outside of their originating site, these certificates could be useless or confusing. A certificate that contains a site-local IPv6 address and other name forms, such as a domain name, could be a source of confusion if it is transmitted outside of the original site. The certificate would indicate one name-to-address binding, and the DNS would provide another. To avoid problems where certificates containing site-local addresses may incorrectly identify a node, the user of a certificate that contains a site local IPv6 address must confirm that the certificate was issued by the local site administrator. Wasserman Expires September 2003 17 Impact of Site-Local Addressing in IPv6 March 2003 It is not sufficient to check the certificate authority (CA) root. Wasserman Expires September 2003 18 Impact of Site-Local Addressing in IPv6 March 2003 4 Benefits of IPv6 Site-Local Addressing IPv6 site-local addresses are stable, provider-independent addresses that can be used within isolated and globally connected IPv6 sites. Site-local addressing also provides a simple access control mechanism and may enable inherently local applications and services. 4.1 Addressing Benefits for Isolated Sites A primary advantage of site-local addressing is that the operator of an isolated single-site network, a site that has no IPv6 connectivity to the Internet or any other IPv6 site, 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. 4.2 Single-site Networks Routers in an isolated, single-site 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 desireable 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. Any use of site-local addresses on globally attached networks could reduce the usefulness of site-local addresses in an isolated, single-site network, as it might be necessary for IPv6 implementations to provide special handling for site-local addresses. Any special handling would be inconsistent with treating site-local addresses exactly like global addresses. 4.3 Networks behind NATs Another benefit of site-local addressing is that it provides a convenient set of addresses to use on an internal IPv6 network that is connected to the Internet via a network address translator (NAT). This includes IPv6 sites that are connected to the IPv4 Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT], as well as IPv6 sites that may be connected to an IPv6 Internet using IPv6-to-IPv6 NAT. 4.4 Addressing 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 Wasserman Expires September 2003 19 Impact of Site-Local Addressing in IPv6 March 2003 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 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 and problems that are described in section 3.3. 4.4.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. 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 for newly-connected networks. Easily obtainable, provider-independent global addresses would actually be preferred, but are not available. Also, attaching a site to the Internet for the first time is a one-time event, so optimizing an addressing scheme to simplify first-time connectivity is not advisable. 4.4.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, and address selection rules that prefer site-local addresses when available. 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. Wasserman Expires September 2003 20 Impact of Site-Local Addressing in IPv6 March 2003 4.4.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. Site-local addresses are of minimal utility in this situation, as they will only allow site-local connections to be maintained. The enterprise will still need to reconfigure its routers, firewalls, name servers, etc. with new global prefixes to reestablish global connectivity. 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. 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 long-lived connections might fail, including network outages, system restarts or local network reconfiguration. So, any application that depends upon the maintenance of long-lived connections will still need to include a mechanism to re-initiate lost connections. That mechanism should include performing a new DNS query (or equivalent name to address mapping) to allow the connection to be reestablished after renumbering. 4.5 Access Control Benefits Wasserman Expires September 2003 21 Impact of Site-Local Addressing in IPv6 March 2003 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 as 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. It has been suggested that site-local access control is a direct replacement for the access-control properties of an IPv4-to-IPv4 NAT box, but that is incorrect. Traditional IPv4 NAT provides some level of access control to all nodes on the network, unless an explicit external-to-internal address mapping has been configured. An internal node on a network running IPv4 NAT can establish a client connection to a node on the global Internet without exposing a global address that can be used to establish inbound connections to the internal node. IPv6 site-local addresses do not provide this type of protection. If an IPv6 node wants to communicate with nodes in the global Internet, it will need to have a global IPv6 address configured, and it will need to use that global address for global communication. 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 site-local addressing only provides 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. As discussed in section 3.2, the site- local access control boundaries would also need to be configured to coincide with routing protocol area or AS boundaries, which is not a good match for many situations. A more flexible mechanism for providing simple prefix-based 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 the use of IPv6 site-local addresses on globally connected networks. 4.5.1 Site-Local Access Control and Tunneling There may be security vulnerabilities associated with the use of site-local access control and tunneling. A packet that contains a site-local source or destination address could be encapsulated in a globally addressed header, and sent to a tunnel end-point in a remote site. The resulting traffic would appear to have originated within the destination site. If an unencrypted tunnel transits intermediate networks, it might also be possible for a node on one of the intermediate networks to generate traffic that would be treated as site-local within the destination site. Wasserman Expires September 2003 22 Impact of Site-Local Addressing in IPv6 March 2003 In order to prevent non-local traffic from gaining site-local access privileges, it is necessary for the tunnel end-points to know whether or not the tunnel is entirely contained within a single site. If not, the tunnel end-points should act as site- border routers (SBRs), and discard any traffic that uses site-local source or destination addresses in the internal headers. 4.6 Potential Benefits for Local Applications and Services There is a proposal to use well-known IPv6 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 September 2003 23 Impact of Site-Local Addressing in IPv6 March 2003 5 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 architecture for at least four years. However, there are very few implementations that actually provide any special treatment for site-local addresses, and the majority of those implementations are research or test implementations that do not include much upper- layer protocol support, such as routing protocols or applications. Many of the problems listed in this document have been identified or confirmed by people who have implemented, or attempted to implement, SBRs and/or IPv6 site-border nodes that include routing protocols or other upper-layer protocols. Outside of the IPv6 WG, the remainder of the IETF has not embraced site-local addressing, so the specific properties of site-local addresses have not been reflected in the IPv6 versions of routing protocols, transport protocols or applications. Perhaps due to the lack of implementations that take advantage of site-local addressing, there is no significant deployment of IPv6 routers that advertise site-local prefixes. Wasserman Expires September 2003 24 Impact of Site-Local Addressing in IPv6 March 2003 6 Conclusions As defined in the current scoped addressing architecture, IPv6 site-local addressing causes complexities and problems for all parts of the TCP/IP protocol suite, particularly for site-border routers, Mobile IP and DNS. Supporting the use of site-local addresses on globally connected networks and nodes will increase the cost and complexity of IPv6 implementations, and there are relatively few benefits to offset those costs. At the Atlanta IETF meeting in November 2002, the IPv6 working group agreed to limit the use of IPv6 site-local addressing in some way, to reduce the associated problems and complexities. This document describes the current issues and benefits associated with site-local addressing, and it could be used to evaluate proposals for limiting the use of site-local addresses. It may also be useful in identifying areas for further work, if any, once an appropriate usage model is selected. Wasserman Expires September 2003 25 Impact of Site-Local Addressing in IPv6 March 2003 7 Security Considerations This document does not define or modify a protocol. However, it does present many issues regarding IPv6 site-local addressing, and some of those issues do have security implications. The use of site-local addresses on globally connected networks and nodes causes several complexities and technical issues for security protocols and implementations of those protocols. See section 3.8 for details. There are some security-related issues with the use of site-local access control discussed in sections 3.4 and 4.5 of this document. In particular, the use of a site-local address in a Mobile IPv6 home address option may cause security concerns if used in conjunction with site-local access control. Site-local access control may also be compromised by the use of site-local addresses inside any IP-in-IP tunnel that traverses network links that are not part of the site. Wasserman Expires September 2003 26 Impact of Site-Local Addressing in IPv6 March 2003 8 Change Log Changes since draft-wasserman-ipv6-sl-impact-00.txt: 26-Dec-02 Added section on Mobile IPv6 issues. Added further details on OSPF implementation issues based on SBR implementation experience reported on the IPv6 WG mailing list. Added real acknowledgements for review comments. Changes since draft-wasserman-ipv6-sl-impact-01.txt: 1-Jan-03 Added further details about "dummy site" requirements for BGP and IS-IS. Correctly identified SIP as a session layer protocol. 2-Jan-03 Added DNS issue regarding local caching resolvers. Clarified use of the term VPN in various sections. Added sections and initial information for site-local impacts on IPsec, key exchange and certificates. 3-Jan-03 Added section discussing the interaction between site-local access control and tunneling. Added details about the use of site-local addresses in security certificates. 2-Mar-03 Further enhanced security section. Removed recommendation from main document and included in appendix. Several changes based on mailing list feedback. Wasserman Expires September 2003 27 Impact of Site-Local Addressing in IPv6 March 2003 9 References 9.1 Normative References [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [ADDRARCH] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipngwg-addr-arch-v3-11.txt, October 2002. 9.2 Informative References [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [SCOPARCH] S. Deering, et. al, "IPv6 Scoped Address Architecture", draft- ietf-ipngwg-scoping-arch-04.txt, June 2002. [ADDRSEL] R. Draves, "Default Address Selection for IPv6", draft-ietf- ipv6-default-addr-select-09.txt, August 2002. [MIPV6] D. Johnson, et. al., "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-19.txt, October 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. [NATPT] G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000 Wasserman Expires September 2003 28 Impact of Site-Local Addressing in IPv6 March 2003 10 Acknowledgements This document reflects information and ideas obtained from many people over several years of discussing these issues. Thanks to the following people for providing constructive feedback regarding this document: Rob Austein, Steve Bellovin, Randy Bush, Russ Housley, Hiroki Ishibashi, Pekka Savola. The Mobile IPv6 section is largely based on IPv6 mailing list postings by Erik Nordmark. 11 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 12 Appendix A: "Limited Use" Proposal This appendix contains the author's recommendation for how the problems described in this document could be resolved. This solution has been referred to as the "limited use" proposal for limiting the use of site-local addresses, and it resolves all of the technical problems described in this document. It would require minor updates to IPv6 WG documents, and it would not require any effort within other WGs or areas. 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, DNS and Mobile IP. There are many 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 specifications and software that would be required to make site-local addressing 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 simpler, less problematic mechanisms. So, the author of this document recommends that IPv6 site-local addresses be reserved for use on isolated, single-site networks or behind NATs (either IPv4-to-IPv6 or IPv6-to-IPv6 NATs). Limiting the use of IPv6 site-local addresses in this fashion will eliminate Wasserman Expires September 2003 29 Impact of Site-Local Addressing in IPv6 March 2003 all of the complexities and issues associated with site-local addressing, and will still allow site-local addresses to be used in isolated, single-site networks or behind NATS, where global IPv6 prefixes may not be available. In particular, an update to the IPv6 Addressing Architecture [ADDRARCH] should be published indicating that site-local addresses are reserved for use on isolated, single-site networks, and that all implementations should treat site-local addresses exactly like global addresses. The Default Address Selection rules [ADDRSEL] should be updated to use site-local addresses only when global addresses are unavailable. Also, all mention of site-border nodes and all special handling of site-local addresses should be removed from the Scoped Address Architecture [SCOPARCH]. The Scoped Address Architecture should still be published, to explain the use of link-local unicast addresses and how address scopes work for IPv6 multicast. Wasserman Expires September 2003 30