> URLs are an obvious candidate to consider because they're in use, seem
> to basically work to identify routing endpoints, and are far from a
> random, out of thin air, choice.
In reality, you’re not really talking about URLs here, even. You’re talking
about DNS host names. (The part before the // isn’t really part of what
you want to consider in your network routing scenario, neither is anything
that comes after the first /).
It’s not that we couldn’t use some form of hierarchically structured human-
readable name for this purpose… It’s that using DNS host names _REALLY_
wouldn’t work well.
Except what if we used basic textual representations for addresses that kind of looked like DNS names, but didn't actually try to use DNS names? Let's even assume we keep DNS largely unchanged, but introduced "B records" to handle the new addressing scheme, similar to how we introduced AAAA records to handle translating between names and IPv6 addresses. Perhaps we also add a special-case "TLD-alike" called .address to indicate when we want to connect to the specified address and not do a DNS lookup of the name we've requested?
For example, let's say my internet domain is
nanog.org. I might have DNS setup for
nanog.org, but I may also claim addressing space under
nanog.org. Since my ASN is 64500, I will use it to advertise "
nanog.org" to my peers: so when you check a looking glass for
nanog.org, you'll see that it's routing to AS 64500 just like any IPv4 or IPv6 announcement.
Now if you want to visit a website called
www.nanog.org, and you punch that into your web browser, it's going to do a DNS lookup. Assuming this addressing scheme is preferred over IPv4 or IPv6, the first thing your browser will do is a DNS lookup for a B record for "
www.nanog.org" - and in my
nanog.org zone, I'll have one or more B records pointing to the address hosting the site, for example:
Upon receiving this, your browser will then initiate a port 443 TCP connection (or UDP for QUIC or whatever its protocol of choice is, in this, the year 3305) to
webserver1.nanog.org, which is what will be in the packet headers. Its upstream router will see this and route it until it reaches a member of the DFZ at which point that DFZ router will then determine that "
webserver1.nanog.org" is part of "
nanog.org" and that "
nanog.org" is announced by AS64500 which is available from two transit providers, prefer one of them based on whatever traffic engineering rules are the norm in 3305, and send the packet on to the next hop for that route.
When I think about it, this actually seems shockingly reasonable, potentially massive RAM requirements for routers aside (we're getting there anyway!). Am I missing something?