IPv6 for future CCNAs (+), Final Part.

Unicast Addresses: Unique-Local.
Before we talk about Unique-Local Addresses (ULA), let me tell you about Site-Local addresses; it was deprecated in favor of the ULA back in 2004 because the term “site” was too ambiguous, no body agreed upon a clear definition of the term “site”; what was considered a “Site”?
Also, the provability of Site-Local address being globally unique were no that high, as opposed to ULAs.
ULAs are meant to be routed within an organization’s LAN or even WAN, but they are not routable over the public network (Internet), hence, you can think of ULAs very much as IPv4’s Private addresses.

A ULA is identified by the first 7 bits of the address which are 1 1 1 1 1 1 0 and that is FC00 in hex. The 8th bit, called the “L” bit, is set to 1 if the Global ID was Locally assigned, meaning that is was generated by the organization.

As we will see just ahead, the Global ID is always generated by the organization, so the “L” bit will always be set to 1 and the “L” bit set to 0 is reserved for future usage, hence, the address we will see is 1 1 1 1 1 1 0 1 (FD00::/8).

Notice that after the 8th bit, there is another 40bits field called the Global ID, and this field is randomly generated by the organization to assure high probabilities of a unique Network Prefix, even globally.

Section 3.2–Global ID of the RFC 4193–Unique-Local IPv6 Address, recommends that this field NOT be generated in a sequential fashion to prevent any allocation relationship between Global IDs, instead, it should be randomly generated following the steps described in section 3.2.2 of the RFC.

Let’s see an example of a ULA Prefix:

Special IPv6 Addresses.

Unspecified Address.
This address is represented as 0:0:0:0:0:0:0:0 or just :: and it is very similar to the unspecified IPv4 address 0.0.0.0.
It is used as a “place holder” if you will; for example, as you know, when an interface gets IPv6 enabled, it gets an auto-assigned Link-Local address, but first, it needs to make sure that this address has not been assigned to another interface already. So to do this, it uses a process called Duplicate Address Detection (DAD) as part of the Auto-configuration process, and during this process, the interface sends out a packet called Neighbor Solicitation (NS) message to the All-Nodes multicast address of FF20::1 “asking” if this particular address is being used by another interface already on the network, the source address on this packet will be all zeroes or :: which is the unspecified address (more details on auto-configuration and DAD later).

Loopback Address.
The Loopback address is very similar to and used for the same purpose as the 127.0.0.1 Loopback address in IPv4, but it is represented in IPv6 by all zeroes and a 1, like this; 0:0:0:0:0:0:0:1 or just ::1.

An example of its usage will be when there is an issue on the network and we want to make sure that a particular interface is working properly, we can send a PING packet to the interface’s Loopback address of ::1 (pinging itself) and if we get a reply, it means that the TCP/IP stack in this interface is working properly… the issue is somewhere else.. :O)

The picture below shows that this interface is ready to exchange packets in a TCP/IP network. The ping packets went through the TCI/IP stack, (Application down to Physical), looped around and went through the TCP/IP stack again (Physical up to Application):

Multicast Addresses.
Every type of IPv6 addresses we’ve discussed so far, have been Unicast addresses, let’s move on now to the Multicast address.

Let me get this important aspect of a Multicast address out of the way; The Multicast address type replaces IPv4’s Broadcast, but the way it works makes it much more efficient then a Broadcast. There, let’s continue now.

A Multicast address represents a Multicast Group and interfaces that need to recieve this traffic, will be automatically joined into these Multicast Groups.

It is one-to-many communication, so a packet sent to a Multicast address will be received by all the interfaces that have been automatically joined into the Multicast group, which this Multicast address represents.

These Multicast addresses are predefined and well-known (I’ll show you a table in just a bit), and an interface is automatically joined to different, well-known multicast groups as needed.

For example, as we already know, when we enable an interface for IPv6, a Link-Local address is assigned to it, but also, the interface will join a couple of well-known multicast groups; FF02::1 (All-Nodes) and FF02::2 (All-Routers). These well-known and predefined Multicast addresses represent a Multicast Group; FF02::1 represents all IPv6 enable devices on the network and FF02::2 represents all the IPv6 routers on the network. This means that when an interface sends out a packet to the multicast address FF02::1, every single device will receive and process the packet, and if the packet is sent to FF02::2, every router will receive and process the packet.

As you can see, the All-Nodes FF02::1 Multicast address works much like a Broadcast, but remember, in order for a device to receive this packet it must be joined into the All-Nodes Multicast Group and the interface will be joined into the Multicast group if needed. If it is not joined, then it will not receive the packet at all. This is the main difference between the All-Nodes Multicast address and a Broadcast from IPv4.

Note: There is a third well-known multicast group that the interface gets joined into, that is the Solicited-Node multicast group and we’ll talk about this just ahead.

The predefined, well-known address groups are:

Let’s see how an interface is joined into a multicast group:

Multicast Address Format.
An IPv6 Multicast address is very easy to recognize; it is represented by the first 8 most significant bits set to 1111 1111, that’s FF in hex so, any address that starts with FF is a multicast address.

Further more, the next 8 bits (8th through 15th) are divided into two fields; Flag and Scope, respectively:

Picture from http://www.cisco.com/c/en/us/td/docs/security/fwsm/fwsm40/configuration/guide/fwsm_cfg/ports_f.html#wp1045362

Without going into much detail about the Flag and Scope fields because it is not a CCNA topic, you should know that the Flag field is 4 bits long and it represents the 3rd hex digit of the address. If the Flag field is a 0 (in hex of course), it means that the address is permanently assigned (a predefined, well-known multicast address), and if it is a 1, it is a temporary or transient address. This indicated that a well-known multicast address will always start with FF0, and that is true.

The Scope field, also 4bits long, provides for 15 different possibilities, the most important are 1, 2, 4, 5, 8 and E, they indicate; Node, Link, Admin, Site, Organization or Global scope, respectively.

Now, let’s pay attention to the well-known multicast addresses table above. Notice that the 4th hex digit on all the addresses (except the last one) is a 2, this indicates (look at the picture above), that the scope for these addresses is link-local, that is, within the link/segment.

In contrast, look at the last well-known address, its 4th hex digit is a 5, indicating that the scope is site-local, the LAN, and it makes sense because, in this case, an NTP server controls the time settings for all network devices that use its services, not just the ones directly connected, on the same link.

Solicited-Node Address.
Before we get into how the Solicited-Node address is used, let’s find out about its format and where it comes from.

The Solicited-Node address is constructed by combining a predefined 104 bit prefix; FF02::1:FF and the 24 least significant bits from the interface’s Unicast address (or addresses).

For example, let’s say that the Unicast address in this case is a Link-Local address of FE80::AAAA:BBBB:123A:A321; the process will take the last 6 hex digits of the address, 3A:A321 (that’s 24 bits) and append them to the predefined FF02::1:FF/104 prefix, so the interface’s complete Solicited-Node address will be FF02::1:FF3A:A321.

The picture below demonstrates this:

Now, I will ask you a question and give you the answer on the following video, but try to answer the question before watching the video, so you can check your understanding. ;O)

Question: If the Link-Local address assigned to an interface is FE80::3B:ED49:CA22:1, what will be the Solicited-Node address linked to this Link-Local address?

What is a Solicited-Node address used for?
We said that when a host’s gets its Link-Local address (or any other Unicast address) it is automatically joined into the All-Nodes, All-Routers and the Solicited-Node multicast groups, this means that the host’s interface will specifically listen for traffic sent to this multicast groups. This is a very important point, the whole purpose for an interface to join a multicast group is because it needs to participate in this particular group activities according to what its configuration dictates, hence, it will actively listen for traffic from this group.

OK, right now we are going to talk specifically about the Solicited-Node multicast address. There are two address resolution processes in which the Solicited-Node address is used; these are MAC address (Layer 2) mapping and Duplicate Address Detection (DAD) which are part of the IPv6 Neighbor Discovery process.

If we think about IPv4 for a moment, it too has a process to map IPs to unknowns MACs, that process is called ARP and it is handle at L2, L3 is not involved at all.

Whenever a host needs to map an IP to an unknown MAC, an ARP Request message is sent to the broadcast MAC address FFFF:FFFF:FFFF and so every single node on the network receives and process this ARP Request, but only the intended target responds with an ARP Reply which includes the L2 info that the host that sent the ARP Request needs.

Now, with IPv6, there is no more L2 broadcast and there is no more ARP, the IPv6 process to map IPs to MACs is part of a process called Neighbor Discovery and it uses the L3 Solicited-Node address to accomplish this, L2 is not involved. In other words, the IPv6 process to map MACs was moved to from Layer 2 (Ethernet) to Layer 3 (IPv6).

I will explain the process in both scenarios (MAC address mapping and DAD) and this will give you a good understanding of how the Solicited-Node address is used:

Note: Both this processes use the messages Neighbor Solicitation (NS) and Neighbor Advertisement (NA). These messages are defined in the Neighbor Discovery Protocol (NDP) which we will talk about next.

• MAC address mapping:
  • The scenario is as follows; Host A and Host B are in the same network segment. Host A wants to communicate with Host B but it only knows Host B‘s L3, IPv6 address.

    So, to get Host B‘s L2 MAC address, Host A figures out Host B‘s Solicited-Node address (as it was explained before) and sends a Neighbor Solicitation (NS) message (similar to the ARP Request message on IPv4) to this address.

  • Host B receives this NS message and replies with a Neighbor Advertisement (NA) (similar to the ARP Reply message in IPv4) which contains its L2 info.

  • Host A receives the NA, adds Host B‘s L2 info into its Neighbor table (similar to the ARP table in IPv4) and it can, from now on, communicate directly with Host B on L2.

• Duplicate Address Detection (DAD):
  • To check if an IPv6 address is being used on the network, DAD will put together a Solicited-Node address using the predefined prefix of FF02::1:FF and the last six digits (24bits) of the IPv6 address it wants to use.
  • It will then send a NS message to this address.
  • If it receives an NA message as a reply, it means that this particular address is already being used.

Let’s do a packet capture using Wireshark to see if we can catch some of this concepts in action:

Neighbor Discovery Protocol.
We’ve already talked about some of the Neighbor Discovery processes such as DAD and MAC mapping. Let’s dig a bit deeper into the NDP, see what we find.

We’ve mentioned that in IPv4, ARP was used whenever a host needed to learn or match an unknown MAC address to a known IP address. Well, not only IPv6 no longer uses L2 broadcast messeges, it does not use ARP either, instead, it uses the Neighbor Discovery Protocol (NDP) which is part of the Internet Control Messege Protocol Version 6 (ICMPv6).

To accomplish the discovery of neighbors, NDP implements 5 messege types: Router Solicitation (RS), Router Advertisment (RA), Neighbor Solicitation (NS) and Neighbor Advertisment (NA) and a Redirect Messege.

Let me get the Redirect Message out of the way as it is very simple; when a router receives a message requesting information on how to get to a certain network, for example, and this router knows how to get there but there is another router that is directly connected to this particular network (or closer), it will reply with a Redirect Message saying, “hey, I know how to get to where you’re going, but here is a better gateway for you to use as well or from now on”. Thas it.

OK, on to the other message types. I will show you which types of Neighbor Discovery messages are used, where, and when, this will give you a good understanding of what they do:

• During SLAAC: When a host is trying to come up with its IPv6 address through Stateless Address AutoConfiguration, it uses the NDP messeges RS and RA to learn the IPv6 address’ prefix and prefix length (the Network ID) and also Default Router information.

• During DAD: Once a host learns or is assigned its IPv6 address, it needs to make sure that this address is not being used on the network by another host. This is accomplished through DAD, making use of the NS and NA messeges. I’ve explained the process before, refer to “What is a Solicited-Node address used for?”

• During MAC discovery: After DAD, the host has an IPv6 assigned and, as we explained before, when it needs to learn other host’s MAC, it uses the NS and NA messeges. This process was also explained before, refer to “What is a Solicited-Node address used for?”

• During Router Discovery: RS and RA messeges are sent by routers to discover other routers attached to the same link/segment. This is mostly used to get IPv6 addresing information for autoconfiguration.

StateLess Address AutoConfiguration – SLAAC.
So we’ve mentioned SLAAC many times before, let’s see what it is about.

So let’s take, for example, the NIC in your PC (or IPv6 device), when it comes on, the first thing that It needs to accomplish is getting an IP address, right? In this case it is going to be a Link-Local address, and to do this, this is what happens:

SLAAC uses the RS and RA message types defined in the Router Discovery process to learn the address prefix and prefix length, to construct the IPv6 address for an interface.

Look at the picture below. PC1 just turned on and it is connected to the same subnet as R1. To construct, in this case an IPv6 Global Unicat address, PC1 send out an RS message to the All-Routers multicast address of FF02::2 saying “Hey there, if there is a router out here, can you send me what I need to configure my IP address?” R1 will receive this RS and reply with an RA to the All-Nodes multicast address of FF02::1. This RA contains the info that PC1 needs to configure itself, mainly the prefix and its length (usualy /64), which in this case is 2001:DB8:1111:1::/64, and Default Router info.

When PC1 receives the RA, it puts together a GUA using the prefix information received in the RA and comes up with its own modified EUI-64 format Interface ID or, it can be manually configured… it is now ready to go out to play.

Picture taken from the book “Cisco CCNA R&S 200-120, OCG” by Wendell Odom.

Router Discovery.
A host can send an RS messege to the all-routers multicast address of FF02::2 to request information about the routers attached to the same link/segment. In turn, the routers respond to the RS with an RA of their own, either to the Unicast address of the host that sent the RS, or to the all-nodes multicast address FF02::1, either way, the host that originated the RS will recieve the RA.

If the RA is not sent in response to an RS (because periodically, routers send RAs on their own), it was unsolicited, the RA is sent only to the all-nodes address directly.

Picture taken from the book “Cisco CCNA R&S 200-120, OCG” by Wendell Odom.

Anycast Address.
Hey there… Let me ask you a question; what was one of the most unique characteristics of an IPv4 address?… Can you think of any unique answer?… no?… OK, I’ll tell you, the answer is that they have to be… yes, that’s right, unique!

Well then, let me give you this definitions of an IPv6 Anycast address: “An IPv6 Anycast address is any, Global or Unique-Local address, that has been assigned to more than one interface…”

I can almost see you scratching your heads now, and the funny part is that this is a true statement!

You are provably screaming at this moment, “How can this be, it is not possible. Surely there will be some sort of catastrophic event if we use the same Global or Unique-Local IPv6 address on more than one interface, Gerald lost his marbles”.. right?

Well, no I have not, assigning an IPv6 more than once is what you need to do to create an IPv6 Anycast address. See, because an Anycast address is used as a fail-over address, fault tolerance they call it. Let me give you an example.

Say you want to add an FTP server in your IPv6 network and this FTP server is very import, it feeds files that your employees use daily. So you think to yourself, “Wouldn’t be a good idea if I can have two FTP servers using the same IPv6 address, and traffic to this address could be routed to the nearest server?”… Think no more, if you are running IPv6 in your network, just assign the same Global or Unique-Local address to the DNS servers, and let the routing protocol control the traffic flow to them.

Here is a very important point regarding the fact that Anycast addresses are used for fault tolerance; While this is true, it doesn’t mean that ALL traffic is going to be flowing to just one of the servers in our example. Depending on where you are on the network, traffic is going to flow to either one server or the other.

A “Fault tolerance” system is not the same as a “backup” system, on a backup system, “something” waits for the other “something” to fail and then it kicks in. This is not the case here, both our servers are going to receive traffic, how much and from where is controlled by the routing protocol. If one server fails, traffic will be re-routed to the other server.

---

 

END OF PART II

References:

• Members of the Cisco Learning Network at https://learningnetwork.cisco.com/welcome -Thank you guys!

• CCNP R&S, ROUTE 300-101 OCG by Kevin Wallace, CCIE 7945

• https://tools.ietf.org/html/rfc4291

• https://docs.oracle.com/cd/E19683-01/817-0573/chapter1-26/index.html

• https://technet.microsoft.com/en-us/library/bb726995.aspx#EDAA

• http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

• http://ipv6.com

• https://technet.microsoft.com/en-us/library/cc757359(v=ws.10).aspx

• http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html