It's just that I'm in Thailand right now and I am bitter about how lousy the Internet works here, and I have a hard time seeing any development of high quality end user IPv6 connectivity here anytime soon. That's why my "halfway there" is coming from. I hope I'm wrong, and it might help if residential equipment gets IPv6 capability because a lot of the Internet equipment here seems to be of that calibre (probably because of price point).
Depends on which side of the loadbalancer you're talking about and how it is configured.
Owen
Franck Martin wrote:
Sure the internet will not die...
But by the time we run out of IPv4 to allocate, the IPv6 network will
not have completed to dual stack the current IPv4 network. So what will
happen?
Reality is that as soon as SSL web servers and SSL-capable web browsers
have support for name-based virtual hosts, the number of IPv4 addresses
required will drop. Right now, you need 1 IP address for 1 SSL site;
SNI spec of SSL gets rid of that.my load balancer needs 16 ips for every million simultaneous
connections, so does yours.I'm pretty sure that's not the case for inbound connections...
Depends on which side of the loadbalancer you're talking about and how it is
configured.
Owen
Sounds like he is talking about a source NAT pool. If the box will support
a million simultaneous PATS, it takes 16 addresses to make a PAT pool of
that size. But if you are routing in the data center they can be private, as
only the real servers will see them. If you had a need to do 1 arm across
the Internet a single NAT pool would provide service for a large number of
VIPS. These are featuress of an ACE.
* Patrick W. Gilmore:
Reality is that as soon as SSL web servers and SSL-capable web
browsers have support for name-based virtual hosts, the number of
IPv4 addresses required will drop. Right now, you need 1 IP
address for 1 SSL site; SNI spec of SSL gets rid of that.Agreed.
When do you expect Windows XP & earlier versions to be a small enough
segment of the userbase that businesses will consider DoS'ing those
customers? My guess is when the cost of additional v4 addresses is
higher than the profit generated by those customers.Put another way: Not until it is too late.
I'm not so sure. Name-based virtual hosting for plain HTTP was
introduced when Windows NT 4.0 was still in wide use. It originally
came with Internet Explorer 2.0, which did not send the Host: header
in HTTP requests.
NT4 was never heavily adopted by users. Also, not nearly as many billions were being sold on e-commerce sites.
Anyway, I think the TLS thing is a bit of a red herring. It might be
a popular justification for IP space at the formal level, but
real-world requirements are a bit more nuanced. FTP and SSH/SFTP do
not support name-based virtual hosting, so if you're a web hoster and
structured things around "one IPv4 address per customer", then there
might be another obstacle to collapsing everything on a single IPv4
address. It's also difficult to attribute DoS attackers at sub-HTTP
layers to a customer if everything is on a single IPv4 address, making
mitigation a bit harder.
Since the vast majority of non-SSL HTTP is served off shared IP addresses, I would have to disagree. Also, it is trivial to dump FTP/SSH sessions into the correct directory on a shared backend system. So SSL does seem to me to be the big problem with the hosting side of the house.
But end of day, we do agree. I do not see the growth in certs being the limiting factor here. There are far more users than websites, so even if we could wave a magic wand and get back all HTTP/SSL IP addresses, we would still have a large problem.
* Patrick W. Gilmore:
I'm not so sure. Name-based virtual hosting for plain HTTP was
introduced when Windows NT 4.0 was still in wide use. It originally
came with Internet Explorer 2.0, which did not send the Host: header
in HTTP requests.NT4 was never heavily adopted by users.
It was fairly popular on corporate desktops, until 2005 or so. You
really don't want to know details.
Also, not nearly as many billions were being sold on e-commerce
sites.
We're talking pretty much recent history here, closer to 2005 than to
2000. Here are some statistics from a popular IT web site in Germany,
from mid-2006:
<http://www.heise.de/newsticker/meldung/Mozilla-Firefox-gewinnt-wieder-Marktanteile-140479.html>
They report a 2.5% market share. Of course, these clients weren't
running Internet Explorer 2.0 anymore, and this offers a clue what
will happen if SNI is a desirable feature in browsers. 
I had an interesting discussion with someone from Registration Services at ARIN today.
The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued
space) do not come from the server side... They come from the eye-ball ISPs. The only
/8 issued by ARIN to an ISP, for example, was issued to a cable ISP.
With this in mind, I don't think there's much to be gained here. Optimizing the utilization
of less than 25% of the address space in the face of the consumption rate on the 75%
side simply cannot yield a meaningful result. It really is akin to rearranging the deck
chairs on the Titanic.
Owen
Owen DeLong wrote:
I had an interesting discussion with someone from Registration Services at ARIN today.
The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued
space) do not come from the server side... They come from the eye-ball ISPs. The only
/8 issued by ARIN to an ISP, for example, was issued to a cable ISP.With this in mind, I don't think there's much to be gained here. Optimizing the utilization
of less than 25% of the address space in the face of the consumption rate on the 75%
side simply cannot yield a meaningful result. It really is akin to rearranging the deck
chairs on the Titanic.
The eyeball ISPs will find it trivial to NAT should they ever need to do
so however, something servers cannot do - you are looking at numbers,
not operational considerations.
--Patrick
You and I have vastly different definitions of "trivial".
I'm looking at both, and, frankly, LSN (large scale NAT) is not as trivial as you
think. I actually talk to and work with some of these very large providers on
a regular basis. None of them is looking forward to deploying LSN with anything
but dread. The support issues, user experience, CALEA problems, and other
issues with LSN are huge. None of them that I am aware of are considering
using lSN to free up addresses to hand over to hosting providers.
Owen
Personally, I'm just waiting to see which eyeball ISP is the first to react
to looming IPv4 exhaustion by (NAT | IPv6 && 6to4)ing their client ranges
and using the freed up /9 to offer colo/hosting services at very competitive
(compared to desperately scrambling to find a /29 at your IPv4-exhausted
ISP) pricing.
In a message written on Sun, Apr 18, 2010 at 10:22:25PM -0700, joel jaeggli wrote:
Just because the curve doesn't look steep enough now doesn't mean it
won't in two years. Human behavior is hard to model and panic hasn't set
in yet.
There is also an aspect of this transition I don't think we've seen
before (in networking). A large percentage of end users are on
technologies (cable modem, dsl, even dial up) who's configuration
is entirely driven out of a provisioning database.
Once the backbone is rolled out, the nameservers, dhcp, and
configuration servers dual-stacked many ISP's could enable IPv6 for
all of their customers overnight with only a few keystrokes. Now
they won't literally do it that way to save their support folks,
but if the need arises they will be able to push the button quite
quickly.
I suspect the middle part of this S curve is going to be much, much
steeper than anyone is predicting right now.
Patrick,
Having made this bold claim, have you ever actually tried to run a natted
eyeball network? The last two natted eyeball networks I worked with could
never figure out which aspect of NAT hurt more: the technical side or the
business side.
Nick
Nick Hilliard wrote:
The eyeball ISPs will find it trivial to NAT should they ever need to do
so [...]Patrick,
Having made this bold claim, have you ever actually tried to run a natted
eyeball network? The last two natted eyeball networks I worked with could
never figure out which aspect of NAT hurt more: the technical side or the
business side.Nick
I apologize for a lack of clarity, in that what I meant was:
"NAT for eyeball ISPs is technically possible and feasible if needed
(since IP addresses are centrally managed by one company); NAT for
servers (in the sense of dedicated/colocated systems run by different
people/companies) is almost technically impossible and not feasible due
to customer training needed and the coordination that would be required."
I meant "trivial" FSVO "possible" - sorry.
--Patrick
* Nick Hilliard:
I haven't been a customer of an ISP in New Zealand for a long time now, but people there tell me that there is an expectation of NAT when you sign up for DSL service. Nobody normally expects to be handed a globally-unique v4 address.
Joe
Well said.
I've been pondering LSN lately. I think people have haven't been involved in large scale service changes or migrations can't appreciate just how many unanticipated edge cases can appear and blindside a project.
I expect that deploying IPv6 will be far less problematic than deploying LSN for a large ISP.
Rob
There is also an aspect of this transition I don't think we've seen
before (in networking). A large percentage of end users are on
technologies (cable modem, dsl, even dial up) who's configuration
is entirely driven out of a provisioning database.Once the backbone is rolled out, the nameservers, dhcp, and
configuration servers dual-stacked many ISP's could enable IPv6 for
all of their customers overnight with only a few keystrokes.
*If* the whole IPv6 config can be driven from the same database. For
the time being, DHCPv6 cannot deliver a default gateway to customers
(and there is a religious faction within the IPv6 community which
seem to want to prevent this at all costs).
As long as we have the dependency on RA for default gateways, what
you suggest is considerably more difficult.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
to my knowledge, if we're talking about the same organisation, this large
ISP is moving away from NAT, or already has done so.
Sure, you can NAT eyeballs, but it hurts like hell.
Nick
Don't forget the home gateway aspect -- it's a huge gaping hole in the IPv6
deployment strategy for ISPs. And don't talk to me about Apple's Airport
Extreme. ISPs want (once the volume of IETF IPv6-related drafts has settled
down) for every router at Wal-mart to include IPv6 support. If they start
right now and presume that home gateways/routers are replaced every 3 to 5
years, it will be several years before they've covered even 50% of the
homes.
Frank
Alternatively, they could commission the vendors to release firmware
upgrades with IPv6 support for the most common older devices. Given
that many of them are Linux based and the code already exists, this
isn't likely to be technically difficult. The customer support
costs, however, of convincing people to actually install the new
firmware is another story. A consortium of ISPs could collectively
work with the biggest OEMs/vendors to get this done if they wanted to
do so.
Start by commissioning IPv6 support into all new hardware. I would
think that given the razor thin margins in home gateways/routers extra
money coming in for simply turning on code which already exists would
be attractive to at least some of them. Come up with some kind of
logo for the program "IPv6 READY!". Make it a bandwagon thing so
that vendors who aren't part of the program look behind the times.
Offer some kind of cheap to implement network service to customers
which can only be accessed via IPv6 to create user demand. Many
people have said that the reason that no one is doing IPv6 is that
there is nothing in it for the end users, so change that.
Bill Bogstad