idnits 2.17.1 draft-ietf-ipngwg-scoped-routing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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: 5 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 April 1999 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 and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents 17 as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet-Drafts as 22 reference material, or to cite them other than as a ``working draft'' 23 or ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document outlines a mechanism for generating routing tables that 34 include scoped IPv6 addresses. It defines a set of 35 rules for routers to implement in order to forward scoped unicast and 36 multicast addresses regardless of the routing protocol. It should be 37 noted that these rules will apply to all scoped addresses. 39 Contents 41 1. Introduction 1 43 2. Assumptions and Definitions 1 45 3. Single Site Routing 1 47 4. Site Boundary Unicast Routing 2 48 4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 2 49 4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 4 51 5. Scoped Multicast Routing 5 52 5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 5 53 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5 55 6. Protocol Impact 6 57 1. Introduction 59 This document defines a set of rules for the generation of forwarding 60 tables that contain scoped addresses. This document describes the 61 handling of scoped addresses for both single site and 62 site boundary routers. Ideally, these concepts should be included in 63 followup drafts of IPv6 routing protocols. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 66 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 67 this document are to be interpreted as described in [RFC 2119]. 69 2. Assumptions and Definitions 71 This document makes several assumptions concerning sites : 73 - Site boundaries cut through nodes 75 - Site boundaries are identical for unicast and multicast traffic 77 - A single interface can only be in one site 79 - Each interface participating in a site has a site identifier 81 - In the absence of explicit configuration, all site identifiers on 82 a node default to the same value 84 A single site router is defined as a router configured with the same 85 site identifier on all interfaces. A site boundary router is defined 86 as a router that has at least 2 distinct site identifiers configured. 87 This could include a router connected to 2 distinct sites or a router 88 connected to 1 site and a separate global network (Figure ??). 90 3. Single Site Routing 92 In a single site router, a routing protocol 93 can advertise and route all addresses and prefixes on all interfaces. 94 This configuration does not require any special handling for site 95 local addresses. The reception and transmission of site local 96 addresses is handled in the same manner as globally scoped addresses. 97 This applies to both unicast and multicast routing protocols. 99 * * 100 * * 101 * Site ID = X * 102 * * 103 * * 104 +-*---|--------|---*-+ 105 | * i/f 1 i/f 2 * | 106 | **************** | 107 | | 108 | | 109 | Router | 110 ***************** ******************* 111 | * * | 112 Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default 113 | * * | 114 ***************** ******************* 115 +--------------------+ 117 Figure 1: Multi-Sited Router 119 4. Site Boundary Unicast Routing 121 With respect to site boundaries, 122 routers must consider which interfaces a packet can be transmitted on 123 as well as control the propagation of routing information specific to 124 the site. This includes controlling which prefixes can be advertised 125 on an interface. 127 4.1. Routing Protocols 129 When a routing protocol determines that it is a site boundary router, 130 it must perform additional work in order to protect inter site 131 integrity and still maintain intra site connectivity. 133 In order to maintain connectivity, the routing protocol must be 134 able to create forwarding information for the global prefixes as well 135 as for all of the site prefixes for each of its attached sites. The 136 most straight forward way of doing this is to create up to (n + 1) 137 routing tables; one for the global prefixes, if any, and one for each 138 of the (n) sites. 140 To protect inter site integrity, routers must be selective in the 141 forwarding information that is shared with neighboring routers. 142 Routing protocols routinely transmit their routing information to 143 neighboring routers. When a router is transmitting this routing 144 information, it must not include any information about sites other 145 than the site defined on the interface used to reach a neighbor. 147 * * 148 * * 149 * Site ID = X * 150 * * 151 * * 152 +-*---|--------|---*-+ 153 | * i/f 1 i/f 2 * | 154 | **************** | 155 | | 156 | | 157 | Router | 158 ***************** ******************* 159 | * * | 160 Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default 161 | * * | 162 ***************** ******************* 163 +--------------------+ 165 i/f 1 : global prefix = 3FFE:20::/64 166 site prefix = FEC0:0:0:N/64 168 i/f 2 : no global prefix 169 site prefix = FEC0:0:0:K/64 171 i/f 3 : global prefix = 3FFE:40::/64 172 site prefix = FEC0:0:0:M/64 174 i/f 4 : global prefix = 3FFE:80::/64 175 no site prefix 177 Figure 2: Routing Information Exchange 179 As an example, the router in Figure ?? must advertise routing 180 information on four interfaces. The information advertised is as 181 follows : 183 - Interface 1 185 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 186 3FFE:80::/64) 188 * Site prefix FEC0:0:0:N/64 190 * Site prefix FEC0:0:0:K/64 192 - Interface 2 194 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 195 3FFE:80::/64) 197 * Site prefix FEC0:0:0:N/64 199 * Site prefix FEC0:0:0:K/64 201 - Interface 3 203 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 204 3FFE:80::/64) 206 * Site prefix FEC0:0:0:M/64 208 - Interface 4 210 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 211 3FFE:80::/64) 213 By imposing advertisement rules, site integrity is maintained by 214 keeping all site routing information contained within the site. 216 4.2. Packet Forwarding 218 In addition to the extra cost of generating additional 219 forwarding information for each site, site boundary routers must also 220 do some additional checking when forwarding packets that contain site 221 local addresses. 223 If a packet being forwarded contains a 224 site local destination address, regardless of the scope of the source 225 address, the router must perform the following : 227 - Lookup incoming interface's site identifier 228 - Perform route lookup for destination address in arrival 229 interfaces site scoped routing table 231 If a packet being forwarded contains a site local source 232 address and a globally scoped destination address, the following must 233 be performed : 235 - Lookup outgoing interface's site identifier 237 - Compare inbound and outbound interfaces' site identifiers 239 If the site identifiers match, the 240 packet can be forwarded. If they do not match, an ICMPv6 destination 241 unreachable message must be sent to the sender with a new code value, 242 code = 5 (Scope Mismatch). 243 This ICMPv6 message will indicate that the destination address is not 244 reachable with the specified source address. 246 5. Scoped Multicast Routing 248 With IPv6 multicast, there are multiple scopes 249 supported. Multicast routers must be able to control the propagation 250 of scoped packets based on administratively configured boundaries. 252 5.1. Routing Protocols 254 Multicast routing protocols must follow the same rules as the unicast 255 protocols. They will be required to maintain information about 256 global prefixes as well as information about all scope boundaries 257 that pass through the router. Multicast protocols that rely on 258 underlying unicast protocols (i.e. PIM) will not suffer as much of a 259 performance impact since the unicast protocol will handle the 260 forwarding table generation. They must be able to handle the 261 additional scope boundaries used in multicast addresses. Multicast 262 protocols that generate and 263 maintain their own routing tables will have to perform the additional 264 route calculations for scope. All multicast protocols will be forced 265 to handle 14 additional scoping identifiers above the site 266 identifiers supported in IPv6 unicast addresses. 268 5.2. Packet Forwarding 270 The forwarding rules for multicast can be described by the following 271 combinations : 273 - Global multicast destination address / Global unicast source 274 address 276 - Global multicast destination address / Site local unicast source 277 address 279 - Scoped multicast destination address / Global unicast source 280 address 282 - Scoped multicast destination address / Site local unicast source 283 address 285 The first combination requires no special 286 processing over what is currently in place for global IPv6 multicast. 287 Combinations 2,3, and 4 should result in the router performing the 288 same identifiers check as outlined for site local unicast addresses. 289 Since IPv6 supports fifteen unique multicast scopes, it is assumed 290 that scopes 0x1 through 0x4 are strictly less than 291 the unicast site scope, scope 0x5 (site) is equal to the unicast site 292 scope, scopes 0x6 through 0xd are strictly greater than the unicast 293 site scope and strictly less than the unicast global scope, and scope 294 0xe is equal to the unicast global scope. 296 6. Protocol Impact 298 The performance impact on routing protocols is obvious. 299 Routers implementing scoped address support will be forced to perform 300 an additional check in the main forwarding path to 301 determine if the source address is scoped. This will add overhead to 302 the processing of every packet flowing through the router. In 303 addition, there will be some storage overhead for 304 the scope identifiers. If scoped addresses are going to be realized, 305 this performance impact may be acceptable. 307 References 309 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 310 Requirement Levels", RFC 2119, BCP14, March 1997. 312 Security Considerations 314 This document specifies a set of guidelines that allow routers to 315 prevent site 316 specific information from leaking out of each site. If site boundary 317 routers allow site routing information to be forwarded outside of the 318 site, the integrity of the site could be compromised. 320 Acknowledgements 322 I would like to thank Thomas Narten, Steve Deering, and Erik Nordmark 323 for their comments and reviews of this document. 325 Author's Address 327 Brian Haberman 328 IBM Corporation 329 800 Park Office Drive 330 Research Triangle Park, NC 27709 331 USA 332 +1-919-254-2673 333 haberman@raleigh.ibm.com