idnits 2.17.1 draft-ietf-ipv6-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: ---------------------------------------------------------------------------- ** 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 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.) ** There are 36 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2003) is 7607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3513 (ref. '1') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-02 -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 3493 (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '7') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '8') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2732 (ref. '9') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '10') (Obsoleted by RFC 3986) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Deering 3 Internet-Draft Cisco Systems 4 Expires: December 22, 2003 B. Haberman 5 Caspian Networks 6 T. Jinmei 7 Toshiba 8 E. Nordmark 9 Sun Microsystems 10 A. Onoe 11 Sony 12 B. Zill 13 Microsoft 14 June 23, 2003 16 IPv6 Scoped Address Architecture 17 draft-ietf-ipv6-scoping-arch-00.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 22, 2003. 42 Copyright Notice 44 Copyright (C) The Internet Society (2003). All Rights Reserved. 46 Abstract 48 This document specifies the architectural characteristics, expected 49 behavior, textual representation, and usage of IPv6 addresses of 50 different scopes. According to a decision in the IPv6 working group, 51 this document intentionally avoids using the syntax and usage of 52 unicast site-local addresses. 54 1. Introduction 56 Internet Protocol version 6 includes support for addresses of 57 different "scope", that is, both global and non-global (e.g., link- 58 local) addresses. While non-global addressing has been introduced 59 operationally in the IPv4 Internet, both in the use of private 60 address space ("net 10", etc.) and with administratively scoped 61 multicast addresses, the design of IPv6 formally incorporates the 62 notion of address scope into its base architecture. This document 63 specifies the architectural characteristics, expected behavior, 64 textual representation, and usage of IPv6 addresses of different 65 scopes. 67 Though the current specification [1] defines unicast site-local 68 addresses, the IPv6 working group decided to deprecate the syntax and 69 the usage and is now investigating other forms of local IPv6 70 addressing. The usage of any new forms of local addresses will be 71 documented elsewhere in the future. Thus, this document 72 intentionally focuses on link-local and multicast scopes only. 74 2. Definitions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [2]. 80 3. Basic Terminology 82 The terms link, interface, node, host, and router are defined in [3]. 83 The definitions of unicast address scopes (link-local and global) and 84 multicast address scopes (interface-local, link-local, etc.) are 85 contained in [1]. 87 4. Address Scope 89 Every IPv6 address other than the unspecified address has a specific 90 scope, that is, a topological span within which the address may be 91 used as a unique identifier for an interface or set of interfaces. 92 The scope of an address is encoded as part of the address, as 93 specified in [1]. 95 For unicast addresses, this document discusses two defined scopes: 97 o Link-local scope, for uniquely identifying interfaces within 98 (i.e., attached to) a single link only. 100 o Global scope, for uniquely identifying interfaces anywhere in the 101 Internet. 103 The IPv6 unicast loopback address, ::1, is treated as having link- 104 local scope within an imaginary link to which a virtual "loopback 105 interface" is attached. 107 The unspecified address, ::, is a special case. It does not have any 108 scope, because it must never be assigned to any node according to 109 [1]. Note, however, that an implementation might use an 110 implementation dependent semantics for the unspecified address and 111 may want to allow the unspecified address to have specific scopes. 112 For example, implementations often use the unspecified address to 113 represent "any" address in APIs. In such a case, implementations may 114 want to regard the address in a particular scope to represent the 115 notion of "any addresses in the scope." This document does not 116 prohibit such a usage, as long as it is limited within the 117 implementation. 119 [1] defines IPv6 addresses with embedded IPv4 addresses as part of 120 global addresses. Thus, those addresses have global scope, with 121 regards to the IPv6 scoped address architecture. However, an 122 implementation may use those addresses as if they had other type of 123 scopes for convenience. For instance, [7] assigns link-local scope 124 to IPv4 auto-configuration addresses, and converts those addresses 125 into IPv4-mapped IPv6 addresses in order for destination address 126 selection among IPv4 and IPv6 addresses. This would implicitly mean 127 IPv4-mapped addresses correspondent to IPv4 auto-configuration 128 addresses have link-local scope. This document does not preclude 129 such a usage, as long as it is limited within the implementation. 131 Anycast addresses [1] are allocated from the unicast address space 132 and have the same scope properties as unicast addresses. All 133 statements in this document regarding unicast apply equally to 134 anycast. 136 For multicast addresses, there are fourteen possible scopes, ranging 137 from interface-local to global (including link-local). The 138 interface-local scope spans a single interface only; a multicast 139 address of interface-local scope is useful only for loopback delivery 140 of multicasts within a single node, for example, as a form of inter- 141 process communication within a computer. Unlike the unicast loopback 142 address, interface-local multicast addresses may be assigned to any 143 interface. 145 There is a size relationship among scopes: 147 o for unicast scopes, link-local is a smaller scope than global. 149 o for multicast scopes, scopes with lesser values in the "scop" 150 subfield of the multicast address (Section 2.7 of [1]) are smaller 151 than scopes with greater values, with interface-local being the 152 smallest and global being the largest. 154 However, two scopes of different size may cover the exact same region 155 of topology. For example, a (multicast) site may consist of a single 156 link, in which both link-local and site-local scope effectively cover 157 the same topological span. 159 5. Scope Zones 161 A scope zone, or a simply a zone, is a connected region of topology 162 of a given scope. For example, the set of links connected by routers 163 within a particular (multicast) site, and the interfaces attached to 164 those links, comprise a single zone of multicast site-local scope. 165 Note that a zone is a particular instance of a topological region 166 (e.g., Alice's site or Bob's site), whereas a scope is the size of a 167 topological region (i.e., a site or a link or a ...). 169 The zone to which a particular non-global address pertains is not 170 encoded in the address itself, but rather is determined by context, 171 such as the interface from which it is sent or received. Thus, 172 addresses of a given (non-global) scope may be re-used in different 173 zones of that scope. For example, two different physical links may 174 each contain a node with link-local address fe80::1. 176 Zones of the different scopes are instantiated as follows: 178 o Each interface on a node comprises a single zone of interface- 179 local scope (for multicast only). 181 o Each link, and the interfaces attached to that link, comprises a 182 single zone of link-local scope (for both unicast and multicast). 184 o There is a single zone of global scope (for both unicast and 185 multicast), comprising all the links and interfaces in the 186 Internet. 188 o The boundaries of zones of scope other than interface-local, link- 189 local, and global must be defined and configured by network 190 administrators. 192 Zone boundaries are relatively static features, not changing in 193 response to short-term changes in topology. Thus, the requirement 194 that the topology within a zone be "connected" is intended to include 195 links and interfaces that may be only occasionally connected. For 196 example, a residential node or network that obtains Internet access 197 by dial-up to an employer's (multicast) site may be treated as part 198 of the employer's (multicast) site-local zone even when the dial-up 199 link is disconnected. Similarly, a failure of a router, interface, 200 or link that causes a zone to become partitioned does not split that 201 zone into multiple zones; rather, the different partitions are still 202 considered to belong to the same zone. 204 Zones have the following additional properties: 206 o Zone boundaries cut through nodes, not links. (Note that the 207 global zone has no boundary, and the boundary of an interface- 208 local zone encloses just a single interface.) 210 o Zones of the same scope cannot overlap, i.e., they can have no 211 links or interfaces in common. 213 o A zone of a given scope (less than global) falls completely within 214 zones of larger scope, i.e., a smaller scope zone cannot include 215 more topology than any larger scope zone with which it shares any 216 links or interfaces. 218 o Each zone is required to be "convex" from a routing perspective, 219 i.e., packets sent from one interface to any other interface in 220 the same zone are never routed outside the zone. 222 Each interface belongs to exactly one zone of each possible scope. 224 6. Zone Indices 226 Considering the fact that the same non-global address may be in use 227 in more than one zone of the same scope (e.g., the use of link-local 228 address fe80::1 in two separate physical links), and that a node may 229 have interfaces attached to different zones of the same scope (e.g., 230 a router normally has multiple interfaces attached to different 231 links), a node requires an internal means of identifying to which 232 zone a non-global address belongs. This is accomplished by 233 assigning, within the node, a distinct "zone index" to each zone of 234 the same scope to which that node is attached, and allowing all 235 internal uses of an address to be qualified by a zone index. 237 The assignment of zone indices is illustrated in the example in the 238 figure below: 240 --------------------------------------------------------------------- 242 --------------------------------------------------------------- 243 | a node | 244 | | 245 | | 246 | | 247 | | 248 | | 249 | | 250 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 251 | | 252 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 253 --------------------------------------------------------------- 254 : | | | | 255 : | | | | 256 : | | | | 257 (imaginary ================= a point- a 258 loopback an Ethernet to-point tunnel 259 link) link 261 Figure 1: Zone Indices Example 263 --------------------------------------------------------------------- 265 This example node has five interfaces: 267 A loopback interface to the imaginary loopback link (a phantom 268 link that goes nowhere), 270 Two interfaces to the same Ethernet, 272 An interface to a point-to-point link, and 274 A tunnel interface (e.g., the abstract endpoint of an IPv6-over- 275 IPv6 tunnel [6], presumably established over either the Ethernet 276 or the point-to-point link.) 278 It is thus attached to five interface-local zones, identified by the 279 interface indices 1 through 5. 281 Because the two Ethernet interfaces are attached to the same link, 282 the node is attached to only four link-local zones, identified by 283 link indices 1 through 4. 285 Each zone index of a particular scope should contain an information 286 to represent the scope type, so that all indices of all scopes are 287 unique within the node and zone indices themselves can be used for a 288 dedicated purpose. An entry of a Management Information Base (MIB) 289 will be an example of the dedicated purpose. The actual 290 representation to encode the scope type is implementation dependent 291 and is out of scope of this document. Within this document, indices 292 are simply represented like "link index 2" for readability. 294 The zone indices are strictly local to the node. For example, the 295 node on the other end of the point-to-point link may well be using 296 entirely different interface and link index values for that link. 298 An implementation should also support the concept of a "default" zone 299 for each scope. It is convenient to reserve the index value zero, at 300 each scope, to mean "use the default zone". Unlike other zone 301 indices, the default ID does not contain any scope type, and the 302 scope type is determined by the address by which the default ID was 303 accompanied. An implementation may additionally define a separate 304 default zone for each scope type. Those default indices can also be 305 used as the zone qualifier for an address for which the node is 306 attached to only one zone, e.g., when using global addresses. 308 There is at present no way for a node to automatically determine 309 which of its interfaces belong to the same zones, e.g., the same link 310 or the same multicast scope zone larger than interface. In the 311 future, protocols may be developed to determine that information. In 312 the absence of such protocols, an implementation must provide a means 313 for manual assignment and/or reassignment of zone indices. 314 Furthermore, to avoid the need to perform manual configuration in 315 most cases, an implementation should, by default, initially assign 316 zone indices as follows, and only as follows: 318 o A unique interface index for each interface 320 o A unique link index for each interface 322 o A unique subnet (multicast "scop" value 3) index for each 323 interface 325 Then, manual configuration would be necessary only for the less 326 common cases of nodes with multiple interfaces to a single link or a 327 single subnet, interfaces to different sites, or interfaces to zones 328 of different (multicast-only) scopes. 330 Thus, the default zone index assignments for the example node from 331 Figure 1 would be as illustrated in Figure 2, below. Manual 332 configuration would then be required to, for example, assign the same 333 link index to the two Ethernet interfaces as shown in Figure 1. 335 --------------------------------------------------------------------- 337 --------------------------------------------------------------- 338 | a node | 339 | | 340 | | 341 | | 342 | | 343 | | 344 | /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ | 345 | | 346 | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | 347 | | 348 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 349 --------------------------------------------------------------- 350 : | | | | 351 : | | | | 352 : | | | | 353 (imaginary ================= a point- a 354 loopback an Ethernet to-point tunnel 355 link) link 357 Figure 2: Example of Default Zone Indices 359 --------------------------------------------------------------------- 361 As well as initially assigning zone indices, as specified above, an 362 implementation should automatically select a default zone for each 363 scope for which there is more than one choice, to be used whenever an 364 address is specified without a zone index (or with a zone index of 365 zero). For instance, in the example shown in Figure 2, the 366 implementation might automatically select intf2, link2, and subnet2 367 as the default zones for each of those three scopes. (Perhaps the 368 selection algorithm is to choose the first zone that includes an 369 interface other than the loopback interface as the default for each 370 scope.) A means must also be provided for manually assigning the 371 default zone for a scope, overriding any automatic assignment. 373 Because the unicast loopback address, ::1, may not be assigned to any 374 interface other than the loopback interface, it is recommended that, 375 whenever ::1 is specified without a zone index, or with the default 376 zone index, it be interpreted as belonging to the loopback link-local 377 zone, regardless of which link-local zone has been selected as the 378 default. If this is done, then in the common case of nodes with only 379 a single non-loopback interface (e.g., a single Ethernet interface), 380 it becomes possible to avoid any need to qualify link- local 381 addresses with a zone index: the unqualified address ::1 would always 382 refer to the link-local zone containing the loopback interface, and 383 all other unqualified link-local addresses would refer to the link- 384 local zone containing the non-loopback interface (as long as the 385 default link-local zone were set to be the zone containing the non- 386 loopback interface). 388 Because of the requirement that a zone of a given scope fall 389 completely within zones of larger scope (see Section 5, above), if 390 two interfaces are assigned to different zones of scope S, they must 391 also be assigned to different zones of all scopes smaller than S. 392 Thus, the manual assignment of distinct zone indices for one scope 393 may require the automatic assignment of distinct zone indices for 394 smaller scopes. For example, suppose that distinct multicast site- 395 local indices 1 and 2 are manually assigned in Figure 1 and that site 396 1 contains link 1, 2, and 3, while site 2 only contains link 4. This 397 configuration would then cause the automatic creation of 398 corresponding admin-local (i.e. multicast "scop" value 4) indices 1 399 and 2, because admin-local scope is smaller than site-local scope. 401 Taking all of the above considerations in account, the complete set 402 of zone indices for our example node from Figure 1 with the 403 additional configurations here is shown in Figure 3, below. 405 --------------------------------------------------------------------- 407 --------------------------------------------------------------- 408 | a node | 409 | | 410 | | 411 | | 412 | | 413 | | 414 | /--------------------site1--------------------\ /--site2--\ | 415 | | 416 | /-------------------admin1--------------------\ /-admin2--\ | 417 | | 418 | /-subnet1-\ /-------subnet2-------\ /-subnet3-\ /-subnet4-\ | 419 | | 420 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 421 | | 422 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 423 --------------------------------------------------------------- 424 : | | | | 425 : | | | | 426 : | | | | 427 (imaginary ================= a point- a 428 loopback an Ethernet to-point tunnel 429 link) link 431 Figure 3: Complete Zone Indices Example 433 --------------------------------------------------------------------- 435 Although the examples above show the zones being assigned index 436 values sequentially for each scope, starting at one, the zone index 437 values are arbitrary. An implementation may use any value it chooses 438 to label a zone as long as it meets the requirement that the index 439 value of each zone of all scopes be unique within the node. 440 Similarly, an implementation may choose an index value other than 441 zero to represent the default zone. Implementations choosing to 442 follow the recommended basic API [5] will want to restrict their 443 index values to those that can be represented by the sin6_scope_id 444 field of a sockaddr_in6 structure. 446 7. Sending Packets 448 When an upper-layer protocol sends a packet to a non-global 449 destination address, it must have a means of identifying to the IPv6 450 layer the intended zone, for cases in which the node is attached to 451 more than one zone of the destination address's scope. 453 Although identification of an outgoing interface is sufficient to 454 identify an intended zone (because each interface is attached to no 455 more than one zone of each scope), that is more specific than desired 456 in many cases. For example, when sending to a link-local unicast 457 address, from a node that has more than one interface to the intended 458 link (though this is an unusual configuration), the upper layer 459 protocol may not care which of those interfaces is used for the 460 transmission, but rather would prefer to leave that choice to the 461 routing function in the IP layer. Thus, the upper-layer requires the 462 ability to specify a zone index, rather than an interface identifier, 463 when sending to a non-global, non-loopback destination address. 465 8. Receiving Packets 467 When an upper-layer protocol receives a packet containing a non- 468 global source or destination address, the zone to which that address 469 pertains can be determined from the arrival interface, because the 470 arrival interface can be attached to only one zone of the same scope 471 as the address under consideration. However, it is recommended that 472 the IP layer convey to the upper layer the correct zone indices for 473 the arriving source and destination addresses, in addition to the 474 arrival interface identifier. 476 9. Forwarding 478 When a router receives a packet addressed to a node other than 479 itself, it must take the zone of the destination and source addresses 480 into account as follows: 482 o The zone of the destination address is determined by the scope of 483 the address and arrival interface of the packet. The next-hop 484 interface is chosen by looking up the destination address in a 485 (conceptual) routing table specific to that zone. That routing 486 table is restricted to refer only to interfaces belonging to that 487 zone. 489 o After the next-hop interface is chosen, the zone of the source 490 address is considered. As with the destination address, the zone 491 of the source address is determined by the scope of the address 492 and arrival interface of the packet. If transmitting the packet 493 on the chosen next-hop interface would cause the packet to leave 494 the zone of the source address, i.e., cross a zone boundary of the 495 scope of the source address, then the packet is discarded and an 496 ICMP Destination Unreachable message [4] with Code 2 ("beyond 497 scope of source address") is sent to the source of the packet. 499 Note that even with the decision that unicast site-local addresses 500 are deprecated, the above procedure still applies to link-local 501 addresses. Thus, if a router receives a packet with a link-local 502 destination address that is not one of the router's own link-local 503 addresses on the arrival link, the router is expected to try to 504 forward the packet to the destination on that link (subject to 505 successful determination of the destination's link-layer address via 506 the Neighbor Discovery protocol [8]). The forwarded packet may be 507 transmitted back out the arrival interface, or out any other 508 interface attached to the same link. 510 A node that receives a packet addressed to itself and containing a 511 Routing Header with more than zero Segments Left (Section 4.4 of [3]) 512 first checks the scope of the next address in the Routing Header. If 513 the scope of the next address is smaller than the scope of the 514 original destination address, the node MUST discard the packet. 515 Otherwise, it swaps the original destination address with the next 516 address in the Routing Header. Then the above forwarding rules apply 517 as follows: 519 o The zone of the new destination address is determined by the scope 520 of the next address in the Routing Header and arrival interface of 521 the packet. The next-hop interface is chosen just like the first 522 bullet of the rules above. 524 o After the next-hop interface is chosen, the zone of the source 525 address is considered just like the second bullet of the rules 526 above. 528 This check about the scope of the next address ensures that when a 529 packet arrives at its final destination, if that destination is link- 530 local then the receiving node can know that the packet originated on- 531 link. As a result, this will help the receiving node send a 532 "response" packet with the final destination of the received packet 533 as the source address without breaking its source zone. 535 Note that it is possible, though generally inadvisable, to use a 536 Routing Header to convey a non-global address across its associated 537 zone boundary. For example, consider a case where a link-border node 538 (e.g., a router) receives a packet with the destination being a link- 539 local address. If the packet contains a Routing Header where the 540 next address is a global address, the next-hop interface to the 541 global address may belong to a different link than that of the 542 original destination. This is allowed, because the scope of the next 543 address is not smaller than the scope of the original destination. 545 10. Routing 547 Note: since unicast site-local addresses are deprecated, and link- 548 local addresses does not need routing, the discussion in this section 549 only applies to multicast scoped routing. 551 When a routing protocol determines that it is operating on a zone 552 boundary, it MUST protect inter-zone integrity and maintain intra- 553 zone connectivity. 555 In order to maintain connectivity, the routing protocol must be able 556 to create forwarding information for the global prefixes as well as 557 for all of the zone prefixes for each of its attached zones. The 558 most straightforward way of doing this is to create (conceptual) 559 forwarding tables for each specific zone. 561 To protect inter-zone integrity, routers must be selective in the 562 prefix information that is shared with neighboring routers. Routers 563 routinely exchange routing information with neighboring routers. 564 When a router is transmitting this routing information, it must not 565 include any information about zones other than the zones assigned to 566 the interface used to transmit the information. 568 --------------------------------------------------------------------- 570 * * 571 * * 572 * =========== Organization X * 573 * | | * 574 * | | * 575 +-*----|-------|------+ * 576 | * intf1 intf2 | * 577 | * | * 578 | * intf3 --- * 579 | * | * 580 | *********************************** 581 | | 582 | Router | 583 | | 584 ********************** ********************** 585 | * * | 586 Org. Y --- intf4 * * intf5 --- Org. Z 587 | * * | 588 ********************** ********************** 589 +---------------------+ 591 Figure 4: Multi-Organization Multicast Router 593 --------------------------------------------------------------------- 595 As an example, the router in Figure 4 must exchange routing 596 information on five interfaces. The information exchanged is as 597 follows (for simplicity, multicast scopes smaller or larger than 598 organization except global are not considered here): 600 o Interface 1 602 * All global prefixes 604 * All organization prefixes learned from Interfaces 1, 2, and 3 606 o Interface 2 608 * All global prefixes 610 * All organization prefixes learned from Interfaces 1, 2, and 3 612 o Interface 3 614 * All global prefixes 616 * All organization prefixes learned from Interface 1, 2, and 3 618 o Interface 4 620 * All global prefixes 622 * All organization prefixes learned from Interface 4 624 o Interface 5 626 * All global prefixes 628 * All organization prefixes learned from Interfaces 5 630 By imposing route exchange rules, zone integrity is maintained by 631 keeping all zone-specific routing information contained within the 632 zone. 634 11. Textual Representation 636 As already mentioned, to specify an IPv6 non-global address without 637 ambiguity, an intended scope zone should be specified as well. As a 638 common notation to specify the scope zone, an implementation SHOULD 639 support the following format. 641
% 643 where 644
is a literal IPv6 address, 646 is a string to identify the zone of the address, and 648 `%' is a delimeter character to distinguish between
and 649 . 651 The following subsections describe detail definitions, concrete 652 examples, and additional notes of the format. 654 11.1 Non-Global Addresses 656 The format applies to all kinds of unicast and multicast addresses of 657 non-global scope except the unspecified address, which does not have 658 a scope. The format is meaningless and should not be used for global 659 addresses. The loopback address belongs to the trivial link, i.e., 660 the link attached to the loopback interface, thus the format should 661 not be used for the loopback address either. This document does not 662 specify the usage of the format when the
is the unspecified 663 address, since the address does not have a scope. This document, 664 however, does not prohibit an implementation from using the format 665 for those special addresses for implementation dependent purposes. 667 11.2 Zone Indices 669 In the textual representation, the part should be able to 670 identify a particular zone of the address' scope. Although a zone 671 index is expected to contain the scope type and to be unique among 672 all scopes as described in Section 6 of this document, the 673 part of this format does not have to contain the scope type because 674 the
part should specify the appropriate scope. This also 675 means the part does not have to be unique among all scopes. 677 With this loosened property, an implementation can use convenient 678 representation as . For example, to represent link index 2, 679 the implementation can simply use "2" as , which would be 680 more readable than other representation that contains the scope type 681 "link". 683 When an implementation interprets the format, it should construct the 684 "full" zone ID, which contains the scope type, from the 685 part and the scope type specified by the
part. 687 An implementation SHOULD support at least numerical indices as 688 , which are non-negative decimal integers. The default zone 689 ID, which is typically expected to be 0, is included in the integers. 690 When is the default, the delimiter character, "%", and 691 can be omitted. Similarly, if a textual representation of 692 an IPv6 address is given without a zone ID, it should be interpreted 693 as
% where is the default zone ID 694 of the scope that
has. 696 An implementation MAY support other kinds of non-null strings as 697 . However, the strings must not conflict with the delimiter 698 character. The precise format and semantics of such additional 699 strings is implementation dependent. 701 One possible candidate of such strings would be interface names, 702 since interfaces uniquely disambiguate any type of scopes. In 703 particular, interface names can be used as "default identifiers" for 704 interfaces, links, and subnets, because there is, by default, a one- 705 to-one mapping between interfaces and each of those scopes as 706 described in Section 6. 708 An implementation could also use interface names as for 709 larger scopes than subnets, but there might be some confusion in such 710 use. For example, when more than one interface belongs to a same 711 (multicast) site, a user would be confused about which interface 712 should be used. Also, a mapping function from an address to a name 713 would encounter a same kind of problem, when it prints an address 714 with an interface name as a zone index. This document does not 715 specify how these cases should be treated and leaves it 716 implementation dependent. 718 It cannot be assumed that a same index is common to all nodes in a 719 zone (see Section 6). Hence, the format MUST be used only within a 720 node and MUST NOT be sent on a wire unless every node that interprets 721 the format agrees on the semantics. 723 11.3 Examples 725 Here are examples. The following addresses 727 fe80::1234 (on the 1st link of the node) 728 ff02::9abc (on the 5th link of the node) 729 ff08::def0 (on the 10th organization of the node) 731 (Here we assume a natual translation from a zone index to the 732 part where the Nth zone of any scope is translated into 733 "N".) 735 If we use interface names as , those addresses could also be 736 represented as follows: 738 fe80::1234%ne0 739 ff02::9abc%pvc1.3 740 ff08::def0%interface10 742 where the interface "ne0" belongs to the 1st link, "pvc1.3" belongs 743 to the 5th link, and "interface10" belongs to the 10th organization. 745 11.4 Usage Examples 747 Applications that are supposed to be used in end hosts like telnet, 748 ftp, and ssh, may not explicitly support the notion of address scope, 749 especially of link-local addresses. However, an expert user (e.g. a 750 network administrator) sometimes has to give even link-local 751 addresses to such applications. 753 Here is a concrete example. Consider a multi-linked router, called 754 "R1", that has at least two point-to-point interfaces (links). Each 755 of the interfaces is connected to another router, called "R2" and 756 "R3", respectively. Also assume that the point-to-point interfaces 757 are "unnumbered", that is, they have link-local addresses only. 759 Now suppose that the routing system on R2 hangs up and has to be 760 reinvoked. In this situation, we may not be able to use a global 761 address of R2, because this is a routing trouble and we cannot expect 762 that we have enough routes for global reachability to R2. 764 Hence, we have to login R1 first, and then try to login R2 using 765 link-local addresses. In such a case, we have to give the link-local 766 address of R2 to, for example, telnet. Here we assume the address is 767 fe80::2. 769 Note that we cannot just type like 771 % telnet fe80::2 773 here, since R1 has more than one link and hence the telnet command 774 cannot detect which link it should try to connect. Instead, we 775 should type the link-local address with the link index as follows: 777 % telnet fe80::2%3 779 where "3" after the delimiter character `%' conrresponds to the link 780 index of the point-to-point link. 782 Another example is an EBGP peering. When two IPv6 ISPs establish an 783 EBGP peering, using a particular ISP's global addresses for the peer 784 would be unfair, and using their link-local addresses would be better 785 in a neutral IX. In such a case, link-local addresses should be 786 specified in a router's configuration file and the link for the 787 addresses should be disambiguated, since a router usually connects to 788 multiple links. 790 11.5 Related API 792 The "Basic Socket API" [5] defines how the format for non-global 793 addresses should be treated in library functions that translate a 794 nodename to an address, or vice versa. 796 11.6 Omitting Zone Indices 798 The format defined in this document does not intend to invalidate the 799 original format for non-global addresses, that is, the format without 800 the zone index portion. As described in Section 6, in some common 801 cases with the notion of the default zone ID, there can be no 802 ambiguity about scope zones. In such an environment, the 803 implementation can omit the "%" part, and, as a result, it 804 can act as if it did not support the extended format at all. 806 11.7 Combinations of Delimiter Characters 808 There are other kinds of delimiter characters defined for IPv6 809 addresses. In this subsection, we describe how they should be 810 combined with the format for non-global addresses. 812 The IPv6 addressing architecture [1] also defines the syntax of IPv6 813 prefixes. If the address portion of a prefix is non-global and its 814 scope zone should be disambiguated, the address portion SHOULD be in 815 the format. For example, a link-local prefix fe80::/64 on the 2nd 816 link can be represented as follows: 818 fe80::%2/64 820 In this combination, it is important to place the zone index portion 821 before the prefix length, when we consider parsing the format by a 822 name-to-address library function [5]. That is, we can first separate 823 the address with the zone index from the prefix length, and just pass 824 the former to the library function. 826 The preferred format for literal IPv6 addresses in URL's are also 827 defined [9]. When a user types the preferred format for an IPv6 non- 828 global address whose zone should be explicitly specified, the user 829 could use the format for the non-global address combined with the 830 preferred format. 832 However, the typed URL is often sent on a wire, and it would cause 833 confusion if an application did not strip the portion 834 before sending. Also, the format for non-global addresses might 835 conflict with the URI syntax [10], since the syntax defines the 836 delimiter character (`%') as the escape character. 838 Hence, this document does not specify how the format for non-global 839 addresses should be combined with the preferred format for literal 840 IPv6 addresses. As for the conflict issue with the URI format, it 841 would be better to wait until the relationship between the preferred 842 format and the URI syntax is clarified. In fact, the preferred 843 format for IPv6 literal addresses itself has same kind of conflict. 844 In any case, it is recommended to use an FQDN instead of a literal 845 IPv6 address in a URL, whenever an FQDN is available. 847 12. Security Considerations 849 The routing section of this document specifies a set of guidelines 850 that allow routers to prevent zone-specific information from leaking 851 out of each zone. If, for example, multicast site boundary routers 852 allow site routing information to be forwarded outside of the site, 853 the integrity of the site could be compromised. 855 Since the use of the textual representation of non-global addresses 856 is restricted within a single node, it does not create a security 857 vulnerability from outside the node. However, a malicious node might 858 send a packet that contains a textual IPv6 non-global address with a 859 zone index, intending to deceive the receiving node about the zone of 860 the non-global address. Thus, an implementation should be careful 861 when it receives packets that contain textual non-global addresses as 862 data. 864 13. Acknowledgements 866 Many members the IPv6 working group provided useful comments and 867 feedback on this document. In particular, Margaret Wasserman and Bob 868 Hinden led the working group to make a consensus on IPv6 local 869 addressing. Richard Draves proposed an additional rule to process 870 Routing header containing scoped addresses. Dave Thaler and Francis 871 Dupont gave valuable suggestions to define semantics of zone indices 872 in terms of related API. 874 Normative References 876 [1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 877 Addressing Architecture", RFC 3513, April 2003. 879 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 880 Levels", RFC 2119, BCP 14, March 1999. 882 [3] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6) 883 Specification", RFC 2460, December 1998. 885 [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for 886 the Internet Protocol Version 6 (IPv6)", Internet Draft draft- 887 ietf-ipngwg-icmp-v3-02.txt, November 2001. 889 [5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, 890 "Basic Socket Interface Extensions for IPv6", RFC 3493, February 891 2003. 893 Informative References 895 [6] Conta, A., "Generic Packet Tunneling in IPv6 Specification", 896 RFC 2473, December 1998. 898 [7] Draves, R., "Default Address Selection for Internet Protocol 899 version 6 (IPv6)", RFC 3484, February 2003. 901 [8] Narten, T., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 902 2461, December 1998. 904 [9] Hinden, R., Carpenter, B. and L. Masinter, "Preferred Format 905 for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 907 [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 908 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 909 1998. 911 Authors' Addresses 913 Stephen E. Deering 914 Cisco Systems, Inc. 915 170 West Tasman Drive 916 San Jose, CA 95134-1706 917 USA 919 Brian Haberman 920 Caspian Networks 921 1 Park Drive, Suite 300 922 Research Triangle Park, NC 27709 923 USA 925 Phone: +1-919-949-4828 926 EMail: brian@innovationslab.net 927 Tatuya Jinmei 928 Corporate Research & Development Center, Toshiba Corporation 929 1 Komukai Toshiba-cho, Saiwai-ku 930 Kawasaki-shi, Kanagawa 212-8582 931 Japan 933 Phone: +81-44-549-2230 934 Fax: +81-44-520-1841 935 EMail: jinmei@isl.rdc.toshiba.co.jp 937 Erik Nordmark 938 Sun Microsystems Laboratories, Europe 939 180, avenue de l'Europe 940 SAINT ISMIER Cedex 38334 941 France 943 Phone: +33 (0)4 74 18 88 03 944 Fax: +33 (0)4 76 18 88 88 945 EMail: Erik.Nordmark@sun.com 947 Atsushi Onoe 948 IT Development Division, NSC, Sony Corporation 949 6-7-35 Kitashinagawa, Kawasaki-shi 950 Tokyo 141-0001 951 Japan 953 Phone: +81-3-5475-8491 954 Fax: +81-3-5475-8977 955 EMail: onoe@sm.sony.co.jp 957 Brian D. Zill 958 Microsoft Research 959 One Microsoft Way 960 Redmond, WA 98052-6399 961 USA 963 Phone: +1-425-703-3568 964 Fax: +1-425-936-7329 965 EMail: bzill@microsoft.com 967 Full Copyright Statement 969 Copyright (C) The Internet Society (2003). All Rights Reserved. 971 This document and translations of it may be copied and furnished to 972 others, and derivative works that comment on or otherwise explain it 973 or assist in its implementation may be prepared, copied, published 974 and distributed, in whole or in part, without restriction of any 975 kind, provided that the above copyright notice and this paragraph are 976 included on all such copies and derivative works. However, this 977 document itself may not be modified in any way, such as by removing 978 the copyright notice or references to the Internet Society or other 979 Internet organizations, except as needed for the purpose of 980 developing Internet standards in which case the procedures for 981 copyrights defined in the Internet Standards process must be 982 followed, or as required to translate it into languages other than 983 English. 985 The limited permissions granted above are perpetual and will not be 986 revoked by the Internet Society or its successors or assigns. 988 This document and the information contained herein is provided on an 989 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 990 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 991 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 992 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 993 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 995 Acknowledgement 997 Funding for the RFC Editor function is currently provided by the 998 Internet Society.