worse than IPv6 Pain Experiment

Thu Oct 10 01:43:22 UTC 2019

On Wed, Oct 9, 2019 at 5:28 PM Owen DeLong <owen at delong.com> wrote:

>
> > 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:
www.nanog.org. IN B webserver1.nanog.org
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.
On the other hand, if you wish to simply load whatever comes up when you
make an HTTPS request to port 443 on webserver1.nanog.org, you might enter "
https://webserver1.nanog.org.address/" which will then skip the DNS check
and simply try connecting to webserver1.nanog.org.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191009/1e560540/attachment.html>