idnits 2.17.1 draft-ietf-ipv6-scoping-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 36 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2003) is 7607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3513 (ref. '1') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-02 -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 3493 (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '7') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '8') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2732 (ref. '9') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '10') (Obsoleted by RFC 3986) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Deering 3 Internet-Draft Cisco Systems 4 Expires: December 22, 2003 B. Haberman 5 Caspian Networks 6 T. Jinmei 7 Toshiba 8 E. Nordmark 9 Sun Microsystems 10 A. Onoe 11 Sony 12 B. Zill 13 Microsoft 14 June 23, 2003 16 IPv6 Scoped Address Architecture 17 draft-ietf-ipv6-scoping-arch-00.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 22, 2003. 42 Copyright Notice 44 Copyright (C) The Internet Society (2003). All Rights Reserved. 46 Abstract 48 This document specifies the architectural characteristics, expected 49 behavior, textual representation, and usage of IPv6 addresses of 50 different scopes. According to a decision in the IPv6 working group, 51 this document intentionally avoids using the syntax and usage of 52 unicast site-local addresses. 54 1. Introduction 56 Internet Protocol version 6 includes support for addresses of 57 different "scope", that is, both global and non-global (e.g., link- 58 local) addresses. While non-global addressing has been introduced 59 operationally in the IPv4 Internet, both in the use of private 60 address space ("net 10", etc.) and with administratively scoped 61 multicast addresses, the design of IPv6 formally incorporates the 62 notion of address scope into its base architecture. This document 63 specifies the architectural characteristics, expected behavior, 64 textual representation, and usage of IPv6 addresses of different 65 scopes. 67 Though the current specification [1] defines unicast site-local 68 addresses, the IPv6 working group decided to deprecate the syntax and 69 the usage and is now investigating other forms of local IPv6 70 addressing. The usage of any new forms of local addresses will be 71 documented elsewhere in the future. Thus, this document 72 intentionally focuses on link-local and multicast scopes only. 74 2. Definitions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [2]. 80 3. Basic Terminology 82 The terms link, interface, node, host, and router are defined in [3]. 83 The definitions of unicast address scopes (link-local and global) and 84 multicast address scopes (interface-local, link-local, etc.) are 85 contained in [1]. 87 4. Address Scope 89 Every IPv6 address other than the unspecified address has a specific 90 scope, that is, a topological span within which the address may be 91 used as a unique identifier for an interface or set of interfaces. 92 The scope of an address is encoded as part of the address, as 93 specified in [1]. 95 For unicast addresses, this document discusses two defined scopes: 97 o Link-local scope, for uniquely identifying interfaces within 98 (i.e., attached to) a single link only. 100 o Global scope, for uniquely identifying interfaces anywhere in the 101 Internet. 103 The IPv6 unicast loopback address, ::1, is treated as having link- 104 local scope within an imaginary link to which a virtual "loopback 105 interface" is attached. 107 The unspecified address, ::, is a special case. It does not have any 108 scope, because it must never be assigned to any node according to 109 [1]. Note, however, that an implementation might use an 110 implementation dependent semantics for the unspecified address and 111 may want to allow the unspecified address to have specific scopes. 112 For example, implementations often use the unspecified address to 113 represent "any" address in APIs. In such a case, implementations may 114 want to regard the address in a particular scope to represent the 115 notion of "any addresses in the scope." This document does not 116 prohibit such a usage, as long as it is limited within the 117 implementation. 119 [1] defines IPv6 addresses with embedded IPv4 addresses as part of 120 global addresses. Thus, those addresses have global scope, with 121 regards to the IPv6 scoped address architecture. However, an 122 implementation may use those addresses as if they had other type of 123 scopes for convenience. For instance, [7] assigns link-local scope 124 to IPv4 auto-configuration addresses, and converts those addresses 125 into IPv4-mapped IPv6 addresses in order for destination address 126 selection among IPv4 and IPv6 addresses. This would implicitly mean 127 IPv4-mapped addresses correspondent to IPv4 auto-configuration 128 addresses have link-local scope. This document does not preclude 129 such a usage, as long as it is limited within the implementation. 131 Anycast addresses [1] are allocated from the unicast address space 132 and have the same scope properties as unicast addresses. All 133 statements in this document regarding unicast apply equally to 134 anycast. 136 For multicast addresses, there are fourteen possible scopes, ranging 137 from interface-local to global (including link-local). The 138 interface-local scope spans a single interface only; a multicast 139 address of interface-local scope is useful only for loopback delivery 140 of multicasts within a single node, for example, as a form of inter- 141 process communication within a computer. Unlike the unicast loopback 142 address, interface-local multicast addresses may be assigned to any 143 interface. 145 There is a size relationship among scopes: 147 o for unicast scopes, link-local is a smaller scope than global. 149 o for multicast scopes, scopes with lesser values in the "scop" 150 subfield of the multicast address (Section 2.7 of [1]) are smaller 151 than scopes with greater values, with interface-local being the 152 smallest and global being the largest. 154 However, two scopes of different size may cover the exact same region 155 of topology. For example, a (multicast) site may consist of a single 156 link, in which both link-local and site-local scope effectively cover 157 the same topological span. 159 5. Scope Zones 161 A scope zone, or a simply a zone, is a connected region of topology 162 of a given scope. For example, the set of links connected by routers 163 within a particular (multicast) site, and the interfaces attached to 164 those links, comprise a single zone of multicast site-local scope. 165 Note that a zone is a particular instance of a topological region 166 (e.g., Alice's site or Bob's site), whereas a scope is the size of a 167 topological region (i.e., a site or a link or a ...). 169 The zone to which a particular non-global address pertains is not 170 encoded in the address itself, but rather is determined by context, 171 such as the interface from which it is sent or received. Thus, 172 addresses of a given (non-global) scope may be re-used in different 173 zones of that scope. For example, two different physical links may 174 each contain a node with link-local address fe80::1. 176 Zones of the different scopes are instantiated as follows: 178 o Each interface on a node comprises a single zone of interface- 179 local scope (for multicast only). 181 o Each link, and the interfaces attached to that link, comprises a 182 single zone of link-local scope (for both unicast and multicast). 184 o There is a single zone of global scope (for both unicast and 185 multicast), comprising all the links and interfaces in the 186 Internet. 188 o The boundaries of zones of scope other than interface-local, link- 189 local, and global must be defined and configured by network 190 administrators. 192 Zone boundaries are relatively static features, not changing in 193 response to short-term changes in topology. Thus, the requirement 194 that the topology within a zone be "connected" is intended to include 195 links and interfaces that may be only occasionally connected. For 196 example, a residential node or network that obtains Internet access 197 by dial-up to an employer's (multicast) site may be treated as part 198 of the employer's (multicast) site-local zone even when the dial-up 199 link is disconnected. Similarly, a failure of a router, interface, 200 or link that causes a zone to become partitioned does not split that 201 zone into multiple zones; rather, the different partitions are still 202 considered to belong to the same zone. 204 Zones have the following additional properties: 206 o Zone boundaries cut through nodes, not links. (Note that the 207 global zone has no boundary, and the boundary of an interface- 208 local zone encloses just a single interface.) 210 o Zones of the same scope cannot overlap, i.e., they can have no 211 links or interfaces in common. 213 o A zone of a given scope (less than global) falls completely within 214 zones of larger scope, i.e., a smaller scope zone cannot include 215 more topology than any larger scope zone with which it shares any 216 links or interfaces. 218 o Each zone is required to be "convex" from a routing perspective, 219 i.e., packets sent from one interface to any other interface in 220 the same zone are never routed outside the zone. 222 Each interface belongs to exactly one zone of each possible scope. 224 6. Zone Indices 226 Considering the fact that the same non-global address may be in use 227 in more than one zone of the same scope (e.g., the use of link-local 228 address fe80::1 in two separate physical links), and that a node may 229 have interfaces attached to different zones of the same scope (e.g., 230 a router normally has multiple interfaces attached to different 231 links), a node requires an internal means of identifying to which 232 zone a non-global address belongs. This is accomplished by 233 assigning, within the node, a distinct "zone index" to each zone of 234 the same scope to which that node is attached, and allowing all 235 internal uses of an address to be qualified by a zone index. 237 The assignment of zone indices is illustrated in the example in the 238 figure below: 240 --------------------------------------------------------------------- 242 --------------------------------------------------------------- 243 | a node | 244 | | 245 | | 246 | | 247 | | 248 | | 249 | | 250 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 251 | | 252 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 253 --------------------------------------------------------------- 254 : | | | | 255 : | | | | 256 : | | | | 257 (imaginary ================= a point- a 258 loopback an Ethernet to-point tunnel 259 link) link 261 Figure 1: Zone Indices Example 263 --------------------------------------------------------------------- 265 This example node has five interfaces: 267 A loopback interface to the imaginary loopback link (a phantom 268 link that goes nowhere), 270 Two interfaces to the same Ethernet, 272 An interface to a point-to-point link, and 274 A tunnel interface (e.g., the abstract endpoint of an IPv6-over- 275 IPv6 tunnel [6], presumably established over either the Ethernet 276 or the point-to-point link.) 278 It is thus attached to five interface-local zones, identified by the 279 interface indices 1 through 5. 281 Because the two Ethernet interfaces are attached to the same link, 282 the node is attached to only four link-local zones, identified by 283 link indices 1 through 4. 285 Each zone index of a particular scope should contain an information 286 to represent the scope type, so that all indices of all scopes are 287 unique within the node and zone indices themselves can be used for a 288 dedicated purpose. An entry of a Management Information Base (MIB) 289 will be an example of the dedicated purpose. The actual 290 representation to encode the scope type is implementation dependent 291 and is out of scope of this document. Within this document, indices 292 are simply represented like "link index 2" for readability. 294 The zone indices are strictly local to the node. For example, the 295 node on the other end of the point-to-point link may well be using 296 entirely different interface and link index values for that link. 298 An implementation should also support the concept of a "default" zone 299 for each scope. It is convenient to reserve the index value zero, at 300 each scope, to mean "use the default zone". Unlike other zone 301 indices, the default ID does not contain any scope type, and the 302 scope type is determined by the address by which the default ID was 303 accompanied. An implementation may additionally define a separate 304 default zone for each scope type. Those default indices can also be 305 used as the zone qualifier for an address for which the node is 306 attached to only one zone, e.g., when using global addresses. 308 There is at present no way for a node to automatically determine 309 which of its interfaces belong to the same zones, e.g., the same link 310 or the same multicast scope zone larger than interface. In the 311 future, protocols may be developed to determine that information. In 312 the absence of such protocols, an implementation must provide a means 313 for manual assignment and/or reassignment of zone indices. 314 Furthermore, to avoid the need to perform manual configuration in 315 most cases, an implementation should, by default, initially assign 316 zone indices as follows, and only as follows: 318 o A unique interface index for each interface 320 o A unique link index for each interface 322 o A unique subnet (multicast "scop" value 3) index for each 323 interface 325 Then, manual configuration would be necessary only for the less 326 common cases of nodes with multiple interfaces to a single link or a 327 single subnet, interfaces to different sites, or interfaces to zones 328 of different (multicast-only) scopes. 330 Thus, the default zone index assignments for the example node from 331 Figure 1 would be as illustrated in Figure 2, below. Manual 332 configuration would then be required to, for example, assign the same 333 link index to the two Ethernet interfaces as shown in Figure 1. 335 --------------------------------------------------------------------- 337 --------------------------------------------------------------- 338 | a node | 339 | | 340 | | 341 | | 342 | | 343 | | 344 | /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ | 345 | | 346 | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | 347 | | 348 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 349 --------------------------------------------------------------- 350 : | | | | 351 : | | | | 352 : | | | | 353 (imaginary ================= a point- a 354 loopback an Ethernet to-point tunnel 355 link) link 357 Figure 2: Example of Default Zone Indices 359 --------------------------------------------------------------------- 361 As well as initially assigning zone indices, as specified above, an 362 implementation should automatically select a default zone for each 363 scope for which there is more than one choice, to be used whenever an 364 address is specified without a zone index (or with a zone index of 365 zero). For instance, in the example shown in Figure 2, the 366 implementation might automatically select intf2, link2, and subnet2 367 as the default zones for each of those three scopes. (Perhaps the 368 selection algorithm is to choose the first zone that includes an 369 interface other than the loopback interface as the default for each 370 scope.) A means must also be provided for manually assigning the 371 default zone for a scope, overriding any automatic assignment. 373 Because the unicast loopback address, ::1, may not be assigned to any 374 interface other than the loopback interface, it is recommended that, 375 whenever ::1 is specified without a zone index, or with the default 376 zone index, it be interpreted as belonging to the loopback link-local 377 zone, regardless of which link-local zone has been selected as the 378 default. If this is done, then in the common case of nodes with only 379 a single non-loopback interface (e.g., a single Ethernet interface), 380 it becomes possible to avoid any need to qualify link- local 381 addresses with a zone index: the unqualified address ::1 would always 382 refer to the link-local zone containing the loopback interface, and 383 all other unqualified link-local addresses would refer to the link- 384 local zone containing the non-loopback interface (as long as the 385 default link-local zone were set to be the zone containing the non- 386 loopback interface). 388 Because of the requirement that a zone of a given scope fall 389 completely within zones of larger scope (see Section 5, above), if 390 two interfaces are assigned to different zones of scope S, they must 391 also be assigned to different zones of all scopes smaller than S. 392 Thus, the manual assignment of distinct zone indices for one scope 393 may require the automatic assignment of distinct zone indices for 394 smaller scopes. For example, suppose that distinct multicast site- 395 local indices 1 and 2 are manually assigned in Figure 1 and that site 396 1 contains link 1, 2, and 3, while site 2 only contains link 4. This 397 configuration would then cause the automatic creation of 398 corresponding admin-local (i.e. multicast "scop" value 4) indices 1 399 and 2, because admin-local scope is smaller than site-local scope. 401 Taking all of the above considerations in account, the complete set 402 of zone indices for our example node from Figure 1 with the 403 additional configurations here is shown in Figure 3, below. 405 --------------------------------------------------------------------- 407 --------------------------------------------------------------- 408 | a node | 409 | | 410 | | 411 | | 412 | | 413 | | 414 | /--------------------site1--------------------\ /--site2--\ | 415 | | 416 | /-------------------admin1--------------------\ /-admin2--\ | 417 | | 418 | /-subnet1-\ /-------subnet2-------\ /-subnet3-\ /-subnet4-\ | 419 | | 420 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 421 | | 422 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 423 --------------------------------------------------------------- 424 : | | | | 425 : | | | | 426 : | | | | 427 (imaginary ================= a point- a 428 loopback an Ethernet to-point tunnel 429 link) link 431 Figure 3: Complete Zone Indices Example 433 --------------------------------------------------------------------- 435 Although the examples above show the zones being assigned index 436 values sequentially for each scope, starting at one, the zone index 437 values are arbitrary. An implementation may use any value it chooses 438 to label a zone as long as it meets the requirement that the index 439 value of each zone of all scopes be unique within the node. 440 Similarly, an implementation may choose an index value other than 441 zero to represent the default zone. Implementations choosing to 442 follow the recommended basic API [5] will want to restrict their 443 index values to those that can be represented by the sin6_scope_id 444 field of a sockaddr_in6 structure. 446 7. Sending Packets 448 When an upper-layer protocol sends a packet to a non-global 449 destination address, it must have a means of identifying to the IPv6 450 layer the intended zone, for cases in which the node is attached to 451 more than one zone of the destination address's scope. 453 Although identification of an outgoing interface is sufficient to 454 identify an intended zone (because each interface is attached to no 455 more than one zone of each scope), that is more specific than desired 456 in many cases. For example, when sending to a link-local unicast 457 address, from a node that has more than one interface to the intended 458 link (though this is an unusual configuration), the upper layer 459 protocol may not care which of those interfaces is used for the 460 transmission, but rather would prefer to leave that choice to the 461 routing function in the IP layer. Thus, the upper-layer requires the 462 ability to specify a zone index, rather than an interface identifier, 463 when sending to a non-global, non-loopback destination address. 465 8. Receiving Packets 467 When an upper-layer protocol receives a packet containing a non- 468 global source or destination address, the zone to which that address 469 pertains can be determined from the arrival interface, because the 470 arrival interface can be attached to only one zone of the same scope 471 as the address under consideration. However, it is recommended that 472 the IP layer convey to the upper layer the correct zone indices for 473 the arriving source and destination addresses, in addition to the 474 arrival interface identifier. 476 9. Forwarding 478 When a router receives a packet addressed to a node other than 479 itself, it must take the zone of the destination and source addresses 480 into account as follows: 482 o The zone of the destination address is determined by the scope of 483 the address and arrival interface of the packet. The next-hop 484 interface is chosen by looking up the destination address in a 485 (conceptual) routing table specific to that zone. That routing 486 table is restricted to refer only to interfaces belonging to that 487 zone. 489 o After the next-hop interface is chosen, the zone of the source 490 address is considered. As with the destination address, the zone 491 of the source address is determined by the scope of the address 492 and arrival interface of the packet. If transmitting the packet 493 on the chosen next-hop interface would cause the packet to leave 494 the zone of the source address, i.e., cross a zone boundary of the 495 scope of the source address, then the packet is discarded and an 496 ICMP Destination Unreachable message [4] with Code 2 ("beyond 497 scope of source address") is sent to the source of the packet. 499 Note that even with the decision that unicast site-local addresses 500 are deprecated, the above procedure still applies to link-local 501 addresses. Thus, if a router receives a packet with a link-local 502 destination address that is not one of the router's own link-local 503 addresses on the arrival link, the router is expected to try to 504 forward the packet to the destination on that link (subject to 505 successful determination of the destination's link-layer address via 506 the Neighbor Discovery protocol [8]). The forwarded packet may be 507 transmitted back out the arrival interface, or out any other 508 interface attached to the same link. 510 A node that receives a packet addressed to itself and containing a 511 Routing Header with more than zero Segments Left (Section 4.4 of [3]) 512 first checks the scope of the next address in the Routing Header. If 513 the scope of the next address is smaller than the scope of the 514 original destination address, the node MUST discard the packet. 515 Otherwise, it swaps the original destination address with the next 516 address in the Routing Header. Then the above forwarding rules apply 517 as follows: 519 o The zone of the new destination address is determined by the scope 520 of the next address in the Routing Header and arrival interface of 521 the packet. The next-hop interface is chosen just like the first 522 bullet of the rules above. 524 o After the next-hop interface is chosen, the zone of the source 525 address is considered just like the second bullet of the rules 526 above. 528 This check about the scope of the next address ensures that when a 529 packet arrives at its final destination, if that destination is link- 530 local then the receiving node can know that the packet originated on- 531 link. As a result, this will help the receiving node send a 532 "response" packet with the final destination of the received packet 533 as the source address without breaking its source zone. 535 Note that it is possible, though generally inadvisable, to use a 536 Routing Header to convey a non-global address across its associated 537 zone boundary. For example, consider a case where a link-border node 538 (e.g., a router) receives a packet with the destination being a link- 539 local address. If the packet contains a Routing Header where the 540 next address is a global address, the next-hop interface to the 541 global address may belong to a different link than that of the 542 original destination. This is allowed, because the scope of the next 543 address is not smaller than the scope of the original destination. 545 10. Routing 547 Note: since unicast site-local addresses are deprecated, and link- 548 local addresses does not need routing, the discussion in this section 549 only applies to multicast scoped routing. 551 When a routing protocol determines that it is operating on a zone 552 boundary, it MUST protect inter-zone integrity and maintain intra- 553 zone connectivity. 555 In order to maintain connectivity, the routing protocol must be able 556 to create forwarding information for the global prefixes as well as 557 for all of the zone prefixes for each of its attached zones. The 558 most straightforward way of doing this is to create (conceptual) 559 forwarding tables for each specific zone. 561 To protect inter-zone integrity, routers must be selective in the 562 prefix information that is shared with neighboring routers. Routers 563 routinely exchange routing information with neighboring routers. 564 When a router is transmitting this routing information, it must not 565 include any information about zones other than the zones assigned to 566 the interface used to transmit the information. 568 --------------------------------------------------------------------- 570 * * 571 * * 572 * =========== Organization X * 573 * | | * 574 * | | * 575 +-*----|-------|------+ * 576 | * intf1 intf2 | * 577 | * | * 578 | * intf3 --- * 579 | * | * 580 | *********************************** 581 | | 582 | Router | 583 | | 584 ********************** ********************** 585 | * * | 586 Org. Y --- intf4 * * intf5 --- Org. Z 587 | * * | 588 ********************** ********************** 589 +---------------------+ 591 Figure 4: Multi-Organization Multicast Router 593 --------------------------------------------------------------------- 595 As an example, the router in Figure 4 must exchange routing 596 information on five interfaces. The information exchanged is as 597 follows (for simplicity, multicast scopes smaller or larger than 598 organization except global are not considered here): 600 o Interface 1 602 * All global prefixes 604 * All organization prefixes learned from Interfaces 1, 2, and 3 606 o Interface 2 608 * All global prefixes 610 * All organization prefixes learned from Interfaces 1, 2, and 3 612 o Interface 3 614 * All global prefixes 616 * All organization prefixes learned from Interface 1, 2, and 3 618 o Interface 4 620 * All global prefixes 622 * All organization prefixes learned from Interface 4 624 o Interface 5 626 * All global prefixes 628 * All organization prefixes learned from Interfaces 5 630 By imposing route exchange rules, zone integrity is maintained by 631 keeping all zone-specific routing information contained within the 632 zone. 634 11. Textual Representation 636 As already mentioned, to specify an IPv6 non-global address without 637 ambiguity, an intended scope zone should be specified as well. As a 638 common notation to specify the scope zone, an implementation SHOULD 639 support the following format. 641
%