[159690] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jan 18 01:42:55 2013

In-Reply-To: <50F8D686.3070200@ttec.com>
From: Owen DeLong <owen@delong.com>
Date: Thu, 17 Jan 2013 20:42:03 -1000
To: Joe Maimon <jmaimon@ttec.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org



Sent from my iPad

On Jan 17, 2013, at 6:58 PM, Joe Maimon <jmaimon@ttec.com> wrote:

>=20
>=20
> Owen DeLong wrote:
>=20
>> And this is where you run off the rails=E2=80=A6 You are assuming that NA=
T today
>> and CGN provide similar functionality from an end-user perspective.
>=20
> To the extent that CGN functions like the clueless linksys daisy-chain, th=
en yes it does.

Right, but it that extent is very limited.

>>=20
>> The reality is that they do not. CGN is a substantially more degraded
>> form of internet access than current traditional per-site NAT.
>>=20
>> 1.    The end-site does not control the NAT box.
>=20
> The vast majority of end site today either do not control the NAT box or d=
o not know how to control the NAT box.
>=20

Bzzt... They may not actively control it through an administrative interface=
, but, there is not some other administrator actively disabling functionalit=
y they care about.

>> 2.    UPnP and NAT-PMP do NOT work through CGN.
>=20
> And without this wondrous technology, nothing works behind a NAT! Whatever=
 did we do before the invention and mass adoption of UPnP and NAT-PMP!

Many things that users depend on and like do not work without it. Those thin=
gs did not work/did not exist much before UPnP/NAT-PMP. That is the reason U=
PnP and NAT-PMP were developed and gained such wide acceptance so quickly. P=
rior to that, some popular applications also received customized ALGs implem=
ented in most NAT boxes.

>> 3.    There is no other provision in most CGNs to allow for inbound
>>    connection trickery that allows many of today's applications to
>>    function in spite of NAT.
>=20
> Clearly we have run out of trickery as multiple layers of NAT stumps even t=
he finest of our tricksters.

Yes, we can dedicate thousands more developer hours to making yet more exten=
sions to code to work around yet more NAT and maybe make it sort of kind of w=
ork almost as poorly as it does now. Or we could pour a fraction of those de=
veloper hours into implementing IPv6 in those same applications and have the=
 problem solved in perpetuity.

> We will have to wait and see on this one. There is a complex interaction b=
etween protocol development, application deployment, cpe technology and user=
 behavior all influenced by the NAT reality we are all witness to.

Yep. The trick is figuring out how to educate developers so that we can get O=
FF the damn NAT merry-go-round. NAT at this point has become the internet eq=
uivalent of charging $2 more than you pay on your credit card each month and=
 wondering why the bill never shrinks.

> Will this interaction adopt and adapt CGN? Clearly your opinion is not, bu=
t its only an opinion.

Actually, I'm more afraid that it will for some time to come. Results of con=
tinuing to do so:

1. Applications cost more.
2. Applications become progressively even more fragile and more poorly imple=
mented that the current state of affairs.
3. Security goes even more out the window than it already has because there w=
ill be even less ability to identify the source of malicious conduct than th=
ere is today.
4. Routers cost more.
5. Router software continues to become more complex and more fragile and eve=
n more poorly implemented than the current state of the average home gateway=
 while not actually adding any new functionality, just continuing to escalat=
e the arms race to stay where we are in the face of an ever worsening NAT en=
vironment.
6. Performance continues to degrade on the alter of ever more layers of tran=
slation, obfuscation, hackery, workarounds, etc.

My hope is that we will realize at some point that this is a badly loosing p=
roposition, but, my fear is that we will actually find ways to make it work a=
nd worse yet, dedicate resources to doing so.

IMHO, having it fail miserably is the best case scenario. The alternatives a=
re far worse.

>>> Wireless has - remind me - how many /8's compared to, say, Google?
>>=20
>> Are you sure that 75% of VZW's IP addresses are assigned to end-customer
>> devices? I am not.
>=20
> No, actually, I believe what he said is that OF the Addresses ASSIGNED to d=
evices, 75% are end-customers.

Even that is a statistic of which I am unconvinced without better evidence.

> Far more are likely not in use by any specific device at any given point i=
n time.

Sure, but let's go with the modified statement you give above.

That assumes that VZW's entire network infrastructure, including billing sys=
tems, backhaul, provisioning, helpdesk, call centers, offices, servers, etc.=
 all adds up to less than 1/4 of the
total devices connected to their network.

I highly doubt it.

> And what else exactly would VZW  be doing with those addresses? Running mo=
re servers and infrastructure then wireless clients to use them?

I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above f=
or a partial list of the various things I expect they are doing with those a=
ddresses.

>> First, it's more like 1/100 customers that are not already behind NAT
>> of some form, so your 37 years drops to 0.37 years (a little more than
>> 4 months).
>=20
> Rather disingenuous of you. We are not addressing "some form" of nat. We a=
re addressing the specific form of CGN. Of which far fewer then 1/100 custom=
ers are behind.

Then it's equally disingenuous to use VZW end-user device counts as well.

> How about much simpler math. Assume 75% IP in any provider organization ar=
e for subscribers. Assume an average 5-10 subscribers per CGN IP.

I don't believe the first assumption and I think that more than about 3 is r=
ather optimistic for the second one, actually. Especially in the face of ded=
icated port range CGN proposed by most of the ISPs I know have real plans to=
 implement CGN rather than just a "yeah, we'll do that when we have to" appr=
oach.


> Clearly, that organization's subscriber growth will be limited by CGN tech=
nology, not by address scarcity.

Why? Does it not scale linearly? If not, why not?

>> This seems very disruptive and rather heavy on the overhead for a 4-month=

>> stop-gap.
> >
> > Owen
> >
> >
>=20
> Think locally for a bit. Addresses are not instantaneously fungible across=
 the internet. Any provider who can pull this off will have far more then a 4=
-month stop-gap. They may even have enough to peddle on the market.

I think that's very optimistic. I'm not sure why you say they are not instan=
taneously fungible. It takes me only a few seconds to move an address around=
 between locations I control and only a little longer if I want to move it a=
round with someone else who is interested in cooperating in that move.


Owen=


home help back first fref pref prev next nref lref last post