----- Original Message -----

From: "Chris Adams" <cmadams@hiwaay.net>

Once upon a time, Jay Ashworth <jra@baylink.com> said:

...

Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name?

Is that a statistically significant percentage of all the IPs in use?

I have no numbers, but my gut feeling is that there are a lot more eyeballs than web servers with lots of IPs.

Fair point. Though those are choked behind carriers who may well CGN them whether the eyeballs like it or not.

...

Wasn't there something going on to make HTTPS IP muxable? How's that coming?

SNI; RFC 3546

...

How fast could it be deployed?

The RFC is just shy of 10 years old, so that's like a baby compared to IPv6.

It is mostly deployed, but there's still a fair number of old clients that don't support it. WinXP+IE is probably the biggest fail, followed by Android < 3.0 and BlackBerry.

When you say "it is mostly deployed", what exactly do you mean? Is it layer 7 or 4? Does it live in libraries that can be upgraded behind users' backs? Or is it actually in the browser proper? Or are you just talking about the server-side of the equation? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "David Hubbard" <dhubbard@dino.hostasaurus.com>

The web server has to support it too, which means compiling apache with SNI support and there are of course plenty of hosts running old apache.

Well, sure, but for the hoster, it's a direct benefit, not an externality; they have motive to fix it. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

If the hosting provider can still charge for IPv4 addresses, why would they support SNI or IPv6 SSL ;) I have seen a CDN using certificates with tons of domain names in subject alternative name. Old Symbian phones don't support SAN...... On Thu, Apr 25, 2013 at 10:32 PM, Jay Ashworth <jra@baylink.com> wrote:

----- Original Message -----

...

From: "David Hubbard" <dhubbard@dino.hostasaurus.com>

...

The web server has to support it too, which means compiling apache with SNI support and there are of course plenty of hosts running old apache.

Well, sure, but for the hoster, it's a direct benefit, not an externality; they have motive to fix it.

Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

On Apr 26, 2013, at 00:19 , joel jaeggli <joelja@bogus.com> wrote:

On 4/25/13 6:24 PM, Jay Ashworth wrote:

...

Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger networks:

Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? It doesn't, or doesn't if if your clients are not stuck in the past.

...

Is that a statistically significant percentage of all the IPs in use?

Wasn't there something going on to make HTTPS IP muxable? How's that coming?

TLS SNI has existed for a rather long time. there are stuborn legacy hosts.

...

How fast could it be deployed? you can use it now.

Sure, you "can". But no one will. No one (especially someone doing SSL content) wants 99% connectivity. And there's a lot more than 1% XP out there. (Hrm, that explanation works to explain why to a couple decimal places 0% of the Internet is on v6 only today.) -- TTFN, patrick

On Apr 25, 2013, at 9:27 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:

On Apr 26, 2013, at 00:19 , joel jaeggli <joelja@bogus.com> wrote:

...

On 4/25/13 6:24 PM, Jay Ashworth wrote:

...

...

Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger networks:

Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? It doesn't, or doesn't if if your clients are not stuck in the past.

...

Is that a statistically significant percentage of all the IPs in use?

Wasn't there something going on to make HTTPS IP muxable? How's that coming?

TLS SNI has existed for a rather long time. there are stuborn legacy hosts.

...

How fast could it be deployed? you can use it now.

Sure, you "can".

But no one will. No one (especially someone doing SSL content) wants 99% connectivity. And there's a lot more than 1% XP out there. (Hrm, that explanation works to explain why to a couple decimal places 0% of the Internet is on v6 only today.)

Just to give a numbers, in case anyone is interested - we have been passively monitoring SSL traffic of ~300k users for more than a year (project description at http://notary.icsi.berkeley.edu). All in all, we see about 71% of the connections on port 443 using SNI. And the only site I am aware of that uses SNI quite extensively is google - their servers give different certificates to clients that do not support SNI and clients that support it. Bernhard

There's ways around it for most software but old jetdirect stuff, switches, routers, ip control systems. Things are going to be 6to4 for a while. In fact I won't be surprised to see little hardware boxes that do it for $30 or so (probably late with this idea but have no need to know). On Apr 27, 2013 12:57 AM, "Jima" <nanog@jima.us> wrote:

On 2013-04-26 01:29, Don Gould wrote:

...

I agree with others that there is still way to much XP and other non supporting platforms and I suspect that by the time we get those out of the system we'll be most of the way there for IPv6 access.

And heck, you don't even need to get rid of XP for IPv6 -- just enable the stack. (It's not the greatest implementation, but `ipv6 install` is still an easier sell than "replace your computer.")

Jima

In message <517B608A.9060101@jima.us>, Jima writes:

On 2013-04-26 23:08, shawn wilson wrote:

...

There's ways around it for most software but old jetdirect stuff, switches, routers, ip control systems. Things are going to be 6to4 for a while. In fact I won't be surprised to see little hardware boxes that do it for $30 or so (probably late with this idea but have no need to know).

I hope you mean NAT64; 6to4 is, at best, iffy to support. I do like the $30 hardware device idea, though -- I haven't seen anything like that yet.

I saw adds for such a device a couple of years ago.

The majority of what I think of when you say "control systems" shouldn't be directly connected to the internet anyway, even with ACLs -- or so I gleaned from the nice folks from DHS. ;-)

Jima

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Apr 26, 2013, at 9:55 PM, Jima <nanog@jima.us> wrote:

On 2013-04-26 01:29, Don Gould wrote:

...

I agree with others that there is still way to much XP and other non supporting platforms and I suspect that by the time we get those out of the system we'll be most of the way there for IPv6 access.

And heck, you don't even need to get rid of XP for IPv6 -- just enable the stack. (It's not the greatest implementation, but `ipv6 install` is still an easier sell than "replace your computer.")

Jima

This will work until you no longer have an IPv4 resolver available for DNS. After that, XP fails miserably. Owen

Doing away with IPv4 isn't a sane short-term goal for anyone

who wants global internet connectivity/reachability, period. folk who advocate disconnecting from ipv4 should lead by example or stfu. either way, it would reduce the drivel level. randy

-- for example: large Cable providers getting together and agreeing to implement a 100ms RTT latency penalty for IPv4

we do not see intentionally damaging our customers as a big sales feature. but we think all our competitors should do so. randy

I don't see turning IPv4 off as a short-term goal for anyone. OTOH, I do see the cost of maintaining residential IPv4 service escalating over about the next 5-7 years. Lee Howard sees roughly the same thing. (He has fancier math and better statistics than I used). Bottom line, it is unlikely that $residential_price will be sufficient to sustain residential IPv4 service(s) beyond about 2018. The biggest question in that equation will be what percentage of residential users are behind the unmaintainable CGN solutions and what percentage retain service similar to the current (sad) state of affairs. For the customers in the latter category, they might be able to continue until their addresses are needed for more profitable services. Owen

On Apr 28, 2013, at 6:37 PM, Jimmy Hess <mysidia@gmail.com> wrote:

On 4/28/13, Owen DeLong <owen@delong.com> wrote:

...

I don't see turning IPv4 off as a short-term goal for anyone. OTOH, I do see the cost of maintaining residential IPv4 service escalating over about the next 5-7 years.

Yes... Which I interpret to result in an outcome of less service, for more cost, for residential users, eventually, as long as IPv4 addresses remain demanded in a quantity greater than the number available.

The math says that won't work out well. Looks like it is far more economical for residential providers to simply stop providing IPv4 to any customer that chooses not to pay a premium for it (steep premium at that).

Either (a) CGN, or (b) Fewer IPv4 subscriptions at higher price per subscription, than would otherwise occured (if IPv4 addresses were not scarce).

Yep.

Is there another possible outcome for residential IPv4 experience that you see as likely?

Depends. Unless there is sufficient mass of residential subscribers willing to pay the premium for CGN (unlikely in my estimation), it'll make the most sense for residential providers to simply turn off IPv4 services and tell laggard web sites like Amazon that they are SOL in terms of getting further business from those customers.

(Either of those two scenarios is most likely to result in less connectivity, fewer network users, higher cost, and worst service per user..)

Briefly… Shortly thereafter, it will result in a mad dash by the afflicted content providers to get their act together with IPv6.

On the other hand... price tag $X for IPv6+IPv4, no option for just IPv4, and price tag $X / 2 for just IPv6.

Well, either way you look at it (I think in terms of $X for IPv6, $X*2 for dual-stack) where $X is close to what you pay today. The math works out the same, roughly.

Could provide motivation for the residential users (and their destinations) to move towards IPv6. Once a large enough quantity had moved towards IPv6 only, the price could return to $X for IPv6 only.

The destinations are the actual problem. The residential users don't care all that much as long as they can reach their destinations. The only remaining problem once the destinations are addressed are the consumer electronics that lack IPv6 support. That's a much easier problem to work around.

And the price difference could be structured in other forms (not necessarily as a subscription price difference), it could take a non-monetary form, such as increased privilege, or more bandwidth (greater throughput, higher cap) for IPv6 only users, etc.

Probably not. It's the cost of providing IPv4 services that will escalate. As such, to do what you are suggesting, they'd have to raise everyone's subscription prices at the same time as well. Owen

On Apr 29, 2013, at 7:28 AM, Jack Bates <jbates@brightok.net> wrote:

On 4/29/2013 3:19 AM, Owen DeLong wrote:

...

Depends. Unless there is sufficient mass of residential subscribers willing to pay the premium for CGN (unlikely in my estimation), it'll make the most sense for residential providers to simply turn off IPv4 services and tell laggard web sites like Amazon that they are SOL in terms of getting further business from those customers.

CGN isn't that bad, and if you set up an acceptable opt-out method, it should work fine. Some things haven't changed much. A majority of my customers have no need for services that NAT44 or NAT444 break in a noticeable way. In the same regard, I can cut their number of simultaneous connections drastically if need be(but 16k gains me 4:1). As long as their Facebook apps work, they most likely won't notice to opt out.

It's not a question of how bad it is (I think it actually is, but that's another discussion altogether). It's a matter of how much it costs to maintain it on an ongoing basis. The real world numbers, especially when you count up the technical support calls that are expected are pretty nasty from a "we want to make a profit selling this" perspective. When you say a majority of customers, I think you are mistaken. The majority of services do not break. However, the vast majority of customers use at least one thing today that does break. Play Station Network, for example, doesn't do well with CGN. Yelp, for example, won't do well with CGN in terms of its geolocation proclivities. Depending on where you live and where you get CGN'd you may get interesting results with some banking institutions, Netflix, and some other things as a result of their geolocation proclivities. Google maps may or may not break in interesting ways depending on load on the CGN server and other factors. The list goes on. A single tech support call from a customer cancels out the margin for approximately 5 months of service, so even if you only break 20% of the customers to the point of creating a tech support call each month, you lose.

If I get 25% on CGN, I gain years of IPv4 reuse. If I succeed at 50%+, I suspect I'll survive the cutover.

Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses.

Of course, I don't believe anyone should consider CGN without IPv6 support. It has the potential of keeping people from noticing the CGN as p2p apps support IPv6.

The more things support IPv6, the less painful CGN will be. This is certain.

The only thing I haven't liked is that it looks like I'll have to have the customer reboot after the opt-out for their IPv4 address reassignment (or wait it out). One CGN deployment method I'm considering is flow analysis of the customer traffic and automatically opting out customers which analysis shows will definitely not work. This analysis works best post dual stack deployment which isn't a problem for me.

Telling a customer to reboot a router (or a single host) isn't all that bad. After all, they probably did that at least 5 times at the behest of your front-line support folks before they reached someone that understood the problem anyway. (At least that's been my general experience with most residential providers).

I'm extremely happy with deterministic port block allocation(based on http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-05?). Thankfully, I won't have to keep a log of every connection. I don't mind exporting flows for analysis, but I don't want to keep 1-2 years of them.

Or 7, as required by CALEA. The problem with draft-donely is that customers that exceed the expected number of ports run into issues (or additional logging required), so you either don't get the best efficiency out of your addresses, or you get problems in other ways. Owen

On Apr 29, 2013, at 10:29 AM, Jack Bates <jbates@brightok.net> wrote:

On 4/29/2013 11:11 AM, Owen DeLong wrote:

...

Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses.

The residential currently eats up a majority of my addresses, so the more I can recover from them for business customers, the better.

Point is that your business customers probably won't be so CGN tolerant and growth there will reduce the ability to multiply residential customers on recovered addresses.

...

Telling a customer to reboot a router (or a single host) isn't all that bad. After all, they probably did that at least 5 times at the behest of your front-line support folks before they reached someone that understood the problem anyway. (At least that's been my general experience with most residential providers).

Perhaps my viewpoint is different, given that I only have two lines of support folk, and talking to me is a rarity for a customer. :)

I was speaking from the customer perspective. In addition to working for an ISP, I'm also a customer of multiple residential providers and have experience with a number of former providers as well.

...

Or 7, as required by CALEA. The problem with draft-donely is that customers that exceed the expected number of ports run into issues (or additional logging required), so you either don't get the best efficiency out of your addresses, or you get problems in other ways. Owen

That problem was mentioned on v6ops, and the general lesson that I took from it is to not exceed 16:1 ratio if it can be helped. 4k ports should be fine. 64:1 is probably sustainable for a lot of customers with 1k ports, but there will be a percentage that will have issues. Luckily, most of those with issues are usually running services that require opt-out anyways.

Hmmm… Thinking just about my active usage, 4k ports divvied up among the 15 or so IP-speaking hosts in my house works out to just under 300 ports per host. That's probably sufficient for relatively light usage. It would probably suck pretty bad on days when I'm doing a lot.

If I calculate correctly, even at 20% of my residential(70% of total allocated) on CGN, I'm regaining 18% of my residential assignments with a 16:1 ratio. I could conservatively figure a years worth of my usual allocation has been saved. If I can push better numbers, I'll get more years.

What does the CGN cost you per subscriber (equipment, additional staff, etc.?) Owen

On 04/29/2013 11:00 AM, Jack Bates wrote:

If the existing cards handle CGN without additional licensing, then the only real cost is personal, my sanity, and the company need/will not factor that in.

One thing to consider is what the new support load will be from issues dealing with CGN causing new breakage. That might be baked into your support already, but at larger scale it probably isn't. Maybe it's marginal, but it's worth asking. Mike

In message <05CD8F9B-46DD-4069-9EBE-2C92FFFF210E@delong.com>, Owen DeLong writes:

On Apr 26, 2013, at 9:55 PM, Jima <nanog@jima.us> wrote:

...

On 2013-04-26 01:29, Don Gould wrote:

...

I agree with others that there is still way to much XP and other non supporting platforms and I suspect that by the time we get those out of the system we'll be most of the way there for IPv6 access.

And heck, you don't even need to get rid of XP for IPv6 -- just enable the stack. (It's not the greatest implementation, but `ipv6 install` is still an easier sell than "replace your computer.")

Jima

This will work until you no longer have an IPv4 resolver available for DNS. After that, XP fails miserably.

No. You just need to install a caching nameserver or a simple v4/v6 relay. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org