[#netfmdst]: Traffic destinations

Traffic Destinations

When network traffic is sent, the network traffic specifies a “destination”.

Communication Destination Types

[#unicast]: Unicast

“Unicast” traffic specifies a destination of a network address of another device. This “unicast” traffic is typically meant for a single device to be paying attention to the traffic. This is the simple, normal method of communication where one device contacts the network address that identifies another device.

(Alternatives may include multicast, anycast, and for IPv4: broadcast.)

This is rather similar in concept to one person speaking in a normal-volumed speaking voice to another nearby person. If another person device tries to listen to the conversation, that person might be able to hear the conversion just fine.

[#loopback]: loopback

There is a physical device called a “loopback plug” which simply receives network traffic, and then sends the same network traffic back to the network card which sent the traffic. Actually, the device might work on an even more basic level, but sending back the electrical signals that it receives. Such a device has been known to be useful when troubleshooting, perhaps by helping to test equipment.

This is similar in concept to a person covering his mouth so that nobody can hear him, and them mumbling in a fairly quiet voice. The person speaking may be able to hear and even understand what is being said; nobody else is likely to understand the sound.

Such “loopback” communications can also be implemented in software, and that can be very useful. For example, a computer that runs a “web server” software could also run a “web browser”. This web browser and the web server can communicate with each other. Both the web browser and the web server will act like they are communicating over a network, so they don't need a lot of special programming instructions to handle the fact that the communication is actually happening between programs on the same machine.

[#multicst]: Multicast

Another type of traffic is “multicast”. This is similar in concept to a person who speaks speaks loudly enough that everybody nearby can hear. If someone wants to receive a message, they can pay attention to the person in that corner. If a person wants to receive messages from multiple corners, that's fine too. To give an example of how that could work, a person could do this by placing devices in multiple corners of the room. Devices that could help with this may be a “walkie talkie”, a cordless phone, a wireless (“cell”) phone, or an audio recorder like an old-fashioned “tape recorder”. This would allow a person to be able to hear what is said by someone else who is in any of the corners where a listening device was placed.

[#brodcast]: Broadcast

“Broadcast” traffic is designed for all devices in a group to be listening to. This is similar to speaking loudly in front of a group, or maybe even using a megaphone (a combination microphone/speaker that a person holds in front of them). Anyone in the same room will be able to hear that message. However, still using this same analogy, barriers (like walls, or distance) may exist that prevent the sound from being heard.

Traffic sent to certain addresses are interpreted as “broadcast” signals, and so multiple devices that receive a copy of the message should check to see if the message is something to pay attention to. (In the most general concept, this could be clarified to say “all” devices hear the message. However, since broadcast traffic is typically limited/restricted, typically broadcast messages are only received by all of the devices on a single “broadcast domain”, which is commonly the same group of devices that are on a single subnet.)

[#anycast]: Anycast
Confusion during IPv6 traffic

Many people have taught about different traffic types, but have not been provided with a clearly understandable description of “anycast” traffic. People who have experienced such a thing might wish to get some more background ifnormation from a brief article about anycast confusion.

Despite all of this confusion, anycast actually is not really a terribly challenging concept.

What Anycast is

Anycast traffic is where a device sends information to a specific network address, and that traffic may be routed to different locations. (The traffic may be routed to a different network card/device on the same computer as another network card/device in the same computer, or to a different computer in the same room, or even to a different continent.)

Analogy information

This is somewhat similar to a person calling up a large company, and the company has the phone call go to a location where a staff member will speak to the caller. There are many possible staff members, maybe even in different cities.

The person who makes the phone call to the big company does not need to know where the staff member is located. All that person needs to know is that this person was able to use a telephone number and was able to talk to a person.

Anycast usage

To clear up some existing confusion, and to help people relax a bit more about the topic of “anycast”, it is worthwhile to start by looking at some cases where anycast is not needed.

When anycast support is not required

Anycast is not a technology that is required to implement just to have a basic network that fully provides useful services. Enabling support to communicate with anycast is not a crucial that requires sppecial efforts while making a small-scale network. Supporting the anycast concept does not need to be a high priority for simple introductory/test networks.

Computers that are not set up to be using anycast can still communicate with computers that do use anycast. When that happens, the computers that are not set up for anycast will typically have absolutely no indication that anycast is being used. That is fine; the computer that is not using anycast does not have any need to know that anycast is being used during any part of the process. As an example, some global root DNS servers use anycast. The DNS client does not need to know that the server's response is coming from an anycast address. During an average communication with an anycast DNS server, all that a client can typically determine from the communication is that the DNS client tried to communicate to the address, and it got a response.

(This is quite similar to how a person calling a company's tech support line doesn't need to know where the phone call is going to. All they need to know is that they were able to successfully communicate.)

Although anycast is often brought up during IPv6 training, that is because IPv6 implements anycast different than how anycast was commonly implemented in IPv4. Therefore, the topic is useful for people who know about IPv4 anycast. Anycast does not need to start being implemented just because people start supporting IPv6. No special support for anycast is required.

Benefits of anycast

Adding special support to implement anycast can provide benefits, like reliability or increased access speed from various parts of the globe. This redundancy may be an enhancement to an existing network, and so may be pursued at some point, but this is generally much less crucial than just getting initial basic functionality to become operational.

For people who are interested in more advanced handling of network traffic, especially related to concepts like increasing reliability and/or speed through the use of redundancy including multiple locations, anycast is a technology that could be a useful option. Anycast may require using a bit more advanced setup (compared to Unicast) on each device implementing anycast, as well as setting up some support for some routers. IETF BCP 126 - Operation of Anycast servers may be applicable/helpful.

Addresses used

There are addresses reserved for various purposes.


Put very simply (whether or not this fits any specific proper definition of Unicast), an IP address is generally considered to be a “unicast” address until it fits one of the other categories, like a “multicast” address. RFC 4291 section 2.4 has a small “table” (group of columns) which describes some of the types of addresses, and then describes “Global Unicast” as “everything else”.

Anycast addresses are not part of the table in RFC 4291 section 2.4 since they don't have their own unique address space; they are discussed in RFC 4291 section 2.4 in the sentence after that table.

RFC 4291 page 10 says that “Global Unicast” IPv6 addresses have an embedded MAC address, except for some of the “Global Unicast” IPv6 addresses that have the first three bits set to zero. This standard has been overridden by the newer “privacy” extensions.

For example, RFC 4291 section 2.5 is about Unicast addresses. RFC 5375: IPv6 Unicast Address Assignment Considerations.


Some network addresses have been reserved for loopback communication. One of these addresses is IPv6 ::1/128.

Technically, all of IPv4 127/8 is also reserved for “loopback” communications, although is, by far, the IPv4 address that has been supported more than any other. Most devices, including computers, probably support these addresses by default.

Some equipment, such as equipment using Cisco IOS, may support loopback communications but might not support those reserved addresses by default. So, a person needs to enable the available support before loopback addresses work.


To implement multicast, programs use protocols that were designed to support the multicast. A “listener” needs to decide to listen to traffic sent to a destination. (In the previous example, that is like a person placing a “listening” device in a corner of the room.)

There are also large ranges of IP addresses that have been reserved for use by multicast communications.

There are further details available for those who are trying to implement multicast. Those details are available in a more specific section about multicast details.

details about broadcast

Since broadcast traffic is typically used in many networks (because broadcast traffic is used by automatic address assignment protocols, and perhaps also some neighbor discovery methods), this is a pretty important concept for network technicians to be aware of. Some network traffic is likely to communicate using a network address that is intended to be used for broadcast traffic. More details about this “broadcast traffic” are available in the section about broadcast addresses.

Anycast addresses look like unicast

RFC 4291 section 2.6: “Anycast Addresses” notes, “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.” What this means is that the term “anycast address” refers to how the address is being used. If a list of addresses is being looked at, it is impossible to identify that any specific address in the list is anycast, and not unicast, just by looking at the address. Anycast addresses look just like unicast addresses.

So, unlike IPv4 broadcast addresses that fit certain patterns, or multicast addresses that fit within certain address ranges, there are no patterns to the numbers that will indicate that an address is an anycast address.

Addresses that are being used for unicast transmission are called unicast addresses. Addresses that are unused are also classified as unicast addresses. Anycast addresses are addresses that are used for anycast communications. So an address is not an “anycast address” until someone starts to use the address for anycast communications. Until someone starts using an address as an anycast address, the address is a unicast address.

After discussing what an anycast address looks like, the next sentence from RFC 4291 section 2.6 describes one way that an “anycast address” is made: “When a unicast address is assigned to more than one interface”, then the address is effectively “an anycast address”. This requires special configuration by the computers that have the NIC which is using the anycast address.

So, anycast refers to how an address is being used, and does not refer to any sort of numeric patterns in an IPv6 address.

Is it unicast?

Note: This is an extra section for people interested in technical standards, and who wish to be very precise with their usage of terminology. (This is beyond the scope of a basic tutorial.)

Clearly, addresses which are “multicast” addresses are not “unicast”. For some other addresses, there may be less clarity about whether they are officially “unicast” addresses.

Is Loopback Unicast?

Some people may consider loopback to be unicast, since there is just a single destination. That may be true. RFC 4291 section 2.4 clearly indicates that IPv6 ::1 is not part of IPv6 “Global Unicast”. However, that same section also indicates that “Link-Local unicast” is not part of the IPv6 “Global Unicast” group, so IPv6 “Global Unicast” does not contain absolutely all unicast addresses. The way that loopback is handled does seem to fit the definition of IPv6 “Unicast” that is provided in the second paragraph (which is the paragraph titled “Unicast”) of RFC 4291 section 2.

Is Anycast Unicast?

RFC 4291 keeps referring to anycast in addition to unicast, so this seems to imply that anycast addresses are not considered to be unicast addresses. This is especially implied by the second paragraph of RFC 4291 section 2.6 which says that assigning a unicast address to multiple NICs results in “turning it into an anycast address”, although that doesn't specify whether it stops being unicast. The way that the RFC was written seems to indicate that anycast addresses are a different category than unicast, so anycat addresses are not unicast. This conclusion is largely based on observation rather than a clearly defined statement that is being quoted.