Copyright 2012 Scott Conrad VanderWoude, and newer. All rights reserved.

Some of this may be from information with an earlier Copyright by Scott Conrad VanderWoude. For further details on intellectual property related to this resource, please see details near the Start page.)

IPv6 addresses

A more official list may be found at RFC 5156: Special-Use IPv6 Addresses. (RFC 4890: Recommendations for Filtering ICMPv6 in Firewalls may also have some information that is similar in nature.)

Some details of large networks have been shared by IANA's list of IPv6 address space usage. More details, such as seeing the RIR that has received the allocation for assigned specific address ranges, is documented by the IANA's list of “IPv6 Global Unicast Address Assignments”.

[#colcols3] - ::/3 (:: through end of 1fff::/16)
Current firewall recommendation: mostly blocked and logged. (This may change, such as if 1::/16 stops being a bogon.)

There are some addresses that may have special uses. For example, see the section on ::FFFF:0:0/96. For various reasons, some addresses within this range are blocked. However, a simple observation shows that currently (at the time of this writing) all IPv6 unicast global addresses are sent out via the 2000::/3 range. There are other addresses that may need to be sent out to a gateway device, such as some addresses in the ff00::/4 range, but in all likelihood nothing in the ::/3 range needs to be sent out at this time. (The address range currently consists only of invalid addresses and bogons. Bogons are address ranges which aren't currently routed on the public Internet.) Note that this rule may not be valid once some of the addresses, which are currently bogons, become assigned for actual use. In the meantime, though, blocking all such traffic and logging/alerting on it might help to identify and/or localize some problems before the problem traffic travels to devices further in or out of the network. Therefore, blocking these addresses (at least temporarily for the current time) is recommended.

Address Range
These are all addresses that come before (and not including) 0200::/3. (In order for the first nibble, represented by the first two digits of hexadecimal notation, to be a two or higher, there needs to be a bit set to one within the first three bits of the address. This range is for addresses where all of the first three bits are zero.)

All addresses in this range, except for two of them, are addresses in the “global unicast” range of addresses, as noted by RFC 4291 section 2.4 (and the earlier RFC 3513 section 2.4). However, these addresses are uniquely different from most global unicast address spaces because addresses in this range, unlike the other ranges, do not require an embedded interface ID. This difference is spelled out in the following sentences quoted from RFC documents. RFC 4291 section 2.5.4 (and the older RFC 3513 section 2.5.4) says, “All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.”

(Some further information about Global Unicast address ranges/spaces may be found in the section about an address range with most of the Global Unicast address spaces.)

[#colcolzz] - ::/128
This is the “unspecified” address, also sometimes known as the “invalid” address. Such incoming traffic shouldn't be trusted. Reference: RFC 4291 section 2.5.2 - The Unspecified Address. (The IPv4 address that would be nearest to an equivilent to this address would be Technically, this address would also fit the description of the Subnet-Router anycast address for any subnet that ends with ::. However, expecting this address to serve as an anycast address would seem inconsistent with this address's primary and commonly-supported role, which is being an “unspecified” address which is “invalid” for being used like a normal address.
Firewall recommendation
This should be blocked (by all routers, including firewalls or other routing devices and software).
[#colcol1] - ::1/128
The “loopback” address, as specified by RFC 4291 section 2.5.3. (The equivilent IPv4 address would be
Firewall recommendations

Block this on all network interfaces that are not loopback devices. (Unix systems do typically have a network interface which is set to be a loopback device, often named lo0. Such an address may legitimately have such traffic, so do not block traffic for this address on that sort of interface. For all other types of network interfaces (such as most standard network interfaces), block the untrustworthy traffic.

Traffic coming from ::1/128 should not be arriving via a standard network interface. Traffic going to ::1/128 should not be getting sent out via a standard network interface. Software and rules commonly end up treating ::1/128 as a trustworthy address, so if traffic involving this address is flowing in a way that seems untrustworthy, such as trying to travel over/through a network interface which is not a trusted loopback interface, then this traffic should be blocked as soon as possible. Hopefully blocking such traffic immediately will be something that happens before the traffic starts to be trusted.

[#ccs96] - Addresses starting at ::2 and within the ::/96 range (::2 - ::ffff:ffff)
Address range
This is the entire ::/96 address range except for two addresses, ::/128 and ::1/128, both of which are discussed in previous text.
Firewall recommendations
Block, at least for traffic involving the public Internet. RFC 5156 section 2.3 says that such “addresses are deprecated and should not appear on the public Internet.”

Previously, any address in this range, other than ::1 (which has a special meaning), would be called an “IPv4-Compatible IPv6 address” as noted by RFC 4291 section However, this RFC 4291 section calls such a use “deprecated” and says “New or updated implementations are not required to support this address type.” (RFC 4291 (“IPv6 Addressing Architecture”) section 4: IANA Considerations notes, about this address block, that IANA should “not reassign it for any other purpose.”)

Even though this address range may not be supported by new/updated implementations, there may be other options for this same sort of functionality. See information about using ::FFFF:0:0/96 (IPv4-Mapped Addresses) and/or the “6to4” addresses at 2002::/16. Also, the IPv6 64:ff9b::/96 prefix and the IPv4 192.88.99/24 prefix may be related to “6to4”.

::1:0:0 - the end of 1FF::/8

This covers addresses from 0000:0000:0000:0000:0000:0001:0000:0000 to the end of 01FF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF.

[#ccozzs80]: ::1:0:0 - ::FFFE:FFFF:FFFF)

This section describes ::1:0:0 and higher addresses within ::/80, but which are still under ::FFFF:0:0/96. Admittedly, that pattern of addresses is more convoluted to type/read than just seeing the range.

Many of these addresses are less noteworthy addresses. However, instead of skipping these addresses, they are mentioned in this documentation simply to point out there is an address range here, after ::ffff:ffff and before ::ffff:0:0. Basically, these addresses can be treated similar to other un-special addresses in the ::/3 range.

[#ccffff96] - ::FFFF:0:0/96 (::FFFF:0:0 through ::FFFF:FFFF:FFFF): IPv4-Mapped Addresses

The last 32 bits of the IPv6 (represented by the final two fields of the hexadecimal address, after the “::FFFF:”), is large enough in size to mimic an IPv4 address (since IPv4 addresses are 32 bits).

Referenced by RFC 5156 section 2.2 which references RFC 4291. Specifically, RFC 4291 “IPv6 Addressing Architecture”: Section “IPv4-Mapped IPv6 Address covers these types of addresses, and references RFC 4038: Application Aspects of IPv6 Transition. This address range is probably the address range which will, more than any other address range, use embedded IPv4 addresses as part of the IPv6 addresses as specified by RFC 4291 section 2.2: Text Representation of IPv6 addresses subsection 3.

The Addresses starting at ::2 and within the ::/96 range were initially designed to have similar functionality. (They had a similar name, “IPv4-Compatible addresses”, while these addresses use the name “IPv4-Mapped Addresses”.) Some other addresses which may be a bit similar in nature could be the 6to4 addresses at 2002::/16.

Related to the topic of using these types of addresses: RFC 4942: IPv4 and “IPv6 Transition/Coexistence Security Considerations”.

Firewall recommendations
May vary. (Perhaps route traffic, converting the traffic where necessary, to and from IPv4 addresses.) When creating an original IPv6 setup, if IPv6/IPv4 translation is not yet supported, it may make sense to just block the traffic. Attempting to forward such traffic to another organization is probably not a good idea if it is unknown how that organization is likely to handle such traffic.
Similar addresses

6to4 addresses may include the IPv6 2002::/16 prefix, the IPv6 64:ff9b::/96 prefix and the IPv4 192.88.99/24 prefix.

Addresses starting at ::2 and within the ::/96 range were once considered to be another option, although newer standards prohibit such usage for that address block.

Some more unused addresses (::1:0:0:0 - the end of 63::/16)

Some other addresses that do not currently have any special use documented on this site include:

  • ::1:0:0:0 and higher values of ::/19. (This ends up meaning all addresses from ::1:0:0:0 to the end of 001F:FFFF::/64.) (However, this description is not meant to be applied to addresses lower than ::1:0:0:0, even though those addresses are part of ::/19. That is because many of the addresses lower than ::1:0:0:0 are reserved for some special purposes).
  • 20::/10 (20::/16 through the end of 3F::/16)
  • 40::/11 (40::/16 through the end of 5F::/16)
  • 60::/14 (60::/16 through the end of 63::/16)

Note: No strong statement is being made here that the addresses have absolutely no reserved uses. The statement made is simply that this documentation does not have further details about how these addresses may be reserved. That might be because of the addresses being unreserved/bogons, or possibly because this documentation is incomplete and/or (to a degree, hopefully just a small degree) out of date. Before planning to use any such addresses under the belief that these addresses might not be actively used, do perform some online checks for any (updated) details on how these addresses might have started to be used.

64::/16 - 6F::/16 (0064:0000::/32 - 006F:FFFF::/32)

This segment may be mostly unused, but is not entirely unreserved.

[#64ff9bv4]: 64:ff9b::/96 (64:ff9b:0:0:0:0:0:0 through 64:ff9b:0:0:0:0:ffff:ffff) : Well-known Prefix for IPv6 Addressing of IPv4/v6 Translators
Firewall recommendations

In general, but not in all cases, pass the traffic. More specifically, anticipate that such traffic might be processed with a technique like NAT64. The addresses in this range represent embedded IPv4 addresses. Therefore, traffic should not get passed if the IPv4 would be traffic that doesn't get passed. (For details of how IPv4 addresses may be used, see Information on the usage of IPv4 addresses.)


RFC 6052 section 2.1: The “Well-Known Prefix” for IPv6 Addressing of IPv4/v6 Translators documents this prefix. RFC 6052 section 3: “Deployment Guidelines” starts out with RFC 6052 section 3.1: “Restrictions on the Use of the Well-Known Prefix”. (In order to be compliant with standard behavior, be sure to follow such restrictions.)

Note that 64:ff9b::1:0:0 through the end of 64:ff9b:: are not part of 64:ff9b::/96, and so those addresses are not reserved by RFC 6052. (RFC 6052 is not reserving all of 64:ff9b::/64, nor any larger subnet; only 64:ff9b::/96.)

Remember that each octet of an IPv4 address represents 8 bits, which is equivilent to two nibbles of an IPv6 address. Each nibble is represented by one hexadecimal digit of the IPv6 address.

Wikipedia: article for “IPv6 address”, “Transition from IPv4” section has identified this address range as being related to 6to4. Other address ranges (also identified by the same Wikipedia article) related to 6to4 include the IPv6 2002::/16 prefix and the IPv4 192.88.99/24 prefix.


RFC 6052 section 3.1 says that these must only be used for global IPv4 addresses.

007F::/16, and 0080::/17 (0080::/16 through the end of 00FF::/16), and 0100::/16 (0100:0::/32 through the end of 01FF:FFFF::/32)
There may not be much to currently report about these ranges. What this means is that, at the time of this writing, the ranges may have been unused/unreserved.
[#0200s7] - 200::/7 (0200::/8 through 03FF::/8)

Current use: nothing special. (Recommendation: Treat like the vast majority of the rest of the address range. So, treat as a bogon. Block for now.)

In the past, RFC 1888 section 2 (top of page 4): Summary of defined mechanisms had defined usage for IPv6 addresses where the first byte of the address was a 2 or a 3 (so this affected all IPv6 addresses from the beginning of 200/8 to the end of 3FF/8). However, this reservation of the address range was revoked by RFC 4048, titled “RFC 1888 Is Obsolete”. That RFC 4048 was published to hopefully prevent anyone from starting to rely on the Obsoleted RFC 1888. The RFC 4048 document does state, “As far as is known to the IETF, these address mappings have never been seriously used and are not supported by IPv6 implementations.”

For any possible related ongoing interest, RFC 4548: Internet Code Point (ICP) Assignments for Network Service Access Point (NSAP) Addresses provides details about using NSAP. IANA's IPv6 Address Space document cites RFC 4048 and 4548.

Notes of other RFC references: This NSAP-related usage of addresses was mentioned by RFC 2373 section 2.5.5: (Obsoleted documentation about) NSAP Addresses. This RFC, of course, is numbered between 1888 and 4048. (RFC 3513 page 24: Start of Appendix B notes why there isn't a similar section in RFC 3513: the information was combined with RFC 3513 section 2.5.4.) However, RFC 4291 page 23, released after RFC 4048, noted that NSAP information was removed.

[#0400s7] - 400::/7 (0400::/8 through 05FF::/8)
Firewall recommendations
Do nothing special with this block: simply treat it as part of the larger block that it is in. (The details in this documentation are basically regarding historical, rather than current, standards.)
Further details
If the first seven bits are 0000010 (so the first eight bits are 00000100 or 00000101, so the first two nibbles shown in the first two hexadecimal digits are 04 or 05), RFC 2373 section 2.5.6 had a reference to using such addresses to map IPX addresses to IPv6 addresses. There was only a single sentence which did not provide any technical details: it said “The draft definition, motivation, and usage are under study.” The second non-header line of RFC 3513 page 25 notes the removal of “the address block reserved for IPX addresses.”
[#mstglbuc]: Large range of most of the Global Unicast address spaces: 2000::/3 - end of FE7F::/9
Global Unicast Address Ranges

The largest range of consecutive Global Unicast IPv6 Addresses, a range which consists of most IPv6 Addresses, goes from 2000::/3 (which begins with binary 0010 0000 0000 0000) and going up through the end of FE7F::/9 (a.k.a. the end of FE7F::/16 which starts with binary 1111 1110 0111 1111).

This is one of the blocks of Global Unicast addresses noted by RFC 3513 section 2.4: Address Type Identification. This large block of global unicast addresses comes directly after the next largest Global Unicast block, which is is ::/3 except for ::/128 and ::1/128), so all addresses from ::2/128 up to, but not including, the beginning of 1FFF::/3.

These global unicast addresses (beginning with the early addresses that start with binary 0010, although other, later prefixes are in this wide range as well) do come directly after other global unicast spaces (which start with binary 000). Although the address spaces are consecutive, they do have differences in terms of required patterns/uses of bits and also how the address spaces are handed out to RIR's. (Those are the reasons why this documentation is currently referring to these address spaces as being in two groups instead of just one even larger group.)

After those two large groups of Global Unicast Addresses, the definitions from the newer RFC 4291: IPv6 Adressing Architecture: Section 2.4: Address Type Identification do specify (rather indirectly, but quite clear when anlayzed precisely) that FEC0::/10 is yet another range of global unicast address space.

Standard uses of the global unicast address spaces
Non-global-unicast addresses using global unicast address spaces

Not all addresses in the global unicast address space(s) are actually considered global unicast addresses. Yes, that's right. Although the address spaces/ranges are named after their most common use, types of addresses other than a “global unicast address” do also come from the same address spaces. Therefore, an address is not necessarily “global unicast” just because it came from a “global unicast address” range.

RFC 1884 page 12 (section 2.5's second paragraph) explains, “Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses.” RFC 4291 section 2.4 agrees: “Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses.” For more details about Anycast addresses, see RFC 4291 section 2.6: Anycast Addresses.

However, anycast addresses are the only exception that existed at the time of the publication of RFC 4291. Section 2.4 did mention the possibility that additional exceptions may exist from future standard specifications. However, at the time of RFC 4291's initial publication, anycast addresses were the only already existing exception that were permitted by section 2.4 of that RFC.

Non-global nature of some global unicast addresses
Some addresses, including large blocks at FE80::/9 and fd00::/8, are not meant to be routed globally (at least not directly and without translation). Still, the structure which is most commonly expected in such addresses is that they have the format of a Global Unicast address. They are considered, by RFC 4291 section 2.4, to be Global Unicast addresses, despite how much traffic on the public Internet can or cannot be easily routed directly to such addresses.
Required Interface identifier

RFC 3513: IPv6 addressing: Section 2.5.4: Global Unicast Addresses states, “All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1.” (RFC 3513 section 2.5.1: Interface Identifiers has more details.)

(The same RFC 3513 section 2.5.4 says “Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.” Therefore, this quoted text does not apply to the global unicast addresses which are from ::2/128 through the end of ::/3.) The requirement about the 64-bit identifier does apply to the largest global unicast range, 2000::/3 through the end of FE7F::/16 (and the same requirement would also apply to FEC0::/10).

It is a common understanding or assumption that the interface ID is based off of a NIC's 48-bit MAC address. In actuality, the text from the first paragraph of “RFC 3513: IPv6 Addressing Architecture: section 2.5.1: Interface Identifiers” states, “In some cases an interface's identifier will be derived directly from that interface's link-layer address.” That text implies there may be other cases. Setting up an IPv6 Test Lab - Part 1 (June 22, 2007) states that Microsoft Windows “Vista is unusual because the link-local address doesn't relate to the hardware MAC address, but instead uses a random identifier.”

Another assumption may be that the 64-bit Interface ID is at the end of the address. This does not seem to be strictly specified by RFC 3513 section 2.5.1 directly. However, having the 64-bit Interface ID at the end of the address is likely common practice, and it is referenced by other documentation. For example, RFC 3513 section 2.5.1 does reference the 7th bit of the Interface ID as being the “universal/local bit”, and RFC 5375 Appendix B section B.2.4 (on page 32 of the RFC document) refers to the “universal/local” bit as being the 71st bit of the IPv6 global unicast address. Another reference is when RFC 3627: /127 IPv6 prefixes: Section 5 refers to this “universal/local” bit as the 70th bit of the IPv6 global unicast address. Granted, calling that bit the “70th” bit is quite confusing because it really references bit number 70 using a zero-based count, so it is really referencing the 71st bit. Regardless of that unclarity, it's clear that moving the interface ID's starting bit would be expected to similarly offset the “universal/local” bit (and similarly it would also offset the following bit, which is named the “individual/group” bit). Therefore, it does seem to be a safe assumption that the interface ID is at the end of the address. Variations might not violate RFC 3513, but they could be contrary to the text of RFCs 5375 and 3627.

As for how the interface ID is calculated, RFC 3513 provides details. RFC 3513 Appendix A refers to using the first 24 bits of a MAC address, then using the bytes 0xFFFE, and then using the last 24 bits of a MAC address.

The first 64 bits of an IPv6 address may have some other specific patterns that mean various things, as described in the following details.

[#2000ccs3] - 2000::/3 (all of 2000::/4 and 3000::/4) (starts with binary: 0010 or 0011) (Current Unicast Range)

The IANA's IPv6 address space web location (which is linked to from IANA's Global Unicast Address Assignments: XML file, and which may or does redirect to IANA's IPv6 address space: XML document) documents 2000::/3 as being “Global Unicast”. The footnote related to the “2000::/3”, “Global Unicast” section of IANA's IPv6 address space document), (which may be Footnote 3 of IANA's IPv6 address space document) states (at the time of this writing), “IANA unicast address assignments are currently limited to the IPv6 unicast address range of 2000::/3.”

RFC 3587, which was released in August 2003, says “Even though currently only 2001::/3 is being deployed by the IANA, implementations should not make any assumptions about 2001::/3 being special.” An earlier RFC, RFC 2374, singled out the 2000::/3 range. (The RFC doesn't mention 2000::/3 in notation involving hexadecimal, but rather identified those addresses as onces which had a “Format Prefix” with a value of 001.) However, some details of that document were “formally made historic by” RFC 3587 section 2. Examples of things made historic, other than removing the limit of 2001::/3, include throwing out some sub-divisions of an address within the 2001::/3 range: specifically the “Top-Level Aggregation Identifier” (“TLA ID” / “TLA”) and “Next-Level Aggregation Identifier” (“NLA ID” / “NLA”) were explicitly axed by RFC 3587 section 2.

The footnote related to the “2000::/3”, “Global Unicast” section of IANA's IPv6 address space document), (which may be Footnote 3 of IANA's IPv6 address space document) refers to IANA's IPv6 Global Unicast Address Assignments (which may or does redirect to IANA's IPv6 Global Unicast Address Assignments: XML documentation), which provides additional details about which RIR has received the assignment of each documented address range. The documented address ranges on that page are IPv6 /23 address blocks, or larger address blocks.

Firewall Recommendation
Varies. (Some of this does have a recommendation to be blocked, while some of this address range is not an address with a general recommendation to be blocked.) (See sub-sections for further details.)
[#2001cs23] - 2001::/23 (2001:0000:: through the end of 2001:01ff::):

Details of the intent of addresses in this range are provided by RFC 4773: Administration of the IANA Special Purpose IPv6 Address Block. IANA's IPv6 Global Unicast Address Assignments (which may or does redirect to IANA's IPv6 Global Unicast Address Assignments: XML documentation) refers to IANA's documentation of the IANA IPv6 Special Purpose Address Registry. The document does state, “Address prefixes listed in the Special Purpose Address Registry are not guaranteed routability in any particular local or global context.” Additionally, that documentation provides details of current assignments.

[#2001cs32] - 2001::/32 (2001:0:0:: through the end of 2001:0000:ffff::) : Teredo

Teredo addresses. (RFC 5156 (Special-Use IPv6 Addresses): section 2.8: section about the Teredo address block refers to RFC 4380: Teredo.

Teredo had been implemented at 3FFE:831F::/32.

Firewall recommendations
No further details are here at this time.
[#2001twoc] - 2001:2::/48 (Goes from the start of 2001:2:0:0::/64 through the end of 2001:2:0:ffff::/64) : BMWG
[#bmwgerad] - Misdocumentation in official documentation
Although RFC 5180 section 8 specifies that “IANA has allocated 2001:0200::/48”, RFC 5180 Errata disagrees and says that “IANA has assigned 2001:0002::/48”. So which is really correct: is the assigned address really supposed to be 2001:2:: or 2001:200::? The answer seems to be made available by reviewing IANA's documentation: IANA's documentation on the IANA IPv6 Special Purpose Address Registry shows that the documented address range is 2001:0002::/48.
Similar addresses
[#2001tenc] - 2001:10::/28 (Goes from the start of 2001:0010::/32 through the end of 2001:001f::/32) : ORCHID
Current Firewall Recommendation (temporarily)
Until the year 2014, the advice to follow is likely to be RFC 5156 section 2.10 which says “Addresses within this block should not appear on the public Internet.” This is because of the “ORCHID” RFC 4843. The year 2014 is mentioned in RFC 4843, and so it wouldn't be surprising if this rule may change then.
Essentially, this address range is reserved to allow programmers to use ORCHID addresses when dealing with APIs, and for it to be safely known that such addresses won't conflict with real IPv6 addresses since real IPv6 addresses shouldn't be used in this range.
[#20012h48] - 2001:200::/48 : Unassigned despite RFC 5180's reference
Although RFC 5180 does reference this address, that is an error. This is noted in the section called “Misdocumentation in official documentation” within the area that discusses 2001:2::/48.
[#20010db8] - 2001:db8::/32 (2001:0db8:0000::/48 to the end of 2001:0db8:ffff::/48) : Documentation Prefix
Firewall Recommendation
RFC 5156 section 2.6 says “Addresses within this block should not appear on the public Internet.”

RFC 3849, RFC 5156 section 2.6.

People using examples for documentation may also be interested in BCP 32: Reserved Top Level DNS Names (e.g. RFC 2606: Reserved Top Level DNS Names).

Some IPv4 addresses have been similarly reserved by IANA for this same sort of purpose: They are The IPv4 address range 192.0.2/24 (“TEST-NET-1”), The IPv4 address range 198.51.100/24 (“TEST-NET-2”), and The IPv4 address range 203.0.113/24 (“TEST-NET-3”).

One case where this address range is not being used as an example: Draft IETF document about locally assigned DNS zones (version 13, section 4.6).

[#2002s16] - 2002::/16 (2002:0000:0000::/48 to the end of 2002:ffff:ffff::/48) : 6to4

The first 16 bits are 0x2002. The next 32 bits represent an IPv4 address, so the IPv6 address 2002:: is like the IPv4 address and the IPv6 address 2002:ffff:ffff:: is representing the IPv4 (which is the IPv4 broadcast address).

RFC 3056: 6to4 describes a mechanism called 6to4. The RFC 3056: 6to4 document says, “The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution.” However, even though the document authors may have hoped that one or more different solutions for IPv4 and IPv6 are provided, the same document, in section 2 of RFC 3056, also says “The IANA has permanently assigned one 13-bit IPv6 Top Level Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH, AGGR] for the 6to4 scheme.Its numeric value is 0x0002, i.e., it is 2002::/16 when expressed as an IPv6 address prefix.” (Having the Format Prefix of 001 followed by a 13-bit TLA of 0x2, a.k.a. a Format Prefix of 001 followed by the 13 bits 0 0000 0000 0002, equates to 2002::/16 in hexadecimal format.)

So, as just discussed, an address starting with 2002::/16 comes out of the addresses reserved for the 6to4 method. Furthermore, not only the address block, but also the individual addresses are called 6to4: Wikipedia's article on 6to4: section called “Address block allocation” says very plainly, “Any IPv6 address that begins with the 2002::/16 prefix is known as a 6to4 address”.

There is an RFC that looks quite related: RFC 3964: Security Considerations for 6to4

After the first 48 bits (which are the initial 16 set to 0x2002, followed by 32 bits representing the IPv4 address), there are 16 bits left in the first half of the address. Wikipedia's article on 6to4: section on “Address block allocation” suggests that the first half of these middle 32 bits may be used “for a 16-bit subnet field” and for the latter half of these middle 32 bits, combined with the 48 bits at the end of the address, to be a total of 64 bits used to identify the host within a subnet. (A 16-bit subnet field would be half of the bits of an IPv4 address, such as the size of all addresses in the 192.168/16 range, or any other IPv4 /16.)

Firewall Recommendation
(No specific recommendation is made at this time. (Review the overview and decide how to handle.))
Misc notes
It might seem desirable to concoct a way to embed an IPv4 address into IPv6 notation, such as 2002: However, this is not supported by the relevant RFC's. The second paragraph of RFC 6052 page 14 states, “According to Section 2.2 of [RFC4291], in the legal textual representations of IPv6 addresses, dotted decimal can only appear at the end.” (The relevant part of RFC 4291 section 2.2 is the subsection number 3.) (That RFC 6052 is about translating IPv4 addresses with IPv6 addresses, and especially section 2.2 (IPv4-Embedded IPv6 Address Format) of RFC 6052 discusses various prefix lengths before the bits that represent an embedded IPv4 address.) Additionally, RFC 5952 section 5 notes using the mixed format only when addresses are used in the last/lower 32-bits of the IPv6 address. So, to summarize, although it may make some logical sense to write out addresses this way, it is explicitly unsupported by official standards documents.
Similar addresses

the IPv6 64:ff9b::/96 prefix and the IPv4 192.88.99/24 prefix may be related.

[#ccffff96] - ::FFFF:0:0/96 may be used similarly. Addresses starting at ::2 and within the ::/96 range were once considered to be another option, although newer standards prohibit such usage for that address block.

[#3ffes16] - 3FFE::/16 (3FFE:0000::/32 to the end of 3FFE:FFFF::/32) : ex-6bone
Firewall recommendations

Filter (drop), unless support is needed for an old subnet for Teredo (although that may also be appropriate to drop).

RFC 3701 page 5 notes, “When the 6bone Testing Address Allocation is reclaimed by the IANA, it is expected that many network operators will filter it on their borders to ensure these prefixes are not misused.”

Current Status

This address range refers to something named 6bone. This should no longer be used, RFC 3701: “6bone (IPv6 Testing Address Allocation) Phaseout”. The URL for IETF description of “IPv6 Backbone (6bone)” identifies this as being a “concluded” working group.

Further information

Before this experimental backbone was concluded, RFC 2471: IPv6 Testing Address Allocation was very clear (in the first paragraph of the “Introduction”) making multiple statements that this was temporary.

Some historical details are given in RFC 3701. For similar historical addresses: 5F00::/8.

Notable Subnet(s)
[#3ffe831f] - 3FFE:831F::/32 (3FFE:831F:0000::/48 to the end of 3FFE:831F:FFFF::/48): ex-Teredo-over-the-old-6bone-addresses

A Windows XP implementation of Teredo used 3FFE:831F::/32 but XP SP3 should use 2001::/32. IANA's IPv6 Global Unicast Address Assignments: Note #9 (or, if the numerical note numbers have changed, whichever note is applicable to the 3000::/4 range) has noted, “3FFE:831F::/32 was used for Teredo in some old but widely distributed networking stacks. This usage is deprecated in favour of 2001::/32, which was allocated for the purpose in [RFC4380]” The fact that these previous addresses for Teredo are no longer recommended isn't any more complicated than the fact that these addresses were part of the larger 3FFE::/16 address range which stopped being a range recommended for active use.

[#lotv6bog] - 4000::/6 through FBFF::/6 : Currently lots of IPv6 bogons
Firewall Recommendation

Treat as bogons. (Some of this information about bogon treatment should be moved to another, more centralized location as anti-abuse strategies are published.) That is, if you reasonably expect to be reviewing bogon lists as they get updated, then start by checking up to date bogon lists and then block the traffic for now, and be sure to stay on top of checking the bogon lists as they get updated. However, if you expect that you may stop regularly checking the bogon lists, or don't even want to start, then you should allow traffic so that legitimate traffic isn't blocked as segments are removed from the bogon lists.

There are people who feel that administrators of network traffic routing, such as people who configure firewalls, have a duty to not use out of date bogon lists, by keeping the bogon lists up to date or by cleaning up any old lists that were used (and choosing to not use the lists at all, if desired). The simple reason is because there certainly have been cases where people obtain legitimately assigned addresses but they are unable to communicate with some portions of the Internet because of outdated rules leading to the traffic being improperly blocked. How unpleasant it would be to find that some brand new Internet service just isn't working because the traffic is being discriminated against by people who were too lazy to stop breaking such traffic as the traffic became ready for proper widespread use.

At the time of this writing, an abbreviated list of bogons in this address range (which is a list that reflects the official, less abbreviated list) is:

4000::/2, 6000::/3, 8000::/2, A000::/3, C000::/3, E000::/4, F000::/5, and F800::/6.

Some bogon information

IANA's IPv6 Address Space assignments documentation ( ) shows this range of addresses, 4000::/6 through FBFF::/6, is “Reserved by IETF”. Specifically, the address ranges documented on IANA's website:

4000::/3, 6000::/3, 8000::/3, A000::/3, C000::/3 (C000::/4 - end of Dfff::/4), E000::/4 (E000::/4 - end of Efff::/4), F000::/5 (F000::/5 - end of F7ff::/5), and F800::/6 (F800::/6 - end of FBff::/6).

The above could be abbreviated a bit: 4000::/2 contains all of 4000::/3 (which contains addresses from 4000::/4 to the end of 5fff::/4) and 6000::/3 (which contains all of 6000::/4 to the end of 7fff::/4). Similarly, 8000::/2 contains all of 8000::/3 (which contains addresses from 8000::/4 to the end of 9fff::/4) and A000::/3 (which contains all of A000::/4 to the end of Bfff::/4).

It wouldn't at all be surprising if many of these addresses are later converted into something like “Global Unicast”. As of this writing, though, the IANA web page simply listed these as reserved, and so they are available for future assignment by IANA.

[#5f00s8]: Info on historical reservations/usage
5F00::/8 (5F00::/16 through the end of 5FFF::/16) was allocated by RFC 1897 (described as an FP of 010 and registry ID of 11111, although the concept of a registry ID was replaced by the time RFC 2373 section 2.5.7 was published, and that was replaced by RFC 3587). The RFC that mentioned this address range, RFC 1897, was marked as obsoleted by RFC 2471 and then both were phased out by RFC 3701. More details about RFC 2471 are discussed in the section about 3FFE::/16 (6bone).
[#fc00s7] - FC00::/7 : FC00::/8 through FDFF::/8) : Half are reserved, other half are locally assigned (private) IPv6 addresses

IANA's IPv6 Address Space assignments documentation ( ) lists this as Unique Local Unicast. The addresses are reserved by RFC 4193: Unique Local IPv6 Unicast Addresses. The abbreviation of “ULA” stands for “Unique Local Address”, and refers to this section of IPv6 addresses. (The phrase “ULA address” is as redundant as “ATM machine” or “PIN number”.)

This address range is broken in half. The intent of each separate half is as follows:

[#fc00s8] - fc00::/8 (fc00::/16 to the end of fcff::/16) : Reserved IPv6 addresses

Mostly reserved for future use by RFC 4193 (Unique Local IPv6 Unicast Addresses) section 3.1 (Format)

Specifically, the first seven bits of 1111110 are specified in the document by references to “FC00::/7”. Section 3.1 of RFC 4193 refers to the eighth bit (which the RFC refers to by a name of “L”). When that eighth bit is zero, the range is narrowed down more specifically to FC00::/8. The RFC describes that narrowed down range as being reserved (or, more verbatim, the RFC says such use “may be defined in the future”).

The only real indication of how these addresses are meant to be used is by RFC 4193 section 3.2 when it says that “Another method, indicated by clearing the L bit, may be defined later.” Therefore, frivilous use of these addresses is not recommended, as they are meant to be reserved for potential use by a new standard that may more precisely define the use of these addresses.

[#fd00s8] - fd00::/8 (fd00:0000::/16 to the end of fdff:ffff::/16) : Locally assigned IPv6 Unicast address

These IPv6 addresses are reserved, similar to how some specific IPv4 unicast addresses are reserved by BCP5 (e.g. RFC 1918) for local assignment (so that they may be used for private use).

Reservation: The fd00::/8 addresses are reserved by RFC 4193 (“Unique Local IPv6 Unicast Addresses”) section 3.1, although this is not necessarily straightforward in the RFC: RFC 4193 doesn't contain the letter combination “fd” and so makes no direct mention of a range called fd00::/8. Instead, having the first byte set to fd is simply implied by the mathematics that are stated in the RFC. What the RFC does refer to are fc00::/7 addresses that have the eighth bit set to one. The RFC states that addresses in FC00::/7, with the eighth bit set to 1, are locally assigned. If an address starts with FC00::/7 and also has the eighth bit set (to 1), that will make the address start with FD.

To discuss this just a bit further (in case this provides further clarity): RFC 4193 reserves fc00::/7 which is a range from the start of fc00::/16 through the end of fdff::/16, and starts with the seven bits 1111110. fd00::/8 is some of the addresses within the larger fc00::/7 range, and specifically those addresses where the eight bit is one so the first bits are 11111101 (instead of 11111100). (The other addresses within fc00::/7 range are the fc00::/8 addresses.)

Although the addresses are meant for local use, and are meant to be non-routable, they are meant to be globally unique. Therefore, after the first eight bits, the next 56 bits do have some rules which are meant to be followed to help ensure the desired global uniqueness. RFC 4193 section 3.1 specifies a method of assigning those bits when using fd00::/8. Specifically, it refers to RFC 4193 section 3.2 which identifies these addresses “indicated by setting the L bit to 1”. (Having the L bit cleared to zero “may be defined later” and would refer to an address in the fc00::/8 range instead of the fd00::/8 range.)

Specifically, after the first 8 bits, RFC 4193's intention is to have 40 bits be calculated using RFC 4193 section 3.2 and then 16 bits be used as a subnet ID. That covers the first half of the IPv6 address and leaves the remaining 64 bits for unique addresses within the subnet. Those 64 bits for a unique address are intended to be defined as described by RFC 4291 section 2.5.1.

For the 40 bits after the first eight, appears to be a script to implement this (in Python). seems to implement this, generating a prefix that is randomish (from time). (It isn't known how it is generating an EIU-64, though... perhaps using a MAC on the web server?)

There probably is a web site (or some software) that will take a MAC and generate a GUID according to RFC 4193 section 3.2. See how to generate a 64 bit ID. Note that RFC 4291 section 2.5.1 says "In some cases, an interface's identifier will be derived directly from that interface's link-layer address." So a MAC address can be used. However, it also refers to a local scope, e.g. tunnel end-points, and seems to be referencing universal scope versus local scope. (This could be useful when making 64bit/48bit unique addresses e.g. MAC addresses?)

IEEE document on MAC addresses section 3 says the second bit specifies if the address is universally or locally administered (to determine if it is unique universally or globally). Since each octet is transmitted with the least significant bit first, the second bit of the actual OUI is the seventh bit of how the address is typically written out.

[#fe00s9] - fE00::/9 (fE00::/16 to the end of FE7F::/16) : More bogons
IANA's IPv6 Address Space assignments documentation ( ) lists this as “Reserved by IETF”, so potentially it may be assigned something similar to the large block of addresses from 4000::/6 to FBFF::/6 which, as of this writing, are also unassigned and available for future use.

Covering the addresses up through the end of FE7F::/16 completes this large block of global unicast address spaces which goes from the beginning of addresses that begin with 0010 binary (which would start with the beginning of 2000::/3) and goes up through the end of fE7F::/16. That is the largest chunk of regular “Global Unicast” IPv6 addresses as indicated by RFC 4291 section 2.4, unless one prefers to also include the directly preceeding group of “Global Unicast” addresses from ::2/127 through the end of 01ff::/16. (Those different groups of “Global Unicast” addresses are sensibly grouped sensibly because of some properties/characteristics which do vary between the groups, although the two groups do in fact combine into one even larger group of “Global Unicast” addresses which go all the way from ::2/127 through the end of FE7F::/16.)

For more global unicast addresses, which are identified as “Global Unicast” addresses by both RFC 4291 section 2.4: “Address Type Identification” and RFC 4291 section 2.5.7: “Site-Local IPv6 Unicast Addresses”, see FEC0::/10 (FEC0::/16 through FEFF::/16).

[#fe80s9] - FE80::/9 (starting with binary 1111 1110 1xxx xxxx::) (FE80::/16 to the end of FEFF::/16) : (Initially meant for local use)
Firewalling recommendations
Each half of this segment has different recommendations.
[#fe80s10] - FE80::/10 (starting with binary 1111 1110 10xx xxxx::) (FE80::/16 to the end of FEBF::/16) : Local-Use IPv6 Unicast Addresses

RFC 4291 section 2.4: Address Type Identification describes this range as “Link-Local Unicast” The older term for this same address range was “Local-Use IPv6 Unicast Addresses”, as identified and reserved by RFC 3513 section 2.4: Address Type Identification, and discussed further by RFC 3513 section 2.5.6 : Local-Use IPv6 Unicast Addresses. (The RFC 4291 refers to RFC 3513 as obsolete.)

For fe80::/10 Link-local unicast addresses, the first eight bits make up the character 0xFE and are the bits 11111110. Then the the next two bits are a one and a zero (as specified by the number eight and the /10 that says to use the first two bits of the number 8.) RFC 4291 section 2.1 says “All interfaces are required to have at least one Link-Local unicast address”, and RFC 4291 section 2.5.6 defines a Link-Local unicase address as an address starting with 1111111010. (RFC section 2.4 points out the IPv6 abbreviation is FE80::/10.)

Note that fe80::/10 addresses do not always start with the text “fe80:”. fe80::/10 includes fe80::/16 and the last address of febf::/16, and all addresses in between such as the addresses in the range of fe9a::/16.

However, even though all of fe80::/10 is reserved by link-local (as shown by RFC 3513 section 2.4: Address Type Identification), there is a reason to limit link-local addresses to fe80::/64. (Honoring such a limitation does effectively waste all addresses in fe80::/10 except for fe80::/64.) The reason for this limit is simply that RFC 4291: “IPv6 Addressing Architecture”, section 2.5.6: “Link-Local IPv6 Unicast Addresses shows a diagram that indicates bits eleven through 63 are cleared to a zero value.

Reverse DNS domains

IANA: Special-Use Domain Names lists the following (in addition to other domains that are reserved for “special-use”)


This is rather unique, as no other block of IPv6 addresses are represented by domains that are listed on that page. The addresses are mentioned in sections 4, 12, and 22 (prior to section 22.1) of RFC 6762: Multicast DNS.

[#fe80s64] - FE80::/64 (FE80::/128 to the end of FE80::ffff:ffff:ffff:ffff/128) : Link Local IPv6 Unicast Address Range
Router/Firewall Recommendations:
Do not forward to any other links. RFC 3513 section 2.5.6 : Local-Use IPv6 Unicast Addresses says “Routers must not forward any packets with link-local source or destination addresses to other links.”

RFC 4291 section 2.5.6: Local-Use IPv6 Unicast Addresses describes this sub-section of addresses which are in the “Link-local” IPv6 Unicast Address Range. In addition to the documented value of the first ten bits, which is noted in the earlier section 2.4 of the same RFC, this section's diagram communicates that the 54 bits after the first 10 bits are all zeros.

By documenting that the 54 bits after the first 10 bits are all zeros, that effectively limits the “link local” address range to fe80::/64 (fe80:0:0:0:0::/80 through the end of fe80:0:0:0:ffff::/80), rather than all of fe80::/10 (fe80::/16 through the end of febf::/16).

Similar addresses
Most of IPv4 169.254/16 has a similar purpose.
[#fe805efe] - FE80::5EFE:0:0/96 (FE80::5EFE:0:0/128 to the end of FE80::5EFE:ffff:ffff/128) : ISATAP
See Wikipedia's page on ISATAP. The final 32 bits that are variable represent IPv4 addresses. Wikipedia's page on IPv6: Section on automatic tunneling says “Unlike 6to4 and Teredo, which are inter-site tunnelling mechanisms, ISATAP is an intra-site mechanism, meaning that it is designed to provide IPv6 connectivity between nodes within a single organisation.” [non-sic: British spelling of organization.] Therefore, the fact that this is within a range for addresses (that were initially) reserved for local use is sensible.
[#fe80ns64] - FE80::/10 addresses other than FE80::/64 addresses (FE80:0:0:0001::/64 to the end of FEBF:ffff:ffff:ffff::/64)

Usage of this range is within the address range of FE80::/10 addresses, so this has the binary prefix that RFC 3513 section 2.4 and RFC 4291 section 2.4 identify as “Link-Local unicast”. However, RFC 3513 section 2.5.6 and RFC 4291 section 2.5.6 say “Link-Local addresses have the following format” and then specify that bits 11 through 64 are all cleared to zero. Addresses that are not within FE80::/64 do not fit within the format described by section 2.5.6 of those two RFC documents.

One possible interpretation is that use of these addresses are not described consistently by those RFC documents. Another, though, is that the usage may simply not be defined yet, just like many other reserved addresses. Supporting this view, RFC 3513 section 2.5.6 identified that there were “two types of local-use unicast addresses defined”. This implies that any other type of local-use unicast address (the FE80::/9 address range) may simply be a type that isn't yet defined.

[#fec0s10] - FEC0::/10 (binary starting with 1111 1110 11xx xxxx::) (FEC0:0000::/16 to the end of FEFF::/16) : Global Unicast: Previous Site-Local IPv6 Unicast Addresses
Router/Firewall Recommendations

Do not send traffic involving such addresses to any destination outside of an organization, and do not accept such traffic from any address which is not part of the organization.

Currently the reason for that is that these addresses are bogons. Before their original assignment was deprecated, the intended use of these “site local” addresses would not have had the traffic be sent over the public Internet (without translation). RFC 3879 (“Deprecating Site Local Addresses”) section 4 says “router implementations SHOULD be configured to prevent routing of this prefix by default.” An earlier use of the addresses was for them to be treated by a site like private addresses, and so there may be some archaic assumptions that such traffic should be treated like it is coming from a trusted site. For that reason, attacks might be a bit more likely to come in with an address in this range, which is a reason not to accept such traffic (unless these addresses are assigned a different purpose at a later time). Since these addresses are now considered to be global unicast, the only justification to block these is their current status as bogons. No current standards or other long term logic suggest that these should be blocked forever since, in theory, IANA could re-assign this block at some point. (In reality, IANA is probably not likely to assign this block of addresses when there are so many other ranges of unused addresses that don't have a history, like this address range has, of being previously assigned/used/reserved-for-a-special-purpose.)

Overview of current use/plans

RFC 4291 (“IP Version 6 Addressing Architecture”) section 2.5.7: “Site-Local IPv6 Unicast Addresses” says that “new implementations must treat this prefix as Global Unicast”. Also in that same RFC, this address range is part of the “everything else” category mentioned in RFC 4291 section 2.4, and so what section 2.4 specifies is that these addresses are Global Unicast. (This differs from the older RFC 3513 section 2.4 where the term “everything else” did not apply to the “Site-local unicast” “Address type”.)

This section of global unicast addresses is far smaller than the larger chunk of global unicast addresses which goes from ::0002/127 through the end of FE7F::/16. The reason for these Global Unicast addresses being separated from the larger Global Unicast group has to do with the history of these addresses: They were not always intended to be treated as Global Unicast addresses. Further details are in the section of the history of Site-Local addresses.

Some more details, such as a requirement of an embedded Interface ID, are provided by the Overview section of the section about the large range with most of the Global Unicast address spaces.

[#hisitlcl]: History of FEC0::/10 being Site-Local

RFC 4291 (“IP Version 6 Addressing Architecture”) section 2.5.7: “Site-Local IPv6 Unicast Addresses” says that “The special behavior of this prefix defined in [RFC3513] must no longer be supported in new implementations (i.e., new implementations must treat this prefix as Global Unicast).” However, it also has this note: “Existing implementations and deployments may continue to use this prefix.” (RFC 3879 section 4 has a similar note, but capitalized differently.) Therefore, building a new implementation that uses the old behavior is a non-standard behavior. However, once that non-compliant behavior is done, any use of the old behavior on such “Existing implementations and deployments” would be compliant to the precise text as stated, whether or not intended, unless the statement only referred to deployments pre-dating the publication of the statement. In any case, such usage should be compatible with software because software should be compatible with such usage (in case it is being used on an existing deployment), unless the software attempts to do something unusual such as detect the date of initial deployment.

Although earlier RFCs, such as RFC 3513 section 2.4 and especially RFC 3513 section 2.5.6, referred to these as the “Site-local” local-use unicast addresses, that initial intended use has been revoked rather srongly.

RFC 4291 section 2.5.7 : Site-Local IPv6 Unicast Addresses which “are now deprecated” by RFC 3879: Deprecating Site Local Addresses (which states that after “debating”, “the consensus was far from unanimous”). RFC 3879 section 4 says “router implementations SHOULD be configured to prevent routing of this prefix by default.”

IETF draft document says “It is expected that IPv6 site-local addresses will be self correcting as IPv6 implementations remove support for site-local addresses.”

[#fec00fs64] - FEC0:0:0:ffff::/64 (a.k.a. FEC0:0000:0000:ffff:0000::/80 through the end of FEC0:0000:0000:ffff:ffff::/80)
[#fec00fx3]: FEC0:0:0:ffff::/126 (FEC0:0000:0000:ffff:0000::/128 through FEC0:0000:0000:ffff:0000:0000:0000:0003/128)): A not-fully-standardized usage: “Well-known” (site-local) DNS servers

Draft which expired in years ago: Well known site local unicast addresses to communicate with recursive DNS servers says that the three addresses fec0:0:0:ffff::1 and fec0:0:0:ffff::2 and fec0:0:0:ffff::3 be used for DNS servers. Note that this document isn't widely recognized as a standard meant to be used on a wide-scale basis. (Versions 6 and 7 of the draft likely meant to update the expiration date to the following year, but didn't, and so, ridiculously, their listed expiration date is earlier than the date they were published. In addition, the page says, “It is inappropriate to use Internet-Drafts as reference material”, and also inappropriate to cite them as being anything other than a “work in progress.”

Using such addresses is in violation of the rule that bogons shouldn't be used: As noted by IANA page on Internet Protocol Version 6 Address Space, the IETF says the FEC0::/10 address range is “Reserved by IETF”, so any such usage is violating the reservation.

Surely, no respectable manufacturer of hardware or software would actually start utilizing such an unprepared thing, right? Let's see... The following may not have been fully tested and verified by site's staff, but the following information has been found:

Clients using Microsoft Windows Vista support these DNS addresses, according to Lab part 2. These are documented by TechNet article: Using Windows Tools to Obtain IPv6 Configuration Info.

Possibly related topic: Usable DNS servers to use

[#ff00s8] - FF00::/8 (FF00::/16 through the end of the IPv6 address range, which is the end of FFFF::/16) : Multicast
Firewall/Router recommendations

(No specific recommendations are currently being provided here.)

RFC 2588 - IP Multicast and Firewalls might be IPv4 specific, but may have some relevant info.

An network interface listens to traffic which is sent to any “group” that the interface has “joined”. Reserving all of the addresses that start with FF. The IPv4 equivilent: Addresses from the IPv4 Class D range.
Format of IPv6 multicast addresses
Nibble, nibble, nibble, nibble: the first four nibbles of each IPv6 multicast address
The first octet of a multicast address
The first octet byte contains eight bits which are all set to one. Both of the nibbles in this first octet byte can be written with the hexadecimal character F, so all IPv6 multicast addresses start with FF. (This statement is true of all IPv6 multicast addresses: statements that are true for multicast addresses are not necessarily true about “anycast” addresses.)
[#ffxxbyt2]: The second octet byte

The second octet byte of an IPv6 address contains the 9th through the 16th bits of the address. (These may often be referred to using zero-based counts, in which case they might be identifies as bit number 8 through bit number 15). Like all other octet bytes, this contains eight bits. Those eight bits may also be referred to as two nibbles, where each nibble consists of four bits each. For this specific byte

The meanings of the values of the bits in the IPv6 multicast address's third nibble may take a bit of time/study to grasp, and may be details that aren't needed for a novice to dive into right away. However, it still may be nice to know that there are patterns. The cases where the 10th and 11th bits are both cleared to zero are probably the simplest of cases.

The first two nibbles are certain to have each bit set to a value of one, since IPv6 multicast addresses start with FF##::/8. After those first two nibbles, the next nibble is, naturally, the third nibble. Both the third and fourth nibbles of each IPv6 multicast address are nibbles with names. Both the name of the third nibble, and the name of the fourth nibble, are four letter abbreviations of five letter words. (That means the abbreviations save just a single letter.)

The IPv6 address's fourth nibble: the 9th through the 12th bits

This nibbles is part of the second octet byte. (More information about that entire byte, at least some of which is information that applies to this nibble, is information available at that hyperlink.)

The third nibble of an entire IPv6 address was named “flgs” by (the now-obsoleted) RFC 3513: IPv6 addressing (section 2.7: Multicast addresses). That name is meant to represent the word “flags”.

The fifth half-nibble of each IPv6 multicast address
The ninth bit of each IPv6 multicast address
(the now-obsoleted) RFC 3513: IPv6 addressing (section 2.7: Multicast addresses) is an older document that says the first bit (of this nibble) is “reserved” and “must be initialized to 0.” That remains true with the newer RFC 4291: IP Version 6 Addressing Architecture (Section 2.7: Multicast addresses) which replaced the old RFC 3513. (RFC 3513 also had definitions for the next three bits, although there has been some change there.) Until another, newer RFC overrides the current status, the first flag bit may not be set to one because, if it was, that would be in violation of the latest RFC that covers the possible values of that bit.
The tenth bit of each IPv6 multicast address

The second flag/bit is discussed in the RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address: Section 3 (“Modified Unicast-Prefix-based Address Format”). The initial assigned to name this bit is “R”. (Older documentation, such as RFC 3306 (page 3), only had documentation for when this bit is a zero, and so it was represented with a name/initial of a zero.) If this bit is one, RFC 3956 section 3 notes that the next two bits will also be 1 (because of RFC 3306, which is about to be re-mentioned and which describes the third bit).

The eleventh bit of each IPv6 multicast address

The third flag/bit of the address's third nibble is discussed in RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses (particularly sections 4 and 6). If this is set to 1, then the multicast address “is assigned based on the network prefix”. What this effectively means and reveals is that some procedure, likely automated, is used to calculate the address. If this is set to 1, the RFC 3306 indicates that this is a dynamic address, and therefore the next bit “MUST be set to 1” in that case. If this bit is set to one, then RFC 3306 page 3 specifies that the third byte of the whole IPv6 network address is reserved, the fourth byte is a value for “plen”, and RFC 3306 has further details about the rest of the bits.

The twelth bit of each IPv6 multicast address

For the fourth/last/final bit of the IPv6 multicast address's third nibble, the the setting of this flag bit was originally defined by (the now-obsoleted) RFC 3513: IPv6 addressing (section 2.7: Multicast addresses). That basic definition is still endorsed by the newer RFC 4291: IP Version 6 Addressing Architecture (Section 2.7: Multicast addresses), although there is now some increased complexity regarding the value of the fourth bit: that newer RFC 4291 also references RFCs about the second and third bit, and those other RFCs also have some rules about the 4th bit.

  • If the nibble's second ("R") bit is zero and the nibble's third ("P") bit is 0, then this is called the “Transient” bit. In that case, a value of zero means “a permanently-assigned ("well-known") multicast address, assigned by the Internet Assigned Numbers Authority (IANA).”
  • If the third bit of this nibble is a one, then this fourth bit is set to a value of one.
    • If the second bit of this nibble is a one, then the third bit of this nibble is a one (and this nibble's forth bit is also set to a value of one).

Based on the information provided about the 9th and 10th bits, the third hexadecimal digits cannot be 5, 6, or 8 through F. Any of those values would violate necessary patterns. (Requiring that the first bit is a zero will prevent values of 8 through F. If the tenth bit is a zero, then the eleventh and twelth bits must be a zero, so that knocks out 5 and 6.) (of having the first bit be a zero, and having the eleventh and twelth bits be a 1 if the ten bit is a 1.)

That would seem to only allow the possibilities of the zero through three, or seven. However, a value of 2 also violates a rule described in the section about the twelth bit, which is that the twelth bit must be a 1 if the eleventh bit is a 1. So, only values of 0, 1, or 3 are possible for the third digit.

Finally, this gets narrowed down further with the requirement that the digit should be odd unless the address is specified by IANA, which is a conclusion directly drawn from the information provided by RFC 4291 section 2.7 (when discussing the “T” flag on page 12).

This seems rather restrictive, but are the rules based on RFC documents, and so people must follow those rules if they are “standards-compliant”, unless newer RFC documents provide updated information.

Commentary about the fourth byte will discuss the case when both the third and fourth byte are zero.

The fourth nibble: Wrapping up the first couple of octet bytes

This nibble is part of the second octet byte. (More information about that entire byte, at least some of which is information that applies to this nibble, is information available at that hyperlink.)

After the third nibble, which presents flags, the fourth nibble is called “scop”, a name which is a (not very abbreviated) abbreviation of the word “scope”. The documentation of (the now-obsoleted) RFC 3513: IPv6 addressing (section 2.7: Multicast addresses) uses hexadecimal notation to document all of the possible values for this nibble, and documents any special meaning or use for half of the possible values while the other half of the possibilities are listed as “unassigned”, so no special use has been provided for them. The newer RFC 4291: IP Version 6 Addressing Architecture (Section 2.7: Multicast addresses) does not update these assignments. RFC 2373 section 2.7 had a very similar list.

The scope values include:

  • reserved values: 0 and F. In RFC 3513 and 4291, 3 is also reserved.
  • 1 : Interface-Local scope (RFC 3513 and 4291) (RFC 2373 called this “node-local”
  • 2: Link-Local.
  • 3: discussed by zero
  • 4: Admin-Local (in RFC 3513 and 4291, was unassigned in RFC 2373)
  • 5: Site-Local
  • 8 : Organization-Local
  • E : Global
  • F : as noted by zero, F is reserved

Since this is the fourth nibble, this is the fourth hexadecimal digit when writing out the IPv6 address in standard notation. This nibble can be used to quickly identify the scope. For instance, an address that is in the FF12::/16 range will be using link-local scope.

Note that the above information may be contemplated whenever an address assignment is decided upon. However, this is not an unused address range meant for decentralized private assignments. (For such a thing, see some of the addresses within the FE80::/9 address range.) There are some public IANA assignments for IPv6 multicast addresses.

The group ID

After the first 16 bits (two octet bytes), there is a field called the “group ID” which is a field located at the end of the IPv6 multicast address. If the 11th bit of the entire IPv6 multicast address is a zero, then RFC 3306 section 4 specifies that the address should be referred to by section 2.7 of the IPv6 Addressing Architecture RFC, which is an RFC that has been updated after RFC 3306 so a more recent, relevant RFC reference is RFC 4291 section 2.7, and in this case the group ID is bits bytes long (taking up all of the bits after the first two octets). However, if the 11th bit of the entire IPv6 multicast address is set to a value of one, then RFC 3306 page 3 has a different format where the group ID is a smaller 32-bits long (and is still at the end of the address). The other bits, bits 17 through 96, may or do have different interpretations, as described by RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses (particularly sections 4 and 6?).

As an update from the earlier RFC 3513 (which documented this term “group ID”), RFC 4291: IP Version 6 Addressing Architecture (Section 2.7: Multicast Addresses) noted “group ID identifies the multicast group, either permanent or transient, within the given scope. Additional definitions of the multicast group ID field structure are provided in” another RFC, which is RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses. Therefore, even though RFC 4291 does not have the newer chart shown in RFC 3306, the newer RFC does acknowledge RFC 3306.

[#i6ffiana]: IANA-reserved IPv6 multicast addresses

To see some details of the current assignments, see: IANA's IPv6 Multicast Assignments (XML) (or IANA's IPv6 Multicast Assignments (text file version) which the XML file links to) or IANA's IPv6 Multicast Assignments (redirector to text or XML versions, used when browsing directly to the multicast-addresses/ directory). (The XML version is prettiest, showing some nice tables, and is nicely rendered by some web browsers: see information about XML files for details.)

Some of the more important/noteworthy addresses include:

[#i6ff00sc]: FF00::/12 (FF00::/16 through the end of FF0F:FFFF:/16)

If (after being fully expanded) an IPv6's address's first three hexadecimal digits are “FF0” (regardless of what the fourth hexadecimal digit is), then the values are covered by the list of address ranges at the top of RFC 4291 page 16, as well as the first full statement of that page (which comes right after the list of addresses).

Such addresses should only be used in ways that the addresses are reserved for, as covered in other sections of RFC 4291 section 2.7.1.

[#ff02cc1]: FF02::1 : all-nodes multicast address (reserved by RFC 4291 page 16 (in section 2.7.1))

A definition for the term “node” is provided by RFC 4861 section 2.1 which says a node is “a device that implements IP” (and unlike many older documents where “IP” is synonymous with IPv4, “IP” generally refers IPv6 in that document). RFC 4291 page 16 shows that FF02::1 is for all link-local IPv6 nodes. Therefore, this would be similar to IPv4's An example of this being used is RFC 4861 (NDP) section 2.3 (section on “Addresses”)).

See: RFC 4291: “IPv6 Addressing Architecture”, section 2.7: “Multicast addresses. In RFC 4291 section 2.8: “A Node's Required Addresses”, it is revealed that every IPv6 device should support “The All-nodes multicast addresses” specified by RFC 4291: “IPv6 Adressing Architecture”, section 2.7.1: “Pre-Defined Multicast Addresses”. These required addresses are both FF01::1 (which is “Interface-Local scope”, per RFC 4291 section 2.7) and also FF02::1 (which is “Link-Local” scope, according to the same section, RFC 4291 section 2.7).

FF02::2 - all-routers multicast address (reserved by RFC 4291 page 16 (in section 2.7.1))

A definition for the term “router” is provided by RFC 4861 section 2.1 which says a router is “a node that forwards IP packets not explicitly addressed to itself.”

RFC 4861 (NDP) section 2.3 (section on “Addresses”)).

This would seem similar to FF02::1, except that any host (a “host” is defined by RFC 4861 section 2.1 as “any node that is not a router”) would treat this traffic as traffic only meant for other nodes. That means the hosts would ignore the traffic (after processing the traffic enough to find out that the traffic isn't meant for the host) unless “promiscuous mode” is being used.

[#ff02z1c2]: FF02::1:2: All-dhcp-agents
This is “All-dhcp-agents” as noted by IANA's IPv6 Multicast Assignments (redirector to text or XML versions, used when browsing directly to the multicast-addresses/ directory) which references RFC 3315. (See also the IPv6 address FF05::1:3.)
[#ff02z1c3]: FF02::1:3: LLMNR
FF02::1:3 is that address is used with LLMNR, as noted by RFC 4795: LLMNR. (This method of name resolution is mentioned at: section on name(-to-address) resolution, sub-section on LLMNR.)
FF02:0:0:0:0:1:FF00::/104 (to FF02:0:0:0:0:1:FFFF:FFFF) - “Solicited-Node multicast address”
The last 24 bits of the multicast address are taken from another address (RFC 4291 page 16). RFC 4291 page 17 notes, “A node is required to compute and join (on the appropriate interface) the associated Solicited-Node multicast addresses for all unicast and anycast addresses that have been configured for the node's interfaces (manually or automatically).”
[#ff05z1c3]: FF05:0:0:0:0:0:1:3: All DHCP Servers
All DHCP servers, as noted by IANA's IPv6 Multicast Assignments (redirector to text or XML versions, used when browsing directly to the multicast-addresses/ directory) which references RFC 3315. (See also the IPv6 address FF02::1:2.) (The following address, FF05:0:0:0:0:0:1:4, had been “All-dhcp-relays” as noted by RFC 2375: “IPv6 Multicast Address Assignments” Section 2.3: “Site-Local Scope”. However, IANA's IPv6 Multicast Assignments (redirector to text or XML versions, used when browsing directly to the multicast-addresses/ directory) now calls it “Deprecated (2003-03-12)”.

Some other blocks include:

FF30::/24 (FF30::/32 - FF3F::/32)
See RFC 3306 section 6
See RFC 3956 section 3.
Misc. multicast info
RFC 4489

And that wraps up the IPv6 address range.