idnits 2.17.1 draft-ietf-ipngwg-scoping-arch-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 667 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 6 instances of too long lines in the document, the longest one being 3 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) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2553 (Obsoleted by RFC 3493) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPNGWG Working Group S. Deering 2 Internet Draft Cisco Systems 3 draft-ietf-ipngwg-scoping-arch-01.txt B. Haberman 4 March 2000 Nortel Networks 5 Expires September 2000 B. Zill 6 Microsoft 8 IP Version 6 Scoped Address Architecture 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite 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 specifies the architectural characteristics, expected 32 behavior, and usage of IPv6 addresses of different scopes 34 1. Introduction 36 The Internet Protocol version 6 (IPv6) introduces the concept of 37 limited scope addresses to the IP lexicon. While operational 38 practice with IPv4 has included the concept of a private address 39 space (net 10, etc.), the design of IPv6 incorporates such addresses 40 into its base architecture. This document defines terms associated 41 with such addresses and describes mechanisms for their behavior. 43 Deering, Haberman, Zill 1 44 2. Definitions 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in [RFC 2119]. 50 3. Basic Terminology 52 The terms link, interface, node, host, and router are defined in 53 [RFC 2460]. The definitions of unicast address scopes (link-local, 54 site-local, and global) and multicast address scopes (node-local, 55 link-local, etc.) are contained in [RFC 2373]. 57 4. Address Scope 59 Every IPv6 address has a specific scope, that is, a topological 60 "distance" within which the address may be used as a unique 61 identifier for an interface. The scope of an address is encoded as 62 part of the address, as specified in [RFC 2373]. 64 For unicast addresses, there are three defined scopes: 66 o Link-local scope, for uniquely identifying interfaces 67 within a single link only. 69 o Site-local scope, for uniquely identifying interfaces 70 within a single site only. A "site" is, by intent, not 71 rigorously defined, but is typically expected to cover a 72 region of topology that belongs to a single organization 73 and is located within a single geographic location, such 74 as an 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, 78 when the residence obtains Internet access via an 79 employer's or school's site). 81 o Global scope, for uniquely identifying interfaces 82 anywhere in the Internet. 84 For multicast addresses, there are fourteen possible scopes, ranging 85 from node-local to global (including both link-local and site- 86 local). A node-local multicast address serves as a unique 87 identifier for an interface within a single node only; such an 88 address is used only for "loopback" delivery of multicasts within a 89 single node, for example, as a form of inter-process communication 90 within a computer. 92 Deering, Haberman, Zill 2 93 There is an ordering relationship among scopes: 95 o for unicast scopes, link-local is a smaller scope than 96 site-local, and site-local is a smaller scope than 97 global. 99 o for multicast scopes, scopes with lesser values in the 100 "scop" subfield of the multicast address [RFC 2373, 101 section 2.7] are smaller than scopes with greater values, 102 with node-local being the smallest and global being the 103 largest. 105 However, two scopes of different size may cover the exact same 106 region of topology, for example, a site may consist of a single 107 link, in which both link-local and site-local scope effectively 108 cover the same topological "distance". 110 5. Scope Zones 112 A scope zone, or a simply a zone, is a connected region of topology 113 of a given scope. For example, the set of links connected by 114 routers within a particular site, and the interfaces attached to 115 those links, comprise a single zone of site-local scope. To 116 understand the distinction between scopes and zones, observe that 117 the topological regions within two different sites are considered to 118 be two DIFFERENT zones, but of the SAME scope. 120 Addresses of a given (non-global) scope may be re-used in different 121 zones of that scope. The zone to which a particular non-global 122 address pertains is not encoded in the address itself, but rather is 123 determined by context, such as the interface from which it is sent 124 or received. 126 Zones of the different scopes are defined as follows: 128 o A node-local zone (for multicast only) consists of a 129 single interface on a node. [Note: node-local scope 130 would have been more accurately named interface-local.] 132 o A link-local zone (for unicast and multicast) consists of 133 a single link and all the interfaces attached to that 134 link. 136 o There is a single zone of global scope (for both unicast 137 and multicast), comprising all the links and interfaces 138 in the Internet. 140 o The boundaries of zones of scope other than node-local, 141 link-local, and global must be defined and configured by 142 network administrators. The only required such 144 Deering, Haberman, Zill 3 145 boundaries are site boundaries. A site boundary serves 146 for both unicast and multicast. 148 Zone boundaries are relatively static features, not changing in 149 response to short-term changes in topology. Thus, the requirement 150 that the topology within a zone be "connected" is intended to 151 include links and interfaces that may be only occasionally 152 connected. For example, a residential node or network that obtains 153 Internet access by dial-up to an employer's site may be treated as 154 part of the employer's site-local zone even when the dial-up link is 155 disconnected. Similarly, a failure of a router, interface, or link 156 that causes a zone to become partitioned does not split that zone 157 into multiple zones; rather, the different partitions are still 158 considered to belong to the same zone. 160 Zones have the following additional properties: 162 o Zone boundaries cut through nodes, not links. (There are 163 two exceptions: the global zone has no boundary, and the 164 boundary of a node-local zone conceptually cuts through 165 an interface between a node and a link.) 167 o Zones of the same scope cannot overlap, i.e., they can 168 have no links or interfaces in common. 170 o A zone of a given scope (less than global) falls 171 completely within zones of larger scope, i.e., a smaller 172 scope zone cannot include more topology than any larger 173 scope zone with which it shares any links or interfaces. 175 Each interface belongs to one node-local zone, one link-local zone, 176 one site-local zone, and the global zone. Each link belongs to one 177 link-local zone, one site-local zone, and the global zone. An 178 interface or link only belongs to additional (i.e., multicast) zones 179 if it falls within the configured boundaries of such additional 180 zones. 182 6. Zone Indices 184 Because the same address of a given (non-global) scope can be re- 185 used in different zones of that scope, a node must have a means -- 186 other than examining the address itself -- of associating non-global 187 addresses with particular zones when sending, receiving, or 188 forwarding packets containing such addresses. This is accomplished 189 by assigning a local "zone index" to each zone to which a node is 190 attached. Each attached zone of the same scope must be assigned a 191 different index value; attached zones of different scopes can re-use 192 the same index values. 194 Deering, Haberman, Zill 4 195 The assignment of zone indices is illustrated in the example in the 196 figure below: 198 --------------------------------------------------------------- 199 | a node | 200 | | 201 | | 202 | | 203 | | 204 | | 205 | /--site1--\ /--------------site2--------------\ /--site3--\ | 206 | | 207 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 208 | | 209 | intf1 intf2 intf3 intf4 intf5 | 210 --------------------------------------------------------------- 211 : | | | | 212 : | | | | 213 : | | | | 214 the ================= a point- a 215 loopback an Ethernet to-point tunnel 216 link link 218 Figure 1 : Zone Indices Example 220 This example node has five interfaces: 222 o A loopback interface, which can be thought of as an 223 interface to a phantom link -- the "loopback link" -- 224 that goes nowhere, 226 o Two interfaces to the same Ethernet, 228 o An interface to a point-to-point link, and 230 o A tunnel interface (e.g., the abstract endpoint of an 231 IPv6-over-IPv6 tunnel [RFC 2473], presumably established 232 over either the Ethernet or the point-to-point link.) 234 It is thus attached to five node-local zones, identified by the 235 interface indices 1 through 5. 237 Because the two Ethernet interfaces are attached to the same link, 238 the node is attached to only four link-local zones, identified by 239 link indices 1 through 4. 241 It is attached to three site-local zones: one imaginary one to which 242 the loopback interface belongs, one to which the Ethernet and the 243 point-to-point link belong, and one to which the tunnel belongs 244 (perhaps because it is a tunnel to another organization). These 245 site-local zones are identified by the site indices 1 through 3. 247 Deering, Haberman, Zill 5 248 The zone indices are strictly local to the node. For example, the 249 node on the other end of the point-to-point link may well be using 250 entirely different interface, link, and site index values for that 251 link. 253 The zone index values are arbitrary. An implementation may use any 254 value it chooses to label a zone as long as it maintains the 255 requirement that the index value of each attached zone of the same 256 scope must be unique within the node. Implementations choosing to 257 follow the recommended basic API [RFC 2553] will also want to 258 restrict their index values to those that can be represented by the 259 sin6_scope_id field of a sockaddr_in6. 261 An implementation may also support the concept of a "default" zone 262 for each scope. It is convenient to reserve the index value zero, 263 at each scope, to mean "use the default zone". This default index 264 can also be used to identify the zone for any scopes for which the 265 node has not assigned any indices, such as the various multicast- 266 only scopes. 268 There is at present no way for a node to automatically determine 269 which of its interfaces belongs to the same zones, e.g., the same 270 link or the same site. In the future, protocols may be developed to 271 determine that information. In the absence of such protocols, an 272 implementation must provide a means for manual assignment and/or 273 reassignment of zone indices. Furthermore, to avoid the need to 274 perform manual configuration in most cases, an implementation 275 should, by default, initially assign zone indices as follows: 277 o A unique interface index for each interface 279 o A unique link index for each interface 281 o A single site index for all interfaces 283 Then, manual configuration would be necessary only for the less 284 common cases of nodes with multiple interfaces to a single link, 285 interfaces to different sites, or interfaces to zones of different 286 (multicast-only) scopes. 288 7. Sending Packets 290 When an upper-layer protocol sends a packet to a non-global 291 destination address, the node must also identify the intended zone 292 to be used for transmission. 294 Deering, Haberman, Zill 6 295 Note that there is one exception to the above statement: when 296 sending to the IPv6 unicast loopback address, ::1, there is no 297 need to identify the intended zone, even though that address is 298 non-global. Conceptually, the unicast loopback address is a link- 299 local address for a node's loopback interface, and is never 300 assigned to any other interface. Therefore, it unambiguously 301 identifies a single zone of link-scope, that being the phantom 302 loopback link. 304 Although identification of an outgoing interface is sufficient to 305 identify an intended zone (because each interface is attached to no 306 more than one zone of each scope), that is more specific than 307 desired in many cases. For example, when sending to a site-local 308 unicast address, from a node that has more than one interface to the 309 intended site, the upper layer protocol may not care which of those 310 interfaces is used for the transmission, but rather would prefer to 311 leave that choice to the routing function in the IP layer. Thus, 312 the upper-layer requires the ability to specify a zone index, rather 313 than an interface index, when sending to a non-global, non-loopback 314 destination address. 316 There may also be cases where the upper-layer wishes to restrict the 317 choice of outgoing interface to those belonging to a zone of smaller 318 scope than the destination address. For example, when sending to a 319 site-local destination, the upper-layer may wish to specify a 320 specific link on which the packet should be transmitted, but leave 321 the choice of which specific interface to use on that link to the IP 322 layer. One possible reason for such behavior is that the source 323 address chosen by the upper-layer is of smaller scope than the 324 destination, e.g., when using a link-local source address and a 325 site-local destination address. Thus, the upper layer requires the 326 ability, when sending a packet, to specify any zone of scope less 327 than or equal to the scope of the destination address, including the 328 case in which the destination address is of global scope. For this 329 reason, an implementation might find it useful to assign a distinct 330 value for each zone index, so that they are unique across all zones, 331 regardless of scope. 333 (Authors' note to selves: Think about distinct values 334 for default at each scope level.) 336 8. Receiving Packets 338 When an upper-layer protocol receives a packet containing a non- 339 global source or destination address, the zone to which that address 340 pertains can be determined from the arrival interface, because the 341 arrival interface can attached to only one zone of the same scope as 342 the address under consideration. 344 Deering, Haberman, Zill 7 345 9. Forwarding 347 When a router receives a packet addressed to a node other than 348 itself, it must take the zone of the destination and source 349 addresses into account as follows: 351 o The zone of the destination address is determined by the 352 scope of the address and arrival interface of the packet. 353 The next-hop interface is chosen by looking up the 354 destination address in a (conceptual) routing table 355 specific to that zone. That routing table is restricted 356 to refer only to interfaces belonging to that zone. 358 o After the next-hop interface is chosen, the zone of the 359 source address is considered. As with the destination 360 address, the zone of the source address is determined by 361 the scope of the address and arrival interface of the 362 packet. If transmitting the packet on the chosen next- 363 hop interface would cause the packet to leave the zone of 364 the source address, i.e., cross a zone boundary of the 365 scope of the source address, then the packet is discarded 366 and an ICMP Destination Unreachable message [RFC 2463] 367 with Code 2 ("beyond scope of source address") is sent to 368 the source of the packet. 370 Note that the above procedure applies for addresses of all scopes, 371 including link-local. Thus, if a router receives a packet with a 372 link-local destination address that is not one of the router's own 373 link-local addresses on the arrival link, the router is expected to 374 try to forward the packet to the destination on that link (subject 375 to successful determination of the destination's link-layer address 376 via the Neighbor Discovery protocol [RFC 2461]). The forwarded 377 packet may be transmitted back out the arrival interface, or out any 378 other interface attached to the same link. 380 A node that receives a packet addressed to itself and containing a 381 Routing Header with more than zero Segments Left [RFC 2460, section 382 4.4] swaps the original destination address with the next address in 383 the Routing Header. Then the above forwarding rules are applied, 384 using the new destination address. An implementation MUST NOT 385 examine additional addresses in the Routing header to determine 386 whether they are crossing boundaries for their scopes. Thus, it is 387 possible, though generally inadvisable, to use a Routing Header to 388 convey a non-global address across its associated zone boundary. 390 10. Routing 392 When a routing protocol determines that it is operating on a zone 393 boundary, it MUST protect inter-zone integrity and maintain intra- 394 zone connectivity. 396 Deering, Haberman, Zill 8 397 In order to maintain connectivity, the routing protocol must be able 398 to create forwarding information for the global prefixes as well as 399 for all of the zone prefixes for each of its attached zones. The 400 most straightforward way of doing this is to create (conceptual) 401 forwarding tables for each specific zone. 403 To protect inter-zone integrity routers must be selective in the 404 prefix information that is shared with neighboring routers. Routers 405 routinely exchange routing information with neighboring routers. 406 When a router is transmitting this routing information, it must not 407 include any information about zones other than the zones assigned to 408 the interface used to transmit the information. 410 * * 411 * * 412 * ----------- Site ID = X * 413 * | | * 414 +-*---|-------|-----+ * 415 | * i/f 1 i/f 2 | * 416 | * | * 417 | * i/f 5 - * 418 | ******************************* 419 | | 420 | Router | 421 ******************* ******************* 422 | * * | 423 Site ID = Y - i/f 3 * * i/f 4 - Site ID = Z 424 | * * | 425 ******************* ******************* 426 +-------------------+ 428 Figure 2: Multi-Sited Router 430 As an example, the router in Figure 2 must exchange routing 431 information on five interfaces. The information exchanged is as 432 follows: 434 o Interface 1 436 o All global prefixes 438 o All site prefixes learned from Interfaces 1, 2, and 5 440 o Interface 2 442 o All global prefixes 444 o All site prefixes learned from Interfaces 1, 2, and 5 446 Deering, Haberman, Zill 9 447 o Interface 3 449 o All global prefixes 451 o All site prefixes learned from Interface 3 453 o Interface 4 455 o All global prefixes 457 o All site prefixes learned from Interface 4 459 o Interface 5 461 o All global prefixes 463 o All site prefixes learned from Interfaces 1, 2, and 5 465 By imposing route exchange rules, zone integrity is maintained by 466 keeping all zone-specific routing information contained within the 467 zone. 469 11. Related Documents 471 The following list is a set of documents that are related to IPv6 472 address scope: 474 o Site Prefixes in Neighbor Discovery, draft-ietf-ipngwg- 475 site-prefixes-03.txt 477 o An Extension of Format for IPv6 Scoped Addresses, draft- 478 ietf-ipngwg-scopedaddr-format-00.txt 480 o Default Address Selection for IPv6, draft-ietf-ipngwg- 481 default-addr-select-00.txt 483 o Basic Socket Interface Extensions for IPv6, RFC 2553 485 o Advanced Sockets API for IPv6, draft-ietf-ipngwg- 486 rfc2292bis-01.txt 488 12. Mobility 490 TBD 492 13. Textual Representation 494 TBD 496 Deering, Haberman, Zill 10 497 14. Security Considerations 499 The routing section of this document specifies a set of guidelines 500 that allow routers to prevent zone-specific information from leaking 501 out of each site. If site boundary routers allow site routing 502 information to be forwarded outside of the site, the integrity of 503 the site could be compromise 505 15. References 507 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 508 Requirement Levels", RFC 2119, BCP14, March 1999. 510 [RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing 511 Architecture", RFC 2373, July 1998. 513 [RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version 514 6 (IPv6) Specification", RFC 2460, December 1998. 516 [RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in 517 IPv6 Specification", RFC 2473, December 1998. 519 [RFC 2463] Conta, A., and Deering, S., "Internet Control Message 520 Protocol (RFC 2463) for Internet Protocol Version 6 521 (IPv6)", RFC 2463, December 1998. 523 [RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 524 Discovery for IP Version 6 (IPv6)", RFC 2461, December 525 1998. 527 [RFC 2553] Gilligan, R., Thomson, S., Bound, J., and Stevens, W., 528 "Basic Socket Interface Extensions for IPv6", RFC 2553, 529 March 1999. 531 Acknowledgements 533 Authors' Addresses 535 Stephen E. Deering 536 Cisco Systems, Inc. 537 170 West Tasman Drive 538 San Jose, CA 95134-1706 539 USA 541 Phone: +1-408-527-8213 542 Fax: +1-408-527-8213 544 Deering, Haberman, Zill 11 545 Email: deering@cisco.com 547 Brian Haberman 548 Nortel Networks 549 4309 Emperor Blvd. 550 Suite 200 551 Durham, NC 27703 552 USA 554 Phone: +1-919-992-4439 555 Email: haberman@nortelnetworks.com 557 Brian D. Zill 558 Microsoft Research 559 One Microsoft Way 560 Redmond, WA 98052-6399 561 USA 563 Phone: +1-425-703-3568 564 Fax: +1-425-936-7329 565 Email: bzill@microsoft.com 567 Deering, Haberman, Zill 12