Hi Carlos, On Sun, Oct 03, 2021 at 02:57:51PM +0200, Carles Pina i Estany via GLLUG wrote: > I have a Raspberry pi connected to a BT router that recently has > "switched" to ipv6 only (yay?!). This is helping me to test a Gandi > server ipv6 configuration. > > Raspberry pi: /sbin/ifconfig eth0:
First of all you should get into the habit of using "ip address" and "ip route" commands instead of "ifconfig" and "route". The latter commands have been deprecated for many years now and while they are probably showing you correct information here, they do not always do so, as there is information in kernel data structures that these commands haven't been updated to handle. There's also settings that they can't set, for the same reason. Finally, it is harder to talk about network configuration when using the display from old tools. People who are particularly wedded to "ifconfig" etc. sometimes argue that it's what they know and they know it's showing them correct info, but in a situation where seeking support from others the current tools need to be used so everyone knows what they are looking at. So, I understand that there may be a muscle memory issue with immediately reaching for "ifconfig" etc — I experienced the same myself and still do with some of the "netstat" replacements — but there's nothing to be done about that except try to learn the new tools! > eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet6 fe80::56d8:5a6c:fc11:16f1 prefixlen 64 scopeid 0x20<link> > inet6 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c prefixlen 64 scopeid > 0x0<global> > ether b8:27:eb:b0:9d:76 txqueuelen 1000 (Ethernet) > Gandi server: /sbin/ifconfig eth0: > eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 213.167.241.144 netmask 255.255.254.0 broadcast 213.167.241.255 > inet6 2001:4b98:dc2:53:216:3eff:fe82:b1fb prefixlen 64 scopeid > 0x0<global> > inet6 fe80::216:3eff:fe82:b1fb prefixlen 64 scopeid 0x20<link> > ether 00:16:3e:82:b1:fb txqueuelen 1000 (Ethernet) > -inet6 2a00 and 2001 ipv6 addresses: they are global ipv6 routeable from > the internet (google.com is 20aa:..., dns.google is 2001:...). Yes. > by the DHCP server of each network (or static configuration). Yes, although dynamic IPv6 configuration is more often done by StateLess Address Autoconfiguration (SLAAC) rather than DHCP. SLAAC works through announcements by the network segment's router(s) telling devices on that network segment which addresses they can choose and what their default gateway should be. https://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration DHCPv6 does exist though so it is possible that this is used in addition or instead of SLAAC. > -Any difference between 2a00 and 2001? Any other addresses like this? They are conceptually as similar as 12.0.0.0/8 and 185.0.0.0/8 in IPv4m, for example. Just different globally routable address blocks. Out of the entire 128-bit space of IPv6 addresses, 2000::/3 has been allocated so far for global unicast addresses, so every public address you see should be in the range: $ sipcalc 2000::/3 -[ipv6 : 2000::/3] - 0 [IPV6 INFO] Expanded Address - 2000:0000:0000:0000:0000:0000:0000:0000 Compressed address - 2000:: Subnet prefix (masked) - 2000:0:0:0:0:0:0:0/3 Address ID (masked) - 0:0:0:0:0:0:0:0/3 Prefix address - e000:0:0:0:0:0:0:0 Prefix length - 3 Address type - Aggregatable Global Unicast Addresses Network range - 2000:0000:0000:0000:0000:0000:0000:0000 - 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml > -From the server I would be able to ping > 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c if BT wanted (can I ask them? > is it in the router configuration? Doing a traceroute I don't quite get > into the local home router IP, I don't think so) In theory you or anyone should be able to ping 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c but there might be a firewall in operation. It's probably a good idea if there is, as that's on your LAN side of the link and you don't really want the Internet to be able to talk directly to your router. I'm afraid I've no idea if you are able to disable any such firewalling or get BT to do anything about it. > -fe80:: are local in the network IPs. For Gandi: this gets generated out > of the MAC address. And not for the Pi, why not? (how to set this up?) Your pi: > inet6 fe80::56d8:5a6c:fc11:16f1 prefixlen 64 scopeid 0x20<link> > ether b8:27:eb:b0:9d:76 txqueuelen 1000 (Ethernet) Your server: > inet6 fe80::216:3eff:fe82:b1fb prefixlen 64 scopeid 0x20<link> > ether 00:16:3e:82:b1:fb txqueuelen 1000 (Ethernet) I think that your raspberry pi might be using stable privacy addresses (RFC7217) to choose a random interface ID (IID) per link not based on MAC address, then using that for link-local and for any autoconfigured addresses, so that your MAC address is not transmitted outside your network. https://newbedev.com/how-to-avoid-exposing-my-mac-address-when-using-ipv6 Normally the link local address is generated as a "Modified EUI-64 identifier"; it will have ff:fe in the middle and would have the 7th bit flipped, so we'd expect the EUI-64 for b8:27:eb:b0:9d:76 to be: Insert ff:fe → b827:ebff:feb0:9d76 'b8' as bits → 10111000 flip 7th → 10111010 back to hex → ba27:ebff:feb0:9d76 Your IID on your pi clearly isn't that, but it also doesn't have the ff:fe or the flipped 7th bit, so it's not EUI-64. Looking at "ip -6 a" (short hand for "ip address show") might tell you some more info; it will at least say whether the address is temporary or not. Temporary privacy addresses (RFC4941) are also used for security but the fact that they constantly change can cause problems so sometimes people use these stable identifiers instead, that are based off some local secret. Sometimes only the global scope addresses use the private identifiers but some implementations derive the link scope address this way too, as it is possible for your link address to be published outside, e.g. in email headers. I think this is what is happening here but perhaps you can confirm by inspecting your local configuration. > pi@raspberrypi:~ $ traceroute -n -6 google.com > traceroute to google.com (2a00:1450:4009:817::200e), 30 hops max, 80 byte > packets > 1 2a00:23c6:2c01:b801:ee6c:9aff:fea3:a231 5.056 ms 4.732 ms 4.549 ms > > I'm not quite matching the first hop with the routing table. Why not? This is down to how traceroute works. Traceroute relies on receiving an ICMP packet from each hop. It only knows the name of the hop based on the source address of the ICMP packet. Even though you talk to fe80::ee6c:9aff:fea3:a231 as your default gateway, it generates an ICMP packet with its global address in it (2a00:23c6:2c01:b801:ee6c:9aff:fea3:a231) because the packet that caused this ICMP to be generated had source address 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c. > ipv4 I would be able to see the gateway there (unless the gateway is not > answering ICMP, but if it's fe80::ee6c:9aff:fea3:a231 it does answer > ICMP). In IPv4 the device generally wouldn't have multiple valid source addresses to choose from. In an IPv4 network without NAT, if you are 1.2.3.4 and your router is 1.2.3.1, then when you send a packet to google at 142.250.200.14 it has source address 1.2.3.4. This generates ICMP at your router that wants to go back to you at 1.2.3.4 so it will choose source address 1.2.3.1 for that ICMP. Even if your host had an extra private address 192.168.123.4 and router had a private address 192.168.123.1, router is not going to spontaneously decide to source an ICMP packet from 192.168.123.1 when it sends it to 1.2.3.4 even if you did set your default gateway to be 192.168.123.1. So in fact IPv4 is working exactly the same as IPv6 in this regard it's just that you don't tend to use IPv4 that way. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug