
Five years of IPv6: whither the next five? - okket
https://blog.apnic.net/2017/06/06/five-years-ipv6-whither-next-five/
======
2bluesc
I've had IPv6 natively for 4+ years in San Francisco[0] on my residential
cable connection. This appears to be one of the few things Comcast does right.

Without any extra effort the following sites (small sample from Alexa top 500)
use IPv6:

* google.com

* youtube.com

* gmail.com

* facebook.com

* wikipedia.org

* netflix.com

Without IPv6 (no AAAA DNS records):

* reddit.com

* amazon.com

* twitter.com

* news.ycombinator.com

* imgur.com

* bing.com

* ebay.com

It's happening, slowly. ISPs who care are supporting it. A significant portion
of my every day web traffic is over IPv6 and nobody has noticed. People on my
local network are using it on Linux, Windows and Mac OS X and they don't even
know what IPv6 is.

Google is clearly leading the IPv6 charge and has a statistics page[1] for
those interested.

[0] [https://blog.kylemanna.com/ipv6/comcast-automatically-
enabli...](https://blog.kylemanna.com/ipv6/comcast-automatically-enabling-
ipv6-in-san-francisco/)

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

~~~
bhhaskin
Another major source of IPv6 traffic that most people are unaware of it the
cell networks. Most cellphone providers use IPv6.

~~~
2bluesc
> Another major source of IPv6 traffic that most people are unaware of it the
> cell networks. Most cellphone providers use IPv6.

Yes. I have T-Mobile in SF, and going to test-ipv6.com shows "10/10 readiness
score".

~~~
soloadventurer
0/10 here, on Cellcard in Cambodia. No IPv6 address detected, but the DNS
server appears to have IPv6 internet access.

------
luckydude
We'll be having the same post 20 years from now. NAT, for all its problems,
has more or less solved the IP address problem.

As a geek, one who has put the networking stack into the ETA-10 (yeah, I know,
nobody knows that machine, CDC spinoff super computer) and SCO's unix (yeah, I
know, it sucked), so as a geek who gets the stack pretty well, I've never
warmed up to IPv6.

To me, it seems like it went too far. 64 bits not enough? Really? Unless I'm
doing the math wrong 64 bits is enough for 2635249153 addresses for every
human on the planet.

    
    
        slovax ~/p bc
        2^64
        18446744073709551616
        ./(7*1000^3)
        2635249153.38707880228571428571
    

So 128 bits is needed why? I get that people used to say that 16 bits would be
enough and they were wrong and the 32 bit people were wrong. I just don't see
how we run out of 64 bits in the next $BIG_PILE of years.

I don't get it. Seems over engineered. IPv4 works pretty well, seems like a
slight improvement would have been enough.

~~~
zkms
> NAT, for all its problems, has more or less solved the IP address problem.

A bunch of very large-scale network operators (like Comcast, T-Mobile USA,
Verizon, and Facebook) seem to strongly disagree with that, given how eagerly
they've deployed IPv6 to get away from the hell that is IPv4 NAT and CGN.

Yes, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast,
mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.)
that mostly only look good through the rose-tinted glasses of the 90s and
significantly slowed down deployment -- and in the end mostly ended up as
"difference for difference's sake".

128 bits of addressing space and getting away from IPv4 NAT were unambiguously
good. 128 bits is a lot, but memory/bandwidth is just going to get cheaper
(for slow links you should use header-compression anyway), and it was better
to go whole hog and skip 64 and go to 128 to avoid a future 64->128
transition. Given how the 32->128 transition is going, this seems like it was
an excellent decision.

~~~
ra1n85
From an operator's perspective, 128 bits is more difficult to troubleshoot
compared to the 32 bits of IPv4. RFC5962 makes things easier, though only
marginally.

~~~
dingo_bat
Not to mention there is no int128_t in C. You have to use poorly defined byte
arrays to pass the thing around. It's irritating af.

~~~
CountSessine
typedef struct { uint8_t[16] d; } ipv6addr;?

~~~
dingo_bat
Which is a byte array. When you pass this to a function, it does not fit in a
single register. The equality operator doesn't work, nor do other logical
operators. Everything has to be defined. 64 bit would have been so easy. And
it would still have been enough.

Edit: somebody replied and deleted their comment. Since I had written a
response I am editing this comment.

> Then your real complaint... is that you don't have 128-bit machine registers

Agreed, although my real complaint is more towards IPv6, for not thinking
about this real-life limitation.

> what the urgent need to pass IPv6 addresses in machine registers

It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had
this problem and still would have enough space for everyone on earth.

> And how is it "irritating af"?

Apart from the speed concerns: > The equality operator doesn't work, nor do
other logical operators. Everything has to be defined.

~~~
deathanatos
> _When you pass this to a function, it does not fit in a single register._

Depends on the architecture. On amd64 (the architecture I'm typing this
comment on), a 128-bit struct, like defined above, will fit in registers —
yes, in 64-bit registers. The amd64 ABI[1] will split them across two
registers. For example, if we take the above struct and use it,

    
    
      void foo() {
        ipv6_addr addr = { { 1, 2, 3, 4, 5, 6, 7, 8, }, };
        bar(addr);
      }
    

This compiles to:

    
    
      movabsq	$578437695752307201, %rdi
      xorl	%esi, %esi
      jmp	bar
    

The nasty looking number is the initialization; it's easier to see in hex:

    
    
      In [1]: hex(578437695752307201)
      Out[1]: '0x807060504030201'
    

That ends up in %rdi, the first of the amd64 arg-passing registers. The next
half is zeros, so it goes in %rsi (the compiler just zeros it). Then we "call"
bar. (There is tail-call optimization here)

The non-optimized version is similar, but more drawn out:

    
    
      # for some reason we zero it first
      movq	$0, -16(%rbp)
      movq	$0, -8(%rbp)
      # then we init it again… okay gcc.
      movb	$1, -16(%rbp)
      movb	$2, -15(%rbp)
      movb	$3, -14(%rbp)
      movb	$4, -13(%rbp)
      movb	$5, -12(%rbp)
      movb	$6, -11(%rbp)
      movb	$7, -10(%rbp)
      movb	$8, -9(%rbp)
      # move the struct into rdx/rax
      movq	-16(%rbp), %rdx
      movq	-8(%rbp), %rax
      # just to move it into the arg-passing registers
      movq	%rdx, %rdi
      movq	%rax, %rsi
      # call the function
      call	bar
    

> _It 's much slower than IPv4 to deal with! 64 bit addresses wouldn't have
> had this problem and still would have enough space for everyone on earth._

It's twice as wide, yes, but that doesn't _necessarily_ mean you're needing to
pass it in memory.

> _still would have enough space for everyone on earth._

IP addresses aren't just numbers assigned to machines. They must also —
effectively — encode the _route_ to that machine; you can sort of imagine it
as a tree, with each bit giving you successively more local directions on the
Internet. Now, of course, that's not _exactly_ how it works, but the point is
that some parts of that tree are going to be sparsely populated. Having a
wider address space means you can make bigger, but not necessarily full,
allocations in the address space, allowing you to keep whole networks together
in a common prefixes, which results in simpler routing tables. (At least,
that's the idea as I understand it.)

And it's not just 1 per person: I have more than one device, and I move
between networks during the course of a day. If all of the networks I
frequented actually had IPv6, I'd bog down _at least_ 6–8 IPv6 addresses
during the course of a boring day, and that's not counting stuff like
networking equipment.

It's not just a simple question of "are there enough bits to assign each
person an address"

> _The equality operator doesn 't work, nor do other logical operators. _

On amd64 at least, __int128_t exists, I believe, and I think it should come
with operators. In higher-level languages, you can define < and == simply
enough.

Now, I grant that the above is _highly_ architecture specific, and there
definitely exist architectures where this doesn't apply. And those, yes,
128-bit will be slower than a theoretical 64-bit. I just don't think it's
worth worrying about.

[1]:
[https://software.intel.com/sites/default/files/article/40212...](https://software.intel.com/sites/default/files/article/402129/mpx-
linux64-abi.pdf)

~~~
lloeki
> IP addresses aren't just numbers assigned to machines. They must also —
> effectively — encode the route to that machine; you can sort of imagine it
> as a tree, with each bit giving you successively more local directions on
> the Internet. Now, of course, that's not exactly how it works, but the point
> is that some parts of that tree are going to be sparsely populated. Having a
> wider address space means you can make bigger, but not necessarily full,
> allocations in the address space, allowing you to keep whole networks
> together in a common prefixes, which results in simpler routing tables. (At
> least, that's the idea as I understand it.)

Exactly, and the huge address space allows the standard to right out set some
structure to it, with 48 bits for global routing, 16 bits for subnet
addressing, plus 64 bits for link-local, interface identifier. Routing is only
concerned about the first 64 bits (which has all the fast operations you could
dream of) and _global_ routing only the first 48 even. Obviously doing some
work to match the topology to the address space in a smart way by leveraging
CIDR to reduce the size of routing tables is always going to be useful.

[https://en.wikipedia.org/wiki/IPv6_address#Unicast_and_anyca...](https://en.wikipedia.org/wiki/IPv6_address#Unicast_and_anycast_address_format)

------
MrRadar
It's interesting how his chart deflects somewhere around 80%, since at the
2017 Rocky Mountain IPv6 Summit that's about where T-Mobile US (who probably
have the highest penetration of IPv6-capable endpoints of any ISP) noted their
transition started slowing drastically.[0] The main reasons are that the
remaining devices are old (e.g. 3G phones), have limited capabilities/needs
(e.g. embedded IoT devices which just need to phone home once in a while), or
are using odd configurations (e.g. for some reason T-Mobile doesn't currently
support IPv6 for tethering).

Another good talk from that conference is about how Carrier Grade NATs are
(amazingly) even worse in practice than they sound in theory[1]. During the
Q&A portion one of the audience members points out that as technologies like
CGN become required to provide IPv4 service it will cause the cost of
supporting IPv4 to rise over time and naturally push ISPs to kill IPv4 as the
use of v4 drops while the costs to support it do not.

I can also recommend a short talk by Cloudflare about their experience serving
IPv6 traffic[2] and another on the history and future of IPv6[3].

[0]
[https://www.youtube.com/watch?v=nNMNglk_CvE](https://www.youtube.com/watch?v=nNMNglk_CvE)

[1]
[https://www.youtube.com/watch?v=fbk4H6EmZzI](https://www.youtube.com/watch?v=fbk4H6EmZzI)

[2]
[https://www.youtube.com/watch?v=2RGzR5eMfcg](https://www.youtube.com/watch?v=2RGzR5eMfcg)

[3] [https://www.youtube.com/watch?v=p_HbX-
batjs](https://www.youtube.com/watch?v=p_HbX-batjs)

------
eth0up
I remember the first time I looked at my ip6 address and found my MAC in the
host portion. Obvious and predictable as it might be to some folks, it
surprised and annoyed me. With a unique MAC in every assigned ip6 address,
it's pretty easy to imagine the tracking potential, e.g., a unique ID
following a user where ever an ip6 address is assigned. Apparently Apple and
even Network-Manager(Linux) automatically randomize/obscure the MAC for ip6
addresses - I don't know about Windows though. Using wicd in Linux, I must
either randomize the MAC manually, or configure sysctl.conf accordingly.
Otherwise, it's great, I suppose, that every atom in the known universe can
have its own ip.

~~~
mgbmtl
When my residential ISP started allocating IPv6 blocks, they published our
postal codes in the whois database. In Canada, in a city, that postcode is
basically a dozen buildings (one side of a street block), at least where I
live. For a stalker, it's practically a full address.

We pressured the ISP to remove this information. They resisted, said it was
policy, we read the RFCs and argued back. A few weeks later it was removed.

Similarly, most Linux distributions now enable IPv6 privacy extensions. Once
people settle in their habits, it becomes more difficult to change this type
of behaviour.

IPv6 is a big change. Adopt early, influence policy while you can :)

~~~
kalleboo
When I was a student, my rDNS was the student housing building number +
apartment number. Makes it easy for people to direct abuse requests at least.

------
ryandvm
After watching Windows, Python3, and IPv6 all go through decade long upgrade
cycles, I'm hoping we've all learned some valuable lessons about the hidden
costs of backward compatibility.

~~~
phicoh
Alternatively, the computer industry forgot about backward compatibility and
now has to relearn it.

Color TV was designed to be compatible with black&white. Stereo FM radio
compatible with mono, stereo vinyl records with mono. Electricity changes
very, very slowly.

When computers become such an essential part of every day life, you cannot
make radical changes any more every couple of years.

If your design becomes successful, you may be stuck with it for a couple of
decades.

The failure of IPv6 is also the success of IPv4 engineering. When IPv6 was
designed in the mid 90s, there were many issues that might hold back IPv4 down
the road.

It is only in the last couple of years, that issues (related to the IPv4
address shortage) pop up that basically cannot be solved anymore and make IPv6
an attractive alternative.

~~~
MrRadar
> The failure of IPv6 is also the success of IPv4 engineering. When IPv6 was
> designed in the mid 90s, there were many issues that might hold back IPv4
> down the road.

Another big part of it is that all of the features of IPv6 _except_ the
address length change were back-ported to IPv4 (e.g. address auto-assignment
and IPsec) removing the carrots and leaving only the "stick" of the IPv4
address shortage (which barely registered at all until a few years ago) to
push people to v6.

------
gerdesj
Multi-link routing is the only thing that IPv6 fails to address effectively.

I've just read the usual crappy "why 2^128" bollocks etc (you don't run
internet routing, do you) here and the other usual whining.

However, how do you effectively use multiple connections to the internet,
without resorting to PI and something like BGP?

~~~
ra1n85
Can you clarify what you mean by multi-link routing? Are you referring to
multipathing?

What is stopping you from using multiple connections to the internet?

~~~
gerdesj
Say you want multiple links to the internet - redundancy/cost/whatever.

Each link will have a prefix that you are delegated and your SLAAC or DHCPv6
will give out addresses etc.

Now which one will your device use? Your PC cannot know that link C is down
because that is only known by your router.

IPv6 does not address the same basics that IPv4 failed at - routing around
crap, without a routing protocol.

~~~
ra1n85
That makes no sense.

The kernel routing table of your PC should remove the link once the PHY has
been detected to be down. That's even if your PC supports multipathing.

We don't rely on layer 3 to communicate a link is down to us - we rely on
layer 1.

~~~
izacus
When cable/DSL falls down, it's not going to take PHY down. You'll have active
ethernet but no packets will come through.

With IPv4 the router will just fix up NAT. With IPv6 you now have to deal with
significantly more complexity.

~~~
ra1n85
>With IPv4 the router will just fix up NAT. With IPv6 you now have to deal
with significantly more complexity.

How so?

In a multihomed environment, you'd still be PAT'ing to unique addresses on the
WAN side (unless a FHRP is in use, which would be rare) - if one of those
links go down, so too does all of the flows associated with address of the
link. If no dynamic routing protocol or redirects are in use, the gateway with
the down link will also eat half (assuming two gateways) of all egress
traffic.

IPv6 should be easier as no NAT/PAT is in use, therefore you have no
challenges with statefulness or routing symmetry.

~~~
izacus
It SHOULD be easier. It's not on current widely available prosumer hardware.

Yes, your connections will get temporary eaten. But for the typical developers
workload that won't be a huge issue because most connections you do are short-
lived. Configuring all your clients to properly switch vs. configuring your
NAT router (with builtin functionality for exactly that) is orders of
magnitude more complex.

------
iso-8859-1
Android doesn't support DHCPv6 and SLAAC is not good enough. We need consensus
on sufficiently sized prefixes using DHCPv6 Prefix Delegation. See
[https://en.wikipedia.org/wiki/DHCPv6#Implementation](https://en.wikipedia.org/wiki/DHCPv6#Implementation)

This is the next big step as far as I see it.

------
bhhaskin
I have switched to IPv6 at home for a few years now. I love it. I wish my work
supported IPv6. The ability to have multiple VMs be able to have incoming
connections is great. No more having to do wired ports for NATing reasons
although an IPv6 firewall is a must.

------
hannob
I'm not super familiar with the development in the low level network space,
but I really wonder what the plan for IPv6 is.

IPv6 has been the future of IP networking for decades. Yet here we are and I
still often surf the Internet without v6 connectivity.

It suffers from a fundamental problem: As long as IPv6 is not universally
available nobody has a real advantage from supporting it. But as long as it
provides no advantage many ISPs and web server operators won't bother
supporting it.

I think this is a design flaw. IPv6 was built without a plausible transition
plan. The plan "over time more and more people will switch to v6 and at some
point everyone will have it" clearly doesn't work and will never work.

~~~
manacit
There was a time when running out of IPv4 addresses meant that ISPs and other
providers _had_ to switch to IPv6, or they would run out of addresses (or
spend too much acquiring them). With NAT and stuff, that risk has seemed to
decrease significantly.

Google statistics show that nearly 20% of their traffic is over v6, which is
honestly not bad. The USA itself is 35%, with no latency hit.

~~~
hannob
> Google statistics show that nearly 20% of their traffic is over v6, which is
> honestly not bad. The USA itself is 35%, with no latency hit.

This is totally bad. We need close to a 100% for v6 to make any sense. 20%
IPv6 is pretty pointless.

~~~
josteink
> This is totally bad. We need close to a 100% for v6 to make any sense.

Considering how it was 2% not many years ago, this is a huge improvement.

What's going to drive this further is that the cost of supporting IPv4 will
increase more and more as IP-space is exhausted and ISPs will have to apply
new hacks like CGN.

At that point getting people to IPv6 and IPv6-only will be a purely be about
economics.

------
chiph
How to see if your connection is IPv6:

[http://ipv6test.google.com/](http://ipv6test.google.com/)

~~~
iso-8859-1
It will show a green check mark even if you don't have IPv6, just to show that
you won't have problems with timeouts...

------
jtl999
Have we figured out good ways to gracefully handle prefix changes via
DHCP6-PD. I'm kind of worried of my provider changing my prefix "from under my
feet" and breaking firewall rules, or worse.

Also my ISP blocks some ports incoming lst time I checked, even on IPv6, even
on their business plans, without a static IP. And I assume they would do the
same with v6 because they don't support static prefixes themselves.

To be fair their IPv4s are _very_ static and only change when I change my WAN
MAC address or am offline for longer than a DHCP lease (power outage)

------
autokad
boy world war 2 really put a dent in clothes washer adoption. That aside, it
feels like the adoption sort of resembles 64 bit windows adoptions. took a
while but it happened bit by bit

~~~
vacri
but interestingly, fridge adoption kept powering on.

------
Animats
Is he measuring IPv6 visibility in DNS, or IPv6 traffic? China went to mostly
IPv6 for mobiles years ago. Where else could they get enough addresses?

~~~
nine_k
With Neftlix and Youtube using IPv6, the majority of _traffic_ of an average
household may as well be on IPv6 already, where available at the last-mile
level.

------
super-io
Folks in this thread claimng to be using IPv6. Anyone using cjdns? Best use of
IPv6 I have heard about so far.

------
abpavel
The #1 mistake IETF did was not making IPv6 compatible with IPv4. It's hard to
comprehend for most, bug essentially we're building a whole new separate
Internet. The old Internet, or the Internet Classic (v4) and the New Internet
- The v6 Internet. IPv6 is a totally new protocol - new L2 interaction with
Neighbor Discovery (i.e. has no concept of default gateway), new routing
tables, new route-maps, nes access lists, new BFD,... Therefore new topology,
new routing behavior, new resiliency and redundancy mechanisms... Just because
hardware allows running v4 and v6 stacks side by side, it doesn't make them
compatible, just easier to implement by not having to buy new hardware for
both.

~~~
deathanatos
> _making IPv6 compatible with IPv4._

This gets suggested and rehashed on every single IPv6 comment section. There
is no way to make IPv6 compatible with IPv4: by the Pigeonhole principle,
there is simply no way to reference 2 ^ 128 objects using only 32-bits. The
next usual hack is to "add an option" or something; but all the routing
hardware would need to understand that option, which entails upgrading the
entire Internet, which is exactly what IPv6 is doing/has done, except that
adding an option ends up with a _worse_ design.

Any suggestion needs to fulfill a. any machine should be reachable and b. you
can't upgrade everything, or you may as well just go with what we've got.

~~~
akvadrako
I don't think even many of the IPv6 designers would agree with you.
Originally, IPv6 was supposed to bring a large set of improvements, like
first-class encryption, larger minimum packet sizes, stateless addressing and
auto-configured routing. It wasn't just more bits.

In the end either all those things were backported to IPv4 or turned out to be
bad ideas. IPv6 ended up being just more bits, but with a fully incompatible
implementation.

If they had known this at the beginning, we could have transitioned to IPv6
long ago, by designing for a smooth transition period and reusing as much of
the IPv4 stack as possible.

An end-to-end extension header would have been simple - something that can
fallback to NAT connection tracking when it's not recognised. And it would
have saved man-centuries of effort.

------
Qantourisc
Been 5 years already ?; still not a word from my ISP :/

~~~
kalleboo
My ISP supports IPv6... if you configure a second, PPPoEv6 connection on your
router. Which as far as I can tell none of the top routers on the market here
support. Heck even OS X doesn't seem to support it.

~~~
zAy0LfpBZLC8mAC
> PPPoEv6

There is no such thing, it's still PPPoE and PPP, just that there is IPV6CP
and IPv6 on top of PPP. And that, in principle, can run through the same PPP
session as IPCP and IPv4, though a weird ISP might not support that,
obviously.

------
zebraflask
v6 doesn't work with a lot of VPNs.

------
nik736
I don't think we will see IPv6 eliminating IPv4 within the next 10 years. As
long as IPv6 is used in parallel there is really no advantage since IPv4
depletion is still an issue and you need to use both. Since switching and
routing IPv6 is more expensive the current hardware in use won't even be able
to handle all the load and until every switch and router (at home and in the
datacenter) is replaced 10 years will go by in no-time.

Also, most people who ask for IPv6 for their VMs or whatever don't even have
any use for it. IPv6 will be a huge mess, if I only think about sending emails
via IPv6, how should that even work properly?

~~~
rjsw
Routing IPv6 can be less expensive as you need to do one checksum fewer than
for IPv4.

Email works fine.

~~~
nik736
Email works fine technically for sure. But what about handling things like
spam? How are projects like spamhaus supposed to work with nearly infinite
IPv6 addresses?

This is extremely hard with IPv4 already, it will be a huge mess with IPv6.

~~~
flyinghamster
IPv6 blacklists seem to be based on /64 prefixes rather than individual
addresses. That hit me when I was enabling an IPv6 MX on a VPS; I had to get
my own /64 prefix rather than use the standard default single address, since
the default lied within a spammer-contaminated /64 block.

I know it seems rather excessive to use an entire /64 and only populate a few
addresses, but I'd rather have too many addresses available than too few.

~~~
cm2187
But how do you know you should use a /64 mask? One of my hosting providers
assigns much smaller subnets. Some others assign /56\. You are at risk of
blocking many legitimate IPs and missing many others.

~~~
profmonocle
> But how do you know you should use a /64 mask? One of my hosting providers
> assigns much smaller subnets.

It's baked into the standard that IPv6 networks shouldn't be smaller than
/64\. If a provider is disregarding the standard so blatantly I would probably
avoid them.

Really, why on earth would a cloud provider be so stingy with IPv6 that they'd
give less than a /64 per customer? ARIN gives out /32s like candy and a single
/32 can be split into ~4.3 billion /64s.

~~~
daurnimator
Sadly the ISP for internet to our office building only gave out a /65... that
we are meant to share with ~20 companies.

Suffice to say I've got IPv6 to the internet gateway, but no further. => They
fulfilled their contractual obligation to "provide ipv6 connectivity", while
being entirely useless. They'll probably use us as a stat to prove that no one
wants ipv6 anyway...

There is no choice in provider.

~~~
cm2187
But why /65 is such a big deal? You can divide it in 32 different /70 subnets,
one per company. That still leave you with 2^58 IPs by company. You can still
even use MAC addresses in your IPs.

~~~
zAy0LfpBZLC8mAC
SLAAC on ethernet requires a /64\. A provider assigning you anything but at
least a /48 is pure incompetence, if it's explicitly for 20 companies, they
really should be giving out a /43.

~~~
cm2187
Yeah but stateful vs stateless DHCP is really a minor problem.

~~~
zAy0LfpBZLC8mAC
> is really a minor problem.

So, it's a problem. For no reason at all.

Also, no, it's not really just a minor problem. Reconfiguring your one client
device might be trivial, but that's really not the question.

The question is what you do with a setup with a few dozen
devices/machines/routers/whatever.

First of all, even if you do a new setup, it's idiotic that you'd have to
consider the idiosyncrasies of your ISP when designing your network, instead
of choosing whatever setup fits your internal requirements best. That you
possibly cannot buy a certain printer because it doesn't support DHCPv6, or
whatever.

But it's a lot worse when you think about switching ISPs with an existing
setup: Having to completely rebuild your network because of your ISP's idiocy
is ... well, idiotic. Suppose you have a bunch of routers that do SLAAC for
end devices and obtain prefixes via DHCP-PD from the uplink router. Really,
all that should be technically required in such a setup to switch from one
provider to another would be to unplug the old line, plug in the new line,
everything should renumber automatically, while keeping the exact same network
structure. Good luck reconfiguring all of that to work with a /65 ... and when
you have done that, tell me again that it's a minor problem.

~~~
cm2187
You don't need to set up your clients with IPv6 more than you need with IPv4.
Your router will do DHCP in just the same way. To me this is only a minor
inconvenience.

~~~
zAy0LfpBZLC8mAC
You might as well be saying that electrical installation is trivial, as it's
just a plug you need to plug into the wall.

All the stuff that I've been talking about is what is required so that in the
end, you can just plug in your laptop and have IPv6 connectivity without any
manual intervention on your part. Yeah, that's how it is supposed to be. But
that depends, among other things, on the ISP providing a reasonably sized
prefix.

Also, there is more to networks than "the router" and "clients". You can have
more than one router, you can have servers, you can have routers with multiple
interfaces that are isolated from one another ... not everything is "my home
DSL router with built-in WiFi access point, used by one smartphone, one
tablet, and one laptop".

And I think you might be confusing SLAAC with DHCP? Those are two completely
distinct mechanisms, and you don't need DHCP in IPv6 networks at all, in
particular not for client systems.

