idnits 2.17.00 (12 Aug 2021) /tmp/idnits33906/draft-ietf-ipngwg-scoped-routing-03.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 66 lines 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 85 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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.) -- The document date (August 2000) is 7942 days in the past. Is this intentional? 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: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPNGWG Working Group B. Haberman 2 Internet Draft Nortel Networks 3 draft-ietf-ipngwg-scoped-routing-03.txt 4 February 2000 5 Expires August 2000 7 Routing of Scoped Addresses 8 in the Internet Protocol Version 6 (IPv6) 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet- Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document outlines a mechanism for generating forwarding tables 32 that include scoped IPv6 addresses. It defines a set of rules for 33 routers to implement in order to forward packets addressed to scoped 34 unicast or multicast addresses regardless of the routing protocol. 35 These rules apply to all scoped addresses. 37 1. Introduction 39 This document defines a set of rules for the generation of forwarding 40 table entries for scoped addresses. These rules will describe the 41 handling of scoped addresses for both single site and site boundary 42 routers. These rules apply to all routing protocols that support IPv6 43 addresses. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in [RFC 2119]. 49 2. Assumptions and Definitions 51 This document makes several assumptions concerning sites: 53 - Links belong to at most one site 54 - Interfaces belong to the site of the attached link, if any 56 Haberman 1 57 - Nodes are a part of all sites which their interfaces belong to, 58 and no other sites 59 - Site boundaries are identical for unicast and multicast traffic 60 - A single interface can be in at most one site 61 - Each interface participating in a site has a site identifier 62 - In the absence of explicit configuration, all site identifiers on 63 a node default to the same value 65 A single site router is defined as a router configured with the same 66 site identifier on all interfaces. A site boundary router is defined 67 as a router that has at least 2 distinct site identifiers. 69 * * 70 * * 71 * Site ID = X * 72 * * 73 +-*---|-------|---*-+ 74 | * i/f 1 i/f 2 * | 75 | *************** | 76 | | 77 | | 78 | Router | 79 ******************* ******************* 80 | * * | 81 Site ID = Y -i/f 3 * * i/f 4- Site ID = Default 82 | * * | 83 ******************* ******************* 84 +-------------------+ 86 Figure 1: Multi-Sited Router 88 3. Single Site Routing 90 In a single site router, a routing protocol can advertise and route all 91 addresses and prefixes, except the link-local prefixes, on all 92 interfaces. This configuration does not require any special handling 93 for site local addresses. The reception and transmission of site local 94 addresses is handled in the same manner as globally scoped addresses. 95 This applies to both unicast and multicast routing protocols. 97 4. Site Boundary Unicast Routing 99 With respect to site boundaries, routers must consider which interfaces 100 a packet can be transmitted on as well as control the propagation of 101 routing information specific to the site. This includes controlling 102 which prefixes can be advertised on an interface. 104 4.1 Routing Protocols 106 When a routing protocol determines that it is a site boundary router, 107 it must perform additional work in order to protect inter site 108 integrity and still maintain intra site connectivity. 110 Haberman 2 111 In order to maintain connectivity, the routing protocol must be able to 112 create forwarding information for the global prefixes as well as for 113 all of the site prefixes for each of its attached sites. The most 114 straightforward way of doing this is to create up to (n+1) forwarding 115 tables; one for the global prefixes, if any, and one for each of the 116 (n) sites. 118 To protect inter site integrity; routers must be selective in the 119 forwarding information that is shared with neighboring routers. 120 Routing protocols routinely transmit their routing information to its 121 neighboring routers. When a router is transmitting this routing 122 information, it must not include any information about sites other than 123 the site defined on the interface used to reach a neighbor. 125 As an example, the router in Figure 1 must advertise routing 126 information on four interfaces. The information advertised is as 127 follows: 129 - Interface 1 130 - All global prefixes 131 - All site prefixes learned from Interfaces 1 and 2 132 - Interface 2 133 - All global prefixes 134 - All site prefixes learned from Interfaces 1 and 2 135 - Interface 3 136 - All global prefixes 137 - All site prefixes learned from Interface 3 138 - Interface 4 139 - All global prefixes 140 - No site prefixes 142 By imposing advertisement rules, site integrity is maintained by 143 keeping all site routing information contained within the site. 145 4.2 Packet Forwarding 147 In addition to the extra cost of generating additional forwarding 148 information for each site, site boundary routers must also do some 149 additional checking when forwarding packets that contain site local 150 addresses. 152 If a packet being forwarded contains a site local destination address, 153 regardless of the scope of the source address, the router must perform 154 the following: 156 - Lookup incoming interface's site identifier 157 - Perform route lookup for destination address in arrival 158 interface's site scoped routing table 160 If a packet being forwarded contains a site local source address and a 161 global scoped destination address, the following must be performed: 163 - Lookup outgoing interface's site identifier 164 - Compare inbound and outbound interfaces' site identifiers 166 If the site identifiers match, the packet can be forwarded. If they do 167 not match, an ICMPv6 destination unreachable message must be sent to 169 Haberman 3 170 the sender with a code value, code = 2 (beyond scope of source 171 address). 173 5. Scoped Multicast Routing 175 With IPv6 multicast, there are multiple scopes supported. Multicast 176 routers must be able to control the propagation of scoped packets based 177 on administratively configured boundaries. 179 5.1 Routing Protocols 181 Multicast routing protocols must follow the same rules as the unicast 182 protocols. They will be required to maintain information about global 183 prefixes as well as information about all scope boundaries that exist 184 on the router. 186 Multicast protocols that rely on underlying unicast protocols for route 187 exchange (i.e. PIM, MOSPF) will not suffer as much of a performance 188 impact since the unicast protocol will handle the forwarding table 189 generation. They must be able to handle the additional scope 190 boundaries used in multicast addresses. 192 Multicast protocols that generate and maintain their own routing tables 193 will have to perform the additional route calculations for scope 194 boundaries. All multicast protocols will be forced to handle fourteen 195 additional scooping identifiers above the site identifiers supported in 196 IPv6 unicast addresses. 198 5.2 Packet Forwarding 200 The following combinations describe the forwarding rules for multicast: 202 - Global multicast destination / Global unicast source 203 - Global multicast destination / Site local unicast source 204 - Scoped multicast destination / Global unicast source 205 - Scoped multicast destination / Site local unicast source 207 The first combination requires no special processing over what is 208 currently in place for global IPv6 multicast. The remaining 209 combinations should result in the router performing the same 210 identifiers check as outlined for the site local unicast addresses. 211 Since IPv6 multicast supports fifteen unique multicast scopes, it is 212 assumed that scopes 0x1 through 0x4 are strictly less than the unicast 213 site scope, scope 0x5 (site) is equal to the unicast site scope, scopes 214 0x6 through 0xd are strictly greater than the unicast site scope and 215 strictly less than the unicast global scope, and scope 0xe is equal to 216 the unicast global scope. 218 6. Protocol Impact 220 The performance impact on routing protocols is obvious. Routers 221 implementing scoped address support will be forced to perform an 222 additional check in the main forwarding path to determine if the source 223 address is a site-local address. This will add overhead to the 224 processing of every packet flowing through the router. This overhead 226 Haberman 4 227 is no different than the overhead occurred in checking for invalid 228 source addresses such as multicast addresses, the loopback address, and 229 the unspecified address, which is a required function in IPv6. In 230 addition, there will be storage overhead for the scope identifiers and 231 the forwarding tables that must be maintained for each site. 233 7. Security Considerations 235 This document specifies a set of guidelines that allow routers to 236 prevent site-specific information from leaking out of each site. If 237 site boundary routers allow site routing information to be forwarded 238 outside of the site, the integrity of the site could be compromised. 240 8. References 242 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 243 Requirement Levels", RFC 2119, BCP14, March 1999. 245 Acknowledgements 247 The author would like to thank Thomas Narten, Steve Deering, Erik 248 Nordmark, Matt Crawford, and Jim Bound for their comments and reviews of 249 this document. 251 Haberman 5 252 Author's Address 254 Brian Haberman 255 Nortel Networks 256 4309 Emperor Blvd. 257 Suite 200 258 Durham, NC 27703 259 1-919-992-4439 260 Email : haberman@nortelnetworks.com 262 Haberman 6