idnits 2.17.1 draft-ietf-ipngwg-scoping-arch-02.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. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2553BIS' is mentioned on line 779, but not defined ** Obsolete undefined reference: RFC 2553 (Obsoleted by RFC 3493) == Unused Reference: 'RFC 2460' is defined on line 845, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ipngwg-addr-arch-v3-04 ** 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) ** Obsolete normative reference: RFC 2553 (Obsoleted by RFC 3493) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 -- Possible downref: Non-RFC (?) normative reference: ref. 'BASICAPI' ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 3 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-02.txt B. Haberman 5 March 2001 Nortel Networks 6 Expires September 2001 T. Jinmei 7 Toshiba 8 E. Nordmark 9 Sun Microsystems 10 A. Onoe 11 Sony 12 B. Zill 13 Microsoft 15 IPv6 Scoped Address Architecture 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies the architectural characteristics, expected 39 behavior, textual representation, and usage of IPv6 addresses of 40 different scopes. 42 1. Introduction 44 Internet Protocol version 6 includes support for addresses of 45 different "scope", that is, both global and non-global (e.g., link- 46 local, site-local, etc.) addresses. While non-global addressing has 47 been introduced operationally in the IPv4 Internet, both in the use 48 of private address space ("net 10", etc.) and with administratively 49 scoped multicast addresses, the design of IPv6 formally incorporates 51 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 1 52 the notion of address scope into its base architecture. This 53 document specifies the architectural characteristics, expected 54 behavior, textual representation, and usage of IPv6 addresses of 55 different scopes. 57 2. Definitions 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC 2119]. 63 3. Basic Terminology 65 The terms link, interface, node, host, and router are defined in [RFC 66 2460]. The definitions of unicast address scopes (link-local, site- 67 local, and global) and multicast address scopes (interface-local, 68 link-local, etc.) are contained in [ADDRARCH]. 70 4. Address Scope 72 Every IPv6 address has a specific scope, that is, a topological span 73 within which the address may be used as a unique identifier for an 74 interface or set of interfaces. The scope of an address is encoded 75 as part of the address, as specified in [ADDRARCH]. 77 For unicast addresses, there are three defined scopes: 79 o Link-local scope, for uniquely identifying interfaces 80 within (i.e., attached to) a single link only. 82 o Site-local scope, for uniquely identifying interfaces 83 within a single site only. A "site" is, by intent, not 84 rigorously defined, but is typically expected to cover a 85 region of topology that belongs to a single organization 86 and is located within a single geographic location, such 87 as an office, an office complex, or a campus. A personal 88 residence may be treated as a site (for example, when the 89 residence obtains Internet access via a public Internet 90 service provider), or as a part of a site (for example, 91 when the residence obtains Internet access via an 92 employer's or school's site). 94 o Global scope, for uniquely identifying interfaces anywhere 95 in the Internet. 97 The IPv6 unicast loopback address, ::1, is treated as having link- 98 local scope within an imaginary link to which a virtual "loopback 99 interface" is attached. 101 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 2 102 Anycast addresses [ADDRARCH] are allocated from the unicast address 103 space and have the same scope properties as unicast addresses. All 104 statements in this document regarding unicast apply equally to 105 anycast. 107 For multicast addresses, there are fourteen possible scopes, ranging 108 from interface-local to global (including both link-local and site- 109 local). The interface-local scope spans a single interface only; a 110 multicast address of interface-local scope is useful only for 111 loopback delivery of multicasts within a single node, for example, as 112 a form of inter-process communication within a computer. Unlike the 113 unicast loopback address, interface-local multicast addresses may be 114 assigned to any interface. 116 There is a size relationship among scopes: 118 o for unicast scopes, link-local is a smaller scope than 119 site-local, and site-local is a smaller scope than global. 121 o for multicast scopes, scopes with lesser values in the 122 "scop" subfield of the multicast address [ADDRARCH, 123 section 2.7] are smaller than scopes with greater values, 124 with interface-local being the smallest and global being 125 the largest. 127 However, two scopes of different size may cover the exact same region 128 of topology. For example, a site may consist of a single link, in 129 which both link-local and site-local scope effectively cover the same 130 topological span. 132 5. Scope Zones 134 A scope zone, or a simply a zone, is a connected region of topology 135 of a given scope. For example, the set of links connected by routers 136 within a particular site, and the interfaces attached to those links, 137 comprise a single zone of site-local scope. Note that a zone is a 138 particular instance of a topological region (e.g., Alice�s site or 139 Bob�s site), whereas a scope is the size of a topological region 140 (i.e., a site or a link or a ...). 142 The zone to which a particular non-global address pertains is not 143 encoded in the address itself, but rather is determined by context, 144 such as the interface from which it is sent or received. Thus, 145 addresses of a given (non-global) scope may be re-used in different 146 zones of that scope. For example, Alice's site and Bob's site may 147 each contain a node with site-local address fec0::1. 149 Zones of the different scopes are instantiated as follows: 151 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 3 152 o Each interface on a node comprises a single zone of 153 interface-local scope (for multicast only). 155 o Each link, and the interfaces attached to that link, 156 comprises a single zone of link-local scope (for both 157 unicast and multicast). 159 o There is a single zone of global scope (for both unicast 160 and multicast), comprising all the links and interfaces in 161 the Internet. 163 o The boundaries of zones of scope other than interface- 164 local, link-local, and global must be defined and 165 configured by network administrators. A site boundary 166 serves as such for both unicast and multicast. 168 Zone boundaries are relatively static features, not changing in 169 response to short-term changes in topology. Thus, the requirement 170 that the topology within a zone be "connected" is intended to include 171 links and interfaces that may be only occasionally connected. For 172 example, a residential node or network that obtains Internet access 173 by dial-up to an employer's site may be treated as part of the 174 employer's site-local zone even when the dial-up link is 175 disconnected. Similarly, a failure of a router, interface, or link 176 that causes a zone to become partitioned does not split that zone 177 into multiple zones; rather, the different partitions are still 178 considered to belong to the same zone. 180 Zones have the following additional properties: 182 o Zone boundaries cut through nodes, not links. (Note that 183 the global zone has no boundary, and the boundary of an 184 interface-local zone encloses just a single interface.) 186 o Zones of the same scope cannot overlap, i.e., they can 187 have no links or interfaces in common. 189 o A zone of a given scope (less than global) falls 190 completely within zones of larger scope, i.e., a smaller 191 scope zone cannot include more topology than any larger 192 scope zone with which it shares any links or interfaces. 194 Each interface belongs to exactly one zone of each possible scope. 196 6. Zone Indices 198 Considering the fact that the same non-global address may be in use 199 in more than one zone of the same scope (e.g., the use of site-local 200 address fec0::1 in both Alice's site and Bob's site), and that a node 201 may have interfaces attached to different zones of the same scope 203 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 4 204 (e.g., having one interface attached to Alice's site and another to 205 Bob's site), a node requires an internal means of identifying to 206 which zone a non-global address belongs. This is accomplished by 207 assigning, within the node, a distinct "zone index" to each zone of 208 the same scope to which that node is attached, and allowing all 209 internal uses of an address to be qualified by a zone index. 211 The assignment of zone indices is illustrated in the example in the 212 figure below: 214 --------------------------------------------------------------- 215 | a node | 216 | | 217 | | 218 | | 219 | | 220 | | 221 | /--------------------site1--------------------\ /--site2--\ | 222 | | 223 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 224 | | 225 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 226 --------------------------------------------------------------- 227 : | | | | 228 : | | | | 229 : | | | | 230 (imaginary ================= a point- a 231 loopback an Ethernet to-point tunnel 232 link) link 234 Figure 1 : Zone Indices Example 236 This example node has five interfaces: 238 o A loopback interface to the imaginary loopback link (a 239 phantom link that goes nowhere), 241 o Two interfaces to the same Ethernet, 243 o An interface to a point-to-point link, and 245 o A tunnel interface (e.g., the abstract endpoint of an 246 IPv6-over-IPv6 tunnel [RFC 2473], presumably established 247 over either the Ethernet or the point-to-point link.) 249 It is thus attached to five interface-local zones, identified by the 250 interface indices 1 through 5. 252 Because the two Ethernet interfaces are attached to the same link, 253 the node is attached to only four link-local zones, identified by 254 link indices 1 through 4. 256 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 5 257 It is attached to two site-local zones: one to which the loopback 258 link, the Ethernet, and the point-to-point link belong, and one to 259 which the tunnel belongs (perhaps because it is a tunnel to another 260 organization). These site-local zones are identified by the site 261 indices 1 and 2. 263 Note that each attached zone of the same scope must be assigned a 264 different index value, whereas attached zones of different scopes can 265 re-use the same index. 267 The zone indices are strictly local to the node. For example, the 268 node on the other end of the point-to-point link may well be using 269 entirely different interface, link, and site index values for that 270 link. 272 An implementation should also support the concept of a "default" zone 273 for each scope. It is convenient to reserve the index value zero, at 274 each scope, to mean "use the default zone". This default index can 275 also be used as the zone qualifier for an address for which the node 276 is attached to only one zone, e.g., when using global addresses. 278 There is at present no way for a node to automatically determine 279 which of its interfaces belong to the same zones, e.g., the same link 280 or the same site. In the future, protocols may be developed to 281 determine that information. In the absence of such protocols, an 282 implementation must provide a means for manual assignment and/or 283 reassignment of zone indices. Furthermore, to avoid the need to 284 perform manual configuration in most cases, an implementation should, 285 by default, initially assign zone indices as follows, and only as 286 follows: 288 o A unique interface index for each interface 290 o A unique link index for each interface 292 o A unique subnet (multicast "scop" value 3) index for each 293 interface 295 Then, manual configuration would be necessary only for the less 296 common cases of nodes with multiple interfaces to a single link or a 297 single subnet, interfaces to different sites, or interfaces to zones 298 of different (multicast-only) scopes. 300 Thus, the default zone index assignments for the example node from 301 Figure 1 would be as illustrated in Figure 2, below. Manual 302 configuration would then be required to, for example, assign the same 303 link index to the two Ethernet interfaces as shown in Figure 1. 305 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 6 306 --------------------------------------------------------------- 307 | a node | 308 | | 309 | | 310 | | 311 | | 312 | | 313 | /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ | 314 | | 315 | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | 316 | | 317 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 318 --------------------------------------------------------------- 319 : | | | | 320 : | | | | 321 : | | | | 322 (imaginary ================= a point- a 323 loopback an Ethernet to-point tunnel 324 link) link 326 Figure 2 : Example of Default Zone Indices 328 As well as initially assigning zone indices, as specified above, an 329 implementation should automatically select a default zone for each 330 scope for which there is more than one choice, to be used whenever an 331 address is specified without a zone index (or with a zone index of 332 zero). For instance, in the example shown in Figure 2, the 333 implementation might automatically select intf2, link2, and subnet2 334 as the default zones for each of those three scopes. (Perhaps the 335 selection algorithm is to choose the first zone that includes an 336 interface other than the loopback interface as the default for each 337 scope.) A means must also be provided for manually assigning the 338 default zone for a scope, overriding any automatic assignment. 340 Because the unicast loopback address, ::1, may not be assigned to 341 any interface other than the loopback interface, it is recommended 342 that whenever ::1 is specified without a zone index, or with the 343 default zone index, that it be interpreted as belonging to the 344 loopback link-local zone, regardless of which link-local zone has 345 been selected as the default. If this is done, then in the common 346 case of nodes with only a single non-loopback interface (e.g., a 347 single Ethernet interface), it becomes possible to avoid any need 348 to qualify link-local addresses with a zone index: the unqualified 349 address ::1 would always refer to the link-local zone containing 350 the loopback interface, and all other unqualified link-local 351 addresses would refer to the link-local zone containing the non- 352 loopback interface (as long as the default link-local zone were set 353 to be the zone containing the non-loopback interface). 355 Because of the requirement that a zone of a given scope fall 356 completely within zones of larger scope (see section 5, above), if 357 two interfaces are assigned to different zones of scope S, they must 359 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 7 360 also be assigned to different zones of all scopes smaller than S. 361 Thus, the manual assignment of distinct zone indices for one scope 362 may require the automatic assignment of distinct zone indices for 363 smaller scopes. For example, the manual assignment of distinct site- 364 local indices 1 and 2 in the node in Figure 1 would cause the 365 automatic creation of corresponding admin-local (i.e. multicast 366 "scop" value 4) indices 1 and 2, because admin-local scope is smaller 367 than site-local scope. 369 Taking all of the above considerations in account, the complete set 370 of zone indices for our example node from Figure 1 is shown in Figure 371 3, below. 373 --------------------------------------------------------------- 374 | a node | 375 | | 376 | | 377 | | 378 | | 379 | | 380 | /--------------------site1--------------------\ /--site2--\ | 381 | | 382 | /-------------------admin1--------------------\ /-admin2--\ | 383 | | 384 | /-subnet1-\ /-------subnet2-------\ /-subnet3-\ /-subnet4-\ | 385 | | 386 | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | 387 | | 388 | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | 389 --------------------------------------------------------------- 390 : | | | | 391 : | | | | 392 : | | | | 393 (imaginary ================= a point- a 394 loopback an Ethernet to-point tunnel 395 link) link 397 Figure 3 : Complete Zone Indices Example 399 Although the examples above show the zones being assigned index 400 values sequentially, starting at one, the zone index values are 401 arbitrary. An implementation may use any value it chooses to label a 402 zone as long as it meets the requirement that the index value of each 403 attached zone of the same scope be unique within the node. 404 Similarly, an implementation may choose an index value other than 405 zero to represent the default zone. Implementations choosing to 406 follow the recommended basic API [RFC 2553] will want to restrict 407 their index values to those that can be represented by the 408 sin6_scope_id field of a sockaddr_in6. 410 (Authors' note to selves: The Working Group seemed to be 411 in favor of allowing all zone indices for all scopes to 413 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 8 414 have unique values in a sin6 scope id field, e.g., by 415 using the first four bits of the scope id to identify the 416 scope [using the same encoding as the scop field in 417 multicast addresses], and placing the zone id in the 418 remaining 28 bits. This would probably be best specified 419 the advanced API spec, rather than here.) 421 7. Sending Packets 423 When an upper-layer protocol sends a packet to a non-global 424 destination address, it must have a means of identifying to the IPv6 425 layer the intended zone, for cases in which the node is attached to 426 more than one zone of the destination address's scope. 428 Although identification of an outgoing interface is sufficient to 429 identify an intended zone (because each interface is attached to no 430 more than one zone of each scope), that is more specific than desired 431 in many cases. For example, when sending to a site-local unicast 432 address, from a node that has more than one interface to the intended 433 site, the upper layer protocol may not care which of those interfaces 434 is used for the transmission, but rather would prefer to leave that 435 choice to the routing function in the IP layer. Thus, the upper- 436 layer requires the ability to specify a zone index, rather than an 437 interface identifier, when sending to a non-global, non-loopback 438 destination address. 440 8. Receiving Packets 442 When an upper-layer protocol receives a packet containing a non- 443 global source or destination address, the zone to which that address 444 pertains can be determined from the arrival interface, because the 445 arrival interface can be attached to only one zone of the same scope 446 as the address under consideration. However, it is recommended that 447 the IP layer convey to the upper layer the correct zone indices for 448 the arriving source and destination addresses, in addition to the 449 arrival interface identifier. 451 9. Forwarding 453 When a router receives a packet addressed to a node other than 454 itself, it must take the zone of the destination and source addresses 455 into account as follows: 457 o The zone of the destination address is determined by the 458 scope of the address and arrival interface of the packet. 459 The next-hop interface is chosen by looking up the 460 destination address in a (conceptual) routing table 462 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 9 463 specific to that zone. That routing table is restricted 464 to refer only to interfaces belonging to that zone. 466 o After the next-hop interface is chosen, the zone of the 467 source address is considered. As with the destination 468 address, the zone of the source address is determined by 469 the scope of the address and arrival interface of the 470 packet. If transmitting the packet on the chosen next-hop 471 interface would cause the packet to leave the zone of the 472 source address, i.e., cross a zone boundary of the scope 473 of the source address, then the packet is discarded and an 474 ICMP Destination Unreachable message [RFC 2463] with Code 475 2 ("beyond scope of source address") is sent to the source 476 of the packet. 478 Note that the above procedure applies for addresses of all scopes, 479 including link-local. Thus, if a router receives a packet with a 480 link-local destination address that is not one of the router's own 481 link-local addresses on the arrival link, the router is expected to 482 try to forward the packet to the destination on that link (subject to 483 successful determination of the destination's link-layer address via 484 the Neighbor Discovery protocol [RFC 2461]). The forwarded packet may 485 be transmitted back out the arrival interface, or out any other 486 interface attached to the same link. 488 A node that receives a packet addressed to itself and containing a 489 Routing Header with more than zero Segments Left [RFC 2460, section 490 4.4] swaps the original destination address with the next address in 491 the Routing Header. Then the above forwarding rules are applied, 492 using the new destination address where the zone of the new 493 destination address should be determined by the scope of the previous 494 destination address and the interface to which the previous address 495 belongs (which is not necessarily equal to the incoming interface). 496 An implementation MUST NOT examine additional addresses in the 497 Routing header to determine whether they are crossing boundaries for 498 their scopes. Thus, it is possible, though generally inadvisable, to 499 use a Routing Header to convey a non-global address across its 500 associated zone boundary. 502 10. Routing 504 When a routing protocol determines that it is operating on a zone 505 boundary, it MUST protect inter-zone integrity and maintain intra- 506 zone connectivity. 508 In order to maintain connectivity, the routing protocol must be able 509 to create forwarding information for the global prefixes as well as 510 for all of the zone prefixes for each of its attached zones. The 511 most straightforward way of doing this is to create (conceptual) 512 forwarding tables for each specific zone. 514 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 10 515 To protect inter-zone integrity, routers must be selective in the 516 prefix information that is shared with neighboring routers. Routers 517 routinely exchange routing information with neighboring routers. 518 When a router is transmitting this routing information, it must not 519 include any information about zones other than the zones assigned to 520 the interface used to transmit the information. 522 * * 523 * * 524 * =========== Site X * 525 * | | * 526 * | | * 527 +-*----|-------|------+ * 528 | * intf1 intf2 | * 529 | * | * 530 | * intf3 --- * 531 | * | * 532 | *********************************** 533 | | 534 | Router | 535 | | 536 ********************** ********************** 537 | * * | 538 Site Y --- intf4 * * intf5 --- Site Z 539 | * * | 540 ********************** ********************** 541 +---------------------+ 543 Figure 4: Multi-Sited Router 545 As an example, the router in Figure 4 must exchange routing 546 information on five interfaces. The information exchanged is as 547 follows: 549 o Interface 1 551 o All global prefixes 553 o All site prefixes learned from Interfaces 1, 2, and 3 555 o Interface 2 557 o All global prefixes 559 o All site prefixes learned from Interfaces 1, 2, and 3 561 o Interface 3 563 o All global prefixes 565 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 11 566 o All site prefixes learned from Interface 1, 2, and 3 568 o Interface 4 570 o All global prefixes 572 o All site prefixes learned from Interface 4 574 o Interface 5 576 o All global prefixes 578 o All site prefixes learned from Interfaces 5 580 By imposing route exchange rules, zone integrity is maintained by 581 keeping all zone-specific routing information contained within the 582 zone. 584 11. Mobility 586 A mobile node that moves outside its "home site" must maintain the 587 "home site-local addresses" for continued communication with nodes in 588 its "home site". This implies that such a mobile node conceptually 589 will have one interface (for the traffic destined to and from its 590 home site) which is assigned the home site-local addresses in 591 addition to its other interfaces which might be part of the visited 592 site. 594 A mobile node may choose to autoconfigure site-local addresses in the 595 visited site. However, such addresses add complexity to the mobile 596 node with little or no benefit. Thus it is recommended that mobile 597 nodes only autoconfigure global addresses when moving to links 598 outside its home site. 600 A mobile node needs to be able to detect when it has moved to a 601 different site. Thus in addition to the regular movement detection 602 in [MOBILE] it should inspect the site prefixes in the Router 603 Advertisement messages to determine when it is outside its home site. 605 (Authors' note to selves: complete section description on 606 mobility aspects) 608 12. Textual Representation 610 As already mentioned, to specify an IPv6 non-global address without 611 ambiguity, an intended scope zone should be specified as well. As a 612 common notation to specify the scope zone, an implementation SHOULD 613 support the following format. 615 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 12 616
%