[GLLUG] basic IPv6 questions

Chris Bell chrisbell at chrisbell.org.uk
Mon Oct 4 13:56:06 UTC 2021


On Sunday, 3 October 2021 20:12:46 BST Carles Pina i Estany via GLLUG wrote:
> Hi Andy,
> 
> On Oct/03/2021, Andy Smith via GLLUG wrote:
> > 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".
> 
> [...]
> 
> > So, I understand that there may be a muscle memory issue with
> 
> I have solved some muscle memory with "alias" :-)
> 
> Not an excuse, you are 100% right, just for a Sunday laugh:
> 
> I have human parsing issues! I read the output of "ifconfig" and "route"
> without any effort. I need some effort for the output of "ip a", "ip r"
> and I miss some parameters sometimes.
> 
> It's about 20 years that I moved from "pine" to "mutt" and I still use
> "p" to start "mutt":
> carles at pinux:~$ alias p
> alias p='LANG=en_GB.UTF8 mutt'
> carles at pinux:~$
> 
> (my system's locale is in Catalan but I prefer mutt in English)
> 
> I've followed with interest your email (THANKS EVER SO MUCH!). I'll add
> some comments in some places with some small question or for me to
> confirm that I understood some parts correctly...
> 
> > 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.
> 
> As said below by you and thanks to "sipcalc 2000::/3":
> Anything from 2000:0000:0000:0000:0000:0000:0000:0000 to
> 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff belongs to the global unicast
> addresses.
> 
> > >  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
> 
> I suspect that 20 years ago I studied this at uni. Sadly I've forgotten
> many things and I think that we never did a hands on setting up of an
> ipv6 network :-(
> 
> > 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_autoconfi
> >     guration
> I've read also the linked (and specially the first two paragraphs):
> https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
> 
> If the Raspberry pi + BT router used SLAAC is this more or less what
> happens?
> -Raspberry pi sends a broadcast using NDP probably type "Router
> Solicitation (Type 133)"
> (https://www.rfc-editor.org/rfc/rfc4861.html#section-4.1)
> -Router probably answers with a "Router Advertisement (Type 134)"
> (https://www.rfc-editor.org/rfc/rfc4861.html#section-4.2)
> 
> The Router Advertisement includes the IP of the router (in the "Source
> Address"?)
> 
> > DHCPv6 does exist though so it is possible that this is used in
> > addition or instead of SLAAC.
> 
> good to know!
> 
> When I had to setup a Linux box in a LAN I sometimes use
> isc-dhcp-server. If I wanted to setup ipv6 devices with SLAAC: what
> would be the way to go?
> 
> For example, the last time that I had to do this I used isc-dhcp-server
> for very basic things like:
> -Setup the DNS of the clients
> -For some of the clients a static assigned IP (e.g. host with MAC
> address X is always the IP Y)
> -Setup the gateway of the clients (some clients didn't have a gateway,
> some had a gateway)
> 
> Is this something that could be done using SLAAC? Or should be done with
> a DHCPv6 server?
> 
> > > -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
> 
> thanks for this!
> 
> > > -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
> 
> [...]
> 
> > > -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-i
> >     pv6
> > 
> > Normally the link local address is generated as a "Modified EUI-64
> 
> To confirm:
> 
> Link local address: a private address like 192.168.0.0/24 (starting with
> fe80:: in ipv6). Valid only in the network segment, not routeable
> 
> Global address: network 2000::/3 public routeable
> 
> > 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.
> 
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000 link/ether b8:27:eb:b0:9d:76 brd
> ff:ff:ff:ff:ff:ff
>     inet6 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c/64 scope global dynamic
> mngtmpaddr noprefixroute valid_lft 287sec preferred_lft 107sec
>     inet6 fe80::56d8:5a6c:fc11:16f1/64 scope link
>        valid_lft forever preferred_lft forever
> 
> does "dynamic" imply "temporary"?
> 
> > 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.
> 
> Does the "ip a" that I showed answer the question? (else I'll dig more)
> 
> > > 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.
> 
> So, if I had a different ipv6 device in this network (when I'm there in
> 10 days I will test it): the traceroute first hop will be different
> depending on the device that I initiate the ipv6?
> 
> > > 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.
> 
> I think that I understood it!
> 
> BTW, in the Raspberry pi:
> pi at raspberrypi:~ $ ip a
> [...]
> inet6 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c/64 scope global dynamic
> mngtmpaddr noprefixroute [...]
> 
> Do I have all this IPs:
> $ sipcalc 2a00:23c6:2c01:b801:2817:ffe3:d3aa:5d8c/64
> 
> Network range		- 2a00:23c6:2c01:b801:0000:0000:0000:0000 -
> 			  2a00:23c6:2c01:b801:ffff:ffff:ffff:ffff
> 
> So I can just assign more IPs if I want to the eth0 and ping to other
> IPs from other devices in the network? (and outside the network if the
> firewall allowed it?)
> 
> > https://bitfolk.com/ -- No-nonsense VPS hosting
> 
> This email is a fantastic reason to consider bitfolk (and the same with
> other emails in the past years from companies that I might be
> interested)
You might like to read http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO.
There are many Requests For Comments (RFC's), see https://www.ietf.org 
together with standards set by the IEEE, see https://standards.ieee.org/
I have also put some information on my website.
-- 
Chris Bell
Website chrisbell.org.uk





More information about the GLLUG mailing list