[GLLUG] basic IPv6 questions
Andy Smith
andy at bitfolk.com
Sun Oct 3 17:20:16 UTC 2021
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 at 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
More information about the GLLUG
mailing list