idnits 2.17.00 (12 Aug 2021) /tmp/idnits52862/draft-ietf-ipngwg-scoping-arch-00.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 11 longer pages, the longest (page 2) being 67 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 243 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Unused Reference: 'RFC 2460' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'ICMPv6' is defined on line 524, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'BASICAPI' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPNGWG Working Group S. Deering 3 Internet Draft Cisco Systems 4 draft-ietf-ipngwg-scoping-arch-00.txt B. Haberman 5 March 2000 Nortel Networks 6 Expires September 2000 B. Zill 7 Microsoft 9 IP Version 6 Scoped Address Architecture 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. Internet- 19 Drafts are draft documents valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet- Drafts as reference material or to cite 22 them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies the architectural characteristics, expected 33 behavior, and usage of IPv6 addresses of different scopes 35 1. Introduction 37 The Internet Protocol version 6 (IPv6) introduces the concept of 38 limited scope addresses to the IP lexicon. While operational practice 39 with IPv4 has included the concept of a private address space (net 10, 40 etc.), the design of IPv6 incorporates such addresses into its base 41 architecture. This document defines terms associated with such 42 addresses and describes mechanisms for their behavior. 44 Deering, Haberman, Zill 1 45 2. Definitions 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC 2119]. 51 3. Basic Terminology 53 The terms link, interface, node, host, and router are defined in [RFC 54 2460]. The definitions of unicast address scopes (link-local, site- 55 local, and global) and multicast address scopes (node-local, link- 56 local, etc.) are contained in [RFC 2373]. 58 4. Address Scope 60 Every IPv6 address has a specific scope, that is, a topological 61 "distance" within which the address may be used as a unique identifier 62 for an interface. The scope of an address is encoded as part of the 63 address, as specified in [RFC 2373]. 65 For unicast addresses, there are three defined scopes: 67 o Link-local scope, for uniquely identifying interfaces within 68 a single link only. 69 o Site-local scope, for uniquely identifying interfaces within 70 a single site only. A "site" is, by intent, not rigorously 71 defined, but is typically expected to cover a region of 72 topology that belongs to a single organization and is 73 located within a single geographic location, such as an 74 office, an office complex, or a campus. A personal 75 residence may be treated as a site (for example, when the 76 residence obtains Internet access via a public Internet 77 service provider), or as a part of a site (for example, when 78 the residence obtains Internet access via an employer's or 79 school's site). 80 o Global scope, for uniquely identifying interfaces anywhere 81 in the Internet. 83 For multicast addresses, there are fourteen possible scopes, ranging 84 from node-local to global (including both link-local and site-local). 85 A node-local multicast address serves as a unique identifier for an 86 interface within a single node only; such an address is used only for 87 "loopback" delivery of multicasts within a single node, for example, as 88 a form of inter-process communication within a computer. 90 There is an ordering relationship among scopes: 92 o for unicast scopes, link-local is a smaller scope than site- 93 local, and site-local is smaller scope than global. 94 o for multicast scopes, scopes with lesser values in the 95 "scop" subfield of the multicast address [RFC 2373, section 96 2.7] are smaller than scopes with greater values, with node- 97 local being the smallest and global being the largest. 99 However, two scopes of different size may cover the exact same region 100 of topology, for example, a site may consist of a single link, in which 102 Deering, Haberman, Zill 2 103 both link-local and site-local scope effectively cover the same 104 topological "distance". 106 5. Scope Zones 108 A scope zone, or a simply a zone, is a connected region of topology of 109 a given scope. For example, the set of links connected by routers 110 within a particular site, and the interfaces attached to those links, 111 comprise a single zone of site-local scope. To understand the 112 distinction between scopes and zones, observe that the topological 113 regions within two different sites are considered to be two DIFFERENT 114 zones, but of the SAME scope. 116 Addresses of a given (non-global) scope may be re-used in different 117 zones of that scope. The zone to which a particular non-global address 118 pertains is not encoded in the address itself, but rather is determined 119 by context, such as the interface from which it is sent or received. 121 Zones of the different scopes are defined as follows: 123 o A node-local zone (for multicast only) consists of a single 124 interface on a node. [Note: node-local scope would have 125 been more accurately named interface-local.] 126 o A link-local zone (for unicast and multicast) consists of a 127 single link and all the interfaces attached to that link. 128 o There is a single zone of global scope (for both unicast and 129 multicast), comprising all the links and interfaces in the 130 Internet. 131 o The boundaries of zones of scope other than node-local, 132 link-local, and global must be defined and configured by 133 network administrators. The only required such boundaries 134 are site boundaries. A site boundary serves for both 135 unicast and multicast. 137 Zone boundaries are relatively static features, not changing in 138 response to short-term changes in topology. Thus, the requirement that 139 the topology within a zone be "connected" is intended to include links 140 and interfaces that may be only occasionally connected. For example, a 141 residential node or network that obtains Internet access by dial-up to 142 an employer's site may be treated as part of the employer's site-local 143 zone even when the dial-up link is disconnected. Similarly, a failure 144 of a router, interface, or link that causes a zone to become 145 partitioned does not split that zone into multiple zones; rather, the 146 different partitions are still considered to belong to the same zone. 148 Zones have the following additional properties: 150 o Zone boundaries cut through nodes, not links. (There are 151 two exceptions: the global zone has no boundary, and the 152 boundary of a node-local zone conceptually cuts through an 153 interface between a node and a link.) 154 o Zones of the same scope cannot overlap, i.e., they can have 155 no links or interfaces in common. 156 o A zone of a given scope (less than global) falls completely 157 within zones of larger scope, i.e., a smaller scope zone 158 cannot include more topology than any larger scope zone with 159 which it shares any links or interfaces. 161 Deering, Haberman, Zill 3 162 Each interface belongs to one node-local zone, one link-local zone, one 163 site-local zone, and the global zone. Each link belongs to one link- 164 local zone, one site-local zone, and the global zone. An interface or 165 link only belongs to additional (i.e., multicast) zones if it falls 166 within the configured boundaries of such additional zones. 168 6. Zone Indexes 170 Because the same address of a given (non-global) scope can be re-used 171 in different zones of that scope, a node must have a means _- other 172 than examining the address itself _- of associating non-global 173 addresses with particular zones when sending, receiving, or forwarding 174 packets containing such addresses. This is accomplished by assigning a 175 local "zone index" to each zone to which a node is attached. Each 176 attached zone of the same scope must be assigned a different index 177 value; attached zones of different scopes can re-use the same index 178 values. 180 The assignment of zone indexes is illustrated in the example in the 181 figure below: 183 --------------------------------------------------------------- 184 | a node | 185 | | 186 | | 187 | | 188 | | 189 | | 190 | /--site1--\ /--------------site2--------------\ /--site3--\ | 191 | | 192 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 193 | | 194 | intf1 intf2 intf3 intf4 intf5 | 195 --------------------------------------------------------------- 196 : | | | | 197 : | | | | 198 : | | | | 199 the ================= a point- a 200 loopback an Ethernet to-point tunnel 201 link link 203 This example node has five interfaces: 205 o A loopback interface, which can be thought of as an 206 interface to a phantom link _- the "loopback link" _- that 207 goes nowhere, 208 o Two interfaces to the same Ethernet, 209 o An interface to a point-to-point link, and 210 o A tunnel interface (e.g., the abstract endpoint of an IPv6- 211 overIPv6 tunnel [TUNNEL], presumably established over either 212 the Ethernet or the point-to-point link.) 214 It is thus attached to five node-local zones, identified by the 215 interface indexes 1 through 5. 217 Deering, Haberman, Zill 4 218 Because the two Ethernet interfaces are attached to the same link, the 219 node is attached to only four link-local zones, identified by link 220 indexes 1 through 4. 222 It is attached to three site-local zones: one imaginary one to which 223 the loopback interface belongs, one to which the Ethernet and the 224 point-to-point link belong, and one to which the tunnel belongs 225 (perhaps because it is a tunnel to another organization). These site- 226 local zones are identified by the site indexes 1 through 3. 228 The zone indexes are strictly local to the node. For example, the node 229 on the other end of the point-to-point link may well be using entirely 230 different interface, link, and site index values for that link. 232 The zone index values are arbitrary. An implementation may use any 233 value it chooses to label a zone so long as it maintains the 234 requirement that the index value of each attached zone of the same 235 scope must be unique within the node. Implementations choosing to 236 follow the recommended basic API [BASICAPI] will also want to restrict 237 their index values to those that can be represented by the 238 sin6_scope_id field of a sockaddr_in6. 240 An implementation may also support the concept of a "default" zone for 241 each scope. It is convenient to reserve the index value zero, at each 242 scope, to mean "use the default zone". This default index can also be 243 used to identify the zone for any scopes for which the node has not 244 assigned any indexes, such as the various multicast-only scopes. 246 There is at present no way for a node to automatically determine which 247 of its interfaces belong to the same zones, e.g., the same link or the 248 same site. In the future, protocols may be developed to determine that 249 information. In the absence of such protocols, an implementation must 250 provide a means for manual assignment and/or reassignment of zone 251 indexes. Furthermore, to avoid the need to perform manual 252 configuration in most cases, an implementation should, by default, 253 initially assign zone indexes as follows: 255 o A unique interface index for each interface 256 o A unique link index for each interface 257 o A single site index for all interfaces 259 Then, manual configuration would be necessary only for the less common 260 cases of nodes with multiple interfaces to a single link, interfaces to 261 different sites, or interfaces to zones of different (multicast-only) 262 scopes. 264 7. Sending Packets 266 When an upper-layer protocol sends a packet to a non-global destination 267 address, the node must also identify the intended zone to be used for 268 transmission. 270 Note that there is one exception to the above statement: when sending 271 to the IPv6 unicast loopback address, ::1, there is no need to 272 identify the intended zone, even though that address is non-global. 273 Conceptually, the unicast loopback address is a link-local address for 274 a node's loopback interface, and is never assigned to any other 276 Deering, Haberman, Zill 5 277 interface. Therefore, it unambiguously identifies a single zone of 278 link-scope, that being the phantom loopback link. 280 Although identification of an outgoing interface is sufficient to 281 identify an intended zone (because each interface is attached to no 282 more than one zone of each scope), that is more specific than desired 283 in many cases. For example, when sending to a site-local unicast 284 address, from host that has more than one interface to the intended 285 site, the upper layer protocol may not care which of those interfaces 286 is used for the transmission, but rather would prefer to leave that 287 choice to the routing function in the IP layer. Thus, the upper-layer 288 requires the ability to specify a zone index, rather than an interface 289 index, when sending to a non-global, non-loopback destination address. 291 There may also be cases where the upper-layer wishes to restrict the 292 choice of outgoing interface to those belonging to a zone of smaller 293 scope than the destination address. For example, when sending to a 294 site-local destination, the upper-layer may wish to specify a specific 295 link on which the packet should be transmitted, but leave the choice of 296 which specific interface to use on that link to the IP layer. One 297 possible reason for such behavior is that the source address chosen by 298 the upper-layer is of smaller scope than the destination, e.g., when 299 using a link-local source address and a site-local destination address. 300 Thus, the upper layer requires the ability, when sending a packet, to 301 specify any zone of scope less than or equal to the scope of the 302 destination address, including the case in which the destination 303 address is of global scope. For this reason, an implementation might 304 find it useful to assign a distinct value for each zone index, so that 305 they are unique across all zones, regardless of scope. 307 8. Receiving Packets 309 When an upper-layer protocol receives a packet containing a non-global 310 source or destination address, the zone to which that address pertains 311 can be determined from the arrival interface, because the arrival 312 interface can attached to only one zone of the same scope as the 313 address under consideration. 315 9. Forwarding Rules and Routing 317 A single zone router is defined as a router configured with the same 318 zone index on all interfaces. A zone boundary router is defined as a 319 router that has at least 2 distinct zone indices of the same scope. 321 Deering, Haberman, Zill 6 322 * * 323 * * 324 * Site ID = X * 325 * * 326 +-*---|-------|---*-+ 327 | * i/f 1 i/f 2 * | 328 | *************** | 329 | | 330 | | 331 | Router | 332 ******************* ******************* 333 | * * | 334 Site ID = Y -i/f 3 * * i/f 4- Site ID = Default 335 | * * | 336 ******************* ******************* 337 +-------------------+ 339 Figure 1: Multi-Sited Router 341 9.1 Single Zone Routing Protocols 343 In a single zone router, a routing protocol can advertise all addresses 344 and prefixes, except the link-local prefixes, on all interfaces. This 345 configuration does not require any special handling for scoped 346 addresses. The reception and transmission of scoped addresses is 347 handled in the same manner as global addresses. This applies to both 348 unicast and multicast routing protocols. 350 9.2 Zone Boundary Unicast Routing 352 With respect to zone boundaries, routers must consider which interfaces 353 a packet can be transmitted on as well as control the propagation of 354 routing information specific to the zone. This includes controlling 355 which prefixes can be advertised on an interface. 357 9.2.1 Routing Protocols 359 When a routing protocol determines that it is a zone boundary router, 360 it must perform additional work in order to protect inter-zone 361 integrity and still maintain intra zone connectivity. 363 In order to maintain connectivity, the routing protocol must be able to 364 create forwarding information for the global prefixes as well as for 365 all of the zone prefixes for each of its attached sites. The most 366 straightforward way of doing this is to create up to (n+1) forwarding 367 tables; one for the global prefixes, if any, and one for each of the 368 (n) zones. 370 To protect inter zone integrity; routers must be selective in the 371 forwarding information that is shared with neighboring routers. 372 Routing protocols routinely transmit their routing information to its 373 neighboring routers. When a router is transmitting this routing 374 information, it must not include any information about zones other than 375 the zones defined on the interface used to reach a neighbor. 377 Deering, Haberman, Zill 7 378 As an example, the router in Figure 1 must advertise routing 379 information on four interfaces. The information advertised is as 380 follows: 382 - Interface 1 383 - All global prefixes 384 - All site prefixes learned from Interfaces 1 and 2 385 - Interface 2 386 - All global prefixes 387 - All site prefixes learned from Interfaces 1 and 2 388 - Interface 3 389 - All global prefixes 390 - All site prefixes learned from Interface 3 391 - Interface 4 392 - All global prefixes 393 - No site prefixes 395 By imposing advertisement rules, zone integrity is maintained by 396 keeping all zone routing information contained within the zone. 398 9.2.2 Packet Forwarding 400 In addition to the extra cost of generating additional forwarding 401 information for each zone, boundary routers must also do some 402 additional checking when forwarding packets that contain non-global 403 scoped addresses. 405 If a packet being forwarded contains a non-global destination address, 406 regardless of the scope of the source address, the router must perform 407 the following: 409 - Lookup incoming interface's zone index 410 - Perform route lookup for destination address in arrival 411 interface's zone scoped routing table 413 If a packet being forwarded contains a non-global source address and a 414 global scoped destination address, the following must be performed: 416 - Lookup outgoing interface's zone index 417 - Compare inbound and outbound interfaces' zone indices 419 If the zone indices match, the packet can be forwarded. If they do not 420 match, an ICMPv6 destination unreachable message must be sent to the 421 sender with a code value, code = 2 (beyond scope of source address). 423 Note that the above procedure applies for addresses of all scopes, 424 including link-local. Thus, if a router receives a packet with a link- 425 local destination address that is not one of the router's own link- 426 local addresses on the arrival link, the router is expected to try and 427 forward the packet to the destination on that link (subject to 428 successful determination of the destination's link-layer address via 429 the Neighbor Discovery protocol [ND]). The forwarded packet may be 430 transmitted back out the arrival interface or out any other interface 431 attached to the same link. 433 Deering, Haberman, Zill 8 434 9.3 Scoped Multicast Routing 436 With IPv6 multicast, there are multiple scopes supported. Multicast 437 routers must be able to control the propagation of scoped packets based 438 on administratively configured boundaries. 440 9.3.1 Routing Protocols 442 Multicast routing protocols must follow the same rules as the unicast 443 protocols. They will be required to maintain information about global 444 prefixes as well as information about all scope boundaries that exist 445 on the router. 447 Multicast protocols that rely on underlying unicast protocols for route 448 exchange (i.e. PIM, MOSPF) will not suffer as much of a performance 449 impact since the unicast protocol will handle the forwarding table 450 generation. They must be able to handle the additional scope 451 boundaries used in multicast addresses. 453 Multicast protocols that generate and maintain their own routing tables 454 will have to perform the additional route calculations for scope 455 boundaries. All multicast protocols will be forced to handle fourteen 456 additional scooping identifiers above the site identifiers supported in 457 IPv6 unicast addresses. 459 9.3.2 Packet Forwarding 461 The following combinations describe the forwarding rules for multicast: 463 - Global multicast destination / Global unicast source 464 - Global multicast destination / Non-global unicast source 465 - Non-global multicast destination / Global unicast source 466 - Non-global multicast destination / Non-global unicast source 468 The first combination requires no special processing over what is 469 currently in place for global IPv6 multicast. The remaining 470 combinations should result in the router performing the same zone index 471 check as outlined for the non-global unicast addresses 473 9.4 Routing Headers 475 A node that receives a packet addressed to itself and containing a 476 Routing Header with more than zero Segments Left [RFC 2460, section 477 4.4] swaps the original destination address with the next address in 478 the Routing Header. Then the above forwarding rules are applied, using 479 the new destination address. An implementation need not, indeed MUST 480 NOT, examine additional addresses in the Routing header to determine 481 whether they are crossing boundaries for their scopes. Thus, it is 482 possible, though generally inadvisable, to use a Routing Header to 483 convey a non-global address across its associated zone boundary. 485 10. Related Documents 487 The following list is a set of documents that are related to scoped 488 IPv6 addresses: 490 Deering, Haberman, Zill 9 491 o Site Prefixes in Neighbor Discovery, draft-ietf-ipngwg-site- 492 prefixes-03.txt 493 o An Extension of Format for IPv6 Scoped Addresses, draft- 494 ietf-ipngwg-scopedaddr-format-00.txt 495 o Default Address Selection for IPv6, draft-ietf-ipngwg- 496 default-addr-select-00.txt 498 11. Mobility 500 TBD 502 12. Security Considerations 504 The routing section of this document specifies a set of guidelines that 505 allow routers to prevent zone-specific information from leaking out of 506 each site. If site boundary routers allow site routing information to 507 be forwarded outside of the site, the integrity of the site could be 508 compromise 510 13. References 512 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 513 Requirement Levels", RFC 2119, BCP14, March 1999. 515 [RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing 516 Architecture", RFC 2373, July 1998. 518 [RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version 519 6 (IPv6) Specification", RFC 2460, December 1998. 521 [TUNNEL] Conta, A., and Deering, S., "Generic Packet Tunneling in 522 IPv6 Specification", RFC 2473, December 1998. 524 [ICMPv6] Conta, A., and Deering, S., "Internet Control Message 525 Protocol (ICMPv6) for Internet Protocol Version 6 526 (IPv6)", RFC 2463, December 1998. 528 [ND] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 529 Discovery for IP Version 6 (IPv6)", RFC 2461, December 530 1998. 532 [BASICAPI] 534 Acknowledgements 536 Authors' Addresses 538 Stephen E. Deering 539 Cisco Systems, Inc. 540 170 West Tasman Drive 541 San Jose, CA 95134-1706 542 USA 544 Deering, Haberman, Zill 10 545 Phone: +1-408-527-8213 546 Fax: +1-408-527-8213 547 Email: deering@cisco.com 549 Brian Haberman 550 Nortel Networks 551 4309 Emperor Blvd. 552 Suite 200 553 Durham, NC 27703 554 USA 556 Phone: +1-919-992-4439 557 Email: haberman@nortelnetworks.com 559 Brian D. Zill 560 Microsoft Research 561 One Microsoft Way 562 Redmond, WA 98052-6399 563 USA 565 Phone: +1-425-703-3568 566 Fax: +1-425-936-7329 567 Email: bzill@microsoft.com 569 Deering, Haberman, Zill 11