Not sure about Vonage, but Skype, Xbox, and just about everything else
imaginable (other than hosting a server) works just fine over NAT with
default-deny inbound here, and we have several thousand students in the
dorms that bang the heck out of those services. Most applications have
adapted to the SOHO NATing router that is prevalent today on broadband
internet. And if it didn't work, believe me, I'd hear about it 
Jeff
I'll agree there, as developers have built in some tricks to work around NAT issues. But in reality doing away with NAT is a much better alternative for the long haul. So you are both right, but I'll side with Owen when doing network deployments as to ease my future headaches.
NAT yes.
NAT + NAT (NAT444 or CGN which is what we are talking about here), not so much.
Owen
Once you are doing NAT and your immediate gateway does not supports
UPnP, what's the difference if it's NAT44 or NAT444?
I'm currently using NAT444444, with at least two layers of 802.11g
WiFi and 5 routers that seem to be doing independent NAT. Two of them
are mine, then the other 3 are of the ISP, to whom I connect through
802.11g, and it generally works just fine; traceroute on the final
hosts shows 5 first hops being in various separate 192.168.0.0/16 and
10.0.0.0/8 networks. iChat works. SIP works, too (for both incoming
and outgoing voice call). Even ssh connections stay alive for more
than 24h with a mere 240s keepalive setting.
IPv6 is obviously the solution, but I think CGN poses more
technological and legal problems for the carriers as opposed to their
clients or the general-purpose non-server non-p2p application
developers.
CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever.
C.
Is the output of traceroute you reference above what you base your supposition on that you are behind multiple NATs? Or do you have some other information indicating so?
Owen DeLong wrote:
And this is where you run off the rails� You are assuming that NAT today
and CGN provide similar functionality from an end-user perspective.
To the extent that CGN functions like the clueless linksys daisy-chain, then yes it does.
The reality is that they do not. CGN is a substantially more degraded
form of internet access than current traditional per-site NAT.1. The end-site does not control the NAT box.
The vast majority of end site today either do not control the NAT box or do not know how to control the NAT box.
2. UPnP and NAT-PMP do NOT work through CGN.
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!
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.
Clearly we have run out of trickery as multiple layers of NAT stumps even the finest of our tricksters.
We will have to wait and see on this one. There is a complex interaction between protocol development, application deployment, cpe technology and user behavior all influenced by the NAT reality we are all witness to.
Will this interaction adopt and adapt CGN? Clearly your opinion is not, but its only an opinion.
Wireless has - remind me - how many /8's compared to, say, Google?
Are you sure that 75% of VZW's IP addresses are assigned to end-customer
devices? I am not.
No, actually, I believe what he said is that OF the Addresses ASSIGNED to devices, 75% are end-customers.
Far more are likely not in use by any specific device at any given point in time.
And what else exactly would VZW be doing with those addresses? Running more servers and infrastructure then wireless clients to use them?
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).
Rather disingenuous of you. We are not addressing "some form" of nat. We are addressing the specific form of CGN. Of which far fewer then 1/100 customers are behind.
How about much simpler math. Assume 75% IP in any provider organization are for subscribers. Assume an average 5-10 subscribers per CGN IP.
Clearly, that organization's subscriber growth will be limited by CGN technology, not by address scarcity.
This seems very disruptive and rather heavy on the overhead for a 4-month
stop-gap.
>
> Owen
>
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.
Joe
Owen DeLong wrote:
And this is where you run off the rails… You are assuming that NAT today
and CGN provide similar functionality from an end-user perspective.To the extent that CGN functions like the clueless linksys daisy-chain, then yes it does.
Right, but it that extent is very limited.
The reality is that they do not. CGN is a substantially more degraded
form of internet access than current traditional per-site NAT.1. The end-site does not control the NAT box.
The vast majority of end site today either do not control the NAT box or do not know how to control the NAT box.
Bzzt... They may not actively control it through an administrative interface, but, there is not some other administrator actively disabling functionality they care about.
2. UPnP and NAT-PMP do NOT work through CGN.
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 things did not work/did not exist much before UPnP/NAT-PMP. That is the reason UPnP and NAT-PMP were developed and gained such wide acceptance so quickly. Prior to that, some popular applications also received customized ALGs implemented 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.Clearly we have run out of trickery as multiple layers of NAT stumps even the finest of our tricksters.
Yes, we can dedicate thousands more developer hours to making yet more extensions to code to work around yet more NAT and maybe make it sort of kind of 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 the problem solved in perpetuity.
We will have to wait and see on this one. There is a complex interaction between 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 OFF the damn NAT merry-go-round. NAT at this point has become the internet equivalent 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, but its only an opinion.
Actually, I'm more afraid that it will for some time to come. Results of continuing to do so:
1. Applications cost more.
2. Applications become progressively even more fragile and more poorly implemented that the current state of affairs.
3. Security goes even more out the window than it already has because there will be even less ability to identify the source of malicious conduct than there is today.
4. Routers cost more.
5. Router software continues to become more complex and more fragile and even more poorly implemented than the current state of the average home gateway while not actually adding any new functionality, just continuing to escalate the arms race to stay where we are in the face of an ever worsening NAT environment.
6. Performance continues to degrade on the alter of ever more layers of translation, obfuscation, hackery, workarounds, etc.
My hope is that we will realize at some point that this is a badly loosing proposition, but, my fear is that we will actually find ways to make it work and worse yet, dedicate resources to doing so.
IMHO, having it fail miserably is the best case scenario. The alternatives are far worse.
Wireless has - remind me - how many /8's compared to, say, Google?
Are you sure that 75% of VZW's IP addresses are assigned to end-customer
devices? I am not.No, actually, I believe what he said is that OF the Addresses ASSIGNED to devices, 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 in time.
Sure, but let's go with the modified statement you give above.
That assumes that VZW's entire network infrastructure, including billing systems, 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 more servers and infrastructure then wireless clients to use them?
I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above for a partial list of the various things I expect they are doing with those addresses.
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).Rather disingenuous of you. We are not addressing "some form" of nat. We are addressing the specific form of CGN. Of which far fewer then 1/100 customers 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 are 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 rather optimistic for the second one, actually. Especially in the face of dedicated 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" approach.
Clearly, that organization's subscriber growth will be limited by CGN technology, 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
>
>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 instantaneously 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 around with someone else who is interested in cooperating in that move.
Owen
I hate to break it to you guys more of the larger providers in NA are implementing CGNAT in the next 6 to 18 months. Especially the mobile carriers.
I have agreed long ago that mobile is the one place where CGN will go mostly unnoticed. First of all, most mobiles have been behind some form of CGN for a long time. Second, hardly anyone expects real internet access through their mobile in NA to actually be fully functional to begin with. It's always been somewhat broken and everyone is used to that. Breaking it a little bit more will probably make no difference whatsoever.
I can already count on VZW to disable, block, or degrade to uselessness any attempt at a VOIP call or VIDEO conference other than through the built-in applications where the phone manufacturer and the carrier have come to some agreement and built in hooks to make it sort of work. I can also count on VZW to do nasty things to my DNS requests (ever try turning on DNSSEC validation on a handset? I don't recommend it.)
When I was on SPRINT, they were slightly worse. On my iPAD via AT&T, it's much worse.
Mobile carriers in North America are an ever increasing quagmire where one has to attempt to locate the one that sucks least for the duration of your next contract.
Let's focus more on CGN via CMTS, GPON, or DSL system. That's where the real pain will be felt by the subscribers.
Owen
IPv6 is obviously the solution, but I think CGN poses more
technological and legal problems for the carriers as opposed to their
clients or the general-purpose non-server non-p2p application
developers.
Correct. The most significant challenges to CGN are legal compliance
issues. NAT complicates the process of determining who did what using
the public IP at this timestamp. CGN developers have designed some
novel solutions to that problem, such as dedicating port ranges to
particular interior addresses and logging the range once instead of
trying to log every connection. So, don't expect it to be a show
stopper for long.
On the technical side, enterprises have been doing large-scale NAT for
more than a decade now without any doomsday consequences. CGN is not
different.
CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever.
Also correct. The primary impacts from CGN are folks who want to host
a game server, folks running bit torrent and folks who want to use
Skype. Skype's not stupid and voip relays are easy so after minor
growing pains that'll cease to be an issue too.
Make opting out of CGN simple and cheap. The relatively few folks who
would be impacted will opt out with no particular animus towards you
and you'll recover the IP addresses you had dedicated to the rest.
Regards,
Bill Herrin
Well yeah, but everything is under control of the IT department to setup
rules and forwards. That's not the same as a end user that wants a port
forward to host a xbox 360 game on their fiber connection and can't set
it up.
I've tried getting the firewall disabled that denies "ALL" incoming
traffic on my 3G stick and it's simply not possible, that is the sort of
flexibility that the market is selling.
Most of the ISPs I have personally and professionally worked with have
the flexibility of a piece of mahogany.
I'm pretty sure that some of the dedicated online game hosters are
looking forward to this. Those investments should turn out great.
Regards,
Seth
(resending with nanog-approved address..)
Vonage will, in most cases fail through CGN as will Skype, Xbox-360,
and many of the other IM clients.Not sure about Vonage, but Skype, Xbox, and just about everything else
imaginable (other than hosting a server) works just fine over NAT with
default-deny inbound here, and we have several thousand students in the
dorms that bang the heck out of those services. Most applications have
adapted to the SOHO NATing router that is prevalent today on broadband
internet. And if it didn't work, believe me, I'd hear about it
Your users must have fairly low expectations 
That snide comment aside, a single level of NAT44 works OK now for most current consumer level applications. But this is about multiple levels of NAT, where the usual "hacks" with UPNP IGD/NAT-PMP to get inbound ports are not likely to work. Even if you dont support these tricks on your end today, its likely that it is supported at the other side. Most "p2p" traffic like Skype only needs the mapping to work at one end, as they have to signal/negotiate addresses and portnumbers through some third party anyway.
So currently, even double NAT at one end, it is likely to work out (within the current expectations of users.)
When CGN gets to critical mass, where both ends of a connection is likely to be even more crippled than today*, things change. Now you have to bounce all the data of some third party, like a DC, maybe not even on the same continent.
When Skype fails to map ports at both ends today the experience is pretty horrible actually, at least over here, even with the backing of Microsofts infrastructure. Also makes me wonder how expensive running such services will become (Only feasable for Google and Microsoft?)
* Some support for mapping ports at CGN is in development, but requires new or updated CPE/home gateways, software support/awareness and support for it in the CGN (riiight.)
Owen DeLong wrote:
Clearly we have run out of trickery as multiple layers of NAT stumps even the finest of our tricksters.
Yes, we can dedicate thousands more developer hours to making yet more extensions to code to work around yet more NAT and maybe make it sort of kind of 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 the problem solved in perpetuity.
There is no "we"
People will follow their personal motivations. If that includes improving their application experience in the face of prevalent CGN technology, I expect many of them to decide to put in the effort no matter what either your or I have to say about it.
My hope is that we will realize at some point that this is a badly loosing proposition, but, my fear is that we will actually find ways to make it work and worse yet, dedicate resources to doing so.
IMHO, having it fail miserably is the best case scenario. The alternatives are far worse.
See above. The internet is not top down. It is a potpourri of interacting influences. Nobody takes marching orders from either of us.
I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above for a partial list of the various things I expect they are doing with those addresses.
So a provider to have a one to one relationship between infrastructure addresses and subscribers is somehow plausible to you? Anyone else?
Not to me. Not even if you count every single employees and every single corporate server and device, of which the vast majority are not even using globally unique addresses. Which is what we are discussing.
And suppose they are. A corporation like that can re-use 50% of their IPv4 by converting internally to NAT (and IPv6 we hope).
How about much simpler math. Assume 75% IP in any provider organization are 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 rather optimistic for the second one, actually. Especially in the face of dedicated 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" approach.
Most NAT44 implementations have absolutely no issue scaling to low hundreds of users with ONE IP address.
3 is absolutely ridiculously low. 3 of the above, maybe.
However, even at 3, that means that they can double their subscriber base with 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.
And since you believe that it is plausible for such an organization to have a one to one infrastructure/subscriber relationship, going private (and we hope ipv6) internally, gives them another 3x subscriber base.
Clearly, CGN can provide enough address re-use to stave off exhausting in a provider's subscriber base for years.
But only if the technology scales and is not immediately rejected by 30-60% of the subscriber base.
This is why we view the testing of CGN as newsworthy.
Clearly, that organization's subscriber growth will be limited by CGN technology, not by address scarcity.
Why? Does it not scale linearly? If not, why not?
I dont particularly like a multilayered NAT internet any more than you.
However it is coming and will stay for as long as it is needed and useful for those who operate it. Which is likely to be far longer then either of us like.
We only differ in one point. You believe it will be so bad that it will immediately drive ipv6 adoption and be viewed as a short term expensive boondoggle of a misguided experiment. I am not so confident in its failure.
I think we are heading toward a new norm.
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.
With your numbers, a provider can double or triple (actually quadruple or sextuple using your ratio) their subscriber base by converting to CGN. Were you being overly optimistic?
Or were my estimates, starting at quadrupling or more, overly optimistic?
I'm not sure why you say they are not instantaneously fungible.
>
> Owen
Because nobody deploying CGN is going to flag day convert entire subscriber bases. Because the addresses they free up will be reused internally. Because if you are not one of these entities with low hanging fruit such as easily convertible to CGN subscriber bases, you are NOT going to directly benefit from the efforts of those who do.
Unless they peddle it (or return it).
Joe
The people on this list have a influence in how the Internet run, hope
somebody smart can figure how we can avoid going there, because there
is frustrating and unfun."Free network-based firewall to be installed next month. OPT OUT HERE
if you don't want it."I haven't heard anyone talking about carrier-grade firewalls. To make
CGN
work a little, you have to enable full-cone NAT, which means as long as
you're connected to anything on IPv4, anyone can reach you (and for a
timeout period after that). And most CGN wireline deployments will have
some kind of bulk port assignment, so the same ports always go to the
same
users. NAT != security, and if you try to make it, you will lose more
customers than I predicted.Hi Lee,
Then it's a firewall that mildly enhances protection by obstructing
90% of the port scanning attacks which happen against your computer.
It's a free country so you're welcome to believe that the presence or
absence of NAT has no impact on the probability of a given machine
being compromised. Of course, you're also welcome to join the flat
earth society. As for me, the causative relationship between the rise
of the "DSL router" implementing negligible security except NAT and
the fall of port scanning as a credible attack vector seems blatant
enough.
CGNs are not identical to home NAT functionality. Home NATs are
frequently restricted cone NATs, which is why uPNP or manual
port-forwarding are required. CGNs for residential deployments are full
cone NATs, so that this problematic applications are less problematic.
See Network address translation - Wikipedia and
draft-donley-nat444-impacts.
It's not a hard problem. There are yet plenty of IPv4 addresses to go
around for all the people who actually care whether or not they're
behind a NAT.I doubt that very much, and look forward to your analysis supporting
that
statement.If you have the data I'll be happy to crunch it but I'm afraid I'll
have to leave the data collection to someone who is paid to do that
very exhaustive work.
I don't have any data that might support your assertion, which is why I'm
calling you on it.
Nevertheless, I'll be happy to document my assumptions and show you
where they lead.I assume that fewer than 1 in 10 eyeballs would find Internet service
behind a NAT unsatisfactory. Eyeballs are the consumers of content,
the modem, cable modem, residential DSL customers. Some few of them
are running game servers, web servers, etc. but 9 in 10 are the email,
vonage and netflix variety who are basically not impacted by NAT.
Netflix seems to have some funny interactions with some gateways and CGN.
[nat444-impacts]
What about p2p?
I assume that 75% or more of the IPv4 addresses which are employed in
any use (not sitting idle) are employed by eyeball customers. Verizon
Wireless has - remind me - how many /8's compared to, say, Google?
The same number: 0.
I don't know how many addresses VZW has, but I could look it up in Whois
if I knew the orgID.
How'd you get 75%?
If you count from the explosion of interest in the Internet in 1995 to
now, it took 18 years to consume all the IPv4 addresses. Call it
consumption of 1/18th of the address space per year.
You're going with linear growth? See nro.net/statistics.
Is it more like 1 in 5 customers would cough up
an extra $5 rather than use a NAT address? The nearest comparable
would be your ratio of dynamic to static IP assignments. Does your
data support that being higher than 1 in 10? I'd bet the broad data
sets don't.
If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining. Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1). That means that for every user you
NAT, you get 1/10 of an address.
Example: An 10,000-user ISP is growing at 10% annually. They have 1,000
addresses left, so they implement CGN. You say to assuming 90% of them
can be NATted, so next year, 100 get a unique IPv4 address, the other 900
share 90 addresses. At 190 addresses per year, CGN bought you five years.
I think your 90% is high. If it's 70%, you burn 370 per year.
That doesn't include the fact the increased support costs, or alienated
customer cancellations, or any of the stuff I talked about in TCO of CGN.
Lee
IPv6 is obviously the solution, but I think CGN poses more
technological and legal problems for the carriers as opposed to their
clients or the general-purpose non-server non-p2p application
developers.Correct. The most significant challenges to CGN are legal compliance
issues. NAT complicates the process of determining who did what using
the public IP at this timestamp. CGN developers have designed some
novel solutions to that problem, such as dedicating port ranges to
particular interior addresses and logging the range once instead of
trying to log every connection. So, don't expect it to be a show
stopper for long.
Many servers don't log source port. Doesn't matter if the CGN operator
has a log, if you can't provide enough data to find the right entry in the
log.
On the technical side, enterprises have been doing large-scale NAT for
more than a decade now without any doomsday consequences. CGN is not
different.
Even if the implementation was the same (it's not), that doesn't mean the
operation is the same in a a different environment. Residential users
have different applications and expectations than enterprise users (not a
lot of game consoles or BitTorrent on corporate networks). The legal
issue is different, too: a different level of response is appropriate from
a corporate net admin than an ISP.
CGN breaks the internet, but it doesn't break non-p2p VoIP at all
whatsoever.Also correct. The primary impacts from CGN are folks who want to host
a game server, folks running bit torrent and folks who want to use
Skype. Skype's not stupid and voip relays are easy so after minor
growing pains that'll cease to be an issue too.
"voip relays are easy"? To what scale, for a free service?
Make opting out of CGN simple and cheap. The relatively few folks who
would be impacted will opt out with no particular animus towards you
and you'll recover the IP addresses you had dedicated to the rest.
You are welcome to deploy it if you choose to.
Part of the reason I'm arguing against it is that if everyone deploys it,
then everyone has to deploy it. If it is seen as an alternative to IPv6
by some, then others' deployment of IPv6 is made less useful: network
effect. Also, spending money on CGN seems misguided; if you agree that
you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
also* for CGN?
Lee
IPv6 is obviously the solution, but I think CGN poses more
technological and legal problems for the carriers as opposed to their
clients or the general-purpose non-server non-p2p application
developers.Correct. The most significant challenges to CGN are legal compliance
issues. NAT complicates the process of determining who did what using
the public IP at this timestamp. CGN developers have designed some
novel solutions to that problem, such as dedicating port ranges to
particular interior addresses and logging the range once instead of
trying to log every connection. So, don't expect it to be a show
stopper for long.On the technical side, enterprises have been doing large-scale NAT for
more than a decade now without any doomsday consequences. CGN is not
different.
Yes it is... In the enterprise, whatever the security team decides isn't supposed to
be supported on the enterprise LAN, the end-users just sort of have to accept.
In the residential ISP world, unless every ISP in a given service area degrades all
of their customers in the exact same way, you have a very different situation.
CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever.
Also correct. The primary impacts from CGN are folks who want to host
a game server, folks running bit torrent and folks who want to use
Skype. Skype's not stupid and voip relays are easy so after minor
growing pains that'll cease to be an issue too.Make opting out of CGN simple and cheap. The relatively few folks who
would be impacted will opt out with no particular animus towards you
and you'll recover the IP addresses you had dedicated to the rest.
An interesting theory, but I don't think it will be so few.
Owen
Lee Howard wrote:
You are welcome to deploy it if you choose to.
Part of the reason I'm arguing against it is that if everyone deploys it,
then everyone has to deploy it. If it is seen as an alternative to IPv6
by some, then others' deployment of IPv6 is made less useful: network
effect. Also, spending money on CGN seems misguided; if you agree that
you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
also* for CGN?Lee
Suppose a provider fully deploys v6, they will still need CGN so long as they have customers who want to access the v4 internet.
Unfortunately, that may have the side effect of undercutting some portion of v6's value proposition, inversely related to its suckage.
Joe
Owen DeLong wrote:
Clearly we have run out of trickery as multiple layers of NAT stumps even the finest of our tricksters.
Yes, we can dedicate thousands more developer hours to making yet more extensions to code to work around yet more NAT and maybe make it sort of kind of 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 the problem solved in perpetuity.
There is no "we"
People will follow their personal motivations. If that includes improving their application experience in the face of prevalent CGN technology, I expect many of them to decide to put in the effort no matter what either your or I have to say about it.
There most certainly is a "WE". "WE" may not get to make the decision about how any of this turns out, but "WE" will suffer the consequences of those collective decisions.
My hope is that we will realize at some point that this is a badly loosing proposition, but, my fear is that we will actually find ways to make it work and worse yet, dedicate resources to doing so.
IMHO, having it fail miserably is the best case scenario. The alternatives are far worse.
See above. The internet is not top down. It is a potpourri of interacting influences. Nobody takes marching orders from either of us.
Right, but everybody suffers the consequences of the decisions made by those interacting influences. As such, I am at least attempting to educate as many of the decision makers along the way in the hopes of getting some reasonable 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 above for a partial list of the various things I expect they are doing with those addresses.
So a provider to have a one to one relationship between infrastructure addresses and subscribers is somehow plausible to you? Anyone else?
Subscribers, no, subscriber addresses in a wireless environment, yeah.
Not to me. Not even if you count every single employees and every single corporate server and device, of which the vast majority are not even using globally unique addresses. Which is what we are discussing.
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 more NAT out of many places. Personally, I would not advocate putting that effort into such an obviously losing proposition, but obviously I may well be in the minority there.
How about much simpler math. Assume 75% IP in any provider organization are 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 rather optimistic for the second one, actually. Especially in the face of dedicated 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" approach.
Most NAT44 implementations have absolutely no issue scaling to low hundreds of users with ONE IP address.
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 already concentrated those low hundreds of users into the port range of a single address at the first level. Now you're inflicting a second level where you can't get nearly that level of compression.
3 is absolutely ridiculously low. 3 of the above, maybe.
However, even at 3, that means that they can double their subscriber base with 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 additional 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 have a one to one infrastructure/subscriber relationship, going private (and we hope ipv6) internally, gives them another 3x subscriber base.
Clearly, CGN can provide enough address re-use to stave off exhausting in a provider's subscriber base for years.
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.
draft-donnely anyone?
Clearly, that organization's subscriber growth will be limited by CGN technology, not by address scarcity.
Why? Does it not scale linearly? If not, why not?
I dont particularly like a multilayered NAT internet any more than you.
However it is coming and will stay for as long as it is needed and useful for those who operate it. Which is likely to be far longer then either of us like.
We only differ in one point. You believe it will be so bad that it will immediately drive ipv6 adoption and be viewed as a short term expensive boondoggle 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 into making it work.
I think we are heading toward a new norm.
You may, unfortunately be correct.
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.
With your numbers, a provider can double or triple (actually quadruple or sextuple using your ratio) their subscriber base by converting to CGN. Were you being overly optimistic?
Or were my estimates, starting at quadrupling or more, overly optimistic?
You assume a 100% conversion rate and 100% across the board acceptance of the 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 optimistic.
I'm not sure why you say they are not instantaneously fungible.
>
> OwenBecause nobody deploying CGN is going to flag day convert entire subscriber bases. Because the addresses they free up will be reused internally. Because if you are not one of these entities with low hanging fruit such as easily 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, but, an available address is instantaneously fungible.
Anyway, IMHO, all resources dedicated to CGN are resources that would be better 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 be 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 have to until we can turn off v4." basis.
Owen
Lee Howard wrote:
You are welcome to deploy it if you choose to.
Part of the reason I'm arguing against it is that if everyone deploys it,
then everyone has to deploy it. If it is seen as an alternative to IPv6
by some, then others' deployment of IPv6 is made less useful: network
effect. Also, spending money on CGN seems misguided; if you agree that
you're going to deploy IPv6 anyway, why spend the money for IPv6 *and
also* for CGN?Lee
Suppose a provider fully deploys v6, they will still need CGN so long as they have customers who want to access the v4 internet.
Actually, NAT64/DNS64 is a much better alternative in that situation. The bigger issue is customers who still have v4-only devices and some reasonable expectation that those will
continue to be supported.
Unfortunately, that may have the side effect of undercutting some portion of v6's value proposition, inversely related to its suckage.
Which is why I consider the consumer electronics industry to be the important frontier in getting IPv6 support at this point. All of these smart TVs, DVD players, receivers, etc. that don't support IPv6 are going to be the real problem in deploying non-IPv4 service to residential customers in the coming years.
Owen
Lee Howard wrote:
If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining. Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1). That means that for every user you
NAT, you get 1/10 of an address.
Example: An 10,000-user ISP is growing at 10% annually. They have 1,000
addresses left, so they implement CGN. You say to assuming 90% of them
can be NATted, so next year, 100 get a unique IPv4 address, the other 900
share 90 addresses. At 190 addresses per year, CGN bought you five years.I think your 90% is high. If it's 70%, you burn 370 per year.
That doesn't include the fact the increased support costs, or alienated
customer cancellations, or any of the stuff I talked about in TCO of CGN.Lee
2-5 years from a currently one year supply?
Factor in the current base and growth for at least another decade is assured.
If it works for the new subscribers, it will work for the existing ones.
Does anybody doubt that successful CGN deployment easily translates into many years more of v4?
We understand that there are hosts of theoretical and practical impacts. What we do not yet know is how the public and providers at large will react or adapt to these impacts.
If just the right balance of CGN negativity and resulting v6 adoption is the result, then we will all muddle through more or less ok.
Otherwise we will be seeing either frantic v6 migration everywhere or even slower pace then what we have now.
Joe
Then it's a firewall that mildly enhances protection by obstructing
90% of the port scanning attacks which happen against your computer.
It's a free country so you're welcome to believe that the presence or
absence of NAT has no impact on the probability of a given machine
being compromised. Of course, you're also welcome to join the flat
earth society. As for me, the causative relationship between the rise
of the "DSL router" implementing negligible security except NAT and
the fall of port scanning as a credible attack vector seems blatant
enough.CGNs are not identical to home NAT functionality.
Didn't say they were. What I said was that claiming NAT has no
security impact was false on its face.
Home NATs are
frequently restricted cone NATs, which is why uPNP or manual
port-forwarding are required. CGNs for residential deployments are full
cone NATs,
CGNs are most certainly not full cone NATs. Full cone NATs guarantee
that any traffic which arrives at the external address is mapped to
the internal address at the same port, functionality which requires a
1:1 mapping between external addresses and active internal addresses.
Were they full-cone, with a 1:1 IP address mapping, CGNs would be
completely useless for the stated purpose of reducing consumption of
global addresses.
I'm given to understand that they do try to restrict a given internal
address to emitting packets on a particular range of ports on a
particular external address but that's functionality on top of a
restricted-port cone NAT, not a fundamentally different kind of NAT.
I assume that fewer than 1 in 10 eyeballs would find Internet service
behind a NAT unsatisfactory. Eyeballs are the consumers of content,
the modem, cable modem, residential DSL customers. Some few of them
are running game servers, web servers, etc. but 9 in 10 are the email,
vonage and netflix variety who are basically not impacted by NAT.Netflix seems to have some funny interactions with some gateways and CGN.
[nat444-impacts]
Some NATs have serious bugs that aren't obvious until you try to stack them.
What about p2p?
If it worked with CGNs there'd be a whole lot less than 1 in 10 folks
needing to opt out.
How'd you get 75%?
It's a SWAG, hence an assumption.
You're going with linear growth? See nro.net/statistics.
I'm guessing sublinear given the major backpressure from having to
purchase or transfer IP addresses from other uses instead of getting
fresh ones from a registry but the evidence isn't in yet so I'll
conservatively estimate it at linear.
Is it more like 1 in 5 customers would cough up
an extra $5 rather than use a NAT address? The nearest comparable
would be your ratio of dynamic to static IP assignments. Does your
data support that being higher than 1 in 10? I'd bet the broad data
sets don't.If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining. Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1). That means that for every user you
NAT, you get 1/10 of an address.
So at 10:1 you get 9/10ths of an address back from each of the 9 in 10
eyeballs who converts to NAT. At a more likely ratio of 30:1 you get
29/30ths back. I'd have to rerun my numbers but that shaves something
on the order of 1 year off my 37 year estimate.
Regards,
Bill Herrin