#slaac — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #slaac, aggregated by home.social.
-
About fucking time... Android finally doing proper DHCPv6. When this is live on my phone I can turn off SLAAC, and not have Windows insist on using it (yes, there's meant to be ways to stop Windows from using SLAAC, so it only uses DHCPv6, but I never saw any of them work). *I* don't want 'random' addresses, I want predictable ones for firewalling and ACLs: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1
-
About fucking time... Android finally doing proper DHCPv6. When this is live on my phone I can turn off SLAAC, and not have Windows insist on using it (yes, there's meant to be ways to stop Windows from using SLAAC, so it only uses DHCPv6, but I never saw any of them work). *I* don't want 'random' addresses, I want predictable ones for firewalling and ACLs: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1
-
A fun hour or so of troubleshooting #IPv6 just to realise that I'd forgotten to reconfigure the #dhcpPrefixDelegation onto the #vif after making it #vlanaware #edgerouter #slaac #ubiquity
-
Service:
Hin und wieder wird bei DYNDNS eine stabile Host-ID verlangt:
Linux allgemein:
man ip-token
ip token set ::3000 dev eth0
oder im NetworkManager:
https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nm-settings-nmcli.html[ipv6]
addr-gen-mode=eui64
method=auto
token=::3333Damit kommt man ohne DHCPv6 aus und die Hosts müssen nicht ihre MAC-Adresse "verraten".
Wenn jemand die äquivalenten Einstellungen für andere OS oder Tools kennt, kann ja gern damit darauf antworten.
-
Service:
Hin und wieder wird bei DYNDNS eine stabile Host-ID verlangt:
Linux allgemein:
man ip-token
ip token set ::3000 dev eth0
oder im NetworkManager:
https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nm-settings-nmcli.html[ipv6]
addr-gen-mode=eui64
method=auto
token=::3333Damit kommt man ohne DHCPv6 aus und die Hosts müssen nicht ihre MAC-Adresse "verraten".
Wenn jemand die äquivalenten Einstellungen für andere OS oder Tools kennt, kann ja gern damit darauf antworten.
-
I had a presentation about registering #hostname on #ipv6, when #SLAAC is used. Is there any attempt to register name to local #dns server, when I am on IPv6 only network? I think dynamic update over TCP would be similar to #dhcp based registration Dnsmasq does automatically. Is there any system attempting it already?
-
I had a presentation about registering #hostname on #ipv6, when #SLAAC is used. Is there any attempt to register name to local #dns server, when I am on IPv6 only network? I think dynamic update over TCP would be similar to #dhcp based registration Dnsmasq does automatically. Is there any system attempting it already?
-
It was really cumbersome to configure IPv6 on my proxmox playground box.
Yes I do want this box to act as a router for the hosted VMs, but yes I also want SLAAC to get the default route and DNS!
Long story short, in a pre-up I had to add a "echo 0" to the forwarding sysctl for the wan interface.
But from my understanding, this interface is still forwarding IPv6 packets for the VMs.At least now it's working, and also tested that the configuration is also correctly applied upon a reboot.
-
It was really cumbersome to configure IPv6 on my proxmox playground box.
Yes I do want this box to act as a router for the hosted VMs, but yes I also want SLAAC to get the default route and DNS!
Long story short, in a pre-up I had to add a "echo 0" to the forwarding sysctl for the wan interface.
But from my understanding, this interface is still forwarding IPv6 packets for the VMs.At least now it's working, and also tested that the configuration is also correctly applied upon a reboot.
-
Is it just me or is #radvd "::/64" prefix autodiscovery broken since it doesn't limit the prefix length to 64? If the ISP offers a wider than 64-bit block the autodiscovery will just pick that value as-is and advertise it. At least macOS and iOS will reject such overly wide RA.
One fix for this is to just use explicit prefix stanza with "address::/64" but this requires that the radvd.conf is generated runtime based on the prefix obtained from the ISP.
Since I didn't feel like having to keep regenerating the radvd.conf dynamically I just patched the send.c to limit the xprefix.PrefixLen to 64.
I'm sure there's a better way but this problem looked like a nail to me.
-
Is it just me or is #radvd "::/64" prefix autodiscovery broken since it doesn't limit the prefix length to 64? If the ISP offers a wider than 64-bit block the autodiscovery will just pick that value as-is and advertise it. At least macOS and iOS will reject such overly wide RA.
One fix for this is to just use explicit prefix stanza with "address::/64" but this requires that the radvd.conf is generated runtime based on the prefix obtained from the ISP.
Since I didn't feel like having to keep regenerating the radvd.conf dynamically I just patched the send.c to limit the xprefix.PrefixLen to 64.
I'm sure there's a better way but this problem looked like a nail to me.
-
Embrace IPv6 before its too late? - Many hackers have familiar sayings in their heads, such as “If it ain’t broke, don... - https://hackaday.com/2024/06/08/embrace-ipv6-before-its-too-late/ #routeradvertisement #homenetworking #networkhacks #slaac #ipv4 #ipv6
-
Embrace IPv6 before its too late? - Many hackers have familiar sayings in their heads, such as “If it ain’t broke, don... - https://hackaday.com/2024/06/08/embrace-ipv6-before-its-too-late/ #routeradvertisement #homenetworking #networkhacks #slaac #ipv4 #ipv6
-
CW: tech posting, ipv6 rant
#ipv6 is just driving me up a wall rn. Let's go on a journey of pain:
- I want to "live in the future" so I let my Unifi udm-pro gateway also get an ipv6 upstream address. My ISP gives me a /56 over DHCPv6 for some reason, this works fine.
- To get that down to LAN devices I let the gw pass it on with #SLAAC, since "thou shalt not think in terms of DHCP with ipv6"
- If I leave it on auto config, the ISPs upstream DNS server is pushed via SLAAC. This is Bad because clients tend to prefer ipv6 DNS over ipv4 and thus they trust an NXDOMAIN for an internal address that the ipv4 DHCP provisioned DNS server would know about.
- So we enable manual SLAAC. The DNS server is a mandatory field and only accepts an ipv6 address. Great, now I need to serve local DNS over ipv6.
- But my server nodes get their ipv6 address over the same damn SLAAC and an RA from the ISP can and frequently does change the address space thus invalidating any static ip I put in as DNS!
Why are we doing this again?
-
CW: tech posting, ipv6 rant
#ipv6 is just driving me up a wall rn. Let's go on a journey of pain:
- I want to "live in the future" so I let my Unifi udm-pro gateway also get an ipv6 upstream address. My ISP gives me a /56 over DHCPv6 for some reason, this works fine.
- To get that down to LAN devices I let the gw pass it on with #SLAAC, since "thou shalt not think in terms of DHCP with ipv6"
- If I leave it on auto config, the ISPs upstream DNS server is pushed via SLAAC. This is Bad because clients tend to prefer ipv6 DNS over ipv4 and thus they trust an NXDOMAIN for an internal address that the ipv4 DHCP provisioned DNS server would know about.
- So we enable manual SLAAC. The DNS server is a mandatory field and only accepts an ipv6 address. Great, now I need to serve local DNS over ipv6.
- But my server nodes get their ipv6 address over the same damn SLAAC and an RA from the ISP can and frequently does change the address space thus invalidating any static ip I put in as DNS!
Why are we doing this again?
-
Short question: WireGuard + auto IPv6, doable?
Long question: can I run SLAAC/rtadvd over a WireGuard interface? I can do the scripting by myself.
-
Short question: WireGuard + auto IPv6, doable?
Long question: can I run SLAAC/rtadvd over a WireGuard interface? I can do the scripting by myself.
-
Extremely surprising finding: while #FreeBSD has no problems at all taking part in an #IPv6 network via #SLAAC or manually assigned addresses in combination with regular router advertisements, even the version 14 base system still doesn’t seem to support #DHCPv6 in a standards-compliant way. https://forums.freebsd.org/threads/is-there-a-working-dhcpv6-client-for-freebsd.60168/ from 2018 suggests using dual-dhcpcd. Is that still the recommended solution?
-
Extremely surprising finding: while #FreeBSD has no problems at all taking part in an #IPv6 network via #SLAAC or manually assigned addresses in combination with regular router advertisements, even the version 14 base system still doesn’t seem to support #DHCPv6 in a standards-compliant way. https://forums.freebsd.org/threads/is-there-a-working-dhcpv6-client-for-freebsd.60168/ from 2018 suggests using dual-dhcpcd. Is that still the recommended solution?
-
I found something strange on my home server upgraded to #FreeBSD 14.0-RELEASE.
I got 2 jails built with #Bastille. Both are using VNet. Their network is setup with static #IPv4 and #SLAAC #IPv6.
All works fine. I can ping in both ways and using IPv4 & IPv6 other computers on the local network.
Jails can ping the host in IPv4 in both ways, but IPv6 ping doesn’t work to the host. If the host try to ping jails, it works and IPv6 ping from jails to host magically works.
I tried to disable #PF on jails but it doesn’t changed anything.
Did I missed anything new in 14.0 with network stack? -
Introductory post: this is my public sub-account for #IPv6 content; my main account is linked in my profile.
I support the complete roll-out of IPv6, including intermediate efforts like dual-stack support and #NAT64 #DNS64 #CLAT, with the ultimate goal of native IPv6 support in all-new deployments, using RFC standards and best practices.
I support subnets no smaller than /64 (#SLAAC), ISPs should delegate prefixes of at least /56 or /48, and #ICMPv6 should be rate-limited, never blocked.
-
Introductory post: this is my public sub-account for #IPv6 content; my main account is linked in my profile.
I support the complete roll-out of IPv6, including intermediate efforts like dual-stack support and #NAT64 #DNS64 #CLAT, with the ultimate goal of native IPv6 support in all-new deployments, using RFC standards and best practices.
I support subnets no smaller than /64 (#SLAAC), ISPs should delegate prefixes of at least /56 or /48, and #ICMPv6 should be rate-limited, never blocked.
-
I understand the reasoning, but whoever decided that every interface needed a full /64 ipv6 prefix and then hard code it into SLAAC was a bit out of touch with reality.
Sure it makes calculating an address from the mac address easy, but the truth is that /48s are not being handed out like candy at hosting providers which is where they should be assigned to each customer.
A /96 would have been more than sufficient for interfaces. That's over 4 billion unique addresses per interface.
-
I understand the reasoning, but whoever decided that every interface needed a full /64 ipv6 prefix and then hard code it into SLAAC was a bit out of touch with reality.
Sure it makes calculating an address from the mac address easy, but the truth is that /48s are not being handed out like candy at hosting providers which is where they should be assigned to each customer.
A /96 would have been more than sufficient for interfaces. That's over 4 billion unique addresses per interface.
-
Anyone have thoughts on what might prevent #SLAAC from working on a network for which stateful #ipv6 address configuration works just fine? Details are in https://unix.stackexchange.com/q/725361/4989 if you're curious.
The target system is obviously seeing router advertisements and configures the correct default route. Router advertisements have the "A" flag set, and the "accept_ra" sysctl is "2" for this interface.
-
Anyone have thoughts on what might prevent #SLAAC from working on a network for which stateful #ipv6 address configuration works just fine? Details are in https://unix.stackexchange.com/q/725361/4989 if you're curious.
The target system is obviously seeing router advertisements and configures the correct default route. Router advertisements have the "A" flag set, and the "accept_ra" sysctl is "2" for this interface.
