The RFC describes a field called sin6_scope_id that can be used to specify an interface. RFC 3493 (Basic Socket Interface Extensions for IPv6) describes extensions to the socket interface to make it usable for IPv6. For example, a router may use the address fe80::1 on all interfaces as shown in Figure 1: For IPv6 link-local addresses, we can assume that this is not the case. To make it work, you need to explicitly select a local address on the desired interface (assuming that addresses are unique among interfaces). However, when that fails or when the user wants to override the kernel's decision, there is only an indirect way of specifying an interface. In most cases, the kernel can pick a suitable interface. Specifying an outgoing interface for a connection or a packet is a long standing problem with sockets API.
#Convert mac address to ipv6 link local series
The sockets API is a series of system calls, with names like socket(), bind(), connect(), send(), sendto(), recv(), recvfrom() , that were first introduced in version 4.2 of the BSD Unix operating system and later became a standard for almost all Unix-like operating systems. IPv6 link-local addresses would have been just a tiny detail of the whole IPv6 ecosystem if it was not for sockets API. The ethernet interface has an IPv4 address and two IPv6 addresses: This host has two interfaces, a loopback interface "lo", and an ethernet interface "enp0s5". IPv6 link-local addresses are used quite a lot.įor example, if you run "ip addr" on a Linux system, you will get something like this: $ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s5: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff inet 192.0.2.42/24 brd 192.0.2.255 scope global noprefixroute dynamic enp0s5 valid_lft 767sec preferred_lft 767sec inet6 2001:db8::8c28:c929:72db:49fe/64 scope global noprefixroute dynamic valid_lft 2591998sec preferred_lft 604798sec inet6 fe80::9656:d028:8652:66b6/64 scope link noprefixroute valid_lft forever preferred_lft forever Beyond that, IPv6 routers advertise link-local addresses to hosts (and other routers). Typically, a node will assign IPv6 link-local addresses to interfaces as soon as they have become available. In contrast, IPv6 link-local addresses are used next to other IPv6 addresses. So IPv4 link-local addresses show up when there are no other IPv4 addresses. However, there is a big difference: an IPv4 link-local address is typically assigned to an interface when DHCP fails to supply an address. IPv4 link-local addresses are taken from the prefix 169.254.0.0/16. In practice, only fe80::/64 is used.Īt first glance, IPv6 link-local addresses are similar to IPv4 link-local addresses, which are defined in RFC 3927 (Dynamic Configuration of IPv4 Link-Local Addresses). IPv6 link-local addresses are defined by RFC 4291 (IPv6 Addressing Architecture) and are covered by the prefix fe80::/10. There have been cases where routers would happily forward packets with a link-local source address. Packets with those addresses are not forwarded by routers. IPv6 link-local addresses are addresses that can be used to communicate with nodes (hosts and routers) on an attached link. In this article, we described how link-local addresses in IPv6, and specifically the '%eth0'-part of link-local addresses, can have an impact on RIPE Atlas measurements. And while this is true for most network operators, if you're a RIPE Atlas system programmer, you can run into interesting situations. Some people say IPv6 is "96 more bits, no magic". or, how RIPE Atlas measurement data just got a little bit more complex.