nanog mailing list archives

Re: IPv6 and HTTPS


From: Jack Bates <jbates () brightok net>
Date: Mon, 29 Apr 2013 09:28:10 -0500

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.

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

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

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.

Jack


Current thread: