idnits 2.17.1 draft-ietf-ipngwg-scoped-routing-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-16) 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 7 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: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Brian Haberman 2 September 1998 IBM 4 Routing of Scoped Addresses 5 in the Internet Protocol Version 6 (IPv6) 7 9 Status of This Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as 19 reference material, or to cite them other than as a ``working draft'' 20 or ``work in progress.'' 22 To learn the current status of any Internet Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), ftp.isi.edu (US West Coast). 28 Abstract 30 This document outlines a mechanism for generating routing tables that 31 include scoped IPv6 addresses. It defines a set of 32 rules for routers to implement in order to forward scoped unicast and 33 multicast addresses regardless of the routing protocol. It should be 34 noted that these rules will apply to all scoped addresses. 36 Contents 38 1. Introduction 1 40 2. Assumptions and Definitions 1 42 3. Single Site Routing 1 44 4. Site Boundary Unicast Routing 2 45 4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 2 46 4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 4 48 5. Scoped Multicast Routing 5 49 5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 5 50 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5 52 6. Protocol Impact 6 54 1. Introduction 56 This document defines a set of rules for the generation of forwarding 57 tables that contain scoped addresses. This document describes the 58 handling of scoped addresses for both single site and 59 site boundary routers. Ideally, these concepts should be included in 60 followup drafts of IPv6 routing protocols. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 63 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 64 this document are to be interpreted as described in [RFC 2119]. 66 2. Assumptions and Definitions 68 This document makes several assumptions concerning sites : 70 - Site boundaries cut through nodes 72 - Site boundaries are identical for unicast and multicast traffic 74 - A single interface can only be in one site 76 - Each interface participating in a site has a site identifier 78 - In the absence of explicit configuration, all site identifiers on 79 a node default to the same value 81 A single site router is defined as a router configured with the same 82 site identifier on all interfaces. A site boundary router is defined 83 as a router that has at least 2 distinct site identifiers configured. 84 This could include a router connected to 2 distinct sites or a router 85 connected to 1 site and a separate global network (Figure 1). 87 3. Single Site Routing 89 In a single site router, a routing protocol 90 can advertise and route all addresses and prefixes on all interfaces. 91 This configuration does not require any special handling for site 92 local addresses. The reception and transmission of site local 93 addresses is handled in the same manner as globally scoped addresses. 94 This applies to both unicast and multicast routing protocols. 96 * * 97 * * 98 * Site ID = X * 99 * * 100 * * 101 +-*---|--------|---*-+ 102 | * i/f 1 i/f 2 * | 103 | **************** | 104 | | 105 | | 106 | Router | 107 ***************** ******************* 108 | * * | 109 Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default 110 | * * | 111 ***************** ******************* 112 +--------------------+ 114 Figure 1: Multi-Sited Router 116 4. Site Boundary Unicast Routing 118 With respect to site boundaries, 119 routers must consider which interfaces a packet can be transmitted on 120 as well as control the propagation of routing information specific to 121 the site. This includes controlling which prefixes can be advertised 122 on an interface. 124 4.1. Routing Protocols 126 When a routing protocol determines that it is a site boundary router, 127 it must perform additional work in order to protect inter site 128 integrity and still maintain intra site connectivity. 130 In order to maintain connectivity, the routing protocol must be 131 able to create forwarding information for the global prefixes as well 132 as for all of the site prefixes for each of its attached sites. The 133 most straight forward way of doing this is to create up to (n + 1) 134 routing tables; one for the global prefixes, if any, and one for each 135 of the (n) sites. 137 To protect inter site integrity, routers must be selective in the 138 forwarding information that is shared with neighboring routers. 139 Routing protocols routinely transmit their routing information to 140 neighboring routers. When a router is transmitting this routing 141 information, it must not include any information about sites other 142 than the site defined on the interface used to reach a neighbor. 144 * * 145 * * 146 * Site ID = X * 147 * * 148 * * 149 +-*---|--------|---*-+ 150 | * i/f 1 i/f 2 * | 151 | **************** | 152 | | 153 | | 154 | Router | 155 ***************** ******************* 156 | * * | 157 Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default 158 | * * | 159 ***************** ******************* 160 +--------------------+ 162 i/f 1 : global prefix = 3FFE:20::/64 163 site prefix = FEC0:0:0:N/64 165 i/f 2 : no global prefix 166 site prefix = FEC0:0:0:K/64 168 i/f 3 : global prefix = 3FFE:40::/64 169 site prefix = FEC0:0:0:M/64 171 i/f 4 : global prefix = 3FFE:80::/64 172 no site prefix 174 Figure 2: Routing Information Exchange 176 As an 177 example, the router in Figure 2 must advertise routing information on 178 four interfaces. The information advertised is as follows : 180 - Interface 1 182 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 183 3FFE:80::/64) 185 * Site prefix FEC0:0:0:N/64 187 * Site prefix FEC0:0:0:K/64 189 - Interface 2 191 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 192 3FFE:80::/64) 194 * Site prefix FEC0:0:0:N/64 196 * Site prefix FEC0:0:0:K/64 198 - Interface 3 200 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 201 3FFE:80::/64) 203 * Site prefix FEC0:0:0:M/64 205 - Interface 4 207 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 208 3FFE:80::/64) 210 By imposing advertisement rules, site integrity is maintained by 211 keeping all site routing information contained within the site. 213 4.2. Packet Forwarding 215 In addition to the extra cost of generating additional 216 forwarding information for each site, site boundary routers must also 217 do some additional checking when forwarding packets that contain site 218 local addresses. 220 If a packet being forwarded contains a 221 site local destination address, regardless of the scope of the source 222 address, the router must perform the following : 224 - Lookup incoming interface's site identifier 225 - Perform route lookup for destination address in arrival 226 interfaces site scoped routing table 228 If a packet being forwarded contains a site local source 229 address and a globally scoped destination address, the following must 230 be performed : 232 - Lookup outgoing interface's site identifier 234 - Compare inbound and outbound interfaces' site identifiers 236 If the site identifiers match, the 237 packet can be forwarded. If they do not match, an ICMPv6 destination 238 unreachable message must be sent to the sender with a new code value, 239 code = 5 (Scope Mismatch). 240 This ICMPv6 message will indicate that the destination address is not 241 reachable with the specified source address. 243 5. Scoped Multicast Routing 245 With IPv6 multicast, there are multiple scopes 246 supported. Multicast routers must be able to control the propagation 247 of scoped packets based on administratively configured boundaries. 249 5.1. Routing Protocols 251 Multicast routing protocols will have to follow the same rules as the 252 unicast protocols. They will be required to maintain information 253 about global prefixes as well as information about all scope 254 boundaries that pass through the router. Multicast protocols 255 that rely on underlying unicast protocols (i.e. PIM) will not suffer 256 as much of a performance impact since the unicast protocol will 257 handle the forwarding table generation. They must be able to handle 258 the additional scope boundaries used in multicast addresses. 259 Multicast protocols that generate and 260 maintain their own routing tables will have to perform the additional 261 route calculations for scope. All multicast protocols will be forced 262 to handle 14 additional scoping identifiers above the site 263 identifiers supported in IPv6 unicast addresses. 265 5.2. Packet Forwarding 267 The forwarding rules for multicast can be described by the following 268 combinations : 270 - Global multicast destination address / Global unicast source 271 address 273 - Global multicast destination address / Site local unicast source 274 address 276 - Scoped multicast destination address / Global unicast source 277 address 279 - Scoped multicast destination address / Site local unicast source 280 address 282 The first combination requires no special 283 processing over what is currently in place for global IPv6 multicast. 284 Combinations 2,3, and 4 should result in the router performing the 285 same identifiers check as outlined for site local unicast addresses. 286 Since IPv6 supports fifteen unique multicast scopes, it is assumed 287 that scopes 0x1 through 0x4 are strictly less than 288 the unicast site scope, scope 0x5 (site) is equal to the unicast site 289 scope, scopes 0x6 through 0xd are strictly greater than the unicast 290 site scope and strictly less than the unicast global scope, and scope 291 0xe is equal to the unicast global scope. 293 6. Protocol Impact 295 The performance impact on routing protocols is obvious. 296 Routers implementing scoped address support will be forced to perform 297 an additional check in the main forwarding path to 298 determine if the source address is scoped. This will add overhead to 299 the processing of every packet flowing through the router. In 300 addition, there will be some storage overhead for 301 the scope identifiers. If scoped addresses are going to be realized, 302 this performance impact may be acceptable. 304 References 306 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 307 Requirement Levels", RFC 2119, BCP14, March 1997. 309 Security Considerations 311 This document specifies a set of guidelines that allow routers to 312 prevent site 313 specific information from leaking out of each site. If site boundary 314 routers allow site routing information to be forwarded outside of the 315 site, the integrity of the site could be compromised. 317 Acknowledgements 319 I would like to thank Thomas Narten, Steve Deering, and Erik Nordmark 320 for their comments and reviews of this document. 322 Author's Address 324 Brian Haberman 325 IBM Corporation 326 800 Park Office Drive 327 Research Triangle Park, NC 27709 328 USA 329 +1-919-254-2673 330 haberman@raleigh.ibm.com