[159705] in North American Network Operators' Group
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jan 18 12:54:57 2013
In-Reply-To: <50F970DF.2090501@ttec.com>
From: Owen DeLong <owen@delong.com>
Date: Fri, 18 Jan 2013 07:51:48 -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 18, 2013, at 5:57 AM, Joe Maimon <jmaimon@ttec.com> wrote:
>=20
>=20
> Owen DeLong wrote:
>=20
>=20
>>> Clearly we have run out of trickery as multiple layers of NAT stumps eve=
n the finest of our tricksters.
>>=20
>> Yes, we can dedicate thousands more developer hours to making yet more ex=
tensions to code to work around yet more NAT and maybe make it sort of kind o=
f work almost as poorly as it does now. Or we could pour a fraction of those=
developer hours into implementing IPv6 in those same applications and have t=
he problem solved in perpetuity.
>=20
> There is no "we"
>=20
> People will follow their personal motivations. If that includes improving t=
heir application experience in the face of prevalent CGN technology, I expec=
t many of them to decide to put in the effort no matter what either your or I=
have to say about it.
>=20
There most certainly is a "WE". "WE" may not get to make the decision about h=
ow any of this turns out, but "WE" will suffer the consequences of those col=
lective decisions.
>> My hope is that we will realize at some point that this is a badly loosin=
g proposition, but, my fear is that we will actually find ways to make it wo=
rk and worse yet, dedicate resources to doing so.
>>=20
>> IMHO, having it fail miserably is the best case scenario. The alternative=
s are far worse.
>=20
> See above. The internet is not top down. It is a potpourri of interacting i=
nfluences. Nobody takes marching orders from either of us.
>=20
Right, but everybody suffers the consequences of the decisions made by those=
interacting influences. As such, I am at least attempting to educate as man=
y of the decision makers along the way in the hopes of getting some reasonab=
le outcome somewhere down the road rather than watching the internet fall to=
pieces in NAT hell.
>> I'd believe 50% or maybe even 65%, but 75% stretches credibility. See abo=
ve for a partial list of the various things I expect they are doing with tho=
se addresses.
>=20
> So a provider to have a one to one relationship between infrastructure add=
resses and subscribers is somehow plausible to you? Anyone else?
>=20
Subscribers, no, subscriber addresses in a wireless environment, yeah.
> Not to me. Not even if you count every single employees and every single c=
orporate server and device, of which the vast majority are not even using gl=
obally unique addresses. Which is what we are discussing.
>=20
> And suppose they are. A corporation like that can re-use 50% of their IPv4=
by converting internally to NAT (and IPv6 we hope).
There are many ways we can sabotage our infrastructure in order to squeeze m=
ore NAT out of many places. Personally, I would not advocate putting that ef=
fort into such an obviously losing proposition, but obviously I may well be i=
n the minority there.
>>> How about much simpler math. Assume 75% IP in any provider organization a=
re for subscribers. Assume an average 5-10 subscribers per CGN IP.
>>=20
>> I don't believe the first assumption and I think that more than about 3 i=
s rather optimistic for the second one, actually. Especially in the face of d=
edicated port range CGN proposed by most of the ISPs I know have real plans t=
o implement CGN rather than just a "yeah, we'll do that when we have to" app=
roach.
>=20
> Most NAT44 implementations have absolutely no issue scaling to low hundred=
s of users with ONE IP address.
>=20
We're not talking NAT44... We're talking NAT444 and you don't get nearly the=
multiplier at the second layer that you can get at the first level. You've a=
lready concentrated those low hundreds of users into the port range of a sin=
gle address at the first level. Now you're inflicting a second level where y=
ou can't get nearly that level of compression.
> 3 is absolutely ridiculously low. 3 of the above, maybe.
>=20
> However, even at 3, that means that they can double their subscriber base w=
ith their existing addresses. So unless their existing base took 2 months to=
acquire, that is a deal more than 4 month stop gap you claim.
Or not. At 3 they can double their subscriber base if they don't need any ad=
ditional external facing infrastructure to support all of this and get a 100=
% efficient conversion of users from their existing connectivity to CGN.
> And since you believe that it is plausible for such an organization to hav=
e a one to one infrastructure/subscriber relationship, going private (and we=
hope ipv6) internally, gives them another 3x subscriber base.
>=20
> Clearly, CGN can provide enough address re-use to stave off exhausting in a=
provider's subscriber base for years.
>=20
> But only if the technology scales and is not immediately rejected by 30-60=
% of the subscriber base.
Which assumes many facts not in evidence and is contrary to the research and=
testing that has been done so far.
> This is why we view the testing of CGN as newsworthy.
>=20
draft-donnely anyone?
>>=20
>>=20
>>> Clearly, that organization's subscriber growth will be limited by CGN te=
chnology, not by address scarcity.
>>=20
>> Why? Does it not scale linearly? If not, why not?
>=20
> I dont particularly like a multilayered NAT internet any more than you.
>=20
> However it is coming and will stay for as long as it is needed and useful f=
or those who operate it. Which is likely to be far longer then either of us l=
ike.
>=20
> We only differ in one point. You believe it will be so bad that it will im=
mediately drive ipv6 adoption and be viewed as a short term expensive boondo=
ggle of a misguided experiment. I am not so confident in its failure.
I'm not confident in it's failure, rather I'm afraid we will pour $billions i=
nto making it work.
> I think we are heading toward a new norm.
>=20
You may, unfortunately be correct.
>>>=20
>>> Think locally for a bit. Addresses are not instantaneously fungible acro=
ss 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.
>>=20
>> I think that's very optimistic.
>=20
> With your numbers, a provider can double or triple (actually quadruple or s=
extuple using your ratio) their subscriber base by converting to CGN. Were y=
ou being overly optimistic?
>=20
> Or were my estimates, starting at quadrupling or more, overly optimistic?
You assume a 100% conversion rate and 100% across the board acceptance of th=
e change among all subscribers. That's a HUGE capital outlay all at once and=
pretty optimistic on the acceptance rate IMHO, so, yes, you were overly opt=
imistic.
>=20
>> I'm not sure why you say they are not instantaneously fungible.
> >
> > Owen
>=20
> Because nobody deploying CGN is going to flag day convert entire subscribe=
r bases. Because the addresses they free up will be reused internally. Becau=
se if you are not one of these entities with low hanging fruit such as easil=
y convertible to CGN subscriber bases, you are NOT going to directly benefit=
from the efforts of those who do.
I agree that not all addresses are immediately available for fungibility, bu=
t, an available address is instantaneously fungible.
Anyway, IMHO, all resources dedicated to CGN are resources that would be bet=
ter spent moving away from IPv4. Fortunately, so far, the majority of larger=
residential providers seem to be looking in the same direction. Yes, we'll b=
e stuck with some CGN, but I suspect most providers will implement it on a "=
we inflict this on new subscribers as we have to, but only as many as we hav=
e to until we can turn off v4." basis.
Owen
