INTERNET-DRAFT R. Hinden, Nokia February 28, 2003 Moderate Use Case for IPv6 Site-Local Addresses Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This internet draft expires on August 28, 2003. Abstract This internet draft describes the moderate use case for IPv6 Site- Local Addresses. 1.0 Introduction This internet draft describes the Moderate use case for IPv6 Site- Local addresses. Site-Local addresses are defined in the IPv6 Addressing Architecture [ADDARCH]. The IPv6 working group has been discussing what is the appropriate use scenario for IPv6 Site-Local addresses. The draft describes a possible scenario. The Moderate use case for IPv6 Site-Local addresses allows Site-Local addresses to be used inside of a site for services and applications that prefer to use Site-Local addresses for communication inside of draft-hinden-ipv6-sl-moderate-01.txt [Page 1] INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003 the site. Sites may use site-local addresses concurrently with global routable addresses or may use them exclusively if they are disconnected from the Internet and do not have any IPv6 global routable addresses. The moderate use scenario limits site-local usage to cases where site-local addresses are purposely enabled and configured by an administrator. Site-local addresses will not be used if the source and destination hosts could have used global addresses instead. The moderate use scenario document includes approaches for keeping site-local addresses and DNS names inside of a site, site border router issues, site-local uniqueness issues, and changes and/or extensions to existing IPv6 documents. 2.0 Acknowledgments The author would like to thank Andrew White, Bob Fink, Hiroki Ishibashi, Juha Wiljakka Pekka Savola, Rich Draves, Rob Austein, and Tony Hain for their comments and suggestions on this document. 3.0 Site Definition The document doesn't attempt to define a site in exact terms. A site is a set of associated subnets. Sites do not overlap each other. Sites typically range from home or small office to a campus of a large organization. In most cases the site boundary is where there is an administrative or geographic boundary such as where the connection to an ISP is or a campus in a specific geographic location. In many IPv6 transition scenarios an IPv6 over IPv4 tunnel will be created at the edge of a site. In routing protocol terms this is where typically there is an IGP/EGP boundary or between areas in an IGP like OSPF. 4.0 Site-Local Moderate Use Scenario The moderate use scenario for IPv6 site-local addresses allows for the use of site-local addresses concurrently with global IPv6 addresses. The use of site-local addresses is limited to cases where an administrator has configured hosts and services to use them. They will not be used if the source and destination hosts could have used global addresses instead. The motivation for this use case is to restrict the use of site-local addresses to communication inside of the site and insure that they draft-hinden-ipv6-sl-moderate-01.txt [Page 2] INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003 are very unlikely to be used for any site to site communication. Using limited scope addresses for site to site communication, while possible (i.e., via tunneling or VPN technologies), is problematic and makes it hard to debug problems. Overall it is simpler to use global addresses. 4.1 Site-Local Address Assignment IPv6 site-local addresses, like global scope unicast addresses, are only assigned to nodes if their use has been enabled (via IPv6 address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and configured in the DNS. They are not created automatically the way that IPv6 link-local addresses are and will not appear or be used unless they are purposely configured. In order for hosts to autoconfigure site-local addresses routers have to be configured to advertise site-local /64 prefixes in router advertisements. Likewise, a DHCPv6 server must have been configured to assign them. In order for a node to learn the site-local address of another node, the Site-local address must have been installed in the DNS. For these reasons, it is straight forward to control their usage in a site. To limit the use of site-local addresses the following guidelines apply: - Nodes that are to only be reachable inside of a site, the local DNS should be configured to only include the site-local addresses of these nodes. Nodes with only site-local addresses must not be installed in the global DNS. - Nodes that are to be limited to only communicate with other nodes in the site should be set to only autoconfigure site-local addresses via [ADDAUTO] or to only receive site-local addresses via [DHCP6]. Note: For the case where both global and site- local prefixes are being advertised on a subnet, this will require a switch in the devices to only autoconfigure site-local addresses. See section 5.1 for more details on this. - Nodes that are to be reachable from inside of the site and outside of the site, the DNS should be configured to include the global addresses of these nodes. The local DNS may be configured to also include the site-local addresses of these nodes. - Nodes that can communicate with other nodes inside of the site and outside of the site, should autoconfigure global addresses draft-hinden-ipv6-sl-moderate-01.txt [Page 3] INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003 via [ADDAUTO] or receive global address via [DHCP6]. They may also obtain site-local addresses via the same mechanisms. 4.2 Site Local Address Selection In order for nodes to limit their use of site-locals to specific configured cases the following address selection rules are needed: - If the destination only has a site-local address, the source should prefer to use a site-local source address. - If the destination only has a global address, the source should prefer to use a global source address. - If a source has a site-local and global addresses, and the destination has site-local and global addresses, the source should use the global address as the source address and use the global address of the destination as the destination address. Note, this is a change to IPv6 Default Address Selection. See section 5.2 for details of these changes. 4.3 Site Border Router Filtering It is important to keep any packets with site-local source or destination addresses from leaking outside of the site and to keep any site-local prefixes from being advertised outside of their site. There are two cases to implement this filtering requirements: Site- Border routers and firewalls. 4.3.1 Site Border Routers Site border routers must install a black hole route for the Site- Local prefix FEC0::/10. This will insure that packets with Site- Local destination addresses will not be forwarded outside of the site via a default route. Site border routers must not forward any packets with site-local source or destination addresses outside of the site. This requires a filter to be installed in the site-border router. A simple approach to creating a site border router is to allow an draft-hinden-ipv6-sl-moderate-01.txt [Page 4] INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003 interface to be configured in a "no site" site. If an interface is in the "no site" site, then the router will not forward any packets with site-local source and/or destination addresses to or from this interface. If BGP is being used at the site border with an ISP, filters must be installed in the BGP configuration to keep any site-local prefixes from being advertised outside of the site or for site-local prefixes to be learned from another site. 4.3.2 Firewalls Firewalls are commonly used in IPv4 to create site boundaries and are sometimes used to limit the scope of IPv4 addresses. This includes filtering packets with private IPv4 source or destination addresses. If IPv6 firewalls are used to connect the site to other sites (including ISPs), then the firewall must install filters to drop packets with site-local source and/or destination addresses to keep them from entering or exiting the site. 4.4 Routing Site-local addresses should be routed inside the site just like any other unicast addresses. They can be carried in any IPv6 routing protocol without any change. It is expected that an instance of an IGP routing protocols will be run inside of a single site. Any routing protocol that is used between sites is required to filter out any incoming or outgoing site-local routes. For example, if BGP is being used at the site border with an ISP, filters must be installed in the BGP configuration to keep any site-local prefixes from being advertised outside of the site or for site-local prefixes to be learned from another site. 4.5 DNS Naming Issues Site-Local addresses must not be installed in the global DNS. They may be installed in a naming system local to the site or kept separate from the global DNS using techniques such as "two-faced" DNS. Approaches for doing this are common in the IPv4 Internet today. draft-hinden-ipv6-sl-moderate-01.txt [Page 5] INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003 4.6 Site-Local Uniqueness Issues Site-local addresses as defined in [ADDARCH] all share a common prefix (i.e., FEC0::/10). There is a potential for confusion if packets containing these type of address were to escape the site. Due to the the way that addresses are autoconfigured in IPv6 with IPv6 IPv6 autoconfiguration [ADDAUTO] is very unlikely that two complete 128-bit site-local addresses would ever conflict with each other. It is unlikely to be a problem in practice. This is also true if temporary address were created using the privacy extensions defined in [PRIV]. IPv6 addresses created manually or with stateful methods such as [DHCP6] might have some potential for conflict. For this reason it is preferable to only create IPv6 site-local addresses with [ADDAUTO] or [PRIV]. 5.0 Changes and Extensions to Existing Specifications 5.1 IPv6 Node Requirements Nodes that are to intended to have the capability to be limited to only communicate with other nodes inside of the site (e.g., no global communication) should include a switch that has a site-only setting. This could be a software configuration or a hardware toggle switch for simple appliances. Support for multi-sited nodes is not required. Routers that are designed to be used at site borders should implement the "no site" site and firewalls should support site border filtering. 5.2 Default Address Selection TBD [Document changes to default address selection] 6.0 Security Considerations TBD draft-hinden-ipv6-sl-moderate-01.txt [Page 6] INTERNET-DRAFT Moderate Usage of IPv6 Site-Local Addresses January 2003 REFERENCES [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing Architecture", Internet Draft, , October 2002. [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998. [DEFAULT] Draves, R., "Default Address Selection for IPv6", Internet Draft, , November 2002. [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, BCP00009, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP14, March 1997. [PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" RFC3041, January 2001. AUTHOR'S ADDRESS Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA phone: +1 650 625-2004 email: hinden@iprg.nokia.com draft-hinden-ipv6-sl-moderate-01.txt [Page 7]