Re: worse than IPv6 Pain Experiment

[bzs]

On October 9, 2019 at 17:12 b...@herrin.us (William Herrin) wrote:
 > On Wed, Oct 9, 2019 at 4:30 PM John R. Levine  wrote:
 > > > Can I summarize the current round of objections to my admittedly
 > > > off-beat proposal (use basically URLs rather than IP addresses in IP
 > > > packet src/dest) as:
 > > >
 > > >  We can't do that! It would require changing something!
 > >
 > > Nope.  You can summarize it as "it doesn't scale", which is what has
 > > killed endless numbers of superficially plausible bad ideas.
 > 
 > And Barry's been around long enough to know this. What's up Barry? What's the
 > meta-argument you're trying to make here 'cause "bits is bits" is about as
 > smart as telling a chef that "food is food."

Some brought up objections to IPv6 one of which was that its long hex
strings are difficult to remember compared to IPv4 addresses.

I first suggested that might be largly a human interface issue more
than a flaw in the design.

Then I remembered a talk I gave in Singapore, intended to be
controversial, suggesting the use of essentially URLs as a superset of
"domain names", but whatever, everyone knows what I mean, as actual
addresses in packets.

Just trying to stimulate some thinking beyond IPv6 and assessing where
we are in general terms regarding for example changes in hardware etc
availability since IPv6 was first being developed ca 1990.

Particularly in a context where the less than stellar adoption of IPv6
is an issue.

Some, most, of the comments have been very interesting and also
thought-provoking.

Others amounted to "but where do we put the gasoline in this
new-fangled electric car?!" (yes some fundamental things would need to
be redesigned), some wanted the entire design right here and right now
(sorry!), and a few basically revealed people who've never to my
knowledge managed anything more complicated than a zippo lighter
claiming profound and intuitive insight into mass scalability.

But as I said it's a few RFCs short of an internet.

Just meant to stir some discussion: Is there life after IPv6? What
might motivate another round of evolution and by whom?

My sense is these questions might be more imminent than some may want
to believe given the rise of issues such as security, privacy,
government control, accountability, legal and insurance issues, and a
multi-trillion dollar economy riding on this internet little of which
was really on the table in, say, 1990.

For example given the relatively low adoption of IPv6 and the
impossibility (pretty much) of going forward with IPv4, and the new
realities I mention, might someone(s) with sufficient interest and
capitalization and influence push to knock over the whole game board?

They marched us into a box canyon!

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

RE: worse than IPv6 Pain Experiment

[Kevin Menzel]

> Bits is bits.

A fixed length bit field and a variable length bit field are incredibly 
different beasts at the hardware level. Knowing exactly after how many bits you 
can make a routing or switching decision is ... pretty darned useful.

Kevin Menzel
Infrastructure Analyst
Sheridan College

-Original Message-
From: NANOG  On Behalf Of b...@theworld.com
Sent: Wednesday, October 9, 2019 5:43 PM
To: John Levine 
Cc: nanog@nanog.org; b...@theworld.com
Subject: Re: worse than IPv6 Pain Experiment


OK OK OK.

Can I summarize the current round of objections to my admittedly off-beat 
proposal (use basically URLs rather than IP addresses in IP packet src/dest) as:

  We can't do that! It would require changing something!

I've no doubt many here are comfortable with the current architecture.

Bits is bits.

URLs are, to a machine, just bit strings though they do incorporate a 
hierarchical structure which isn't that dissimilar from current network/host 
parts of IP addresses.

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.

Given the vast improvements in hardware since we last seriously thought about 
this (ca. 1990, IPv6) perhaps this worship of bit-twiddling and bit-packing may 
be a bit (haha) like those who once objected to anything but machine language 
programming because HLLs were so inefficient!

P.S. It was from a talk I gave in Singapore to the local HackerSpace and 
intended to provoke thought and discussion but not just "no, we can't do that 
because that's not the way we do things."

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: worse than IPv6 Pain Experiment

[Tony Finch]

b...@theworld.com  wrote:
>
> Can I summarize the current round of objections to my admittedly
> off-beat proposal (use basically URLs rather than IP addresses in IP
> packet src/dest) as:

[snip]

This reminds me of the named data networking research project

https://named-data.net/project/faq/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Southwest 6
to gale 8, occasionally 5 at first, then veering west or northwest 3 to 5
later. Moderate or rough, occasionally very rough later in far south. Rain or
showers. Moderate or good, occasionally poor later.

Re: worse than IPv6 Pain Experiment

[Owen DeLong]

> On Oct 9, 2019, at 18:43 , Matt Harris  wrote:
> 
> On Wed, Oct 9, 2019 at 5:28 PM Owen DeLong  > 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  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. 

Except that’s not how it works for IPv4 or IPv6 announcements. You don’t route 
to an ASN (for better or worse, worse IMHO, but hard to fix at this point). You 
route to a next-hop (NLRI) and ASNs are primarily for loop detection/prevention 
and demarcation of boundaries of administrative control.

Other than what you do in policy based on the AS PATH or other AS-related 
attributes, they really have zero significance in forwarding decisions.

> 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. 

Well, I’m not wild about the addressing scheme and I think it creates 
tremendous potential for confusion (and some serious implementation challenges 
for fast packet switching), but, I do like the idea of DFZ routing being based 
on destination ASN and candidate routes rather than on specific IPv4/IPv6 
next-hop addresses.

Also, you state two transit providers as if that is a simple 
router-implementable concept. That’s very hand-wavy in today’s world. Consider 
the following…

Let’s say we have transit providers A and B. You are ISP Q. You have border 
routers numbered Q01 to Q50 scattered around the world. Let’s say that each of 
these routers peers with at least one of {A,B} and that some of them peer with 
both.

For a packet arriving on any Qn router, the answer is relatively simple (pass 
it to a local peering session and you’re done.).

Now, consider the scenario where 25% of your routers peer with A and 25% peer 
with B, but the two groups have a 50% overlap (12.5% of your total routers peer 
with A and B).

The packet arrives at one of your routers Qn that is not a member of that 37.5% 
total (12.5% A only, 12.5% B only, 12.5% both) routers that are peered with 
either A or B.

However, you have an indirect path on Qn via another transit AS Z that is 
announcing both A and B as reachable via its network.

Do you forward the packet internally to a 

Re: worse than IPv6 Pain Experiment

[Matt Harris]

On Wed, Oct 9, 2019 at 5:28 PM Owen DeLong  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 
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?

Re: worse than IPv6 Pain Experiment

[Masataka Ohta]

John R. Levine wrote:

There's only a few thousand top level domains, so routers should he able 
to handle this with no problem.  Whaddaya think?


Hierarchy inconsistent with network topology is useless for routing.

Masataka Ohta

Re: worse than IPv6 Pain Experiment

[William Herrin]

On Wed, Oct 9, 2019 at 4:30 PM John R. Levine  wrote:
> > Can I summarize the current round of objections to my admittedly
> > off-beat proposal (use basically URLs rather than IP addresses in IP
> > packet src/dest) as:
> >
> >  We can't do that! It would require changing something!
>
> Nope.  You can summarize it as "it doesn't scale", which is what has
> killed endless numbers of superficially plausible bad ideas.

And Barry's been around long enough to know this. What's up Barry? What's
the meta-argument you're trying to make here 'cause "bits is bits" is about
as smart as telling a chef that "food is food."

Regards,
Bill



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: worse than IPv6 Pain Experiment

[John R. Levine]

Can I summarize the current round of objections to my admittedly
off-beat proposal (use basically URLs rather than IP addresses in IP
packet src/dest) as:

 We can't do that! It would require changing something!


Nope.  You can summarize it as "it doesn't scale", which is what has 
killed endless numbers of superficially plausible bad ideas.


Like I said, if there were a few thousand URLs it could work, but with 
hundreds of millions or billions, not a chance.  Numbers with five zeros 
and numbers with nine zeros are not the same.


But while we're proposing bad ideas, how about this one: we pull the 
domain name out of the URL and flip it around and put it at the front, so 
instead of https://badidea.com/crud we have "com.badidea/https://crud.; 
Now we can do hierarchical routing, starting with the "com" and then 
"com.badidea", shoving the DNS resolution into the router.


There's only a few thousand top level domains, so routers should he able 
to handle this with no problem.  Whaddaya think?


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: worse than IPv6 Pain Experiment

[Valdis Klētnieks]

On Wed, 09 Oct 2019 17:43:00 -0400, b...@theworld.com said:

> 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.

So explain in detail how a router gets from "URL" to "which interface to send 
the
packet on".  Include in your discussion how anycast works, and how to deal with
things like www.google.com, which currently uses DNS and geolocation so not
every host on the internet has the same view of what server(s) to contact.

Problem example:  My employer moved something from a 128.173/16 address
to a 198.82/16 address without changing the name.  How would your scheme
address the fact that the routing may have changed, when the URL/hostname 
remains
the same?

Hint:  If URLS or hostnames actually identified routing endpoints, we'd not 
have DNS.



pgpDSR49wNpe0.pgp
Description: PGP signature

Re: worse than IPv6 Pain Experiment

[Masataka Ohta]

b...@theworld.com wrote:


URLs are, to a machine, just bit strings though they do incorporate
a hierarchical structure which isn't that dissimilar from current 
network/host parts of IP addresses.


Wrong.

CIDR hierarchy (available within ASes) has strong correlation
to network topology that locations below certain hierarchy
are strongly connected, which is why, from out side of the locations,
packets may be routed only looking at that levels of hierarchy.

OTOH, hierarchy of domain name represents organizational
structure with weak relationship to topology. No internal connection
can be expected and it is not useful for proxy routing.

They are dissimilar.

Masataka Ohta

Re: worse than IPv6 Pain Experiment

[Owen DeLong]

> On Oct 9, 2019, at 14:43 , b...@theworld.com wrote:
> 
> 
> OK OK OK.
> 
> Can I summarize the current round of objections to my admittedly
> off-beat proposal (use basically URLs rather than IP addresses in IP
> packet src/dest) as:
> 
>  We can't do that! It would require changing something!

No… You can summarize it as “Doing things that way would break lots of
useful things without yielding much in the way of practical benefit.”

> I've no doubt many here are comfortable with the current architecture.

Well, sure, but I bet most of us would jump at the chance for something
better if we actually saw such a thing. I’m all for trying out the wild and
crazy ideas that might yield benefit. I just don’t think that what you have
proposed so far actually qualifies on that last part.

> Bits is bits.

Yes and no. At the lowest possible layer, a bit is a bit is a bit. However,
when you add abstraction and assign meaning, such as ASCII characters,
double-precision floating point, URLs, IPv6 (or if you must, IPv4) addresses,
OSPF Areas, Autonomous System Numbers, etc., then groups of bits start
to take on additional significance.

It matters how we represent, process, interpret, store, and manage those bits.

Different methodologies of each of those tasks are more or less appropriate
for each given application. For example, a straight twos-compliment binary
numeric interpretation of a 64-bit wide field with the MSb for sign and the
remaining bits as significant digits is fantastic for integer arithmetic, but 
nearly
useless for arbitrary precision manipulation of fractions. On the other hand,
IEEE 754 floating point format of 32 bits where the MSb is for sign, the next
8 bits represent the exponent, and the remaining 23 bits represent the
significant digits (“fraction” in IEEE terms) is very useful for arbitrary
precision manipulation of fractions, but not at all good at integer math,
especially for integer numbers that require low order precision, but have
values greater than 2^23.

Similarly, the current structure of IPv6 (and if you must, IPv4) addresses
provides tremendous utility for moving packets about the internet. It’s not
great at providing human-readable destination addresses. It’s also not
great at providing geographic location information. Both of those are tasks
for which those particular representations were never intended.

There’s a reason that we have compact cars and B-trains (double
trailer tractor-trailer rigs). A compact car is lousy at moving massive
quantities of products. OTOH, a B-Train doesn’t fit in the average
parking space very well and is hard to maneuver down most residential
streets. (It also gets really lousy gas mileage for single-person 
transportation).

We purpose build things in different ways to optimize them for different tasks
throughout human history. Addresses are no different.

> URLs are, to a machine, just bit strings though they do incorporate a
> hierarchical structure which isn't that dissimilar from current
> network/host parts of IP addresses.

Well, yes and no. For example, it’s not uncommon for a domain, say
toyota.com, to be widely distributed across multiple networks of wildly
different topologies.

With the exceptions of anycast and multicast, it’s very unusual (I’d even
venture to say unheard of) for a globally scoped address to be usefully
deployed on multiple connected disparate networks without some
sort of translator in the middle).

Neither end of a URL provides anything resembling network topological
hierarchy.

> 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.

> Given the vast improvements in hardware since we last seriously
> thought about this (ca. 1990, IPv6) perhaps this worship of
> bit-twiddling and bit-packing may be a bit (haha) like those who once
> objected to anything but machine language programming because HLLs
> were so inefficient!

Or, perhaps, it’s not actually a love of bit-twiddling so much as a recognition
that there are serious flaws with the idea of trying to use DNS host names
for routing decisions.

Come back with a more useful naming scheme that takes topology into
consideration and lines up where routing decisions need to, and let’s
discuss it more seriously. Continue pounding on DNS host names and
you’re not going to make much headway because, well, it’s not quite
the dumbest thing I’ve ever heard, but it isn’t that far off.

> P.S. It was from a talk I gave in Singapore to 

Re: worse than IPv6 Pain Experiment

[bzs]

OK OK OK.

Can I summarize the current round of objections to my admittedly
off-beat proposal (use basically URLs rather than IP addresses in IP
packet src/dest) as:

  We can't do that! It would require changing something!

I've no doubt many here are comfortable with the current architecture.

Bits is bits.

URLs are, to a machine, just bit strings though they do incorporate a
hierarchical structure which isn't that dissimilar from current
network/host parts of IP addresses.

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.

Given the vast improvements in hardware since we last seriously
thought about this (ca. 1990, IPv6) perhaps this worship of
bit-twiddling and bit-packing may be a bit (haha) like those who once
objected to anything but machine language programming because HLLs
were so inefficient!

P.S. It was from a talk I gave in Singapore to the local HackerSpace
and intended to provoke thought and discussion but not just "no, we
can't do that because that's not the way we do things."

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: worse than IPv6 Pain Experiment

[John Levine]

In article <23963.65395.763065.591...@gargle.gargle.howl> you write:
>So I proposed we dump numeric addresses entirely and use basically
>URLs in IP packets and elsewhere.
>
>I really meant something like 'IP://www.TheWorld.com' in the
>source/dest addr, possibly more specific for multiple interfaces but
>whatevs.
>
>Leave out the implied 'IP://' and my example is 16 chars just like
>IPv6.
>
>Routers could of course do what they like with those internally such
>as maintain a hash table to speed look-ups. Not anyone outside of
>router software developers' problem. ...

This is more or less equivalent to using device MAC addresses
everywhere.

I think that if you talk to people who build routers, you will find
that they depend really heavily on the detail that every IP address
has a network part and a host part, and they route using the network
part.

Ethernet switches send traffic to arbitrary MAC addresses, at the cost
of remembering every MAC address they've seen, typically in a table
with a few thousand entries.  I know you've been on the net long
enough to remember the good old days when there were only a few
thousand URLs, but I fear it's unlikely we'll go back there.

R's,
John