0

I recently switched my virtual private server hehoe.de from Ubuntu to Arch Linux. I am struggling trying to regain IPv6 connectivity. Access via IPv4 is working fine, so the hardware is okay.

The server provider instructs me to use 2a00:5080:1:199::1/128 for the server's IPv6 address and fe80::1 as the gateway. They gave me a configuration file to use with netctl for IPv4 connectivity. I added the IPv6 sections:

Description='A basic static ethernet connection'
Interface=enX0
Connection=ethernet
IP=static
Address=('84.38.64.200/32')
Routes=('172.16.147.1/32 dev eth0')
Gateway='172.16.147.1'
IP6=static
Address6=('2a00:5080:1:199::1')
Gateway6='fe80::1'

After enabling and starting the profile, the command ip addr list shows this:

enX0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:16:3e:4f:7f:20 brd ff:ff:ff:ff:ff:ff
inet 84.38.64.200/32 scope global enX0
   valid_lft forever preferred_lft forever
inet6 2a00:5080:1:199::1/128 scope global 
   valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe4f:7f20/64 scope link 
   valid_lft forever preferred_lft forever

It makes me think the addresses are set-up correctly.

The command ip -6 route shows this:

2a00:5080:1:199::1 dev enX0 proto kernel metric 256 pref medium
fe80::/64 dev enX0 proto kernel metric 256 pref medium
default via fe80::1 dev enX0 metric 1024 pref medium

The routes are looking fine to me, too.

I can ping -6 fe80::1%enX0 so there is some machine there.

Running mtr -6 google.com on the server only shows an empty table. That made me think the gateway is not being considered at all.

Observing the ping attempts with tcpdump -e -n -i enX0 "ip6":

18:44:45.981952 00:16:3e:4f:7f:20 > fe:ff:ff:ff:ff:ff, ethertype IPv6 (0x86dd), length 118: 2a00:5080:1:199::1 > 2a00:1450:4001:81c::2003: ICMP6, echo request, id 8, seq 3, length 64

Where 2a00:1450:4001:81c::2003 is the google server I tried to ping.

ip neigh shows:

172.16.147.1 dev enX0 lladdr fe:ff:ff:ff:ff:ff REACHABLE 
fe80::1 dev enX0 lladdr fe:ff:ff:ff:ff:ff router STALE

So fe:ff:ff:ff:ff:ff is indeed the router's MAC address.

Any ideas how to debug this issue?

Improve this question
7
  • Trying an mtr against that IP (2a00:5080:1:199::1) gives me 2001:1608:ffff:179:0:20:4119:2 as the last reachable hop, your machine never responds. fe80::/64 is a link-local address, that won't be routing. Commented Oct 25, 2024 at 20:25
  • Yes, the machine does not respond. That is the problem. Does the gateway need to be on a route-able address in IPv6? Commented Oct 25, 2024 at 21:51
  • That's what it's like on my machine, but that is ubuntu and acquires its settings from my router via DHCP. My first hop is my router's public IP. Commented Oct 25, 2024 at 23:59
  • @tink: Link-local addresses are fairly standard for gateways/nexthops (as the route nexthop address by definition has to be resolvable to a MAC address on the local link, whereas its routability beyond that is completely irrelevant). If it's pingable, then the problem likely is elsewhere. Commented Nov 1, 2024 at 17:25
  • 1
    Good idea, @grawity. I added tcpdump's output to the question body. The packets seem to be sent to the correct address. I am starting to suspect my configuration is not actually wrong, but it is the router that has stopped routing IPv6 packets. I'll probably need to get in touch with the server provider's support again. This provider uses Xen for virtualization. I suspect that is where enX0 is derived from. Commented Nov 1, 2024 at 18:05

1 Answer 1

Reset to default
0

I finally managed to get in touch with the VPS provider. It turns out that when using their particular web-interface to select an operating system, the network settings are reset to the default of IPv4 only. IPv6 connectivity must be requested explicitly and manually. I recently did the request and now IPv6 works with the same settings as mentioned above.

mtring the server now yields these last lines:

2001:1608:ffff:179:0:20:4119:2
2a00:5080:6:da01::c32a:233
2a00:5080:1:199::1

Where 2a00:5080:6:da01::c32a:233 seems to be the router which previously did neither respond nor route the packages.

There is another difference. ip -6 neigh now shows REACHABLE instead of STALE:

fe80::1 dev enX0 lladdr fe:ff:ff:ff:ff:ff router REACHABLE

My theory is that within the virtual network, fe80::1 is the link-local address of 2a00:5080:6:da01::c32a:233.

Improve this answer
1
  • REACHABLE vs STALE is mostly irrelevant; all neighbor entries become STALE after a very brief timer until they are re-verified and become REACHABLE again, as part of continuous "dead gateway detection". Both are equally better than FAILED (which would indicate a completely nonexistent address). See watch -d -n 0.5 ip -6 nei. Commented Jul 31 at 5:51

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.