Differences

This shows you the differences between two versions of the page.

--- doc:appunti:net:ipv6_on_ppp [2024/07/05 12:51] – [IPv6 source address problem] niccolo
+++ doc:appunti:net:ipv6_on_ppp [2024/07/05 15:37] (current) – [Troubleshooting IPv6 problems] niccolo
@@ Line 547: / Line 547: @@
 To give a **persistent addresses** to the client, take note of the DUID received by the server and put it into a **host** section of the server configuration **dhcp6s.conf** (see above). The DUID is composed of a 64 bit random string and the MAC address of the client's network interface; once generated, it is stored into a file named **/var/lib/dhcpv6/dhcp6c_duid**.
-==== IPv6 source address problem ====
+FIXME: What to do to protect LAN hosts from the internet?
+===== MRU and MTU for PPPoE =====
+In Debian GNU/Linux the default configuration file for the **pppd** daemon is **/etc/ppp/peers/provider**. It is possibile to specify both the //maximum transmission unit// (MTU) and the //maximum receive unit// (MRU). The MTU is used to configure the ppp interface, the MRU is used instead during the nogotiation phase to ask the peer to send packets of no more than the specified bytes (i.e. to set its MTU).
+The standard MTU size for Ethernet is 1500 bytes; PPPoE header uses 6 bytes and the PPP protocol ID uses 2 bytes, so the default MTU on a PPPoE interface is **1492** bytes. On the receiving side we don't want to pose restrictions to the peer, so we stay with the 1500 bytes default:
+<file>
+debug
+mtu 1492
+mru 1500
+</file>
+During the negotiation phase the **pppd** daemon may receive specific MRU requests from the internet provider, here it is a //debug// log in syslog:
+<file>
+pppd[975]: rcvd [LCP ConfReq id=0x1 <mru 1488> <auth pap> <magic 0xd18deef6>]
+</file>
+In this case the pppd will configure the **ppp** interface with the requested **1488 MTU**, instead of the 1492 from the configuration file.
+===== IPv6 Prefixes =====
+^ FE80::/64          | Link-local prefix.  |
+^ FF02::1            | All-nodes multicast address.  |
+^ FF02::2            | All-routers multicast address.  |
+^ FF02::1:FFxx:xxxx  | Duplicate Address Detection multicast group.  |
+===== Troubleshooting IPv6 problems =====
+In general, to troubleshoot any networking issue, you use the **ping** command to check if the remote address is responding:
+<code>
+# ping -6 2a01:4f8:1c17:7636::1
+</code>
-FIXME It was a problem of duplicate address indeed!
+In some cases it is useful also to **ping your own addresses** (you can have more than one). Discover all of them with:
 <code>
-ip -6 address show dev enp0s7
+# ip -6 address show dev enp0s7
 </code>
@@ Line 565: / Line 601: @@
 </code>
-Notice the **dadfailed**!!! Cannot even ping itself.
+In the example above the interface have two **global** scope addresses, one assigned via DHCPv6 and the other obtained via SLAAC. The first one has the **dadfailed** flag, which means that the **duplicate address detection** has detected a conflict in the network. This means that the IP address in question will not be used as the source address and it does not even respond to a self-ping.
-Enabling the DHCPv6 address only (i.e. disabling SLAAC configuration on the client) the IPv6 routing doese not work; we get the //Beyond scope of source address// error message. Sniffing the traffic on the default gateway we can see:
+If you have only one global IP address which is **dadfailed**, you cannot reach remote hosts on IPv6. It may be a difficult situation to diagnose, because using the simple **ifconfig** command you see the assigned IPv6 address and the **default route** is OK:
 <code>
+# ip -6 route show
+a02:2420:503:1c03::2 dev enp0s7 proto kernel metric 256 pref medium
+a02:2420:503:1c03::/64 dev enp0s7 proto kernel metric 256 expires 86387sec pref medium
+fe80::/64 dev enp0s7 proto kernel metric 256 pref medium
+default via fe80::d003:a6ff:fef2:6fe8 dev enp0s7 proto ra metric 1024 expires 167sec hoplimit 64 pref medium
+</code>
+**NOTICE**: The default router can be reached via its **link** scope address (as seen above) or via its **global** scope address: both can be used.
+If you sniff the ping request on the router, you can see the problem more clearly:
+<code>
+# tcpdump -i eth0 -n 'icmp6'
+...
 IP6 fe80::225:22ff:fedd:4598 > 2a01:4f8:1c17:7636::1: ICMP6, echo request,
     id 56698, seq 1, length 64
@@ Line 576: / Line 626: @@
 </code>
-The default gateway on the client seems OK (check it with ''ip -6 route show''), but the source address is set to the **link scope** address instead of the **global** one. You can confirm it with the command ''%%ip -6 route get <ipv6_address>%%'':
+The client uses its link scope address as source address, which causes the **beyond scope** error. You can confirm this problem on the client using the ''ip route get'' command:
 <code>
-ip -6 route get 2a01:4f8:1c17:7636::1
+# ip -6 route get 2a01:4f8:1c17:7636::1
 a01:4f8:1c17:7636::1 from ::
     via 2a02:2420:503:1c03::1
@@ Line 587: / Line 638: @@
 </code>
-You can compare the result when the SLAAC is enabled:
+You can compare the result when you have at least one working global IP address:
 <code>
-ip -6 route get 2a01:4f8:1c17:7636::1
+# ip -6 route get 2a01:4f8:1c17:7636::1
 a01:4f8:1c17:7636::1 from ::
     via fe80::d003:a6ff:fef2:6fe8
@@ Line 598: / Line 649: @@
 </code>
-In the first case the **src** address is the **link scope** one, not suitable for routing. In the second case it is the one received via SLAAC, which has a **global scope** and indeed it is working. Notice that the address of the router (shown as the **via** address) is not releveant, the //link scope// one does work.
+In the first case the **src** address is the **link scope** one, not suitable for routing. In the second case it is the one received via SLAAC, which has a **global scope** and indeed it is working. Notice that the address of the router (shown as the **via** address) is not releveant, even the //link scope// one does work.
-FIXME How to solve?
-FIXME: What to do to protect LAN hosts from the internet?
-===== MRU and MTU for PPPoE =====
-In Debian GNU/Linux the default configuration file for the **pppd** daemon is **/etc/ppp/peers/provider**. It is possibile to specify both the //maximum transmission unit// (MTU) and the //maximum receive unit// (MRU). The MTU is used to configure the ppp interface, the MRU is used instead during the nogotiation phase to ask the peer to send packets of no more than the specified bytes (i.e. to set its MTU).
-The standard MTU size for Ethernet is 1500 bytes; PPPoE header uses 6 bytes and the PPP protocol ID uses 2 bytes, so the default MTU on a PPPoE interface is **1492** bytes. On the receiving side we don't want to pose restrictions to the peer, so we stay with the 1500 bytes default:
-<file>
-debug
-mtu 1492
-mru 1500
-</file>
-During the negotiation phase the **pppd** daemon may receive specific MRU requests from the internet provider, here it is a //debug// log in syslog:
-<file>
-pppd[975]: rcvd [LCP ConfReq id=0x1 <mru 1488> <auth pap> <magic 0xd18deef6>]
-</file>
-In this case the pppd will configure the **ppp** interface with the requested **1488 MTU**, instead of the 1492 from the configuration file.
-===== IPv6 Prefixes =====
-^ FE80::/64          | Link-local prefix.  |
-^ FF02::1            | All-nodes multicast address.  |
-^ FF02::2            | All-routers multicast address.  |
-^ FF02::1:FFxx:xxxx  | Duplicate Address Detection multicast group.  |
 ===== Web References =====