idnits 2.17.1 draft-hinden-6man-rfc4291bis-06.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 15 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 19, 2015) is 3106 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) -- Looks like a reference, but probably isn't: '1' on line 949 -- Looks like a reference, but probably isn't: '5' on line 953 -- 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 (==), 5 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 21, 2016 October 19, 2015 8 IP Version 6 Addressing Architecture 9 draft-hinden-6man-rfc4291bis-06 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 21, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . 14 83 2.4.5.2. IPv4-Mapped IPv6 Address . . . . . . . . . . . . 14 84 2.4.6. Link-Local IPv6 Unicast Addresses . . . . . . . . . . 14 85 2.4.7. Site-Local IPv6 Unicast Addresses . . . . . . . . . . 15 86 2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . . . 15 87 2.5.1. Required Anycast Address . . . . . . . . . . . . . . 16 88 2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16 89 2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 19 90 2.7. A Node's Required Addresses . . . . . . . . . . . . . . . 21 91 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 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. Creating Modified EUI-64 Format Interface 99 Identifiers . . . . . . . . . . . . . . . . . . . . 24 100 Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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.hinden-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.8 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.5.2 369 Loopback 00...1 (128 bits) ::1/128 2.5.3 370 Multicast 11111111 ff00::/8 2.7 371 Link-Local unicast 1111111010 fe80::/10 2.5.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.5.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.5.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, site-local unicast (deprecated, see Section 2.5.7), 401 and Link-Local unicast. There are also some special-purpose subtypes 402 of Global Unicast, such as IPv6 addresses with embedded IPv4 403 addresses. Additional address types or subtypes can be defined in 404 the future. 406 IPv6 nodes may have considerable or little knowledge of the internal 407 structure of the IPv6 address, depending on the role the node plays 408 (for instance, host versus router). At a minimum, a node may 409 consider that unicast addresses (including its own) have no internal 410 structure: 412 | 128 bits | 413 +-----------------------------------------------------------------+ 414 | node address | 415 +-----------------------------------------------------------------+ 417 A slightly sophisticated host (but still rather simple) may 418 additionally be aware of subnet prefix(es) for the link(s) it is 419 attached to, where different addresses may have different values for 420 n: 422 | n bits | 128-n bits | 423 +-------------------------------+---------------------------------+ 424 | subnet prefix | interface ID | 425 +-------------------------------+---------------------------------+ 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 a local scope interface identifier and a 453 Link-Local address may be created with a universal scope interface 454 identifier. 456 For all unicast addresses, except those that start with the binary 457 value 000, Interface IDs are required to be 64 bits long. If derived 458 from an IEEE MAC-layer address, they must be constructed in Modified 459 EUI-64 format. 461 Modified EUI-64 format-based interface identifiers may have universal 462 scope when derived from a universal token (e.g., IEEE 802 48-bit MAC 463 or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a 464 global token is not being used (e.g., serial links, tunnel end- 465 points) or where global tokens are undesirable (e.g., temporary 466 tokens for privacy [RFC4941]. 468 Modified EUI-64 format interface identifiers are formed by inverting 469 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 470 forming the interface identifier from IEEE EUI-64 identifiers. In 471 the resulting Modified EUI-64 format, the "u" bit is set to one (1) 472 to indicate universal scope, and it is set to zero (0) to indicate 473 local scope. The first three octets in binary of an IEEE EUI-64 474 identifier are as follows: 476 0 0 0 1 1 2 477 |0 7 8 5 6 3| 478 +----+----+----+----+----+----+ 479 |cccc|ccug|cccc|cccc|cccc|cccc| 480 +----+----+----+----+----+----+ 482 written in Internet standard bit-order, where "u" is the universal/ 483 local bit, "g" is the individual/group bit, and "c" is the bits of 484 the company_id. Appendix A, "Creating Modified EUI-64 Format 485 Interface Identifiers", provides examples on the creation of Modified 486 EUI-64 format-based interface identifiers. 488 The motivation for inverting the "u" bit when forming an interface 489 identifier is to make it easy for system administrators to hand 490 configure non-global identifiers when hardware tokens are not 491 available. This is expected to be the case for serial links and 492 tunnel end-points, for example. The alternative would have been for 493 these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the 494 much simpler 0:0:0:1, 0:0:0:2, etc. 496 IPv6 nodes are not required to validate that interface identifiers 497 created with modified EUI-64 tokens with the "u" bit set to universal 498 are unique. 500 The details of forming interface identifiers are defined in the 501 appropriate "IPv6 over " specification, such as "IPv6 over 502 Ethernet" [RFC2464], and "IPv6 over FDDI" [RFC2467]. 504 2.4.2. The Unspecified Address 506 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 507 must never be assigned to any node. It indicates the absence of an 508 address. One example of its use is in the Source Address field of 509 any IPv6 packets sent by an initializing host before it has learned 510 its own address. 512 The unspecified address must not be used as the destination address 513 of IPv6 packets or in IPv6 Routing headers. An IPv6 packet with a 514 source address of unspecified must never be forwarded by an IPv6 515 router. 517 2.4.3. The Loopback Address 519 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 520 It may be used by a node to send an IPv6 packet to itself. It must 521 not be assigned to any physical interface. It is treated as having 522 Link-Local scope, and may be thought of as the Link-Local unicast 523 address of a virtual interface (typically called the "loopback 524 interface") to an imaginary link that goes nowhere. 526 The loopback address must not be used as the source address in IPv6 527 packets that are sent outside of a single node. An IPv6 packet with 528 a destination address of loopback must never be sent outside of a 529 single node and must never be forwarded by an IPv6 router. A packet 530 received on an interface with a destination address of loopback must 531 be dropped. 533 2.4.4. Global Unicast Addresses 535 The general format for IPv6 Global Unicast addresses is as follows: 537 | n bits | m bits | 128-n-m bits | 538 +------------------------+-----------+----------------------------+ 539 | global routing prefix | subnet ID | interface ID | 540 +------------------------+-----------+----------------------------+ 542 where the global routing prefix is a (typically hierarchically- 543 structured) value assigned to a site (a cluster of subnets/links), 544 the subnet ID is an identifier of a link within the site, and the 545 interface ID is as defined in Section 2.5.1. 547 All Global Unicast addresses other than those that start with binary 548 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 549 described in Section 2.5.1. Global Unicast addresses that start with 550 binary 000 have no such constraint on the size or structure of the 551 interface ID field. 553 Examples of Global Unicast addresses that start with binary 000 are 554 the IPv6 address with embedded IPv4 addresses described in 555 Section 2.5.5. An example of global addresses starting with a binary 556 value other than 000 (and therefore having a 64-bit interface ID 557 field) can be found in [RFC3587]. 559 2.4.5. IPv6 Addresses with Embedded IPv4 Addresses 561 Two types of IPv6 addresses are defined that carry an IPv4 address in 562 the low-order 32 bits of the address. These are the "IPv4-Compatible 563 IPv6 address" and the "IPv4-mapped IPv6 address". 565 2.4.5.1. IPv4-Compatible IPv6 Address 567 The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 568 transition. The format of the "IPv4-Compatible IPv6 address" is as 569 follows: 571 | 80 bits | 16 | 32 bits | 572 +--------------------------------------+--------------------------+ 573 |0000..............................0000|0000| IPv4 address | 574 +--------------------------------------+----+---------------------+ 576 Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" 577 must be a globally-unique IPv4 unicast address. 579 The "IPv4-Compatible IPv6 address" is now deprecated because the 580 current IPv6 transition mechanisms no longer use these addresses. 581 New or updated implementations are not required to support this 582 address type. 584 2.4.5.2. IPv4-Mapped IPv6 Address 586 A second type of IPv6 address that holds an embedded IPv4 address is 587 defined. This address type is used to represent the addresses of 588 IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 589 address" is as follows: 591 | 80 bits | 16 | 32 bits | 592 +--------------------------------------+--------------------------+ 593 |0000..............................0000|ffff| IPv4 address | 594 +--------------------------------------+----+---------------------+ 596 See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 597 address". 599 2.4.6. Link-Local IPv6 Unicast Addresses 601 Link-Local addresses are for use on a single link. Link-Local 602 addresses have the following format: 604 | 10 | 605 | bits | 54 bits | 64 bits | 606 +----------+-------------------------+----------------------------+ 607 |1111111010| 0 | interface ID | 608 +----------+-------------------------+----------------------------+ 610 Link-Local addresses are designed to be used for addressing on a 611 single link for purposes such as automatic address configuration, 612 neighbor discovery, or when no routers are present. 614 Routers must not forward any packets with Link-Local source or 615 destination addresses to other links. 617 2.4.7. Site-Local IPv6 Unicast Addresses 619 Site-Local addresses were originally designed to be used for 620 addressing inside of a site without the need for a global prefix. 621 Site-local addresses are now deprecated as defined in [RFC3879]. 623 Site-Local addresses have the following format: 625 | 10 | 626 | bits | 54 bits | 64 bits | 627 +----------+-------------------------+----------------------------+ 628 |1111111011| subnet ID | interface ID | 629 +----------+-------------------------+----------------------------+ 631 The special behavior of this prefix defined in [RFC3513] must no 632 longer be supported in new implementations (i.e., new implementations 633 must treat this prefix as Global Unicast). 635 Existing implementations and deployments may continue to use this 636 prefix. 638 2.5. Anycast Addresses 640 An IPv6 anycast address is an address that is assigned to more than 641 one interface (typically belonging to different nodes), with the 642 property that a packet sent to an anycast address is routed to the 643 "nearest" interface having that address, according to the routing 644 protocols' measure of distance. 646 Anycast addresses are allocated from the unicast address space, using 647 any of the defined unicast address formats. Thus, anycast addresses 648 are syntactically indistinguishable from unicast addresses. When a 649 unicast address is assigned to more than one interface, thus turning 650 it into an anycast address, the nodes to which the address is 651 assigned must be explicitly configured to know that it is an anycast 652 address. 654 For any assigned anycast address, there is a longest prefix P of that 655 address that identifies the topological region in which all 656 interfaces belonging to that anycast address reside. Within the 657 region identified by P, the anycast address must be maintained as a 658 separate entry in the routing system (commonly referred to as a "host 659 route"); outside the region identified by P, the anycast address may 660 be aggregated into the routing entry for prefix P. 662 Note that in the worst case, the prefix P of an anycast set may be 663 the null prefix, i.e., the members of the set may have no topological 664 locality. In that case, the anycast address must be maintained as a 665 separate routing entry throughout the entire Internet, which presents 666 a severe scaling limit on how many such "global" anycast sets may be 667 supported. Therefore, it is expected that support for global anycast 668 sets may be unavailable or very restricted. 670 One expected use of anycast addresses is to identify the set of 671 routers belonging to an organization providing Internet service. 672 Such addresses could be used as intermediate addresses in an IPv6 673 Routing header, to cause a packet to be delivered via a particular 674 service provider or sequence of service providers. 676 Some other possible uses are to identify the set of routers attached 677 to a particular subnet, or the set of routers providing entry into a 678 particular routing domain. 680 2.5.1. Required Anycast Address 682 The Subnet-Router anycast address is predefined. Its format is as 683 follows: 685 | n bits | 128-n bits | 686 +------------------------------------------------+----------------+ 687 | subnet prefix | 00000000000000 | 688 +------------------------------------------------+----------------+ 690 The "subnet prefix" in an anycast address is the prefix that 691 identifies a specific link. This anycast address is syntactically 692 the same as a unicast address for an interface on the link with the 693 interface identifier set to zero. 695 Packets sent to the Subnet-Router anycast address will be delivered 696 to one router on the subnet. All routers are required to support the 697 Subnet-Router anycast addresses for the subnets to which they have 698 interfaces. 700 The Subnet-Router anycast address is intended to be used for 701 applications where a node needs to communicate with any one of the 702 set of routers. 704 2.6. Multicast Addresses 706 An IPv6 multicast address is an identifier for a group of interfaces 707 (typically on different nodes). An interface may belong to any 708 number of multicast groups. Multicast addresses have the following 709 format: 711 | 8 | 4 | 4 | 112 bits | 712 +------ -+----+----+---------------------------------------------+ 713 |11111111|ff1 |scop| group ID | 714 +--------+----+----+---------------------------------------------+ 716 binary 11111111 at the start of the address identifies the address 717 as being a multicast address. 719 +-+-+-+-+ 720 ff1 is a set of 4 flags: |X|R|P|T| 721 +-+-+-+-+ 723 The high-order flag is reserved, and must be initialized to 0. 725 T = 0 indicates a permanently-assigned ("well-known") multicast 726 address, assigned by the Internet Assigned Numbers Authority 727 (IANA). 729 T = 1 indicates a non-permanently-assigned ("transient" or 730 "dynamically" assigned) multicast address. 732 The P flag's definition and usage can be found in [RFC3306] as 733 updated by [RFC7371]. 735 The R flag's definition and usage can be found in [RFC3956] as 736 updated by [RFC7371]. 738 The X flag's definition and usage can be found in [RFC3956] as 739 updated by [RFC7371]. 741 scop is a 4-bit multicast scope value used to limit the scope of 742 the multicast group. The values are as follows: 744 0 reserved 745 1 Interface-Local scope 746 2 Link-Local scope 747 3 Realm-Local scope 748 4 Admin-Local scope 749 5 Site-Local scope 750 6 (unassigned) 751 7 (unassigned) 752 8 Organization-Local scope 753 9 (unassigned) 754 A (unassigned) 755 B (unassigned) 756 C (unassigned) 757 D (unassigned) 758 E Global scope 759 F reserved 761 Interface-Local scope spans only a single interface on a node 762 and is useful only for loopback transmission of multicast. 763 Packets with interface-local scope received from another node 764 must be discarded. 766 Link-Local multicast scope spans the same topological region as 767 the corresponding unicast scope. 769 Interface-Local, Link-Local, and Realm-Local scope boundaries 770 are automatically derived from physical connectivity or other 771 non-multicast-related configurations. Global scope has no 772 boundary. The boundaries of all other non-reserved scopes of 773 Admin-Local or larger are administratively configured. For 774 reserved scopes, the way of configuring their boundaries will 775 be defined when the semantics of the scope are defined. 777 According to [RFC4007], the zone of a Realm-Local scope must 778 fall within zones of larger scope. Because the zone of a 779 Realm-Local scope is configured automatically while the zones 780 of larger scopes are configured manually, care must be taken in 781 the definition of those larger scopes to ensure that the 782 inclusion constraint is met. 784 Realm-Local scopes created by different network technologies 785 are considered to be independent and will have different zone 786 indices (see Section 6 of [RFC4007]). A router with interfaces 787 on links using different network technologies does not forward 788 traffic between the Realm-Local multicast scopes defined by 789 those technologies. 791 Site-Local scope is intended to span a single site. 793 Organization-Local scope is intended to span multiple sites 794 belonging to a single organization. 796 scopes labeled "(unassigned)" are available for administrators 797 to define additional multicast regions. 799 group ID identifies the multicast group, either permanent or 800 transient, within the given scope. Additional definitions of the 801 multicast group ID field structure are provided in [RFC3306]. 803 The "meaning" of a permanently-assigned multicast address is 804 independent of the scope value. For example, if the "NTP servers 805 group" is assigned a permanent multicast address with a group ID of 806 101 (hex), then 808 ff01:0:0:0:0:0:0:101 means all NTP servers on the same interface 809 (i.e., the same node) as the sender. 811 ff02:0:0:0:0:0:0:101 means all NTP servers on the same link as the 812 sender. 814 ff05:0:0:0:0:0:0:101 means all NTP servers in the same site as the 815 sender. 817 ff0e:0:0:0:0:0:0:101 means all NTP servers in the Internet. 819 Non-permanently-assigned multicast addresses are meaningful only 820 within a given scope. For example, a group identified by the non- 821 permanent, site-local multicast address ff15:0:0:0:0:0:0:101 at one 822 site bears no relationship to a group using the same address at a 823 different site, nor to a non-permanent group using the same group ID 824 with a different scope, nor to a permanent group with the same group 825 ID. 827 Multicast addresses must not be used as source addresses in IPv6 828 packets or appear in any Routing header. 830 Routers must not forward any multicast packets beyond the scope 831 indicated by the scop field in the destination multicast address. 833 Nodes must not originate a packet to a multicast address whose scop 834 field contains the reserved value 0; if such a packet is received, it 835 must be silently dropped. Nodes should not originate a packet to a 836 multicast address whose scop field contains the reserved value F; if 837 such a packet is sent or received, it must be treated the same as 838 packets destined to a global (scop E) multicast address. 840 2.6.1. Pre-Defined Multicast Addresses 842 The following well-known multicast addresses are pre-defined. The 843 group IDs defined in this section are defined for explicit scope 844 values. 846 Use of these group IDs for any other scope values, with the T flag 847 equal to 0, is not allowed. 849 reserved multicast addresses: ff00:0:0:0:0:0:0:0 850 ff01:0:0:0:0:0:0:0 851 ff02:0:0:0:0:0:0:0 852 ff03:0:0:0:0:0:0:0 853 ff04:0:0:0:0:0:0:0 854 ff05:0:0:0:0:0:0:0 855 ff06:0:0:0:0:0:0:0 856 ff07:0:0:0:0:0:0:0 857 ff08:0:0:0:0:0:0:0 858 ff09:0:0:0:0:0:0:0 859 ff0a:0:0:0:0:0:0:0 860 ff0b:0:0:0:0:0:0:0 861 ff0c:0:0:0:0:0:0:0 862 ff0d:0:0:0:0:0:0:0 863 ff0e:0:0:0:0:0:0:0 864 ff0f:0:0:0:0:0:0:0 866 The above multicast addresses are reserved and shall never be 867 assigned to any multicast group. 869 all nodes addresses: ff01:0:0:0:0:0:0:1 870 ff02:0:0:0:0:0:0:1 872 The above multicast addresses identify the group of all IPv6 nodes, 873 within scope 1 (interface-local) or 2 (link-local). 875 all routers addresses: ff01:0:0:0:0:0:0:2 876 ff02:0:0:0:0:0:0:2 877 ff05:0:0:0:0:0:0:2 879 The above multicast addresses identify the group of all IPv6 routers, 880 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 882 Solicited-Node Address: ff02:0:0:0:0:1:ffxx:xxxx 884 Solicited-Node multicast address are computed as a function of a 885 node's unicast and anycast addresses. A Solicited-Node multicast 886 address is formed by taking the low-order 24 bits of an address 887 (unicast or anycast) and appending those bits to the prefix 888 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 889 range 890 ff02:0:0:0:0:1:ff00:0000 892 to 894 ff02:0:0:0:0:1:ffff:ffff 896 For example, the Solicited-Node multicast address corresponding to 897 the IPv6 address 4037::01:800:200e:8c6c is ff02::1:ff0e:8c6c. IPv6 898 addresses that differ only in the high-order bits (e.g., due to 899 multiple high-order prefixes associated with different aggregations) 900 will map to the same Solicited-Node address, thereby reducing the 901 number of multicast addresses a node must join. 903 A node is required to compute and join (on the appropriate interface) 904 the associated Solicited-Node multicast addresses for all unicast and 905 anycast addresses that have been configured for the node's interfaces 906 (manually or automatically). 908 2.7. A Node's Required Addresses 910 A host is required to recognize the following addresses as 911 identifying itself: 913 o Its required Link-Local address for each interface. 915 o Any additional Unicast and Anycast addresses that have been 916 configured for the node's interfaces (manually or 917 automatically). 919 o The loopback address. 921 o The All-Nodes multicast addresses defined in Section 2.7.1. 923 o The Solicited-Node multicast address for each of its unicast 924 and anycast addresses. 926 o Multicast addresses of all other groups to which the node 927 belongs. 929 A router is required to recognize all addresses that a host is 930 required to recognize, plus the following addresses as identifying 931 itself: 933 o The Subnet-Router Anycast addresses for all interfaces for 934 which it is configured to act as a router. 936 o All other Anycast addresses with which the router has been 937 configured. 939 o The All-Routers multicast addresses defined in Section 2.7.1. 941 3. IANA Considerations 943 The "IPv4-Compatible IPv6 address" is deprecated by this document. 944 The IANA should continue to list the address block containing these 945 addresses at http://www.iana.org/assignments/ipv6-address-space as 946 "Reserved by IETF" and not reassign it for any other purpose. For 947 example: 949 0000::/8 Reserved by IETF [RFC3513] [1] 951 The IANA has added the following note and link to this address block. 953 [5] 0000::/96 was previously defined as the "IPv4-Compatible IPv6 954 address" prefix. This definition has been deprecated by 955 [RFC4291]. 957 The IANA has updated the references for the IPv6 Address Architecture 958 in the IANA registries accordingly. 960 4. Security Considerations 962 IPv6 addressing documents do not have any direct impact on Internet 963 infrastructure security. Authentication of IPv6 packets is defined 964 in [RFC4302]. 966 5. Acknowledgments 968 The authors would like to acknowledge the contributions of Paul 969 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 970 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 971 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 972 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 973 Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, 974 Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali. 976 The authors would also like to acknowledge the authors of the 977 updating RFCs that were incorporated in this version of the document 978 to move IPv6 to Internet Standard. This includes Marcelo Bagnulo, 979 Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms, 980 Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima, 981 Xing Li, and Stig Venaas. 983 6. References 985 6.1. Normative References 987 [I-D.hinden-6man-rfc2460bis] 988 Deering, S. and B. Hinden, "Internet Protocol, Version 6 989 (IPv6) Specification", draft-hinden-6man-rfc2460bis-07 990 (work in progress), September 2015. 992 6.2. Informative References 994 [EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 995 Registration Authority"", March 1997, 996 . 999 [IANA-AD] "Internet Protocol Version 6 Address Space", 1000 . 1003 [IANA-SP] "IANA IPv6 Special-Purpose Address Registry", 1004 . 1007 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1008 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1009 . 1011 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 1012 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 1013 . 1015 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1016 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1017 August 2002, . 1019 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1020 (IPv6) Addressing Architecture", RFC 3513, DOI 10.17487/ 1021 RFC3513, April 2003, 1022 . 1024 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1025 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 1026 August 2003, . 1028 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1029 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 1030 2004, . 1032 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1033 Point (RP) Address in an IPv6 Multicast Address", RFC 1034 3956, DOI 10.17487/RFC3956, November 2004, 1035 . 1037 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1038 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 1039 10.17487/RFC4007, March 2005, 1040 . 1042 [RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and 1043 E. Castro, "Application Aspects of IPv6 Transition", RFC 1044 4038, DOI 10.17487/RFC4038, March 2005, 1045 . 1047 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1048 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1049 2006, . 1051 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1052 10.17487/RFC4302, December 2005, 1053 . 1055 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1056 (CIDR): The Internet Address Assignment and Aggregation 1057 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1058 2006, . 1060 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1061 Extensions for Stateless Address Autoconfiguration in 1062 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1063 . 1065 [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 1066 Multicast Addressing Architecture", RFC 7371, DOI 1067 10.17487/RFC7371, September 2014, 1068 . 1070 Appendix A. Creating Modified EUI-64 Format Interface Identifiers 1072 Depending on the characteristics of a specific link or node, there 1073 are a number of approaches for creating Modified EUI-64 format 1074 interface identifiers. This appendix describes some of these 1075 approaches. 1077 Links or Nodes with IEEE EUI-64 Identifiers 1079 The only change needed to transform an IEEE EUI-64 identifier to an 1080 interface identifier is to invert the "u" (universal/local) bit. An 1081 example is a globally unique IEEE EUI-64 identifier of the form: 1083 |0 1|1 3|3 4|4 6| 1084 |0 5|6 1|2 7|8 3| 1085 +----------------+----------------+----------------+----------------+ 1086 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 1087 +----------------+----------------+----------------+----------------+ 1089 where "c" is the bits of the assigned company_id, "0" is the value of 1090 the universal/local bit to indicate universal scope, "g" is 1091 individual/group bit, and "m" is the bits of the manufacturer- 1092 selected extension identifier. The IPv6 interface identifier would 1093 be of the form: 1095 |0 1|1 3|3 4|4 6| 1096 |0 5|6 1|2 7|8 3| 1097 +----------------+----------------+----------------+----------------+ 1098 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 1099 +----------------+----------------+----------------+----------------+ 1101 The only change is inverting the value of the universal/local bit. 1103 Links or Nodes with IEEE 802 48-bit MACs 1105 [EUI64] defines a method to create an IEEE EUI-64 identifier from an 1106 IEEE 48-bit MAC identifier. This is to insert two octets, with 1107 hexadecimal values of 0xFF and 0xFE (see the Note at the end of 1108 appendix), in the middle of the 48-bit MAC (between the company_id 1109 and vendor-supplied id). An example is the 48-bit IEEE MAC with 1110 Global scope: 1112 |0 1|1 3|3 4| 1113 |0 5|6 1|2 7| 1114 +----------------+----------------+----------------+ 1115 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 1116 +----------------+----------------+----------------+ 1118 where "c" is the bits of the assigned company_id, "0" is the value of 1119 the universal/local bit to indicate Global scope, "g" is individual/ 1120 group bit, and "m" is the bits of the manufacturer- selected 1121 extension identifier. The interface identifier would be of the form: 1123 |0 1|1 3|3 4|4 6| 1124 |0 5|6 1|2 7|8 3| 1125 +----------------+----------------+----------------+----------------+ 1126 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 1127 +----------------+----------------+----------------+----------------+ 1129 When IEEE 802 48-bit MAC addresses are available (on an interface or 1130 a node), an implementation may use them to create interface 1131 identifiers due to their availability and uniqueness properties. 1133 Links with Other Kinds of Identifiers 1135 There are a number of types of links that have link-layer interface 1136 identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples 1137 include LocalTalk and Arcnet. The method to create a Modified EUI-64 1138 format identifier is to take the link identifier (e.g., the LocalTalk 1139 8-bit node identifier) and zero fill it to the left. For example, a 1140 LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in 1141 the following interface identifier: 1143 |0 1|1 3|3 4|4 6| 1144 |0 5|6 1|2 7|8 3| 1145 +----------------+----------------+----------------+----------------+ 1146 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 1147 +----------------+----------------+----------------+----------------+ 1149 Note that this results in the universal/local bit set to "0" to 1150 indicate local scope. 1152 Links without Identifiers 1154 There are a number of links that do not have any type of built-in 1155 identifier. The most common of these are serial links and configured 1156 tunnels. Interface identifiers that are unique within a subnet 1157 prefix must be chosen. 1159 When no built-in identifier is available on a link, the preferred 1160 approach is to use a universal interface identifier from another 1161 interface or one that is assigned to the node itself. When using 1162 this approach, no other interface connecting the same node to the 1163 same subnet prefix may use the same identifier. 1165 If there is no universal interface identifier available for use on 1166 the link, the implementation needs to create a local-scope interface 1167 identifier. The only requirement is that it be unique within a 1168 subnet prefix. There are many possible approaches to select a 1169 subnet-prefix-unique interface identifier. These include the 1170 following: 1172 Manual Configuration 1173 Node Serial Number 1174 Other Node-Specific Token 1176 The subnet-prefix-unique interface identifier should be generated in 1177 a manner such that it does not change after a reboot of a node or if 1178 interfaces are added or deleted from the node. 1180 The selection of the appropriate algorithm is link and implementation 1181 dependent. The details on forming interface identifiers are defined 1182 in the appropriate "IPv6 over " specification. It is strongly 1183 recommended that a collision detection algorithm be implemented as 1184 part of any automatic algorithm. 1186 Note: [EUI64] actually defines 0xFF and 0xFF as the bits to be 1187 inserted to create an IEEE EUI-64 identifier from an IEEE MAC- 1188 48 identifier. The 0xFF and 0xFE values are used when 1189 starting with an IEEE EUI-48 identifier. The incorrect value 1190 was used in earlier versions of the specification due to a 1191 misunderstanding about the differences between IEEE MAC-48 and 1192 EUI-48 identifiers. 1194 This document purposely continues the use of 0xFF and 0xFE 1195 because it meets the requirements for IPv6 interface 1196 identifiers (i.e., that they must be unique on the link), IEEE 1197 EUI-48 and MAC-48 identifiers are syntactically equivalent, 1198 and that it doesn't cause any problems in practice. 1200 Appendix B. CHANGES SINCE RFC 4291 1202 This document has the following changes from RFC4291, "IP Version 6 1203 Addressing Architecture". Numbers identify the Internet-Draft 1204 version that the change was made.: 1206 06) Incorporate the updates made by RFC7371. The changes were to 1207 the flag bits and their definitions in Section 2.6. 1209 05) Incorporate the updates made by RFC7346. The change was to 1210 add Realm-Local scope to the multicast scope table in 1211 Section 2.6, and add the updating text to the same section. 1213 04) Incorporate the updates made by RFC6052. The change was to 1214 add a text in Section 2.3 that points to the IANA registries 1215 that records the prefix defined in RFC6052 and a number of 1216 other special use prefixes. 1218 03) Incorporate the updates made by RFC7136 to deprecate the U 1219 and G bits in Modified EUI-64 format Internet IDs. 1221 03) Add note to the reference section acknowledging the authors 1222 of the updating documents. 1224 03) Editorial changes. 1226 02) Updates to resolve the open Errata on RFC4291. These are: 1228 Errata ID: 3480: Corrects the definition of Interface- 1229 Local multicast scope include that packets with interface- 1230 local scope received from another node must be discarded 1232 Errata ID: 1627: Remove extraneous "of" in Section 2.7. 1234 Errata ID: 2702: This errata is marked rejected. No 1235 change is required. 1237 Errata ID: 2735: This errata is marked rejected. No 1238 change is required. 1240 Errata ID: 4406: This errata is marked rejected. No 1241 change is required. 1243 Errata ID: 2406: This errata is marked rejected. No 1244 change is required. 1246 Errata ID: 863: This errata is marked rejected. No change 1247 is required. 1249 Errata ID: 864: This errata is marked rejected. No change 1250 is required. 1252 Errata ID: 866: This errata is marked rejected. No change 1253 is required. 1255 02) Update references to current versions. 1257 02) Editorial changes. 1259 01) Incorporate the updates made by RFC5952 regarding the text 1260 format when outputting IPv6 addresses. A new section was 1261 added for this and addresses shown in this document were 1262 changed to lower case. 1264 01) Revise this Section to document to show the the changes from 1265 RFC4291. 1267 01) Editorial changes. 1269 00) Establish a baseline from RFC4291. The only intended changes 1270 are formatting (XML is slightly different from .nroff), 1271 differences between an RFC and Internet Draft, fixing a few 1272 ID Nits, and updates to the authors information. There 1273 should not be any content changes to the specification. 1275 Authors' Addresses 1277 Robert M. Hinden 1278 Check Point Software 1279 959 Skyway Road 1280 San Carlos, CA 94070 1281 USA 1283 Email: bob.hinden@gmail.com 1285 Stephen E. Deering 1286 Retired 1287 Vancouver, British Columbia 1288 Canada