Re: Redploying most of 127/8 as unicast public

[Francis Booth via NANOG <nanog () nanog org>]

> On Nov 20, 2021, at 6:35 PM, Matthew Walster <matthew () 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 () boothlabs me