idnits 2.17.1 draft-ietf-ipv6-scoping-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1034. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 32 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (August 20, 2004) is 7188 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) ** Obsolete normative reference: RFC 2463 (ref. '4') (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '6') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '9') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2732 (ref. '12') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '13') (Obsoleted by RFC 3986) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF IPv6 Working Group S. Deering 2 Internet-Draft Cisco Systems 3 Expires: February 18, 2005 B. Haberman 4 Johns Hopkins Univ 5 T. Jinmei 6 Toshiba 7 E. Nordmark 8 Sun Microsystems 9 B. Zill 10 Microsoft 11 August 20, 2004 13 IPv6 Scoped Address Architecture 14 draft-ietf-ipv6-scoping-arch-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on February 18, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 This document specifies the architectural characteristics, expected 48 behavior, textual representation, and usage of IPv6 addresses of 49 different scopes. According to a decision in the IPv6 working group, 50 this document intentionally avoids using the syntax and usage of 51 unicast site-local addresses. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3 58 4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11 62 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11 63 9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 11. Textual Representation . . . . . . . . . . . . . . . . . . . 15 66 11.1 Non-Global Addresses . . . . . . . . . . . . . . . . . . 15 67 11.2 The Part . . . . . . . . . . . . . . . . . . . 15 68 11.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 69 11.4 Usage Examples . . . . . . . . . . . . . . . . . . . . . 17 70 11.5 Related API . . . . . . . . . . . . . . . . . . . . . . 18 71 11.6 Omitting Zone Indices . . . . . . . . . . . . . . . . . 18 72 11.7 Combinations of Delimiter Characters . . . . . . . . . . 18 73 12. Security Considerations . . . . . . . . . . . . . . . . . . 19 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 75 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 76 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 16.1 Normative References . . . . . . . . . . . . . . . . . . . 20 79 16.2 Informative References . . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 81 Intellectual Property and Copyright Statements . . . . . . . 23 83 1. Introduction 85 Internet Protocol version 6 includes support for addresses of 86 different "scope", that is, both global and non-global (e.g., 87 link-local) addresses. While non-global addressing has been 88 introduced operationally in the IPv4 Internet, both in the use of 89 private address space ("net 10", etc.) and with administratively 90 scoped multicast addresses, the design of IPv6 formally incorporates 91 the notion of address scope into its base architecture. This 92 document specifies the architectural characteristics, expected 93 behavior, textual representation, and usage of IPv6 addresses of 94 different scopes. 96 Though the current address architecture specification [1] defines 97 unicast site-local addresses, the IPv6 working group decided to 98 deprecate the syntax and the usage [5], and is now investigating 99 other forms of local IPv6 addressing. The usage of any new forms of 100 local addresses will be documented elsewhere in the future. Thus, 101 this document intentionally focuses on link-local and multicast 102 scopes only. 104 2. Definitions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [2]. 110 3. Basic Terminology 112 The terms link, interface, node, host, and router are defined in [3]. 113 The definitions of unicast address scopes (link-local and global) and 114 multicast address scopes (interface-local, link-local, etc.) are 115 contained in [1]. 117 4. Address Scope 119 Every IPv6 address other than the unspecified address has a specific 120 scope, that is, a topological span within which the address may be 121 used as a unique identifier for an interface or set of interfaces. 122 The scope of an address is encoded as part of the address, as 123 specified in [1]. 125 For unicast addresses, this document discusses two defined scopes: 127 o Link-local scope, for uniquely identifying interfaces within 128 (i.e., attached to) a single link only. 130 o Global scope, for uniquely identifying interfaces anywhere in the 131 Internet. 133 The IPv6 unicast loopback address, ::1, is treated as having link- 134 local scope within an imaginary link to which a virtual "loopback 135 interface" is attached. 137 The unspecified address, ::, is a special case. It does not have any 138 scope, because it must never be assigned to any node according to 139 [1]. Note, however, that an implementation might use an 140 implementation dependent semantics for the unspecified address and 141 may want to allow the unspecified address to have specific scopes. 142 For example, implementations often use the unspecified address to 143 represent "any" address in APIs. In such a case, implementations may 144 want to regard the address in a particular scope to represent the 145 notion of "any addresses in the scope." This document does not 146 prohibit such a usage, as long as it is limited within the 147 implementation. 149 [1] defines IPv6 addresses with embedded IPv4 addresses as part of 150 global addresses. Thus, those addresses have global scope, with 151 regards to the IPv6 scoped address architecture. However, an 152 implementation may use those addresses as if they had other scopes 153 for convenience. For instance, [6] assigns link-local scope to IPv4 154 auto-configured link-local addresses (the addresses from the prefix 155 169.254.0.0/16 [7]), and converts those addresses into IPv4-mapped 156 IPv6 addresses in order to perform destination address selection 157 among IPv4 and IPv6 addresses. This would implicitly mean the 158 IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration 159 link-local addresses have link-local scope. This document does not 160 preclude such a usage, as long as it is limited within the 161 implementation. 163 Anycast addresses [1] are allocated from the unicast address space 164 and have the same scope properties as unicast addresses. All 165 statements in this document regarding unicast apply equally to 166 anycast. 168 For multicast addresses, there are fourteen possible scopes, ranging 169 from interface-local to global (including link-local). The 170 interface-local scope spans a single interface only; a multicast 171 address of interface-local scope is useful only for loopback delivery 172 of multicasts within a single node, for example, as a form of 173 inter-process communication within a computer. Unlike the unicast 174 loopback address, interface-local multicast addresses may be assigned 175 to any interface. 177 There is a size relationship among scopes: 179 o for unicast scopes, link-local is a smaller scope than global. 181 o for multicast scopes, scopes with lesser values in the "scop" 182 subfield of the multicast address (Section 2.7 of [1]) are smaller 183 than scopes with greater values, with interface-local being the 184 smallest and global being the largest. 186 However, two scopes of different size may cover the exact same region 187 of topology. For example, a (multicast) site may consist of a single 188 link, in which both link-local and site-local scope effectively cover 189 the same topological span. 191 5. Scope Zones 193 A scope zone, or simply a zone, is a connected region of topology of 194 a given scope. For example, the set of links connected by routers 195 within a particular (multicast) site, and the interfaces attached to 196 those links, comprise a single zone of multicast site-local scope. 197 Note that a zone is a particular instance of a topological region 198 (e.g., Alice's site or Bob's site), whereas a scope is the size of a 199 topological region (i.e., a site or a link or a ...). 201 The zone to which a particular non-global address pertains is not 202 encoded in the address itself, but rather is determined by context, 203 such as the interface from which it is sent or received. Thus, 204 addresses of a given (non-global) scope may be re-used in different 205 zones of that scope. For example, two different physical links may 206 each contain a node with link-local address fe80::1. 208 Zones of the different scopes are instantiated as follows: 210 o Each interface on a node comprises a single zone of 211 interface-local scope (for multicast only). 213 o Each link, and the interfaces attached to that link, comprises a 214 single zone of link-local scope (for both unicast and multicast). 216 o There is a single zone of global scope (for both unicast and 217 multicast), comprising all the links and interfaces in the 218 Internet. 220 o The boundaries of zones of scope other than interface-local, 221 link-local, and global must be defined and configured by network 222 administrators. 224 Zone boundaries are relatively static features, not changing in 225 response to short-term changes in topology. Thus, the requirement 226 that the topology within a zone be "connected" is intended to include 227 links and interfaces that may be only occasionally connected. For 228 example, a residential node or network that obtains Internet access 229 by dial-up to an employer's (multicast) site may be treated as part 230 of the employer's (multicast) site-local zone even when the dial-up 231 link is disconnected. Similarly, a failure of a router, interface, 232 or link that causes a zone to become partitioned does not split that 233 zone into multiple zones; rather, the different partitions are still 234 considered to belong to the same zone. 236 Zones have the following additional properties: 238 o Zone boundaries cut through nodes, not links. (Note that the 239 global zone has no boundary, and the boundary of an 240 interface-local zone encloses just a single interface.) 242 o Zones of the same scope cannot overlap, i.e., they can have no 243 links or interfaces in common. 245 o A zone of a given scope (less than global) falls completely within 246 zones of larger scope, i.e., a smaller scope zone cannot include 247 more topology than any larger scope zone with which it shares any 248 links or interfaces. 250 o Each zone is required to be "convex" from a routing perspective, 251 i.e., packets sent from one interface to any other interface in 252 the same zone are never routed outside the zone. Note, however, 253 that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 254 tunnel link [8]), a lower layer network of the tunnel can be 255 located outside the zone without breaking the convexity property. 257 Each interface belongs to exactly one zone of each possible scope. 258 Note that this means an interface belongs to a scope zone regardless 259 of what kind of unicast address the interface has or of which 260 multicast groups the node joins on the interface. 262 6. Zone Indices 264 Considering the fact that the same non-global address may be in use 265 in more than one zone of the same scope (e.g., the use of link-local 266 address fe80::1 in two separate physical links), and that a node may 267 have interfaces attached to different zones of the same scope (e.g., 268 a router normally has multiple interfaces attached to different 269 links), a node requires an internal means of identifying to which 270 zone a non-global address belongs. This is accomplished by 271 assigning, within the node, a distinct "zone index" to each zone of 272 the same scope to which that node is attached, and allowing all 273 internal uses of an address to be qualified by a zone index. 275 The assignment of zone indices is illustrated in the example in the 276 figure below: 278 --------------------------------------------------------------- 279 | a node | 280 | | 281 | | 282 | | 283 | | 284 | | 285 | | 286 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 287 | | 288 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 289 --------------------------------------------------------------- 290 : | | | | 291 : | | | | 292 : | | | | 293 (imaginary ================= a point- a 294 loopback an Ethernet to-point tunnel 295 link) link 297 Figure 1: Zone Indices Example 299 This example node has five interfaces: 301 A loopback interface to the imaginary loopback link (a phantom 302 link that goes nowhere), 304 Two interfaces to the same Ethernet link, 306 An interface to a point-to-point link, and 308 A tunnel interface (e.g., the abstract endpoint of an 309 IPv6-over-IPv6 tunnel [8], presumably established over either the 310 Ethernet or the point-to-point link.) 312 It is thus attached to five interface-local zones, identified by the 313 interface indices 1 through 5. 315 Because the two Ethernet interfaces are attached to the same link, 316 the node is attached to only four link-local zones, identified by 317 link indices 1 through 4. Also note that even if the tunnel 318 interface is established over the Ethernet, the tunnel link gets its 319 own link index, which is different from the index of the Ethernet 320 link zone. 322 Each zone index of a particular scope should contain enough 323 information to allow the determination of the scope, so that all 324 indices of all scopes are unique within the node and zone indices 325 themselves can be used for a dedicated purpose. Usage of the index 326 to identify an entry in the Management Information Base (MIB) is an 327 example of the dedicated purpose. The actual representation to 328 encode the scope is implementation dependent and is out of scope of 329 this document. Within this document, indices are simply represented 330 like "link index 2" for readability. 332 The zone indices are strictly local to the node. For example, the 333 node on the other end of the point-to-point link may well be using 334 entirely different interface and link index values for that link. 336 An implementation should also support the concept of a "default" zone 337 for each scope. And, when supported, the index value zero at each 338 scope SHOULD be reserved to mean "use the default zone". Unlike 339 other zone indices, the default index does not contain any scope, and 340 the scope is determined by the address which the default index 341 accompanies. An implementation may additionally define a separate 342 default zone for each scope. Those default indices can also be used 343 as the zone qualifier for an address for which the node is attached 344 to only one zone, e.g., when using global addresses. 346 There is at present no way for a node to automatically determine 347 which of its interfaces belong to the same zones, e.g., the same link 348 or the same multicast scope zone larger than interface. In the 349 future, protocols may be developed to determine that information. In 350 the absence of such protocols, an implementation must provide a means 351 for manual assignment and/or reassignment of zone indices. 352 Furthermore, to avoid the need to perform manual configuration in 353 most cases, an implementation should, by default, initially assign 354 zone indices as follows, and only as follows: 356 o A unique interface index for each interface 358 o A unique link index for each interface 360 Then, manual configuration would be necessary only for the less 361 common cases of nodes with multiple interfaces to a single link or 362 interfaces to zones of different (multicast-only) scopes. 364 Thus, the default zone index assignments for the example node from 365 Figure 1 would be as illustrated in Figure 2, below. Manual 366 configuration would then be required to, for example, assign the same 367 link index to the two Ethernet interfaces as shown in Figure 1. 369 --------------------------------------------------------------- 370 | a node | 371 | | 372 | | 373 | | 374 | | 375 | | 376 | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | 377 | | 378 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 379 --------------------------------------------------------------- 380 : | | | | 381 : | | | | 382 : | | | | 383 (imaginary ================= a point- a 384 loopback an Ethernet to-point tunnel 385 link) link 387 Figure 2: Example of Default Zone Indices 389 As well as initially assigning zone indices, as specified above, an 390 implementation should automatically select a default zone for each 391 scope for which there is more than one choice, to be used whenever an 392 address is specified without a zone index (or with a zone index of 393 zero). For instance, in the example shown in Figure 2, the 394 implementation might automatically select intf2 and link2 as the 395 default zones for each of those two scopes. (One possible selection 396 algorithm is to choose the first zone that includes an interface 397 other than the loopback interface as the default for each scope.) A 398 means must also be provided for manually assigning the default zone 399 for a scope, overriding any automatic assignment. 401 Because the unicast loopback address, ::1, may not be assigned to any 402 interface other than the loopback interface, it is recommended that, 403 whenever ::1 is specified without a zone index, or with the default 404 zone index, it be interpreted as belonging to the loopback link-local 405 zone, regardless of which link-local zone has been selected as the 406 default. If this is done, then in the common case of nodes with only 407 a single non-loopback interface (e.g., a single Ethernet interface), 408 it becomes possible to avoid any need to qualify link-local addresses 409 with a zone index: the unqualified address ::1 would always refer to 410 the link-local zone containing the loopback interface, and all other 411 unqualified link-local addresses would refer to the link-local zone 412 containing the non-loopback interface (as long as the default 413 link-local zone were set to be the zone containing the non-loopback 414 interface). 416 Because of the requirement that a zone of a given scope fall 417 completely within zones of larger scope (see Section 5, above), if 418 two interfaces are assigned to different zones of scope S, they must 419 also be assigned to different zones of all scopes smaller than S. 420 Thus, the manual assignment of distinct zone indices for one scope 421 may require the automatic assignment of distinct zone indices for 422 smaller scopes. For example, suppose that distinct multicast 423 site-local indices 1 and 2 are manually assigned in Figure 1 and that 424 site 1 contains link 1, 2, and 3, while site 2 only contains link 4. 425 This configuration would then cause the automatic creation of 426 corresponding admin-local (i.e. multicast "scop" value 4) indices 1 427 and 2, because admin-local scope is smaller than site-local scope. 429 Taking all of the above considerations in account, the complete set 430 of zone indices for our example node from Figure 1 with the 431 additional configurations here is shown in Figure 3, below. 433 --------------------------------------------------------------- 434 | a node | 435 | | 436 | | 437 | | 438 | | 439 | | 440 | /--------------------site1--------------------\ /--site2--\ | 441 | | 442 | /-------------------admin1--------------------\ /-admin2--\ | 443 | | 444 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 445 | | 446 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 447 --------------------------------------------------------------- 448 : | | | | 449 : | | | | 450 : | | | | 451 (imaginary ================= a point- a 452 loopback an Ethernet to-point tunnel 453 link) link 455 Figure 3: Complete Zone Indices Example 457 Although the above examples show the zones being assigned index 458 values sequentially for each scope, starting at one, the zone index 459 values are arbitrary. An implementation may use any value it chooses 460 to label a zone as long as it meets the requirement that the index 461 value of each zone of all scopes be unique within the node and that 462 zero SHOULD be reserved to represent the default zone. 463 Implementations choosing to follow the recommended basic API [10] 464 will want to restrict their index values to those that can be 465 represented by the sin6_scope_id field of the sockaddr_in6 structure. 467 7. Sending Packets 469 When an upper-layer protocol sends a packet to a non-global 470 destination address, it must have a means of identifying to the IPv6 471 layer the intended zone, for cases in which the node is attached to 472 more than one zone of the destination address's scope. 474 Although identification of an outgoing interface is sufficient to 475 identify an intended zone (because each interface is attached to no 476 more than one zone of each scope), that is more specific than desired 477 in many cases. For example, when sending to a link-local unicast 478 address, from a node that has more than one interface to the intended 479 link (though this is an unusual configuration), the upper layer 480 protocol may not care which of those interfaces is used for the 481 transmission, but rather would prefer to leave that choice to the 482 routing function in the IP layer. Thus, the upper-layer requires the 483 ability to specify a zone index, rather than an interface identifier, 484 when sending to a non-global, non-loopback destination address. 486 8. Receiving Packets 488 When an upper-layer protocol receives a packet containing a non- 489 global source or destination address, the zone to which that address 490 pertains can be determined from the arrival interface, because the 491 arrival interface can be attached to only one zone of the same scope 492 as the address under consideration. However, it is recommended that 493 the IP layer convey to the upper layer the correct zone indices for 494 the arriving source and destination addresses, in addition to the 495 arrival interface identifier. 497 9. Forwarding 499 When a router receives a packet addressed to a node other than 500 itself, it must take the zone of the destination and source addresses 501 into account as follows: 503 o The zone of the destination address is determined by the scope of 504 the address and arrival interface of the packet. The next-hop 505 interface is chosen by looking up the destination address in a 506 (conceptual) routing table specific to that zone (see Section 10). 507 That routing table is restricted to refer only to interfaces 508 belonging to that zone. 510 o After the next-hop interface is chosen, the zone of the source 511 address is considered. As with the destination address, the zone 512 of the source address is determined by the scope of the address 513 and arrival interface of the packet. If transmitting the packet 514 on the chosen next-hop interface would cause the packet to leave 515 the zone of the source address, i.e., cross a zone boundary of the 516 scope of the source address, then the packet is discarded. 517 Additionally, if the packet's destination address is a unicast 518 address, an ICMP Destination Unreachable message [4] with Code 2 519 ("beyond scope of source address") is sent to the source of the 520 original packet. Note: Code 2 is currently left as unassigned in 521 [4]. But the IANA is going to re-assign the value for the new 522 purpose, and [4] will be revised with this change. 524 Note that even with the decision that unicast site-local addresses 525 are deprecated, the above procedure still applies to link-local 526 addresses. Thus, if a router receives a packet with a link-local 527 destination address that is not one of the router's own link-local 528 addresses on the arrival link, the router is expected to try to 529 forward the packet to the destination on that link (subject to 530 successful determination of the destination's link-layer address via 531 the Neighbor Discovery protocol [9]). The forwarded packet may be 532 transmitted back out the arrival interface, or out any other 533 interface attached to the same link. 535 A node that receives a packet addressed to itself and containing a 536 Routing Header with more than zero Segments Left (Section 4.4 of [3]) 537 first checks the scope of the next address in the Routing Header. If 538 the scope of the next address is smaller than the scope of the 539 original destination address, the node MUST discard the packet. 540 Otherwise, it swaps the original destination address with the next 541 address in the Routing Header. Then the above forwarding rules apply 542 as follows: 544 o The zone of the new destination address is determined by the scope 545 of the next address and the arrival interface of the packet. The 546 next-hop interface is chosen just like the first bullet of the 547 rules above. 549 o After the next-hop interface is chosen, the zone of the source 550 address is considered just like the second bullet of the rules 551 above. 553 This check about the scope of the next address ensures that when a 554 packet arrives at its final destination, if that destination is link- 555 local then the receiving node can know that the packet originated on- 556 link. As a result, this will help the receiving node send a 557 "response" packet with the final destination of the received packet 558 as the source address without breaking its source zone. 560 Note that it is possible, though generally inadvisable, to use a 561 Routing Header to convey a non-global address across its associated 562 zone boundary in the previously-used next address field. For 563 example, consider a case where a link-border node (e.g., a router) 564 receives a packet with the destination being a link-local address, 565 and the source address a global address. If the packet contains a 566 Routing Header where the next address is a global address, the 567 next-hop interface to the global address may belong to a different 568 link than that of the original destination. This is allowed, because 569 the scope of the next address is not smaller than the scope of the 570 original destination. 572 10. Routing 574 Note: since unicast site-local addresses are deprecated, and 575 link-local addresses do not need routing, the discussion in this 576 section only applies to multicast scoped routing. 578 When a routing protocol determines that it is operating on a zone 579 boundary, it MUST protect inter-zone integrity and maintain intra- 580 zone connectivity. 582 In order to maintain connectivity, the routing protocol must be able 583 to create forwarding information for the global groups as well as for 584 all of the scoped groups for each of its attached zones. The most 585 straightforward way of doing this is to create (conceptual) 586 forwarding tables for each specific zone. 588 To protect inter-zone integrity, routers must be selective in the 589 group information that is shared with neighboring routers. Routers 590 routinely exchange routing information with neighboring routers. 591 When a router is transmitting this routing information, it must not 592 include any information about zones other than the zones assigned to 593 the interface used to transmit the information. 595 * * 596 * * 597 * =========== Organization X * 598 * | | * 599 * | | * 600 +-*----|-------|------+ * 601 | * intf1 intf2 | * 602 | * | * 603 | * intf3 --- * 604 | * | * 605 | *********************************** 606 | | 607 | Router | 608 | | 609 ********************** ********************** 610 | * * | 611 Org. Y --- intf4 * * intf5 --- Org. Z 612 | * * | 613 ********************** ********************** 614 +---------------------+ 616 Figure 4: Multi-Organization Multicast Router 618 As an example, the router in Figure 4 must exchange routing 619 information on five interfaces. The information exchanged is as 620 follows (for simplicity, multicast scopes smaller or larger than 621 organization except global are not considered here): 623 o Interface 1 624 * All global groups 625 * All organization groups learned from Interfaces 1, 2, and 3 627 o Interface 2 628 * All global groups 629 * All organization groups learned from Interfaces 1, 2, and 3 631 o Interface 3 632 * All global groups 633 * All organization groups learned from Interfaces 1, 2, and 3 635 o Interface 4 636 * All global groups 637 * All organization groups learned from Interface 4 639 o Interface 5 640 * All global groups 641 * All organization groups learned from Interface 5 643 By imposing route exchange rules, zone integrity is maintained by 644 keeping all zone-specific routing information contained within the 645 zone. 647 11. Textual Representation 649 As already mentioned, to specify an IPv6 non-global address without 650 ambiguity, an intended scope zone should be specified as well. As a 651 common notation to specify the scope zone, an implementation SHOULD 652 support the following format. 654
% 656 where 658
is a literal IPv6 address, 660 is a string to identify the zone of the address, and 662 `%' is a delimiter character to distinguish between
and 663 . 665 The following subsections describe detailed definitions, concrete 666 examples, and additional notes of the format. 668 11.1 Non-Global Addresses 670 The format applies to all kinds of unicast and multicast addresses of 671 non-global scope except the unspecified address, which does not have 672 a scope. The format is meaningless and should not be used for global 673 addresses. The loopback address belongs to the trivial link, i.e., 674 the link attached to the loopback interface, and thus the format 675 should not be used for the loopback address either. This document 676 does not specify the usage of the format when the
is the 677 unspecified address, since the address does not have a scope. This 678 document, however, does not prohibit an implementation from using the 679 format for those special addresses for implementation dependent 680 purposes. 682 11.2 The Part 684 In the textual representation, the part should be able to 685 identify a particular zone of the address's scope. Although a zone 686 index is expected to contain enough information to determine the 687 scope and to be unique among all scopes as described in Section 6 of 688 this document, the part of this format does not have to 689 contain the scope because the
part should specify the 690 appropriate scope. This also means the part does not have 691 to be unique among all scopes. 693 With this loosened property, an implementation can use a convenient 694 representation as . For example, to represent link index 2, 695 the implementation can simply use "2" as , which would be 696 more readable than other representations that contain the "link" 697 scope. 699 When an implementation interprets the format, it should construct the 700 "full" zone index, which contains the scope, from the part 701 and the scope specified by the
part. (Remember that a zone 702 index itself should contain the scope as specified in Section 6.) 704 An implementation SHOULD support at least numerical indices as 705 , which are non-negative decimal integers. The default zone 706 index, which should typically be 0 (see Section 6), is included in 707 the integers. When is the default, the delimiter 708 character, "%", and can be omitted. Similarly, if a 709 textual representation of an IPv6 address is given without a zone 710 index, it should be interpreted as
% where 711 is the default zone index of the scope that
712 has. 714 An implementation MAY support other kinds of non-null strings as 715 . However, the strings must not conflict with the delimiter 716 character. The precise format and semantics of such additional 717 strings is implementation dependent. 719 One possible candidate of such strings would be interface names, 720 since interfaces uniquely disambiguate any scopes. In particular, 721 interface names can be used as "default identifiers" for interfaces 722 and links, because there is, by default, a one-to-one mapping between 723 interfaces and each of those scopes as described in Section 6. 725 An implementation could also use interface names as for 726 larger scopes than links, but there might be some confusion in such 727 use. For example, when more than one interface belongs to the same 728 (multicast) site, a user would be confused about which interface 729 should be used. Also, a mapping function from an address to a name 730 would encounter the same kind of problem, when it prints an address 731 with an interface name as a zone index. This document does not 732 specify how these cases should be treated and leaves it 733 implementation dependent. 735 It cannot be assumed that indices are common across all nodes in a 736 zone (see Section 6). Hence, the format MUST be used only within a 737 node and MUST NOT be sent on the wire unless every node that 738 interprets the format agrees on the semantics. 740 11.3 Examples 742 Here are examples. The following addresses 744 fe80::1234 (on the 1st link of the node) 745 ff02::5678 (on the 5th link of the node) 746 ff08::9abc (on the 10th organization of the node) 748 would be represented as follows: 750 fe80::1234%1 751 ff02::5678%5 752 ff08::9abc%10 754 (Here we assume a natural translation from a zone index to the 755 part where the Nth zone of any scope is translated into 756 "N".) 758 If we use interface names as , those addresses could also be 759 represented as follows: 761 fe80::1234%ne0 762 ff02::5678%pvc1.3 763 ff08::9abc%interface10 765 where the interface "ne0" belongs to the 1st link, "pvc1.3" belongs 766 to the 5th link, and "interface10" belongs to the 10th organization. 768 11.4 Usage Examples 770 Applications that are supposed to be used in end hosts like telnet, 771 ftp, and ssh, may not explicitly support the notion of address scope, 772 especially of link-local addresses. However, an expert user (e.g. a 773 network administrator) sometimes has to give even link-local 774 addresses to such applications. 776 Here is a concrete example. Consider a multi-linked router, called 777 "R1", that has at least two point-to-point interfaces (links). Each 778 of the interfaces is connected to another router, called "R2" and 779 "R3", respectively. Also assume that the point-to-point interfaces 780 have link-local addresses only. 782 Now suppose that the routing system on R2 hangs up and has to be 783 reinvoked. In this situation, we may not be able to use a global 784 address of R2, because this is a routing trouble and we cannot expect 785 that we have enough routes for global reachability to R2. 787 Hence, we have to login R1 first, and then try to login R2 using 788 link-local addresses. In such a case, we have to give the link-local 789 address of R2 to, for example, telnet. Here we assume the address is 790 fe80::2. 792 Note that we cannot just type like 794 % telnet fe80::2 796 here, since R1 has more than one link and hence the telnet command 797 cannot detect which link it should try to use for connecting. 798 Instead, we should type the link-local address with the link index as 799 follows: 801 % telnet fe80::2%3 803 where "3" after the delimiter character `%' corresponds to the link 804 index of the point-to-point link. 806 11.5 Related API 808 An extension to the recommended basic API defines how the format for 809 non-global addresses should be treated in library functions that 810 translate a nodename to an address, or vice versa [11]. 812 11.6 Omitting Zone Indices 814 The format defined in this document does not intend to invalidate the 815 original format for non-global addresses, that is, the format without 816 the zone index portion. As described in Section 6, in some common 817 cases with the notion of the default zone index, there can be no 818 ambiguity about scope zones. In such an environment, the 819 implementation can omit the "%" part, and, as a result, it 820 can act as if it did not support the extended format at all. 822 11.7 Combinations of Delimiter Characters 824 There are other kinds of delimiter characters defined for IPv6 825 addresses. In this subsection, we describe how they should be 826 combined with the format for non-global addresses. 828 The IPv6 addressing architecture [1] also defines the syntax of IPv6 829 prefixes. If the address portion of a prefix is non-global and its 830 scope zone should be disambiguated, the address portion SHOULD be in 831 the format. For example, a link-local prefix fe80::/64 on the 2nd 832 link can be represented as follows: 834 fe80::%2/64 836 In this combination, it is important to place the zone index portion 837 before the prefix length, when we consider parsing the format by a 838 name-to-address library function [11]. That is, we can first 839 separate the address with the zone index from the prefix length, and 840 just pass the former to the library function. 842 The preferred format for literal IPv6 addresses in URL's are also 843 defined [12]. When a user types the preferred format for an IPv6 844 non-global address whose zone should be explicitly specified, the 845 user could use the format for the non-global address combined with 846 the preferred format. 848 However, the typed URL is often sent on the wire, and it would cause 849 confusion if an application did not strip the portion 850 before sending. Note that the applications should not need to care 851 about which kind of addresses they're using, much less parse or strip 852 out the portion of the address. Also, the format for 853 non-global addresses might conflict with the URI syntax [13], since 854 the syntax defines the delimiter character (`%') as the escape 855 character. 857 Hence, this document does not specify how the format for non-global 858 addresses should be combined with the preferred format for literal 859 IPv6 addresses. As for the conflict issue with the URI format, it 860 would be better to wait until the relationship between the preferred 861 format and the URI syntax is clarified. In fact, the preferred 862 format for IPv6 literal addresses itself has the same kind of 863 conflict. In any case, it is recommended to use an FQDN instead of a 864 literal IPv6 address in a URL, whenever an FQDN is available. 866 12. Security Considerations 868 A limited scoped address without its zone index has security 869 implications, and cannot be used for some security contexts. For 870 example, a link-local address cannot be used in a traffic selector of 871 a security association established by Internet Key Exchange (IKE) 872 when the IKE messages are carried over global addresses. Also, a 873 link-local address without its zone index cannot be used in access 874 control lists. 876 The routing section of this document specifies a set of guidelines 877 that allow routers to prevent zone-specific information from leaking 878 out of each zone. If, for example, multicast site boundary routers 879 allow site routing information to be forwarded outside of the site, 880 the integrity of the site could be compromised. 882 Since the use of the textual representation of non-global addresses 883 is restricted to use within a single node, it does not create a 884 security vulnerability from outside the node. However, a malicious 885 node might send a packet that contains a textual IPv6 non-global 886 address with a zone index, intending to deceive the receiving node 887 about the zone of the non-global address. Thus, an implementation 888 should be careful when it receives packets that contain textual 889 non-global addresses as data. 891 13. IANA Considerations 893 This document has no actions for IANA. 895 14. Contributors 897 This document is a combination of several separate efforts. Atsushi 898 Onoe took a significant role in one of them, and deeply contributed 899 to the content of Section 11 as a co-author of a separate proposal. 901 15. Acknowledgements 903 Many members of the IPv6 working group provided useful comments and 904 feedback on this document. In particular, Margaret Wasserman and Bob 905 Hinden led the working group to make a consensus on IPv6 local 906 addressing. Richard Draves proposed an additional rule to process 907 Routing header containing scoped addresses. Dave Thaler and Francis 908 Dupont gave valuable suggestions to define semantics of zone indices 909 in terms of related API. Pekka Savola reviewed a draft of the 910 document very carefully, and made detailed comments including serious 911 problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy 912 Gleeson reviewed and helped improve the document during the 913 preparation for publication. 915 16. References 917 16.1 Normative References 919 [1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 920 Addressing Architecture", RFC 3513, April 2003. 922 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 923 Levels", BCP 14, RFC 2119, March 1997. 925 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 926 Specification", RFC 2460, December 1998. 928 [4] Conta, A. and S. Deering, "Internet Control Message Protocol 929 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 930 Specification", RFC 2463, December 1998. 932 16.2 Informative References 934 [5] Huitema, C. and B. Carpenter, "Deprecating Site Local 935 Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work in 936 progress), March 2004. 938 [6] Draves, R., "Default Address Selection for Internet Protocol 939 version 6 (IPv6)", RFC 3484, February 2003. 941 [7] Aboba, B., "Dynamic Configuration of Link-Local IPv4 942 Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in 943 progress), July 2004. 945 [8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 946 Specification", RFC 2473, December 1998. 948 [9] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 949 for IP Version 6 (IPv6)", RFC 2461, December 1998. 951 [10] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. 952 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 953 3493, February 2003. 955 [11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic 956 Socket API", draft-ietf-ipv6-scope-api-00 (work in progress), 957 July 2002. 959 [12] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 960 IPv6 Addresses in URL's", RFC 2732, December 1999. 962 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 963 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 964 1998. 966 Authors' Addresses 968 Stephen E. Deering 969 Cisco Systems, Inc. 970 170 West Tasman Drive 971 San Jose, CA 95134-1706 972 USA 973 Brian Haberman 974 Johns Hopkins University Applied Physics Laboratory 975 11100 Johns Hopkins Road 976 Laurel, MD 20723-6099 977 USA 979 Phone: +1-443-778-1319 980 EMail: brian@innovationslab.net 982 Tatuya Jinmei 983 Corporate Research & Development Center, Toshiba Corporation 984 1 Komukai Toshiba-cho, Saiwai-ku 985 Kawasaki-shi, Kanagawa 212-8582 986 Japan 988 Phone: +81-44-549-2230 989 Fax: +81-44-520-1841 990 EMail: jinmei@isl.rdc.toshiba.co.jp 992 Erik Nordmark 993 Sun Microsystems Laboratories, Europe 994 180, avenue de l'Europe 995 SAINT ISMIER Cedex 38334 996 France 998 Phone: +33 (0)4 74 18 88 03 999 Fax: +33 (0)4 76 18 88 88 1000 EMail: Erik.Nordmark@sun.com 1002 Brian D. Zill 1003 Microsoft Research 1004 One Microsoft Way 1005 Redmond, WA 98052-6399 1006 USA 1008 Phone: +1-425-703-3568 1009 Fax: +1-425-936-7329 1010 EMail: bzill@microsoft.com 1012 Intellectual Property Statement 1014 The IETF takes no position regarding the validity or scope of any 1015 Intellectual Property Rights or other rights that might be claimed to 1016 pertain to the implementation or use of the technology described in 1017 this document or the extent to which any license under such rights 1018 might or might not be available; nor does it represent that it has 1019 made any independent effort to identify any such rights. Information 1020 on the procedures with respect to rights in RFC documents can be 1021 found in BCP 78 and BCP 79. 1023 Copies of IPR disclosures made to the IETF Secretariat and any 1024 assurances of licenses to be made available, or the result of an 1025 attempt made to obtain a general license or permission for the use of 1026 such proprietary rights by implementers or users of this 1027 specification can be obtained from the IETF on-line IPR repository at 1028 http://www.ietf.org/ipr. 1030 The IETF invites any interested party to bring to its attention any 1031 copyrights, patents or patent applications, or other proprietary 1032 rights that may cover technology that may be required to implement 1033 this standard. Please address the information to the IETF at 1034 ietf-ipr@ietf.org. 1036 Disclaimer of Validity 1038 This document and the information contained herein are provided on an 1039 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1040 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1041 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1042 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1043 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1044 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1046 Copyright Statement 1048 Copyright (C) The Internet Society (2004). This document is subject 1049 to the rights, licenses and restrictions contained in BCP 78, and 1050 except as set forth therein, the authors retain all their rights. 1052 Acknowledgment 1054 Funding for the RFC Editor function is currently provided by the 1055 Internet Society.