mailing list archives
Re: IPv6 and HTTPS
From: Owen DeLong <owen () delong com>
Date: Mon, 29 Apr 2013 09:11:13 -0700
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.
RE: IPv6 and HTTPS Harry Hoffman (Apr 26)
Re: IPv6 and HTTPS Jakob Heitz (Apr 29)