
A Primer on IPv4, IPv6 and Transition - p1mrx
http://www.potaroo.net/ispcol/2013-04/primer.html
======
alan_cx
This is not an internet thing. We humans are very bad at pre-empting issues
like this and doing something about it ahead of time. Especially when it needs
money spending.

Here in the UK, for example, we _know_ we have an energy crisis looming. We
know we need to build more power stations. We have known this for over 20
years. We have the technology, money and skills, but only this year has one
single new power station been signed off on.

Motor sport... knew neck injury was a common way to die or be crippled. They
had the HANS device which would save a vast majority of lives, but people
refused to use it. Not so much money, but attitude. Then a few drivers died
who could have been saved, and there was a mass push to adopt the HANS device.

Same sort of thing with Islamic terrorists. We knew of the threat, but did
little to stop it until the catastrophe of 9/11.

Look at AIDS. No one did much until the numbers got scary.

What we do is wait and wait until there is a catastrophic failure, then panic
the known solution in to place, while blaming every one in sight. Of course
then mistakes happen because its a rush job.

In short, this is perfectly normal.

I suspect that we wont get IP6 properly until the internet feels and looks
broken. When the average punter is inconvenienced on mass is when IP6 will
properly roll out. In this case, it must be very expensive to blanket upgrade,
and prices will have to rise to cover it. But, the people paying those higher
prices wont see immediate benefit, in effect they will be expected to invest
up front while IP6 is rolled out. Or, for once, will it be different?

I have a suggestion. ISPs could offer a deal where the customer can pay more,
but later on get IP6 upgrades for free, or something beneficial in return for
the investment. Let that increased cost actually be a small private investment
in one's ISP.

------
purephase
While certainly concerning, I think the OP is proving the opposite pole. The
fact that solutions are continually evolving globally to solve the IPv4
address space issue, and pretty seamlessly too, speaks volumes to how amazing
the internet and it's associated technology stack truly is.

IMO, the main issue with IPv6 is it's overall complexity compared to IPv4.
While it's end goal is laudable, I agree with another comment in that there
may have been a better halfway solution (IPv4.1) which could have eased the
transition.

I say this knowing full well that the problem is very complex and the people
working on it brilliant which makes me believe that there may have been no
other way.

~~~
XorNot
Like what?

People keep suggesting we could've somehow gone half-way, but it's an
illogical proposition.

Router ASICs are keyed for IPv4 - that is the only thing they will ever do.
Change _anything_ about IPv4, and you have to replace all the routers (heavy
duty ones, which do the heavy lifting of the internet).

There is no half-way solution to this problem that is somehow "easier" then
existing transition mechanisms.

~~~
LukeShu
IPv4 and IPv6 are both complex protocols. Changing anything does mean that you
have to replace all the routers, but if you only change the address length,
the new routers are almost the same as the old ones, nothing needs re-
engineered. Nobody needs retrained. Most software just needs a struct in a
header file modified. You do need to replace everything, but you don't need to
re-engineer everything. (Not necessarily my opinion, but my interpretation of
GP's opinion)

~~~
XorNot
If you change the address length, no old router and route packets to a new
longer address. Nor can they route packets from long addresses to short ones.
Game over.

You can't "just change the address length". They're hardware ICs. If the
address is not 32 bits long, then its a malformed packet that should be
ignored. They cannot handle it differently. They can't be reprogrammed.

There's been some consternation over Cisco stuff in this capacity, since they
use an ASIC for IPv4 and a software-mechanism for IPv6 which is not nearly as
fast.

The cost and complexity of changing hardware is _enormous_ compared to every
other part of the process. IPv6 in software has been solved, and where it
can't be solved you can shim-it trivially by comparison. Software is not
what's holding it back.

~~~
mprovost
They could have made the change backwards compatible. Basically by doing
something along the lines of designating a part of IPv4 space for use with the
new protocol, and then stuffing the extra address into the optional header
field. Then if you're running an older device that doesn't understand the new
header it will just forward it along until it gets to a device that can.

~~~
XorNot
Which puts you in the same problem: to any device (i.e. one with a hard-wired
ASIC - the largest and fastest hardware generally) the new address space does
not exist.

The internet goes to some lengths to avoid routing loops as well, so once a
packet is passed one router we're not going to be able to easily spin it
around and send it back to get to the right place. The net effect is going to
be to randomly DDoS a bunch of devices which happen to be behind non IPv4.5
hardware, and so receive 50% of the internets traffic which doesn't get routed
properly by an upstream router.

------
Tmmrn
> We are hopelessly addicted to using a network protocol that has now run out
> of addresses.

We... "We"...

Let's see what the situation with germany's Telekom is like:

2010: <http://heise.de/-1102458> \- At the end of 2011 all DSL connections
will be switched to ipv4/ipv6 dual stack

Mid 2012: <http://heise.de/-1605061> \- At the end of 2012 they will provide
ipv4/ipv6 dual stack

End of 2012: <http://heise.de/-1763557> \- Only customers with VOIP or ISDN
are getting ipv6.

It's not "me" who loves it, it's the ISPs.

~~~
skore
> Only customers with VOIP or ISDN are getting ipv6.

I think you got that the wrong way around. Old analog and ISDN connections are
specifically mentioned to never get v6 (which makes sense, I guess). Only new
contracts with a fixed IP _will_ definitely get it.

~~~
Tmmrn
Oh right, I read that wrong.

But... Why does it make sense?

~~~
sliverstorm
IPv4 works just fine, the problem is growing it. If you already have service,
you've already got an address. No problems.

Alternatively, ISDN/dialup gateways just don't support IPv6 because they were
all designed in 1995.

~~~
lucb1e
> _IPv4 works just fine_

Here you are supporting the network problem. If no ISPs support IPv6, it makes
no sense for websites to support it. If no websites support it, it makes no
sense for ISPs to support it.

You're right that everyone with an address needs no new address to be globally
reachable, but in order to actually fix the issue we need _everyone_ to
switch. The protocol versions just don't inter-operate.

------
zaroth
And yet on many guides to hardening Linux, one of the checklist items is to
turn off IPv6! If IETF wanted to fix the address space problem, it could have
been done a lot simpler than IPv6 -- perhaps what the market actually wants is
IPv4.1

From the total internet IP scans I've seen recently, there is also a
significant percentage of allocated IPv4 space which is dark. Out of addresses
we are not.

For example:
[http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731....](http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf)

<http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf>

~~~
sliverstorm
I am not an authority on hardening linux, but I would bet that disabling IPv6
is recommended simply because in most applications it is unnecessary extra
complexity. All your careful IPv4 firewalls are meaningless if you forget to
also configure ip6tables.

~~~
Nick_C
> if you forget to also configure ip6tables

Yeah, I've never understood that. I get that ping and traceroute have their
own IPv6 versions, but that's sort of understandable (maybe).

A firewall, though, is a firewall, it shouldn't matter what one of the IP
protocols is. TCP and UDP don't have separate tools. The maintainers should
clean it all up and put it into one iptables tool. If you want only IPv4, use
a -4 flag, and ditto for IPv6 with a -6 flag. Heck, for most rules you can
just imply it by the nature of the src and dst addresses.

~~~
noselasd
It's because most firewall rules we deploy are for a combination of layer 3
and layer 4 addresses, not just layer 4(port numbers).

And since layer 3 addresses are different between IP versions, we need
different rules. (There may also be additional concerns if you enable V4
mapped addresses for IPv6)

------
apenwarr
People are again panicky about this, just like they are as IPv4 has gone
through every major transition. But the solution is already known: it's called
carrier-grade NAT. ISPs will be NATting at their side, so multiple customers
will appear to have the same IP address.

As with the original adoption of NAT, it will be slightly bumpy at first.
There'll surely need to evolve some sort of port forwarding protocol
(hopefully something more like NAT-PMP and _not_ like uPnP) that will allow
incoming connections through what will now be double NATs (one at the ISP and
one in your home), since we can assume people won't remove their original NAT
just because a new one has been added. People like their personal NAT, it
makes them feel safe. And I think those people are right to feel that way.

And then if you want to run a public web server, for now you'll have to pay
extra for a static IP, just like you have had to do for years now. That's not
a big deal, there are way less than 4 billion public web servers right now.
The market won't run out right away. As we get even tighter on addresses, the
price of a static IP will rise.

And when _that_ becomes a problem (prices too high), someone will find a way
to use something like DNS SRV records to have multiple web servers on a single
IP address, using different port numbers, and DNS will tell your web browser
which port to use. This will require browsers to support whatever new
standard, but I figure we have 10+ years before this level of workaround is
absolutely critical.

Remember, if you allow for identifying servers by ip:port instead of just IP,
you have roughly 65536 times as many "addresses" available. That's enough to
last pretty much forever.

We don't need IPv6. We will need new routers to do the carrier grade NATting
(and it's a very hard problem to NAT at that speed/scale, but hey, that's what
money is for. And ISPs can deploy it incrementally, as they run out of
addresses).

~~~
vy8vWJlco
If carrier-grade NAT is the solution, then the future is non-routable. If you
are behind NAT and I am not, you can make an outgoing connection to me and we
can still talk. If we are both behind NAT, we need a 3rd party's help. That is
not an Internet IMHO.

~~~
apenwarr
All you need is a proper dynamic port opening scheme like NAT-PMP. You may
also want to use a third-party STUN server to exchange routing info, but
that's no more complex (actually easier) than DNS.

It's still the internet even though you need DNS to turn names into IP
addresses, right? It's just a little more complicated. That's what the new
world will be: the Internet, but a little more complicated. Which is exactly
what happened when DNS, then CIDR, then NAT were introduced.

~~~
vy8vWJlco
As important as DNS is for the Web, the Internet doesn't currently (and
shouldn't) need DNS (or a DNS-like coordinator) any more than cupcakes need
candles. If I know your telephone number, I shouldn't have to dial the
operator and ask for their help (and implicit permission), I should be able to
help myself and dial direct. We are re-imposing an unnecessary middle layer
that has all sorts of social equality/neutrality implications. (People with
global addresses have more power than those who don't.)

That's the point of direct addressing: removing ambiguity and allowing direct
connections.

Edit: The cost of patching IPv4 is just another reason to move deliberately to
IPv6 (or something that allows direct addressing again, but for the sake of
argument, IPv6 is the leading candidate).

Edit: Deleted confused nonsense about NAT-PMP.

~~~
apenwarr
I think you may be misunderstanding NAT-PMP. Done correctly, that protocol can
open a port through multiple layers of NAT without having to know how many
layers there are. And then you'll have a well-defined public ip:port that
other people can connect to you on. (You could, for example, advertise that
ip:port in dynamic DNS or a bittorrent peer discovery protocol, just like you
do today for dynamically-assigned IP addresses.)

There's no doubt that direct addressing is simpler and more appealing. Yes.
But it requires worldwide 100% deployment of a replacement to IPv4, which is
not simple at all.

~~~
vy8vWJlco
Yes, I had the wrong idea about NAT-PMP.

The cost of patching IPv4 and working around the quirks seems similar and less
desirable to the cost of simply running IPv6 in parallel. I wouldn't describe
it as all-or-nothing, but I would say ISPs need to help by providing low-
latency tunnels/advertised routes. (Hurricane Electric can't handle
everything, going forward.)

"All-or-nothing" itself creates an obstacle.

~~~
aidenn0
The problem isn't that it's expensive for ISPs to deploy ipv6; the problem is
that an ipv6 address is strictly worse than an ipv4 address[1]. Therefore
deploying ipv6 would be spending money to give customers something they don't
want. Nobody is going to do that! 98%+ of customers will be happier with ipv4
behind CG NAT than an ipv6 address, as they don't see the internet as a
network of peers, but rather see it as "I'm a client, I want to connect to
servers"

[1] By "strictly worse" I mean there isn't, currently, any server that anybody
cares about that you can connect to solely with ipv6; there are, however,
numerous sites that are only connectable to with ipv4.

~~~
vy8vWJlco
It's not really a case against IPv6 that existing websites don't need it since
that's a privileged position that makes IPv4 seem fine. IPv4 exhaustion is
only a problem for individuals at the edge who want incoming calls (to act as
servers). Fortunately, today, new edge-homed servers can already use IPv6
through a tunnel, with the immediate advantage that they have a "real"
globally-routable address that they can be reached at. In that sense, IPv6 has
already arrived. It would just be nice if I didn't have to set up that extra
tunnel to connect to something that only I and my clients connect to.

The people at the edge who don't care are, sadly, the one's who would most
benefit. I agree that that is a problem. These social problems (the consumer
apathy and the willingness of ISPs to exploit that to make a peer network a
broadcast tree) are admittedly overwhelming but, as you also note, the costs
to ISPs are minor: IPv6 can be provided to the edge, even if it's ultimately
tunneled over IPv4-only hardware.

This is more a matter of technology-leaders, IMHO, pushing/expecting ISPs to
do the right thing for once (if we can spare a few minutes from selling
censorship to dictators). History has shown they aren't going to do it without
public pressure. Their preferred distribution medium (cable TV) already
existed: it was people who understood that it was a peer network that drove
the adoption of the Internet. If IPv6 spends the first 10 years or more being
used exclusively by that group of people, fine, but it's still worth
promoting. ISPs only started taking it seriously in the last few years, so
there's a long way to go, but I think it's a reasonable goal to get an
upstream IPv6 router advertisement, eliminating the need for tunnels, to every
IPv4-connected home in the next 5 years (it is really just a matter of
installing Linux, or your preferred OS, on a spare box until the load dictates
an upgrade; there is no chicken-or-egg problem).

------
sown
Quick tip: Link local addresses in IPV6 are mandatory and all start with
"fe80:". If you've enabled IPv6 on your machine but don't use IPv6 on your
network, this is probably what you will see from ifconfig.

If you try to ssh user@fe80:0123::1, for example, you'll get an invalid
argument error from connect(). In this case, you'd do an ssh
user@fe80:0123::1%eth0, assuming that address is the link local address of
eth0 on that host. Alternatively, don't use the link local address.

------
notacoward
The tone is unnecessarily alarmist. IPv4 address exhaustion might limit
internet _growth_ , but it will not cause the internet _as it already exists_
to break suddenly. Adjustments have been made and will continue to be made,
such as corporate use of non-routable subnets for internal machines and a
market for unused addresses. While address exhaustion is a serious issue that
still must be dealt with in the next few years, the sky is not falling.

~~~
raldi
Or rather, the sky is falling, but it's still high enough up, and descending
slowly enough, that we have plenty of time for a gradual and orderly
transition to .. uh, I guess this is where the metaphor breaks down.

~~~
andrewflnr
Underground bunkers?

------
p1mrx
And as a follow-up to the article, note that IPv4 depletion is not an abstract
scenario. If you host a website, or manage a network, or write software that
ever touches an IP address, it is quite literally your responsibility to pull
out a keyboard and help fix this problem. If you're blocked on a system that
isn't ready for IPv6, then you should find out why, or seek alternatives. The
Internet is far too useful for us to stand around and watch it rot.

~~~
Scaevolus
Microsoft has a tool called Checkv4 that scans code for things that have to be
changed for IPv6 compatibility. Is there any equivalent for Linux?

~~~
p1mrx
I'm not aware of any automatic code scanners for Linux; usually the easiest
thing to do is try it and see what breaks. You can use a HE.net or SixXS
tunnel to get connectivity if your ISP isn't ready.

Beej's Guide shows how to use the C socket APIs in a dual-stack manner:
[http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html...](http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#ip4to6)

For testing your own network and browser, <http://test-ipv6.com/> is quite
good.

------
trotsky
IPv6 demonstrates a real flaw in the IETF. It has little ability to throw away
a standard that suffers from flaws that aren't of a technical nature and start
over. It's been clear for a long time that IPv6 was suffering from huge
adoption barriers. There have been countless IETF transition standards
proposed, adopted and deployed meant as stopgaps for ip6 like CGNAT while 6
continues to languish. Carriers, an obvious critical stakeholder in protocol
adoption, didn't have an opportunity to participate in the standards process
at the time. Yet we continue cry that the problem is the people that won't
adopt it, not the protocol that people won't adopt. DNSSEC has suffered from a
similar but less dramatic market failure.

~~~
skymt
Why should we expect carriers to adopt IPv6+1 any quicker than IPv6? Are there
specific elements of IPv6 that are so carrier-unfriendly that correcting them
would be worth throwing away all the progress that's been made?

~~~
trotsky
Because we'd be talking about something closer to ipv4+1, something that
allowed core equipment to not have to process packets in a different way and
maintain completely separate routing tables for granularity of traffic that
only matters at the edge.

~~~
josteink
_Because we'd be talking about something closer to ipv4+1, something that
allowed core equipment to not have to process packets in a different way_

If that would be true, then it wouldn't be able to provide any better end-to-
end connectivity than IPv4 and thus would be a completely wasted effort.

------
walshemj
The problem was is that the IPV6 designers where all ivory tower types and
forgot that the first priority should be migration and interoperability.

~~~
vy8vWJlco
Migration and interoperability, IMHO, are very minor problems. Software needs
very minor changes to support IPv6 addresses (the socket interfaces are not
affected, only the address input string, which is handled by an OS
library...). The problem is 1/3 hardware/software (a lot of firewalls and
NATs) and 2/3 political: most ISPs began as telephone or cable providers with
a vested interest in creating or maintaining media distribution monopolies.
NAT is the best thing since sliced bread to them since it largely breaks end-
to-end routing/global addressability. (VoIP, P2P, etc, are all much harder
through NAT)

~~~
sliverstorm
Can you not use NAT with IPv6?

~~~
nwh
Every device can have it's own address, so you don't really need it as much.

~~~
sliverstorm
Sure, but if the ISPs number-one goal is putting a stranglehold on your
personal freedoms, is there anything actually stopping them from using NAT on
IPv6 if they wanted to?

If they are truly draconian cabals of evil, I don't expect "well, you don't
need it _as much_ " would stop them.

~~~
wmf
What's stopping them is their own greed; NAT costs more than not having it.

------
jacob019
IMHO, the only thing blocking ipv6 adoption is the ISP's, like Comcast. Many
of the datacenters support it, the devices support it, we're ready to go just
waiting on the pipes. T-Mobile is already using ipv6 for mobile, so our old
ISP's are dropping the ball as usual. Carrier grade NAT will be rolled out
alongside ipv6, and ipv6 adoption will accellerate exponentially as everyone
will want to avoid the performance issues that NAT has, all the devices
already prefer ipv6. Markets are demand driven, as soon as the clients support
it, the servers will fall in line surprisingly fast. I'm not worried, ipv6 is
happening, we just need to give the ISP's a kick.

~~~
ianburrell
Comcast is a bad example since they are furthest along deploying IPv6 of any
of the major US ISPs. They have coverage for 50% of customers.

But only 1% of traffic is IPv6 mostly because customer equipment doesn't
support it. Cable modems need to be upgraded to DOCSIS 3.0. Most consumer
routers also don't support IPv6 including many models currently for sale. The
manufacturers don't seem to have plans to release upgrades for IPv6 support.
The third part firmwares like DD-WRT and OpenWRT have some support but it
still isn't great. Most customers wouldn't be willing or able to install new
firmware.

~~~
jacob019
Thanks for the interesting facts, I didn't know that about Comcast. I still
think that widespread ISP support will lead to rapid adoption, with 50% of
traffic being switched over in a decade once that occurs. How old is your
cable modem and router?

~~~
ianburrell
My cable modem and router are brand new since I deliberately bought IPv6
capable ones so I can use IPv6 when it becomes available.

Mobile seems to be the area with the most IPv6 adoption. Verizon Wireless has
25% of traffic on IPv6. Verizon required IPv6 for its LTE network, and many of
the popular mobile sites like Google and Facebook support IPv6.

~~~
jacob019
Mobile definitely seems to be leading the way. I know the pace of obsolescence
may be slowing a bit, but I still suspect that most consumer cable modems and
routers will be replaced within a decade, similar to the pace of 802.11n
adoption. It is troubling that ipv4 only ones are still being sold. So many
negative comments here, but I still believe ipv6 will be rapidly adopted in
the coming years and that all this concern about carrier NAT and the depleted
ipv4 address space will become irrelevant in short order.

------
tptacek
Three broad points.

First, the supply side: if you read this article through, you saw the demand
curve inflections at the classful-classless change and at the NAT change.
Downthread someone already mentioned carrier-NAT, which is one more potential
inflection. But there are others; the biggest could be a liquid market for
routable blocks. There are large companies pointlessly squatting on huge
allocations; some of them assign _routable_ IP addresses for every desktop in
their network, despite (sanely) firewalling them off entirely from the
Internet. A market for IP addresses would make that waste expensive and return
potentially large numbers of addresses back to general use.

Second, the demand side: It will no doubt enrage HN nerds to hear this, but
most Internet users do not need a first-class address. In fact, it's possible
that most Internet users are poorly-served by first-class addresses! They
never take advantage of them, but holding them exposes them to attacks.
Because mass-market application developers in 201x have to assume large
portions of their users don't have direct Internet connectivity, technology
seems to be trending away from things that require it, and towards tunneling,
HTTP-driven solutions, and third-party rendezvous.

Finally: Who says IPv6 needs to be the future? Bernstein's summary[1] of the
problems with transitioning is getting old, but the points in it seem valid.
If we're going to forklift a whole new collection of libraries and programs
onto everyone's computer, why don't we just deprecate the whole IP layer and
build something better. I don't think I see the reason why IP can't just be to
2020 what Ethernet was to 1990: a common connectivity layer we use to build
better, more interesting network layers on top of.

The core functionality of the IP protocol has served beautifully over the last
20 years, but the frills and features have not. IP multicast is a failure.
IPSEC is a failure. QOS is still a tool limited to network engineers. We
barely have anycast.

These are all features that would be valuable if they work, but that don't
work because the end to end argument militates against them --- their service
models evolve too fast for the infrastructure to keep up, and they're pulled
in different directions by different users anyways.

We can get new features _and_ unbounded direct connectivity with overlay
networks. We have only the most basic level of experience with overlays ---
BitTorrent, Skype --- but the experience we've had seems to indicate that if
you have a problem users care about, overlays tend to solve them nicely. We
should start generalizing our experience with successful P2P systems like
Skype and pull in some of the academic work (like the MIT PDOS RON project)
and come up with a general-purpose connectivity layer that treats IPv4 like
IPv4 treats Ethernet.

Special bonus to that strategy: Verizon and AT&T don't really get a say in how
those overlays work, and nobody needs to wait for a standards committee to
agree on whether things are going to be big endian or use ASN.1 or XML.

[1] <http://cr.yp.to/djbdns/ipv6mess.html>

~~~
belorn
Each of those three points has strong counter arguments.

> A market for IP addresses would make that waste expensive and return
> potentially large numbers of addresses back to general use.

The concept of legal ownership of IP addresses as property is explicitly
denied by ARIN and RIPE[1], and for good reason. If they were property, the
addresses would be held and hoarded as investments (which can be seen in the
subset which is already owned in this manner). They would also fragment, which
leads to worse performance and higher costs. Given those two reasons, the
first point fails under the label of really bad idea.

> it's possible that most Internet users are poorly-served by first-class
> addresses!

Internet users, or let's call them end users, want to use software that works,
is effective and thirdly cheap. Software that has those 3 attributes serves
them. However, with NAT, those attributes are directly harmed. Some software
will never work with NAT. Of those that will work, some are much less
effective, such as harmed latency and privacy. And thirdly, NAT adds costs to
software development in from of complexity, meaning that the end cost for
users increase. Thus, because of NAT, software is less useful and more costly,
which in turn _harms_ Internet users.

> Who says IPv6 needs to be the future?

IPv6 was the smallest possible change to fix the problem, while still
maintaining a form of performance requirement that overlay networks don't.
Performance here being 1) latency, 2) router capacity, 3) privacy/security. If
a new protocol would fulfill the performance requirements, then there would be
a reason to discuss replacing IPv6 with something better, but until that time
is here, IPv6 is the upgrade that is necessary for the Internet, end-users,
and suppliers.

[1] <https://www.arin.net/policy/nrpm.html>

~~~
mprovost
> IPv6 was the smallest possible change to fix the problem

Really? Going from a 32 bit addressing scheme to 33 bits would double the
amount of addresses, pushing the problem a way down the track. Sticking to
octets for simplicity, going to 40 bit addressing (five octets) would provide
as many addresses as we need for the near future. But they went for 128 bit
addressing with IPv6 - I fail to see how that was the smallest change that
they could have made.

Making it backwards compatible with v4 would have been an even smaller change
and we'd probably be using it by now if they hadn't broken compatibility.

And how was picking an address size that didn't match up to the native integer
size of any common CPU good for performance? Maybe they expected us all to be
running 128 bit CPUs by now.

~~~
josteink
If you're going to break compatibility by changing the fundamental address-
size anyway, what does it matter if you future proof it by a factor of 256 or
something ginormeous so that we wont have to go down this road again ten years
from now?

~~~
tptacek
Because the difference between a 64 bit integer (which would also have been
future-proofed for the current IP service model) and a 128 bit integer is not
simply 8 more bytes, but also the fact that all modern non-MCU computers can
treat a 64 bit integer as a scalar, but are effectively forced to handle a 128
bit integer as a string or a structure of some sort.

This can be the difference between a 1-line patch to a C program and a 30 line
patch.

Of course, the standards committees don't care about that cost (it is an
externality to them), because "rough consensus and working code" stopped being
the code of the IETF more than a decade ago.

~~~
yuhong
AFAIK IPv6 originally became a RFC back in 1995.

------
icedchai
The short term solution is carrier grade NAT. This will extend the life time
of IPv4 for another 5 to 10 years.

(I've been running IPv6 on my home network since 2008 using a tunnel provider.
My ISP does not support native IPv6 yet.)

------
kristopher
The problem is not in the routers or operating systems, it's in the
applications.

Programmers do not yet know enough about IPv6, nor do they have the drive to
learn about it.

~~~
p1mrx
The problem is essentially everywhere. Router/OS programmers are programmers
too, and some are more on the ball than others.

In the consumer router space, the level and quality of IPv6 support is far
from perfect. Even the third-party firmware is spotty. IPv6 works fairly well
on OpenWRT trunk, thanks to 6relayd and odhcp6c, but the best you'll get from
DD-WRT is a kernel module and a pile of scripts in the wiki.

------
bestest
Yeah, one thing that is definitely broken is justified text alignment on the
web.

------
jokoon
Sorry but I don't understand why and who can't make it happen if the hardware
is there.

Maybe because the software ISP use is not ready yet ?

------
dewiz
with proliferation of NATting what will happen to consumers geolocation? how
will NAT statefulness affect reliability? NAT over NATs ? are push
notifications on mobiles linked/affected? what about P2P networks?

~~~
vy8vWJlco
Latencies will go through the roof, and P2P will be harder because of the
difficulty in establishing connections without the help of willing 3rd parties
with routable addresses (to act as proxies, or provide STUN-like
functionality, etc). (Geolocation will probably stay about the same, but could
go down depending on the depth of the NAT'ing... For example, if you are
behind 2, you will only be seen as the outermost address...)

If it weren't for the latencies and the liability, I would consider a P2P IPv6
overlay an acceptable transition plan.

------
andyl
OK - I'm willing to transfer one of my servers from IPv4 to IPv6. How do I
tell if my hardware/software/isp/etc. is compatible? Where should I get
started?

~~~
zdw
Bug your ISP first. See if you can get assigned IPv6 addresses. Alternatively
you can use tunnelbroker.

If the 3 VPS providers I use, two had them available. None of my local ISP's
assign IPv6 addresses, even though nearly all hardware built in the last 5
years supports it.

