WeOS
5.20.1

# IPv6 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.

Related Documentation

- Interface Configuration
- IGMP/MLD Snooping

## 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 `ipv6` context?

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`:

1. First `S1` will check if the MAC address of `S3` is already a known neighbor and if it is reachable. If it is, the ICMP echo request will be sent directly.

2. If the MAC address is not known, `S1` will send an NDP Neighbor Solicitation message to the Solicited-Node Multicast Address of `S3`. This message will be sent to the multicast address ff02::1:ff00:103.

3. `S3` will 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 that `S1` used 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.

4. `S1` will receive the NDP Neighbor Advertisement message and add the MAC address of `S3` to its list of known neighbors.

5. `S1` will now be able to send the ICMP echo request and insert the correct destination MAC address into the Ethernet frame.

« Previous Next »