idnits 2.17.1 draft-ietf-6man-rfc4291bis-08.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 242 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 (June 20, 2017) is 2500 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) -- 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 (~~), 4 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: December 22, 2017 June 20, 2017 8 IP Version 6 Addressing Architecture 9 draft-ietf-6man-rfc4291bis-08 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 December 22, 2017. 39 Copyright Notice 41 Copyright (c) 2017 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 . . . . . . . 6 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 . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . 15 87 2.5.1. Required Anycast Address . . . . . . . . . . . . . . 15 88 2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16 89 2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 6.1. Normative References . . . . . . . . . . . . . . . . . . 23 96 6.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Appendix A. Modified EUI-64 Format Interface Identifiers . . . . 26 99 A.1. Creating Modified EUI-64 Format Interface Identifiers . . 26 100 Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 29 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 Note: The term "prefix" is used in several different contexts for 142 IPv6: a prefix used by a routing protocol, a prefix used by a node 143 to determine if another node is connected to the same link, and a 144 prefix used to construct the complete address of a node. 146 In IPv6, all zeros and all ones are legal values for any field, 147 unless specifically excluded. Specifically, prefixes may contain, or 148 end with, zero-valued fields. 150 2.1. Addressing Model 152 IPv6 addresses of all types are assigned to interfaces, not nodes. 153 An IPv6 unicast address refers to a single interface. Since each 154 interface belongs to a single node, any of that node's interfaces' 155 unicast addresses may be used as an identifier for the node. 157 All interfaces are required to have at least one Link-Local unicast 158 address (see Section 2.7 for additional required addresses). A 159 single interface may also have multiple IPv6 addresses of any type 160 (unicast, anycast, and multicast) or scope. Unicast addresses with a 161 scope greater than link-scope are not needed for interfaces that are 162 not used as the origin or destination of any IPv6 packets to or from 163 non-neighbors. This is sometimes convenient for point-to-point 164 interfaces. There is one exception to this addressing model: 166 A unicast address or a set of unicast addresses may be assigned to 167 multiple physical interfaces if the implementation treats the 168 multiple physical interfaces as one interface when presenting it 169 to the internet layer. This is useful for load-sharing over 170 multiple physical interfaces. 172 Currently, IPv6 continues the IPv4 model in that a subnet prefix is 173 associated with one link. Multiple subnet prefixes may be assigned 174 to the same link. 176 2.2. Text Representation of IPv6 Addresses 178 2.2.1. Text Representation of Addresses 180 There are three conventional forms for representing IPv6 addresses as 181 text strings: 183 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to 184 four hexadecimal digits of the eight 16-bit pieces of the address. 185 Examples: 187 abcd:ef01:2345:6789:abcd:ef01:2345:6789 188 2001:db8:0:0:8:800:200c:417a 190 Note that it is not necessary to write the leading zeros in an 191 individual field, but there must be at least one numeral in every 192 field (except for the case described in 2.). 194 2. Due to some methods of allocating certain styles of IPv6 195 addresses, it will be common for addresses to contain long strings 196 of zero bits. In order to make writing addresses containing zero 197 bits easier, a special syntax is available to compress the zeros. 198 The use of "::" indicates one or more groups of 16 bits of zeros. 199 The "::" can only appear once in an address. The "::" can also be 200 used to compress leading or trailing zeros in an address. 202 For example, the following addresses 204 2001:db8:0:0:8:800:200c:417a a unicast address 205 ff01:0:0:0:0:0:0:101 a multicast address 206 0:0:0:0:0:0:0:1 the loopback address 207 0:0:0:0:0:0:0:0 the unspecified address 209 may be represented as 211 2001:db8::8:800:200c:417a a unicast address 212 ff01::101 a multicast address 213 ::1 the loopback address 214 :: the unspecified address 216 3. An alternative form that is sometimes more convenient when dealing 217 with a mixed environment of IPv4 and IPv6 nodes is 218 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 219 the six high-order 16-bit pieces of the address, and the 'd's are 220 the decimal values of the four low-order 8-bit pieces of the 221 address (standard IPv4 representation). Examples: 223 0:0:0:0:0:0:13.1.68.3 224 0:0:0:0:0:ffff:129.144.52.38 226 or in compressed form: 228 ::13.1.68.3 229 ::ffff:129.144.52.38 231 2.2.2. Text Representation of Address Prefixes 233 The text representation of IPv6 address prefixes is similar to the 234 way IPv4 address prefixes are written in Classless Inter-Domain 235 Routing (CIDR) notation [RFC4632]. An IPv6 address prefix is 236 represented by the notation: 238 ipv6-address/prefix-length 240 where 242 ipv6-address is an IPv6 address in any of the notations listed in 243 Section 2.2. 245 prefix-length is a decimal value specifying how many of the leftmost 246 contiguous bits of the address comprise the prefix. 248 For example, the following are legal representations of the 60-bit 249 prefix 20010db80000cd3 (hexadecimal): 251 2001:0db8:0000:cd30:0000:0000:0000:0000/60 253 2001:0db8::cd30:0:0:0:0/60 255 2001:0db8:0:cd30::/60 257 The following are NOT legal representations of the above prefix: 259 2001:0db8:0:cd3/60 may drop leading zeros, but not trailing 260 zeros, within any 16-bit chunk of the address 262 2001:0db8::cd30/60 address to left of "/" expands to 263 2001:0db8:0000:0000:0000:0000:0000:cd30 265 2001:0db8::cd3/60 address to left of "/" expands to 266 2001:0db8:0000:0000:0000:0000:0000:0cd3 268 When writing both a node address and a prefix of that node address 269 (e.g., the node's subnet prefix), the two can be combined as follows: 271 the node address 2001:0db8:0:cd30:123:4567:89ab:cdef 272 and its subnet number 2001:0db8:0:cd30::/60 273 can be abbreviated as 2001:0db8:0:cd30:123:4567:89ab:cdef/60 275 2.2.3. Recommendation for outputting IPv6 addresses 277 This section provides a recommendation for systems generating and 278 outputting IPv6 addresses as text. Note, all implementations must 279 accept and process all addresses in the formats defined in the 280 previous two sections of this document. Background on this 281 recommendation can be found in [RFC5952]. 283 The recommendations are as follows: 285 1. The hexadecimal digits "a", "b", "c", "d", "e", and "f" in an IPv6 286 address must be represented in lowercase. 288 2. Leading zeros in a 16-Bit Field must be suppressed. For example, 290 2001:0db8::0001 292 is not correct and must be represented as 294 2001:db8::1 296 3. A single 16-bit 0000 field must be represented as 0. 298 The use of the symbol "::" must be used to its maximum capability. 299 For example: 301 2001:db8:0:0:0:0:2:1 303 must be shortened to 305 2001:db8::2:1 307 Likewise, 309 2001:db8::0:1 311 is not correct, because the symbol "::" could have been used to 312 produce a shorter representation 314 2001:db8::1. 316 4. When there is an alternative choice in the placement of a "::", 317 the longest run of consecutive 16-bit 0 fields must be shortened, 318 that is, in 320 2001:0:0:1:0:0:0:1 322 the sequence with three consecutive zero fields is shortened to 324 2001:0:0:1::1 326 5. When the length of the consecutive 16-bit 0 fields are equal, for 327 example 329 2001:db8:0:0:1:0:0:1 331 the first sequence of zero bits must be shortened. For example 333 2001:db8::1:0:0:1 335 is the correct representation. 337 6. The symbol "::" must not be used to shorten just one 16-bit 0 338 field. For example, the representation 340 2001:db8:0:1:1:1:1:1 342 is correct, but 344 2001:db8::1:1:1:1:1 346 is not correct. 348 7. The text representation method describe in this section should 349 also be use for text Representation of IPv6 Address Prefixes. For 350 example 352 2001:0db8:0000:cd30:0000:0000:0000:0000/60 354 should be shown as 356 2001:0db8:0:cd30::/60 358 8. The text representation method describe in this section should be 359 applied for IPv6 addresses with embedded IPv4 address. For 360 example 362 0:0:0:0:0:ffff:192.0.2.1 364 should be shown as 366 ::ffff:192.0.2.1 368 2.3. Address Type Identification 370 The type of an IPv6 address is identified by the high-order bits of 371 the address, as follows: 373 Address type Binary prefix IPv6 notation Section 374 ------------ ------------- ------------- ------- 375 Unspecified 00...0 (128 bits) ::/128 2.4.2 376 Loopback 00...1 (128 bits) ::1/128 2.4.3 377 Multicast 11111111 ff00::/8 2.6 378 Link-Local unicast 1111111010 fe80::/10 2.4.6 379 Global Unicast (everything else) 381 Anycast addresses are taken from the unicast address spaces (of any 382 scope) and are not syntactically distinguishable from unicast 383 addresses. 385 The general format of Global Unicast addresses is described in 386 Section 2.4.4. Some special-purpose subtypes of Global Unicast 387 addresses that contain embedded IPv4 addresses (for the purposes of 388 IPv4-IPv6 interoperation) are described in Section 2.4.5. 390 Future specifications may redefine one or more sub-ranges of the 391 Global Unicast space for other purposes, but unless and until that 392 happens, implementations must treat all addresses that do not start 393 with any of the above-listed prefixes as Global Unicast addresses. 395 The current assigned IPv6 prefixes and references to their usage can 396 be found in the IANA Internet Protocol Version 6 Address Space 397 registry [IANA-AD] and the IANA IPv6 Special-Purpose Address Registry 398 [IANA-SP]. 400 2.4. Unicast Addresses 402 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 403 bit-length, similar to IPv4 addresses under Classless Inter-Domain 404 Routing. 406 IPv6 unicast routing is based on prefixes of any valid length up to 407 128 [BCP198]. 409 There are several types of unicast addresses in IPv6, in particular, 410 Global Unicast, Local unicast, and Link-Local unicast. There are 411 also some special-purpose subtypes of Global Unicast, such as IPv6 412 addresses with embedded IPv4 addresses. Additional address types or 413 subtypes can be defined in the future. 415 IPv6 nodes may have considerable or little knowledge of the internal 416 structure of the IPv6 address, depending on the role the node plays 417 (for instance, host versus router). At a minimum, a node may 418 consider that unicast addresses (including its own) have no internal 419 structure: 421 | 128 bits | 422 +-----------------------------------------------------------------+ 423 | node address | 424 +-----------------------------------------------------------------+ 426 A slightly more complex host may additionally be aware of subnet 427 prefix(es) for the link(s) it is attached to, where different 428 addresses may have different values for n: 430 | n bits | 128-n bits | 431 +-------------------------------+---------------------------------+ 432 | subnet prefix | interface ID | 433 +-------------------------------+---------------------------------+ 435 Though a very simple router may have no knowledge of the internal 436 structure of IPv6 unicast addresses, routers will more generally have 437 knowledge of one or more of the hierarchical boundaries for the 438 operation of routing protocols. The known boundaries will differ 439 from router to router, depending on what positions the router holds 440 in the routing hierarchy. 442 Except for the knowledge of the subnet boundary discussed in the 443 previous paragraphs, nodes should not make any assumptions about the 444 structure of an IPv6 address. 446 2.4.1. Interface Identifiers 448 Interface identifiers in IPv6 unicast addresses are used to identify 449 interfaces on a link. They are required to be unique within a subnet 450 prefix. It is recommended that the same interface identifier not be 451 assigned to different nodes on a link. They may also be unique over 452 a broader scope. The same interface identifier may be used on 453 multiple interfaces on a single node, as long as they are attached to 454 different subnets. 456 Interface IDs must be viewed outside of the node that created 457 Interface ID as an opaque bit string without any internal structure. 459 Note that the uniqueness of interface identifiers is independent of 460 the uniqueness of IPv6 addresses. For example, a Global Unicast 461 address may be created with an interface identifier that is only 462 unique on a single subnet, and a Link-Local address may be created 463 with interface identifier that is unique over multiple subnets. 465 Interface Identifiers are 64 bit long except if the first three bits 466 of the address are 000, or when the addresses are manually 467 configured, or by exceptions defined in standards track documents. 468 The rationale for using 64 bit Interface Identifiers can be found in 469 [RFC7421]. An example of a standards track exception is [RFC6164] 470 that standardises 127 bit prefixes on inter-router point-to-point 471 links. 473 Note: In the case of manual configuration, the Prefix and 474 Interface Identifier can be any length as long as they add up to 475 128. 477 The details of forming interface identifiers are defined in other 478 specifications, such as "Privacy Extensions for Stateless Address 479 Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating 480 Semantically Opaque Interface Identifiers with IPv6 Stateless Address 481 Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in 482 appropriate "IPv6 over " specifications, such as "IPv6 over 483 Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T 484 G.9959 Networks" [RFC7428]. The security and privacy considerations 485 for IPv6 address generation is described in [RFC7721]. 487 Earlier versions of this document described a method of forming 488 interface identifiers derived from IEEE MAC-layer addresses call 489 Modified EUI-64 format. These are described in Appendix A and are no 490 longer recommended. 492 2.4.2. The Unspecified Address 494 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 495 must never be assigned to any node. It indicates the absence of an 496 address. One example of its use is in the Source Address field of 497 any IPv6 packets sent by an initializing host before it has learned 498 its own address. 500 The unspecified address must not be used as the destination address 501 of IPv6 packets or in IPv6 Routing headers. An IPv6 packet with a 502 source address of unspecified must never be forwarded by an IPv6 503 router. 505 2.4.3. The Loopback Address 507 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 508 It may be used by a node to send an IPv6 packet to itself. It must 509 not be assigned to any physical interface. It is treated as having 510 Link-Local scope, and may be thought of as the Link-Local unicast 511 address of a virtual interface (typically called the "loopback 512 interface") to an imaginary link that goes nowhere. 514 The loopback address must not be used as the source address in IPv6 515 packets that are sent outside of a single node. An IPv6 packet with 516 a destination address of loopback must never be sent outside of a 517 single node and must never be forwarded by an IPv6 router. A packet 518 received on an interface with a destination address of loopback must 519 be dropped. 521 2.4.4. Global Unicast Addresses 523 The general format for IPv6 Global Unicast addresses is as follows: 525 | n bits | m bits | 128-n-m bits | 526 +------------------------+-----------+----------------------------+ 527 | global routing prefix | subnet ID | interface ID | 528 +------------------------+-----------+----------------------------+ 530 where the global routing prefix is a (typically hierarchically- 531 structured) value assigned to a site (a cluster of subnets/links), 532 the subnet ID is an identifier of a link within the site, and the 533 interface ID is as defined in Section 2.4.1. 535 Examples of Global Unicast addresses that start with binary 000 are 536 the IPv6 address with embedded IPv4 addresses described in 537 Section 2.4.5. An example of global addresses starting with a binary 538 value other than 000 (and therefore having a 64-bit interface ID 539 field) can be found in [RFC3587]. 541 2.4.5. IPv6 Addresses with Embedded IPv4 Addresses 543 Two types of IPv6 addresses are defined that carry an IPv4 address in 544 the low-order 32 bits of the address. These are the "IPv4-Compatible 545 IPv6 address" and the "IPv4-mapped IPv6 address". 547 2.4.5.1. IPv4-Compatible IPv6 Address 549 The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 550 transition. The format of the "IPv4-Compatible IPv6 address" is as 551 follows: 553 | 80 bits | 16 | 32 bits | 554 +--------------------------------------+--------------------------+ 555 |0000..............................0000|0000| IPv4 address | 556 +--------------------------------------+----+---------------------+ 558 Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" 559 must be a globally-unique IPv4 unicast address. 561 The "IPv4-Compatible IPv6 address" is now deprecated because the 562 current IPv6 transition mechanisms no longer use these addresses. 563 New or updated implementations are not required to support this 564 address type. 566 2.4.5.2. IPv4-Mapped IPv6 Address 568 A second type of IPv6 address that holds an embedded IPv4 address is 569 defined. This address type is used to represent the addresses of 570 IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 571 address" is as follows: 573 | 80 bits | 16 | 32 bits | 574 +--------------------------------------+--------------------------+ 575 |0000..............................0000|ffff| IPv4 address | 576 +--------------------------------------+----+---------------------+ 578 See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 579 address". 581 2.4.6. Link-Local IPv6 Unicast Addresses 583 Link-Local addresses are for use on a single link. Link-Local 584 addresses have the following format: 586 | 10 | 587 | bits | 54 bits | 64 bits | 588 +----------+-------------------------+----------------------------+ 589 |1111111010| 0 | interface ID | 590 +----------+-------------------------+----------------------------+ 592 Link-Local addresses are designed to be used for addressing on a 593 single link for purposes such as automatic address configuration, 594 neighbor discovery, or when no routers are present. 596 Routers must not forward any packets with Link-Local source or 597 destination addresses to other links. 599 2.4.7. Other Local Unicast IPv6 Addresses 601 Unique Local Addresses (ULA) [RFC4193], the current form of Local 602 IPv6 Addresses, are intended to be used for local communications, 603 have global unicast scope, and are not expected to be routable on the 604 global Internet. 606 Site-Local addresses, deprecated by [RFC3879], the previous form of 607 Local IPv6 Addresses, were originally designed to be used for 608 addressing inside of a site without the need for a global prefix. 610 The special behavior of Site-Local defined in [RFC3513] must no 611 longer be supported in new implementations (i.e., new implementations 612 must treat this prefix as Global Unicast). Existing implementations 613 and deployments may continue to use this prefix. 615 2.5. Anycast Addresses 617 An IPv6 anycast address is an address that is assigned to more than 618 one interface (typically belonging to different nodes), with the 619 property that a packet sent to an anycast address is routed to the 620 "nearest" interface having that address, according to the routing 621 protocols' measure of distance. 623 Anycast addresses are allocated from the unicast address space, using 624 any of the defined unicast address formats. Thus, anycast addresses 625 are syntactically indistinguishable from unicast addresses. When a 626 unicast address is assigned to more than one interface, thus turning 627 it into an anycast address, the nodes to which the address is 628 assigned must be explicitly configured to know that it is an anycast 629 address. 631 For any assigned anycast address, there is a longest prefix P of that 632 address that identifies the topological region in which all 633 interfaces belonging to that anycast address reside. Within the 634 region identified by P, the anycast address must be maintained as a 635 separate entry in the routing system (commonly referred to as a "host 636 route"); outside the region identified by P, the anycast address may 637 be aggregated into the routing entry for prefix P. 639 Note that in the worst case, the prefix P of an anycast set may be 640 the null prefix, i.e., the members of the set may have no topological 641 locality. In that case, the anycast address must be maintained as a 642 separate routing entry throughout the entire Internet, which presents 643 a severe scaling limit on how many such "global" anycast sets may be 644 supported. Therefore, it is expected that support for global anycast 645 sets may be unavailable or very restricted. 647 One expected use of anycast addresses is to identify the set of 648 routers belonging to an organization providing Internet service. 649 Such addresses could be used as intermediate addresses in an IPv6 650 Routing header, to cause a packet to be delivered via a particular 651 service provider or sequence of service providers. 653 Some other possible uses are to identify the set of routers attached 654 to a particular subnet, or the set of routers providing entry into a 655 particular routing domain. 657 2.5.1. Required Anycast Address 659 The Subnet-Router anycast address is predefined. Its format is as 660 follows: 662 | n bits | 128-n bits | 663 +------------------------------------------------+----------------+ 664 | subnet prefix | 00000000000000 | 665 +------------------------------------------------+----------------+ 667 The "subnet prefix" in an anycast address is the prefix that 668 identifies a specific link. This anycast address is syntactically 669 the same as a unicast address for an interface on the link with the 670 interface identifier set to zero. 672 Packets sent to the Subnet-Router anycast address will be delivered 673 to one router on the subnet. All routers are required to support the 674 Subnet-Router anycast addresses for the subnets to which they have 675 interfaces. 677 The Subnet-Router anycast address is intended to be used for 678 applications where a node needs to communicate with any one of the 679 set of routers. 681 2.6. Multicast Addresses 683 An IPv6 multicast address is an identifier for a group of interfaces 684 (typically on different nodes). An interface may belong to any 685 number of multicast groups. Multicast addresses have the following 686 format: 688 | 8 | 4 | 4 | 112 bits | 689 +------ -+----+----+---------------------------------------------+ 690 |11111111|flgs|scop| group ID | 691 +--------+----+----+---------------------------------------------+ 693 binary 11111111 at the start of the address identifies the address 694 as being a multicast address. 696 +-+-+-+-+ 697 flgs is a set of 4 flags: |0|R|P|T| 698 +-+-+-+-+ 700 The high-order flag is reserved, and must be initialized to 0. 702 T = 0 indicates a permanently-assigned ("well-known") multicast 703 address, assigned by the Internet Assigned Numbers Authority 704 (IANA). 706 T = 1 indicates a non-permanently-assigned ("transient" or 707 "dynamically" assigned) multicast address. 709 The P flag's definition and usage can be found in [RFC3306]. 711 The R flag's definition and usage can be found in [RFC3956]. 713 scop is a 4-bit multicast scope value used to limit the scope of 714 the multicast group. The values are as follows: 716 0 reserved 717 1 Interface-Local scope 718 2 Link-Local scope 719 3 Realm-Local scope 720 4 Admin-Local scope 721 5 Site-Local scope 722 6 (unassigned) 723 7 (unassigned) 724 8 Organization-Local scope 725 9 (unassigned) 726 A (unassigned) 727 B (unassigned) 728 C (unassigned) 729 D (unassigned) 730 E Global scope 731 F reserved 733 Interface-Local scope spans only a single interface on a node 734 and is useful only for loopback transmission of multicast. 735 Packets with interface-local scope received from another node 736 must be discarded. 738 Link-Local multicast scope spans the same topological region as 739 the corresponding unicast scope. 741 Interface-Local, Link-Local, and Realm-Local scope boundaries 742 are automatically derived from physical connectivity or other 743 non-multicast-related configurations. Global scope has no 744 boundary. The boundaries of all other non-reserved scopes of 745 Admin-Local or larger are administratively configured. For 746 reserved scopes, the way of configuring their boundaries will 747 be defined when the semantics of the scope are defined. 749 According to [RFC4007], the zone of a Realm-Local scope must 750 fall within zones of larger scope. Because the zone of a 751 Realm-Local scope is configured automatically while the zones 752 of larger scopes are configured manually, care must be taken in 753 the definition of those larger scopes to ensure that the 754 inclusion constraint is met. 756 Realm-Local scopes created by different network technologies 757 are considered to be independent and will have different zone 758 indices (see Section 6 of [RFC4007]). A router with interfaces 759 on links using different network technologies does not forward 760 traffic between the Realm-Local multicast scopes defined by 761 those technologies. 763 Site-Local scope is intended to span a single site. 765 Organization-Local scope is intended to span multiple sites 766 belonging to a single organization. 768 scopes labeled "(unassigned)" are available for administrators 769 to define additional multicast regions. 771 group ID identifies the multicast group, either permanent or 772 transient, within the given scope. Additional definitions of the 773 multicast group ID field structure are provided in [RFC3306]. 775 The "meaning" of a permanently-assigned multicast address is 776 independent of the scope value. For example, if the "NTP servers 777 group" is assigned a permanent multicast address with a group ID of 778 101 (hex), then 780 ff01:0:0:0:0:0:0:101 means all NTP servers on the same interface 781 (i.e., the same node) as the sender. 783 ff02:0:0:0:0:0:0:101 means all NTP servers on the same link as the 784 sender. 786 ff05:0:0:0:0:0:0:101 means all NTP servers in the same site as the 787 sender. 789 ff0e:0:0:0:0:0:0:101 means all NTP servers in the Internet. 791 Non-permanently-assigned multicast addresses are meaningful only 792 within a given scope. For example, a group identified by the non- 793 permanent, site-local multicast address ff15:0:0:0:0:0:0:101 at one 794 site bears no relationship to a group using the same address at a 795 different site, nor to a non-permanent group using the same group ID 796 with a different scope, nor to a permanent group with the same group 797 ID. 799 Multicast addresses must not be used as source addresses in IPv6 800 packets or appear in any Routing header. 802 Routers must not forward any multicast packets beyond the scope 803 indicated by the scop field in the destination multicast address. 805 Nodes must not originate a packet to a multicast address whose scop 806 field contains the reserved value 0; if such a packet is received, it 807 must be silently dropped. Nodes should not originate a packet to a 808 multicast address whose scop field contains the reserved value F; if 809 such a packet is sent or received, it must be treated the same as 810 packets destined to a global (scop E) multicast address. 812 2.6.1. Pre-Defined Multicast Addresses 814 The following well-known multicast addresses are pre-defined. The 815 group IDs defined in this section are defined for explicit scope 816 values. 818 Use of these group IDs for any other scope values, with the T flag 819 equal to 0, is not allowed. 821 Reserved Multicast Addresses: ff00:0:0:0:0:0:0:0 822 ff01:0:0:0:0:0:0:0 823 ff02:0:0:0:0:0:0:0 824 ff03:0:0:0:0:0:0:0 825 ff04:0:0:0:0:0:0:0 826 ff05:0:0:0:0:0:0:0 827 ff06:0:0:0:0:0:0:0 828 ff07:0:0:0:0:0:0:0 829 ff08:0:0:0:0:0:0:0 830 ff09:0:0:0:0:0:0:0 831 ff0a:0:0:0:0:0:0:0 832 ff0b:0:0:0:0:0:0:0 833 ff0c:0:0:0:0:0:0:0 834 ff0d:0:0:0:0:0:0:0 835 ff0e:0:0:0:0:0:0:0 836 ff0f:0:0:0:0:0:0:0 838 The above multicast addresses are reserved and shall never be 839 assigned to any multicast group. 841 All Nodes Addresses: ff01:0:0:0:0:0:0:1 842 ff02:0:0:0:0:0:0:1 844 The above multicast addresses identify the group of all IPv6 nodes, 845 within scope 1 (interface-local) or 2 (link-local). 847 All Routers Addresses: ff01:0:0:0:0:0:0:2 848 ff02:0:0:0:0:0:0:2 849 ff05:0:0:0:0:0:0:2 851 The above multicast addresses identify the group of all IPv6 routers, 852 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 854 Solicited-Node Address: ff02:0:0:0:0:1:ffxx:xxxx 856 Solicited-Node multicast address are computed as a function of a 857 node's unicast and anycast addresses. A Solicited-Node multicast 858 address is formed by taking the low-order 24 bits of an address 859 (unicast or anycast) and appending those bits to the prefix 860 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 861 range 863 ff02:0:0:0:0:1:ff00:0000 865 to 867 ff02:0:0:0:0:1:ffff:ffff 869 For example, the Solicited-Node multicast address corresponding to 870 the IPv6 address 4037::01:800:200e:8c6c is ff02::1:ff0e:8c6c. IPv6 871 addresses that differ only in the high-order bits (e.g., due to 872 multiple high-order prefixes associated with different aggregations) 873 will map to the same Solicited-Node address, thereby reducing the 874 number of multicast addresses a node must join. 876 A node is required to compute and join (on the appropriate interface) 877 the associated Solicited-Node multicast addresses for all unicast and 878 anycast addresses that have been configured for the node's interfaces 879 (manually or automatically). 881 Additional defined multicast address can be found in the IANA IPv6 882 Multicast Address Allocation registry [IANA-MC] 884 2.7. A Node's Required Addresses 886 A host is required to recognize the following addresses as 887 identifying itself: 889 o Its required Link-Local address for each interface. 891 o Any additional Unicast and Anycast addresses that have been 892 configured for the node's interfaces (manually or 893 automatically). 895 o The loopback address. 897 o The All-Nodes multicast addresses defined in Section 2.6.1. 899 o The Solicited-Node multicast address for each of its unicast 900 and anycast addresses. 902 o Multicast addresses of all other groups to which the node 903 belongs. 905 A router is required to recognize all addresses that a host is 906 required to recognize, plus the following addresses as identifying 907 itself: 909 o The Subnet-Router Anycast addresses for all interfaces for 910 which it is configured to act as a router. 912 o All other Anycast addresses with which the router has been 913 configured. 915 o The All-Routers multicast addresses defined in Section 2.6.1. 917 3. IANA Considerations 919 RFC4291 is referenced in a number of IANA registries. These include: 921 o Internet Protocol Version 6 Address Space [IANA-AD] 923 o IPv6 Global Unicast Address Assignments [IANA-GU] 925 o IPv6 Multicast Address Space Registry [IANA-MC] 927 o Application for an IPv6 Multicast Address [IANA-MA] 929 o Internet Protocol Version 6 (IPv6) Anycast Addresses [IANA-AC] 931 o IANA IPv6 Special-Purpose Address Registry [IANA-SP] 933 o Reserved IPv6 Interface Identifiers [IANA-ID] 934 o Number Resources [IANA-NR] 936 o Protocol Registries [IANA-PR] 938 o Technical requirements for authoritative name servers [IANA-NS] 940 o IP Flow Information Export (IPFIX) Entities [IANA-FE] 942 The IANA should update these references to point to this document. 944 There are also other references in IANA procedures documents that the 945 IANA should investigate to see if they should be updated. 947 4. Security Considerations 949 IPv6 addressing documents do not have any direct impact on Internet 950 infrastructure security. Authentication of IPv6 packets is defined 951 in [RFC4302]. 953 One area relavant to IPv6 addressing is privacy. IPv6 addresses can 954 be created using interface identifiers constructed with unique stable 955 tokens. The addresses created in this manner can be used to track 956 the movement of devices across the Internet. Since earlier versions 957 of this document were published, several approaches have been 958 developed that mitigate these problems. These are described in 959 "Security and Privacy Considerations for IPv6 Address Generation 960 Mechanisms" [RFC7721], "Privacy Extensions for Stateless Address 961 Autoconfiguration in IPv6" [RFC4941], and "A Method for Generating 962 Semantically Opaque Interface Identifiers with IPv6 Stateless Address 963 Autoconfiguration (SLAAC)" [RFC7217]. 965 5. Acknowledgments 967 The authors would like to acknowledge the contributions of Paul 968 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 969 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 970 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 971 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 972 Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, 973 Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali. 975 The authors would also like to acknowledge the authors of the 976 updating RFCs that were incorporated in this version of the document 977 to move IPv6 to Internet Standard. This includes Marcelo Bagnulo, 978 Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms, 979 Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima, 980 Xing Li, and Stig Venaas. 982 6. References 984 6.1. Normative References 986 [I-D.ietf-6man-rfc2460bis] 987 Deering, S. and R. Hinden, "Internet Protocol, Version 6 988 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 989 in progress), May 2017. 991 6.2. Informative References 993 [BCP198] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 994 Length Recommendation for Forwarding", BCP 198, RFC 7608, 995 DOI 10.17487/RFC7608, July 2015, 996 . 998 [EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 999 Registration Authority"", March 1997, 1000 . 1003 [IANA-AC] "Internet Protocol Version 6 (IPv6) Anycast Addresses", 1004 . 1007 [IANA-AD] "Internet Protocol Version 6 Address Space", 1008 . 1011 [IANA-FE] "IP Flow Information Export (IPFIX) Entities", 1012 . 1014 [IANA-GU] "IPv6 Global Unicast Address Assignments", 1015 . 1018 [IANA-ID] "IANA IPv6 Special-Purpose Address Registry", 1019 . 1022 [IANA-MA] "Application for an IPv6 Multicast Address", 1023 . 1025 [IANA-MC] "IPv6 Multicast Address Space Registry", 1026 . 1029 [IANA-NR] "Number Resources", . 1031 [IANA-NS] "Technical requirements for authoritative name servers", 1032 . 1034 [IANA-PR] "Protocol Registries", . 1036 [IANA-SP] "IANA IPv6 Special-Purpose Address Registry", 1037 . 1040 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1041 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1042 . 1044 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1045 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1046 August 2002, . 1048 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1049 (IPv6) Addressing Architecture", RFC 3513, DOI 10.17487/ 1050 RFC3513, April 2003, 1051 . 1053 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1054 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 1055 August 2003, . 1057 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1058 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 1059 2004, . 1061 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1062 Point (RP) Address in an IPv6 Multicast Address", RFC 1063 3956, DOI 10.17487/RFC3956, November 2004, 1064 . 1066 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1067 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 1068 10.17487/RFC4007, March 2005, 1069 . 1071 [RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and 1072 E. Castro, "Application Aspects of IPv6 Transition", RFC 1073 4038, DOI 10.17487/RFC4038, March 2005, 1074 . 1076 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1077 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1078 . 1080 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1081 10.17487/RFC4302, December 2005, 1082 . 1084 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1085 (CIDR): The Internet Address Assignment and Aggregation 1086 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1087 2006, . 1089 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1090 Extensions for Stateless Address Autoconfiguration in 1091 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1092 . 1094 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1095 Address Text Representation", RFC 5952, DOI 10.17487/ 1096 RFC5952, August 2010, 1097 . 1099 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1100 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1101 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1102 . 1104 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1105 Interface Identifiers with IPv6 Stateless Address 1106 Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/ 1107 RFC7217, April 2014, 1108 . 1110 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 1111 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 1112 Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/ 1113 RFC7421, January 2015, 1114 . 1116 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1117 over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/ 1118 RFC7428, February 2015, 1119 . 1121 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1122 Considerations for IPv6 Address Generation Mechanisms", 1123 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1124 . 1126 Appendix A. Modified EUI-64 Format Interface Identifiers 1128 Modified EUI-64 format-based interface identifiers may have universal 1129 scope when derived from a universal token (e.g., IEEE 802 48-bit MAC 1130 or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a 1131 global token is not being used (e.g., serial links, tunnel end- 1132 points) or where global tokens are undesirable (e.g., temporary 1133 tokens for privacy [RFC4941]. 1135 Modified EUI-64 format interface identifiers are formed by inverting 1136 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 1137 forming the interface identifier from IEEE EUI-64 identifiers. In 1138 the resulting Modified EUI-64 format, the "u" bit is set to one (1) 1139 to indicate universal scope, and it is set to zero (0) to indicate 1140 local scope. The first three octets in binary of an IEEE EUI-64 1141 identifier are as follows: 1143 0 0 0 1 1 2 1144 |0 7 8 5 6 3| 1145 +----+----+----+----+----+----+ 1146 |cccc|ccug|cccc|cccc|cccc|cccc| 1147 +----+----+----+----+----+----+ 1149 written in Internet standard bit-order, where "u" is the universal/ 1150 local bit, "g" is the individual/group bit, and "c" is the bits of 1151 the company_id. Appendix A, "Creating Modified EUI-64 Format 1152 Interface Identifiers", provides examples on the creation of Modified 1153 EUI-64 format-based interface identifiers. 1155 The motivation for inverting the "u" bit when forming an interface 1156 identifier is to make it easy for system administrators to hand 1157 configure non-global identifiers when hardware tokens are not 1158 available. This is expected to be the case for serial links and 1159 tunnel end-points, for example. The alternative would have been for 1160 these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the 1161 much simpler 0:0:0:1, 0:0:0:2, etc. 1163 IPv6 nodes are not required to validate that interface identifiers 1164 created with modified EUI-64 tokens with the "u" bit set to universal 1165 are unique. 1167 A.1. Creating Modified EUI-64 Format Interface Identifiers 1169 Depending on the characteristics of a specific link or node, there 1170 are a number of approaches for creating Modified EUI-64 format 1171 interface identifiers. This appendix describes some of these 1172 approaches. 1174 Links or Nodes with IEEE EUI-64 Identifiers 1176 The only change needed to transform an IEEE EUI-64 identifier to an 1177 interface identifier is to invert the "u" (universal/local) bit. An 1178 example is a globally unique IEEE EUI-64 identifier of the form: 1180 |0 1|1 3|3 4|4 6| 1181 |0 5|6 1|2 7|8 3| 1182 +----------------+----------------+----------------+----------------+ 1183 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 1184 +----------------+----------------+----------------+----------------+ 1186 where "c" is the bits of the assigned company_id, "0" is the value of 1187 the universal/local bit to indicate universal scope, "g" is 1188 individual/group bit, and "m" is the bits of the manufacturer- 1189 selected extension identifier. The IPv6 interface identifier would 1190 be of the form: 1192 |0 1|1 3|3 4|4 6| 1193 |0 5|6 1|2 7|8 3| 1194 +----------------+----------------+----------------+----------------+ 1195 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 1196 +----------------+----------------+----------------+----------------+ 1198 The only change is inverting the value of the universal/local bit. 1200 Links or Nodes with IEEE 802 48-bit MACs 1202 [EUI64] defines a method to create an IEEE EUI-64 identifier from an 1203 IEEE 48-bit MAC identifier. This is to insert two octets, with 1204 hexadecimal values of 0xFF and 0xFE (see the Note at the end of 1205 appendix), in the middle of the 48-bit MAC (between the company_id 1206 and vendor-supplied id). An example is the 48-bit IEEE MAC with 1207 Global scope: 1209 |0 1|1 3|3 4| 1210 |0 5|6 1|2 7| 1211 +----------------+----------------+----------------+ 1212 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 1213 +----------------+----------------+----------------+ 1215 where "c" is the bits of the assigned company_id, "0" is the value of 1216 the universal/local bit to indicate Global scope, "g" is individual/ 1217 group bit, and "m" is the bits of the manufacturer- selected 1218 extension identifier. The interface identifier would be of the form: 1220 |0 1|1 3|3 4|4 6| 1221 |0 5|6 1|2 7|8 3| 1222 +----------------+----------------+----------------+----------------+ 1223 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 1224 +----------------+----------------+----------------+----------------+ 1226 When IEEE 802 48-bit MAC addresses are available (on an interface or 1227 a node), an implementation may use them to create interface 1228 identifiers due to their availability and uniqueness properties. 1230 Links with Other Kinds of Identifiers 1232 There are a number of types of links that have link-layer interface 1233 identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples 1234 include LocalTalk and Arcnet. The method to create a Modified EUI-64 1235 format identifier is to take the link identifier (e.g., the LocalTalk 1236 8-bit node identifier) and zero fill it to the left. For example, a 1237 LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in 1238 the following interface identifier: 1240 |0 1|1 3|3 4|4 6| 1241 |0 5|6 1|2 7|8 3| 1242 +----------------+----------------+----------------+----------------+ 1243 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 1244 +----------------+----------------+----------------+----------------+ 1246 Note that this results in the universal/local bit set to "0" to 1247 indicate local scope. 1249 Links without Identifiers 1251 There are a number of links that do not have any type of built-in 1252 identifier. The most common of these are serial links and configured 1253 tunnels. Interface identifiers that are unique within a subnet 1254 prefix must be chosen. 1256 When no built-in identifier is available on a link, the preferred 1257 approach is to use a universal interface identifier from another 1258 interface or one that is assigned to the node itself. When using 1259 this approach, no other interface connecting the same node to the 1260 same subnet prefix may use the same identifier. 1262 If there is no universal interface identifier available for use on 1263 the link, the implementation needs to create a local-scope interface 1264 identifier. The only requirement is that it be unique within a 1265 subnet prefix. There are many possible approaches to select a 1266 subnet-prefix-unique interface identifier. These include the 1267 following: 1269 Manual Configuration 1270 Node Serial Number 1271 Other Node-Specific Token 1273 The subnet-prefix-unique interface identifier should be generated in 1274 a manner such that it does not change after a reboot of a node or if 1275 interfaces are added or deleted from the node. 1277 The selection of the appropriate algorithm is link and implementation 1278 dependent. The details on forming interface identifiers are defined 1279 in the appropriate "IPv6 over " specification. It is strongly 1280 recommended that a collision detection algorithm be implemented as 1281 part of any automatic algorithm. 1283 Note: [EUI64] actually defines 0xFF and 0xFF as the bits to be 1284 inserted to create an IEEE EUI-64 identifier from an IEEE MAC- 1285 48 identifier. The 0xFF and 0xFE values are used when 1286 starting with an IEEE EUI-48 identifier. The incorrect value 1287 was used in earlier versions of the specification due to a 1288 misunderstanding about the differences between IEEE MAC-48 and 1289 EUI-48 identifiers. 1291 This document purposely continues the use of 0xFF and 0xFE 1292 because it meets the requirements for IPv6 interface 1293 identifiers (i.e., that they must be unique on the link), IEEE 1294 EUI-48 and MAC-48 identifiers are syntactically equivalent, 1295 and that it doesn't cause any problems in practice. 1297 Appendix B. CHANGES SINCE RFC 4291 1299 This document has the following changes from RFC4291, "IP Version 6 1300 Addressing Architecture". Numbers identify the Internet-Draft 1301 version that the change was made.: 1303 Working Group Internet Drafts 1305 08) Added Note: to Section 2 that the term "prefix" is used in 1306 different contexts in IPv6: a prefix used by a routing 1307 protocol, a prefix used by a node to determine if another 1308 node is connected to the same link, and a prefix used to 1309 construct the complete address of a node. 1311 08) Based on results of IETF last call and extensive w.g. list 1312 discussion, revised text to clarify that 64 bit Interface IDs 1313 are used except when the first three bits of the address are 1314 000, or addresses are manually configured, or when defined by 1315 a standard track document. This text was moved from 1316 Section 2.4 and is now consolidated in Section 2.4.1 Also 1317 removed text in Section 2.4.4 relating to 64 bit Interface 1318 IDs. 1320 08) Removed instruction to IANA fix error in Port Number 1321 assignment. IANA fixed the error on 4 March 2017. 1323 08) Editorial changes. 1325 07) Added text to Section 2.4 summarizing IPv6 unicast routing 1326 and referencing BCP198, citing RFC6164 as an example of 1327 longer prefixes, and that IIDs are required to be 64 bits 1328 long as described in RFC7421. 1330 07) Based on review by Brian Haberman added reference to RFC5952 1331 in Section 2.2.3, corrected case errors in Section 2.6.1, and 1332 added a reference to the IANA Multicast address registry in 1333 Section 2.6.1. 1335 07) Corrected errors in Section 2.2.3 where the examples in 7. 1336 and 8. were reversed. 1338 07) Editorial changes. 1340 06) Editorial changes. 1342 05) Expanded Security Considerations Section to discuss privacy 1343 issues related to using stable interface identifiers to 1344 create IPv6 addresses, and reference solutions that mitigate 1345 these issues such as RFC7721, RFC4941, RFC7271. 1347 05) Added instructions in IANA Considerations to update 1348 references in the IANA registries that currently point to 1349 RFC4291 to point to this document. 1351 05) Rename Section 2.4.7 to "Other Local Unicast Addresses" and 1352 rewrote the text to point to ULAs and say that Site-Local 1353 addresses were deprecated by RFC3879. The format of Site- 1354 Local was removed. 1356 05) Added to Section 2.4.1 a reference to RFC7421 regarding the 1357 background on the 64 bit boundary in Interface Identifiers. 1359 05) Editorial changes. 1361 04) Added text and a pointer to the ULA specification in 1362 Section 2.4.7 1364 04) Removed old IANA Considerations text, this was left from the 1365 baseline text from RFC4291 and should have been removed 1366 earlier. 1368 04) Editorial changes. 1370 03) Changes references in Section 2.4.1 that describes the 1371 details of forming IIDs to RFC7271 and RFC7721. 1373 02) Remove changes made by RFC7371 because there isn't any known 1374 implementation experience. 1376 01) Revised Section 2.4.1 on Interface Identifiers to reflect 1377 current approach, this included saying Modified EUI-64 1378 identifiers not recommended and moved the text describing the 1379 format to Appendix A. 1381 01) Editorial changes. 1383 00) Working Group Draft. 1385 00) Editorial changes. 1387 Individual Internet Drafts 1389 06) Incorporate the updates made by RFC7371. The changes were to 1390 the flag bits and their definitions in Section 2.6. 1392 05) Incorporate the updates made by RFC7346. The change was to 1393 add Realm-Local scope to the multicast scope table in 1394 Section 2.6, and add the updating text to the same section. 1396 04) Incorporate the updates made by RFC6052. The change was to 1397 add a text in Section 2.3 that points to the IANA registries 1398 that records the prefix defined in RFC6052 and a number of 1399 other special use prefixes. 1401 03) Incorporate the updates made by RFC7136 to deprecate the U 1402 and G bits in Modified EUI-64 format Internet IDs. 1404 03) Add note to the reference section acknowledging the authors 1405 of the updating documents. 1407 03) Editorial changes. 1409 02) Updates to resolve the open Errata on RFC4291. These are: 1411 Errata ID: 3480: Corrects the definition of Interface- 1412 Local multicast scope to also state that packets with 1413 interface-local scope received from another node must be 1414 discarded. 1416 Errata ID: 1627: Remove extraneous "of" in Section 2.7. 1418 Errata ID: 2702: This errata is marked rejected. No 1419 change is required. 1421 Errata ID: 2735: This errata is marked rejected. No 1422 change is required. 1424 Errata ID: 4406: This errata is marked rejected. No 1425 change is required. 1427 Errata ID: 2406: This errata is marked rejected. No 1428 change is required. 1430 Errata ID: 863: This errata is marked rejected. No change 1431 is required. 1433 Errata ID: 864: This errata is marked rejected. No change 1434 is required. 1436 Errata ID: 866: This errata is marked rejected. No change 1437 is required. 1439 02) Update references to current versions. 1441 02) Editorial changes. 1443 01) Incorporate the updates made by RFC5952 regarding the text 1444 format when outputting IPv6 addresses. A new section was 1445 added for this and addresses shown in this document were 1446 changed to lower case. 1448 01) Revise this Section to document to show the changes from 1449 RFC4291. 1451 01) Editorial changes. 1453 00) Establish a baseline from RFC4291. The only intended changes 1454 are formatting (XML is slightly different from .nroff), 1455 differences between an RFC and Internet Draft, fixing a few 1456 ID Nits, and updates to the authors information. There 1457 should not be any content changes to the specification. 1459 Authors' Addresses 1461 Robert M. Hinden 1462 Check Point Software 1463 959 Skyway Road 1464 San Carlos, CA 94070 1465 USA 1467 Email: bob.hinden@gmail.com 1469 Stephen E. Deering 1470 Retired 1471 Vancouver, British Columbia 1472 Canada