Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
From the article: "Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage." http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carri... I'm only here to bring you the news. So don't complain to me... -- http://tlmc.fredan.se
On Wed, 16 Jan 2013, fredrik danerklint wrote:
From the article:
"Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage."
I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted. To quote a NANOG veteran: "I encourage my competitors to do this" :) jms
On 16 January 2013 16:31, Justin M. Streiner <streiner@cluebyfour.org>wrote:
On Wed, 16 Jan 2013, fredrik danerklint wrote:
From the article:
"Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage."
I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted.
A lot of ISPs have customers who are foolish and short-sighted (or customers unable to move away from suppliers who are foolish and short-sighted,) and need to support those customers. I'd be very surprised if this move isn't in addition to IPv6 support, even though the article reads as though it is instead of IPv6 support. In other words, it makes sense to be able to support customers who won't move to IPv6 in the short-medium term, even though in the long term it's inevitable. Dan
On Wed, 16 Jan 2013, Daniel Ankers wrote:
In other words, it makes sense to be able to support customers who won't move to IPv6 in the short-medium term, even though in the long term it's inevitable.
I agree, IPv6 isn't an answer to "we're out of IPv4 addresses" right now. So CGNAT44 i combination with IPv6 rollout makes perfect sense. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, Jan 16, 2013 at 11:31 AM, Justin M. Streiner <streiner@cluebyfour.org> wrote:
I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted.
Move along, nothing to see here. Barring a few fanatics, everyone here has known for several years now that CGN would be required for continuing IPv4 support regardless of the progress of IPv6. If you spin it right, it's a "Free network-based firewall to be installed next month. Opt out here if you don't want it." And the fewer than 1 in 10 folks who opt out really aren't a problem. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted.
Move along, nothing to see here. Barring a few fanatics, everyone here has known for several years now that CGN would be required for continuing IPv4 support regardless of the progress of IPv6.
If you spin it right, it's a "Free network-based firewall to be installed next month. Opt out here if you don't want it." And the fewer than 1 in 10 folks who opt out really aren't a problem.
Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network. -- //fredan http://tlmc.fredan.se
On Wed, Jan 16, 2013 at 12:09 PM, fredrik danerklint <fredan-nanog@fredan.se> wrote:
Barring a few fanatics, everyone here has known for several years now that CGN would be required for continuing IPv4 support regardless of the progress of IPv6.
If you spin it right, it's a "Free network-based firewall to be installed next month. Opt out here if you don't want it." And the fewer than 1 in 10 folks who opt out really aren't a problem.
Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network.
ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network.
ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move.
Ok. If I have calculated the netmasks right that would mean to set aside: 2001:0DB8:6440::/42 for the use of 6rd service: 2001:0DB8:6440:0000::/64 = 100.64.0.0 .... 2001:0DB8:647F:FFFF::/64 = 100.127.255.255 -- //fredan http://tlmc.fredan.se
Hi,
If I have calculated the netmasks right that would mean to set aside:
2001:0DB8:6440::/42
for the use of 6rd service:
2001:0DB8:6440:0000::/64 = 100.64.0.0 .... 2001:0DB8:647F:FFFF::/64 = 100.127.255.255
You probably should add a few extra bits for subnetting behind the 6rd CPE. Delegating one /64 would be annoying as more and more CPEs have separate home/office/guest networks. Giving a /56 to each customer would be good and would only take an IPv6 /34 to map from 100.64.0.0/10. That is a quarter of the smallest IPv6 allocation an ISP can get. ISPs can get plenty of IPv6 address space these days if they need it. Smaller ISPs don't need to map the whole 100.64.0.0/10, they could just start with 100.64.0.0/16 for example, which would only take a /40 to give every customer a /56. More blocks can always be added to the 6rd setup later. Cheers, Sander
On Wed, Jan 16, 2013 at 2:53 PM, fredrik danerklint <fredan-nanog@fredan.se> wrote:
ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move.
If I have calculated the netmasks right that would mean to set aside:
2001:0DB8:6440::/42
for the use of 6rd service:
2001:0DB8:6440:0000::/64 = 100.64.0.0 .... 2001:0DB8:647F:FFFF::/64 = 100.127.255.255
Sander already touched on this, but when implementing 6rd you'll want *at least* 4 bits on the subnetting side of the IPv6 block associated with each IPv4 address and you'll want that netmask to be evenly divisible by 4. A /60 or a /56, not a /64. In IPv4 your customer has a "DSL router," potentially with distinct wired and wireless LANs running different RFC1918 address blocks. In IPv6 each of those LANs will consume a /64, so he'll need more than one. Selecting a netmask evenly divisible by 4 has two major benefits. First, it exactly matches one character in the written address. The customer doesn't have ...:ABC4:* through ...:ABC7:*, he has ...:ABC*::. Second, each delegable RDNS zone takes up the same 4 bits so the assignment will be right on an RNDS zone boundary.
Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network.
I assume you meant this a little differently than what you wrote here. It wouldn't make any kind of sense to stand up a private IPv4 network with no IPv4 Internet connection in order to facilitate IPv6 via a 6rd deployment. For one thing it'd be a Rube Goldberg machine. For another, I suspect you'd find it very challenging to acquire a threshold number of paying customers for an IPv6-only network at the moment. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In message <50F70524.4020102@fredan.se>, fredrik danerklint writes:
Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only havi ng 6rd as service on that network.
ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move.
Ok.
If I have calculated the netmasks right that would mean to set aside:
2001:0DB8:6440::/42
for the use of 6rd service:
2001:0DB8:6440:0000::/64 = 100.64.0.0 .... 2001:0DB8:647F:FFFF::/64 = 100.127.255.255
No. With 6rd you DROP the top 10 bits and you give every customer a /56. And you can repeat the exercise 4 times within a /32. /etc/dhcpd.conf: subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:: 2001:DB8::1; } subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:4000: 2001:DB8:4000:1; } subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:8000: 2001:DB8:8000:1; } subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:c000: 2001:DB8:C000:1; } -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
i am not network engineer, but I follow this list to be updated about important news that affect internet stability. NAT is already a problem for things like videogames. You want people to be able to host a multiplayer game, and have his friends to join the game. A free to play MMO may want to make a ban for a bad person permanent, and for this banning a IP is useful, if a whole range of players use a ip, it will be harder to stop these people from disrupting other people fun. Players that can't connect to the other players whine on the forums, and ask the game devs to fix the problem, costing these people money. People that can't connect to other players, for a problem that is not in his side, or under his control, get frustrated. This type of problems are hard to debug for users. 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. -- -- ℱin del ℳensaje.
On 17 January 2013 10:06, . <oscar.vives@gmail.com> wrote:
i am not network engineer, but I follow this list to be updated about important news that affect internet stability.
NAT is already a problem for things like videogames. You want people to be able to host a multiplayer game, and have his friends to join the game. A free to play MMO may want to make a ban for a bad person permanent, and for this banning a IP is useful, if a whole range of players use a ip, it will be harder to stop these people from disrupting other people fun. Players that can't connect to the other players whine on the forums, and ask the game devs to fix the problem, costing these people money. People that can't connect to other players, for a problem that is not in his side, or under his control, get frustrated. This type of problems are hard to debug for users.
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.
If you follow this list then you should already know the answer, functional* IPv6 deployments. - Mike *Some ISPs have some very weird ideas that I hope never catch on.
On Thu, 17 Jan 2013, Mike Jones wrote:
If you follow this list then you should already know the answer, functional* IPv6 deployments.
AND game developers who build IPv6 functionality into their products. Do you hear us, PS3 and Xbox? Oscar, make sure you are telling your favorite game developers that they need to support IPv6 if they want to avoid the NAT mess. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross
On 17 January 2013 15:29, Brandon Ross <bross@pobox.com> wrote: ..
AND game developers who build IPv6 functionality into their products. Do you hear us, PS3 and Xbox?
Oscar, make sure you are telling your favorite game developers that they need to support IPv6 if they want to avoid the NAT mess.
Ok. I will pass the message. Some of them ( FOSS guys) already did http://ioquake3.org/2008/04/21/ioquake3-now-ipv6-capable/ For most commercial projects it don't have my hopes very high. Most game software development are rushed to release. -- -- ℱin del ℳensaje.
On 17/01/2013 14:29, "Brandon Ross" <bross@pobox.com> wrote:
AND game developers who build IPv6 functionality into their products. Do you hear us, PS3 and Xbox?
Oscar, make sure you are telling your favorite game developers that they need to support IPv6 if they want to avoid the NAT mess.
Indeed, the Wii-U launched less than a month ago doesn't have V6 support either. Regards, Neil.
On Thu, Jan 17, 2013 at 5:06 AM, . <oscar.vives@gmail.com> wrote:
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." 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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 1/17/13 9:54 AM, "William Herrin" <bill@herrin.us> wrote:
On Thu, Jan 17, 2013 at 5:06 AM, . <oscar.vives@gmail.com> wrote:
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.
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. Lee
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Jan 17, 2013 at 11:01 AM, Lee Howard <Lee@asgard.org> wrote:
On 1/17/13 9:54 AM, "William Herrin" <bill@herrin.us> wrote:
On Thu, Jan 17, 2013 at 5:06 AM, . <oscar.vives@gmail.com> wrote:
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.
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. 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. 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? 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.
From my assumption, 25% of the addresses are consumed by non-eyeball customers who will continue consuming them at 1/(18*4)= 1/72 of the address space per year. Assuming that server ops still need that many addresses when acquiring them is not so close to free.
From my assumptions 75% * 0.9 = 67.5% of the addresses are currently consumed by eyeball customers who can convert to NAT. Match the previous paragraph's math at 49/72's of the address space recoverable at some cost that while not trivial is also not exorbitant.
Eyeballs were consuming at (1*3)/(18*4)= 3/72's per year but if only 1 in 10 needs a global address that slows to 3/720's. 13/720's per year consumes 490/720's after 37 years. 37 years. So, where am I wrong? 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. Is the current use pattern more like 50/50 between server users and eyeball users? That'd cut things closer to a decade and a half but what data I've glanced at from CAIDA, ARIN and the like doesn't seem to support a belief that eyeballs aren't the major direct user of IPv4 addresses. Perhaps consumption is accelerating, but a lot of that has been low-key hoarding during the past 5 years or so. Even with accelerating consumption we're still looking at a couple decades before we have to really scrape for IPv4 addresses. Perhaps I fouled the math itself. I've been known to miscarry a 1. All the same, the sky doesn't seem to be falling. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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.
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. 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. 2. UPnP and NAT-PMP do NOT work through CGN. 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.
Some few of them are running game servers, web servers, etc. but 9 in 10 are the email, voyage and netflix variety who are basically not impacted by NAT.
Vonage will, in most cases fail through CGN as will Skype, Xbox-360, and many of the other IM clients.
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?
Are you sure that 75% of VZW's IP addresses are assigned to end-customer devices? I am not.
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.
I'll leave the obvious math error in this assumption as an exercise for the reader.
From my assumption, 25% of the addresses are consumed by non-eyeball customers who will continue consuming them at 1/(18*4)= 1/72 of the address space per year. Assuming that server ops still need that many addresses when acquiring them is not so close to free.
This assumption ignores non-customer use of addresses which, while minor, is not insignificant.
From my assumptions 75% * 0.9 = 67.5% of the addresses are currently consumed by eyeball customers who can convert to NAT. Match the previous paragraph's math at 49/72's of the address space recoverable at some cost that while not trivial is also not exorbitant.
This makes a rather absurd assumption that the majority of those eyeball addresses are not already assigned to eyeball NAT pools. This is the second place where your assumptions run wildly off the rails IMHO.
Eyeballs were consuming at (1*3)/(18*4)= 3/72's per year but if only 1 in 10 needs a global address that slows to 3/720's.
While the math works, it would be a lot more clear to say 1/4 * 3/18 = 3/72.
13/720's per year consumes 490/720's after 37 years.
37 years.
So, where am I wrong? 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.
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). This seems very disruptive and rather heavy on the overhead for a 4-month stop-gap. Owen
On 1/17/2013 6:50 PM, Owen DeLong wrote:
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 :) 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. Sent from my iPhone On Jan 17, 2013, at 7:30 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 1/17/2013 6:50 PM, Owen DeLong wrote:
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 :)
Jeff
On Jan 17, 2013, at 4:30 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 1/17/2013 6:50 PM, Owen DeLong wrote:
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 :)
NAT yes. NAT + NAT (NAT444 or CGN which is what we are talking about here), not so much. Owen
On 17 January 2013 17:17, Owen DeLong <owen@delong.com> wrote:
On Jan 17, 2013, at 4:30 PM, Jeff Kell <jeff-kell@utc.edu> wrote:
On 1/17/2013 6:50 PM, Owen DeLong wrote:
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 :)
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.
On Thu, 17 Jan 2013, Constantine A. Murenin wrote:
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.
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? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross
On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 18-1-2013 15:03, William Herrin wrote:
On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
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.
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
On 1/18/13 9:03 AM, "William Herrin" <bill@herrin.us> wrote:
On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
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
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
Sent from my iPad On Jan 18, 2013, at 7:48 AM, Joe Maimon <jmaimon@ttec.com> wrote:
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
On 1/18/13 12:48 PM, "Joe Maimon" <jmaimon@ttec.com> wrote:
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.
Not necessarily. Maybe they need CGN, but they need NAT64, not NAT44. Or IVI. Or maybe they should just hold their noses and buy addresses for a year or a few. What they need a transition strategy; it doesn't necessarily have to be CGN. Years ago, I asked, "Why are we stuck with NAT?" I still ask that. I believe that the reason we're stuck with it is that so many of us believe we're stuck with it--we're resigned to failure, so we don't do anything about it. One of the largest problems we have with this transition is that no one believes they have any influence on it: "I'm stuck with IPv4 until every single other host on the Internet is using IPv6, and maybe for a while after that, depending on happy eyeballs." There are many levers of influence, but the most important ones to use are those that shift externalities. The cost in transition, either in IPv6 or in CGN (or both) will be incurred disproportionately by ISPs. Content providers who care most about quality experience (and usefulness of IP address information) now support IPv6. If you think creatively, you might come up with several levers that could shift the expense from "it's up to ISPs to translate" to "content and devices manufacturer businesses are at risk if they don't support IPv6." Then there's the question--how do you know when you're done? Every single host on the Internet is running IPv6? All but 100? A million? A billion? Probably somewhere in between, but each operator has to decide. Everyone else has to decide when to support IPv6--and hope it's before operators call the transition complete, because then it's too late, because consumers will choose the competitor's product or service that works (on IPv6). If Wordpress doesn't work because there's no IPv6, but Blogspot and Blogger do, maybe consumers just switch. Lee
On Fri, Jan 18, 2013 at 1:28 PM, Lee Howard <Lee@asgard.org> wrote:
Years ago, I asked, "Why are we stuck with NAT?" I still ask that. I believe that the reason we're stuck with it is that so many of us believe we're stuck with it--we're resigned to failure, so we don't do anything about it.
Hi Lee, We're stuck with NAT because -enterprise- network security folks universally accept NAT's efficacy as a lynchpin component in their system security architecture. They accept it because the reasoning in support of the proposition makes sense and they consider the fact of its efficacy to have been satisfactorily demonstrated in practice. You can chase any other reasons for using NAT to the ends of the Earth and you'll never achieve a network where NAT's use can be discontinued. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
There is no "suckerage" to V6. Really, it's not that hard. While CGN is the reality, we need to keep focused on the ultimate goal -- a single long term solution. Imagine a day where there is no dual stack, no IPv4, and no more band-aids. It will be amazing. david. On Fri, Jan 18, 2013 at 9:48 AM, Joe Maimon <jmaimon@ttec.com> wrote:
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
On 1/18/13, David Swafford <david@davidswafford.com> wrote:
There is no "suckerage" to V6. Really, it's not that hard. While CGN is the reality, we need to keep focused on the ultimate goal -- a
Correct. CGN may be part of a transition towards IPv6. Not all providers are necessarily going to see it that way. It's a non-resolutely answered question, whether IPv4+CGN will win, and it will become the new common delivery of IP, or if IPv6 will win. What will be the ultimate cost, for a provider choosing to implement only IPv4 CGN, and completely eschew/ignore IPv6, if IPv6, gets massive buy-in and becomes a predominant IP networking technology, in demand, adopted by all their competitors.... Potential loss of much business for the service provider, due to competitive disadvantage. Versus cost of careful design and building in IPv6 together with CGN rollouts, so there is one major redesign, to prepare for transition, and not two separate rollouts one for CGN and one later to completely rethink for IPv6... In either scenario.... 1 ISP network implementation project for 1 wrong technology for dealing with IP exhaustion (IPv6 or CGN), and not recognizing the problem early is a disaster -- business goes to the competition. 2 ISP network implementation projects; first 1 technology, then the other, after discovering, the wrong technology was chosen, is an improvement (but still expensive) -- network redesign is time consuming, network devices and software are expensive, and business lost to the competition, at least until redesign is completed. 1 implementation of 1 right technology (IPv6 or CGN) and never the other is ideal -- cost implementing CGN (or IPv6) is avoided, if the technology never became necessary. (It's an unlikely scenario after IP exhaustion, however, that either will be unnecessary.) 1 up front preparation/implementation of 2 technologies, in time for IP exhaustion, has high upfront cost, but alleviates the high risk of the first 2 scenarios.
single long term solution. Imagine a day where there is no dual stack, no IPv4, and no more band-aids. It will be amazing.
It's probably about 20 years away.
david. -- -JH
On 18/01/2013 17:48, "Joe Maimon" <jmaimon@ttec.com> wrote:
Suppose a provider fully deploys v6, they will still need CGN so long as they have customers who want to access the v4 internet.
Yes indeed, and the smart folks who thought (clearly didn't!) about how the best way to manage IPV6 and IPV4 in the access network have made this really quite difficult. Much more so than it had to be.
Sent from my iPad On Jan 18, 2013, at 4:03 AM, William Herrin <bill@herrin.us> wrote:
On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
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
On Fri, 18 Jan 2013 09:03:31 -0500, William Herrin said:
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.
Corporate enterprises have been pushing GPO to the desktop for more than a decade as well. Feel free to try to push GPO to Joe Sixpack's PC, let me know how that works out for you.
From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] On Fri, 18 Jan 2013 09:03:31 -0500, William Herrin said:
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.
Corporate enterprises have been pushing GPO to the desktop for more than a decade as well. Feel free to try to push GPO to Joe Sixpack's PC, let me know how that works out for you.
We don't even do NAT here. Our corporate parent has PI space that they've had since the Jurassic period of the internet and we mostly live on that (there are spots of 1918 addresses, but not for NAT purposes, think temporary networks in lab spaces). Access to the internet at large is all via proxy, there is no direct way out. Jamie
(resending with nanog-approved address..) On 18. jan. 2013 01:30, Jeff Kell wrote:
On 1/17/2013 6:50 PM, Owen DeLong wrote:
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.)
-----Original Message----- From: Jeff Kell [mailto:jeff-kell@utc.edu] Sent: Thursday, January 17, 2013 7:30 PM [snip] 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
Really? We get a lot of students complaining about PS3s and Xboxes and giving us documentation for various games indicating that either NAT(PAT) must support UPnP or statically mapped inbound connections, or the game won't work. On the other hand, multi-player games are about the only thing that our users are actually telling us isn't working, we haven't heard any complaints about Skype, Vonage, or other VoIP or IM products. Reference: http://support.xbox.com/en-US/xbox-live/connecting/nat-type-strict -- Toivo Voll Network Engineer Information Technology Communications University of South Florida (Not speaking for my employer.)
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
Sent from my iPad On Jan 17, 2013, at 6:58 PM, Joe Maimon <jmaimon@ttec.com> wrote:
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
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
Sent from my iPad On Jan 18, 2013, at 5:57 AM, Joe Maimon <jmaimon@ttec.com> wrote:
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.
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.
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
Should NAT become prevalent and prevent innovation because of its limitations, this means that innovation will happen only with IPv6 which means the next "must have" viral applications will require IPv6 and this may spur the move away from an IPv4 that has been crippled by NAT everywhere.
On Fri, Jan 18, 2013 at 4:46 PM, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
Should NAT become prevalent and prevent innovation because of its limitations, this means that innovation will happen only with IPv6 which means the next "must have" viral applications will require IPv6 and this may spur the move away from an IPv4 that has been crippled by NAT everywhere.
It won't happen and I'll tell you why not. Client to client communication block diagrams: Without NAT: Client->Router->Router->Router->Router->Router->Client With NAT: Client->Router->Router->Relay->Router->Router->Client At a high level, the two communication diagrams are virtually identical. Add killer app. By it's nature, a killer app is something folks will pay good money for. This means that 100% of killer apps have sufficient funding to install those specialty relays. Odds of a killer app where one router can't be replaced with a specialty relay while maintaining the intended function: not bloody likely. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 13-01-18 17:00, William Herrin wrote:
Odds of a killer app where one router can't be replaced with a specialty relay while maintaining the intended function: not bloody likely.
Back in the late 1980s, large computer manufacturers such as Digital, HP, IBM were pressured to adopt the future in networking: OSI as transport and X.400 for emails. These stacks were eventually developped and implemented. However, the much simpler and more cost effective "Internet" ended up winning and it didn't take that long for governments to remove the requirements to be "OSI compliant" and accepted IPv4 and SMTP as the new standard. OSI and X.400 never gained much of a foothole and the millenium generation probably never heard of them. Is it possible that the same fate awaits IPv6 ? There is pressure to go to IPv6, but if solutions are found for IPv4 which are simpler and more easily deployed, won't that kill any/all efforts to move to IPv6 ?
On 01/18/2013 02:07 PM, Jean-Francois Mezei wrote:
OSI and X.400 never gained much of a foothole and the millenium generation probably never heard of them.
Is it possible that the same fate awaits IPv6 ? There is pressure to go to IPv6, but if solutions are found for IPv4 which are simpler and more easily deployed, won't that kill any/all efforts to move to IPv6 ?
No, because NAT-like solutions to perpetuate v4 only handle the client side of the transaction. At some point there will not be any more v4 address to assign/allocate to content provider networks. They have seen the writing on the wall, and many of the largest (both by traffic and market share) have already moved to providing their content over v6. Doug
On 19 January 2013 04:48, Doug Barton <dougb@dougbarton.us> wrote:
No, because NAT-like solutions to perpetuate v4 only handle the client side of the transaction. At some point there will not be any more v4 address to assign/allocate to content provider networks. They have seen the writing on the wall, and many of the largest (both by traffic and market share) have already moved to providing their content over v6.
Potentially another source of IPv4 addresses - every content network (/hosting provider/etc) that decides they don't want to give their customers IPv6 reachability is a future bankrupt ISP with a load of IPv4 to sell off :) - Mike
On Sat, 19 Jan 2013 06:26:53 +0000, Mike Jones said:
Potentially another source of IPv4 addresses - every content network (/hosting provider/etc) that decides they don't want to give their customers IPv6 reachability is a future bankrupt ISP with a load of IPv4 to sell off :)
The problem is that content networks tend to be a lot smaller than eyeball networks. Even AS15169 fits inside a single /12. How long will that sustain the average IPv6-adverse eyeball network?
On 18 January 2013 14:00, William Herrin <bill@herrin.us> wrote:
On Fri, Jan 18, 2013 at 4:46 PM, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
Should NAT become prevalent and prevent innovation because of its limitations, this means that innovation will happen only with IPv6 which means the next "must have" viral applications will require IPv6 and this may spur the move away from an IPv4 that has been crippled by NAT everywhere.
It won't happen and I'll tell you why not.
Client to client communication block diagrams:
Without NAT: Client->Router->Router->Router->Router->Router->Client
With NAT: Client->Router->Router->Relay->Router->Router->Client
At a high level, the two communication diagrams are virtually identical.
Add killer app. By it's nature, a killer app is something folks will pay good money for. This means that 100% of killer apps have sufficient funding to install those specialty relays.
Odds of a killer app where one router can't be replaced with a specialty relay while maintaining the intended function: not bloody likely.
Regards, Bill Herrin
The killer app of the internet is called p2p. Don't we already have a shortage of IPv4 addresses to start abandoning p2p, and requiring every service to be server-based, wasting extra precious IPv4 addresses? Where's the logic behind this: make it impossible for two computers to community directly because we have a shortage of addresses, yet introduce a third machine with, again, rather limited resources, to waste another IPv4 address? Wasting all kinds of extra resources and adding extra latency? That's not a killer app, that's the inefficiency of capitalism. C.
On Fri, Jan 18, 2013 at 9:02 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
The killer app of the internet is called p2p.
P2p is not an app, it's a technique for implementing an app. There are few apps which require p2p and can't be trivially redesigned not to. If you'll pardon me saying so (and even if you won't) those few boil down to bit torrent and its cousins: used almost exclusively for unlawful activities by cheapskates whose wallets are too few and too small to drive the system.
that's the inefficiency of capitalism.
I wouldn't put it that way but yeah, that's the gist of it. There's an unambiguous and very strong capitalist profit incentive to make your new technology work with IPv4 and NAT. The comparable profit incentive to make it work with IPv6 is weak almost to the point of non-existence. And there is a severe shortage of networking staff capable of implementing technologies that are different than what an organization has implemented before. That market push facilitates deployment of CGNs while sucking manpower away from IPv6. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 1/17/13 6:21 PM, "William Herrin" <bill@herrin.us> wrote:
On Thu, Jan 17, 2013 at 11:01 AM, Lee Howard <Lee@asgard.org> wrote:
On 1/17/13 9:54 AM, "William Herrin" <bill@herrin.us> wrote:
On Thu, Jan 17, 2013 at 5:06 AM, . <oscar.vives@gmail.com> wrote:
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 http://en.wikipedia.org/wiki/Network_address_translation 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
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
On 1/18/13 1:03 PM, "Joe Maimon" <jmaimon@ttec.com> wrote:
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.
It is difficult to change an existing customer's service. Good luck.
Does anybody doubt that successful CGN deployment easily translates into many years more of v4?
Yes, I doubt it. Although if you define "successful" as "many more years of IPv4" my doubts vanish solipsistically.
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.
Fear, uncertainty, doubt. Possible frantic migration. These sound bad to me. Lee
Joe
On Fri, Jan 18, 2013 at 12:20 PM, Lee Howard <Lee@asgard.org> wrote:
On 1/17/13 6:21 PM, "William Herrin" <bill@herrin.us> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Sent from my iPad On Jan 18, 2013, at 8:06 AM, William Herrin <bill@herrin.us> wrote:
On Fri, Jan 18, 2013 at 12:20 PM, Lee Howard <Lee@asgard.org> wrote:
On 1/17/13 6:21 PM, "William Herrin" <bill@herrin.us> wrote:
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.
Even I have never claimed that. I think everyone pretty well understands at this point just how injurious NAT is to actual security.
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.
Actually, as I understand it, it's a hybrid. It's full cone (sort of) in that any packet that arrives within the port range will be translated to the corresponding internal address. It's restricted cone in that it's a port range instead of all ports. I'm not sure how the interior device is constrained to emitting only within the port range unless they are customizing all of the CPE in order to support that.
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.
Which in itself is a pretty strong argument against CGN.
What about p2p?
If it worked with CGNs there'd be a whole lot less than 1 in 10 folks needing to opt out.
So you are assuming <10% of the internet currently uses any p2p technology? Interesting.
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.
I don't think that backpressure really works against having new subscribers or towards reducing churn in the market place where there is competition. As such, I don't see how that would apply.
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.
Actually, at 10:1, you get back 10/11ths, not 9/10ths. However, if CGN's limitations pick up some bad press in the early days, that ratio may well convert to more like 1:10 where you get back 1/11th instead of 10/11ths. This all remains to be seen. Remember, the public will go much more with the emotional reaction to the first press accounts than it will go with rational or well thought out technical argument. Owen
On Thu, 17 Jan 2013 18:21:28 -0500, William Herrin said:
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.
Oddly enough, the drop in portscanning attacks maps even more closely to the shipping of XP SP2, which turned on the onboard firewall by default. Remember that some of the really big worm hits were when they managed to get loose inside corporate networks behind the NAT... Also, a NAT doesn't stop a Java or Adobe exploit in the least, as anybody with security clue will tell you....
On 16/01/2013 08:31, Justin M. Streiner wrote:
On Wed, 16 Jan 2013, fredrik danerklint wrote:
From the article:
"Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage."
I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted.
Apparently they aren't _totally_ blind to v6, but it sounds like it's been put in the mystery "when we have a spare moment!" bin: http://community.plus.net/forum/index.php/topic,106125.0.html S.
On 16 January 2013 08:12, fredrik danerklint <fredan-nanog@fredan.se> wrote:
From the article:
"Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage."
http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carri...
I'm only here to bring you the news. So don't complain to me...
It is obvious that implementing CGN requires a lot of extra resources and a lot of hardware/firmware support for both CPE and operator equipment (the latter from both technical and legal-compliance reasons, and both the former and the latter in order to implement some kind of UPnP-compatible support to still allow some kind of p2p apps to somehow function). And this is at a time when a lot of the world internet traffic has already moved to IPv6, and all major content providers that account for most of the traffic today already support native IPv6: Google, YouTube and FB. Wouldn't it be better instead of the untested, unscalable and dead-end IPv4 CGN to massively start implementing single-stacked IPv6 with NAT64 at the ISP and *464XLAT* within the CPE RG? (With 464XLAT, you wouldn't even need a potentially troublesome DNS64.) This way, instead of having to account for subscriber growth presenting scalability issues on your limited IPv4 resources and CGN-related concerns, you can instead account for the content growth of IPv6-enabled sites, and, basically, have to plan for just about no extra IPv4 scaling budget whatsoever, since with every X subscribers that still need IPv4, you'll have every XX old subscribers that will be moving closer to being IPv6-only. And with every year, a single IPv4 address used for NAT64 will be perfectly able to scale up to serve more and more customers, since fewer and fewer people will need IPv4 connections. So: With CGN, we get to the same old chicken-and-egg story: lack of IPv6 deployment and content/app support, yet an even more imminent shortage of IPv4 addresses (and with every new customer you'll be so much more closer to it) and the scalability and legal issues. With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get all the benefits of CGN (namely, all non-p2p IPv4-only apps and services will still work perfectly fine), but only a couple of the drawbacks. And it'll actually put the correct pressure for both content and application developers to immediately switch to IPv6, and avoid you, the operator, from having to be spending the extra resources and having extra headaches on the IPv4 address shortage. It really makes no sense that any company would still want to invest a single dime into CGN when instead they could be investing in IPv6 with NAT64 and CPE RGs with 464XLAT. I honestly think that 464XLAT can potentially solve all the chicken and egg problems that the big players have been having. Supposedly, that's how T-Mobile USA is planning to move their network forward. (I'm certainly looking towards the day when I could finally enable IPv6 on a Google Nexus on T-Mo.) On the other hand, it's really strange that 464XLAT is so brand bloody new when IPv6 itself, as well as even NAT64 and DNS64, have been there for ages. The idea of 464XLAT is just so ingeniously straight and simple! Somewhat similar to 6rd, I guess. I think that instead of any kind of CGN, all residential (and mobile) broadband connections should be IPv6-only with NAT64 and 464XLAT. That'll basically solve all the actual problems with one stone: lack of IPv6 deployment from content publishers and IPv6 application support (from app developers with no IPv6), and the immediate shortage of the IPv4 addresses. Cheers, Constantine.
Constantine, On Fri, Jan 18, 2013 at 6:56 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
On 16 January 2013 08:12, fredrik danerklint <fredan-nanog@fredan.se> wrote:
From the article:
"Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage."
http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carri...
I'm only here to bring you the news. So don't complain to me...
It is obvious that implementing CGN requires a lot of extra resources and a lot of hardware/firmware support for both CPE and operator equipment (the latter from both technical and legal-compliance reasons, and both the former and the latter in order to implement some kind of UPnP-compatible support to still allow some kind of p2p apps to somehow function).
And this is at a time when a lot of the world internet traffic has already moved to IPv6, and all major content providers that account for most of the traffic today already support native IPv6: Google, YouTube and FB.
Wouldn't it be better instead of the untested, unscalable and dead-end IPv4 CGN to massively start implementing single-stacked IPv6 with NAT64 at the ISP and *464XLAT* within the CPE RG? (With 464XLAT, you wouldn't even need a potentially troublesome DNS64.) This way, instead of having to account for subscriber growth presenting scalability issues on your limited IPv4 resources and CGN-related concerns, you can instead account for the content growth of IPv6-enabled sites, and, basically, have to plan for just about no extra IPv4 scaling budget whatsoever, since with every X subscribers that still need IPv4, you'll have every XX old subscribers that will be moving closer to being IPv6-only. And with every year, a single IPv4 address used for NAT64 will be perfectly able to scale up to serve more and more customers, since fewer and fewer people will need IPv4 connections.
So:
With CGN, we get to the same old chicken-and-egg story: lack of IPv6 deployment and content/app support, yet an even more imminent shortage of IPv4 addresses (and with every new customer you'll be so much more closer to it) and the scalability and legal issues.
With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get all the benefits of CGN (namely, all non-p2p IPv4-only apps and services will still work perfectly fine), but only a couple of the drawbacks. And it'll actually put the correct pressure for both content and application developers to immediately switch to IPv6, and avoid you, the operator, from having to be spending the extra resources and having extra headaches on the IPv4 address shortage. It really makes no sense that any company would still want to invest a single dime into CGN when instead they could be investing in IPv6 with NAT64 and CPE RGs with 464XLAT.
Brilliant so far ...
I honestly think that 464XLAT can potentially solve all the chicken and egg problems that the big players have been having. Supposedly, that's how T-Mobile USA is planning to move their network forward. (I'm certainly looking towards the day when I could finally enable IPv6 on a Google Nexus on T-Mo.)
OK... i am wading into dangerous territory now: Why are you waiting? This page has the 464XLAT software and procedure for Nexus S, Galaxy Nexus, as well as apk for any rooted Android that can handle IPv6 on cellular http://dan.drown.org/android/clat/ Or for the more pure IPv6-only NAT64/DNS64 out-of-the-box experience https://sites.google.com/site/tmoipv6/lg-mytouch
On the other hand, it's really strange that 464XLAT is so brand bloody new when IPv6 itself, as well as even NAT64 and DNS64, have been there for ages. The idea of 464XLAT is just so ingeniously straight and simple! Somewhat similar to 6rd, I guess.
Well, i certainly fought it as long as i could. I was really drinking the Kool-Aid that apps that could not support IPv6 would be de-selected since they were unfit for the internet. I figured evolution would win, but inertia was certainly making things too slow, thus we needed a way to make IPv4-apps (cough cough Skype, Netflix Android App, ...) work on IPv6.
I think that instead of any kind of CGN, all residential (and mobile) broadband connections should be IPv6-only with NAT64 and 464XLAT. That'll basically solve all the actual problems with one stone: lack of IPv6 deployment from content publishers and IPv6 application support (from app developers with no IPv6), and the immediate shortage of the IPv4 addresses.
Cheers, Constantine.
Rock on. I have been on IPv6-only + NAT64/DNS64 for 2 years on mobile full-time, works fine for all my use cases (i dont use skype, voice minutes are close enough to free for many people) CB
participants (28)
-
. -
Andre Tomt -
Brandon Ross -
Cameron Byrne -
Constantine A. Murenin -
Daniel Ankers -
David Swafford -
Doug Barton -
Eric Tykwinski -
fredrik danerklint -
Jamie Bowden -
Jean-Francois Mezei -
Jeff Kell -
Jimmy Hess -
Joe Maimon -
Justin M. Streiner -
Lee Howard -
Mark Andrews -
Mikael Abrahamsson -
Mike Jones -
Neil J. McRae -
Owen DeLong -
Sander Steffann -
Seth Mos -
Stephen D. Strowes -
Valdis.Kletnieks＠vt.edu -
Voll, Toivo -
William Herrin