Difficult protocol. We automate the configuration of addresses in IPv6.

Hacker

Professional
Messages
1,044
Reaction score
834
Points
113
The content of the article
  • Link-local addresses
  • Unique host addresses
  • Router Advertisement (SLAAC)
  • DHCPv6
  • Configuring RA for DHCPv6
  • Configuring DHCPv6
  • Conclusion

In IPv4, there are only two options: statically configuring the address and default gateway, or DHCP. Today we will consider in detail what has replaced the classic DHCP from IPv4, how it works and how to live with it.
It should be remembered that a number of legacy technologies have finally disappeared in IPv6. In particular, it no longer has a broadcast, in all protocols it has been replaced by multicast and standardized multicast addresses: for example, ff02 :: 1 - all hosts in the segment, ff02 :: 2 - all routers.
In addition, not all auto-configuration mechanisms require a server or router.

Link-local addresses
Let's start with the concept of link-local addresses. They are allocated from the ff00 :: / 8 network and assigned to each network card at system boot. Unlike IPv4, they are mandatory in IPv6. This allows each device to have an address and communicate with other devices on the same network, regardless of whether the other configuration mechanisms have worked successfully or are enabled at all.

To send packets via multicast, you need a source address, but broadcast in IPv6, as we remember, does not. That is why having an address at the earliest stage of the download is especially important. In IPv4, with its massive use of broadcasting, this problem was "solved" by using the address 0.0.0.0 instead of the source or destination address.

An isolated network can theoretically work on some link-local addresses, from the point of view of hosts, they are indistinguishable from any others. The difference is only for routers, which are required by the standard not to forward packets from link-local in the destination address to other networks.
In practice, of course, the network is of little use without a connection to the Internet or other private networks, so let's move on to the mechanisms for setting public addresses.

This idea is not new: in IPv4 they already existed and stood out from the 169.254.0.0/16 network, but did not become widespread. One reason for this is that it is difficult to prevent address conflicts. Successful implementation of this idea requires reasonably reliable and practical ways to ensure that host addresses are unique. Let's see how this problem is solved in IPv6.

Unique host addresses
The standard network size for one link-layer segment in IPv6 is /64. That's a lot - 2 ^ 64 addresses! It would seem an absurd idea, but there are grounds for it. In 64 bits, you can put an existing globally unique identifier or generate a random one with a very low probability of conflicts.

Each factory MAC is guaranteed to be unique, so potential address conflicts can be avoided permanently by simply using the MAC address of a network card as part of its IPv6 address. This mechanism is called EUI-64 (Extended Unique Identifier). You can read more about it in the appendix to RFC 2373.

The size of the MAC address is 48 bits (six bytes), but we need 64, so it is divided into two parts of three bytes and the magic number 0xFFFE is inserted in the middle. In addition, the seventh bit of the MAC address is inverted - for globally unique it is set to zero by default.

Since link-local addresses are not routed, this approach does not create any privacy problems. It is obviously problematic for assigning public addresses - an attacker with access to traffic dumps or server logs can easily identify addresses from different networks - for example, from home, from work or a public Wi-Fi hotspot in a hotel - with one device and track movements user.

In the modern world, this is far from the biggest threat to privacy, so we will not consider the mechanisms for dealing with it in detail, but they do exist. One option, IPv6 privacy extensions, is described in RFC 3041. More importantly, IPv6, or rather NDP, the equivalent of ARP, has a built-in mechanism for detecting address collisions. The nodes first set the address to tentative and wait for an NDP packet to arrive with that address at the source. If such a packet arrives, the address is not activated.

Thus, the idea of auto-generated addresses applies to both local and public addresses. For configuration, only the network address is needed.

When configuring network cards, routers often allow you to manually specify only the network address, but leave the system to generate the host ID on its own: for example, interface Gi0; ipv6 address 2001:db8::/64 eui-64in Cisco IOS, set interfaces ethernet eth0 ipv6 address eui64 2001:db8::/64in VyOS. Hosts usually do not know the address of their network, so it must be obtained from an external source. This is where SLAAC (StateLess Address AutoConfiguration) comes into play through the router advertisement.

Router Advertisement (SLAAC)
It should be remembered that there is no ARP in IPv6 either, its role was taken over by NDP - Neighbor Discovery Protocol, described in RFC 4861. Unlike ARP, it is not a separate intermediate layer protocol between network and pipelines, but a subset of ICMPv6. This became possible precisely because link-local addresses are required: there cannot be hosts with an undefined address on the network.

It is significantly more functional than its predecessor, and among other things, it has a clear separation between the host and router roles. In IPv4, the router address could only be configured manually or obtained via DHCP, while in IPv6, routers send packets with information that they are ready to route host traffic, and at the same time tell them their address.
The same protocol is able to transmit to hosts the address of the network in which they find themselves so that they can configure their own addresses.
Let's try to configure this mechanism on GNU / Linux. We will use the radvd package to broadcast router advertisement. It is usually present in the repositories, and there should be no difficulties with its installation.

Suppose the eth0 of the router is configured with 2001: db8 :: 1/64. To begin, including IPv6 routing: sudo sysctl -w net.ipv6.conf.all.forwarding=1. Then we will write the following in /etc/radvd.conf:
Code:
interface eth0 {
    IgnoreIfMissing on;
    AdvManagedFlag off;
    AdvReachableTime 0;
    AdvSendAdvert on;
    AdvOtherConfigFlag off;
    prefix 2001: db8 :: / 64 {
        AdvOnLink on;
        AdvAutonomous on;
    };
};

After running in radvd, we will see the following picture in the traffic dump:
Code:
11: 36: 49.958369 IP6 (flowlabel 0xf840b, hlim 255, next-header ICMPv6 (58) payload length: 56) fe80 :: a00: 27ff: fe76: 3417> ff02 :: 1: [icmp6 sum ok] ICMP6, router advertisement , length 56
hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): 2001: db8 :: / 64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
source link-address option (1), length 8 (1): 08: 00: 27: 76: 34: 17

This is the router advertisement. Destination address ff02 :: 1 is the multicast address of all hosts. Note that the link-local address is used as the source address, not the global public address.

If the client host is Linux, then manual autotuning can be enabled using the option sudo sysctl -w net.ipv6.conf.eth0.accept_ra=1, although it is easier to do this through NetworkManager. After that, on the interface, you will see the automatically configured address, and in the ip -6 routeview, you will see a record default via fe80::a00:27ff:fe76:3417. All automatically configured routes in IPv6 use the link-local address as the gateway address, both on hosts and on routers with RIPng, OSPFv3, and often BGP.

Only routes and network addresses can be distributed via router advertisement. There are extensions for distributing DNS server addresses, but DHCPv6 is indispensable for distributing additional information like NTP servers or even arbitrary options.

DHCPv6
DHCPv6 is similar to its predecessor from IPv4, but differs in implementation details, and these differences must be kept in mind in order to configure it correctly.
Since the default route configuration in IPv6 is done automatically via a router advertisement, DHCPv6 does not provide this feature - do not look for it in the documentation.
In IPv4, hosts send a broadcast request to a DHCP server. In IPv6, even when a host is configured to use DHCPv6, it will not do so unless the router tells it that there is a server on the network.

Configuring RA for DHCPv6
Ours radvd.confhad an option AdvAutonomous on. According to RFC 4862, the autonomous flag means that there is no other mechanism for distributing settings on the network and hosts should configure their addresses based on the information about the network address from the packet: 2001:db8::/64in our case. If this flag is set to zero, then hosts ignore the network address information from router advertisement packets.

Whether hosts should send a request to a DHCPv6 server is determined by the Managed and OtherConfig flags. The Managed flag means that hosts must obtain addresses via DHCPv6. The OtherConfig flag means that hosts should use SLAAC, but additional configuration is available via DHCPv6.
Therefore, before configuring the DHCPv6 server, you need to correct /etc/radvd.confand register there again AdvManagedFlag onand AdvAutonomous offthen restart the service.

Configuring DHCPv6
The DHCPv6 server can be found in the ISC DHCP package, different distributions call it either dhcp-server, or isc-dhcp-server. The location of the config is distribution-dependent and is configured in the startup options, we will conventionally assume that it lies in /etc/dhcpd/dhcpd6.conf. Let's write the minimum config there for the test:
Code:
shared-network TEST {
    subnet6 2001: db8 :: / 64 {
        range6 2001: db8 :: 1000 2001: db8 :: 2000;
        option dhcp6.name-servers 2001: db8 :: 100;
    }
}

Now it remains to start the service, configure the option on the client to receive settings from DHCPv6 and see what happens.

Conclusion
In corporate networks, IPv6 is still the exception rather than the rule, but when it gets there, this article will hopefully help you be prepared for it.
 
Top