
The world in which IPv6 was a good design (2017) - beefhash
https://apenwarr.ca/log/20170810
======
tptacek
What a great post, about something I've been working on almost as long as
Avery. I'm sad I missed it the first time it came around.

I was going to write a long response here, but I think I'll save that for a
blog post (short summary: I disagree vehemently with what I believe the
premise here to be, think that people shouldn't be waiting for the IETF to
give them permission to build new network layers, am fairly certain there's no
such thing as a "layering violation", and think overlay networks are/will-
ultimately make IPv6 irrelevant). So on this thread I'll just pick some nits.

Ethernet networking is not as gross as it's made out here. ARP isn't entirely
pointless! For instance, at the ISP I ran tech for in the 1990s, I was able to
pretty seamlessly move our "data center" and corporate offices across Chicago
without renumbering just by exploiting ARP (I wrote a dumb proxy ARP policy
router). We did similar things to route traffic to the particular terminal
services customers were dialing into, or to the ISDN router who's PRI happened
to service a particular customer. An IP purist would object that we weren't
using OSPF the way God intended us to, but it worked and was probably more
reliable than the bona fide routing protocols we replaced that with.

This narrative also, I think, gives short shrift to DHCP, which does a lot
more than pick IP addresses out for new endpoints, but also pretty much fully
configures their IP connection. If you had to tech support 10,000 random
customers in the era before DNS servers were transparently assigned at
connection, you're not pining for the simple elegance of RARP.

Also: nobody should care about "IGMP-snooping bridges", since IP multicast is
and always was hopeless.

~~~
ChuckMcM
I was going to say the same thing, so I won't :-). That said, I was in the Sun
Systems group when Bob Hinden ("Boss Bob" (there were three Bobs in the group)
of the network group was proposing SIPP as the "next generation IP." It has
been illustrative (but I don't think educational alas) to see how much more
easily this protocol would have managed to be implemented and deployed.

That said, as Thomas points out (indirectly) in the parent to this comment,
the Internet was deployed across a pre-existing network (the telephone
switching network) without any co-operation from the people who defined or
wrote or deployed the protocols the implement telephone switching. As long as
the connection from point A to point B worked, the packets could figure out
how to get from A to B. There is absolutely nothing preventing a suitably
motivated group from creating their own elegant "network" that they layer on
top of the existing broadband networks of today, without having to either
consult, or get permission from, any standards organization.

~~~
mrkstu
That is essentially what most SD-WAN devices do- treat the Internet as an
'underlay' network- most of them are using proprietary code to create their
own network infrastructure that isn't standards based.

~~~
jiveturkey
It generally is standards _based_. Their customers demand it to be so. IPSec
tunnel overlays, usually if not always full mesh. The non-standard part is
tiny insignificant tweaks to IPSec that render it unacceptable to standards
speaking endpoints, thus you can't coordinate with your open source IPSec
device. Stupid myopia, because these systems depend on proprietary
orchestration anyway.

~~~
basch
+1 for velocloud. SDWAN mesh between all your devices, and they provide a
cloud gateway that allows you to connect to any compatible ipsec device,
without having to backhaul all the data to one specific endpoint.

------
wahern
> Edit 2017-08-16: It turns out that nothing in this section requires IPv6. It
> would work fine with IPv4 and NAT, even roaming across multiple NATs.

That's not quite fair. IPv4 and NAT require maintaining a lot of state at
critical intermediate routers. I'm sure we've all experienced (perhaps
regularly) a NAT'ing router losing state because of a reboot, state tables
overflowing, or similar hiccups.

The one absolutely redeeming quality of IPv6 is that with 128 bits routing can
be kept much more hierarchical and stateless. Fragmentation will occur and is
occurring because we now apply trust metrics to IP addresses (thanks,
spammers!) so there's value in owning transferable subnets, but I think IANA
and major ISPs can keep the fragmentation process slow enough that
hardware/software capabilities can stay apace, preserving a largely stateless,
hierarchical routing infrastructure.

That doesn't solve the mobility problem, but it does provide significant
benefits to mobility solutions. Don't underestimate the cost of NAT'ing in
terms of systems complexity. NAT'ing isn't the type of layer, like ethernet
MAC addressing, that we'll always be stuck with.

It's also worth pointing out that some of the [now] unnecessary complexity of
IPv6 will fall away over time. IPv6 will get simpler as time progresses, as it
already has.

~~~
thaeli
> The one absolutely redeeming quality of IPv6 is that with 128 bits routing
> can be kept much more hierarchical and stateless.

For now. Yes, 128 bits is a lot. Yes, even the 64 bit host-part is a lot. But
the old-fashioned, pre-CIDR allocation strategy of IPv6 is _incredibly_
wasteful of address space. There are advantages, and for a single-planet, pre-
IoT Internet, that's plenty. But IPv6 has taken so long to adopt, and future
major stack changes will only be harder, that we really do need to think about
what will work for the Internet a hundred years from now.

~~~
zAy0LfpBZLC8mAC
> But the old-fashioned, pre-CIDR allocation strategy of IPv6 is _incredibly_
> wasteful of address space.

What would be wasteful would be keeping even more address space unallocated,
as that would cause all kinds of costs, from administrative overhead,
incentives to build unnecessarily suboptimal networks, delays due to address
allocation processing, to more fragmented and thus larger routing tables and
renumbering.

Saving address space for the sake of saving address space is not useful.

~~~
kortilla
But a 64 for a single host isn’t driven by any of that.

~~~
zAy0LfpBZLC8mAC
Who is suggesting that you use "64"(?) for a single host?

------
simias
I don't find IPv6 complicated, if anything it's a lot easier to grasp than
IPv4 and it basically comes with batteries included.

The difficulty in my experience stems from one thing and one thing only: you
can almost never go full IPv6. You always have to dual stack IPv4/IPv6, and of
course IPv4 + IPv6 is always strictly more complicated than just IPv4.

I've had the opportunity to develop a solution using an IPv6-only environment
and it was a pleasure to work with. No need to worry about the size of your
subnets or clashing with 3rd party tools using the same address space etc...

>Wouldn't it be better if it had just been IPv4 with more address bits?

I often hear that but I genuinely don't get it. This change would effectively
give you all the problems with IPv6 (i.e. you have to make sure all your
hardware and software equipment can deal with the new, backward-incompatible
format) without all the niceties that IPv6 provides. It's genuinely the worst
of both worlds. NAT is probably the best compromise you can get, using the
port number to sort-of extend the address information to identify several
computers with the same IP, but it's obviously an ugly hack with many
limitations.

~~~
kortilla
IPv6 pretty much requires DNS. There are tons of dead simple networks out
there that administrators just memorize IP addresses on trivially.

~~~
PopeDotNinja
0.0.0.0

1.1.1.1

8.8.8.8

192.168.0.1

^^^ burned into my brain

2001:0db8:0000:0000:0000:ff00:0042:8329

^^^ say what now?!

~~~
Dagger2
This is totally an unfair comparison. Why did you complicate the v6 address?
That's 2001:db8::ff00:42:8329, which is a fair bit shorter than the version
you wrote.

But let's go a step further. If you wanted to remember this address, why did
you pick 2001:db8::ff00:42:8329 in the first place? Why not 2001:db8::53?

If you deliberately pick an address that's longer and more complicated than it
needs to be, and you refuse to use the system (DNS) that's designed to handle
that for you, then you don't get to complain about how long and complicated
the address is.

~~~
PopeDotNinja
I just cut & paste the IPv6 I found in a Wikipedia. But that does touch on a
good point... the formatting for how to express an IPv6 number is more
complicated. The fact that 2001:0db8:0000:0000:0000:ff00:0042:8329 can be
shorted to 2001:db8::ff00:42:8329 is less simpler to figure out than the good
ol' <8bits>.<8bits>.<8bits>.<8bits> IPv4 format (at least that is true for
me).

~~~
Dagger2
It's not that complicated. You can add leading zeros into each field, but
that's similar to how 192.168.0.1 can be written as 192.168.000.001 (but if
you do that in v4, it turns the field into octal! At least in v6 it's just a
superfluous 0.). The only real complication is ::, which just means "insert
zeros here".

(192.168.0.1 can also be written as 192.168.1, 192.11010049 or 3232235521. Or
192.0xa80001. Or 0xc0.0xa80001. Or 0300.168.1. Or a good number of other ways.
That's far worse than anything you can do to a v6 address.)

~~~
astrobe_
> but that's similar to how 192.168.0.1 can be written as 192.168.000.001

I would advise you not to do that. Some systems read the numbers with _atoi()_
, which will interpret a leading zero as a prefix for 'octal' like in C.

~~~
rswail
well that won't make a difference for 0.1 :)

~~~
Dagger2
Yup, I was paying attention to that. Note how adding a leading 0 to 192 made
it 0300.

And people think this is easier than v6, where adding a 0 to db8 just makes it
0db8...?

------
mcguire
" _To do that pointless intermediate step [converting a router 's IP address
to its MAC address], you need to add ARP (address resolution protocol), a
simple non-IP protocol whose job it is to convert IP addresses to ethernet
addresses._"

Well, _technically,_ ARP is how _every_ IP address is converted to a MAC
address. If the IP address is not local (determined by the address, the host's
own address, and the subnet mask), the host ARPs for the router interface; if
it is local, it ARPs for the destination address.

" _They 're nowadays almost inseparable. It's hard to imagine a network
interface (except ppp0) without a 48-bit MAC address, and it's hard to imagine
that network interface working without an IP address._"

Well, _technically,_ it's not: CAN (11-bit "address"/priority/identifier
thingy), ZigBee (16-bit? 64-bit? I dunno.), Bluetooth, etc.

In case you're wondering, there is a long tradition of these kinds of rants.
Everything would be perfect if the IETF had done X instead of Y, if FOO had
happened instead of BAR, if Steve Deering had tripped over his own wineglass
model and received a traumatic brain injury (or not tripped over the wineglass
and not received the brain injury; I'm not clear on that).

There's even people who argue we should have gone with the OSI protocols from
the start, although they are literally evil cultists who prefer the worst
possible option. (Wait, why does that sound appealing?)

~~~
pdkl95
> there is a long tradition of these kinds of rants. Everything would be
> perfect if the IETF had done X instead of Y

[https://tools.ietf.org/html/rfc1925](https://tools.ietf.org/html/rfc1925)

see (10), (11)

[and (11a) always applies]

~~~
mcguire
" _(7a) (corollary). Good, Fast, Cheap: Pick any two (you can 't have all
three)._"

Hell, you're exceptionally lucky to have one.

------
zamadatix
> "Bridging is still, mostly, hardware based and defined by IEEE, the people
> who control the ethernet standards. Routing is still, mostly, software based
> and defined by the IETF"

I disagree, the dataplane of each is usually hardware and the control plane of
each is usually software. I think the dismissal of things like broadcast
learning, ARP, and even DHCP to an extent, leads to the confusion.

> You know these "IP" headers are nonsense because the DHCP server has to open
> a raw socket and fill them in by hand; the kernel IP layer can't do it.

What the kernel IP layer exposes has little to do with whether something is a
"real" IP packet. Under the guise of security anything that wasn't UDP or TCP
bound to an OS configured IP interface isn't part of kernel IP sockets
anymore. This historical conflation of IP = place to bind layer 4 socket is
one reason why QUIC is UDP based.

------
Dunedan
As this post talked a bit about the history of computer networks I have to
jump in and highly recommend "Where Wizards Stay Up Late: The Origins Of The
Internet" ([https://www.amazon.com/Where-Wizards-Stay-Up-Late-
ebook/dp/B...](https://www.amazon.com/Where-Wizards-Stay-Up-Late-
ebook/dp/B000FC0WP6)) to everybody curious about how that thing called
internet came to be. It's such a great book about an era not so long ago, but
often already forgotten.

~~~
RyanShook
Reading it now and highly enjoying it! I’ve recently shared some of the early
specs from BBN and RFCs here on HN if anyone is interested in early internet
as well.

------
dboreham
Much history rewriting here. The author is wrong about mobile use cases not
being thought about when IPng was being worked on. I remember hearing talks
about how to interoperate across wireless lans and WANs, seamlessly, at the
same IETF meeting events. Wireless LANs existed back then and so did Wireless
WAN services. They were just slower and more expensive than today's and of
course not widely used. The first wireless WAN I used with TCP/IP on a laptop
was in 1994 FWIW. 8kbits/s.

------
lolc
I remember sitting in the sun ten years ago, wondering about all the layers
and how there's no need for a MAC address when you have an IP6 address. Then I
wondered why it's not like that. So that was a depressing read in the sense
that there is no a priori reason it shouldn't be that way. Just hacks after
hacks as usual.

~~~
jandrese
It's like that so you can send your IPv6 packets over 20 year old switches and
have them still work. Switches don't care about the IP layer, all they look at
is the MAC layer.

~~~
lolc
Wouldn't it be nice if modern switches could properly route packets without
them being framed in legacy protocols? This could be negotiated when you
connect to them. But because it's only marginal gain and needs dual-stack
switches we just keep the hacks.

Maybe one day.

~~~
zamadatix
Then it'd be a router not a switch and you'd have to replace the router before
you can use the new protocol (see: the current IPv6 deployment situation.

This is why layer 2/Ethernet is a valuable abstraction layer not just a
"legacy protocol". It allows seamless transition to the new layer 3
abstraction without having to replace all of the hardware everywhere at once.

~~~
lolc
Here's the thing though: Managed switches are often configured like routers.
And even dumb switches have "dynamic route discovery" if we want to call it
that.

It would be nice if this could be negotiated away to get a pure IP6 link. If
an intermediate link doesn't support that, legacy addressing could still be
used. I'm not saying we don't need NDP, just that it would be nice if it could
eventually be phased out.

~~~
zamadatix
If you're configuring something like a router then it's a router. It may be a
crap router but if it routes it's still a router.

> It would be nice if this could be negotiated away to get a pure IP6 link.

Then you'd need WiredIPv6, WirelessIPv6, 4GIPv6, 5GIPv6... layer 2 provides
the ability for an abstracted physical layer to transport an abstracted
network layer. Remove it and any time the physical layer changes the network
layer needs to as well as each of these have unique headers, formats, and
data-link capabilities (not all support broadcast for example!).

Every abstraction layer is actively used today, remove it and there is a cost.

------
kazinator
There was no such world.

IP could be easily widened just by taking IP addresses to 64 bits, allocating
some new protocol numbers for that, and keeping everything _exactly_ the same.
In applications, the same old quad dot notation would work textually: 0.0.0.0
to 65535.65535.65535.65535, the latter being the broadcast address and so on.

The IPv4 space could be embedded such that 1.2.3.4 is both an IPv4 address
made of octets, and an "IPv5" made of four hexadecades. Gateways and protocol
stacks could convert the packet formats on the fly: a wide packet with
addresses whose four values are below 256 could be narrowed, and then received
received by IPv4. An IPv4 packet could be widened to "IPv5".

No stupid "neighbor" protocol; just good old ARP, widended to 64 bit IP
addresses.

Machines now have native integers that can hold a 64 bit IP address; great for
all the masking operations in routing logic and whatnot.

~~~
cesarb
"Just widen the addresses" ideas like that are easy to come up with (though
they usually keep the IPv4 address as either the prefix or the suffix of the
"new" address), but the elephant in the room is always the same: how would a
legacy host which only understands classical IPv4 (with 32-bit addresses) talk
to a host which only has "new" (wider than 32-bit) addresses?

~~~
kazinator
> _how would a legacy host which only understands classical IPv4 (with 32-bit
> addresses) talk to a host which only has "new" (wider than 32-bit)
> addresses?_

Hosts with 64 bit addresses would have to support 32 bit addresses also, just
like is the case with IPv6 hosts that have to have IPv4 stacks.

Under 64 bit addresses, it's conceivable that in fact there would not
necessarily have to be an entire IPv4 stack; just protocol conversion to widen
and unwiden the data format.

The stack would have to know that certain connections have IPv4 peers, and so
it would parse IPv4 datagrams coming from those hosts, and likewise send them
IPv4 datagrams.

It could be designed such that if the source and destination addresses
(A.B.C.D) of a connection are such that A <= 255 && B <= 255 && C <= 255 && D
<= 255, then the hosts may optionally use the smaller IPv4 packet format.

~~~
cesarb
Start from the other end: how would an IPv4-only host with an IP address of,
for instance, 198.51.100.1, initiate a connection to a host with a "new"
address of 459.256.369.257? The host at 459.256.369.257 can understand the
"198.51.100.1" address, but the host at 198.51.100.1 has no way to represent
459.256.369.257 as the destination address in an IPv4 packet.

And even if the answer is "they can't initiate a connection", the same problem
also happens in the opposite direction. When the host at 459.256.369.257
initiates a connection to the IPv4-only host at 198.51.100.1, what should it
put in the "source address" field, which only has 32 bits since it's an IPv4
packet? If it puts a dummy address there, how would the reply to that packet
reach it?

~~~
kazinator
> _how would an IPv4-only host with an IP address of, for instance,
> 198.51.100.1, initiate a connection to a host with a "new" address of
> 459.256.369.257?_

The destination address obviously makes no sense to the IPv4-only host, being
outside of the space that it understands, so a direct connection is obviously
impossible. (Are you even asking seriously, or is this just snark?)

The wide-address host would have to have an additional IPv4-compatible address
bound to its network interface. Or else some other host would have to have
such an IPv4-compatible address on its behalf and do NAT or proxying.

~~~
cesarb
> so a direct connection is obviously impossible. (Are you even asking
> seriously, or is this just snark?)

I am asking seriously, both because I've seen proposals where the proposer
does seem to sincerely believe it to be possible to somehow fit more than 32
bits in a 32-bit field (that was a truly baffling one), and because it _is_
possible with stateful hacks similar to NAT64/DNS64 (that is: when the host at
198.51.100.1 tries to look up the address of the host at 459.256.369.257, it
receives a fake but valid address, and a router in the path knows to map the
fake address to the real address while doing all the necessary NAT
shenanigans).

> The wide-address host would have to have an additional IPv4-compatible
> address bound to its network interface.

Then you gain nothing other than extra complexity, since the total number of
hosts is still limited by the 32-bit IPv4 address.

> Or else some other host would have to have such an IPv4-compatible address
> on its behalf and do NAT or proxying.

Then not only you gain nothing by making your "new" addresses a superset of
IPv4 addresses, but also you start looking like IPv6 ended up being, with all
its transition mechanisms.

~~~
kazinator
> _I 've seen proposals where the proposer does seem to sincerely believe it
> to be possible to somehow fit more than 32 bits in a 32-bit field._

Ah, well, that's obviously not a computer programmer with more than 2 or 3
years of experience. :)

> _Then you gain nothing other than extra complexity, since the total number
> of hosts is still limited by the 32-bit IPv4 address._

Have we gained nothing?

Consider that the majority of the IP addresses in the network are individual
subscriber IP addresses, not servers. So we can have a transitional situation
in which major service providers use the old 32 bit address space (so they are
reachable by every client, 32 or 64 bit), while we put new subscribers into
the 64 bit address space.

The users who remain in the 32 bit space will increasingly find that they
can't connect to some servers that are in the beyond-32 parts of 64 space, so
they will have to upgrade their systems.

Users in 32 space cannot do peer-to-peer with 64 users outside of that space,
of course.

~~~
lmm
> Consider that the majority of the IP addresses in the network are individual
> subscriber IP addresses, not servers. So we can have a transitional
> situation in which major service providers use the old 32 bit address space
> (so they are reachable by every client, 32 or 64 bit), while we put new
> subscribers into the 64 bit address space.

> The users who remain in the 32 bit space will increasingly find that they
> can't connect to some servers that are in the beyond-32 parts of 64 space,
> so they will have to upgrade their systems.

> Users in 32 space cannot do peer-to-peer with 64 users outside of that
> space, of course.

i.e. exactly the same situation that we currently have, only it would be less
visible whether you've upgraded, and harder to debug when you had?

The hard part of deploying IPv6 isn't that the protocol is different (indeed
the protocol is significantly simpler e.g. removing fragmentation). The hard
part is that it's necessarily a new global routing table, that you necessarily
can't use it between two hosts unless every router in between them supports it
and has the routes set up. A more IPv4-like packet format would not change
that at all.

~~~
kazinator
You might not have identified the really hard part.

Which is this: reams of application code is hard-coded to the AF_INET address
family, and its binary _sockaddr_in_ structure, and related data types and
functions.

But that's a problem facing any proposed or actual IP facelift.

------
runjake
I was an early adopter implementing and administering IPv6 in a large
enterprise, and I still am administering it. It was a shit show for years but
in recent years client support has stabilized.

However, I've recently, I've come to my own conclusion that IPv6 is largely
doomed and that it will be usurped by IPv4 NATs/CGNATs and >L3 improvements
like QUIC, DTLS, etc. Why?

IPv6 is complex and unfamiliar and has a big learning curve. People aren't
going to "put up with it". They're going to adapt what they have
(skills/tools/etc) and they're doing a good job of it.

I always get asked by people about IPv6 and how they should get started and my
present advice is to "hold off, for now". I'm not even sad about that. The
world is evolving and when framed properly, it doesn't seem that bad.

~~~
betterunix2
I find IPv6 to be simpler than IPv4 -- once I stopped trying to reason about
things in IPv4 terms. The only real complexity I have encountered is in the
various efforts to maintain compatibility with IPv4.

One way or another IPv4 will go away. The limits of scale were hit years ago
and the workarounds break applications (NAT is basically a violation of the
end-to-end principle and the results are predictable), and merging IPv4
private networks is a nightmare.

~~~
kortilla
I don’t see it. No users care that NAT breaks the end to end principle. That’s
only something users care about that want to accept connections, which is <1%.

TCP and UDP have been running over NAT for so long that they work completely
fine. People who make the mistake of assuming asymmetric ports or putting IPs
in the payload fail so early that they quickly learn.

There is so little actual pressure to implement ipv6 that it’s starting to
look pretty doomed.

~~~
johncolanduoni
> I don’t see it. No users care that NAT breaks the end to end principle.
> That’s only something users care about that want to accept connections,
> which is <1%.

I'm not sure <1% of users want to video chat or to play games without
dedicated servers.

> There is so little actual pressure to implement ipv6 that it’s starting to
> look pretty doomed.

There is so much pressure to implement IPv6 on mobile that Apple checks if
your app can deal with an IPv6 only network before the approve it to show up
on the store. If your website supports IPv6 and you have a sizable mobile
userbase, you'll see plenty of it.

------
ktpsns
tl,dr; QUIC is solving shortcomings of IPv6, amongst others the badness of
remaining Ethernet and IPv4, by replacing TCP.

This is one of the most beautiful and deep articles about our networking/IP
world I've ever read. It's so helpful to hear background stories from the
early years of networking (like IPX, I still remember it but was too young to
really make us of it)!

~~~
fulafel
This is a fair summary of the latter part of the article but I think the
argument is flawed:

1\. Mobile IP isn't actually IPv6's raison d'etre

2\. Even for the mobile IP case, QUIC only addresses the HTTP client part of
it - but HTTP didn't need mobile ip to begin with

------
azernik
This... doesn't really describe the motivations for IPv6 well.

Working in networking, it was much-beloved because it eased the address
allocation problem by giving you an enormous, equally-sized address space for
every subnet, and included a potentially-simpler, stripped-down version of
DHCP for non-router nodes. (Edge routers usually use DHCPv6, but only to learn
what prefixes they should hand out to other nodes.)

For core network administrators, the additional address space lets them
organize their routing tables hierarchically, which makes them smaller and
easier to optimize for latency.

Plus, while they were breaking compatibility anyway, fixing up a bunch of
annoying things with IPv4 that had been bugging implementers forever, like
dropping (ugh) fragmentation, rearranging the header information to make it
easier to do routing in hardware, and adding support for metadata in the form
of extensions (useful for ISPs tagging traffic with routing instructions).
Mobile IP was part of this, and was indeed IMO misguided, but is not the only
or (in my experience as an implementer) the main motivation.

That whole digression into the semi-mess that is edge networks over the 802
suite (ethernet + wifi) is irrelevant to this core-network motivation. And in
any case, ARP is (again, speaking as an implementer) a very tidy and useful
abstraction layer. It's even used on non-ethernet networks!

tl;dr the big "killer app" of IPv6 is that it makes the lives of router makers
and network-stack coders easier. Writing new IPv6 code is harder than just
using your IPv4 code, but for green-field projects IPv6 is so much more
pleasant to work with.

~~~
jefftk
The post isn't "Why did people want IPv6" but "Why is IPv6 such a complicated
mess compared to IPv4? Wouldn't it be better if it had just been IPv4 with
more address bits?"

~~~
api
IPv6 is a complicated mess because it was designed by enterprise networking
people. Everything in networking is always more complex than it needs to be.
Always. Network engineers _love_ to overthink everything and they've never
heard of YAGNI.

~~~
kelnos
YAGNI only works when the cost of being wrong is low. In most software, if you
_do_ end up needing something later, you can add it without too much trouble.
In hardware, it means you need to spend a ton of money on redesign, and then
wait years (or decades) for people to upgrade their equipment.

In hardware, if you can reasonably foresee the need for some feature in the
future (where "future" could even be > 10 years), and adding it now doesn't
blow out your cost budget, you should probably add it.

~~~
api
The longevity of network stuff is a stronger argument for simplicity.

The cost of being wrong in the direction of excess complexity is higher than
the cost of being wrong the other way. Layers are added, never removed. A
deficiency can be fixed by adding something. A misfeature or ugly hack is a
boat anchor we lug around for eternity.

~~~
Jweb_Guru
All I hear are buzzwords. Tell me how you can "just add something" when the
protocol doesn't allow you to add it.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=14986324](https://news.ycombinator.com/item?id=14986324)

------
sneakernets
"Bridging is still, mostly, hardware based and defined by IEEE, the people who
control the Ethernet standards. Routing is still, mostly, software based and
defined by the IETF, the people who control the Internet standards. Both
groups still try to pretend the other group doesn't exist. "

I laughed so hard it hurts. Stories like this make me realize that the
eggheads and boffins can be just as dumb and stubborn as I am.

~~~
walshemj
you know the old old joke that the 8th layer of the OSI stack is "politics"

~~~
mcguire
See also
[https://archive.org/details/elementsofnetwor00padl](https://archive.org/details/elementsofnetwor00padl)
_The Elements of Networking Style_.

------
BlueTemplar
So, why haven't the relevant people started working on IPv7/NewProtocol,
like... 10 years ago, when it started to become clear that mobile Internet was
going to become big and that IPv4/6 and TCP/UDP coudln't work well with it?

~~~
kelnos
Probably because they noted the terrible time they were having getting people
to migrate from IPv4 to IPv6, and had no desire to repeat it.

~~~
dcbadacd
It'll only take another 50 years :')

------
Ericson2314
During networking class it sort of dawned on me that the internet people and
LAN people were different and ignoring each other, but they _never actually
said this_. Doing so would have made things a lot clearer.

------
systemBuilder
Thing about IPv6 is that it's designers didn't understand the internet. They
didn't understand that in a client-server architecture only the servers need
full-scale IP addresses because of the 64K ports. They had apparently never
heard of the end to end argument. They saw 16-bit computers being wiped out by
32-bit and figured bigger = always better. xerox predicted 2^48 was all that
we would ever need and as a Xerox protocol designer myself, I think it's still
true. The IPv6 designers thought bigger = better = more router sales ( hey I'm
looking at you, Steve Deering! )

I was asked by Qualcomm to determine when IPv6 would completely replace IPv4.
This was in 2003 and they expected 2006 or 2007 at the latest! But, Qualcomm
never hired internet visionaries ... When I told them "never" I almost got
fired !!

When I left Google search 6 months ago, 15 years later, IPv6 was less than
0.1% of the crawled websites.

It's horribly wasteful for sensor networks and IOT.

It's only useful if you have more than 2^24 addresses because IANA hasn't
added another class A private network range like 10.x.y.z (hint: there is
exactly ONE company that needs a /7 private subnet). 3GPP uses it to give a
unique ID to every phone but that's because they think like Qualcomm.

It will never replace IPv4.

IPv4 is like the roman chariot axle width. It was the right answer, and all
roads today follow Rome's standard.

~~~
kalleboo
> _It 's horribly wasteful for sensor networks and IOT._

What's horribly wasteful for IoT isn't IPv6, it's streaming my baby monitor
video to some server in China because my home internet is behind CGNAT. Of
course, streaming it to some server is more profitable since now you can
charge money for access/storage, so there's no incentive to optimize for
efficiency.

~~~
systemBuilder
And an impractical security mess to tunnel into your home network. There are a
hundred arguments against IPv6 and 3 or 4 - at most - in favor of it.

------
stingraycharles
Ok so here's a question for the HN community: I have IPv6 from my ISP, and as
an experiment, I want to primarily use IPv6 to connect to my different home
servers.

I use automatic address selection, so no DHCP. So this means that when a
server reboots, chances are their address changes.

Other than setting up a custom DNS server and $somehow ensuring that each
server registers itself at this DNS server at boot, are there any elegant
solutions to this?

~~~
starfox64_
Is there anything preventing you from assigning static IPv6 addresses on your
machines?

~~~
stingraycharles
Not necessarily. How would I go about making these IPs easily discoverable by
other hosts? DNS again?

~~~
teddyh
Or mDNS: [http://www.multicastdns.org/](http://www.multicastdns.org/)

As used by Apple’s Bonjour implementation of the Zeroconf networking stack.

If using Debian or the like, just apt install avahi-daemon and libnss-mdns,
and access your hosts on the local network as servername.local.

------
mrfusion
I’m embarrassingly out of the loop. What happened with ipv6? Weren’t we
supposed to run out of IP addresses the years ago? Will ipv6 still happen?

~~~
mindcrime
_Will ipv6 still happen?_

Yes.

[https://www.google.com/intl/en/ipv6/statistics.html](https://www.google.com/intl/en/ipv6/statistics.html)

[https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...](https://www.google.com/intl/en/ipv6/statistics.html#tab=per-
country-ipv6-adoption)

I think we're clearly past the point of no return. How long it will take to
achieve near 100% adoption I have no idea... but with ipv6 already at over 33%
adoption in large countries like India and the US... yeah, it's gonna happen.

All we really need is for Russia and China to get moving on adoption...

~~~
xvilka
China already did. For obvious reasons it just not shown on the Google
statistics page.

~~~
mindcrime
Good point. I totally blanked on that when looking at this.

------
lisper
My first startup, back in the early 90s, was called FlowNet [1]. It was an
incredibly cool design invented by my co-founder, Mike Ciholas. It was fast,
cost-effective (10x price-performance improvement over the contemporary
competition), self-configuring, scalable, and included advanced features like
quality-of-service guarantees.

Needless to say, it did not succeed. But the world would have been a better
place if it had.

[1]
[https://www.linuxjournal.com/article/3293](https://www.linuxjournal.com/article/3293)

------
h2odragon
> "Layers are only ever added."

Vernor Vinge had "Software Archeology" as a thing, it's already too real.

We've already given up the pretense of privacy, let's use a geophysical
coordinate for the basis of our addressing and routing system. All the
problems of mesh networking and mobilty are, if not solved, at least exposed
as what they are, and not hidden behind "and then we tunnel through 4 layers
of protocol to emulate the lack of 7".

~~~
cesarb
> let's use a geophysical coordinate for the basis of our addressing and
> routing system

Networking does not follow geography. My phone is right next to my laptop; but
if I disable my phone's wifi, the network path between them takes a detour
through the next city.

~~~
h2odragon
then the indirection that ties your mobile device to its nearest fixed
forwarding point is an exposed layer. This happens now, you just have several
layers of emulating old circumstances in between, as this article details.

~~~
cesarb
No, that's not the issue; even if the "location" of my phone were defined as
"the location of its base station" or even "the location of the telco's
datacenter next city", the physical wires connecting these "fixed forwarding
points" do not have to follow a direct line. The best path to the USA (which
is to the north of here) is to first go _south_ , then go through the
submarine cable.

~~~
h2odragon
I'm failing to communicate. The location of your phone is whatever it is.
Right now calling you involves mapping your phones ID, at various levels, to
whatever network device can actually route data to it. The first level is
phone number to ... I dunno, but every time i look into it I'm repelled by the
baroqueness.

------
beagle3
2010 saw the introduction of CurveCP[0], and 2011 its first implementation. It
solves a most of what IPv6 does (and then some). The thing it does give up is
complete symmetry - there IS a difference between client and server.

But we've effectively already given that up with NATs (and CGNATs), with
essentially nothing lost[1], so I'd much rather have given that up willfully
and get all the great things CurveCP has to offer, rather than the mess that
is IPv6

An evolved version called MinimalT (published 2013[2], implemented then and
e.g. in 2014[3]) goes much farther, with DNS integration, some DoS protection,
and a few other nice properties while being faster than TCP/IP, and still
being IPv4.

Instead we have QUIC and IPv6.

[0]
[http://www.curvecp.org/addressing.html](http://www.curvecp.org/addressing.html)

[1] And that's unfortunate - but peer to peer is essentially irrelevant now,
when every communication service people actually like uses a server these
days.

[2]
[http://cr.yp.to/tcpip/minimalt-20130522.pdf](http://cr.yp.to/tcpip/minimalt-20130522.pdf)

[3] [https://github.com/nimbus-network/minimalt](https://github.com/nimbus-
network/minimalt)

~~~
simias
>but peer to peer is essentially irrelevant now, when every communication
service people actually like uses a server these days.

That's true but it's sort of a self-fulfilling prophecy the way you put it.
Maybe what we lost is actually the potential to develop alternative, peer-to-
peer, decentralized systems.

Take something like Dropbox, it's been very successful solving a very
practical problem people are having, sharing files over the internet.
Widespread NATing and publicly unreachable computers have a big role in that.
Of course that's not to say that with IPv6 Dropbox would be irrelevant,
there's also the problem of having the files always available, not having to
worry about hardware failures and security issues. Still, I'm sure that in
many cases if people could easily share files directly from their device
without middle-man they would. It's just a pain to get to work reliably
without going through "the cloud".

Of course nowadays that's almost an absurd concept. Everything gets uploaded
on somebody's server and the decentralized web is long behind us.

~~~
beagle3
> Maybe what we lost is actually the potential to develop alternative, peer-
> to-peer, decentralized systems.

For this to work properly one needs (a) mostly reliable addressing and
routing, and (b) mostly online systems.

IPv4 and IPv6 were indeed developed for both (a) and (b). But both started to
disappear when laptops overtook desktops, which would be over a decade now,
and became completely irrelevant when mobiles overtook computers (laptops +
desktops).

It's the world that has changed; it cannot come back in IPv4 due to address
exhaustion, and won't come back in IPv6 because (a) requires stable addresses
-- meaning VPNs for everyone -- and (b) requires the physically impossible
"access to data when phone is out of battery and/or in a Farady cage".

The server-in-the-middle is a must for reliability; People who seriously use
Syncthing or btsync instead of Dropbox have to set up at least one "constantly
on" server because of both (a) and (b) above.

The last remaining use case for peer-to-peer is, I think, live
(chat/voice/video) one on one conversations - and while it's an interesting
and important use case, it can (and has) been solved with stable servers-in-
the-middle, and I don't believe it is significant enough (or was, or will be)
to stop progress; MinimalT makes much more sense than IPv6 or QUIC as a way
forward, but we're unlikely to ever have that at scale.

~~~
cesarb
> requires stable addresses -- meaning VPNs for everyone

The true requirement is for a stable identity, not a stable address. You just
mentioned Syncthing, which is an example of this: every Syncthing node has a
stable identity (which is its public key), but not necessarily a stable
address. All you need is a way to map the identity to the address, which does
not have to be centralized (even though the current implementation in
Syncthing, outside of broadcast-based local address discovery, is
centralized); bittorrent DHT manages to map a torrent's hash to a set of
addresses without needing any central node.

> requires the physically impossible "access to data when phone is out of
> battery and/or in a Farady cage" [...] People who seriously use Syncthing or
> btsync instead of Dropbox have to set up at least one "constantly on" server

You stated the solution yourself: to access the data when the phone is
offline, mirror it to a node which is online. Just because these particular
protocols require you to set up your own always-on node doesn't mean it's a
hard requirement; some older peer-to-peer protocols from over a decade ago
already securely mirrored data in nodes belonging to other users.

~~~
beagle3
> All you need is a way to map the identity to the address, which does not
> have to be centralized (even though the current implementation in Syncthing,
> outside of broadcast-based local address discovery, is centralized);
> bittorrent DHT manages to map a torrent's hash to a set of addresses without
> needing any central node.

That's true; but I think bittorrent DHT is the only decentralized one that
seems have succeeded (I remember quite a few unsuccessful attempts two decades
ago), and its success is probably related to its use case - it is of
everyone's interest to have hashes well-mapped in case you'd need them.

> Some older peer-to-peer protocols from over a decade ago already securely
> mirrored data in nodes belonging to other users.

And for various reasons, they are all gone, whereas e.g. rfc822 email - which
is properly decentralized/federated but does require a stable online node, is
still going strong nearly 40 years later, despite somewhat successful attempts
to re-centralize it by the likes of google.

I think it's inherent - many people now only have a phone, but no one wants a
service that becomes unavailable when you lose your phone or step in a faraday
cage -- there even used to be on-phone voicemails back in the dumb phone days
-- as peer to peer as dumb phones can get -- and they were not popular for the
same reasons.

And if it is indeed inherent, it would be better to take it into account when
designing the next stage.

------
tinus_hn
> You definitely couldn't write something like traceroute for bridging,
> because none of the tools you need to make it work - such as the ability for
> an intermediate bridge to even have an address - exist in plain ethernet.

Doesn’t Windows 10 come with a network mapping tool that does just that (when
not on a domain)?

------
RyanShook
I think the heart of all networking issues is that it’s hard to imagine a
system more complex than the one you have today. IPv6’s main weakness is the
lack of mobile IP and even as we work to solve that problem we are creating
new problems that will only be clear in another decade or two.

------
mcguire
Slide 14 of the BBR deck: " _PROBE_RTT drains queue to refresh min_RTT:
Minimize packets in flight for max(0.2s, 1 round trip) after actively sending
for 10s. Key for fairness among multiple BBR flows._ "

Suddenly, I'm scared.

------
Abekkus
Why isn't TLS client auth a turnkey solution for maintaining a single web
session as a client moves between network segments?

~~~
kelnos
Aside from the fact that TLS client auth is currently a usability nightmare...
well, it could be, but you'd be building that session-resume capability into a
higher layer than would be ideal. Meaning that anything that isn't TLS would
have to build their own session resumption system.

Conceptually, you want to push things as low in the stack as is feasible.

~~~
Abekkus
Session is a higher OSI layer than transport, and any secure session
management would probably be as complicated as TLS in the end.

------
stjohnswarts
I'd be willing to bet that QUIC will not replace TCP in our lifetimes.

------
AFascistWorld
IPv6 opens up the possibility of comprehensive government surveillance, govs
now can attribute every device fixed set of IPs, which link to your ID.

~~~
astrange
[https://tools.ietf.org/html/rfc4941](https://tools.ietf.org/html/rfc4941)

------
paulcarroty
Practice says good design isn't effective against greedy ISPs.

------
RandomTisk
I'd like to propose IPv7. Exactly like IPv4, but 48 bit addresses and must
accept IPv4 traffic and treat addresses as beginning with 0's for first two
octets. You're welcome.

~~~
asdfasgasdgasdg
That's more or less what the article says in its first section. Then it goes
on to tell why that didn't happen. In short, it isn't that simple.

