IPv6 and HTTPS

[jbates at brightok.net (Jack Bates)]

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