idnits 2.17.1 draft-ietf-6man-rfc4291bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 237 has weird spacing: '...address is an...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2016) is 2754 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) == Unused Reference: 'RFC7217' is defined on line 1083, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-6man-rfc2460bis-07 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6man-rfc2460bis' -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hinden 3 Internet-Draft Check Point Software 4 Obsoletes: 4291 (if approved) S. Deering 5 Intended status: Standards Track Retired 6 Expires: April 7, 2017 October 4, 2016 8 IP Version 6 Addressing Architecture 9 draft-ietf-6man-rfc4291bis-05 11 Abstract 13 This specification defines the addressing architecture of the IP 14 Version 6 (IPv6) protocol. The document includes the IPv6 addressing 15 model, text representations of IPv6 addresses, definition of IPv6 16 unicast addresses, anycast addresses, and multicast addresses, and an 17 IPv6 node's required addresses. 19 This document obsoletes RFC 4291, "IP Version 6 Addressing 20 Architecture". 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 7, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Addressing Model . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Text Representation of IPv6 Addresses . . . . . . . . . . 4 72 2.2.1. Text Representation of Addresses . . . . . . . . . . 4 73 2.2.2. Text Representation of Address Prefixes . . . . . . . 5 74 2.2.3. Recommendation for outputting IPv6 addresses . . . . 7 75 2.3. Address Type Identification . . . . . . . . . . . . . . . 9 76 2.4. Unicast Addresses . . . . . . . . . . . . . . . . . . . . 10 77 2.4.1. Interface Identifiers . . . . . . . . . . . . . . . . 11 78 2.4.2. The Unspecified Address . . . . . . . . . . . . . . . 12 79 2.4.3. The Loopback Address . . . . . . . . . . . . . . . . 12 80 2.4.4. Global Unicast Addresses . . . . . . . . . . . . . . 12 81 2.4.5. IPv6 Addresses with Embedded IPv4 Addresses . . . . . 13 82 2.4.5.1. IPv4-Compatible IPv6 Address . . . . . . . . . . 13 83 2.4.5.2. IPv4-Mapped IPv6 Address . . . . . . . . . . . . 13 84 2.4.6. Link-Local IPv6 Unicast Addresses . . . . . . . . . . 14 85 2.4.7. Other Local Unicast IPv6 Addresses . . . . . . . . . 14 86 2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . . . 14 87 2.5.1. Required Anycast Address . . . . . . . . . . . . . . 15 88 2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16 89 2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 18 90 2.7. A Node's Required Addresses . . . . . . . . . . . . . . . 20 91 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 93 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 94 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 6.1. Normative References . . . . . . . . . . . . . . . . . . 22 96 6.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Appendix A. Modified EUI-64 Format Interface Identifiers . . . . 25 99 A.1. Creating Modified EUI-64 Format Interface Identifiers . . 26 100 Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 29 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 103 1. Introduction 105 This specification defines the addressing architecture of the IP 106 Version 6 protocol. It includes the basic formats for the various 107 types of IPv6 addresses (unicast, anycast, and multicast). 109 2. IPv6 Addressing 111 IPv6 addresses are 128-bit identifiers for interfaces and sets of 112 interfaces (where "interface" is as defined in Section 2 of 113 [I-D.ietf-6man-rfc2460bis]). There are three types of addresses: 115 Unicast: An identifier for a single interface. A packet sent 116 to a unicast address is delivered to the interface 117 identified by that address. 119 Anycast: An identifier for a set of interfaces (typically 120 belonging to different nodes). A packet sent to an 121 anycast address is delivered to one of the interfaces 122 identified by that address (the "nearest" one, 123 according to the routing protocols' measure of 124 distance). 126 Multicast: An identifier for a set of interfaces (typically 127 belonging to different nodes). A packet sent to a 128 multicast address is delivered to all interfaces 129 identified by that address. 131 There are no broadcast addresses in IPv6, their function being 132 superseded by multicast addresses. 134 In this document, fields in addresses are given a specific name, for 135 example, "subnet". When this name is used with the term "ID" for 136 identifier after the name (e.g., "subnet ID"), it refers to the 137 contents of the named field. When it is used with the term "prefix" 138 (e.g., "subnet prefix"), it refers to all of the address from the 139 left up to and including this field. 141 In IPv6, all zeros and all ones are legal values for any field, 142 unless specifically excluded. Specifically, prefixes may contain, or 143 end with, zero-valued fields. 145 2.1. Addressing Model 147 IPv6 addresses of all types are assigned to interfaces, not nodes. 148 An IPv6 unicast address refers to a single interface. Since each 149 interface belongs to a single node, any of that node's interfaces' 150 unicast addresses may be used as an identifier for the node. 152 All interfaces are required to have at least one Link-Local unicast 153 address (see Section 2.7 for additional required addresses). A 154 single interface may also have multiple IPv6 addresses of any type 155 (unicast, anycast, and multicast) or scope. Unicast addresses with a 156 scope greater than link-scope are not needed for interfaces that are 157 not used as the origin or destination of any IPv6 packets to or from 158 non-neighbors. This is sometimes convenient for point-to-point 159 interfaces. There is one exception to this addressing model: 161 A unicast address or a set of unicast addresses may be assigned to 162 multiple physical interfaces if the implementation treats the 163 multiple physical interfaces as one interface when presenting it 164 to the internet layer. This is useful for load-sharing over 165 multiple physical interfaces. 167 Currently, IPv6 continues the IPv4 model in that a subnet prefix is 168 associated with one link. Multiple subnet prefixes may be assigned 169 to the same link. 171 2.2. Text Representation of IPv6 Addresses 173 2.2.1. Text Representation of Addresses 175 There are three conventional forms for representing IPv6 addresses as 176 text strings: 178 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to 179 four hexadecimal digits of the eight 16-bit pieces of the address. 180 Examples: 182 abcd:ef01:2345:6789:abcd:ef01:2345:6789 183 2001:db8:0:0:8:800:200c:417a 185 Note that it is not necessary to write the leading zeros in an 186 individual field, but there must be at least one numeral in every 187 field (except for the case described in 2.). 189 2. Due to some methods of allocating certain styles of IPv6 190 addresses, it will be common for addresses to contain long strings 191 of zero bits. In order to make writing addresses containing zero 192 bits easier, a special syntax is available to compress the zeros. 193 The use of "::" indicates one or more groups of 16 bits of zeros. 194 The "::" can only appear once in an address. The "::" can also be 195 used to compress leading or trailing zeros in an address. 197 For example, the following addresses 199 2001:db8:0:0:8:800:200c:417a a unicast address 200 ff01:0:0:0:0:0:0:101 a multicast address 201 0:0:0:0:0:0:0:1 the loopback address 202 0:0:0:0:0:0:0:0 the unspecified address 204 may be represented as 206 2001:db8::8:800:200c:417a a unicast address 207 ff01::101 a multicast address 208 ::1 the loopback address 209 :: the unspecified address 211 3. An alternative form that is sometimes more convenient when dealing 212 with a mixed environment of IPv4 and IPv6 nodes is 213 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 214 the six high-order 16-bit pieces of the address, and the 'd's are 215 the decimal values of the four low-order 8-bit pieces of the 216 address (standard IPv4 representation). Examples: 218 0:0:0:0:0:0:13.1.68.3 219 0:0:0:0:0:ffff:129.144.52.38 221 or in compressed form: 223 ::13.1.68.3 224 ::ffff:129.144.52.38 226 2.2.2. Text Representation of Address Prefixes 228 The text representation of IPv6 address prefixes is similar to the 229 way IPv4 address prefixes are written in Classless Inter-Domain 230 Routing (CIDR) notation [RFC4632]. An IPv6 address prefix is 231 represented by the notation: 233 ipv6-address/prefix-length 235 where 237 ipv6-address is an IPv6 address in any of the notations listed in 238 Section 2.2. 240 prefix-length is a decimal value specifying how many of the leftmost 241 contiguous bits of the address comprise the prefix. 243 For example, the following are legal representations of the 60-bit 244 prefix 20010db80000cd3 (hexadecimal): 246 2001:0db8:0000:cd30:0000:0000:0000:0000/60 248 2001:0db8::cd30:0:0:0:0/60 250 2001:0db8:0:cd30::/60 252 The following are NOT legal representations of the above prefix: 254 2001:0db8:0:cd3/60 may drop leading zeros, but not trailing 255 zeros, within any 16-bit chunk of the address 257 2001:0db8::cd30/60 address to left of "/" expands to 258 2001:0db8:0000:0000:0000:0000:0000:cd30 260 2001:0db8::cd3/60 address to left of "/" expands to 261 2001:0db8:0000:0000:0000:0000:0000:0cd3 263 When writing both a node address and a prefix of that node address 264 (e.g., the node's subnet prefix), the two can be combined as follows: 266 the node address 2001:0db8:0:cd30:123:4567:89ab:cdef 267 and its subnet number 2001:0db8:0:cd30::/60 269 can be abbreviated as 2001:0db8:0:cd30:123:4567:89ab:cdef/60 271 2.2.3. Recommendation for outputting IPv6 addresses 273 This section provides a recommendation for systems generating and 274 outputting IPv6 addresses as text. Note, all implementations must 275 accept and process all addresses in the formats defined in the 276 previous two sections of this document. The recommendations are as 277 follows: 279 1. The hexadecimal digits "a", "b", "c", "d", "e", and "f" in an IPv6 280 address must be represented in lowercase. 282 2. Leading zeros in a 16-Bit Field must be suppressed. For example, 284 2001:0db8::0001 286 is not correct and must be represented as 288 2001:db8::1 290 3. A single 16-bit 0000 field must be represented as 0. 292 The use of the symbol "::" must be used to its maximum capability. 293 For example: 295 2001:db8:0:0:0:0:2:1 297 must be shortened to 299 2001:db8::2:1 301 Likewise, 303 2001:db8::0:1 305 is not correct, because the symbol "::" could have been used to 306 produce a shorter representation 307 2001:db8::1. 309 4. When there is an alternative choice in the placement of a "::", 310 the longest run of consecutive 16-bit 0 fields must be shortened, 311 that is, in 313 2001:0:0:1:0:0:0:1 315 the sequence with three consecutive zero fields is shortened to 317 2001:0:0:1::1 319 5. When the length of the consecutive 16-bit 0 fields are equal, for 320 example 322 2001:db8:0:0:1:0:0:1 324 the first sequence of zero bits must be shortened. For example 326 2001:db8::1:0:0:1 328 is the correct representation. 330 6. The symbol "::" must not be used to shorten just one 16-bit 0 331 field. For example, the representation 333 2001:db8:0:1:1:1:1:1 335 is correct, but 337 2001:db8::1:1:1:1:1 339 is not correct. 341 7. The text representation method describe in this section should 342 also be use for text Representation of IPv6 Address Prefixes. For 343 example 345 0:0:0:0:0:ffff:192.0.2.1 347 should be shown as 349 ::ffff:192.0.2.1 351 8. The text representation method describe in this section should be 352 applied for IPv6 addresses with embedded IPv4 address. For 353 example 355 2001:0db8:0000:cd30:0000:0000:0000:0000/60 357 should be shown as 359 2001:0db8:0:cd30::/60 361 2.3. Address Type Identification 363 The type of an IPv6 address is identified by the high-order bits of 364 the address, as follows: 366 Address type Binary prefix IPv6 notation Section 367 ------------ ------------- ------------- ------- 368 Unspecified 00...0 (128 bits) ::/128 2.4.2 369 Loopback 00...1 (128 bits) ::1/128 2.4.3 370 Multicast 11111111 ff00::/8 2.6 371 Link-Local unicast 1111111010 fe80::/10 2.4.6 372 Global Unicast (everything else) 374 Anycast addresses are taken from the unicast address spaces (of any 375 scope) and are not syntactically distinguishable from unicast 376 addresses. 378 The general format of Global Unicast addresses is described in 379 Section 2.4.4. Some special-purpose subtypes of Global Unicast 380 addresses that contain embedded IPv4 addresses (for the purposes of 381 IPv4-IPv6 interoperation) are described in Section 2.4.5. 383 Future specifications may redefine one or more sub-ranges of the 384 Global Unicast space for other purposes, but unless and until that 385 happens, implementations must treat all addresses that do not start 386 with any of the above-listed prefixes as Global Unicast addresses. 388 The current assigned IPv6 prefixes and references to their usage can 389 be found in the IANA Internet Protocol Version 6 Address Space 390 registry [IANA-AD] and the IANA IPv6 Special-Purpose Address Registry 391 [IANA-SP]. 393 2.4. Unicast Addresses 395 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 396 bit-length, similar to IPv4 addresses under Classless Inter-Domain 397 Routing. 399 There are several types of unicast addresses in IPv6, in particular, 400 Global Unicast, Local unicast, and Link-Local unicast. There are 401 also some special-purpose subtypes of Global Unicast, such as IPv6 402 addresses with embedded IPv4 addresses. Additional address types or 403 subtypes can be defined in the future. 405 IPv6 nodes may have considerable or little knowledge of the internal 406 structure of the IPv6 address, depending on the role the node plays 407 (for instance, host versus router). At a minimum, a node may 408 consider that unicast addresses (including its own) have no internal 409 structure: 411 | 128 bits | 412 +-----------------------------------------------------------------+ 413 | node address | 414 +-----------------------------------------------------------------+ 416 A slightly sophisticated host (but still rather simple) may 417 additionally be aware of subnet prefix(es) for the link(s) it is 418 attached to, where different addresses may have different values for 419 n: 421 | n bits | 128-n bits | 422 +-------------------------------+---------------------------------+ 423 | subnet prefix | interface ID | 424 +-------------------------------+---------------------------------+ 426 Though a very simple router may have no knowledge of the internal 427 structure of IPv6 unicast addresses, routers will more generally have 428 knowledge of one or more of the hierarchical boundaries for the 429 operation of routing protocols. The known boundaries will differ 430 from router to router, depending on what positions the router holds 431 in the routing hierarchy. 433 Except for the knowledge of the subnet boundary discussed in the 434 previous paragraphs, nodes should not make any assumptions about the 435 structure of an IPv6 address. 437 2.4.1. Interface Identifiers 439 Interface identifiers in IPv6 unicast addresses are used to identify 440 interfaces on a link. They are required to be unique within a subnet 441 prefix. It is recommended that the same interface identifier not be 442 assigned to different nodes on a link. They may also be unique over 443 a broader scope. The same interface identifier may be used on 444 multiple interfaces on a single node, as long as they are attached to 445 different subnets. 447 Interface IDs must be viewed outside of the node that created 448 Interface ID as an opaque bit string without any internal structure. 450 Note that the uniqueness of interface identifiers is independent of 451 the uniqueness of IPv6 addresses. For example, a Global Unicast 452 address may be created with an interface identifier that is only 453 unique on a single subnet, and a Link-Local address may be created 454 with interface identifier that is unique over multiple subnets. 456 For all unicast addresses, except those that start with the binary 457 value 000, Interface IDs are required to be 64 bits long. Background 458 on the 64 bit boundary can be bound in [RFC7421]. 460 The details of forming interface identifiers are defined in other 461 specifications, such as "Privacy Extensions for Stateless Address 462 Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating 463 Semantically Opaque Interface Identifiers with IPv6 Stateless Address 464 Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in 465 appropriate "IPv6 over " specifications, such as "IPv6 over 466 Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T 467 G.9959 Networks" [RFC7428]. The security and privacy considerations 468 for IPv6 address generation is described in [RFC7721]. 470 Earlier versions of this document described a method of forming 471 interface identifiers derived from IEEE MAC-layer addresses call 472 Modified EUI-64 format. These are described in Appendix A and are no 473 longer recommended. 475 2.4.2. The Unspecified Address 477 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 478 must never be assigned to any node. It indicates the absence of an 479 address. One example of its use is in the Source Address field of 480 any IPv6 packets sent by an initializing host before it has learned 481 its own address. 483 The unspecified address must not be used as the destination address 484 of IPv6 packets or in IPv6 Routing headers. An IPv6 packet with a 485 source address of unspecified must never be forwarded by an IPv6 486 router. 488 2.4.3. The Loopback Address 490 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 491 It may be used by a node to send an IPv6 packet to itself. It must 492 not be assigned to any physical interface. It is treated as having 493 Link-Local scope, and may be thought of as the Link-Local unicast 494 address of a virtual interface (typically called the "loopback 495 interface") to an imaginary link that goes nowhere. 497 The loopback address must not be used as the source address in IPv6 498 packets that are sent outside of a single node. An IPv6 packet with 499 a destination address of loopback must never be sent outside of a 500 single node and must never be forwarded by an IPv6 router. A packet 501 received on an interface with a destination address of loopback must 502 be dropped. 504 2.4.4. Global Unicast Addresses 506 The general format for IPv6 Global Unicast addresses is as follows: 508 | n bits | m bits | 128-n-m bits | 509 +------------------------+-----------+----------------------------+ 510 | global routing prefix | subnet ID | interface ID | 511 +------------------------+-----------+----------------------------+ 513 where the global routing prefix is a (typically hierarchically- 514 structured) value assigned to a site (a cluster of subnets/links), 515 the subnet ID is an identifier of a link within the site, and the 516 interface ID is as defined in Section 2.4.1. 518 All Global Unicast addresses other than those that start with binary 519 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 520 described in Section 2.4.1. Global Unicast addresses that start with 521 binary 000 have no such constraint on the size or structure of the 522 interface ID field. 524 Examples of Global Unicast addresses that start with binary 000 are 525 the IPv6 address with embedded IPv4 addresses described in 526 Section 2.4.5. An example of global addresses starting with a binary 527 value other than 000 (and therefore having a 64-bit interface ID 528 field) can be found in [RFC3587]. 530 2.4.5. IPv6 Addresses with Embedded IPv4 Addresses 532 Two types of IPv6 addresses are defined that carry an IPv4 address in 533 the low-order 32 bits of the address. These are the "IPv4-Compatible 534 IPv6 address" and the "IPv4-mapped IPv6 address". 536 2.4.5.1. IPv4-Compatible IPv6 Address 538 The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 539 transition. The format of the "IPv4-Compatible IPv6 address" is as 540 follows: 542 | 80 bits | 16 | 32 bits | 543 +--------------------------------------+--------------------------+ 544 |0000..............................0000|0000| IPv4 address | 545 +--------------------------------------+----+---------------------+ 547 Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" 548 must be a globally-unique IPv4 unicast address. 550 The "IPv4-Compatible IPv6 address" is now deprecated because the 551 current IPv6 transition mechanisms no longer use these addresses. 552 New or updated implementations are not required to support this 553 address type. 555 2.4.5.2. IPv4-Mapped IPv6 Address 557 A second type of IPv6 address that holds an embedded IPv4 address is 558 defined. This address type is used to represent the addresses of 559 IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 560 address" is as follows: 562 | 80 bits | 16 | 32 bits | 563 +--------------------------------------+--------------------------+ 564 |0000..............................0000|ffff| IPv4 address | 565 +--------------------------------------+----+---------------------+ 567 See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 568 address". 570 2.4.6. Link-Local IPv6 Unicast Addresses 572 Link-Local addresses are for use on a single link. Link-Local 573 addresses have the following format: 575 | 10 | 576 | bits | 54 bits | 64 bits | 577 +----------+-------------------------+----------------------------+ 578 |1111111010| 0 | interface ID | 579 +----------+-------------------------+----------------------------+ 581 Link-Local addresses are designed to be used for addressing on a 582 single link for purposes such as automatic address configuration, 583 neighbor discovery, or when no routers are present. 585 Routers must not forward any packets with Link-Local source or 586 destination addresses to other links. 588 2.4.7. Other Local Unicast IPv6 Addresses 590 Unique Local Addresses (ULA) [RFC4193], the current form of Local 591 IPv6 Addresses, are intended to be used for local communications, 592 have global unicast scope, and are not expected to be routable on the 593 global Internet. 595 Site-Local addresses, deprecated by [RFC3879], the previous form of 596 Local IPv6 Addresses, were originally designed to be used for 597 addressing inside of a site without the need for a global prefix. 599 The special behavior of Site-Local defined in [RFC3513] must no 600 longer be supported in new implementations (i.e., new implementations 601 must treat this prefix as Global Unicast). Existing implementations 602 and deployments may continue to use this prefix. 604 2.5. Anycast Addresses 606 An IPv6 anycast address is an address that is assigned to more than 607 one interface (typically belonging to different nodes), with the 608 property that a packet sent to an anycast address is routed to the 609 "nearest" interface having that address, according to the routing 610 protocols' measure of distance. 612 Anycast addresses are allocated from the unicast address space, using 613 any of the defined unicast address formats. Thus, anycast addresses 614 are syntactically indistinguishable from unicast addresses. When a 615 unicast address is assigned to more than one interface, thus turning 616 it into an anycast address, the nodes to which the address is 617 assigned must be explicitly configured to know that it is an anycast 618 address. 620 For any assigned anycast address, there is a longest prefix P of that 621 address that identifies the topological region in which all 622 interfaces belonging to that anycast address reside. Within the 623 region identified by P, the anycast address must be maintained as a 624 separate entry in the routing system (commonly referred to as a "host 625 route"); outside the region identified by P, the anycast address may 626 be aggregated into the routing entry for prefix P. 628 Note that in the worst case, the prefix P of an anycast set may be 629 the null prefix, i.e., the members of the set may have no topological 630 locality. In that case, the anycast address must be maintained as a 631 separate routing entry throughout the entire Internet, which presents 632 a severe scaling limit on how many such "global" anycast sets may be 633 supported. Therefore, it is expected that support for global anycast 634 sets may be unavailable or very restricted. 636 One expected use of anycast addresses is to identify the set of 637 routers belonging to an organization providing Internet service. 638 Such addresses could be used as intermediate addresses in an IPv6 639 Routing header, to cause a packet to be delivered via a particular 640 service provider or sequence of service providers. 642 Some other possible uses are to identify the set of routers attached 643 to a particular subnet, or the set of routers providing entry into a 644 particular routing domain. 646 2.5.1. Required Anycast Address 648 The Subnet-Router anycast address is predefined. Its format is as 649 follows: 651 | n bits | 128-n bits | 652 +------------------------------------------------+----------------+ 653 | subnet prefix | 00000000000000 | 654 +------------------------------------------------+----------------+ 656 The "subnet prefix" in an anycast address is the prefix that 657 identifies a specific link. This anycast address is syntactically 658 the same as a unicast address for an interface on the link with the 659 interface identifier set to zero. 661 Packets sent to the Subnet-Router anycast address will be delivered 662 to one router on the subnet. All routers are required to support the 663 Subnet-Router anycast addresses for the subnets to which they have 664 interfaces. 666 The Subnet-Router anycast address is intended to be used for 667 applications where a node needs to communicate with any one of the 668 set of routers. 670 2.6. Multicast Addresses 672 An IPv6 multicast address is an identifier for a group of interfaces 673 (typically on different nodes). An interface may belong to any 674 number of multicast groups. Multicast addresses have the following 675 format: 677 | 8 | 4 | 4 | 112 bits | 678 +------ -+----+----+---------------------------------------------+ 679 |11111111|flgs|scop| group ID | 680 +--------+----+----+---------------------------------------------+ 682 binary 11111111 at the start of the address identifies the address 683 as being a multicast address. 685 +-+-+-+-+ 686 flgs is a set of 4 flags: |0|R|P|T| 687 +-+-+-+-+ 689 The high-order flag is reserved, and must be initialized to 0. 691 T = 0 indicates a permanently-assigned ("well-known") multicast 692 address, assigned by the Internet Assigned Numbers Authority 693 (IANA). 695 T = 1 indicates a non-permanently-assigned ("transient" or 696 "dynamically" assigned) multicast address. 698 The P flag's definition and usage can be found in [RFC3306]. 700 The R flag's definition and usage can be found in [RFC3956]. 702 scop is a 4-bit multicast scope value used to limit the scope of 703 the multicast group. The values are as follows: 705 0 reserved 706 1 Interface-Local scope 707 2 Link-Local scope 708 3 Realm-Local scope 709 4 Admin-Local scope 710 5 Site-Local scope 711 6 (unassigned) 712 7 (unassigned) 713 8 Organization-Local scope 714 9 (unassigned) 715 A (unassigned) 716 B (unassigned) 717 C (unassigned) 718 D (unassigned) 719 E Global scope 720 F reserved 722 Interface-Local scope spans only a single interface on a node 723 and is useful only for loopback transmission of multicast. 724 Packets with interface-local scope received from another node 725 must be discarded. 727 Link-Local multicast scope spans the same topological region as 728 the corresponding unicast scope. 730 Interface-Local, Link-Local, and Realm-Local scope boundaries 731 are automatically derived from physical connectivity or other 732 non-multicast-related configurations. Global scope has no 733 boundary. The boundaries of all other non-reserved scopes of 734 Admin-Local or larger are administratively configured. For 735 reserved scopes, the way of configuring their boundaries will 736 be defined when the semantics of the scope are defined. 738 According to [RFC4007], the zone of a Realm-Local scope must 739 fall within zones of larger scope. Because the zone of a 740 Realm-Local scope is configured automatically while the zones 741 of larger scopes are configured manually, care must be taken in 742 the definition of those larger scopes to ensure that the 743 inclusion constraint is met. 745 Realm-Local scopes created by different network technologies 746 are considered to be independent and will have different zone 747 indices (see Section 6 of [RFC4007]). A router with interfaces 748 on links using different network technologies does not forward 749 traffic between the Realm-Local multicast scopes defined by 750 those technologies. 752 Site-Local scope is intended to span a single site. 754 Organization-Local scope is intended to span multiple sites 755 belonging to a single organization. 757 scopes labeled "(unassigned)" are available for administrators 758 to define additional multicast regions. 760 group ID identifies the multicast group, either permanent or 761 transient, within the given scope. Additional definitions of the 762 multicast group ID field structure are provided in [RFC3306]. 764 The "meaning" of a permanently-assigned multicast address is 765 independent of the scope value. For example, if the "NTP servers 766 group" is assigned a permanent multicast address with a group ID of 767 101 (hex), then 769 ff01:0:0:0:0:0:0:101 means all NTP servers on the same interface 770 (i.e., the same node) as the sender. 772 ff02:0:0:0:0:0:0:101 means all NTP servers on the same link as the 773 sender. 775 ff05:0:0:0:0:0:0:101 means all NTP servers in the same site as the 776 sender. 778 ff0e:0:0:0:0:0:0:101 means all NTP servers in the Internet. 780 Non-permanently-assigned multicast addresses are meaningful only 781 within a given scope. For example, a group identified by the non- 782 permanent, site-local multicast address ff15:0:0:0:0:0:0:101 at one 783 site bears no relationship to a group using the same address at a 784 different site, nor to a non-permanent group using the same group ID 785 with a different scope, nor to a permanent group with the same group 786 ID. 788 Multicast addresses must not be used as source addresses in IPv6 789 packets or appear in any Routing header. 791 Routers must not forward any multicast packets beyond the scope 792 indicated by the scop field in the destination multicast address. 794 Nodes must not originate a packet to a multicast address whose scop 795 field contains the reserved value 0; if such a packet is received, it 796 must be silently dropped. Nodes should not originate a packet to a 797 multicast address whose scop field contains the reserved value F; if 798 such a packet is sent or received, it must be treated the same as 799 packets destined to a global (scop E) multicast address. 801 2.6.1. Pre-Defined Multicast Addresses 803 The following well-known multicast addresses are pre-defined. The 804 group IDs defined in this section are defined for explicit scope 805 values. 807 Use of these group IDs for any other scope values, with the T flag 808 equal to 0, is not allowed. 810 reserved multicast addresses: ff00:0:0:0:0:0:0:0 811 ff01:0:0:0:0:0:0:0 812 ff02:0:0:0:0:0:0:0 813 ff03:0:0:0:0:0:0:0 814 ff04:0:0:0:0:0:0:0 815 ff05:0:0:0:0:0:0:0 816 ff06:0:0:0:0:0:0:0 817 ff07:0:0:0:0:0:0:0 818 ff08:0:0:0:0:0:0:0 819 ff09:0:0:0:0:0:0:0 820 ff0a:0:0:0:0:0:0:0 821 ff0b:0:0:0:0:0:0:0 822 ff0c:0:0:0:0:0:0:0 823 ff0d:0:0:0:0:0:0:0 824 ff0e:0:0:0:0:0:0:0 825 ff0f:0:0:0:0:0:0:0 827 The above multicast addresses are reserved and shall never be 828 assigned to any multicast group. 830 all nodes addresses: ff01:0:0:0:0:0:0:1 831 ff02:0:0:0:0:0:0:1 833 The above multicast addresses identify the group of all IPv6 nodes, 834 within scope 1 (interface-local) or 2 (link-local). 836 all routers addresses: ff01:0:0:0:0:0:0:2 837 ff02:0:0:0:0:0:0:2 838 ff05:0:0:0:0:0:0:2 840 The above multicast addresses identify the group of all IPv6 routers, 841 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 843 Solicited-Node Address: ff02:0:0:0:0:1:ffxx:xxxx 845 Solicited-Node multicast address are computed as a function of a 846 node's unicast and anycast addresses. A Solicited-Node multicast 847 address is formed by taking the low-order 24 bits of an address 848 (unicast or anycast) and appending those bits to the prefix 849 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 850 range 852 ff02:0:0:0:0:1:ff00:0000 854 to 856 ff02:0:0:0:0:1:ffff:ffff 858 For example, the Solicited-Node multicast address corresponding to 859 the IPv6 address 4037::01:800:200e:8c6c is ff02::1:ff0e:8c6c. IPv6 860 addresses that differ only in the high-order bits (e.g., due to 861 multiple high-order prefixes associated with different aggregations) 862 will map to the same Solicited-Node address, thereby reducing the 863 number of multicast addresses a node must join. 865 A node is required to compute and join (on the appropriate interface) 866 the associated Solicited-Node multicast addresses for all unicast and 867 anycast addresses that have been configured for the node's interfaces 868 (manually or automatically). 870 2.7. A Node's Required Addresses 872 A host is required to recognize the following addresses as 873 identifying itself: 875 o Its required Link-Local address for each interface. 877 o Any additional Unicast and Anycast addresses that have been 878 configured for the node's interfaces (manually or 879 automatically). 881 o The loopback address. 883 o The All-Nodes multicast addresses defined in Section 2.6.1. 885 o The Solicited-Node multicast address for each of its unicast 886 and anycast addresses. 888 o Multicast addresses of all other groups to which the node 889 belongs. 891 A router is required to recognize all addresses that a host is 892 required to recognize, plus the following addresses as identifying 893 itself: 895 o The Subnet-Router Anycast addresses for all interfaces for 896 which it is configured to act as a router. 898 o All other Anycast addresses with which the router has been 899 configured. 901 o The All-Routers multicast addresses defined in Section 2.6.1. 903 3. IANA Considerations 905 RFC4291 is referenced in a number of IANA registries. These include: 907 o Internet Protocol Version 6 Address Space [IANA-AD] 909 o IPv6 Global Unicast Address Assignments [IANA-GU] 911 o IPv6 Multicast Address Space Registry [IANA-MC] 913 o Application for an IPv6 Multicast Address [IANA-MA] 915 o Internet Protocol Version 6 (IPv6) Anycast Addresses [IANA-AC] 917 o IANA IPv6 Special-Purpose Address Registry [IANA-SP] 919 o Reserved IPv6 Interface Identifiers [IANA-ID] 921 o Number Resources [IANA-NR] 923 o Protocol Registries [IANA-PR] 925 o Technical requirements for authoritative name servers [IANA-NS] 927 o IP Flow Information Export (IPFIX) Entities [IANA-FE] 929 The IANA should update these references to point to this document. 930 There is a reference to RFC4291 (and RFC3307) that appears to be 931 incorrect and should be removed in: 933 o Modify a Port Number assignment [IANA-PN] 935 There are also other references in IANA procedures documents that the 936 IANA should investigate to see if they should be updated. 938 4. Security Considerations 940 IPv6 addressing documents do not have any direct impact on Internet 941 infrastructure security. Authentication of IPv6 packets is defined 942 in [RFC4302]. 944 One area relavant to IPv6 addressing is privacy. IPv6 addresses can 945 be created using interface identifiers constructed with unique stable 946 tokens. The addresses created in this manner can be used to track 947 the movement of devices across the Internet. Since earlier versions 948 of this document were published, several approaches have been 949 developed that mitigate these problems. These are described in 950 "Security and Privacy Considerations for IPv6 Address Generation 951 Mechanisms" [RFC7721], "Privacy Extensions for Stateless Address 952 Autoconfiguration in IPv6" [RFC4941], and "A Method for Generating 953 Semantically Opaque Interface Identifiers with IPv6 Stateless Address 954 Autoconfiguration (SLAAC)"[RFC7217]. 956 5. Acknowledgments 958 The authors would like to acknowledge the contributions of Paul 959 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 960 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 961 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 962 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 963 Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, 964 Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali. 966 The authors would also like to acknowledge the authors of the 967 updating RFCs that were incorporated in this version of the document 968 to move IPv6 to Internet Standard. This includes Marcelo Bagnulo, 969 Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms, 970 Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima, 971 Xing Li, and Stig Venaas. 973 6. References 975 6.1. Normative References 977 [I-D.ietf-6man-rfc2460bis] 978 Deering, S. and R. Hinden, "Internet Protocol, Version 6 979 (IPv6) Specification", draft-ietf-6man-rfc2460bis-07 (work 980 in progress), October 2016. 982 6.2. Informative References 984 [EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 985 Registration Authority"", March 1997, 986 . 989 [IANA-AC] "Internet Protocol Version 6 (IPv6) Anycast Addresses", 990 . 993 [IANA-AD] "Internet Protocol Version 6 Address Space", 994 . 997 [IANA-FE] "IP Flow Information Export (IPFIX) Entities", 998 . 1000 [IANA-GU] "IPv6 Global Unicast Address Assignments", 1001 . 1004 [IANA-ID] "IANA IPv6 Special-Purpose Address Registry", 1005 . 1008 [IANA-MA] "Application for an IPv6 Multicast Address", 1009 . 1011 [IANA-MC] "IPv6 Multicast Address Space Registry", 1012 . 1015 [IANA-NR] "Number Resources", . 1017 [IANA-NS] "Technical requirements for authoritative name servers", 1018 . 1020 [IANA-PN] "Modify a Port Number assignment", 1021 . 1023 [IANA-PR] "Protocol Registries", . 1025 [IANA-SP] "IANA IPv6 Special-Purpose Address Registry", 1026 . 1029 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1030 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1031 . 1033 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1034 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1035 August 2002, . 1037 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1038 (IPv6) Addressing Architecture", RFC 3513, DOI 10.17487/ 1039 RFC3513, April 2003, 1040 . 1042 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1043 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 1044 August 2003, . 1046 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1047 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 1048 2004, . 1050 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1051 Point (RP) Address in an IPv6 Multicast Address", RFC 1052 3956, DOI 10.17487/RFC3956, November 2004, 1053 . 1055 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1056 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 1057 10.17487/RFC4007, March 2005, 1058 . 1060 [RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and 1061 E. Castro, "Application Aspects of IPv6 Transition", RFC 1062 4038, DOI 10.17487/RFC4038, March 2005, 1063 . 1065 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1066 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1067 . 1069 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1070 10.17487/RFC4302, December 2005, 1071 . 1073 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1074 (CIDR): The Internet Address Assignment and Aggregation 1075 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1076 2006, . 1078 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1079 Extensions for Stateless Address Autoconfiguration in 1080 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1081 . 1083 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1084 Interface Identifiers with IPv6 Stateless Address 1085 Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/ 1086 RFC7217, April 2014, 1087 . 1089 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 1090 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 1091 Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/ 1092 RFC7421, January 2015, 1093 . 1095 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1096 over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/ 1097 RFC7428, February 2015, 1098 . 1100 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1101 Considerations for IPv6 Address Generation Mechanisms", 1102 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1103 . 1105 Appendix A. Modified EUI-64 Format Interface Identifiers 1107 Modified EUI-64 format-based interface identifiers may have universal 1108 scope when derived from a universal token (e.g., IEEE 802 48-bit MAC 1109 or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a 1110 global token is not being used (e.g., serial links, tunnel end- 1111 points) or where global tokens are undesirable (e.g., temporary 1112 tokens for privacy [RFC4941]. 1114 Modified EUI-64 format interface identifiers are formed by inverting 1115 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 1116 forming the interface identifier from IEEE EUI-64 identifiers. In 1117 the resulting Modified EUI-64 format, the "u" bit is set to one (1) 1118 to indicate universal scope, and it is set to zero (0) to indicate 1119 local scope. The first three octets in binary of an IEEE EUI-64 1120 identifier are as follows: 1122 0 0 0 1 1 2 1123 |0 7 8 5 6 3| 1124 +----+----+----+----+----+----+ 1125 |cccc|ccug|cccc|cccc|cccc|cccc| 1126 +----+----+----+----+----+----+ 1128 written in Internet standard bit-order, where "u" is the universal/ 1129 local bit, "g" is the individual/group bit, and "c" is the bits of 1130 the company_id. Appendix A, "Creating Modified EUI-64 Format 1131 Interface Identifiers", provides examples on the creation of Modified 1132 EUI-64 format-based interface identifiers. 1134 The motivation for inverting the "u" bit when forming an interface 1135 identifier is to make it easy for system administrators to hand 1136 configure non-global identifiers when hardware tokens are not 1137 available. This is expected to be the case for serial links and 1138 tunnel end-points, for example. The alternative would have been for 1139 these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the 1140 much simpler 0:0:0:1, 0:0:0:2, etc. 1142 IPv6 nodes are not required to validate that interface identifiers 1143 created with modified EUI-64 tokens with the "u" bit set to universal 1144 are unique. 1146 A.1. Creating Modified EUI-64 Format Interface Identifiers 1148 Depending on the characteristics of a specific link or node, there 1149 are a number of approaches for creating Modified EUI-64 format 1150 interface identifiers. This appendix describes some of these 1151 approaches. 1153 Links or Nodes with IEEE EUI-64 Identifiers 1155 The only change needed to transform an IEEE EUI-64 identifier to an 1156 interface identifier is to invert the "u" (universal/local) bit. An 1157 example is a globally unique IEEE EUI-64 identifier of the form: 1159 |0 1|1 3|3 4|4 6| 1160 |0 5|6 1|2 7|8 3| 1161 +----------------+----------------+----------------+----------------+ 1162 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 1163 +----------------+----------------+----------------+----------------+ 1165 where "c" is the bits of the assigned company_id, "0" is the value of 1166 the universal/local bit to indicate universal scope, "g" is 1167 individual/group bit, and "m" is the bits of the manufacturer- 1168 selected extension identifier. The IPv6 interface identifier would 1169 be of the form: 1171 |0 1|1 3|3 4|4 6| 1172 |0 5|6 1|2 7|8 3| 1173 +----------------+----------------+----------------+----------------+ 1174 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 1175 +----------------+----------------+----------------+----------------+ 1177 The only change is inverting the value of the universal/local bit. 1179 Links or Nodes with IEEE 802 48-bit MACs 1181 [EUI64] defines a method to create an IEEE EUI-64 identifier from an 1182 IEEE 48-bit MAC identifier. This is to insert two octets, with 1183 hexadecimal values of 0xFF and 0xFE (see the Note at the end of 1184 appendix), in the middle of the 48-bit MAC (between the company_id 1185 and vendor-supplied id). An example is the 48-bit IEEE MAC with 1186 Global scope: 1188 |0 1|1 3|3 4| 1189 |0 5|6 1|2 7| 1190 +----------------+----------------+----------------+ 1191 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 1192 +----------------+----------------+----------------+ 1194 where "c" is the bits of the assigned company_id, "0" is the value of 1195 the universal/local bit to indicate Global scope, "g" is individual/ 1196 group bit, and "m" is the bits of the manufacturer- selected 1197 extension identifier. The interface identifier would be of the form: 1199 |0 1|1 3|3 4|4 6| 1200 |0 5|6 1|2 7|8 3| 1201 +----------------+----------------+----------------+----------------+ 1202 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 1203 +----------------+----------------+----------------+----------------+ 1205 When IEEE 802 48-bit MAC addresses are available (on an interface or 1206 a node), an implementation may use them to create interface 1207 identifiers due to their availability and uniqueness properties. 1209 Links with Other Kinds of Identifiers 1211 There are a number of types of links that have link-layer interface 1212 identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples 1213 include LocalTalk and Arcnet. The method to create a Modified EUI-64 1214 format identifier is to take the link identifier (e.g., the LocalTalk 1215 8-bit node identifier) and zero fill it to the left. For example, a 1216 LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in 1217 the following interface identifier: 1219 |0 1|1 3|3 4|4 6| 1220 |0 5|6 1|2 7|8 3| 1221 +----------------+----------------+----------------+----------------+ 1222 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 1223 +----------------+----------------+----------------+----------------+ 1225 Note that this results in the universal/local bit set to "0" to 1226 indicate local scope. 1228 Links without Identifiers 1230 There are a number of links that do not have any type of built-in 1231 identifier. The most common of these are serial links and configured 1232 tunnels. Interface identifiers that are unique within a subnet 1233 prefix must be chosen. 1235 When no built-in identifier is available on a link, the preferred 1236 approach is to use a universal interface identifier from another 1237 interface or one that is assigned to the node itself. When using 1238 this approach, no other interface connecting the same node to the 1239 same subnet prefix may use the same identifier. 1241 If there is no universal interface identifier available for use on 1242 the link, the implementation needs to create a local-scope interface 1243 identifier. The only requirement is that it be unique within a 1244 subnet prefix. There are many possible approaches to select a 1245 subnet-prefix-unique interface identifier. These include the 1246 following: 1248 Manual Configuration 1249 Node Serial Number 1250 Other Node-Specific Token 1252 The subnet-prefix-unique interface identifier should be generated in 1253 a manner such that it does not change after a reboot of a node or if 1254 interfaces are added or deleted from the node. 1256 The selection of the appropriate algorithm is link and implementation 1257 dependent. The details on forming interface identifiers are defined 1258 in the appropriate "IPv6 over " specification. It is strongly 1259 recommended that a collision detection algorithm be implemented as 1260 part of any automatic algorithm. 1262 Note: [EUI64] actually defines 0xFF and 0xFF as the bits to be 1263 inserted to create an IEEE EUI-64 identifier from an IEEE MAC- 1264 48 identifier. The 0xFF and 0xFE values are used when 1265 starting with an IEEE EUI-48 identifier. The incorrect value 1266 was used in earlier versions of the specification due to a 1267 misunderstanding about the differences between IEEE MAC-48 and 1268 EUI-48 identifiers. 1270 This document purposely continues the use of 0xFF and 0xFE 1271 because it meets the requirements for IPv6 interface 1272 identifiers (i.e., that they must be unique on the link), IEEE 1273 EUI-48 and MAC-48 identifiers are syntactically equivalent, 1274 and that it doesn't cause any problems in practice. 1276 Appendix B. CHANGES SINCE RFC 4291 1278 This document has the following changes from RFC4291, "IP Version 6 1279 Addressing Architecture". Numbers identify the Internet-Draft 1280 version that the change was made.: 1282 Working Group Internet Drafts 1284 05) Expanded Security Considerations Section to discuss privacy 1285 issues related to using stable interface identifiers to 1286 create IPv6 addresses, and reference solutions that mitigate 1287 these issues such as RFC7721, RFC4941, RFC7271. 1289 05) Added instructions in IANA Considerations to update 1290 references in the IANA registries that currently point to 1291 RFC4291 to point to this document. 1293 05) Rename Section 2.4.7 to "Other Local Unicast Addresses" and 1294 rewrote the text to point to ULAs and say that Site-Local 1295 addresses were deprecated by RFC3879. The format of Site- 1296 Local was removed. 1298 05) Added to Section 2.4.1 a reference to RFC7421 regarding the 1299 background on the 64 bit boundary in Interface Identifiers. 1301 05) Editorial changes. 1303 04) Added text and a pointer to the ULA specification in 1304 Section 2.4.7 1306 04) Removed old IANA Considerations text, this was left from the 1307 baseline text from RFC4291 and should have been removed 1308 earlier. 1310 04) Editorial changes. 1312 03) Changes references in Section 2.4.1 that describes the 1313 details of forming IIDs to RFC7271 and RFC7721. 1315 02) Remove changes made by RFC7371 because there isn't any known 1316 implementation experience. 1318 01) Revised Section 2.4.1 on Interface Identifiers to reflect 1319 current approach, this included saying Modified EUI-64 1320 identifiers not recommended and moved the text describing the 1321 format to Appendix A. 1323 01) Editorial changes. 1325 00) Working Group Draft. 1327 00) Editorial changes. 1329 Individual Internet Drafts 1331 06) Incorporate the updates made by RFC7371. The changes were to 1332 the flag bits and their definitions in Section 2.6. 1334 05) Incorporate the updates made by RFC7346. The change was to 1335 add Realm-Local scope to the multicast scope table in 1336 Section 2.6, and add the updating text to the same section. 1338 04) Incorporate the updates made by RFC6052. The change was to 1339 add a text in Section 2.3 that points to the IANA registries 1340 that records the prefix defined in RFC6052 and a number of 1341 other special use prefixes. 1343 03) Incorporate the updates made by RFC7136 to deprecate the U 1344 and G bits in Modified EUI-64 format Internet IDs. 1346 03) Add note to the reference section acknowledging the authors 1347 of the updating documents. 1349 03) Editorial changes. 1351 02) Updates to resolve the open Errata on RFC4291. These are: 1353 Errata ID: 3480: Corrects the definition of Interface- 1354 Local multicast scope to also state that packets with 1355 interface-local scope received from another node must be 1356 discarded. 1358 Errata ID: 1627: Remove extraneous "of" in Section 2.7. 1360 Errata ID: 2702: This errata is marked rejected. No 1361 change is required. 1363 Errata ID: 2735: This errata is marked rejected. No 1364 change is required. 1366 Errata ID: 4406: This errata is marked rejected. No 1367 change is required. 1369 Errata ID: 2406: This errata is marked rejected. No 1370 change is required. 1372 Errata ID: 863: This errata is marked rejected. No change 1373 is required. 1375 Errata ID: 864: This errata is marked rejected. No change 1376 is required. 1378 Errata ID: 866: This errata is marked rejected. No change 1379 is required. 1381 02) Update references to current versions. 1383 02) Editorial changes. 1385 01) Incorporate the updates made by RFC5952 regarding the text 1386 format when outputting IPv6 addresses. A new section was 1387 added for this and addresses shown in this document were 1388 changed to lower case. 1390 01) Revise this Section to document to show the changes from 1391 RFC4291. 1393 01) Editorial changes. 1395 00) Establish a baseline from RFC4291. The only intended changes 1396 are formatting (XML is slightly different from .nroff), 1397 differences between an RFC and Internet Draft, fixing a few 1398 ID Nits, and updates to the authors information. There 1399 should not be any content changes to the specification. 1401 Authors' Addresses 1403 Robert M. Hinden 1404 Check Point Software 1405 959 Skyway Road 1406 San Carlos, CA 94070 1407 USA 1409 Email: bob.hinden@gmail.com 1411 Stephen E. Deering 1412 Retired 1413 Vancouver, British Columbia 1414 Canada