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