IPv6 Address Types

IPv6 looks different than IPv4 but there are some similarities. For example we have unicast addresses and we still have a “public” and “private” range. We use different names for these but the idea is the same. One of the differences is that IPv6 has some additional unicast address types.

We still have multicast, same idea but we use different addresses. There are also some reserved addresses that are similar to their IPv4 counterparts.

Something new is anycast, an address that can be assigned on multiple devices so that packets are always routed to the closest destination. Also, broadcast traffic doesn’t exist in IPv6 anymore.

In this lesson we’ll take a look at all the different address types and I’ll explain what they look like and how we use them.

Unicast

Unicast IPv6 addresses are similar to unicast IPv4 addresses. These are meant to configure on one interface so that you can send and receive IPv6 packets. There are a number of different unicast address types that we’ll discuss here.

Global Unicast

The global unicast IPv6 addresses are similar to IPv4 public addresses. These addresses can be used on the Internet. The big difference with IPv4 however, is that IPv6 has so much address space that we can use global unicast addresses on any device in the network.

Unique Local

Unique local addresses work like the IPv4 private addresses. You can use these addresses on your own network if you don’t intend to connect to the Internet or if you plan to use IPv6 NAT. The advantage of unique local addresses is that you don’t need to register at an authority to get some address space. The FC00::/7 prefix is reserved for unique local addresses, however when you implement this you have to set the L-bit to 1 which means that the first two digits will be FD. Here’s an example:

IPv6 Site Local Address

Let’s discuss all the fields of the unique local address. The first 7 bits indicate that we have a unique local address. 1111 110 in binary is FC in hexadecimal. However, the L bit (8th bit) has to be set to 1 so we end up with 1111 1101 which is FD in hexadecimal.

The global ID (40 bits) is something you can make up. Normally an ISP would choose a prefix but now it’s up to you to think of something. What’s left is 16 bits that we can use for different subnets. This gives us a 64-bit prefix, what’s left is 64 bits for the interface ID.

Let’s work on an example…let’s say that we have a LAN and we want to use unique local IPv6 addresses and we require 10 subnets:

  • The prefix starts with FD.
  • We have 40 bits for the global ID, each hexadecimal character represents 4 bits so we can pick 10 hexadecimal characters. Let’s use AB:1234:5678 as the global ID.
  • Our first subnet will start with 0000.

Here’s what we’ll end up with:

IPv6 site local example

FDAB:1234:5678:0000::/64 will be our first subnet. The other subnets could look like this:

  • FDAB:1234:5678:0000::/64
  • FDAB:1234:5678:0001::/64
  • FDAB:1234:5678:0002::/64
  • FDAB:1234:5678:0003::/64
  • FDAB:1234:5678:0004::/64
  • FDAB:1234:5678:0005::/64
  • And so on…

If you are just messing around with IPv6 then you could use a simple global ID like 00:0000:0000 which is nice because you can shorten it to ::. For production networks, it’s better to pick something that is truly unique. When you want to connect multiple sites that use unique local addresses then you want to make sure you don’t have overlapping global IDs.

Link-Local

Link-local addresses are something new in IPv6. As the wording implies, these addresses only work on the local link, we never route these addresses. These addresses are used to send and receive IPv6 packets on a single subnet.

When you enable IPv6 on an interface then the device will automatically create a link-local address. We use the link-local address for things like neighbor discovery (the replacement for ARP) and as the next hop address for routes in your routing table. You will learn more about this when you work through the static route and OSPFv3 lessons.

We use the FE80::/10 range for link-local addresses, this means that the first 10 bits are 1111 1110 10. Here’s what it looks like:

IPv6 link local structure

The first 10 bits are always 1111 1110 10 which means that we start with FE80. Technically the following are all valid link-local addresses:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

501 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi Rene,

    I tried to simulate the Embedded-RP but it didn’t work.
    The only stuff that worked was statically configured ipv6 pim rp-address on all the nodes.

    But i was trying to check that cool feature and what i saw is that on DR (where source is connected) there’s a constant Registering appears there and RP node itself is not seeing (S,G), only (*,G) as a part of connected receiver via MLD join-group.

    I don’t get what i’m missing here…

    I will be very thankful to you if you can reply with your suggestions what could be the problem?

    By the way does this feature s

    ... Continue reading in our forum

  2. Vladimir,
    I am pretty sure that an Embedded RP will work on that platform. One key configuration step that I didn’t see you mention is that you must manually configured the chosen RP to be an RP for itself, via the ipv6 pim rp-address command.

    After the RP has been statically configured to itself, your embedded RP address (assuming it is configured correctly!) should work.

    You are correct in that if you are using a /128 loop back address, you would need to change the “40” to an “80” since those two digits represent the mask in hexadecimal.

    If this still doesn’

    ... Continue reading in our forum

  3. I looked at the formation of your Embedded RP, and it looks correct.

    Your RP = FC00:2:2:2::2/64
    Your Embedded RP Address: FF78:240:FC00:2:2:2:0:1. This address is correctly formatted assuming you want to use the first multicast group (then trailing 0:1) possible on that RP, and the scope of the multicast group is global (8).

    Also, your show commands have the correct output (like on the RP, for example) where it shows the correct (*,G) entry.

    The problem is your lab is extremely complicated, and frankly, I don’t want to spend two hours troubleshooting it. I su

    ... Continue reading in our forum

  4. Hi Andrew,

    I checked with 3 nodes R1—R2—R3 and it worked properly. R1 (source), R2 (RP) and R3 (receiver)
    What i don’t understand is if R1 is sending the MCAST traffic, then who is DR in this scenario? R2? Who actually is sending the unicast register messages towards RP? A little bit confusing this scenario.

    I’m regular to some basic setup where R5—R1—R2—R3—R7 where (R5 is a source), (R1 a DR), (R2 is and RP), (R3 is a last hop router connected to receiver), (R7 is a receiver)

    But what i found out is if i test with 5 devices than it’s not working and DR is show

    ... Continue reading in our forum

  5. Hi Andrew,

    one more update:
    It’s not working when changing the 40 to 80!
    I changed the loopback prefix to /128 (FC00:2:2:2::A/128 instead of FC00:2:2:2::A/64) and joined the following MCAST ipv6 group on receiver (ipv6 mld join-group FF78:A80:FC00:2:2:2:0:1) but RP wasn’t learned on any node and therefore the traffic didn’t flow as well.

    (*, FF78:A80:FC00:2:2:2:0:1), 00:00:03/never, RP ::, flags: SCLJ
      Incoming interface: Null
      RPF nbr: ::
      Immediate Outgoing interface list:
        GigabitEthernet1.37, Forward, 00:00:03/never
    

    But if i was using the following g

    ... Continue reading in our forum

3 more replies! Ask a question or join the discussion by visiting our Community Forum