idnits 2.17.1 draft-haberman-ipv6-site-route-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Brian Haberman 3 April 1998 IBM 5 Routing of Site-Scoped Addresses 6 in the Internet Protocol Version 6 (IPv6) 8 10 Status of This Memo 12 This document is an Internet-Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months, and may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as 20 reference material, or to cite them other than as a ``working draft'' 21 or ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 This document outlines a mechanism for generating 33 routing tables that include site-scoped IPv6 addresses. It defines a 34 set of rules for routers to implement in order to forward site-scoped 35 addresses regardless of the routing protocol. 37 Contents 39 Status of This Memo i 41 Abstract i 43 1. Introduction 1 45 2. Assumptions and Definitions 2 47 3. Single Site Routing 3 49 4. Site-Boundary Unicast Routing 3 50 4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 3 51 4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5 53 5. Site-Boundary Multicast Routing 6 54 5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 6 55 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 6 57 6. Protocol Impact 6 59 1. Introduction 61 This document defines a set of rules for the generation of forwarding 62 tables that contain site-scoped addresses. This 63 document will describe the handling of site-scoped addresses for both 64 single-site and site-boundary routers. Ideally, these concepts 65 should be included in follow-up drafts of IPv6 routing protocols. 67 A preferred model for site-boundaries is depicted in Figure 1. In 68 this model, each router is responsible for generating forwarding 69 information for the global prefixes and exactly 1 70 site. The link between the routers is in neither site. In addition, 71 routing information about Site Y is never propogated into Site X 72 and routing information about Site X is never propogated into Site Y. 73 This model is similar to that of net 10 routing in IPv4. 75 ***** ***** 76 * * 77 * * 78 * * 79 * Router 1 Router 2 * 80 +-*-+ +-*-+ 81 | * | | * | 82 Site X | * | ----------------- | * | Site Y 83 | * | | * | 84 +-*-+ +-*-+ 85 * * 86 * * 87 * * 88 * * 89 ***** ***** 91 Figure 1: Site Boundary Model 93 The rest of this document describes the modifications needed in 94 order to combine the functions of Router 1 and Router 2 into a single 95 router. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 98 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in [RFC 2119]. 101 2. Assumptions and Definitions 103 This document makes several assumptions concerning sites : 105 - Site boundaries cut through nodes 107 - Site boundaries are identical for unicast and multicast traffic 109 - A single interface can only be in one site 111 - Each interface participating in a site has a site identifier 113 - In the absence of explicit configuration, all site identifiers on 114 a router default to the same value 116 - Routers only advertise site prefixes on interfaces configured 117 with site identifiers and site prefixes 119 * * 120 * * 121 * Site ID = X * 122 * * 123 * * 124 +-*---|--------|---*-+ 125 | * i/f 1 i/f 2 * | 126 | **************** | 127 | | 128 | | 129 | Router | 130 ***************** | 131 | * | 132 Site ID = Y - i/f 3 * i/f 4 - 133 | * | 134 ***************** | 135 +--------------------+ 137 Figure 2: Multi-Sited Router 139 A single-site router is defined as a router configured with the same 140 site identifier on all interfaces. A site-boundary router is defined 141 as a router that has at least 2 distinct site identifiers configured. 142 This could include a router connected to 2 distinct sites or a router 143 connected to 1 site and a separate global network (Figure 2). 145 3. Single Site Routing 147 In a single-site router, a routing protocol 148 can advertise and route all addresses and prefixes on all interfaces. 149 This configuration does not require any special handling for 150 site-local addresses. The reception and transmission of site-local 151 addresses is handled in the same manner as globally scoped addresses. 152 This applies to both unicast and multicast routing protocols. 154 4. Site-Boundary Unicast Routing 156 With respect to site boundaries, routers must consider which 157 interfaces a packet can be transmitted on as well as control the 158 propogation of site-specific routing information. This 159 includes controlling which prefixes can be advertised on an interface 160 and what forwarding information can be sent to other routers out that 161 interface. 163 4.1. Routing Protocols 165 When a routing protocol determines that it is a site-boundary router, 166 it must perform additional work in order to protect inter-site 167 integrity and still maintain intra-site connectivity. 169 In order to maintain connectivity, the routing protocol must be 170 able to create forwarding information for the global prefixes as well 171 as for all of 172 the site prefixes defined in the router's site identifiers. The most 173 straight forward way of doing this is to create up to (n + 1) routing 174 tables; one for the global prefixes, if any, and one for each of the 175 (n) sites. This will increase the protocol processing time, but is 176 necessary for connectivity within sites. 178 To protect inter-site integrity, routers must be selective in the 179 forwarding information that is shared with neighboring routers. 180 Routing protocols routinely transmit their routing information to 181 neighboring routers. When a router is transmitting this routing 182 information, it must not include any information about sites other 183 than the site defined on the interface used to reach a neighbor. 185 As an 186 example, the router in Figure 3 must advertise routing information on 187 four interfaces. The information advertised is as follows : 189 - Interface 1 190 * * 191 * * 192 * Site ID = X * 193 * * 194 * * 195 +-*---|--------|---*-+ i/f 1 : global prefix = 3FFE:20::/64 196 | * i/f 1 i/f 2 * | site prefix = FEC0:0:0:N/64 197 | **************** | 198 | | i/f 2 : no global prefix 199 | | site prefix = FEC0:0:0:K/64 200 | Router | 201 ***************** | i/f 3 : global prefix = 3FFE:40::/64 202 | * | site prefix = FEC0:0:0:M/64 203 Site ID = Y - i/f 3 * i/f 4 - 204 | * | i/f 4 : global prefix = 3FFE:80::/64 205 ***************** | no site prefix 206 +--------------------+ 208 Figure 3: Routing Information Exchange 210 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 211 3FFE:80::/64) 213 * Site prefix FEC0:0:0:N/64 215 * Site prefix FEC0:0:0:K/64 217 - Interface 2 219 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 220 3FFE:80::/64) 222 * Site prefix FEC0:0:0:N/64 224 * Site prefix FEC0:0:0:K/64 226 - Interface 3 228 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 229 3FFE:80::/64) 231 * Site prefix FEC0:0:0:M/64 233 - Interface 4 235 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 236 3FFE:80::/64) 238 By imposing advertisement rules, site integrity is maintained by 239 keeping all site routing information contained within the site. 241 4.2. Packet Forwarding 243 In addition to the extra cost of generating additional forwarding 244 information for each site, site-boundary routers must 245 also do some additional checking when forwarding packets that contain 246 site-local addresses. 248 If a packet being forwarded contains a 249 site-local destination address, regardless of the scope of the source 250 address, the router must perform the following : 252 - Lookup incoming interface's site identifier 254 - Perform route lookup for destination address 256 - Lookup outgoing interface's site identifier 258 - Verify that the two site identifiers match 260 The last two steps are required due to 261 the fact that the two interfaces could be in different sites but have 262 identical site-local prefixes. 264 If a packet being forwarded contains a site-local source address and 265 a globally-scoped destination address, there are two possible ways of 266 handling it. The first way is to forward the packet based solely on 267 the destination address. This 268 leads to the possibility that the destination cannot send a response. 269 The second option is to perform the same checks as outlined above for 270 a site-local destination address. If this method is chosen, 271 a new ICMPv6 message could be returned to the sender indicating there 272 is a scoping mismatch. This would allow the sender the chance to use 273 a higher scoped address. 275 5. Site-Boundary Multicast Routing 277 5.1. Routing Protocols 279 Multicast routing protocols will have to follow the same rules as the 280 unicast protocols. They will be required to maintain information 281 about global prefixes as well as information about all sites defined 282 on the box. Protocols that rely on underlying unicast protocols will 283 not suffer as much of a performance impact since the unicast protocol 284 will handle the forwarding table generation. However, multicast 285 protocols that generate and maintain their own routing tables will 286 have to perform the additional route calculations for each site. 288 5.2. Packet Forwarding 290 The forwarding rules for multicast can be described by the following 291 combinations : 293 - Global multicast destination address / Global unicast source 294 address 296 - Global multicast destination address / Site-local unicast source 297 address 299 - Site-scoped multicast destination address / Global unicast source 300 address 302 - Site-scoped multicast destination address / Site-local unicast 303 source address 305 The first combination should follow the same forwarding mechanisms 306 that are in place today 307 for IPv4 multicast. Combinations 3 and 4 should result in the router 308 performing the same site identifiers check as outlined 309 for site-local unicast destination addresses. Combination 2 could be 310 handled in either manner. By performing the site identifier check, a 311 source could be notified that there is a scoping mismatch and give it 312 the opportunity to choose a higher scoped source address. This would 313 require the definition of a new scoping mismatch ICMPv6 message. 315 6. Protocol Impact 317 The performance impact on routing protocols is obvious. However, 318 this impact should only be felt by those routers that exist 319 on site boundaries. Realistically, a router would probably only be a 320 boundary between either two sites or a site 321 and the Internet. If site-scoped addresses are going to be realized, 322 this performance impact may be acceptable. 324 References 326 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 327 Requirement Levels", RFC 2119, BCP14, March 1997. 329 Security Considerations 331 This document specifies a set of guidelines that allow routers to 332 prevent site 333 specific information from leaking out of each site. If site boundary 334 routers allow site routing information to be forwarded outside of the 335 site, the integrity of the site could be compromised. 337 Acknowledgements 339 I would like to thank Thomas Narten for his reviews of this document. 341 Author's Address 343 Brian Haberman 344 IBM Corporation 345 800 Park Office Drive 346 Research Triangle Park, NC 27709 347 USA 348 +1-919-254-2673 349 haberman@raleigh.ibm.com