At the U23 yesterday, we included a simple practice lesson on how networks work. We have a server on our network called
fiep only has a single address,
192.168.23.240/25 according to the local DNS server, as opposed to the rest of the network,
The router did not announce any route for
fiep still had addresses in other networks (
172.23.23.23 as well as an address in
2001:6f8:100c:1::/48), but they weren’t announced anywhere.
The task, as given, was “to connect to http://fiep/hacking4pizza/“. In essence, this reduced the task at hand to either just giving yourself an IP in the
192.168.23.128/25 network or just setting a route for said network, and then opening up your browser. Along with other workarounds, of course, that do require knowledge not easily available.
We had an interesting case, though: one single Mac user could connect to the host without problem, just typing in http://fiep/ and everything’s good.
Confusion was amongst us. We couldn’t quite explain how the Mac managed to just access the site. We assumed it was IPv6, blocked it, and voilà, it didn’t work anymore.
Vague theories were ramped up. Mine was the scariest, and also rather possible:
- The client looks up the hostname, as usual.
- It gets the IP, sees that it has no route to go there.
- Next, an ARP request is pushed out for the IP.
- The switch comes yapping along and says “got it!”, along with the MAC address.
- The client then generates an IPv6 address from the MAC address.
- Voila, connectivity.
There’s just two points where this would have went wrong:
- Usually, the default route catches any stragglers.
- Why generate a v6 address when it gets a connection to the v4 address? Of course, it doesn’t know whether the router will actually forward anything at all.
In the end, though, it was something way more simple: we still had an external DNS server which propagated the public IPv6 address, and the client was using an external DNS server.
But trying to find out what actually happened did prove quite entertaining.