WeOSIPv6 Basic HowTo
About
This document aims to provide a basic guide on how to configure IPv6 on the device. The end goal is to have the device being accessible via IPv6 on the local network.
Following this should have the device being accessible via IPv6, using basic management services such as SSH, WEB and SNMP.
Note
This document will not cover anything related to routing, this is a basic guide to have the device accessible via IPv6 on the local network.
Warning
IPv6 routing is currently not supported on the device. As such, for now the device will only support IPv6 on the local network.
Introduction
IPv6 is the next generation of the Internet Protocol, which is designed to replace regular IPv4. IPv6 provides a much larger address space than IPv4, which is running out of addresses. However, this is not generally a problem for devices on a local network, as they can use private addresses.
As mentioned, this document will focus on the setup of IPv6 on the device for local network access. Where the main targeted scenario is the possibility to establish management connections to the device using IPv6.
We can consider a scenario, as presented in Figure 1 below, where we have a few switches with IPv6 enabled, that are connected to a number of hosts. The hosts are also IPv6 enabled and can communicate with the switches using IPv6.
Local Network: 2001:db8:1::/64
.--------. .--------. .--------.
| | | | | |
| S1 +--------------------+ S2 +--------------------+ S3 |
| | | | | |
'---+----' '---+----' '---+----'
|vlan1: .101 |vlan1: .102 |vlan1: .103
| | |
| | |
--+-------+-------+--- --+-------+-------+--- --+-------+-------+---
| | | | | | | | |
|.1 |.2 |.3 |.4 |.5 |.6 |.7 |.8 |.9
.-+--. .-+--. .-+--. .-+--. .-+--. .-+--. .-+--. .-+--. .-+--.
| H1 | | H2 | | H3 | | H4 | | H5 | | H6 | | H7 | | H8 | | H9 |
'----' '----' '----' '----' '----' '----' '----' '----' '----'
Figure 1: Basic IPv6 network scenario with switches and hosts.
The devices S1, S2 and S3 are the switches in the scenario that are
WeOS devices, and the ones that will be the focus of the later configuration
examples. The hosts H1 to H9 are just some example devices that are
connected to the switches. The network is using the IPv6 address range
2001:db8:1::/64.
The upcoming section and its subsections will provide some introductory information on IPv6 addresses. If this information is superfluous, feel free to skip ahead to the section covering the actual Configuration of the devices.
The Anatomy of an IPv6 Address
The subsequent subsections will provide some introductory information on IPv6 addresses, both how they differ compared to IPv4 addresses, as well as how they are structured. The goal is to provide basic foundational knowledge how to write and understand an IPv6 address, especially when coming from an IPv4 background.
Basic Differences Between IPv4 and IPv6
The following are just a few high-level differences between IPv4 and IPv6 addresses, in order to provide a basic understanding of the differences between the two.
| Feature | IPv4 | IPv6 |
|---|---|---|
| Address Length | 32 bits | 128 bits |
| Maximum Number of Addresses | 2^32, approximately 4.3 billion | 2^128, approximately 3.4 x 10^38, i.e. 340 undecillion. For practical purposes, it is essentially infinite. |
| Address Groups | 4 groups of 3 decimal digits [0-9] | 8 groups of 4 hexadecimal digits [0-9A-F] |
| Group Separator | Dots (.) | Colons (:) |
| Leading Zeros | Can be omitted | Can be omitted |
| Consecutive Zeros | Can NOT be replaced | Can be replaced by double colons (::) |
| Fragmentation | Routers are allowed to fragment packets. | Routers are NOT allowed to fragment packets, instead the end devices are solely responsible for any fragmentation. |
| Checksum | Included in the header | Removed from the header. |
Table 1: Basic differences between IPv4 and IPv6 addresses.
IPv6 Address Format
Writing an IPv6 address can be a bit confusing at first, if you are mostly used to working with IPv4 addresses, but it is quite simple once you get the hang of it. It is in some ways similar to how a MAC address is written, by using colons to separate the groups and using hexadecimal digits.
As mentioned, an IPv6 address is much larger than an IPv4 address, at 128 bits compared to 32 bits. This means that an IPv6 address is divided into 8 groups of 4 hexadecimal digits, separated by colons. A basic example of a full IPv6 address would be:
2001:0db8:0001:0002:7357:0000:0000:0001
However, since there are a lot of zeros in the above address, it is possible to omit the leading zeros, as such:
2001:db8:1:2:7357:0:0:1
Furthermore, it is also possible to replace consecutive groups of zeros with double colons, as such:
2001:db8:1:2:7357::1
Using some of these methods can make the address a bit shorter and easier to read.
Note
Double colons can only be used once in an address, as it would otherwise be
impossible to determine how many groups of zeros were replaced. For instance,
the address 2001:db8::1::1 is not a valid address, as it is impossible to
determine how many groups of zeros were replaced by the double colons.
An IPv6 address is typically divided into three parts, as shown in Figure 2 below, where the parts are as follows:
- Global Routing Prefix: This is the part of the address that is used to route the packet to the correct network.
- Subnet ID: This is the part of the address that is used to identify the local network.
- Interface ID: This is the part of the address that is used to identify the a specific network interface on the local subnet.
128 Bits in Total
◄────────────────────────────────────────────────────────────────────►
◄───────N Bits────────► ◄─M Bits──► ◄─────────128-N-M Bits───────────►
┌───────────────────────┬───────────┬──────────────────────────────────┐
│ Global Routing Prefix │ Subnet ID │ Interface ID │
└───────────────────────┴───────────┴──────────────────────────────────┘
Typically the Global Routing Prefix is 48 bits, the Subnet ID is 16 bits and
the Interface ID is 64 bits. So in this case N=48, M=16 and the Interface ID
is 64 bits.
Figure 2: Basic structure of an IPv6 address. The address is divided into three parts, the Global Routing Prefix, the Subnet ID and the Interface ID.
Based on the structure in Figure 2, the addresses for the devices S1, S2 and S3 in the scenario presented in Figure 1 would be:
S1: 2001:0db8:0001:0000:0000:0000:0000:0101/64
S2: 2001:0db8:0001:0000:0000:0000:0000:0102/64
S3: 2001:0db8:0001:0000:0000:0000:0000:0103/64
◄────────────► ◄──► ◄─────────────────►
A B C
A: Global Routing Prefix - 48 bits
B: Subnet ID - 16 bits
C: Interface ID - 64 bits
Figure 3: IPv6 addresses for devices S1, S2 and S3 in the scenario presented in Figure 1. This is a breakdown what each part of the address represents.
IPv6 Address Types
In IPv6 there are a number of different address types, the most common ones are:
- Unicast Address: An address that identifies a single interface.
- Multicast Address: An address that identifies a group of interfaces.
- Anycast Address: An address that identifies a group of interfaces, where the packet is sent to the nearest interface in the group.
Note
One thing to take note of is that the IPv6 does not have a broadcast address, as IPv4 (255.255.255.255) does. Instead, multicast must be used to reach all devices on the local network.
IPv6 Unicast
The different types of unicast addresses are displayed in the table below:
| Address Type | Range | Description | Example |
|---|---|---|---|
| Global Unicast | 2000::/3 | A routable unicast address, similar to a public IPv4 address. | 2001:db8:1::1 |
| Link-Local | fe80::/10 | An address used to communicate with other devices on the local network. | fe80::5054:ff:fe12:3450 |
| Loopback | ::1/128 | An address used to communicate with the local device itself. | ::1 |
| Unique Local | fc00::/7 | An address that is similar to a private IPv4 address, not intended to be routed on the Internet. | fc00:1::1 |
| Embedded IPv4 | ::/80 | An address that embeds an IPv4 address. | 2001:db8:c000:221:: |
Table 2: Different types of IPv6 Unicast addresses.
The most common type will be the Global Unicast address, which is the equivalent of a public IPv4 address. The Link-Local address is also important. It will always be assigned to any interface that is configured with any other type of IPv6 address implicitly, even if not explicitly specified. It is required for some IPv6 features to work correctly.
When assigning a Unicast address to an interface a prefix length will also be
assigned, if no prefix length is specified, the default is /64. This is the
most common prefix length used for IPv6 addresses, as it is the smallest prefix
length that is supported by all IPv6 devices. The prefix length is used to
determine the size of the network that the address is assigned to. Assigning the
prefix length is pretty much the same as using the CIDR notation for IPv4.
IPv6 Multicast
Same as for IPv4, IPv6 also has multicast addresses. Multicast addresses are used to send frames to multiple destinations at the same time.
Multicast addresses in IPv6 will always be in the range ff00::/8. This gives the total range of multicast addresses in IPv6 as ff00:0000:0000:0000:0000:0000:0000:0000 - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. This can be seen as equivalent to the IPv4 multicast range 224.0.0.0/4.
Tip
It is good reminder that if you see an address that starts with ff, it is a multicast address.
The IPv6 multicast address has a bit more advanced structure than the IPv4 multicast address. Each multicast address have certain bits that are reserved for special purposes. The initial part of the multicast address is divided into the following parts, as can also be seen in Figure 4 below:
- The first 8 bits are always set to ff.
- The next 4 bits are the so called Flags field.
- The last 4 bits are the so called Scope field.
- The remaining 112 bits are the Group ID.
128 Bits in Total
◄──────────────────────────────────────────────────────────────────────────►
◄───────8 Bits────────► ◄─4 Bits─► ◄─4 Bits─► ◄─────────112 Bits───────────►
┌───────────────────────┬──────────┬──────────┬──────────────────────────────┐
│ 11111111 │ Flags │ Scope │ Group ID │
└───────────────────────┴──────────┴──────────┴──────────────────────────────┘
Flags: 0RPT
Figure 4: Basic structure of an IPv6 multicast address. The address is divided into three parts, the Flags field, the Scope field and the Group ID, with the initial part always set to ff.
The Flags field is divided into the following parts:
| Flag | When Set to 1 | When Set to 0 |
|---|---|---|
| R (Rendezvous) | Rendezvous Point is embedded in the address. | Rendezvous Point is not embedded in the address. |
| P (Prefix) | Prefix Based. | Not Prefix Based. |
| T (Transient) | Dynamic, an administratively assigned address. | Permanent, a predefined multicast address (Assigned by IANA). |
Table 3: The Flags field in an IPv6 multicast address.
The scope field is divided into the following parts:
| Value | IPv6 Address | IPv4 Counterpart | Scope | Description |
|---|---|---|---|---|
| 0x1 | ffx1::/16 | - | Interface-Local | The scope is limited to the local interface, usable for loopback. |
| 0x2 | ffx2::/16 | 224.0.0.0/24 | Link-Local | The scope is limited to the local link. Frames within this scope may not be routed. |
| 0x4 | ffx4::/16 | - | Admin-Local | Administratively defined scope. |
| 0x5 | ffx5::/16 | - | Site-Local | The scope is limited to the local site. |
| 0x8 | ffx8::/16 | 239.192.0.0/14 | Organization-Local | The scope is limited to the local organization. |
| 0xE | ffxe::/16 | 224.0.1.0-238.255.255.255 | Global | The scope is global. Allowed to be routed on the Internet. |
Table 4: The Scope field in an IPv6 multicast address.
As an example, the multicast address ff02::1 is a non-transient (Predefined),
link-local multicast address.
As another example, we can take the ND multicast address for the IPv6 address
2001:db8:1::101 for S1, that would be ff02::1:ff00:101. Similar to the one
above it is a non-transient, link-local multicast address.
Well Known IPv6 Multicast Addresses
There are some well known IPv6 multicast addresses that are reserved for different purposes. In the table below we have a list of some of the well known IPv6 multicast addresses:
| Multicast Address | Description |
|---|---|
| ff02::1 | All Nodes |
| ff02::2 | All Routers |
| ff02::5 | OSPFv3 Routers |
| ff02::6 | OSPFv3 DR Routers |
| ff02::8 | IS-IS Routers |
| ff02::9 | RIP Routers |
| ff02::a | EIGRP Routers |
| ff02::d | PIM Routers |
| ff02::12 | VRRP Routers |
| ff02::16 | MLDv2 Reports |
| ff02::1:2 | All DHCP Servers and Relay Agents |
| ff02::1:3 | All LLMNR Nodes |
| ff0x::fb | mDNSv6 |
| ff0x::101 | Network Time Protocol (NTP) |
| ff0x::181 | Precision Time Protocol (PTP) version 2 message, except peer delay measurement |
| ff02::6b | Precision Time Protocol (PTP) version 2 peer delay measurement |
Table 5: Some well known IPv6 multicast addresses.
IPv6 Multicast MAC Address Representation
Same as for IPv4 multicast, IPv6 multicast addresses also have a corresponding
MAC address. The MAC address is calculated by taking the last 32 bits of the
IPv6 multicast address and appending them to the prefix 33:33. In figure 5
below, we have an example of how the MAC address is calculated for the IPv6
multicast address ff02::1.
96 bits 32 bits
◄──────────────────────────────►◄─────►
IPv6 Multicast: ff02:0000:0000:0000:0000:0000:0000:0001
───┬───
│
│ Copy
▼
───────
MAC Address: 33:33:00:00:00:00:00:01
Figure 5: Calculation of the MAC address representation for the IPv6 multicast address ff02::1.
The IPv6 multicast addresses need to have corresponding MAC addresses in order to be insertable into the hardware’s Forwarding Database (FDB). This is necessary to ensure that the multicast traffic can be forwarded correctly on the network, when the multicast traffic is not flooded to all ports, e.g. when MLD snooping is enabled.
Configuration
Adding an IPv6 address to a WeOS device is quite straightforward and it is done
in essentially the same way as for IPv4. Configuration of any type of IP address
is always done in the interface context. When an IPv4 address is configured the
inet command is used, for IPv6 the inet6 command is used instead.
As such, the devices S1, S2 and S3 in the scenario presented in Figure 1 are configured in the following way:
S1:/#> configure S1:/config#> iface vlan1 S1:/config/iface-vlan1/#> inet6 static 2001:db8:1::101/64
S2:/#> configure S2:/config#> iface vlan1 S2:/config/iface-vlan1/#> inet6 static 2001:db8:1::102/64
S3:/#> configure S3:/config#> iface vlan1 S3:/config/iface-vlan1/#> inet6 static 2001:db8:1::103/64
Note
If we would not have specified the prefix length in the above commands, the
default prefix length would have been /64 anyway, since it is the default
value. However, it is possibly good practice to always specify the prefix
length, to ensure that it is always correct, since this behavior could
differ between different vendors.
By default IPv6 is globally disabled on the device. This means that even if an
IPv6 address is configured on an interface, it will not be active until IPv6 is
globally enabled. This option is located under the ipv6 context. Therefore,
to enable IPv6 on the device, the following command must be executed for each
of the devices:
S1:/#> configure S1:/config#> ipv6 S1:/config/ipv6/#> enable
S2:/#> configure S2:/config#> ipv6 S2:/config/ipv6/#> enable
S3:/#> configure S3:/config#> ipv6 S3:/config/ipv6/#> enable
At this point, when the configuration is applied on the devices, they should now
have the IPv6 addresses added to the selected interfaces. In order to verify this
the show iface command can be used in the exec context, it should look something
like this:
S1:/#> show iface
INTERFACE OPER ADDRESS/LENGTH SOURCE MAC/PTP ADDRESS
lo UP 127.0.0.1/8 static 00:00:00:00:00:00
vlan1 UP 2001:db8:1::101/64 static 52:54:00:12:34:50
fe80::5054:ff:fe12:3450/64 link-local
Note
Observe that we have also had a link-local address added to the
interface as well, even though it was not explicitly configured. This will
always be implicitly added to the interface for any inet6 method that
is configured. Of course it is possible to configure a link-local address
explicitly as well, using inet6 link-local.
Ensure Snooping or Flooding of Unknown Multicast is Enabled
Currently, both of these settings should be enabled by default. However, it is still beneficial to know where to find these specific settings, in case they are disabled or need to be changed. For more information on why these settings are important, please refer to the section on IPv6 NeighborDiscovery below.
Enabling MLD Snooping
For some more detailed information why MLD snooping is important for IPv6, please refer to the subsection on MLD Snooping under the IPv6 Neighbor Discovery section.
MLD snooping shares the same configuration as IGMP snooping, i.e. they both use
the same settings. Currently all of these shared settings are located under the
ip context and not under the ipv6 context. To enable MLD snooping, the following
command must be executed:
S1:/#> configure S1:/config#> ip S1:/config/ip/#> multicast-snooping
In addition multicast-snooping can also be enabled/disabled on a per VLAN basis.
For instance, to enable MLD snooping on VLAN 1, the following command must be executed:
S1:/#> configure S1:/config#> vlan 1 S1:/config/vlan-1/#> multicast-snooping
For more information on other relevant multicast snooping settings, please refer to the IGMP/MLD Snooping documentation.
Enabling Flooding of Unknown IPv6 Multicast Addresses
For some more detailed information why flooding of unknown IPv6 multicast addresses is important for IPv6, please refer to the subsection on Flooding of Unknown IPv6 Multicast Addresses under the IPv6 Neighbor Discovery section.
The configuration for flooding of unknown IPv6 multicast addresses, shares the
same configuration as flooding of unknown IPv4 multicast addresses. This setting
is located under the ip context and not under the ipv6 context. To enable
flooding, the following command must be executed:
S1:/#> configure S1:/config#> ip S1:/config/ip/#> multicast-flood-unknown all S1:/config/ip/#> show multicast-flood-unknown ALL S1:/config/ip/#>
The setting multicast-flood-unknown operates per port on the device. In the
command above we did not specify any port, we instead used the keyword all,
which means that the setting will be applied to all ports.
If we want to enable this setting for a specific port or a range of ports, we can do so by specifying the port or range of ports in the command. However, the command itself is additive, meaning that we must first remove any other ports that we do not want to have this setting enabled on, before adding the new ports. For instance, to enable flooding of unknown multicast on port eth1, the following command must be executed:
S1:/#> configure S1:/config#> ip S1:/config/ip/#> no multicast-flood-unknown S1:/config/ip/#> multicast-flood-unknown eth1 S1:/config/ip/#> show multicast-flood-unknown eth1 S1:/config/ip/#>
Or in order to apply it to a range of ports, for instance eth1 to eth5, the following command must be executed:
S1:/#> configure S1:/config#> ip S1:/config/ip/#> no multicast-flood-unknown S1:/config/ip/#> multicast-flood-unknown eth1..eth5 S1:/config/ip/#> show multicast-flood-unknown eth1..eth5 S1:/config/ip/#>
For some more information on the multicast-flood-unknown setting, please refer to the
IGMP/MLD Snooping documentation page, the command description
is located there.
Testing
At this point, the configured switches should be reachable via IPv6. We can test this by simply pinging the switches from any of the hosts on the network. For instance, we could try and ping the switches S2, S3 and hosts H4, and H7 from S1:
S1:/#> ping 2001:db8:1::102 Press Ctrl-C to abort PING 2001:db8:1::102(2001:db8:1::102) 56 data bytes 64 bytes from 2001:db8:1::102: icmp_seq=1 ttl=64 time=0.838 ms S1:/#> ping 2001:db8:1::103 Press Ctrl-C to abort PING 2001:db8:1::103(2001:db8:1::103) 56 data bytes 64 bytes from 2001:db8:1::103: icmp_seq=1 ttl=64 time=0.838 ms S1:/#> ping 2001:db8:1::4 Press Ctrl-C to abort PING 2001:db8:1::4(2001:db8:1::4) 56 data bytes 64 bytes from 2001:db8:1::4: icmp_seq=1 ttl=64 time=0.838 ms S1:/#> ping 2001:db8:1::7 Press Ctrl-C to abort PING 2001:db8:1::7(2001:db8:1::7) 56 data bytes 64 bytes from 2001:db8:1::7: icmp_seq=1 ttl=64 time=0.838 ms S1:/#>
It should at this point also be possible to access the switches via SSH, WEB and SNMP, if these management services are enabled on the devices. For instance, we can try to SSH into S2 from S1:
S1:/#> ssh 2001:db8:1::102 admin@2001:db8:1::102's password: S2:/#>
TroubleShooting
If the device has been configured with an IPv6 address, but it is not active on the configured interface, check the following:
- Is IPv6 globally enabled on the device, under the
ipv6context?
If any of the configured devices on the network have issues reaching each other, check the following:
- Is MLD snooping enabled on the device?
- Is flooding of unknown IPv6 multicast addresses enabled on the device?
If MLD is in use, the joined groups can be checked on the device to ensure that
the correct groups are joined. This can be done by using the show ipv6 mld command:
S1:/#> show ipv6 mld Interface(s) INTERFACE STATE ADDRESS V QUERIER QUERIER ADDRESS QUERY TIMER UPTIME vlan1 up fe80::edb:c6ff:fef3:0 2 other fe80::e6f:eeff:fe8b:0 - 00:00:45.054 Group(s) INTERFACE GROUP VERSION UPTIME vlan1 ff02::16 2 00:00:43.464 vlan1 ff02::1:ff00:1 2 00:00:42.220 vlan1 ff02::1:ff00:4 2 00:00:33.050 vlan1 ff02::1:ff00:7 2 00:00:02.217 vlan1 ff02::1:ff00:101 2 00:00:43.464 vlan1 ff02::1:ff00:102 2 00:00:29.075 vlan1 ff02::1:ff00:103 2 00:00:28.706 vlan1 ff02::1:ff15:0 2 00:00:42.220 vlan1 ff02::1:ff73:0 2 00:00:02.217 vlan1 ff02::1:ff85:0 2 00:00:33.050 vlan1 ff02::1:ff8b:0 2 00:00:29.075 vlan1 ff02::1:ffc8:0 2 00:00:28.706 vlan1 ff02::1:fff3:0 2 00:00:43.464 Join(s) GROUP SOURCE STATE LASTSEEN NONTRKSEEN CREATED On interface vlan1: ff02::16 * JOIN 00:00:00 - 00:00:43 ff02::1:ff00:1 * JOIN 00:00:07 - 00:00:42 ff02::1:ff00:4 * JOIN 00:00:00 - 00:00:33 ff02::1:ff00:7 * JOIN 00:00:02 - 00:00:02 ff02::1:ff00:101 * JOIN 00:00:37 - 00:00:43 ff02::1:ff00:102 * JOIN 00:00:00 - 00:00:29 ff02::1:ff00:103 * JOIN 00:00:01 - 00:00:28 ff02::1:ff15:0 * JOIN 00:00:07 - 00:00:42 ff02::1:ff73:0 * JOIN 00:00:02 - 00:00:02 ff02::1:ff85:0 * JOIN 00:00:00 - 00:00:33 ff02::1:ff8b:0 * JOIN 00:00:00 - 00:00:29 ff02::1:ffc8:0 * JOIN 00:00:01 - 00:00:28 ff02::1:fff3:0 * JOIN 00:00:37 - 00:00:43
To check the currently identified IPv6 neighbors on the device, the show ipv6 neighbors
command can be used:
S1:/#> show ipv6 neighbors IPv6 Neighbors ADDRESS INTERFACE MAC STATE fe80::e12:6fff:fe73:0 vlan1 0c:12:6f:73:00:00 DELAY 2001:db8:1::102 vlan1 0c:6f:ee:8b:00:00 REACHABLE fe80::e6f:eeff:fe8b:0 vlan1 0c:6f:ee:8b:00:00 REACHABLE 2001:db8:1::103 vlan1 0c:ad:25:c8:00:00 REACHABLE 2001:db8:1::7 vlan1 0c:12:6f:73:00:00 REACHABLE fe80::ead:25ff:fec8:0 vlan1 0c:ad:25:c8:00:00 REACHABLE
IPv6 Neighbor Discovery
Same as for IPv4, IPv6 must have a way to discover the MAC address of a device on the local network. In IPv4, this is done using ARP (Address Resolution Protocol). IPv6 uses a similar mechanism called Neighbor Discovery Protocol (NDP).
In IPv4 ARP uses broadcast messages to discover the MAC address of other devices on the local network. Since IPv6 does not support broadcast, NDP uses multicast messages to discover the MAC address of other devices on the local network. However, the NDP messages are not sent to a common multicast address, but to a specific multicast address based on the target IPv6 address. This means that all of these different multicast addresses must be able to reach the intended device(s).
This calculated address is referred to as the Solicited-Node Multicast Address. It
is calculated by taking the last 24 bits of the target IPv6 address and appending
them to the prefix ff02::1:ff00:0/104. This will result in a multicast address
that is, in most cases, unique for each target IPv6 address. As en example,
given the IPv6 address of the devices S1, S2 and S3 in the scenario presented
in Figure 1, the Solicited-Node Multicast Address would be:
| Device | IPv6 Address | Solicited-Node Multicast Address |
|---|---|---|
| S1 | 2001:db8:1::101 | ff02::1:ff00:101 |
| S2 | 2001:db8:1::102 | ff02::1:ff00:102 |
| S3 | 2001:db8:1::103 | ff02::1:ff00:103 |
Table 6: Solicited-Node Multicast Addresses for devices S1, S2 and S3 in the scenario presented in Figure 1.
Just to illustrate the calculation of the Solicited-Node Multicast Address, we
use the IPv6 address of device S1 from the above table, in Figure 6 below.
104 bits 24 bits
◄──────────────────────────────►◄─────►
S1 IPv6 Address: 2001:0db8:0001:0000:0000:0000:0000:0101
───┬───
│
│ Copy
▼
───────
S1 ND Multicast: ff02:0000:0000:0000:0000:0001:ff00:0101
Figure 6: Calculation of the Solicited-Node Multicast Address for device S1. The addresses have been expanded to their full 128 bits for clarity.
Therefore, in order to ensure that any device on the network can correctly perform a neighbor discovery, the switches must be able to forward any potential Solicited-Node Multicast Address correctly. To do this the devices must have at least one of the following features enabled:
- Flooding of Unknown IPv6 Multicast Addresses. This setting is enabled by default.
- MLD Snooping. This setting is also enabled by default.
One of the above must always be enabled to ensure that the devices can correctly perform neighbor discovery. If not, the required multicast addresses will not be reachable and the devices will not be able to communicate with each other. As mentioned, the default is that both of these features are enabled, meaning that there is no issue having them both enabled at the same time, it is actually recommended.
Flooding of Unknown IPv6 Multicast Addresses
With flooding of unknown IPv6 multicast addresses enabled, the switch will, as it sounds, flood all unknown IPv6 multicast addresses to all ports, or specific ports if wanted. Doing this will ensure that any ND messages will always be able to reach the intended device(s) on the local network.
The drawback of this is that all multicast traffic will always be flooded to all ports, or the specified individual flood ports. When we do this we essentially treat the multicast traffic as broadcast traffic, somewhat defeating the purpose of using multicast, in the sense that we are not limiting the traffic to only the intended devices. For this we should of course need MLD snooping enabled.
However, it is usually far more important that communication works, than to save bandwidth, as long as said bandwidth is enough to handle the intended traffic. But naturally, if the amount of multicast traffic on the network is increased, there is going to be a point where the network starts to get congested, and having this feature enabled could potentially make the congestion worse.
Note
As long as the above issue with bandwidth is not a problem, it is recommended to have this feature enabled. This will ensure that the devices can always perform neighbor discovery and communicate with each other.
If this feature is disabled, the switch will not flood unknown IPv6 multicast. In this scenario, we must instead ensure that MLD Snooping is enabled if we want to ensure that the devices can correctly perform neighbor discovery.
MLD Snooping
MLD snooping is the IPv6 equivalent of IGMP snooping for IPv4. If we do not flood unknown IPv6 multicast addresses, we must rely on MLD snooping to ensure that all the ND multicast addresses groups on the local network are joined correctly. Every single interface with an IPv6 address must join the correct multicast group associated with its configured IPv6 address. As soon as an interface has an IPv6 address configured, it will automatically join the correct multicast group.
The above, goes for any IPv6 address, including link-local addresses. This means that if a static address is configured on an interface, a bare minimum of two ND multicast groups will be joined.
Even though any IPv6 enabled device must initially send an MLD report to join the correct multicast group, a MLD querier is necessary to ensure that the relevant groups will continue to be joined. The MLD querier will periodically send MLD queries to ensure that the groups are still required. If no querier is present, the groups will eventually time out and be removed. By default the WeOS devices are eligible to be elected as the MLD querier, when snooping is enabled.
For more information on MLD snooping, please refer to the IGMP/MLD Snooping.
Tip
Since the querier should be aware of all the multicast groups on the network, checking the joined groups on the querier can be a good way to verify that the MLD snooping is working correctly, and that all expected groups are joined.
Warning
In very large network topologies that have a multitude of IPv6 addresses configured across many devices, the number of extra multicast groups that must be joined for all Solicited-Node Multicast Addresses can become quite large. Each of these groups will have their MAC equivalent address inserted into the hardware’s Forwarding Database (FDB). The more entries that are present in the FDB, the more likely it is that a MAC address collision will occur. This can lead to a situation where the switch fails to add the MAC address to the FDB, resulting in the ND messages not being able to reach the intended device(s).
Therefore, if IPv6 is to be utilized in a larger network with many IPv6 addresses present, it is recommended to also have flooding of unknown IPv6 multicast addresses enabled. This will ensure that the ND messages always reach the intended device(s), even if there is a MAC address collision in the FDB.
Combining MLD Snooping and Flooding of Unknown IPv6 Multicast Addresses
As mentioned, the default is that both of these features are enabled. This ensures that multicast traffic should always be able to reach the intended device(s), even if there is a MAC address collision in the FDB.
The resulting behavior in this scenario is that unknown multicast traffic, i.e. multicast traffic that is not part of a joined group, will be flooded to all ports. Once an intended receiver joins a given multicast group, the group will now be “known” and the traffic should only be forwarded to the ports towards the intended receivers.
Therefore, in this scenario, the amount of unnecessarily flooded multicast traffic is essentially minimized when any intended receiver joins a given multicast group.
Address Resolution Example
As an example, let’s say that device S1 wants to ping device S3, on its
statically configured IPv6 address 2001:db8:1::103. The following steps will
be taken to resolve the MAC address of device S3:
-
First
S1will check if the MAC address ofS3is already a known neighbor and if it is reachable. If it is, the ICMP echo request will be sent directly. -
If the MAC address is not known,
S1will send an NDP Neighbor Solicitation message to the Solicited-Node Multicast Address ofS3. This message will be sent to the multicast address ff02::1:ff00:103. -
S3will receive the NDP Neighbor Solicitation message and respond with an NDP Neighbor Advertisement message. This message will set the destination MAC address to the MAC thatS1used to send the NDP Neighbor Solicitation message. Similarly, the destination IPv6 address will be set to the source IPv6 address of the NDP Neighbor Solicitation message, 2001:db8:1::101. -
S1will receive the NDP Neighbor Advertisement message and add the MAC address ofS3to its list of known neighbors. -
S1will now be able to send the ICMP echo request and insert the correct destination MAC address into the Ethernet frame.