Should I Block ICMP?
http://shouldiblockicmp.com/
#ycombinator #ICMP #traceroute #blackhole #traffic #ping #NDP #SLAAC #PMTUD #IPv4 #IPv6 #MTU #MSS #PLPMTUD
Should I Block ICMP?
http://shouldiblockicmp.com/
#ycombinator #ICMP #traceroute #blackhole #traffic #ping #NDP #SLAAC #PMTUD #IPv4 #IPv6 #MTU #MSS #PLPMTUD
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=::3333
Damit 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?
@mort #IPv6 doesn't support host-parts shorter than (and prefixes longer than) 64 bits.
Although some routers (e.g. my #FreeBSD VM) can deal with longer prefixes and I'd be perfectly fine for my small network to assign addresses manually and with #dhcpv6, not all devices and systems (e.g. #android) can do that but insist on #SLAAC, which strictly requires a 64bit host part.
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.
@txt_file Looking at the end of pg 3 of
https://www.rfc-editor.org/rfc/rfc2464
"An IPv6 address prefix used for stateless autoconfiguration [ACONF]
of an Ethernet interface must have a length of 64 bits."
So you are right. If you are not using #ethernet then #SLAAC might work on different prefix that /64
Short question: WireGuard + auto IPv6, doable?
Long question: can I run SLAAC/rtadvd over a WireGuard interface? I can do the scripting by myself.
@troglobit also in #ICMPv6 RA / #RFC4861 it seems that again only a prefix plus prefix length is allowed. And not a netmask. Which would seem quite useful for #IPv6 #multicast?
And now I'm also wondering if a host's #IPv6 stack receiving any (routeable) unicast prefix via #SLAAC or #DHCPv6 should maybe just install the matching #embeddedRP #multicast prefix on its own, by default on the according interface?
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?
@frameworkcomputer @debian
TL;DR:
Not working:
Debian+wifi+NetworkManger
Working:
Debian+lan
Debian+wifi+ifupdown
Fedora
Kali
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?
Host contains this in /etc/rc.conf:
ifconfig_em0="SYNCDHCP"
ifconfig_em0_ipv6="inet6 accept_rtadv"
ipv6_cpe_wanif="em0"
In jails I set this:
ifconfig_vnet0="inet 192.168.1.123/24"
defaultrouter="192.168.1.1"
ifconfig_vnet0_ipv6="inet6 accept_rtadv"
ipv6_cpe_wanif="vnet0"