Only a few days remain before the start of the new cohort for the course from OTUS. In this regard, we would like to share with you a translation of useful material on the topic.
A series of blog articles dedicated to tips and recommendations for troubleshooting related to IPv6 ping (ICMPv6 Echo Request/Echo Reply)
Please note that I am using Linux (specifically, Fedora 31), but I hope the ping command syntax for other operating systems will be quite similar.
🥇CEMU emulator 1.17.2 has been released: performance improvements and bug fixes | ProHoster
The first and simplest piece of advice is to ping all IPv6 nodes on the channel.
IPv6 uses multicast addresses for all types of "one-to-many" communication. There are no broadcast IPv6 addresses. This distinguishes IPv6 from IPv4, where there are several types of broadcast addresses, like the "limited broadcast" address 255.255.255.255 [RFC1122].
However, there is an "all-nodes multicast" IPv6 address, so we will use it to ping all IPv6 nodes on the channel. (The "broadcast" address is actually just a specially named multicast address that represents a multicast group including all nodes. Note that, for instance, the group bit in multicast addresses is included in broadcast addresses at the link layer).
All-nodes multicast IPv6 address for the channel: ff02::1. ff denotes a multicast IPv6 address. The next 0 is part of the flag with unset bits.
Next, 2 defines the multicast group scope. Unlike multicast IPv4 addresses, multicast IPv6 addresses have a scope. The scope value indicates the part of the network where multicast packets are allowed to be forwarded. Once a packet reaches the boundary of the specified scope, it must be discarded, regardless of whether its hop count is non-zero. Of course, if the hop count reaches zero before hitting the specified multicast group boundary, it is immediately dropped as well. Here is the complete list of multicast scopes for IPv6.
Finally, ::1 indicates the all-nodes multicast group.
About the address ff02::1 it should be noted that it is ambiguous. On an IPv6 node with multiple interfaces, such as a router or multi-homed host, in the address ff02::1 There is nothing to specify which interface to send ICMPv6 echo requests to or wait for ICMPv6 echo replies when they arrive. ff02::1 It is valid and can be used on any of the interfaces and channels attached to a multi-interface node.
Therefore, when we ping all IPv6 nodes on the channel, we need to somehow also inform the utility ping for IPv6, which interface to use.
Defining interfaces is a command-line option.
As we have seen, the all-nodes multicast address we want to use — ff02::1 — does not provide any information about which interface to send and receive ICMPv6 echo request and reply packets.
So, how do we specify the interface that will be used for multicast address space or unicast Link-Local addresses?
The first and most obvious way is to provide it as a parameter for the application we are using.
For the utility ping we provide it through the option -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]With this all-nodes multicast ping, we received responses from 6 IPv6 nodes. The responses came from the Link-Local IPv6 addresses starting with the prefix fe80::/10.
To ping do not continue to send ICMPv6 echo requests indefinitely until we interrupt it, we generally specify the number of packets to send via the -c option. However, this also does not allow ping to accept and display more than one ICMPv6 echo reply when sending the multicast ICMPv6 echo request. Instead, we used the -w option to indicate that ping should finish after 1 second, regardless of how many ICMPv6 echo requests or replies were sent or received.
Another thing to note is (DUP!) output in the second and subsequent replies. These packets are identified as duplicate responses because they share the same ICMP sequence number as the individual ICMPv6 echo requests that were sent first. They appear because a multicast ICMPv6 echo request results in multiple individual unicast responses. The number of duplicates is also indicated in the summary statistics.
Interface Definition — Zone ID
Another way to provide an interface for use is as part of the IPv6 address parameters.
We can observe an example of this in the ping output, where the addresses of the responding IPv6 nodes also have a suffix. %enp3s2, for example:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msThis method of specifying interfaces is formally described in [RFC4007], "Architecture for IPv6 Scoped Addresses". Although they are typically referred to as the operating system interface, they actually define something more general — a "zone" or "scope".
The reason for having more general zones or scope zones is that, as mentioned in [RFC4007], an IPv6 node may have several different IPv6 interfaces connected to the same link. These interfaces are members of the same zone.
It should be possible to group several interfaces within a zone under the operating system; Currently, I'm not sure if this is possible under Linux or how to do it.
Using the suffix %, we can remove the command line parameter -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Link-Local Address Responses
From this all-nodes multicast ping, we received a total of 6 unique responses.
These responses came from the unicast Link-Local addresses of the IPv6 nodes. For example, here is the first response:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msLink-Local IPv6 addresses are required on all interfaces that support IPv6 [RFC4291], "IPv6 Addressing Architecture." The reason for this is that an IPv6 node automatically has a unicast IPv6 address that can be used, at least, for communication with other nodes over its directly connected links. This includes communication with applications on other hosts via Link-Local addresses.
This simplifies the development and implementation of protocols such as IPv6 Neighbor Discovery and OSPFv3. It also allows end-user applications on hosts to exchange data over the link without requiring any other supporting IPv6 infrastructure on the link. For direct communication between connected IPv6 hosts, an IPv6 router or DHCPv6 server is not required in the connection.
Link-Local addresses start with a 10-bit prefix fe80, followed by 54 zero bits and then a 64-bit Interface Identifier (IID). In the first response above, 2392:6213:a15b:66ff — is the 64-bit IID.
Looped Multicast
By default, multicast packets are returned internally to the node that sends them. This occurs for both IPv6 and IPv4 addressing.
The reason for this default behavior is that when sending multicast packets, there may also be a listening local multicast application running on the sender host, as well as somewhere in the network. This local application should also receive the multicast packets.
We can see this multicast local loop in our ping output:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...The first and fastest response (0.106 ms compared to 0.453 ms) comes from the Link-Local address configured on the interface enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utility ping provides a way to suppress local feedback of multicast broadcasts using the option -L. If we send a ping to all-nodes multicast with this flag, responses are limited to remote nodes. We do not receive a response from the Link-Local address of the sending interface.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping Link-Local Address
As you might guess, unicast Link-Local addresses themselves also do not provide enough information to specify which interface to use to reach them. Just like with all-nodes multicast pings, we also need to specify the interface as a command line argument. ping or zone ID with the address when pinging Link-Local addresses.
This time we can use -c, to limit the number of packets and responses sent and received ping, since we are performing a unicast ping.
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Ping (all) other IPv6 addresses?
In this article, we saw how to ping all IPv6 nodes on the link using the all-nodes multicast IPv6 address. ff02::1We also learned how to specify which interface to use with the all-nodes multicast IPv6 address, as the address itself cannot provide this information. We used either the command line argument ping, or specified the interface using the suffix %.
Then we learned about unicast Link-Local addresses, which are the addresses used for responding to all-nodes multicast ICMPv6 echo requests.
We also saw how multicast packets return to the sending node by default and how to disable this for the utility ping.
Finally, we pinged a single Link-Local address using the suffix %, since Link-Local addresses themselves also do not provide information about the outgoing interface.
What about pinging all other nodes and getting their global unicast addresses (GUA) (i.e., their public addresses on the Internet) or their unique local unicast addresses (ULA)? We will cover this in the next blog article.
That's all.
Learn more about our course in the.
Source: habr.com
