Home page logo

nanog logo nanog 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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]