
An update on IPv6 - AndrewDucker
http://www.potaroo.net/ispcol/2015-06/ipv6.html
======
ghshephard
The article engages in a little bit of hyperbole with statements like this:
"Not only is this a protracted calamity for the Internet".

I work in a lot of regions in the world, (Mexico, UAE), where they've been
used to the reality that they won't be assigned _any_ IPv4 addresses. I'm
talking about large $Billion+ organizations that made it abundantly clear to
me, that the applications we were deploying ($100million plus network
deployments) - would have to operate with PAT, or we would not be able to
deploy them.

And so we worked around the requirements that we deploy everything on PAT, and
our network deployments (sometimes with thousands of IPV4 network elements)
would have to operate purely within RFC1918 address space.

Speaking as someone who has worked on million+ IPv6 node deployments, (So I
clearly don't have a bias _against_ IPv6) I can say with some certainty that
the only "calamity" we are going to see is increased use of PAT on clients,
and somewhat more expensive IPv4 addresses for those who need to act as a
server. Everyone else will be fine. (Have been fine for years in places where
public IPv4 addresses ceased to be available).

The reality is that this lack of pressure to transfer to IPv6 means that we're
going to see an extended period of time in which we migrate. It will happen
eventually (IPv6 has a lot of awesome features, particularly around self-
addressing, and lord is it wonderful not to have to play CIDR addressing
games, everything is a ::/64) - but it's going to be a lot longer than most
IPv6 advocates would prefer.

~~~
danellis
> lord is it wonderful not to have to play CIDR addressing games, everything
> is a ::/64

/64 is the smallest network, but there are certainly larger aggregates with
smaller prefixes.

~~~
ghshephard
Yes - you're absolutely right. There are administrative collections of /32s,
/48s, /56s - but when it comes time to lighting up a network interface - it's
a /64\. Even if I only have two devices on a network segment, (two routers
that can perform ND with each other), a place that would have used a /30 in
the IPv4 space, I'll light up a /64 and burn the other (2^64)-2 addresses.
With the possible exception of some security scenarios in which a /127 might
be desirable, there is no "address conservation" requirement to use blocks
smaller than a /64.

For those IPv4 network engineers who have a decade+ of jugglings /25s, /26s,
/27s, /28s and /29s, and trying to preserve IP space (particularly globally
routable), this is nice change of affairs.

~~~
danellis
Okay, sure, on hosts you're only going to see /64s, but unless I'm seriously
misunderstanding something, anyone dealing with route aggregation is going to
have to deal with smaller prefixes.

And even just talking about "this is global unicast space", "this is 6to4
space" and "this is link local space" involves small prefixes. So, for
example, you still need to do the same mental juggling to know that 2000::/3
is 2000... to 3fff....

~~~
ghshephard
Agreed. You can't get away from network blocks at the administrative routing
level. But, at least life is a bit easier by making more common use of /48s
and /32s - I.E. 2001:1868::/32 being 2001:1868:0000:0000::/64 ->
2001:1868:FFFF:FFFF::/64.

Thankfully, the 100x more common task of configuring an interface, will always
be a /64.

------
1ris
What I think will really start the network effect is the fact that apple
requires APPs for the new iOS to work in a IPv6 only environment. That means
if Twitter wants to use the latest and greatest features they will have to
make their service available via IPv6.

So IPv6 only connections will start to become a vialbe end-user product. These
will be cheaper than dual-stack installations, so the ISPs will push them.

~~~
mirashii
> That means if Twitter wants to use the latest and greatest features they
> will have to make their service available via IPv6.

This isn't really necessarily the case. The full details on the requirements
for Apple's required "support" for IPv6 are sparse still, but there's no
reason that this can't be done with NAT64.

------
abvdasker
The article briefly touches on this, but I'm mainly interested in IPv6
adoption for the possibilities it opens up in peer-to-peer communications by
removing the need for NAT. Imagine the possibilities if WebRTC didn't require
the use of STUN/TURN/ICE servers to work properly and browsers could simply
talk directly to one another.

~~~
whistlerbrk
I think that is (tin foil hat) perhaps one of the reasons for the hold up.
IPv6 makes true p2p possible and will open up a lot of pirating possibilities.

------
rwmj
I know this idea has long missed the boat, but why wasn't IPv4 address space
extended by adding an IPv4 Option header that could carry extra address bits?

You could even have made IPv4 addresses variable length this way, from 32 up
to a very large number of bits, and hierarchical. And it's relatively easy to
make such a scheme backwards compatible, because you can have (say) a
webserver sitting on 1.2.3.4 answering queries for older clients that don't
know how to form a 1.2.3.4.5.6 address packet.

~~~
josteink
> I know this idea has long missed the boat, but why wasn't IPv4 address space
> extended by adding an IPv4 Option header that could carry extra address
> bits?

Because that wouldn't be compatible with existing IPv4 deployments and would
cause a reliability havoc when a node not configured to deal with it mangled
packets transparently somewhere in between your source and destination end-
points.

I don't get the resistance against IPv6. It works. It's a fresh take. Yes it
requires some new stuff to be deployed and configured here and there, maybe
even requires you to learn something new, but if you thought extending IPv4
would have been any other way you are deluding yourself.

If you're going to do a significant change to something as big as the internet
(and introducing a new address scheme is that, no matter how you implement
it), you might as well step back and think it all through instead of applying
yet another hack.

So tell me. Why are you opposed to IPv6? Why do you want to hang on to this
old IPv4-thing which is already at the bursting point, at the edge of what it
can take?

~~~
mirimir
> So tell me. Why are you opposed to IPv6?

I'm very concerned about implications for anonymity. If every device has a
unique IPv6 address, then just one leak can compromise all other anonymized
connections.

~~~
xorcist
Check out RFC 4941, "Privacy Extensions". It's probably already implemented on
the computer you're using right now.

~~~
spystath
You can still track the prefix though. In a standard /64 deployment only the
suffix will change so there is still some information leaking if you have a
static prefix (obviously, as in static IPv4). However, my ISP defaults to
dynamic /64 prefix unless you opt in for static prefix. I believe most ISPs
should probably do the same.

~~~
wtbob
If you have a dynamic prefix then you can't (easily) run servers; you'd need
some sort of dynamic DNS as well. And if you have dynamic DNS and dynamic
reverse-resolution…there goes anonymity anyway.

IP isn't anonymous; it wasn't designed to be, and probably (given the problems
it's trying to solve) shouldn't be. Anonymity should be an overlay.

~~~
spystath
If you run a server you pretty much need to expose your IP one way or another
anyway, even in IPv4. Well, I suppose you can use something like dynamic dns
but still...

I totally agree, though, anonymity is not part of IP. I was not implying that,
just that there are still ways for home users to somehow shuffle their IPs
within the IPv6 framework.

~~~
mirimir
If I need to run a server, I anonymously lease hosted VPS or whatever, and SSH
via Tor. My concern is keeping my personal Internet connectivity anonymous. I
use nested VPN chains, generally using pfSense VMs as VPN clients, and Tor.

I get that the Tor Project is working on IPv6. But I also want IPv6 NAT, in
pfSense or whatever. That's to keep my local device IPv6 addresses (hosts and
VMs) private, even from Tor entry guards. I guess that it's time to learn how
to ensure that.

------
cm2187
What I don't understand is what is the cost to an ISP of switching. Whether it
is network devices or users devices, unless they are more than 10yo, I would
expect them to be all IPv6 compatible. So yes it will involve some
reconfiguration, training engineers and support, but it looks like a
relatively small investment to me. The switch to optic fibre is a way bigger
investment.

~~~
ghshephard
Financial cost, even in training, isn't high. It's mostly two things -
Inertia, and ROI. All of the network engineers know IPv4 ins and out really,
really well, and have a mindset of not messing with stuff that's working. And
ROI - what financial incentives does an ISP have to switch to IPv6, either in
increased revenue or reduced costs?

~~~
vacri
There's also considerable cost in being an early bird. You get to find all the
chinks in the protocol, all the bodgy firmware issues... all for no
substantial change to the income stream.

------
sz4kerto
IPv4+NAT still works well, because the internet is more and more centralized.
Sadly.

~~~
pdkl95
No, NAT doesn't work well at all. Everybody that says this isn't taking into
account the massive amount of software that wasn't even started in the first
place because it wouldn't work behind a NAT.

In fact, I would suggest that NAT is responsible for a lot of that
centralization, as the workaround for not being able to listen(2) for your
friend you want to communicate with is a centralized service to manage that
connection.

One of the original benefits of TCP/IP networking was that every peer was
equally client and server in the eyes of the protocol. The damage done by NAT
has been the _de facto_ removal of that benefit. Even now when reasonably-
reliable (but INCREDIBLY complicated) NAT-traversal protocols exist, a
centralized service is still required, nullifying the benefit of being able to
_publish without the permission[1] of a central authority_.

[1] [https://www.fourmilab.ch/documents/digital-
imprimatur/](https://www.fourmilab.ch/documents/digital-imprimatur/)

~~~
pilif
_> In fact, I would suggest that NAT is responsible for a lot of that
centralization, as the workaround for not being able to listen(2) for your
friend you want to communicate with is a centralized service to manage that
connection._

IMHO, IPv6 won't fix this problem for many cases. Consumer routers still won't
allow inbound connections, so there will still be the need for some kind of
way to allow the client to tell the router to forward traffic on a specific
port (likely
[https://en.wikipedia.org/wiki/Port_Control_Protocol](https://en.wikipedia.org/wiki/Port_Control_Protocol)).

Which is exactly the same as we get these days with NAP-PMP or UPnP.

Maybe once listening on all local interfaces will not listen on temporary
addresses, we can move to a one-address-per-service model at which point it
becomes more feasible to forego the central firewall dropping all incoming
connections as port-scanning the machine you just got a connection from will
involve scanning 65536 * 2^64 ports

As it stands now, I'm not willing to expose all open ports of my internal
machines over IPv6. Instead I still have specific port opening rules on my
central firewall.

While I have no issue exposing, say, Skype on some port, I _certainly_ don't
want to expose, say, my local NTP port of my Mac, or, worse some local port
mapper needed for NFS mounts.

Yes. I could use a local firewall, but these by default only allow a per-
application setup. "Do you want to allow NTP to be reachable?" \- To my local
network? Yeah. Maybe. To the internet? Hell no.

Current simple built-in firewalls don't allow this kind of answer - at least
on the mac.

~~~
pdkl95
I never claimed anything about IPv6, though it _would_ fix most of the NAT
problem. Most of what you're talking about is based on how the current NAT
infrastructure works... which was sort of my point: NAT badly limits the scope
of how we think about software, because so many designs rely on being being
able to even _name_ hosts uniquely. Designing software for the NAT "party-
line" suddenly requires inventing things like remapping ports to make anything
work.

A particularly bad misconception that ubiquitous NAT has encouraged is the
conflating of the address-translation step (NAT) with the _firewall_ , when
the two concepts are not related at all. You can run either independently of
the other[1].

All that is needed for a home router is a simple firewall, and a way to open
holes in the router's firewall from the internal hosts. The fact that this
software isn't already available on most OS/home-routers is simple lack of
demand... and the fact that it would be totally useless for current NATed home
networks. You don't need all of UPNP or NAT-PMP; there are no ports that need
to be mapped. The difficulty in introducing something to allow certain types
of packets through a firewall is trivial compared to the complexity of working
around NAT.

Concerns about port scanning and "expose all open ports" are just nonsense,
and has nothing to do with NAT. This all-or-nothing approach you seem to be
assuming misses the entire point of having an external firewall (such as on an
home router). You get to pick which packets you let through.

[1] This is why NAT doesn't provide security on it's own. Static NAT, for
example, is just substituting the address; _all_ packets to the public address
are forwarded to the translated address.

------
jorangreef
If I'm not mistaken, I think the MTU for IPv6 is at least 1280? But possibly
also going to end up as no more than that because IPv6 does not necessarily
require people to support more than that?

If so, then that could mean that packet sizes are going to be constant over
the next 20 years, all the while that protocols and pipes get many times
faster and bigger. If I'm not mistaken, those smaller and smaller packet sizes
(relative to faster and faster networks) are going to mean tremendous packet
switching overhead (routing, encryption) especially in protocols such as QUIC
which try to align encryption with packets.

Sort of like a plane having to stop at every red light in a traffic grid
designed for cars.

~~~
pjc50
[https://tools.ietf.org/html/rfc1981](https://tools.ietf.org/html/rfc1981) :
path MTU discovery SHOULD be implemented in IPv6.

~~~
jorangreef
Thanks, that is my concern. I think the "SHOULD" should have been a "MUST" (or
should still be changed to a "MUST") to ensure a forward upgrade path for
larger MTU in future. Otherwise, the network is going to be limited by the
lowest common denominator, namely those clients which do not implement any
path MTU discovery because it's not a MUST, and only support an MTU of at
least 1280 (but no more).

~~~
throwaway2048
You have to realize that RFCs are not a cudgel to bludgeon people into acting
how you would like them to, that never ever works out in reality (at one point
IPSEC was a mandatory MUST for ipv6 deployments) because people are free to
just ignore them if it makes their life too difficult, and trust me they can
and will, no matter what any standard says.

RFCs should, and at least with the popular ones, generally do, reflect the
status of how things actually work on the internet, not how we might wish they
did. If your standards ignore reality, they in turn will be ignored.

Rightly or wrongly a LOT of networks block ICMP wholesale, and thus block
pmtud, it does not matter if some word in a text document changes somewhere,
this will continue to be a reality, so you better be aware of it and be able
to cope with it.

Rough consensus and running code.

~~~
jorangreef
I doubt that "how things actually work on the internet" is "generally"
reflected by RFCs. The history of the internet is people trying to work around
and fix RFCs actually ("at least with the popular ones"). If you're going to
say "SHOULD" you may as well leave it out because people won't follow it.

~~~
throwaway2048
You are still taking a way too strongly legalistic view of things, standards
are not laws (usually). Its not a "everybody conforms to the spec 100% or its
worthless" situation in the vast majority of cases.

SHOULDs exist precisely because of situations like pmtud, you cannot gaurentee
it will be supported, but when it is supported it is helpful and useful.

~~~
jorangreef
Frankly, the original concern is that fixed packet sizes relative to
increasing capabilities are not a good idea for future hardware and software
performance (think silly window syndrome or allocating a million 1-byte
buffers). It's a technical problem that needs a technical solution (preferably
through clearer language describing the issue or else we need to rethink
things). I guess most people are simply not writing protocols that will be
influenced by these decisions, so they fail to see the impact.

Furthermore, no one said this was about "cudgels" and "bludgeons" or being
"too strongly legalistic" or writing "laws". Those are your words, not mine.

~~~
throwaway2048
the implied goal of changing a SHOULD to a MUST is to force people to comply,
im simply trying to communicate that its really not that simple.

------
suprjami
I am looking forward to the day when global IPv4 gets turned off.

They should do it on a World IPv6 Day, how about 6/6/16?

~~~
AndrewDucker
Might take a bit longer.

Looking at
[http://www.google.com/intl/en/ipv6/statistics.html](http://www.google.com/intl/en/ipv6/statistics.html)
it's doubling every year. So it's going to take another four to reach
everywhere.

Maybe 6/6/2020 :-)

(And there are plenty of IPv4-only devices out there, like printers, Consoles,
etc. So I suspect another five years after that before there's so little left
that the address space starts clearing up again.)

------
mino
This are the video/slides of the talk that Geoff Huston (author of the post)
gave at the last RIPE70:
[https://ripe70.ripe.net/archives/video/118/](https://ripe70.ripe.net/archives/video/118/)

Very interesting point of view imho ("bring IPv6 to the rich first, the others
will follow").

------
facepalm
Wall of text.

I still don't know how to use IPV6. Maybe it is just too complicated and they
should come up with something simpler?

~~~
q3k
IPv6 is not complicated.

128 bits of address space. Everyone gets a /64's (128-64=>64 bits of address
space). Larger entities get /48's (128-48=>80 bits of address space). So
everyone (you, your device, your network) has plenty of addresses to spare.

Addresses are written in hex, in the form
0011:2233:4455:6677:8899:aabb:ccdd:eeff (that's 8 groups of 16 bits -> 128
bits). If there are zeroes in an address on, you can omit them (ie.
1122:3344:5566:0000:0000:0000:0000:1234 => 1122:3344:5566::1234).

Some protocols (ARP, kinda DHCP, ICMP) are merged into a single procotol
called NDP (neighbor discovery protocol).

When you're a home user, your router/gateway/CPE would get a /64 from your
ISP, for example 2001:1234:4567:89ab::0/64\. to use for your local devices.
For example, in your LAN, your router would probably be
2001:1234:4567:89ab::1, while your devices would probably be addressed between
2001:1234:4567:89ab::2 and 2001:1234:4567:89ab:ffff:ffff:ffff:ffff.

If your router is not using DHCPv6, but instead only NDP, it would simply
respond with a “we're using 2001:1234:4567:89ab::0/64 here, I'm your gateway”
to every device coming into the LAN, and the device would choose an address
based on it's NIC MAC and some other facts. If your router would be using
DHCPv6, the exchange would be just like in ordinary DHCP (dhcp request -> dhcp
reply with IPv6 address to use).

There is some extra (standarized) link-local magic with IPv6 - if you seen an
fe80::0/16 address on your link, then it means that there was no IPv6
router/DHCP server on there and the devices in the LAN are establishing
connection independently - but of course, without any access to the rest of
the IPv6 Internet. This is also done via NDP, IIRC.

And that's basically it. No NAT. The devices in your LAN are directly routable
to devices in your friend's LAN, or to Facebook's server

~~~
howeyc
Stupid question time.

Is there anything in all this that can make my machine behind the router get
the same address all the time? Do I manually assign it locally as with IPv4
and hope no one else in the building assigns the same IP?

Is there anything to assign IP-to-Hostname at least on the local (behind the
gateway) level. Or is this handled via some other service I need to run (maybe
some server that runs dns and allows machines to push their desired hostname
to it).

~~~
rleigh
It's done automatically by your router and your OS. By default you won't need
to do anything--you plug it in and it just works.

On the machine I'm writing this reply on, when I boot it up (with either
FreeBSD, Linux or Windows) it gets a router advertisement from the router
(which is routing both IPv4 and IPv6). It gets a standard NATed DHCP lease for
IPv4. For IPv6, it combines the /64 network prefix assigned by my ISP with the
NIC MAC address to compute a unique (and stable) address.

There are of course alternatives. I can assign it statically, I can use
privacy extensions to periodically change the address (seems to be the default
on Windows for me) or I can use DHCPv6 to use DHCP-allocated addresses (my
router doesn't support this though I have done it in the past with BIND).

------
AndrewDMcG
2002 explanation by Dan Bernstein of why IPv6 will never happen.
[http://cr.yp.to/djbdns/ipv6mess.html](http://cr.yp.to/djbdns/ipv6mess.html)

~~~
anderiv
DJB was not arguing that IPv6 would never happen. He was arguing that there
are some significant barriers that need to be overcome before meaningful
adoption will occur.

I'd argue that many, if not all of the issues with v6 back in 2002 have been
resolved, and that v6 adoption is accelerating, both on eyeball networks as
well as on public-facing internet services.

------
p1mrx
Figures 3, 4, 5, and 6 are all showing the thumbnail for Figure 6.

------
bencollier49
Have to say I'm fairly unimpressed by how bad the UK looks in these rankings.
The government ought to be incentivising take-up if they don't want the
country to be a technology backwater.

