idnits 2.17.00 (12 Aug 2021) /tmp/idnits55709/draft-ietf-ipngwg-scoping-arch-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 59 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 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 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 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 874, but no explicit reference was found in the text == Outdated reference: draft-ietf-ipngwg-addr-arch-v3 has been published as 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) == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-ipngwg-rfc2553bis has been published as RFC 3493 ** Downref: Normative reference to an Informational draft: draft-ietf-ipngwg-rfc2553bis (ref. 'BASICAPI') ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 2 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-03.txt B. Haberman 5 November 2001 No Affiliation 6 Expires May 2002 T. Jinmei 7 Toshiba 8 E. Nordmark 9 Sun Microsystems 10 A. Onoe 11 Sony 12 B. Zill 13 Microsoft 15 IPv6 Scoped Address Architecture 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies the architectural characteristics, expected 39 behavior, textual representation, and usage of IPv6 addresses of 40 different scopes. 42 1. Introduction 44 Internet Protocol version 6 includes support for addresses of 45 different "scope", that is, both global and non-global (e.g., link- 46 local, site-local, etc.) addresses. While non-global addressing has 47 been introduced operationally in the IPv4 Internet, both in the use 48 of private address space ("net 10", etc.) and with administratively 49 scoped multicast addresses, the design of IPv6 formally incorporates 51 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 1 52 the notion of address scope into its base architecture. This 53 document specifies the architectural characteristics, expected 54 behavior, textual representation, and usage of IPv6 addresses of 55 different scopes. 57 2. Definitions 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC 2119]. 63 3. Basic Terminology 65 The terms link, interface, node, host, and router are defined in [RFC 66 2460]. The definitions of unicast address scopes (link-local, site- 67 local, and global) and multicast address scopes (interface-local, 68 link-local, etc.) are contained in [ADDRARCH]. 70 4. Address Scope 72 Every IPv6 address has a specific scope, that is, a topological span 73 within which the address may be used as a unique identifier for an 74 interface or set of interfaces. The scope of an address is encoded 75 as part of the address, as specified in [ADDRARCH]. 77 For unicast addresses, there are three defined scopes: 79 o Link-local scope, for uniquely identifying interfaces 80 within (i.e., attached to) a single link only. 82 o Site-local scope, for uniquely identifying interfaces 83 within a single site only. A "site" is, by intent, not 84 rigorously defined, but is typically expected to cover a 85 region of topology that belongs to a single organization 86 and is located within a single geographic location, such 87 as an office, an office complex, or a campus. A personal 88 residence may be treated as a site (for example, when the 89 residence obtains Internet access via a public Internet 90 service provider), or as a part of a site (for example, 91 when the residence obtains Internet access via an 92 employer's or school's site). 94 o Global scope, for uniquely identifying interfaces anywhere 95 in the Internet. 97 The IPv6 unicast loopback address, ::1, is treated as having link- 98 local scope within an imaginary link to which a virtual "loopback 99 interface" is attached. 101 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 2 102 Anycast addresses [ADDRARCH] are allocated from the unicast address 103 space and have the same scope properties as unicast addresses. All 104 statements in this document regarding unicast apply equally to 105 anycast. 107 For multicast addresses, there are fourteen possible scopes, ranging 108 from interface-local to global (including both link-local and site- 109 local). The interface-local scope spans a single interface only; a 110 multicast address of interface-local scope is useful only for 111 loopback delivery of multicasts within a single node, for example, as 112 a form of inter-process communication within a computer. Unlike the 113 unicast loopback address, interface-local multicast addresses may be 114 assigned to any interface. 116 There is a size relationship among scopes: 118 o for unicast scopes, link-local is a smaller scope than 119 site-local, and site-local is a smaller scope than global. 121 o for multicast scopes, scopes with lesser values in the 122 "scop" subfield of the multicast address [ADDRARCH, 123 section 2.7] are smaller than scopes with greater values, 124 with interface-local being the smallest and global being 125 the largest. 127 However, two scopes of different size may cover the exact same region 128 of topology. For example, a site may consist of a single link, in 129 which both link-local and site-local scope effectively cover the same 130 topological span. 132 5. Scope Zones 134 A scope zone, or a simply a zone, is a connected region of topology 135 of a given scope. For example, the set of links connected by routers 136 within a particular site, and the interfaces attached to those links, 137 comprise a single zone of site-local scope. Note that a zone is a 138 particular instance of a topological region (e.g., Alice's site or 139 Bob's site), whereas a scope is the size of a topological region 140 (i.e., a site or a link or a ...). 142 The zone to which a particular non-global address pertains is not 143 encoded in the address itself, but rather is determined by context, 144 such as the interface from which it is sent or received. Thus, 145 addresses of a given (non-global) scope may be re-used in different 146 zones of that scope. For example, Alice's site and Bob's site may 147 each contain a node with site-local address fec0::1. 149 Zones of the different scopes are instantiated as follows: 151 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 3 152 o Each interface on a node comprises a single zone of 153 interface-local scope (for multicast only). 155 o Each link, and the interfaces attached to that link, 156 comprises a single zone of link-local scope (for both 157 unicast and multicast). 159 o There is a single zone of global scope (for both unicast 160 and multicast), comprising all the links and interfaces in 161 the Internet. 163 o The boundaries of zones of scope other than interface- 164 local, link-local, and global must be defined and 165 configured by network administrators. A site boundary 166 serves as such for both unicast and multicast. 168 Zone boundaries are relatively static features, not changing in 169 response to short-term changes in topology. Thus, the requirement 170 that the topology within a zone be "connected" is intended to include 171 links and interfaces that may be only occasionally connected. For 172 example, a residential node or network that obtains Internet access 173 by dial-up to an employer's site may be treated as part of the 174 employer's site-local zone even when the dial-up link is 175 disconnected. Similarly, a failure of a router, interface, or link 176 that causes a zone to become partitioned does not split that zone 177 into multiple zones; rather, the different partitions are still 178 considered to belong to the same zone. 180 Zones have the following additional properties: 182 o Zone boundaries cut through nodes, not links. (Note that 183 the global zone has no boundary, and the boundary of an 184 interface-local zone encloses just a single interface.) 186 o Zones of the same scope cannot overlap, i.e., they can 187 have no links or interfaces in common. 189 o A zone of a given scope (less than global) falls 190 completely within zones of larger scope, i.e., a smaller 191 scope zone cannot include more topology than any larger 192 scope zone with which it shares any links or interfaces. 194 o Each zone is required to be "convex" from a routing 195 perspective, i.e., packets sent from one interterface to 196 any other interface in the same zone are never routed 197 outside the zone. 199 Each interface belongs to exactly one zone of each possible scope. 201 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 4 202 6. Zone Indices 204 Considering the fact that the same non-global address may be in use 205 in more than one zone of the same scope (e.g., the use of site-local 206 address fec0::1 in both Alice's site and Bob's site), and that a node 207 may have interfaces attached to different zones of the same scope 208 (e.g., having one interface attached to Alice's site and another to 209 Bob's site), a node requires an internal means of identifying to 210 which zone a non-global address belongs. This is accomplished by 211 assigning, within the node, a distinct "zone index" to each zone of 212 the same scope to which that node is attached, and allowing all 213 internal uses of an address to be qualified by a zone index. 215 The assignment of zone indices is illustrated in the example in the 216 figure below: 218 --------------------------------------------------------------- 219 | a node | 220 | | 221 | | 222 | | 223 | | 224 | | 225 | /--------------------site1--------------------\ /--site2--\ | 226 | | 227 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 228 | | 229 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 230 --------------------------------------------------------------- 231 : | | | | 232 : | | | | 233 : | | | | 234 (imaginary ================= a point- a 235 loopback an Ethernet to-point tunnel 236 link) link 238 Figure 1 : Zone Indices Example 240 This example node has five interfaces: 242 o A loopback interface to the imaginary loopback link (a 243 phantom link that goes nowhere), 245 o Two interfaces to the same Ethernet, 247 o An interface to a point-to-point link, and 249 o A tunnel interface (e.g., the abstract endpoint of an 250 IPv6-over-IPv6 tunnel [RFC 2473], presumably established 251 over either the Ethernet or the point-to-point link.) 253 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 5 254 It is thus attached to five interface-local zones, identified by the 255 interface indices 1 through 5. 257 Because the two Ethernet interfaces are attached to the same link, 258 the node is attached to only four link-local zones, identified by 259 link indices 1 through 4. 261 It is attached to two site-local zones: one to which the loopback 262 link, the Ethernet, and the point-to-point link belong, and one to 263 which the tunnel belongs (perhaps because it is a tunnel to another 264 organization). These site-local zones are identified by the site 265 indices 1 and 2. 267 Note that each attached zone of the same scope must be assigned a 268 different index value, whereas attached zones of different scopes can 269 re-use the same index. 271 The zone indices are strictly local to the node. For example, the 272 node on the other end of the point-to-point link may well be using 273 entirely different interface, link, and site index values for that 274 link. 276 An implementation should also support the concept of a "default" zone 277 for each scope. It is convenient to reserve the index value zero, at 278 each scope, to mean "use the default zone". This default index can 279 also be used as the zone qualifier for an address for which the node 280 is attached to only one zone, e.g., when using global addresses. 282 There is at present no way for a node to automatically determine 283 which of its interfaces belong to the same zones, e.g., the same link 284 or the same site. In the future, protocols may be developed to 285 determine that information. In the absence of such protocols, an 286 implementation must provide a means for manual assignment and/or 287 reassignment of zone indices. Furthermore, to avoid the need to 288 perform manual configuration in most cases, an implementation should, 289 by default, initially assign zone indices as follows, and only as 290 follows: 292 o A unique interface index for each interface 294 o A unique link index for each interface 296 o A unique subnet (multicast "scop" value 3) index for each 297 interface 299 Then, manual configuration would be necessary only for the less 300 common cases of nodes with multiple interfaces to a single link or a 301 single subnet, interfaces to different sites, or interfaces to zones 302 of different (multicast-only) scopes. 304 Thus, the default zone index assignments for the example node from 305 Figure 1 would be as illustrated in Figure 2, below. Manual 307 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 6 308 configuration would then be required to, for example, assign the same 309 link index to the two Ethernet interfaces as shown in Figure 1. 311 --------------------------------------------------------------- 312 | a node | 313 | | 314 | | 315 | | 316 | | 317 | | 318 | /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ | 319 | | 320 | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | 321 | | 322 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 323 --------------------------------------------------------------- 324 : | | | | 325 : | | | | 326 : | | | | 327 (imaginary ================= a point- a 328 loopback an Ethernet to-point tunnel 329 link) link 331 Figure 2 : Example of Default Zone Indices 333 As well as initially assigning zone indices, as specified above, an 334 implementation should automatically select a default zone for each 335 scope for which there is more than one choice, to be used whenever an 336 address is specified without a zone index (or with a zone index of 337 zero). For instance, in the example shown in Figure 2, the 338 implementation might automatically select intf2, link2, and subnet2 339 as the default zones for each of those three scopes. (Perhaps the 340 selection algorithm is to choose the first zone that includes an 341 interface other than the loopback interface as the default for each 342 scope.) A means must also be provided for manually assigning the 343 default zone for a scope, overriding any automatic assignment. 345 Because the unicast loopback address, ::1, may not be assigned to any 346 interface other than the loopback interface, it is recommended that 347 whenever ::1 is specified without a zone index, or with the default 348 zone index, that it be interpreted as belonging to the loopback link- 349 local zone, regardless of which link-local zone has been selected as 350 the default. If this is done, then in the common case of nodes with 351 only a single non-loopback interface (e.g., a single Ethernet 352 interface), it becomes possible to avoid any need to qualify link- 353 local addresses with a zone index: the unqualified address ::1 would 354 always refer to the link-local zone containing the loopback 355 interface, and all other unqualified link-local addresses would refer 356 to the link-local zone containing the non-loopback interface (as long 357 as the default link-local zone were set to be the zone containing the 358 non-loopback interface). 360 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 7 361 Because of the requirement that a zone of a given scope fall 362 completely within zones of larger scope (see section 5, above), if 363 two interfaces are assigned to different zones of scope S, they must 364 also be assigned to different zones of all scopes smaller than S. 365 Thus, the manual assignment of distinct zone indices for one scope 366 may require the automatic assignment of distinct zone indices for 367 smaller scopes. For example, the manual assignment of distinct site- 368 local indices 1 and 2 in the node in Figure 1 would cause the 369 automatic creation of corresponding admin-local (i.e. multicast 370 "scop" value 4) indices 1 and 2, because admin-local scope is smaller 371 than site-local scope. 373 Taking all of the above considerations in account, the complete set 374 of zone indices for our example node from Figure 1 is shown in Figure 375 3, below. 377 --------------------------------------------------------------- 378 | a node | 379 | | 380 | | 381 | | 382 | | 383 | | 384 | /--------------------site1--------------------\ /--site2--\ | 385 | | 386 | /-------------------admin1--------------------\ /-admin2--\ | 387 | | 388 | /-subnet1-\ /-------subnet2-------\ /-subnet3-\ /-subnet4-\ | 389 | | 390 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 391 | | 392 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 393 --------------------------------------------------------------- 394 : | | | | 395 : | | | | 396 : | | | | 397 (imaginary ================= a point- a 398 loopback an Ethernet to-point tunnel 399 link) link 401 Figure 3 : Complete Zone Indices Example 403 Although the examples above show the zones being assigned index 404 values sequentially, starting at one, the zone index values are 405 arbitrary. An implementation may use any value it chooses to label a 406 zone as long as it meets the requirement that the index value of each 407 attached zone of the same scope be unique within the node. 408 Similarly, an implementation may choose an index value other than 409 zero to represent the default zone. Implementations choosing to 410 follow the recommended basic API [BASICAPI] will want to restrict 411 their index values to those that can be represented by the 412 sin6_scope_id field of a sockaddr_in6. 414 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 8 415 7. Sending Packets 417 When an upper-layer protocol sends a packet to a non-global 418 destination address, it must have a means of identifying to the IPv6 419 layer the intended zone, for cases in which the node is attached to 420 more than one zone of the destination address's scope. 422 Although identification of an outgoing interface is sufficient to 423 identify an intended zone (because each interface is attached to no 424 more than one zone of each scope), that is more specific than desired 425 in many cases. For example, when sending to a site-local unicast 426 address, from a node that has more than one interface to the intended 427 site, the upper layer protocol may not care which of those interfaces 428 is used for the transmission, but rather would prefer to leave that 429 choice to the routing function in the IP layer. Thus, the upper- 430 layer requires the ability to specify a zone index, rather than an 431 interface identifier, when sending to a non-global, non-loopback 432 destination address. 434 8. Receiving Packets 436 When an upper-layer protocol receives a packet containing a non- 437 global source or destination address, the zone to which that address 438 pertains can be determined from the arrival interface, because the 439 arrival interface can be attached to only one zone of the same scope 440 as the address under consideration. However, it is recommended that 441 the IP layer convey to the upper layer the correct zone indices for 442 the arriving source and destination addresses, in addition to the 443 arrival interface identifier. 445 9. Forwarding 447 When a router receives a packet addressed to a node other than 448 itself, it must take the zone of the destination and source addresses 449 into account as follows: 451 o The zone of the destination address is determined by the 452 scope of the address and arrival interface of the packet. 453 The next-hop interface is chosen by looking up the 454 destination address in a (conceptual) routing table 455 specific to that zone. That routing table is restricted 456 to refer only to interfaces belonging to that zone. 458 o After the next-hop interface is chosen, the zone of the 459 source address is considered. As with the destination 460 address, the zone of the source address is determined by 461 the scope of the address and arrival interface of the 462 packet. If transmitting the packet on the chosen next-hop 463 interface would cause the packet to leave the zone of the 465 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 9 466 source address, i.e., cross a zone boundary of the scope 467 of the source address, then the packet is discarded and an 468 ICMP Destination Unreachable message [RFC 2463] with Code 469 2 ("beyond scope of source address") is sent to the source 470 of the packet. 472 Note that the above procedure applies for addresses of all scopes, 473 including link-local. Thus, if a router receives a packet with a 474 link-local destination address that is not one of the router's own 475 link-local addresses on the arrival link, the router is expected to 476 try to forward the packet to the destination on that link (subject to 477 successful determination of the destination's link-layer address via 478 the Neighbor Discovery protocol [RFC 2461]). The forwarded packet may 479 be transmitted back out the arrival interface, or out any other 480 interface attached to the same link. 482 A node that receives a packet addressed to itself and containing a 483 Routing Header with more than zero Segments Left [RFC 2460, section 484 4.4] swaps the original destination address with the next address in 485 the Routing Header. Then the above forwarding rules are applied, 486 using the new destination address where the zone of the new 487 destination address should be determined by the scope of the previous 488 destination address and the interface to which the previous address 489 belongs (which is not necessarily equal to the incoming interface). 490 An implementation MUST NOT examine additional addresses in the 491 Routing header to determine whether they are crossing boundaries for 492 their scopes. Thus, it is possible, though generally inadvisable, to 493 use a Routing Header to convey a non-global address across its 494 associated zone boundary. 496 10. Routing 498 When a routing protocol determines that it is operating on a zone 499 boundary, it MUST protect inter-zone integrity and maintain intra- 500 zone connectivity. 502 In order to maintain connectivity, the routing protocol must be able 503 to create forwarding information for the global prefixes as well as 504 for all of the zone prefixes for each of its attached zones. The 505 most straightforward way of doing this is to create (conceptual) 506 forwarding tables for each specific zone. 508 To protect inter-zone integrity, routers must be selective in the 509 prefix information that is shared with neighboring routers. Routers 510 routinely exchange routing information with neighboring routers. 511 When a router is transmitting this routing information, it must not 512 include any information about zones other than the zones assigned to 513 the interface used to transmit the information. 515 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 10 516 * * 517 * * 518 * =========== Site X * 519 * | | * 520 * | | * 521 +-*----|-------|------+ * 522 | * intf1 intf2 | * 523 | * | * 524 | * intf3 --- * 525 | * | * 526 | *********************************** 527 | | 528 | Router | 529 | | 530 ********************** ********************** 531 | * * | 532 Site Y --- intf4 * * intf5 --- Site Z 533 | * * | 534 ********************** ********************** 535 +---------------------+ 537 Figure 4: Multi-Sited Router 539 As an example, the router in Figure 4 must exchange routing 540 information on five interfaces. The information exchanged is as 541 follows: 543 o Interface 1 545 o All global prefixes 547 o All site prefixes learned from Interfaces 1, 2, and 3 549 o Interface 2 551 o All global prefixes 553 o All site prefixes learned from Interfaces 1, 2, and 3 555 o Interface 3 557 o All global prefixes 559 o All site prefixes learned from Interface 1, 2, and 3 561 o Interface 4 563 o All global prefixes 565 o All site prefixes learned from Interface 4 567 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 11 568 o Interface 5 570 o All global prefixes 572 o All site prefixes learned from Interfaces 5 574 By imposing route exchange rules, zone integrity is maintained by 575 keeping all zone-specific routing information contained within the 576 zone. 578 11. Mobility 580 A mobile node using [MOBILE] that moves outside its "home site" 581 should not expect to be able to send and receive packets as if it had 582 remained in the zone. In particular, the mobile node MUST NOT try to 583 have a tunnel back into its old zone for the purposes of attempting 584 such communication. This also implies that the mobile node should 585 choose global addresses as home address whenever possible. This 586 restriction should apply whether the scope of the zone is link-local 587 or site-local. 589 Since there is no standard way to provide an ability to tell whether 590 a mobile node is in its home site and/or whether a correspondent node 591 is in the same site as the mobile node, the mobile node should always 592 use a global care-of address. 594 12. Textual Representation 596 As already mentioned, to specify an IPv6 non-global address without 597 ambiguity, an intended scope zone should be specified as well. As a 598 common notation to specify the scope zone, an implementation SHOULD 599 support the following format. 601
% 603 where 604
is a literal IPv6 address, 605 is a string to identify the scope type and zone of 606 the address, and 607 `%' is a delimiter character to distinguish between
608 and . 610 The following subsections describe detail definitions, concrete 611 examples, and additional notes of the format. 613 12.1 Non-Global Addresses 615 The format is applied to all kinds of unicast and multicast addresses 616 of non-global scope. Although the format is meaningless and should 618 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 12 619 not be used for global addresses, an implementation which handles 620 addresses (e.g. name to address mapping functions) MAY allow users to 621 use such a notation. 623 12.2 Zone Indices 625 In the textual representation, a zone index should be able to 626 identify a particular type of scope and a particular zone of the 627 scope. Note that the representation contains the type of scope as 628 well as the identifier within the particular scope type. This can be 629 useful, for example, when the zone index without an address is used 630 in a Management Information Base (MIB). 632 The actual representation of the zone indices, including how to 633 specify the scope type, is implementation dependent. But one 634 possible example would be to use an integer in which the upper-most 4 635 bits specifies the scope type just like the "scop" subfield of 636 multicast addresses and the rest of the value specifies a particular 637 zone of the scope. For instance, site zones in Figure 1 of Section 6 638 can be represented as 32-bit integers 50000001 and 50000002 (in 639 hexadecimal), which designate site1 and site2, respectively. 641 When a zone index is used with an address in the form of 642
%, the scope type of the address MUST be equal to 643 the scope type of the zone index. An implementation SHOULD check the 644 consistency when it interprets the format. 646 An implementation SHOULD support at least numerical indices as 647 , which are non-negative decimal integers. Positive indices 648 MUST uniquely specify a single zone of a single scope type. An 649 implementation MAY use zero ("0") to specify a "default" zone as 650 described in Section 6 of this document. In this case, the 651 corresponding scope type is the scope type of the
part. 653 Since the identifiers contain scope type values, the decimal integers 654 may not be intuitive for operators. For example, if the upper-most 4 655 bits were used for the scope type values, "site1" would be 656 represented as 1342177281 (which is 50000001 in hexadecimal). 658 In order to improve the readability, this document also defines 659 aliases for the decimal representation. The alias is constructed by 660 concatenating a string and a decimal number, where the string 661 specifies the scope type and the number identifies a particular zone 662 of the scope. Today there are five non-global scope types defined; 663 interface-local, link-local, subnet-local, admin-local, and 664 organization-local, and this document defines five scope type strings 665 accordingly; "intf", "link", "sbnt", "admn", "site", and "orgn". 666 Using this alias, a string "site1" can be used as well as 667 "1342177281" in the example above. An alias string for the global 668 scope is intentionally undefined, since there is no ambiguity about 670 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 13 671 the global scope and it is practically expected zone indices are 672 omitted for global addresses. 674 An implementation MAY support other kinds of non-null strings as 675 . However, the strings must not conflict with the delimiter 676 character or with the aliases. The precise format and semantics of 677 such additional strings is implementation dependent. 679 One possible candidate of such strings would be interface names, 680 since interfaces uniquely disambiguate any type of scopes. In 681 particular, interface names can be used as "default identifiers" for 682 interfaces, links, and subnets, because there is, by default, a one- 683 to-one mapping between interfaces and each of those scopes as 684 described in Section 6. 686 An implementation could also use interface names as for 687 larger scopes than subnets, but there might be some confusion in such 688 use. For example, when more than one interface belongs to a same 689 site, a user would be confused about which interface should be used. 690 Also, a mapping function from an address to a name would encounter a 691 same kind of problem, when it prints an address with an interface 692 name as a zone index. This document does not specify how these cases 693 should be treated and leaves it implementation dependent. 695 It cannot be assumed that a same index is common to all nodes in a 696 zone (see Section 6). Hence, the format MUST be used only within a 697 node and MUST NOT be sent on a wire unless every node that interprets 698 the format agrees with the semantics. 700 12.3 Examples 702 Here are examples. The following addresses 704 fe80::1234 (on the 1st link of the node) 705 fec0::5678 (on the 2nd site of the node) 706 ff02::9abc (on the 5th link of the node) 707 ff08::def0 (on the 10th organization of the node) 709 would be represented as follows: 711 fe80::1234%536870913 or fe80::1234%link1 712 fec0::5678%1342177282 or fec0::5678%site2 713 ff02::9abc%536870917 or ff02::9abc%link5 714 ff08::def0%2147483658 or ff08::def0%orgn10 716 (Here we assume 32-bit integers as zone indices with the upper-most 4 717 bits specifying the scope type.) 719 If we use interface names as , those addresses could also be 720 represented as follows: 722 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 14 723 fe80::1234%ne0 724 fec0::5678%ether2 725 ff02::9abc%pvc1.3 726 ff08::def0%interface10 728 where the interface "ne0" belongs to 1st link, "ether2" belongs to 729 2nd site, and so on. 731 12.4 Usage Examples 733 Applications that are supposed to be used in end hosts like telnet, 734 ftp, and ssh, may not explicitly support the notion of address scope, 735 especially of link-local addresses. However, an expert user (e.g. a 736 network administrator) sometimes has to give even link-local 737 addresses to such applications. 739 Here is a concrete example. Consider a multi-linked router, called 740 "R1", that has at least two point-to-point interfaces (links). Each 741 of the interfaces is connected to another router, called "R2" and 742 "R3", respectively. Also assume that the point-to-point interfaces 743 are "unnumbered", that is, they have link-local addresses only. 745 Now suppose that the routing system on R2 hangs up and has to be 746 reinvoked. In this situation, we may not be able to use a global 747 address of R2, because this is a routing trouble and we cannot expect 748 that we have enough routes for global reachability to R2. 750 Hence, we have to login R1 first, and then try to login R2 using 751 link-local addresses. In such a case, we have to give the link-local 752 address of R2 to, for example, telnet. Here we assume the address is 753 fe80::2. 755 Note that we cannot just type like 757 % telnet fe80::2 759 here, since R1 has more than one link and hence the telnet command 760 cannot detect which link it should try to connect. Instead, we 761 should type the link-local address with the link index as follows: 763 % telnet fe80::2%link3 765 where "link3" after the delimiter character `%' is the link index of 766 the point-to-point link. 768 Another example is an EBGP peering. When two IPv6 ISPs establish an 769 EBGP peering, using a particular ISP's global addresses for the peer 770 would be unfair, and using their link-local addresses would be better 771 in a neutral IX. In such a case, link-local addresses should be 773 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 15 774 specified in a router's configuration file and the link for the 775 addresses should be disambiguated, since a router usually connects to 776 multiple links. 778 12.5 Related API 780 The "Basic Socket API" [BASICAPI] defines how the format for non- 781 global addresses should be treated in library functions that 782 translate a nodename to an address, or vice versa. 784 12.6 Omitting Zone Indices 786 The format defined in this document does not intend to invalidate the 787 original format for non-global addresses, that is, the format without 788 the zone index portion. An implementation SHOULD rather provide a 789 user with a "default" zone of each scope and allow the user to omit 790 zone indices in textual representations. 792 Also, when an implementation can assume that there is no ambiguity of 793 any type of scopes on a node, it MAY even omit the whole 794 functionality to handle the format. An end host with a single 795 interface would be an example of such a case. 797 12.7 Combinations of Delimiter Characters 799 There are other kinds of delimiter characters defined for IPv6 800 addresses. In this subsection, we describe how they should be 801 combined with the format for non-global addresses. 803 The IPv6 addressing architecture [ADDRARCH] also defines the syntax 804 of IPv6 prefixes. If the address portion of a prefix is non-global 805 and its scope zone should be disambiguated, the address portion 806 SHOULD be in the format. For example, the prefix fec0:0:0:1::/64 on 807 the 2nd site should be represented as follows: 809 fec0:0:0:1::%site2/64 811 In this combination, it is important to place the zone index portion 812 before the prefix length, when we consider parsing the format by a 813 name-to-address library function [BASICAPI]. That is, we can first 814 separate the address with the zone index from the prefix length, and 815 just pass the former to the library function. 817 The preferred format for literal IPv6 addresses in URL's are also 818 defined [RFC 2732]. When a user types the preferred format for an 819 IPv6 non-global address whose zone should be explicitly specified, 820 the user could use the format for the non-global address combined 821 with the preferred format. 823 However, the typed URL is often sent on a wire, and it would cause 824 confusion if an application did not strip the portion 826 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 16 827 before sending. Also, the format for non-global addresses might 828 conflict with the URI syntax [RFC 2396], since the syntax defines the 829 delimiter character (`%') as the escape character. 831 Hence, this document does not specify how the format for non-global 832 addresses should be combined with the preferred format for literal 833 IPv6 addresses. As for the conflict issue with the URI format, it 834 would be better to wait until the relationship between the preferred 835 format and the URI syntax is clarified. In fact, the preferred 836 format for IPv6 literal addresses itself has same kind of conflict. 837 In any case, it is recommended to use an FQDN instead of a literal 838 IPv6 address in a URL, whenever an FQDN is available. 840 13. Related Documents 842 The following documents have aspects related to IPv6 address scope, 843 but are not cited elsewhere in this document: 845 o Default Address Selection for IPv6, draft-ietf-ipngwg- 846 default-addr-select-06.txt 848 14. Security Considerations 850 The routing section of this document specifies a set of guidelines 851 that allow routers to prevent zone-specific information from leaking 852 out of each site. If site boundary routers allow site routing 853 information to be forwarded outside of the site, the integrity of the 854 site could be compromised. 856 Since the use of the textual representation of non-global addresses 857 is restricted within a single node, it does not create a security 858 vulnerability from outside the node. However, a malicious node might 859 send a packet that contains a textual IPv6 non-global address with a 860 zone index, intending to deceive the receiving node about the zone of 861 the non-global address. Thus, an implementation should be careful 862 when it receives packets that contain textual non-global addresses as 863 data. 865 15. References 867 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 868 Requirement Levels", RFC 2119, BCP14, March 1999. 870 [ADDRARCH] Hinden, R., and Deering, S., "IP Version 6 Addressing 871 Architecture", Internet Draft, draft-ietf-ipngwg-addr- 872 arch-v3-04.txt, February 2001. 874 [RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version 876 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 17 877 6 (IPv6) Specification", RFC 2460, December 1998. 879 [RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in 880 IPv6 Specification", RFC 2473, December 1998. 882 [RFC 2463] Conta, A., and Deering, S., "Internet Control Message 883 Protocol (RFC 2463) for Internet Protocol Version 6 884 (IPv6)", RFC 2463, December 1998. 886 [RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 887 Discovery for IP Version 6 (IPv6)", RFC 2461, December 888 1998. 890 [MOBILE] Johnson, D.B., and Perkins, C., "Mobility Support in 891 IPv6", Internet Draft, draft-ietf-mobileip-ipv6-14.txt, 892 July 2001. 894 [BASICAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., 895 "Basic Socket Interface Extensions for IPv6", Internet 896 Draft, draft-ietf-ipngwg-rfc2553bis-03.txt, February 2001. 898 [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Preferred 899 Format for Literal IPv6 Addresses in URL's", RFC 2732, 900 December 1999. 902 [RFC 2396] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform 903 Resource Identifiers (URI): Generic Syntax", RFC 2396, 904 August 1998. 906 Acknowledgements 908 Authors' Addresses 910 Stephen E. Deering 911 Cisco Systems, Inc. 912 170 West Tasman Drive 913 San Jose, CA 95134-1706 914 USA 916 Phone: +1-408-527-8213 917 Fax: +1-408-527-8213 918 Email: deering@cisco.com 920 Brian Haberman 921 No Affiliation 923 Phone: +1-919-949-4828 924 Email: haberman@innovationslab.net 926 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 18 927 Tatuya JINMEI 928 Corporate Research & Development Center, Toshiba Corporation 929 1 Komukai Toshiba-cho, Kawasaki-shi 930 Kanagawa 212-8582, JAPAN 932 Phone: +81-44-549-2230 933 Fax: +81-44-520-1841 934 Email: jinmei@isl.rdc.toshiba.co.jp 936 Erik Nordmark 937 Sun Microsystems Laboratories, Europe 938 29 Chemin du Vieux Chene 939 38240 Meylan, France 941 Phone: +33 (0)4 76 18 88 03 942 Fax: +33 (0)4 76 18 88 88 943 Email: Erik.Nordmark@sun.com 945 Atsushi Onoe 946 IT Development Division, NSC, Sony Corporation 947 6-7-35 Kitashinagawa, Shinagawa-ku 948 Tokyo 141-0001, JAPAN 950 Phone: +81-3-5475-8491 951 Fax: +81-3-5475-8977 952 Email: onoe@sm.sony.co.jp 954 Brian D. Zill 955 Microsoft Research 956 One Microsoft Way 957 Redmond, WA 98052-6399 958 USA 960 Phone: +1-425-703-3568 961 Fax: +1-425-936-7329 962 Email: bzill@microsoft.com 964 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 19