[162661] in North American Network Operators' Group
Re: IPv6 and HTTPS
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Apr 29 12:16:32 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <517E837A.8040402@brightok.net>
Date: Mon, 29 Apr 2013 09:11:13 -0700
To: Jack Bates <jbates@brightok.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> 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
