
Is there hope for IPv6? - danyork
https://www.internetgovernance.org/2019/01/04/is-there-hope-for-ipv6/
======
hn_throwaway_99
I hope (but am skeptical) that folks look at the overall failure of ipv6 from
a deployment perspective to understand the root causes of why it failed (some
may think "failure" is too strong a word, but I remember v6 being "just around
the corner" in 2000, yet in 2019 I'm still connecting to a GCP database with
v4).

Coming up with a solution that looks like a huge technological advancement,
with no real respect for the motivations or incentives of those who'll need to
implement and use it, is a fairly common occurrence in tech and something
engineers should be trained to guard against.

~~~
phicoh
There are 3 problems with IPv6

\- There is a lot in IPv6 that is different from IPv4. Ignoring if those
changes are good or bad, it does make the transition harder.

\- IPv6 was promoted way before there was demand. To some extent it is good to
prepare people (and vendors). But it does create the impression that IPv6 is a
failure

\- Demand for IPv6 is highly asymmetrical. The party that is out of IPv4
addresses needs IPv6. But everyone who has enough IPv4 space has no reason to
care.

When IPv6 was first promoted, there basically was no IPv4 market. You would
just go and get more IPv4 space when needed. For the last couple of years we
now have a mature market for IPv4 addresses.

It is possible to buy IPv4 addresses, but prices go up. At some point it
becomes interesting to try to move traffic to IPv6.

~~~
4bpp
More issues with IPv6 that are relevant for me as a techie:

\- Memorising an IPv4 address is about as easy as memorising a phone number,
which is to say, fairly easy. I remember the iPv4 addresses of both my rental
servers, every device on my home LAN, a bunch of public DNS servers if things
go wrong, ...; there's no way I'm going to be able to do that for IPv6.

\- At least last time I tested it (more than 10 years ago now), the greater
length of IPv6 headers had a quite measurable adverse impact on transmission
latency of small packets (online gaming, remote shell...)

\- Why do people keep treating "you get your own unique IP address when
browsing" as if it were an advantage? The way I see it, NAT and IP address
reuse (especially together with some European countries' laws stipulating the
address->identity mapping must be deleted within some time period) are the
currently most widely rolled out privacy technology. Somewhere downthread,
they talk about how Belgian police is trying to prevent ISPs from putting more
than 16 customers behind the same internet address. Since I can hardly say
everything I do on the internet is perfectly legal, what's bad for Belgian
police is probably good for me.

~~~
gerdesj
I'm a techie too but I think:

\- If you go around memorising addresses then you are doing IT wrong in
general. So many things depend on DNS (not just A records) that punching in
IPs by default is a bad habit. Browsers will keep on enforcing SSL/TLS more
and more until the point where typing in an IP address into the URL bar will
be as painful as using the web GUI for say an elderly HP switch is right now.

\- In general latency is not affected by header lengths these days. In some
cases, networks are prioritising IPv6 for the opposite affect. In other cases
ISPs have dropped their entire IPv6 support without noticing for quite some
time. _sigh_

\- The addressing scheme in use should have nothing to do with your privacy.
Yes NAT does accidentally hide you a little bit. However I can fingerprint
your browser instead, for example. I'll trade easy SIP n RTP over NAT any day.

Now, for my gripes:

\- Try doing multi WAN effectively over IPv6 without PI and a routing
algorithm, or NAT \- Try changing ISP (new addressing everywhere)

The second gripe I currently work around with RFC 4193 - Unique Local IPv6
Unicast Addresses, the first one I whine about and will probably use NPT
(wholesale NAT for IPv6)

~~~
pedrocx486
>\- If you go around memorising addresses then you are doing IT wrong in
general.

Because I'll surely have an TLD for my local nginx and for my home router...

~~~
gbrayut
Just use home.arpa from
[https://tools.ietf.org/html/rfc8375](https://tools.ietf.org/html/rfc8375)
with a custom DNS server or host file. Or one of the many dynamic DNS systems.

~~~
Aeolun
Sure, because a custom DNS server is easy to set up.

~~~
justinclift
Depends on your skill set. If you're ok with *nix, then PowerDNS is pretty
simple to work with:

[https://github.com/PowerDNS/pdns](https://github.com/PowerDNS/pdns)

It's also fairly complete, used in production by some pretty big ISPs.

For a light weight approach instead, Dnsmasq is good:

[http://www.thekelleys.org.uk/dnsmasq/doc.html](http://www.thekelleys.org.uk/dnsmasq/doc.html)

It's what most home routers (and lots of other stuff) embed. :)

~~~
Aeolun
Ok, fair enough. It’s fairly simple to set up.

It’s just a bit of a pain to maintain if the only thing you care about is
connecting to server nr 192.168.0.x

I could certainly do it, but there’s 5 services in my house I’d care to
connect to, and remembering 1-5 is just as easy as giving them all names. The
marginal gains are very low.

~~~
justinclift
Oh, I very much agree. For very small local networks in a flat address space,
manually remembering stuff works ok.

Personally I tend to throw the more stable IP addresses in /etc/hosts, as
that's simple too. :)

------
krylon
I have been getting native IPv6 from my ISP for nearly six years now. It is
not quite as cool as it could be, because I get assigned a new prefix every 24
hours, but still, IPv6 is there, and it "just works".

When I connect to machines on my home network in any way involving
avahi/zeroconf, the machines talk to each other via IPv6 by default.

At work, it's a different story. I have drifted from a sysadmin/helpdesk role
into a programmer position, so that is no longer my concern. When it was,
however, there was little incentive to use IPv6 - everything worked and
continues to work just fine with IPv4, and sometimes there were even some
rather esoteric problems with Windows' "Network Location Awareness" when IPv6
was enabled.

~~~
AnIdiotOnTheNet
> because I get assigned a new prefix every 24 hours

Which kinda defeats the purpose of having a globally reachable unique address
in a lot of respects. How am I supposed to allow connections to this device in
my firewall if the address is always changing?

~~~
chrononaut
There's advantages and disadvantages to this approach. When we're talking
about residential networks, some consumers won't care about the inability to
do that, some will. Those that do care also have to weigh the privacy concerns
about the fact that they have a now static prefix for their networks, much
like static IPv4 addresses.

Personally I'd prefer ISPs to take an approach like this by default, but allow
the option for the consumer to have a statically assigned IPv6 prefix for free
if they want it, who understand its implications.

~~~
elcomet
> When we're talking about residential networks, some consumers won't care
> about the inability to do that, some will.

This prevents also to create products that need a public address. I think it
is a real brake on innovation, who knows what could be invented if everyone
had a public ip address ?

~~~
pas
The address is public, you can use a dynDNS easily. Relying on fixed addresses
never works.

------
kevinoid
These are some interesting insights into the economic incentives on the
deployment side. I'm looking forward to reading the report.

It is also interesting to consider the incentives (or lack thereof) for IPv6
peering. The fact that HE and Cogent haven't resolved their peering dispute
from 2009 suggests to me that there is insufficient incentive (particularly
from their customers) to do so, even when there are obvious practical effects.
(I can't reach openstreetmap.org via an HE IPv6 tunnel even now.)

Perhaps the technical effectiveness of Happy Eyeballs and other backwards-
compatibility mechanisms necessarily reduces incentives for improving IPv6?

------
7e
This chart:
[https://www.google.com/intl/en/ipv6/statistics.html](https://www.google.com/intl/en/ipv6/statistics.html)

... reports a steadily increasing adoption rate for IPv6. Is that rate somehow
too slow? It currently stands at 25% of Google users.

~~~
owenversteeg
Huh! I looked closer at the graph and wondered why the line was so fat. If you
zoom in, a clear trend appears: far higher IPv6 usage on weekends. About 25%
more people using IPv6 on weekends than weekdays. (IPv6 is 21% of the total on
weekdays vs 26% on weekends.) I'm surprised there's such a big gulf.

~~~
vertex-four
A lot of home users have had IPv6 “silently” enabled, while many corporate
networks have never implemented it, or only implemented it for a small portion
of services that need it.

------
ctime
I'm curious on how the non-contiguous ipv6 [1] usage will eventually affect
the use of the TCAM in vendor hardware. It seems that most TCAM being
developed today will never be able to store anywhere near the unfathomably
large amount of possible address prefixes being carved - and of course the
prefixes are only are going to get more and more fragmented.

Right now the typically default behavior for switches/routers that encounter
the exhaustion is to summarize prefixes with a shortened prefix and (possibly)
punt the evaluation to the general purpose CPU (example here[1]) - which
suffice it to say, introduces a host of security concerns. This means, as a
security engineer, in situations where complex/large ACLs exist, I need to be
aware of and control how IPv6 TCAM exhaustion failure modes work and plan that
eventually my hardware TCAM may be exhausted and fail in a spectacularly bad
way.

Or, I just ignore IPv6 almost entirely and just don't have the problem
(cleverheadtap.jpg)

[1] [https://www.iana.org/assignments/ipv6-unicast-address-
assign...](https://www.iana.org/assignments/ipv6-unicast-address-
assignments/ipv6-unicast-address-assignments.xhtml) [2]
[https://community.cisco.com/t5/switching/tcam-utilization-
is...](https://community.cisco.com/t5/switching/tcam-utilization-
issue/td-p/2904935)

~~~
jerkstate
I have a theory that announcements will be part of what you pay for in the
future, like you pay for ports and bandwidth today.

------
magila
What we really need is a killer app that requires end-to-end connectivity.
Users have little reason to care about IPv6 right now because the existing
ecosystem of services has evolved around the constraints of NAT. As IPv6
deployment expands hopefully we will reach a point where some great new
application becomes economically viable.

My biggest fear is such an application not emerging quickly enough. Without an
imperative from users for end-to-end connectivity there's a risk that IPv6
networks which somehow break it become entrenched. If that happens we are back
to the old chicken-and-egg situation: Users don't care because there's no app
and there's no app because the network is broken and operators don't care.

~~~
geofft
My ISP (Verizon FiOS in NYC) does not offer IPv6 support at all. Users have
asked for years. They've promised it for years. It's still not there. So it's
not a matter of users asking. Re switching, I think I have one or maybe two
alternatives; I'm not sure if they support IPv6 either, and they have their
downsides too.

Any potential killer app is going to have to decide whether they want to lose
such users, because I cannot imagine an app that is so compelling that I'd
switch ISPs for it. And I'm a person who actually wants IPv6 for its own sake.
I certainly cannot imagine, say, my parents switching ISPs over an app (and
I'm not sure how much choice they have either).

And if such an app arises, it's going to be easy enough for users to use VPNs
- it's already common for people to use VPNs to get to region-locked content
or (at least as of a few years ago) play LAN videogames over the internet.

~~~
magila
_Some_ users have asked their ISP for IPv6, but they are in the extreme
minority. The average user is obviously never going to ask for IPv6 because
they don't know what it is. Really the hope is that users would complain
killer app x doesn't work with their ISP, and eventually there would be enough
pressure to motivate the ISP to deploy IPv6.

~~~
geofft
How would the app become a killer app in the first place if a huge fraction of
users can't use it?

And my estimate is it probably takes years to roll out IPv6 on a network that
isn't ready for it - how would the app _remain_ a killer app until then and
not be disrupted by someone willing to run a proxy server?

------
csears
What if we started charging a small but slowly increasing annual fee for each
IPv4 address? And with the proceeds ICANN starts buying back IPv4 blocks and
permanently retiring them.

~~~
orev
That might actually have the opposite effect of what is desired. Whoever is
charging and benefiting from the fee would then have an incentive to maintain
the status quo of IPv4 and continue collecting the fees. We’re already seeing
this now as people are selling IPv4 addresses. Scarcity + demand creates
market opportunities.

~~~
coding123
Couldn't they can mandate, that no customer must be charged MORE than the
global fee, and violations instantly lose their ipv4 addresses (or rather
replaced with v6)?

I don't know who the ultimate benefactor would be - would it be ICANN?

~~~
richardwhiuk
In what jurisdiction do you envisage that law and why would the politicians
agree to such a tax?

------
geofft
This article completely fails to mention that IPv6 is not just an extension of
the address space but a whole different worldview about how to run a network:

\- IPv6-to-IPv6 NAT has only been accepted very recently and very
begrudgingly. Whatever your views are on NAT, the fact is that lots of people
have network designs that rely on it, and if you want them to stop, you're now
asking them to couple two major transitions, which is a significant economic
cost. (Option 3 in this article is IPv6-to-IPv4 NAT, assuming that the public
internet will indefinitely be IPv4; it's noteworthy that none of their options
ever envision the public internet becoming IPv6.)

\- IPv6 recommends the use of its own scheme, SLAAC, for address assignment,
with DHCPv6 being also very recent and poorly implemented - for instance,
Android has no DHCPv6 support and plans to never implement it
[https://code.google.com/p/android/issues/detail?id=32621](https://code.google.com/p/android/issues/detail?id=32621)
. There's also a "stateless DHCPv6" for communicating DNS servers but using
SLAAC for addressing; without it, SLAAC expects you to use a scheme called
RDNSS to communicate your DNS servers, which is also not 100% supported. So
you now need to spend engineering time supporting all of these options because
some devices only support one and some only support the other, and you need to
come up with network designs that work with both SLAAC (which has strong
opinions on how you use /64s) and DHCPv6 (which doesn't).

\- IPv6 doesn't use ARP, on the grounds that it's a layering violation, a
separate layer-3 protocol that runs directly on top of Ethernet but talks
about IP addresses. Instead, IPv6 has a clever scheme for using multicast to
transfer the information that ARP would convey, by having machines join
multicast groups based on their MAC address. This works very, very poorly with
networks that aren't designed to support significant multicast load - for
instance an attempted deployment of IPv6 caused packet storms in the MIT
Computer Science and AI Lab's network for about a week because their switches
were falling back from multicast to broadcast:
[https://blog.bimajority.org/2014/09/05/the-network-
nightmare...](https://blog.bimajority.org/2014/09/05/the-network-nightmare-
that-ate-my-week/) So a working IPv6 deployment involves upgrading all of your
hardware to hardware that has good support for multicast, which is also a
significant economic cost.

\- Various protocols like Teredo and ISATAP attempt to set up tunneled IPv6
routing in preference to IPv4 routing, making it hard to do a staged
deployment, especially if you have BYOD on your network. For bonus points,
because they're tunneled, you get different _and possibly worse_ routes over
IPv6, making debugging harder. So that's a cost in additional L1 and L2
support.

If someone had come up with an IPv7 that's just "We extended IPv4 to 128-bit
addresses and we left ARP and DHCP and NAT and everything alone," people would
have switched to it already. But the powers that be are drowning in the
second-system effect and nobody wants all the features they added.

~~~
grandinj
This.

I was (as a young engineer) monitoring the mailing lists during the IPV6
proposal discussions and the hubris was palpable.

It was very much a case of "they will have to implement this so we will get to
force all of these other improvements on them too "

~~~
walshemj
makes x.400 and x.500 seem sensible

------
xvilka
IPv6 is already a success in mobile and IoT, and in countries that matter in
economical sense. The rest will follow automatically because they have no
choice. More worrying issues are BGP and SS7 reliance in global networks, and
there are no viable alternatives on the horizon.

~~~
pas
Could you expand on these problems? Why is SS7 an issue? (Aren't telcos moving
to IP based platforms? Device registration on towers can work on whatever
protocol the device supports the base station encapsualtes/proxy-es/processes
that further, and the telco can use whatever routing it wants internally - eg
iBGP. Or even some fancy OpenFlow based control plane.) And of course the
issues with BGP seem even more interesting, if you could detail those too ot'd
be great.

~~~
xvilka
The SS7 protocol stack is soaked with security problems, but also because it
doesn't represent the modern nature of traffic. Of course, telecoms moving to
IP cores and such, but SS7 still widely used mostly because of the
interoperability and roaming. Positive Security recently made a summary report
of the current status of the problem[1]. BGP main problem is the inherent
trust to users and servers, thus allowing malicious actors or even some errors
to do weird things with network traffic. See this[2] Black Hat talk quickly
summarizing them.

[1] [https://www.ptsecurity.com/ww-
en/analytics/ss7-vulnerability...](https://www.ptsecurity.com/ww-
en/analytics/ss7-vulnerability-2018/)

[2] [https://www.blackhat.com/presentations/bh-usa-03/bh-
us-03-co...](https://www.blackhat.com/presentations/bh-usa-03/bh-
us-03-convery-franz-v3.pdf)

~~~
pas
Thanks for the reply, links, and details!

Regarding BGP, it seems that the basic protocol and implementations are okay.
("No implementation allowed BGP OPENs with the wrong AS or from non-configured
peer to reach BGP ESTABLISHED state—as a result, TCP spoofing is required to
inject data", and when you can spoof TCP between routers ... it's probably too
late anyway. In a peering scenario between ASes people either use a direct
cable, a separate VLAN or other direct "transport", in a IXP the IXP operates
a big switching fabric and the peers exchange traffic over that, but the BGP
sessions use fixed IPs and basically they are fixed to switch ports, and even
if currently not every IXP monitors the spoofing/abuse of those, it is easy
and they should be doing so. Sure, the reality is always bleaker, but that's
security. Maybe next-next-next gen will have crypto built in so far down the
stack that without a shared secret no packets will flow. But then humans will
just put the PSK on a bright sticker, or will continue to use "chang3me" for
decades.)

The problems I heard with it is that Tier1 providers just can't really filter
the routes they get from downstreams, as they'd have to know which Tier2
handles which prefixes for which clients and so on. Though I'm not convinced
they are putting much effort into it, as it's easier to just plug in big Cisco
boxes and set up peering with your core and your downstream customers and call
it a day. (And setting up is always messy already, so it's sort of
understandable that there are no easy and custom solutions for somehow
verifying announcements from whatever databases.)

~~~
IPv4Mall
Even though IPv6 quickly established itself as a robust industry there are
countless users who prefer the old IPv4 protocol.Even if we compare IPv6 with
IPV4 there are many such positive features which makes people still choose
IPv4 Ref: [https://ipv4mall.com/blogs/ipv4-vs-ipv6-pros-
cons/](https://ipv4mall.com/blogs/ipv4-vs-ipv6-pros-cons/)

------
ah-
Funny how it's posted on www.internetgovernance.org, which doesn't support
ipv6.

------
the_mitsuhiko
The weird thing is that on some countries IPv4 only turned effectively into
the premium offering. This is for instance the case in Austria where you
generally have the option of ipv4 or ipv6 with dslite or worse only.

All new contracts are ipv6 and the only way to get to ipv4 is via customer
support. However right now ipv4 gives you the better experience.

~~~
vnw
I don't believe it's weird, in fact, I think it's natural. IPv4 is better
(because every single machine and server has IPv4 connectivity, unlike IPv6)
and available addresses are getting scarce. Therefore, IPv4 access with no CG-
NAT is turning into a "premium" service.

------
sliken
39% of Google's traffic is IPv6, clearly there's no hope.

~~~
geofft
Only if the end state is that the public internet will be dual-stack IPv4/IPv6
forever and everyone will need some form of IPv4 connectivity, either a real
IPv4 address or NAT to one (from either private IPv4 or private IPv6). Is that
the world we want? Have we solved the address space exhaustion problem if
that's the route we take?

~~~
BenjiWiebe
If 95% was dual stack, we could start getting rid of ipv4.

------
Pxtl
Imho IPV6 failed because of a failure to make DNS usable to non-specialists.

If every device on every network could be assigned a domain name, then we'd
never have to know what underlying addressing scheme exists.

My ISP has a name. I have an account with them. Every device on my network has
a name.

There's no good reason I don't have

Device.accountName.pub.ispName.tld

Bound to the phone I'm writing this on right now.

But because that doesn't exist, users are still used to screwing with MAC and
IP addresses just to set up port forwarding and all that other nonsense.

And so we have to care about IP addresses. And so we're stuck on ipv4.

~~~
zamadatix
99% of users couldn't tell you what an IP address or port is let alone
manually configure MACs and IPs into their router so I don't think that has
anything to do with adoption of v6. To the vast majority of users they type a
name in the URL bar and that's their full interaction with what they'd think
of as "internet addresses".

Those administering the systems users connect to have always handled DNS just
fine so I don't see why they wouldn't be able to know that the address got a
bit longer.

~~~
iagovar
v6 adresses are hard to memorize tho

~~~
Dagger2
Not really? I don't think you can reasonably argue that:

2001:db8:4242:1::2

is much harder to remember than:

203.0.113.42+192.168.1.2

In fact it's substantially fewer characters.

Okay, obviously you _can_ pick v6 addresses such that they're long and hard to
memorize, but I'd argue that if you do that and also refuse to use DNS for
them then you've lost your right to complain about how long and hard to
memorize they are.

------
krkoch
We tried setting up automatic DNS records on dhcpv6 and slaac on our company
lan, and we just weren't able (opnsense). We have ipv6 working, but it still
doesn't "feel finished".

------
vermontdevil
My university (100k students) is transitioning to ipv6. But it’s a long term
roll out. I have both static ipv4 and ipv6 for my work station. They tell me
the ipv4 will go away in near future.

------
amaccuish
Can anyone explain to me. So right now for v4, we have NAT, and several ways
to get a port open and pointed at us. With v6, every device has its own public
address, like how the internet was intended. And as sensible network admins,
we should have a default deny incoming firewall policy for v6 traffic. But
surely that will prevent these "end-to-end" apps from working, and now they
don't even have protocols like UPnP to bypass the firewall and request ports
to be opened?

~~~
pseudalopex
Sensible network admins will open ports for specific services. Also, UPnP,
NAT-PMP, and PCP support IPv6.

------
vjeux
Facebook publishes some stats about worldwide ipv6 usage that they observe:
facebook.com/ipv6

------
dennisgorelik
A couple of months ago voted for IPv4 by paying $1/month for every IPv4 IP
address on my new server.

128 IP addresses total. That is well over $1k/year voting power.

The reason for that purchase is that IPv4 addresses represent internet
reputation while crawling websites.

I am not interested in getting IPv6 at all.

How much did you pay for IPv6?

~~~
sliken
Comcast gives regular home users 2^68 of them.

------
dghughes
I like IPv6 it can actually be easier to set up stuff instead of using IPv4
for example OSPF. But I find IPv6 is not as intuitive as IPv4 just looking at
an address in IPv4 vs IPv6. You can create new networks for IPv4 pretty easily
just by eyeball but not IPv6. At least I can't.

~~~
apple4ever
It can be done (using each :XXXX: block as a network instead of splitting it
up), but its definitely not quite as easy to eyeball.

~~~
Dagger2
It's quite a bit easier to eyeball than v4, because it's much easier to make
sure that your network falls on a character boundary (multiple of 4 bits out
of 128) than it is to make it fall on an octet boundary (multiple of 8 bits
out of 32).

If you find v6 harder than it's just down to a lack of practice.

------
sverige
> "Given that fundamental constraint, there are only three basic choices for
> network operators:

...

3\. Run native IPv6 among compatible parts of their own network with some kind
of tunneling or translation (i.e., converter technologies in economics) at the
boundaries to make it compatible with IPv4

Among these viable alternatives, we show that dual stack will never get us
across the finish line; it is not economical. It is the third category that
shows promise for some growing networks."

So, basically a more complex version of NAT is what they're proposing for the
"transition" from IPv4 to 6. Am I the only one who remembers that IPv6 was
supposed to eliminate NAT?

~~~
geofft
Yeah, it's fascinating here that they've gone from "NAT is bad and we won't
let you implement NAT, we need an internet on a single flat 128-bit address
space" to "The internet will be IPv4 forever and you should implement IPv6
internally and run NAT, because we like it better than running IPv4 NAT which
is what you've done for years and works great".

~~~
Dagger2
That's not what the article is saying. They're saying that you still need to
provide access to legacy v4-only hosts on the internet somehow, and you either
do that via v4 (i.e. dual stack) or by some transition technology of which
NAT64 is just one possible option.

Nobody is suggesting to not talk native v6 to the internet too, they're just
suggesting to not cut your users off from v4-only services.

~~~
geofft
If all your connections are _potentially_ NATted (i.e., any DNS lookup might
only return an IPv4 record), what's the advantage? You still have to build
applications that are capable of dealing with NATs / non-end-to-end
connections. You just also have to maintain IPv6 infrastructure. That seems
strictly worse than staying on IPv4 NAT.

(If you're talking to specific parties that you know have working IPv6, it's
less work to run a site-to-site VPN than to both maintain working IPv6.)

The only world in which IPv6 is worthwhile is one in which we can turn off
access to legacy v4 hosts and stop having public IPv4 addresses. At this
point, it seems like there is no hope of doing so in the current Internet.
Perhaps in a few hundred years the Internet itself will be dead and IPv4 will
die with it, but not before then.

~~~
tialaramex
No. The idea goes like this:

You throw away IPv4 internally. Nothing internally is IPv4. All your network
address sizing issues vanish, puff, gone, because in IPv6 the subnets are
always 64-bits, which means whether it's four boxes or four million boxes it
fits in the same subnet. No more NAT, you just use real (globally unique) IPv6
addresses for everything, so there are no confusing debug sessions where you
thought 10.4.5.6 was this box but actually because of how routing is set up
it's _that_ box and so you wasted six hours.

So internally everything is _wonderful_

And then to manage the fact that some fraction of the Internet is (and for the
foreseeable future will be) IPv4 only, you have edge devices that translate.
They translate DNS too. If you ask for www.example.com and the answer is A
10.20.30.40 the edge devices wrap that inside an IPv6 address and provides
that as your AAAA answer.

_This_ way around works, because 128 is bigger than 32. Unlike the people who
magically want an IPv6 that hides 128-bits in 32-bits, which is mathematically
impossible, this merely hides 32-bits in 128-bits, which is trivial.

Anyway, nothing else needs to even care, just those edge devices, and as
transition continues you spend less and less money on them. In reality at any
modern company you probably already spend more on edge devices you've added
because somebody read about them in a magazine - anti-malware, service
protection, next generation firewalls, that sort of thing.

------
mikeytown2
If a major player like GitHub doesn't support ipv6 then ??? Also a lot of vps
providers do ipv6 incorrectly so some form; vultr seems to be the only one
I've found that does it well.

------
lkdjjdjjjdskjd
I really want to enable ipv6 on my web site, but then I heard horror stories
about connections failing if not all routers between the client and the server
have ipv6 enabled.

Apparently at least for a while, browsers would not try the same request again
via ipv4, so the site would simply be unreachable.

Perhaps browsers have become smarter about that, but it really makes me wary
about enabling ipv6. I have no immediate benefit besides "doing the right
thing", and some possible downsides.

~~~
capitol_
Yes, browsers have become smarter about that. You can test it by enabling ipv6
and then drop all ipv6 packets with ip6tables, that has the same effect as if
some middlebox dropped them.

------
lurkinghere
IPv6 is so 90s. Put a pink lens and design a global network where are good
people. Netizens as were called.

Give an IPv6 with last digits of the MAC address is unacceptable today. Unique
IP per device maybe dangerous.

Today tracking exists and is smart, some organizations are logging bittorrent
activity. People buys VPN, right?

Really I love shared IPv4 at my University (although they have a /16). Maybe
there are thousands of devices behind. Google Ads becomes crazy. I only want
privacy.

------
AndrewKemendo
The argument seems pretty straightforward and is a classic collective action
problem:

v4 isn't expensive enough (in all cost measurements) to justify switching to
v6. Once that flips, when there aren't any more v4 addresses then everyone
will move there.

It sounds like the costs of v6 are so high that we basically need complete
saturation of the v4 IP ranges, and then a market that trades IPs at a higher
friction/cost rate than than implementing v6.

------
spullara
There is no hope. Without backwards compatibility with IPv4 addresses we will
always have IPv4. The specification was a complete failure.

~~~
Dagger2
v6 has dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64,
464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... it has pretty much every possible
backwards compatibility method that can work with v4.

You could make a reasonable argument that it has too many of them, even. Where
did you get the idea that it didn't have backwards compatibility?

~~~
spullara
It doesn't have any backwards compatibility. You can't turn off IPv4 and just
have IPv6 and still use IPv4 addresses. If it had it, you wouldn't need all
those hacks.

~~~
Dagger2
Yes you can. Those "hacks" are how you do it.

I mean, you can call them hacks, but at the end of the day v4 uses a fixed-
width 32 bit address field and has no mechanism to extend it in a way that's
compatible with other v4 hosts. All you can do is hack around that. There's
nothing that v6 could possibly do to avoid it, because the flaw is in the
design of v4 and not in the design of v6.

------
Animats
Is this US-centric or worldwide? In particular, does it include China?

~~~
zamadatix
[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)

[https://www.facebook.com/ipv6/?tab=ipv6_country](https://www.facebook.com/ipv6/?tab=ipv6_country)

US isn't doing so bad thanks to it's mobile networks being early v6 adopters.

------
HankB99
Require that porn sites use only IPV6 addresses. Or provide some free benefit
to people who access those sites using IPV6. I'm pretty sure adoption will
surge. It worked for VHS.

------
Bombthecat
The main problem is :it is too easy to ignore. You can build around all of the
limitations of ipv4. Which makes ipv6 useless / not needed in the first place.

------
bartwe
As a gamedeveloper it hasn't been particularly easy or clear how to make
connections between users over v6, it is enough of a mess with v4 tbh

------
hkt
I've been saying it for years: IPv4+ would be fine. Just add more bits to
addresses (maybe twice as many octets) and dual stack that instead.

------
seanlinmt
“No one uses IPv6 only."

I had a go using only IPv6 recently. What surprised me was the site that broke
it for me. Github.com.

------
qwerty456127
Perhaps I just misunderstand IPv6 but I prefer IPv4 with NAT and temporarily
leased public router address for privacy and security reasons. AFAIK IPv6
means every device gets assigned a stable unique address everybody can
identify and reach it by. And I have never seen a SOHO WiFi router that would
support IPv6 anyway (perhaps latest fancy expensive ones do).

~~~
Kranar
IPv6 allows for so many IP addresses that you could give yourself a new IP
address every minute and never worry about running out.

~~~
geofft
You could, but does your device actually do so? Are you confident that 100% of
the devices you own use privacy addresses and do not leak non-privacy
addresses?

The nice thing about IPv4 NAT is that you plug a single gadget in to your
ISP's connection (cable modem, ONT, whatever), you connect your devices to
that gadget, and it works out of the box and has all the security properties
you'd expect, even if you're a person who hasn't ever thought about security
properties and doesn't know what IP is and is still running Windows XP because
your word processor still works fine. It might be unclean, but the benefits of
this model are immense.

~~~
z3t4
One problem with IPv4 is that each interface can only have one IP. With IPv6
an interface can have many! For example _both_ a private and a public IP
address!

~~~
geofft
?? multiple IPv4 addresses work fine... ip addr add 192.0.2.2 dev eth0

It's true that IPv6 _requires_ IP stacks to support this, but nothing in IPv4
_prevents_ IP stacks from supporting it.

------
gweinberg
Let's just skip to IPv7.

------
Ericson2314
Maybe we need to tax IPv4 addresses. Once again, markets suck at dealing with
scarce resources. Tax externalities or ditch capitalism, you choose society!

------
rawoke083600
how about ipv5 and we just add an extra .255 ? Im sure our kids wilk figure
out a better solution... ?

~~~
CydeWeys
Assuming you're not joking, the nice thing about IPv4 is that it uses 32 bits,
so you can store addresses in an unsigned int and use memory efficiently. Just
adding one octet takes you up to 40 bits, which has alignment issues. You may
as well go up to 64 bits (half of IPv6), which could be represented as 16 hex
characters, e.g. 06A4.6E1B.12C9.95C8. That way you're kicking the can much
farther down the road too.

~~~
paulddraper
I always wish IPv6 had done example this -- use 64 bits.

The address space is still enormous: a couple billion for every currently
living person (yes, I know allocating isn't 100% efficient, but even at 0.001%
efficiency, that's still tens of thousands per capita).

And, the address could fit in a common word size, and be significantly more
readable.

As is, IPv6's one-address-per-atom-on-Earth is unnecessary, the addresses are
horrendous to read, and the collapsing colon stuff is just obnoxious.

~~~
Dagger2
64 bits probably wouldn't be enough to let people avoid going into address
conservation mode though. Heck, there are way too many ISPs allocating a
single /64 in v6 land _today_ , and there's far more space available in v6
today than there would be after 100+ years of your 64-bit space.

Having an unnecessarily large amount of addresses is a good thing, because the
alternative is to have too few addresses. You don't want to have too few
addresses, because if you think v6 is taking a long time to roll out...
imagine how long a replacement to it would take.

~~~
paulddraper
> Heck, there are way too many ISPs allocating a single /64 in v6 land today

First, ISPs are allocating them because they can. There are enough total /64
blocks for every living person to have a couple billion _blocks_.

Second, ISPs are allocating /64 blocks because they have to. Well, they don't
_have to_ , but there are 20 billion billion total /64 blocks. ISPs will run
of capacity in their routing tables long before address blocks are exhausted.

> Having an unnecessarily large amount of addresses is a good thing

Agreed. Both 64-bit and 128-bit have unnecessarily large address spaces. But
32-bit is too few, though, and byte/word alignment is convenient. So 64-bit is
convenient, unnecessarily large solution.

~~~
Dagger2
There's no requirement for ISPs to allocate /64 blocks. The requirement is
that they allocate enough address space for all of their client's networks to
use /64s. As such, all recommendations are for /56 at least (which takes up
the exact same amount of space in their routing tables as /64 does: one
entry).

If v6 was 64 bits in total, then ISPs would need to be allocating something
closer to /48s to users at a minimum... but can you really imagine ISPs giving
/48s in a 64-bit space when many of those same ISPs don't even give something
larger than /64 in a 128-bit space? And this is despite the fact that a
/48-in-64-bits would be 256 networks of 256 IPs each, which is far smaller
than a /56's 256 networks of 2^64 IPs each? We know from v4 that 256 IPs in a
network is frequently too small.

I'm just not convinced that 64 bits is enough, and I don't think we should
expend this much effort deploying something that could be too small. Sure, it
_might_ be big enough with careful management, but I think it would be stupid
to take the risk.

If you were arguing for an 80 bit address space then I'd have a much harder
time calling it a risk, but for some reason 80 bits is an incredibly unpopular
length.

~~~
paulddraper
I misunderstood your criticism; I thought the blocks were too small.

------
Proven
I always disable IPv6 at home and computers I administer.

IPv6: for machines (IoT)

IPv4: for humans

~~~
philjohn
if it doesnt do ipv6 it's broken

~~~
donatj
I think that is an overstatement.

A car is not broken because it does not drive on rail, you can get you to the
same places.

There is currently very little you cannot do without IPv6.

~~~
philjohn
It's a well known quote.

There are ways to solve the IPv6 problem - and ISPs in Europe have
successfully rolled out both major variants, Dual Stack (Native IPv4 and v6
running alongside each other) or DSLite (Native IPv6 throughout the network,
CGNat at the edge for tunnelled IPv4 traffic).

Liberty Global have opted for DSLite, the last major network of theirs will go
live this year (Virgin Cable), BT and Sky (the two biggest xDSL providers)
have been live for over a year at this point with Dual Stack.

------
joeseeder
Yup, now you have to go out of your way to not support it.

Literary, every modern ISP, hosting or Cloud provides it.

Every Operating System, be it server or client or router, supports IPv6.

~~~
iagovar
No, most ISPs don't. In fact they are afraid of the transition, because of the
many glitches, the total lack of support of MANY devices on the consumer side,
retraining helpdesk, and so many more.

I work for a large ISP and we've done our tests. We ran one about five years
ago and it was a total disaster.

We're currently doing another one and we smoothed many things. Anyway it's not
something welcomed by the helpdesk side. If a client with IPv6 calls with
problems, the've found out that most of the times the only way to not spend
lot of time with the customer is change the setup to a ppoe v4 and forget
about it. And we've used competent people for this test, not you average joe
with 2 prior weeks training in networking.

Helpdesk agents hate it, and the come up with very good reasons.

~~~
ivlad
What exaclty are the reasons, why helpdesk agents hate it?

