IPv6 Unique-Local Addressing Explained

By Joe Astorino on August 2nd, 2010

When we are dealing with IPv6 “private” addressing, it can quickly become pretty confusing. The reason this particular topic becomes confusing is because the people that have developed the technology keep changing their minds!!! Let’s go through some history.

Site-Local Addresses

Site-local addresses were the first stab at having a private address space range for our internal organizations similar to RFC 1918 for IPv4. This address space was defined in RFC 3513 as being in the range FEC0::/10. Basically what this means is that the first 12 bits of the address had to look something like this:

1111 1110 11xx

[ F ] [ E ] [C-F]

So anyways, the site-local address was the first attempt at letting network admins assign their own private addressing for their “sites.” The issues with it were that the term “site” was somewhat ambiguous. Nobody could really agree on what a “site” was. Secondly, there was no guarantee that no two sites within the same organization would not end up using overlapping site addressing due to carelessness or whatever else. Site-Local addresses went to sleep permanently when deprecated officially in RFC 3879. Unfortunately for the current CCIE candidate, this site-local address range is still used quite extensively in some Cisco documentation

Unique-Local Addresses

Out with the old in with the new! Unique-Local addresses have officially replaced site-local addresses. These get a little bit more interesting because there are really two different “flavors.” Unique-Local Addresses (ULA) are defined in RFC 4193 and are given the range FC00::/7. Basically your first 8 bits will look like this:

1111 110x

[F ] [C-D]

Overall, your unique-local address will look something like this:

F[C-D]xx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

So obviously it starts with EITHER FC or FD in hexadecimal. The string of ‘x’s there represents what we call our “global-id” which would describe your company and is 40 bits long. The string of ‘y’s represent what we call the “subnet-id” which describes the sites within your company and is 16 bits long. The string of ‘z’s is the remaining 64 bits that represent a host. So essentially you have a 40-bit value that represents your company and 16 bits to play with for subnetting. If you do the math that gives you up to 65,535 /64 subnets…a LOT of addresses.

OK, so we have this FC00::/7 range. Now, here is where it gets a little extra interesting. Basically some people thought the 40-bit global-id should be something centrally assigned by a registrar of sorts (kind of like ARIN). The addresses would still not be routable on the public internet, but would be controlled by a trusted third party registrar. The reasoning was so that it was guaranteed that no two sites within an organization would ever get overlapping ranges. On the other hand, other people didn’t like the idea of having private addresses allocated to them. Therefore, what they did was a compromise. They took this massive FC00::/7 range and broke it up into two individual /8’s – FC00::/8 and FD00::/8 and each one works a bit differently.

Unique-Local Locally-Assigned Addresses (FD00::/8)

The folks that do not want their private addresses assigned to them by a third party get this range. The kicker is that in the RFC the way that 40-bit global-id get’s picked is still not really SUPPOSED to be up to you. It is a randomly generated number (at least “pseudo-random”). So, with FD00::/8 you get something like this

FDxx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

Here the string of ‘x’s is still the global-id and is 40-bits long…it is just randomly generated, or at least SHOULD be. The rest is the same…we still have 16 bits for subnetting and a /64 host address

Unique-Local Centrally-Assigned Addresses (FD00::/8)

The folks that WERE for the private addresses being centrally assigned by some sort of registrar get the FC00::/8 range. Now, as of right now this organization that is supposed to hand out the addresses really doesn’t exist yet :P ANYWAYS, the concept is similar except now you have something like this:

FCxx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

Here the string of ‘x’s is still the global-id and is 40-bits long…but it is ASSIGNED to you in theory. The rest is the same…we still have 16 bits for subnetting and a /64 host address

So now what?!

For purposes of the CCIE R&S v4.0 lab – IF you are asked to do “site-local” addressing I would verify with the proctor that they REALLY mean site-local as in the FEC0::/10 range. IF that is the case, go ahead and just pick something in the range and use it while smiling to yourself because it is really deprecated.

IF you are asked to do unique-local addressing I would watch the wording of your lab. If it says something about you being “assigned” such and such range, I would opt for the centrally assigned range of FC00::/8. They may say something like “You have been ASSIGNED a global-id of ABCD:EF12:34. Use the middle two octets of your IPv4 subnet as your subnet ID.” Let’s say the middle two octets were 4.4 in your IPv4 address space. That would equate to something like FCAB:CDEF:1234:0404::/64. Because they said ASSIGNED I would assume we were using the FC00::/8 range. The next 40 bits (global-id) were given to you, and you derived the next 16 bits from your IPv4 address.

IF you are told to do unique-local addressing and they mention something about you assigning your global-id yourself, or having it randomly generated I would opt for the FD00::/8 locally assigned range. Maybe you would have a task similar to this: “You have decided to assign the unique-local global-id of BABA:CACA:12. Use the middle two octets of your IPv4 subnet as your subnet ID.” That would equate to something like FDBA:BACA:CA12:0404::/64. Because they said YOU assigned it to yourself or that it was “randomly generated” I would use the FD00::/8 range of addressing there.

Don’t you miss RFC 1918 now? :P


Joe Astorino
CCIE #24347 (R&S)

IPv6 Unique-Local Addressing Explained, 5.0 out of 5 based on 7 ratings
Be Sociable, Share!

    Tags: CCIE R&S, CCIE Routing and Switching, IPv6, ipv6 unique local addressing

    8 Responses to “IPv6 Unique-Local Addressing Explained”

    1. [...] This post was mentioned on Twitter by ipexpert, ONIPE PETER (c0dE-3). ONIPE PETER (c0dE-3) said: RT @ipexpert: Read Joe Astorino's take on IPv6 Unique-Local Addressing Explained http://bit.ly/apgiKB #CCIE [...]

    2. stretch says:

      Nice article! One minor typo: the header “Unique-Local Centrally-Assigned Addresses (FD00::/8)” should read FC00::/8, right?

      Also, I would hope that a CCIE lab task wouldn’t be so needlessly semantic with regard to either range.

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (3 votes cast)
    3. Manouchehr says:

      Really nice write up!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    4. X says:

      FC00::/8 is now deprecated too, so if someone see this article use FD00::/8.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    5. Junaid says:

      fantastic! some valuable info on the CCIE lab :)

      Thankyou

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    6. Ivo Santos says:

      Okay, so if I or somebody else decide to play with ip 6 addresses I or we can use the FD00::/8 network prefix, thats was nice to know, and thanks again for a informative article.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    7. del says:

      Thank you Joe, for the explanation. I was at a loss at how FC00:: equates to 7 bits.i really should stop running from them rfc

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    8. Jose Nomberto says:

      Thank you Joe. Nice explanation about IPv6 ULA. It helped me to finally get this topic clear. By the way, nice example with the BABA:CACA prefix.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)

    Leave a Reply