IPv6 and HTTPS

Mon Apr 29 16:11:13 UTC 2013

On Apr 29, 2013, at 7:28 AM, Jack Bates <jbates at 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