Redploying most of 127/8 as unicast public

Tue Nov 23 20:07:34 UTC 2021

> On Nov 20, 2021, at 6:35 PM, Matthew Walster <matthew at walster.org> wrote:
> 
> I genuinely believe we're reaching a stalling point for IPv6 service enabling, and it's time to focus energy on running IPv6 only clients -- and to do that, we need to make the IPv6 only experience for residential / soho be as pain-free as possible, no extra knowledge required. 

If I may play devils advocate,

Google’s WiFi pucks did something I thought was interesting that I have not seen replicated by others that may or may not be of use to us in this regard. By using a local DNS resolver running on the main WiFi puck in the network, they handed it out via DHCP for clients to use which helped resolve a local webpage that showed devices that were connected to the local network by navigating to “on.here” inside a web browser.

That got me thinking, 

So we know RFC 2606 defined reserved TLDs like .lan and .home so there is already a known list of .TLDs that we know would be safe to use in local scope, and besides the people who are already doing their own thing eg: people running PiHole or similar service inside their networks, or those who insist on setting their DNS servers static, everybody else should be defaulting to whatever is being handed out by their routers' DHCP server so keeping that in mind what if we did something like this:

In order to solve the chicken/egg problem of having to know your IPv6 prefix and the address assigned to your router dynamically for nontechnical users to reach their router configuration pages, the router can run a local DNS resolver for the “.lan” TLD by default that it hands out through RDNSS in it’s RAs. Since the router is the “first” device in the network, it should always take the “router.lan” entry for itself and populate it with its IPv6 address. (Obviously proper inbound filtering should prevent external hosts out on the Internet from reaching the router configuration page.) Local devices will then be able to resolve and reach stuff from within the internal network by hostname. Since the router would also be the first device to become aware of any IPv6 prefix change from the ISP, it lends itself to loop this prefix update into the same processes it would use to update the router’s RA configuration back to the clients and to update it’s local DNS entry for “router.lan”. Best case scenario the prefix update will happen fast enough that it goes unnoticed and clients see minimal disruption.

I feel users may find this method preferable in comparison to the old method of “type in 192.168.1.1 in your browser” where those instructions were not always 100% accurate due to some vendors deciding to use a different variation of private range addresses (I’m looking at you 192.168.0.1, and 192.168.100.1). Everybody would be able to quickly find their routers regardless of vendor, model, firmware version, or ISP.

So (in theory) we have a reliable method of discovering our router configuration page without any prior knowledge of our IPv6 prefix, the IPv6 address assigned to ourselves, or that of the router. We could possibly even support dynamic DNS entries for connected devices that used DHCPv6 (Android obviously not able to take advantage of due to lack of support) to request addresses from the pool. As long as vendors set unique hostnames that don't overlap at the factory or attempt to re-use simple hostnames like chromecast.lan (sorry, I’m picking on Google a lot here.) where the potential for multiple devices to be named the same could occur, I can’t imagine that occurring in Residential / SoHo networks all that often but the potential for it is cetainly there.

But this solution is by no means perfect, there are various situations I can think of where this kind of automation may break down and not work entirely as anticipated, eg: devices joining the network with device MAC address randomization turned on which I know is a default on certain devices and OSes (Android 11 comes to mind), or networks where the administrators do not want to allow joined devices to create their own dynamic DNS entries into the zone, but I digress, those environments are outside the scope of who this is designed for.

I hope others may take inspiration from this idea and maybe expand upon it or even get inspiration to design something that better fits the bill for what you’re looking for. Feedback is always welcome.

(Sorry to Matt and Owen who got this message twice. I originally sent this reply from my secondary address that is not subscribed on the list and the original reply got rejected)

-
Francis Booth
boothf at boothlabs.me