idnits 2.17.1 draft-ietf-ipngwg-scoping-arch-04.txt: -(108): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(688): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(831): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(929): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 6 instances of lines with non-ascii characters in the document. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2460' is defined on line 933, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ipngwg-addr-arch-v3-07 == Outdated reference: A later version (-08) exists of draft-ietf-ipv6-default-addr-select-07 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-17 == Outdated reference: A later version (-09) exists of draft-ietf-ipngwg-rfc2553bis-05 ** Downref: Normative reference to an Informational draft: draft-ietf-ipngwg-rfc2553bis (ref. 'BASICAPI') ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPNGWG Working Group S. Deering 3 Internet Draft Cisco Systems 4 draft-ietf-ipngwg-scoping-arch-04.txt B. Haberman 5 June 2002 Consultant 6 Expires December 2002 T. Jinmei 7 Toshiba 8 E. Nordmark 9 Sun Microsystems 10 A. Onoe 11 Sony 12 B. Zill 13 Microsoft 15 IPv6 Scoped Address Architecture 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies the architectural characteristics, expected 39 behavior, textual representation, and usage of IPv6 addresses of 40 different scopes. 42 1. Introduction 44 Internet Protocol version 6 includes support for addresses of 45 different "scope", that is, both global and non-global (e.g., link- 46 local, site-local, etc.) addresses. While non-global addressing has 47 been introduced operationally in the IPv4 Internet, both in the use 48 of private address space ("net 10", etc.) and with administratively 49 scoped multicast addresses, the design of IPv6 formally incorporates 51 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 1 52 the notion of address scope into its base architecture. This 53 document specifies the architectural characteristics, expected 54 behavior, textual representation, and usage of IPv6 addresses of 55 different scopes. 57 2. Definitions 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC 2119]. 63 3. Basic Terminology 65 The terms link, interface, node, host, and router are defined in [RFC 66 2460]. The definitions of unicast address scopes (link-local, site- 67 local, and global) and multicast address scopes (interface-local, 68 link-local, etc.) are contained in [ADDRARCH]. 70 4. Address Scope 72 Every IPv6 address has a specific scope, that is, a topological span 73 within which the address may be used as a unique identifier for an 74 interface or set of interfaces. The scope of an address is encoded 75 as part of the address, as specified in [ADDRARCH]. 77 For unicast addresses, there are three defined scopes: 79 o Link-local scope, for uniquely identifying interfaces 80 within (i.e., attached to) a single link only. 82 o Site-local scope, for uniquely identifying interfaces 83 within a single site only. A "site" is, by intent, not 84 rigorously defined, but is typically expected to cover a 85 region of topology that belongs to a single organization 86 and is located within a single geographic location, such 87 as an office, an office complex, or a campus. A personal 88 residence may be treated as a site (for example, when the 89 residence obtains Internet access via a public Internet 90 service provider), or as a part of a site (for example, 91 when the residence obtains Internet access via an 92 employer's or school's site). 94 o Global scope, for uniquely identifying interfaces anywhere 95 in the Internet. 97 The IPv6 unicast loopback address, ::1, is treated as having link- 98 local scope within an imaginary link to which a virtual "loopback 99 interface" is attached. 101 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 2 102 The unspecified address, ::, is a special case. It does not have any 103 scope, because it must never be assigned to any node according to 104 [ADDRARCH]. Note, however, that an implementation might use an 105 implementation dependent semantics for the unspecified address and 106 may want to allow the unspecified address to have specific scopes. 107 For example, implementations often use the unspecified address to 108 represent �any� address in APIs. In such a case, implementations may 109 want to regard the address in a particular scope to represent the 110 notion of �any addresses in the scope.� This document does not 111 prohibit such a usage, as long as it is limited within the 112 implementation. 114 [ADDRARCH] defines IPv6 addresses with embedded IPv4 addresses as 115 part of global addresses. Thus, those addresses have global scope, 116 with regards to the IPv6 scoped address architecture. However, an 117 implementation may use those addresses as if they had other type of 118 scopes for convenience. For instance, [ADDRSELECT] assigns site- 119 local scope to IPv4 private addresses, and converts those addresses 120 into IPv4-mapped IPv6 addresses in order for destination address 121 selection among IPv4 and IPv6 addresses. This would implicitly mean 122 IPv4-mapped addresses correspondent to IPv4 private addresses have 123 site-local scope. This document does not preclude such a usage, as 124 long as it is limited within the implementation. 126 Anycast addresses [ADDRARCH] are allocated from the unicast address 127 space and have the same scope properties as unicast addresses. All 128 statements in this document regarding unicast apply equally to 129 anycast. 131 For multicast addresses, there are fourteen possible scopes, ranging 132 from interface-local to global (including both link-local and site- 133 local). The interface-local scope spans a single interface only; a 134 multicast address of interface-local scope is useful only for 135 loopback delivery of multicasts within a single node, for example, as 136 a form of inter-process communication within a computer. Unlike the 137 unicast loopback address, interface-local multicast addresses may be 138 assigned to any interface. 140 There is a size relationship among scopes: 142 o for unicast scopes, link-local is a smaller scope than 143 site-local, and site-local is a smaller scope than global. 145 o for multicast scopes, scopes with lesser values in the 146 "scop" subfield of the multicast address [ADDRARCH, 147 section 2.7] are smaller than scopes with greater values, 148 with interface-local being the smallest and global being 149 the largest. 151 However, two scopes of different size may cover the exact same region 152 of topology. For example, a site may consist of a single link, in 154 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 3 155 which both link-local and site-local scope effectively cover the same 156 topological span. 158 5. Scope Zones 160 A scope zone, or a simply a zone, is a connected region of topology 161 of a given scope. For example, the set of links connected by routers 162 within a particular site, and the interfaces attached to those links, 163 comprise a single zone of site-local scope. Note that a zone is a 164 particular instance of a topological region (e.g., Alice's site or 165 Bob's site), whereas a scope is the size of a topological region 166 (i.e., a site or a link or a ...). 168 The zone to which a particular non-global address pertains is not 169 encoded in the address itself, but rather is determined by context, 170 such as the interface from which it is sent or received. Thus, 171 addresses of a given (non-global) scope may be re-used in different 172 zones of that scope. For example, Alice's site and Bob's site may 173 each contain a node with site-local address fec0::1. 175 Zones of the different scopes are instantiated as follows: 177 o Each interface on a node comprises a single zone of 178 interface-local scope (for multicast only). 180 o Each link, and the interfaces attached to that link, 181 comprises a single zone of link-local scope (for both 182 unicast and multicast). 184 o There is a single zone of global scope (for both unicast 185 and multicast), comprising all the links and interfaces in 186 the Internet. 188 o The boundaries of zones of scope other than interface- 189 local, link-local, and global must be defined and 190 configured by network administrators. A site boundary 191 serves as such for both unicast and multicast. 193 Zone boundaries are relatively static features, not changing in 194 response to short-term changes in topology. Thus, the requirement 195 that the topology within a zone be "connected" is intended to include 196 links and interfaces that may be only occasionally connected. For 197 example, a residential node or network that obtains Internet access 198 by dial-up to an employer's site may be treated as part of the 199 employer's site-local zone even when the dial-up link is disconnected. 200 Similarly, a failure of a router, interface, or link that causes a 201 zone to become partitioned does not split that zone into multiple 202 zones; rather, the different partitions are still considered to 203 belong to the same zone. 205 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 4 206 Zones have the following additional properties: 208 o Zone boundaries cut through nodes, not links. (Note that 209 the global zone has no boundary, and the boundary of an 210 interface-local zone encloses just a single interface.) 212 o Zones of the same scope cannot overlap, i.e., they can 213 have no links or interfaces in common. 215 o A zone of a given scope (less than global) falls 216 completely within zones of larger scope, i.e., a smaller 217 scope zone cannot include more topology than any larger 218 scope zone with which it shares any links or interfaces. 220 o Each zone is required to be "convex" from a routing 221 perspective, i.e., packets sent from one interface to any 222 other interface in the same zone are never routed outside 223 the zone. 225 Each interface belongs to exactly one zone of each possible scope. 227 6. Zone Indices 229 Considering the fact that the same non-global address may be in use 230 in more than one zone of the same scope (e.g., the use of site-local 231 address fec0::1 in both Alice's site and Bob's site), and that a node 232 may have interfaces attached to different zones of the same scope 233 (e.g., having one interface attached to Alice's site and another to 234 Bob's site), a node requires an internal means of identifying to 235 which zone a non-global address belongs. This is accomplished by 236 assigning, within the node, a distinct "zone index" to each zone of 237 the same scope to which that node is attached, and allowing all 238 internal uses of an address to be qualified by a zone index. 240 The assignment of zone indices is illustrated in the example in the 241 figure below: 243 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 5 244 --------------------------------------------------------------- 245 | a node | 246 | | 247 | | 248 | | 249 | | 250 | | 251 | /--------------------site1--------------------\ /--site2--\ | 252 | | 253 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 254 | | 255 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 256 --------------------------------------------------------------- 257 : | | | | 258 : | | | | 259 : | | | | 260 (imaginary ================= a point- a 261 loopback an Ethernet to-point tunnel 262 link) link 264 Figure 1 : Zone Indices Example 266 This example node has five interfaces: 268 o A loopback interface to the imaginary loopback link (a 269 phantom link that goes nowhere), 271 o Two interfaces to the same Ethernet, 273 o An interface to a point-to-point link, and 275 o A tunnel interface (e.g., the abstract endpoint of an 276 IPv6-over-IPv6 tunnel [RFC 2473], presumably established 277 over either the Ethernet or the point-to-point link.) 279 It is thus attached to five interface-local zones, identified by the 280 interface indices 1 through 5. 282 Because the two Ethernet interfaces are attached to the same link, 283 the node is attached to only four link-local zones, identified by 284 link indices 1 through 4. 286 It is attached to two site-local zones: one to which the loopback 287 link, the Ethernet, and the point-to-point link belong, and one to 288 which the tunnel belongs (perhaps because it is a tunnel to another 289 organization). These site-local zones are identified by the site 290 indices 1 and 2. 292 Each zone index of a particular scope should contain an information 293 to represent the scope type, so that all indices of all scopes are 294 unique within the node and zone indices themselves can be used for a 296 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 6 297 dedicated purpose. An entry of a Management Information Base (MIB) 298 will be an example of the dedicated purpose. The actual 299 representation to encode the scope type is implementation dependent 300 and is out of scope of this document. Within this document, indices 301 are simply represented like "link index 2" or "site index 3" for 302 readability. 304 The zone indices are strictly local to the node. For example, the 305 node on the other end of the point-to-point link may well be using 306 entirely different interface, link, and site index values for that 307 link. 309 An implementation should also support the concept of a "default" zone 310 for each scope. It is convenient to reserve the index value zero, at 311 each scope, to mean "use the default zone". Unlike other zone 312 indices, the default ID does not contain any scope type, and the 313 scope type is determined by the address by which the default ID was 314 accompanied. An implementation may additionally define a separate 315 default zone for each scope type. Those default indices can also be 316 used as the zone qualifier for an address for which the node is 317 attached to only one zone, e.g., when using global addresses. 319 There is at present no way for a node to automatically determine 320 which of its interfaces belong to the same zones, e.g., the same link 321 or the same site. In the future, protocols may be developed to 322 determine that information. In the absence of such protocols, an 323 implementation must provide a means for manual assignment and/or 324 reassignment of zone indices. Furthermore, to avoid the need to 325 perform manual configuration in most cases, an implementation should, 326 by default, initially assign zone indices as follows, and only as 327 follows: 329 o A unique interface index for each interface 331 o A unique link index for each interface 333 o A unique subnet (multicast "scop" value 3) index for each 334 interface 336 Then, manual configuration would be necessary only for the less 337 common cases of nodes with multiple interfaces to a single link or a 338 single subnet, interfaces to different sites, or interfaces to zones 339 of different (multicast-only) scopes. 341 Thus, the default zone index assignments for the example node from 342 Figure 1 would be as illustrated in Figure 2, below. Manual 343 configuration would then be required to, for example, assign the same 344 link index to the two Ethernet interfaces as shown in Figure 1. 346 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 7 347 --------------------------------------------------------------- 348 | a node | 349 | | 350 | | 351 | | 352 | | 353 | | 354 | /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ | 355 | | 356 | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | 357 | | 358 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 359 --------------------------------------------------------------- 360 : | | | | 361 : | | | | 362 : | | | | 363 (imaginary ================= a point- a 364 loopback an Ethernet to-point tunnel 365 link) link 367 Figure 2 : Example of Default Zone Indices 369 As well as initially assigning zone indices, as specified above, an 370 implementation should automatically select a default zone for each 371 scope for which there is more than one choice, to be used whenever an 372 address is specified without a zone index (or with a zone index of 373 zero). For instance, in the example shown in Figure 2, the 374 implementation might automatically select intf2, link2, and subnet2 375 as the default zones for each of those three scopes. (Perhaps the 376 selection algorithm is to choose the first zone that includes an 377 interface other than the loopback interface as the default for each 378 scope.) A means must also be provided for manually assigning the 379 default zone for a scope, overriding any automatic assignment. 381 Because the unicast loopback address, ::1, may not be assigned to any 382 interface other than the loopback interface, it is recommended that 383 whenever ::1 is specified without a zone index, or with the default 384 zone index, that it be interpreted as belonging to the loopback link- 385 local zone, regardless of which link-local zone has been selected as 386 the default. If this is done, then in the common case of nodes with 387 only a single non-loopback interface (e.g., a single Ethernet 388 interface), it becomes possible to avoid any need to qualify link- 389 local addresses with a zone index: the unqualified address ::1 would 390 always refer to the link-local zone containing the loopback interface, 391 and all other unqualified link-local addresses would refer to the 392 link-local zone containing the non-loopback interface (as long as the 393 default link-local zone were set to be the zone containing the non- 394 loopback interface). 396 Because of the requirement that a zone of a given scope fall 397 completely within zones of larger scope (see section 5, above), if 398 two interfaces are assigned to different zones of scope S, they must 400 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 8 401 also be assigned to different zones of all scopes smaller than S. 402 Thus, the manual assignment of distinct zone indices for one scope 403 may require the automatic assignment of distinct zone indices for 404 smaller scopes. For example, the manual assignment of distinct site- 405 local indices 1 and 2 in the node in Figure 1 would cause the 406 automatic creation of corresponding admin-local (i.e. multicast 407 "scop" value 4) indices 1 and 2, because admin-local scope is smaller 408 than site-local scope. 410 Taking all of the above considerations in account, the complete set 411 of zone indices for our example node from Figure 1 is shown in Figure 412 3, below. 414 --------------------------------------------------------------- 415 | a node | 416 | | 417 | | 418 | | 419 | | 420 | | 421 | /--------------------site1--------------------\ /--site2--\ | 422 | | 423 | /-------------------admin1--------------------\ /-admin2--\ | 424 | | 425 | /-subnet1-\ /-------subnet2-------\ /-subnet3-\ /-subnet4-\ | 426 | | 427 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 428 | | 429 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 430 --------------------------------------------------------------- 431 : | | | | 432 : | | | | 433 : | | | | 434 (imaginary ================= a point- a 435 loopback an Ethernet to-point tunnel 436 link) link 438 Figure 3 : Complete Zone Indices Example 440 Although the examples above show the zones being assigned index 441 values sequentially for each scope, starting at one, the zone index 442 values are arbitrary. An implementation may use any value it chooses 443 to label a zone as long as it meets the requirement that the index 444 value of each zone of all scopes be unique within the node. 445 Similarly, an implementation may choose an index value other than 446 zero to represent the default zone. Implementations choosing to 447 follow the recommended basic API [BASICAPI] will want to restrict 448 their index values to those that can be represented by the 449 sin6_scope_id field of a sockaddr_in6. 451 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 9 452 7. Sending Packets 454 When an upper-layer protocol sends a packet to a non-global 455 destination address, it must have a means of identifying to the IPv6 456 layer the intended zone, for cases in which the node is attached to 457 more than one zone of the destination address's scope. 459 Although identification of an outgoing interface is sufficient to 460 identify an intended zone (because each interface is attached to no 461 more than one zone of each scope), that is more specific than desired 462 in many cases. For example, when sending to a site-local unicast 463 address, from a node that has more than one interface to the intended 464 site, the upper layer protocol may not care which of those interfaces 465 is used for the transmission, but rather would prefer to leave that 466 choice to the routing function in the IP layer. Thus, the upper- 467 layer requires the ability to specify a zone index, rather than an 468 interface identifier, when sending to a non-global, non-loopback 469 destination address. 471 8. Receiving Packets 473 When an upper-layer protocol receives a packet containing a non- 474 global source or destination address, the zone to which that address 475 pertains can be determined from the arrival interface, because the 476 arrival interface can be attached to only one zone of the same scope 477 as the address under consideration. However, it is recommended that 478 the IP layer convey to the upper layer the correct zone indices for 479 the arriving source and destination addresses, in addition to the 480 arrival interface identifier. 482 9. Forwarding 484 When a router receives a packet addressed to a node other than itself, 485 it must take the zone of the destination and source addresses into 486 account as follows: 488 o The zone of the destination address is determined by the 489 scope of the address and arrival interface of the packet. 490 The next-hop interface is chosen by looking up the 491 destination address in a (conceptual) routing table 492 specific to that zone. That routing table is restricted 493 to refer only to interfaces belonging to that zone. 495 o After the next-hop interface is chosen, the zone of the 496 source address is considered. As with the destination 497 address, the zone of the source address is determined by 498 the scope of the address and arrival interface of the 499 packet. If transmitting the packet on the chosen next-hop 500 interface would cause the packet to leave the zone of the 502 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 10 503 source address, i.e., cross a zone boundary of the scope 504 of the source address, then the packet is discarded and an 505 ICMP Destination Unreachable message [RFC 2463] with Code 506 2 ("beyond scope of source address") is sent to the source 507 of the packet. 509 Note that the above procedure applies for addresses of all scopes, 510 including link-local. Thus, if a router receives a packet with a 511 link-local destination address that is not one of the router's own 512 link-local addresses on the arrival link, the router is expected to 513 try to forward the packet to the destination on that link (subject to 514 successful determination of the destination's link-layer address via 515 the Neighbor Discovery protocol [RFC 2461]). The forwarded packet may 516 be transmitted back out the arrival interface, or out any other 517 interface attached to the same link. 519 A node that receives a packet addressed to itself and containing a 520 Routing Header with more than zero Segments Left [RFC 2460, section 521 4.4] first checks the scope of the next address in the Routing Header. 522 If the scope of the next address is smaller than the scope of the 523 original destination address, the node MUST discard the packet. 524 Otherwise, it swaps the original destination address with the next 525 address in the Routing Header. Then the above forwarding rules apply 526 as follows: 528 o The zone of the new destination address is determined by 529 the scope of the next address in the Routing Header and 530 arrival interface of the packet. The next-hop interface 531 is chosen just like the first bullet of the rules above. 533 o After the next-hop interface is chosen, the zone of the 534 source address is considered just like the second bullet 535 of the rules above. 537 This check about the scope of the next address ensures that when a 538 packet arrives at its final destination, if that destination is link- 539 local then the receiving node can know that the packet originated on- 540 link. Similarly, if the destination is site-local then the receiving 541 node can know that the packet originated within the site. And, as a 542 result, this will help the receiving node send a "response" packet with 543 the final destination of the received packet as the source address 544 without breaking its source zone. 546 Note that it is possible, though generally inadvisable, to use a 547 Routing Header to convey a non-global address across its associated 548 zone boundary. For example, consider a case where a site-border node 549 receives a packet with the destination being a site-local address. If 550 the packet contains a Routing Header where the next address is a global 551 address, the next-hop interface to the global address may belong to a 553 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 11 554 different site than the site of the original destination. This is 555 allowed, because the scope of the next address is not smaller than the 556 scope of the original destination. 558 10. Routing 560 When a routing protocol determines that it is operating on a zone 561 boundary, it MUST protect inter-zone integrity and maintain intra- 562 zone connectivity. 564 In order to maintain connectivity, the routing protocol must be able 565 to create forwarding information for the global prefixes as well as 566 for all of the zone prefixes for each of its attached zones. The 567 most straightforward way of doing this is to create (conceptual) 568 forwarding tables for each specific zone. 570 To protect inter-zone integrity, routers must be selective in the 571 prefix information that is shared with neighboring routers. Routers 572 routinely exchange routing information with neighboring routers. 573 When a router is transmitting this routing information, it must not 574 include any information about zones other than the zones assigned to 575 the interface used to transmit the information. 577 * * 578 * * 579 * =========== Site X * 580 * | | * 581 * | | * 582 +-*----|-------|------+ * 583 | * intf1 intf2 | * 584 | * | * 585 | * intf3 --- * 586 | * | * 587 | *********************************** 588 | | 589 | Router | 590 | | 591 ********************** ********************** 592 | * * | 593 Site Y --- intf4 * * intf5 --- Site Z 594 | * * | 595 ********************** ********************** 596 +---------------------+ 598 Figure 4: Multi-Sited Router 600 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 12 601 As an example, the router in Figure 4 must exchange routing 602 information on five interfaces. The information exchanged is as 603 follows: 605 o Interface 1 607 o All global prefixes 609 o All site prefixes learned from Interfaces 1, 2, and 3 611 o Interface 2 613 o All global prefixes 615 o All site prefixes learned from Interfaces 1, 2, and 3 617 o Interface 3 619 o All global prefixes 621 o All site prefixes learned from Interface 1, 2, and 3 623 o Interface 4 625 o All global prefixes 627 o All site prefixes learned from Interface 4 629 o Interface 5 631 o All global prefixes 633 o All site prefixes learned from Interfaces 5 635 By imposing route exchange rules, zone integrity is maintained by 636 keeping all zone-specific routing information contained within the 637 zone. 639 11. Mobility 641 A mobile node using [MOBILE] can use site-local addresses as its home 642 addresses and/or care-of addresses when the node moves within its 643 "home site" and only communicates with nodes in the home site. In 644 general, however, several issues should be considered. This section 645 describes some of the issues and gives a hint of safe usage to 646 implementations. 648 If a mobile node using a site-local care-of address tries to 649 communicate with an off-site destination, the packet will be 650 discarded by a site-border router. This is especially the case when 652 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 13 653 the mobile node is in a different site from its home site and tries 654 to communicate with its home agent. This is also the case when the 655 correspondent node is in a different site from the foreign site of 656 the mobile node (though there is nothing specific to mobile IPv6 in 657 this particular case). 659 A mobile node could use a site-local home address even outside its 660 home site, if the mobile node can act as a multi-sited node. In this 661 case the mobile node is considered as connected to its home site over 662 a tunnel link between the mobile node and the home agent. The only 663 feasible usage in this situation is to use the tunnel link as a 664 bidirectional tunnel and to perform all communication using the site- 665 local home address via the tunnel link. Otherwise, the site-local 666 home address would (implicitly) break the site zone boundary. 668 In any case, the mobile node will need an ability to tell whether the 669 node is in its home site, in order to deal with the issues described 670 above. Since there is currently no standard way to provide such an 671 ability, it is RECOMMENDED for a mobile node to use global home and 672 care-of addresses whenever possible, unless the node somehow has a 673 guarantee that the site-local addresses can be used safely (e.g., by 674 a manual configuration). 676 12. Textual Representation 678 As already mentioned, to specify an IPv6 non-global address without 679 ambiguity, an intended scope zone should be specified as well. As a 680 common notation to specify the scope zone, an implementation SHOULD 681 support the following format. 683
% 685 where 686
is a literal IPv6 address, 687 is a string to identify the zone of the address, and 688 �%� is a delimeter character to distinguish between
689 and . 691 The following subsections describe detail definitions, concrete 692 examples, and additional notes of the format. 694 12.1 Non-Global Addresses 696 The format applies to all kinds of unicast and multicast addresses of 697 non-global scope except the unspecified address, which does not have a 698 scope. The format is meaningless and should not be used for global 699 addresses. The loopback address belongs to the trivial link, i.e., the 700 link attached to the loopback interface, thus the format should not be 702 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 14 703 used for the loopback interface either. This document does not specify 704 the usage of the format when the
is the unspecified address, 705 since the address does not have a scope. This document, however, does 706 not prohibit an implementation from using the format for those special 707 addresses for implementation dependent purposes. 709 12.2 Zone Indices 711 In the textual representation, the part should be able to 712 identify a particular zone of the address' scope. Although a zone 713 index is expected to contain the scope type and to be unique among all 714 scopes as described in Section 6 of this document, the part 715 of this format does not have to contain the scope type because the 716
part should specify the appropriate scope. This also means 717 the part does not have to be unique among all scopes. 719 With this loosened property, an implementation can use convenient 720 representation as . For example, to represent link index 2, 721 the implementation can simply use "2" as , which would be more 722 readable than other representation that contains the scope type "link". 724 When an implementation interprets the format, it should construct the 725 "full" zone ID, which contains the scope type, from the part 726 and the scope type specified by the
part. 728 An implementation SHOULD support at least numerical indices as 729 , which are non-negative decimal integers. The default zone 730 ID, which is typically expected to be 0, is included in the integers. 731 When is the default, the delimiter character, "%", and 732 can be omitted. Similarly, if a textual representation of 733 an IPv6 address is given without a zone ID, it should be interpreted 734 as
% where is the default zone ID 735 of the scope that
has. 737 An implementation MAY support other kinds of non-null strings as 738 . However, the strings must not conflict with the delimiter 739 character. The precise format and semantics of such additional 740 strings is implementation dependent. 742 One possible candidate of such strings would be interface names, 743 since interfaces uniquely disambiguate any type of scopes. In 744 particular, interface names can be used as "default identifiers" for 745 interfaces, links, and subnets, because there is, by default, a one- 746 to-one mapping between interfaces and each of those scopes as 747 described in Section 6. 749 An implementation could also use interface names as for 750 larger scopes than subnets, but there might be some confusion in such 751 use. For example, when more than one interface belongs to a same 753 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 15 754 site, a user would be confused about which interface should be used. 755 Also, a mapping function from an address to a name would encounter a 756 same kind of problem, when it prints an address with an interface 757 name as a zone index. This document does not specify how these cases 758 should be treated and leaves it implementation dependent. 760 It cannot be assumed that a same index is common to all nodes in a 761 zone (see Section 6). Hence, the format MUST be used only within a 762 node and MUST NOT be sent on a wire unless every node that interprets 763 the format agrees with the semantics. 765 12.3 Examples 767 Here are examples. The following addresses 769 fe80::1234 (on the 1st link of the node) 770 fec0::5678 (on the 2nd site of the node) 771 ff02::9abc (on the 5th link of the node) 772 ff08::def0 (on the 10th organization of the node) 774 would be represented as follows: 776 fe80::1234%1 777 fec0::5678%2 778 ff02::9abc%5 779 ff08::def0%10 781 (Here we assume a natual translation from a zone index to the 782 part where the Nth zone of any scope is translated into 783 �N�.) 785 If we use interface names as , those addresses could also be 786 represented as follows: 788 fe80::1234%ne0 789 fec0::5678%ether2 790 ff02::9abc%pvc1.3 791 ff08::def0%interface10 793 where the interface "ne0" belongs to 1st link, "ether2" belongs to 794 2nd site, and so on. 796 12.4 Usage Examples 798 Applications that are supposed to be used in end hosts like telnet, 799 ftp, and ssh, may not explicitly support the notion of address scope, 800 especially of link-local addresses. However, an expert user (e.g. a 801 network administrator) sometimes has to give even link-local 802 addresses to such applications. 804 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 16 805 Here is a concrete example. Consider a multi-linked router, called 806 "R1", that has at least two point-to-point interfaces (links). Each 807 of the interfaces is connected to another router, called "R2" and 808 "R3", respectively. Also assume that the point-to-point interfaces 809 are "unnumbered", that is, they have link-local addresses only. 811 Now suppose that the routing system on R2 hangs up and has to be 812 reinvoked. In this situation, we may not be able to use a global 813 address of R2, because this is a routing trouble and we cannot expect 814 that we have enough routes for global reachability to R2. 816 Hence, we have to login R1 first, and then try to login R2 using 817 link-local addresses. In such a case, we have to give the link-local 818 address of R2 to, for example, telnet. Here we assume the address is 819 fe80::2. 821 Note that we cannot just type like 823 % telnet fe80::2 825 here, since R1 has more than one link and hence the telnet command 826 cannot detect which link it should try to connect. Instead, we 827 should type the link-local address with the link index as follows: 829 % telnet fe80::2%3 831 where �3� after the delimiter character �%� conrresponds to the link 832 index of the point-to-point link. 834 Another example is an EBGP peering. When two IPv6 ISPs establish an 835 EBGP peering, using a particular ISP's global addresses for the peer 836 would be unfair, and using their link-local addresses would be better 837 in a neutral IX. In such a case, link-local addresses should be 838 specified in a router's configuration file and the link for the 839 addresses should be disambiguated, since a router usually connects to 840 multiple links. 842 12.5 Related API 844 The "Basic Socket API" [BASICAPI] defines how the format for non- 845 global addresses should be treated in library functions that 846 translate a nodename to an address, or vice versa. 848 12.6 Omitting Zone Indices 850 The format defined in this document does not intend to invalidate the 851 original format for non-global addresses, that is, the format without 852 the zone index portion. As described in Section 6, in some common 853 cases with the notion of the default zone ID, there can be no 854 ambiguity about scope zones. In such an environment, the 856 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 17 857 implementation can omit the "%" part, and, as a result, it 858 can act as if it did not support the extended format at all. 860 12.7 Combinations of Delimiter Characters 862 There are other kinds of delimiter characters defined for IPv6 863 addresses. In this subsection, we describe how they should be 864 combined with the format for non-global addresses. 866 The IPv6 addressing architecture [ADDRARCH] also defines the syntax 867 of IPv6 prefixes. If the address portion of a prefix is non-global 868 and its scope zone should be disambiguated, the address portion 869 SHOULD be in the format. For example, the prefix fec0:0:0:1::/64 on 870 the 2nd site can be represented as follows: 872 fec0:0:0:1::%2/64 874 In this combination, it is important to place the zone index portion 875 before the prefix length, when we consider parsing the format by a 876 name-to-address library function [BASICAPI]. That is, we can first 877 separate the address with the zone index from the prefix length, and 878 just pass the former to the library function. 880 The preferred format for literal IPv6 addresses in URL's are also 881 defined [RFC 2732]. When a user types the preferred format for an 882 IPv6 non-global address whose zone should be explicitly specified, 883 the user could use the format for the non-global address combined 884 with the preferred format. 886 However, the typed URL is often sent on a wire, and it would cause 887 confusion if an application did not strip the portion 888 before sending. Also, the format for non-global addresses might 889 conflict with the URI syntax [RFC 2396], since the syntax defines the 890 delimiter character (`%') as the escape character. 892 Hence, this document does not specify how the format for non-global 893 addresses should be combined with the preferred format for literal 894 IPv6 addresses. As for the conflict issue with the URI format, it 895 would be better to wait until the relationship between the preferred 896 format and the URI syntax is clarified. In fact, the preferred 897 format for IPv6 literal addresses itself has same kind of conflict. 898 In any case, it is recommended to use an FQDN instead of a literal 899 IPv6 address in a URL, whenever an FQDN is available. 901 13. Security Considerations 903 The routing section of this document specifies a set of guidelines 904 that allow routers to prevent zone-specific information from leaking 905 out of each site. If site boundary routers allow site routing 907 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 18 908 information to be forwarded outside of the site, the integrity of the 909 site could be compromised. 911 Since the use of the textual representation of non-global addresses 912 is restricted within a single node, it does not create a security 913 vulnerability from outside the node. However, a malicious node might 914 send a packet that contains a textual IPv6 non-global address with a 915 zone index, intending to deceive the receiving node about the zone of 916 the non-global address. Thus, an implementation should be careful 917 when it receives packets that contain textual non-global addresses as 918 data. 920 14. References 922 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 923 Requirement Levels", RFC 2119, BCP14, March 1999. 925 [ADDRARCH] Hinden, R., and Deering, S., "IP Version 6 Addressing 926 Architecture", Internet Draft, draft-ietf-ipngwg-addr- 927 arch-v3-07.txt, November 2001. 929 [ADDRSELECT] Richard Draves, �Default Address Selection for Ipv6�, 930 Internet-Draft, draft-ietf-ipv6-default-addr-select- 931 07.txt, March 2002. 933 [RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version 934 6 (IPv6) Specification", RFC 2460, December 1998. 936 [RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in 937 IPv6 Specification", RFC 2473, December 1998. 939 [RFC 2463] Conta, A., and Deering, S., "Internet Control Message 940 Protocol (RFC 2463) for Internet Protocol Version 6 941 (IPv6)", RFC 2463, December 1998. 943 [RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 944 Discovery for IP Version 6 (IPv6)", RFC 2461, December 945 1998. 947 [MOBILE] Johnson, D.B., Perkins, C., and Arkko, J., "Mobility 948 support in IPv6", Internet Draft, draft-ietf-mobileip- 949 ipv6-17, May 2002. 951 [BASICAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., 952 "Basic Socket Interface Extensions for IPv6", Internet 953 Draft, draft-ietf-ipngwg-rfc2553bis-05.txt, February 2001. 955 [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Preferred 956 Format for Literal IPv6 Addresses in URL's", RFC 2732, 957 December 1999. 959 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 19 961 [RFC 2396] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform 962 Resource Identifiers (URI): Generic Syntax", RFC 2396, 963 August 1998. 965 Acknowledgements 967 Authors' Addresses 969 Stephen E. Deering 970 Cisco Systems, Inc. 971 170 West Tasman Drive 972 San Jose, CA 95134-1706 973 USA 975 Phone: +1-408-527-8213 976 Fax: +1-408-527-8213 977 Email: deering@cisco.com 979 Brian Haberman 980 Consultant 982 Phone: +1-919-949-4828 983 Email: bkhabs@nc.rr.com 985 Tatuya JINMEI 986 Corporate Research & Development Center, Toshiba Corporation 987 1 Komukai Toshiba-cho, Kawasaki-shi 988 Kanagawa 212-8582, JAPAN 990 Phone: +81-44-549-2230 991 Fax: +81-44-520-1841 992 Email: jinmei@isl.rdc.toshiba.co.jp 994 Erik Nordmark 995 Sun Microsystems Laboratories, Europe 996 29 Chemin du Vieux Chene 997 38240 Meylan, France 999 Phone: +33 (0)4 76 18 88 03 1000 Fax: +33 (0)4 76 18 88 88 1001 Email: Erik.Nordmark@sun.com 1003 Atsushi Onoe 1004 IT Development Division, NSC, Sony Corporation 1005 6-7-35 Kitashinagawa, Shinagawa-ku 1007 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 20 1008 Tokyo 141-0001, JAPAN 1010 Phone: +81-3-5475-8491 1011 Fax: +81-3-5475-8977 1012 Email: onoe@sm.sony.co.jp 1014 Brian D. Zill 1015 Microsoft Research 1016 One Microsoft Way 1017 Redmond, WA 98052-6399 1018 USA 1020 Phone: +1-425-703-3568 1021 Fax: +1-425-936-7329 1022 Email: bzill@microsoft.com 1024 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 21