INTERNET DRAFT Brian Haberman April 1998 IBM Routing of Site-Scoped Addresses in the Internet Protocol Version 6 (IPv6) Status of This Memo This document is an Internet-Draft. 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document outlines a mechanism for generating routing tables that include site-scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward site-scoped addresses regardless of the routing protocol. Haberman Expires October 1998 [Page i] Internet Draft Routing of Site-Scoped Addresses April 1998 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Assumptions and Definitions 2 3. Single Site Routing 3 4. Site-Boundary Unicast Routing 3 4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 3 4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5 5. Site-Boundary Multicast Routing 6 5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 6 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Impact 6 Haberman Expires October 1998 [Page ii] Internet Draft Routing of Site-Scoped Addresses April 1998 1. Introduction This document defines a set of rules for the generation of forwarding tables that contain site-scoped addresses. This document will describe the handling of site-scoped addresses for both single-site and site-boundary routers. Ideally, these concepts should be included in follow-up drafts of IPv6 routing protocols. A preferred model for site-boundaries is depicted in Figure 1. In this model, each router is responsible for generating forwarding information for the global prefixes and exactly 1 site. The link between the routers is in neither site. In addition, routing information about Site Y is never propogated into Site X and routing information about Site X is never propogated into Site Y. This model is similar to that of net 10 routing in IPv4. ***** ***** * * * * * * * Router 1 Router 2 * +-*-+ +-*-+ | * | | * | Site X | * | ----------------- | * | Site Y | * | | * | +-*-+ +-*-+ * * * * * * * * ***** ***** Figure 1: Site Boundary Model The rest of this document describes the modifications needed in order to combine the functions of Router 1 and Router 2 into a single router. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Haberman Expires October 1998 [Page 1] Internet Draft Routing of Site-Scoped Addresses April 1998 2. Assumptions and Definitions This document makes several assumptions concerning sites : - Site boundaries cut through nodes - Site boundaries are identical for unicast and multicast traffic - A single interface can only be in one site - Each interface participating in a site has a site identifier - In the absence of explicit configuration, all site identifiers on a router default to the same value - Routers only advertise site prefixes on interfaces configured with site identifiers and site prefixes * * * * * Site ID = X * * * * * +-*---|--------|---*-+ | * i/f 1 i/f 2 * | | **************** | | | | | | Router | ***************** | | * | Site ID = Y - i/f 3 * i/f 4 - | * | ***************** | +--------------------+ Figure 2: Multi-Sited Router A single-site router is defined as a router configured with the same site identifier on all interfaces. A site-boundary router is defined as a router that has at least 2 distinct site identifiers configured. This could include a router connected to 2 distinct sites or a router connected to 1 site and a separate global network (Figure 2). Haberman Expires October 1998 [Page 2] Internet Draft Routing of Site-Scoped Addresses April 1998 3. Single Site Routing In a single-site router, a routing protocol can advertise and route all addresses and prefixes on all interfaces. This configuration does not require any special handling for site-local addresses. The reception and transmission of site-local addresses is handled in the same manner as globally scoped addresses. This applies to both unicast and multicast routing protocols. 4. Site-Boundary Unicast Routing With respect to site boundaries, routers must consider which interfaces a packet can be transmitted on as well as control the propogation of site-specific routing information. This includes controlling which prefixes can be advertised on an interface and what forwarding information can be sent to other routers out that interface. 4.1. Routing Protocols When a routing protocol determines that it is a site-boundary router, it must perform additional work in order to protect inter-site integrity and still maintain intra-site connectivity. In order to maintain connectivity, the routing protocol must be able to create forwarding information for the global prefixes as well as for all of the site prefixes defined in the router's site identifiers. The most straight forward way of doing this is to create up to (n + 1) routing tables; one for the global prefixes, if any, and one for each of the (n) sites. This will increase the protocol processing time, but is necessary for connectivity within sites. To protect inter-site integrity, routers must be selective in the forwarding information that is shared with neighboring routers. Routing protocols routinely transmit their routing information to neighboring routers. When a router is transmitting this routing information, it must not include any information about sites other than the site defined on the interface used to reach a neighbor. As an example, the router in Figure 3 must advertise routing information on four interfaces. The information advertised is as follows : - Interface 1 Haberman Expires October 1998 [Page 3] Internet Draft Routing of Site-Scoped Addresses April 1998 * * * * * Site ID = X * * * * * +-*---|--------|---*-+ i/f 1 : global prefix = 3FFE:20::/64 | * i/f 1 i/f 2 * | site prefix = FEC0:0:0:N/64 | **************** | | | i/f 2 : no global prefix | | site prefix = FEC0:0:0:K/64 | Router | ***************** | i/f 3 : global prefix = 3FFE:40::/64 | * | site prefix = FEC0:0:0:M/64 Site ID = Y - i/f 3 * i/f 4 - | * | i/f 4 : global prefix = 3FFE:80::/64 ***************** | no site prefix +--------------------+ Figure 3: Routing Information Exchange * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:N/64 * Site prefix FEC0:0:0:K/64 - Interface 2 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:N/64 * Site prefix FEC0:0:0:K/64 - Interface 3 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:M/64 Haberman Expires October 1998 [Page 4] Internet Draft Routing of Site-Scoped Addresses April 1998 - Interface 4 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) By imposing advertisement rules, site integrity is maintained by keeping all site routing information contained within the site. 4.2. Packet Forwarding In addition to the extra cost of generating additional forwarding information for each site, site-boundary routers must also do some additional checking when forwarding packets that contain site-local addresses. If a packet being forwarded contains a site-local destination address, regardless of the scope of the source address, the router must perform the following : - Lookup incoming interface's site identifier - Perform route lookup for destination address - Lookup outgoing interface's site identifier - Verify that the two site identifiers match The last two steps are required due to the fact that the two interfaces could be in different sites but have identical site-local prefixes. If a packet being forwarded contains a site-local source address and a globally-scoped destination address, there are two possible ways of handling it. The first way is to forward the packet based solely on the destination address. This leads to the possibility that the destination cannot send a response. The second option is to perform the same checks as outlined above for a site-local destination address. If this method is chosen, a new ICMPv6 message could be returned to the sender indicating there is a scoping mismatch. This would allow the sender the chance to use a higher scoped address. Haberman Expires October 1998 [Page 5] Internet Draft Routing of Site-Scoped Addresses April 1998 5. Site-Boundary Multicast Routing 5.1. Routing Protocols Multicast routing protocols will have to follow the same rules as the unicast protocols. They will be required to maintain information about global prefixes as well as information about all sites defined on the box. Protocols that rely on underlying unicast protocols will not suffer as much of a performance impact since the unicast protocol will handle the forwarding table generation. However, multicast protocols that generate and maintain their own routing tables will have to perform the additional route calculations for each site. 5.2. Packet Forwarding The forwarding rules for multicast can be described by the following combinations : - Global multicast destination address / Global unicast source address - Global multicast destination address / Site-local unicast source address - Site-scoped multicast destination address / Global unicast source address - Site-scoped multicast destination address / Site-local unicast source address The first combination should follow the same forwarding mechanisms that are in place today for IPv4 multicast. Combinations 3 and 4 should result in the router performing the same site identifiers check as outlined for site-local unicast destination addresses. Combination 2 could be handled in either manner. By performing the site identifier check, a source could be notified that there is a scoping mismatch and give it the opportunity to choose a higher scoped source address. This would require the definition of a new scoping mismatch ICMPv6 message. 6. Protocol Impact The performance impact on routing protocols is obvious. However, this impact should only be felt by those routers that exist on site boundaries. Realistically, a router would probably only be a boundary between either two sites or a site Haberman Expires October 1998 [Page 6] Internet Draft Routing of Site-Scoped Addresses April 1998 and the Internet. If site-scoped addresses are going to be realized, this performance impact may be acceptable. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1997. Security Considerations This document specifies a set of guidelines that allow routers to prevent site specific information from leaking out of each site. If site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. Acknowledgements I would like to thank Thomas Narten for his reviews of this document. Author's Address Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA +1-919-254-2673 haberman@raleigh.ibm.com Haberman Expires October 1998 [Page 7]