noprefixroute does not affect IPv6 connectivity with external machines.
However, you can try adding an additional temporary IPv6 address using netplan to see if this resolves the issue.
network:
version: 2
ethernets:
eth0:
# Other configurations...
dhcp6: true
ipv6-privacy: true # add this line
That did the trick! The server can now connect to any IPv6 address!
May I know is the router IPv6 mode in passthrough?
If yes, please try to SSH to the router, and execute this command:
ip -6 nei add [ubuntu ipv6 addr] dev br-lan lladdr [ubuntu NIC MAC]
Example:
ip -6 nei add 2xxx:xxxx:3254:fe90:903a:cea8:d10b:xxxx dev br-lan lladdr xx:0f:xx:28:xx:xx
No to put a dampener on things but you might be interested in this. It's something to be aware of if nothing else:
Sorry, Will’s suggestion was only a temporary fix – the second IPv6 address vanishes at the end of its lifetime, and with it the IPv6 connectivity.
The router is in passthrough mode, and when I execute the suggested command on the router, this the response:
RTNETLINK answers: File exists
Please advise.
This is also the one of method for temporary addresses.
The prompt means that the address already exists. Generally, the lifespan of IPv6 is very long.
ping -6 www.google.com -S <The specified ipv6 address>, if it is reachable?ip -6 neigh show dev br-lan check if the client's MAC and the temporary ipv6 address are matched.None. It only has the stable SLAAC address, containing an EUI-64 interface identifier, unless I add ipv6-privacy: true to the netplan configuration – then a second address is created temporarily after executing netplan apply, but instead of rotating, it vanishes.
No, not with the stable (SLAAC) address.
When the temporary address is present (with ipv6-privacy: true), there are two entries:
<ipv6-prefix>:<eui-64-identifier> lladdr <mac-address> REACHABLE
<ipv6-prefix>:<temporary-privacy-address> lladdr <mac-address> REACHABLE
So there are two reachable address, but only one is routable outside my local network. I read up on noprefixroute, and it is used to achieve exactly this: Do not route a sensitive address outside the local network. Now my problem boils down to the question why the second address vanishes after some time, and whether it is created by SLAAC (so it only receives the IPv6 prefix from the IPS modem/router), or by DHCP6.
We are not sure what configuration may have changed and the second address will appear, and no idea why it disappears then.
You said that is using SLAAC, then DHCP6 will not allocate, but allocate with RA prefix.
Yes, I am confused, too. To summarize the situation again: The dynamic, routable IPv6 address has a lifetime of 3600 seconds (and is not replaced after that time). In the output of sysctl net.ipv6.conf.all, this corresponds to the router_solicitation_max_interval and is much shorter that the temp_preferred_lft and temp_valid_lft values:
net.ipv6.conf.all.router_solicitation_max_interval = 3600
net.ipv6.conf.all.router_solicitations = -1
net.ipv6.conf.all.rpl_seg_enabled = 0
net.ipv6.conf.all.seg6_enabled = 0
net.ipv6.conf.all.seg6_require_hmac = 0
net.ipv6.conf.all.suppress_frag_ndisc = 1
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 604800
net.ipv6.conf.all.use_oif_addrs_only = 0
net.ipv6.conf.all.use_tempaddr = 2
The RA messages from the ISP router, on the other hand, have a router lifetime of just 180 seconds:
13:43:18.460761 IP6 (flowlabel 0x98e5a, hlim 255, next-header ICMPv6 (58) payload length: 104) _gateway > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 104
hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 180s, reachable time 0ms, retrans timer 0ms
rdnss option (25), length 24 (3): lifetime 86400s, addr: 2a02:908:532:bca0:10:18ff:fe3f:3194
prefix info option (3), length 32 (4): 2a02:908:532:bca0::/64, Flags [onlink, auto], valid time 86400s, pref. time 86400s
route info option (24), length 24 (3): ::/0, pref=medium, lifetime=180s
On the Flint 2, the IPv6 prefix lifetime was set to 12 hours, which I increased to 7 days (without any effect). Would it make sense to increase the router_solicitation_max_interval value on the Ubuntu server? And why would the router solicitation interval affect the dynamic SLAAC address’ lifetime?
Based on the situation, it appears that your ISP may be blocking the static IPv6 address of your Ubuntu server.
We recommend trying to manually configure a different IPv6 address to see if that restores functionality.
Regarding the temporary addresses, we'd like to understand more about that issue.
We recommend reducing the value of router_solicitation_max_interval rather than increasing it. RS is helping to send a request to router for asking the latest information to avoid situations like PD prefix changes.
It makes sense to hide the static IP address (which contains the MAC address), so I would not want to change this behaviour.
No, all other devices retain/refresh their temporary addresses properly, and connect to the Internet using these addresses.
The problem is that the temporary address on the Ubuntu server expires (and is not renewed). The expiration after 3600 seconds is not linked to the valid lifetime or preferred lifetime values, so I do not know what causes the expiration (and how to avoid it).
Then it seems unrelated to the router's IPv6 Router Advertisement (RA).
Since this issue appears to be specific to the desktop Linux environment, we recommend seeking assistance from the Ubuntu community.
As our team's expertise is focused on network equipment, we may not be able to provide the best advice for this particular situation.
Alternatively, try using a fixed random IPv6 address which hides the MAC address from the network and should not have lifetime issues.
network:
version: 2
ethernets:
eth0:
# Other configurations...
ipv6-address-generation: stable-privacy # add this line
I will post my question to an Ubuntu forum – thanks for the help so far!
That did work. So there is some difference between the EUI64 address and a stable privacy address, which is not discernible with respect to the tags, but still makes a difference. So this is a solution, although I still wonder where (and why) requests from the EUI64 address is discarded. As suggested, I will turn to a different forum.
Update: It turns out that the whole problem was caused by the ISP modem acting as a router. After my ISP enabled bridge mode for the device, the problem with my server just went away.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.