Misfeatures of UPnP: A) only for IPv4/NAT gateways; B) proprietary specification; C) defined as profile of SOAP over UDP (so very wide attack surface); D) allows every client to make 3rd-party port maps by default (so very insecure by design).
Corrections in PCP A) works for IPv4/NAT and IPv6 gateways (NAT and w/o NAT); B) open IETF specification; C) defined as simple binary protocol (so very narrow attack surface); D) disallows 3rd-party port maps unless optional extension implemented (so less insecure by design).
You need something that does this if you have a firewall (whether there is NAT or not). If you have an IPv6 gateway, then see RFC 6092 section 3.4 Passive Listeners for an explanation. That RFC is referenced by CableLabs and BBF specs, so it is what you should expect to see in most provider-provisioned home gateways in the near future.
Seriously, PCP is what you need to use for this. Does this suck? Maybe. Depends on whether you think having firewalls everywhere denying all inbound traffic to passive listeners by default is a good idea. If you think that's a good idea, then PCP doesn't suck. Deal with it.
> So how do you propose that my game on a machine on NAT arranges to receive UDP through the firewall? I'm supposed to manually configure firewall rules for each game? And then change them all if my IP changes?
Another feature of the AirPort home gateway product line is that it doesn't have any UPnP support, which is the attack surface that has been proven to be so difficult to secure. It also doesn't have an embedded web server for administration and configuration, using instead a proprietary Apple protocol between the firmware and the AirPort Utility rich client program that runs on OS X, iOS and Windows. The attack surface on the AirPort home gateway is really small compared to other products.
Too bad Apple will probably never make another one.
Headline on the original article: What to Do About the Scarcity of IPv4 Addresses Headline on the Slashdot post: Sale of IPv4 Addresses Hindering IPv6 Adoption
TCP port 443 is the new waist of the Internet, and it doesn't look like that's going to change with the transition to IPv6 either. Should we just forget about concurrent multi-path and multi-streaming at the transport layer and do it all at the application layer? Or do you think there might still be room for fixing these problems at the transport layer?
We're talking about an attack that only currently originates from a user population representing less than 0.3% of the Internet user population. If you're under attack over IPv6, then just pull the plug. Seriously, I get that you need to keep your family jewels in a bank vault. You can probably keep the rhinestones under the bed and save on the safe deposit fees.
Turns out for external facing web services, you don't need any of that. You just rack up an IPv6 load-balanced proxy and point it at your existing IPv4 servers. The trick is making sure you don't shoot yourself by implementing a stupid per-source address limit and kill your site over IPv6 because all the IPv4 source addresses are the for the proxy array.
Most of the IPv4 stuff that ISPs are already using today was either never designed for the NAT444 subscriber model, or if it was, then it's badly broken and not as well engineered as the comparatively older and better designed IPv6 stuff. This is especially apparent when you're looking at service providers with more than 16 million subscribers, who need to number subscribers in multiple separate address realms. This is the main problem cited to me by operators who have rejected NAT444 in favor of IPv6 DS/DS-lite.
For evidence, I don't have much to point out except the fact that every major ISP in the United States and Europe, and many in Asia as well, having looked at the operational considerations associated with the NAT444 and IPv6 DS/DS-lite alternatives, now seems to have concluded that the latter is superior to the former. Admittedly, I have nothing but anecdotes to relay if you want help explaining their observed behavior.
As for making GoldenShield workalikes, yes Virginia— that's a piece of cake with IPv6. Easier, actually, because you have only a single address realm to manage.
All of those things can be accomplished at lower cost and with higher scalability and manageability with IPv6. There are some reasonable arguments for deploying NAT444 instead of IPv6 DS or DS-lite, but none of them have anything to do with tightening your grip on what your user community is doing with your network.
Um... because we'd all rather write 2001:db8:0:a::101 instead of 32.1.13.184.0.0.0.10.0.0.0.0.0.0.1.1? Especially since, for anyone with much experience in IPv6 at all, we can look at the former and see the special documentation prefix 2001:db8::/32 at a glance, then see that the subnet identifier is "0:a" and the host identifier is "101" and we're good. That dot delimited version doesn't look so good next to that, does it?
If your computer only knows how to send packets to 4-octet IP addresses, how does it communicate with other computers that have the new longer addresses you're proposing?
Hell, your wireless provider has almost certainly set up a special backdoor for them to get this information about anyone they want without even having to write a letter or speak to a human being. It's a pain in the ass to read and respond to all those letters. It's a pain in the ass to have to write them. Everyone is happier when the cops just log into the LE portal and take whatever data they want.
Everyone loves cops, and everybody wants to help them fight crime and stuff! You love the cops, don't you? Of course, you do. Now, shut up and go back to whining about the fact your location services cache got backed up in the clear to your personal computer.
Which would be relevant if the UDID of the device were being sent to the global database. Gee, I wonder what the letter says about that. I wonder what identifiers competing devices with location services send. I wonder if anybody actually cares about trivial details like that.
Overly clever client-server application programmers using the client private IP address as a unique client identifier, formatting them on the wire with inet_ntop, and the server failing when it can't parse them. Stupidity like that.
You're probably going to be surprised when you find out how many web applications fail comically, when their clients come from IPv6-only hosts through a NAT64+DNS64 gateway, because stupid web coders think clients have to have an IPv4 address to communicate with their server.
It's a non-trivial number. A lot of them are proprietary enterprise applications. My employers have a raft of them. People are beginning to notice that IPv6 transition isn't something can ignore for much longer.
It's optional for 3rd-party applications, but many of the system components make use of it. If people want to run Samba on Mac OS X, there is this thing called MacPorts where you can find its port of Samba, plus lots and lots and lots of other GPLv3 software, and none of it requires an Apple code signature to run.
That may or may not be what you want. Choose wisely.
Slashdot Mirror
They're wrong.
Misfeatures of UPnP: A) only for IPv4/NAT gateways; B) proprietary specification; C) defined as profile of SOAP over UDP (so very wide attack surface); D) allows every client to make 3rd-party port maps by default (so very insecure by design).
Corrections in PCP A) works for IPv4/NAT and IPv6 gateways (NAT and w/o NAT); B) open IETF specification; C) defined as simple binary protocol (so very narrow attack surface); D) disallows 3rd-party port maps unless optional extension implemented (so less insecure by design).
You need something that does this if you have a firewall (whether there is NAT or not). If you have an IPv6 gateway, then see RFC 6092 section 3.4 Passive Listeners for an explanation. That RFC is referenced by CableLabs and BBF specs, so it is what you should expect to see in most provider-provisioned home gateways in the near future.
Seriously, PCP is what you need to use for this. Does this suck? Maybe. Depends on whether you think having firewalls everywhere denying all inbound traffic to passive listeners by default is a good idea. If you think that's a good idea, then PCP doesn't suck. Deal with it.
> So how do you propose that my game on a machine on NAT arranges to receive UDP through the firewall? I'm supposed to manually configure firewall rules for each game? And then change them all if my IP changes?
Ladies and gentlemen, I give you Port Control Protocol [RFC 6887].
Another feature of the AirPort home gateway product line is that it doesn't have any UPnP support, which is the attack surface that has been proven to be so difficult to secure. It also doesn't have an embedded web server for administration and configuration, using instead a proprietary Apple protocol between the firmware and the AirPort Utility rich client program that runs on OS X, iOS and Windows. The attack surface on the AirPort home gateway is really small compared to other products.
Too bad Apple will probably never make another one.
fc00:/7 are *not* private addresses. They are globally scoped, but non-globally routable.
Headline on the original article: What to Do About the Scarcity of IPv4 Addresses
Headline on the Slashdot post: Sale of IPv4 Addresses Hindering IPv6 Adoption
Well-played.
> First I will not say which "side" I am on as that is unimportant as my total climate knowledge is based on grumbling about weather.
Yet, that's the very first thing you did: tell us which "side" you are on. Well played.
Yes, but it's only a very superficial one. Scratch the surface just a bit, and you'll find the same reactionary impulse driving both of them.
TCP port 443 is the new waist of the Internet, and it doesn't look like that's going to change with the transition to IPv6 either. Should we just forget about concurrent multi-path and multi-streaming at the transport layer and do it all at the application layer? Or do you think there might still be room for fixing these problems at the transport layer?
Ssh. You'll wake the baby.
We are old.
We're talking about an attack that only currently originates from a user population representing less than 0.3% of the Internet user population. If you're under attack over IPv6, then just pull the plug. Seriously, I get that you need to keep your family jewels in a bank vault. You can probably keep the rhinestones under the bed and save on the safe deposit fees.
Turns out for external facing web services, you don't need any of that. You just rack up an IPv6 load-balanced proxy and point it at your existing IPv4 servers. The trick is making sure you don't shoot yourself by implementing a stupid per-source address limit and kill your site over IPv6 because all the IPv4 source addresses are the for the proxy array.
Most of the IPv4 stuff that ISPs are already using today was either never designed for the NAT444 subscriber model, or if it was, then it's badly broken and not as well engineered as the comparatively older and better designed IPv6 stuff. This is especially apparent when you're looking at service providers with more than 16 million subscribers, who need to number subscribers in multiple separate address realms. This is the main problem cited to me by operators who have rejected NAT444 in favor of IPv6 DS/DS-lite.
For evidence, I don't have much to point out except the fact that every major ISP in the United States and Europe, and many in Asia as well, having looked at the operational considerations associated with the NAT444 and IPv6 DS/DS-lite alternatives, now seems to have concluded that the latter is superior to the former. Admittedly, I have nothing but anecdotes to relay if you want help explaining their observed behavior.
As for making GoldenShield workalikes, yes Virginia— that's a piece of cake with IPv6. Easier, actually, because you have only a single address realm to manage.
I play comment Bingo with them.
All of those things can be accomplished at lower cost and with higher scalability and manageability with IPv6. There are some reasonable arguments for deploying NAT444 instead of IPv6 DS or DS-lite, but none of them have anything to do with tightening your grip on what your user community is doing with your network.
> and I believe similar functionality is also in Safari.
Wrong.
Um... because we'd all rather write 2001:db8:0:a::101 instead of 32.1.13.184.0.0.0.10.0.0.0.0.0.0.1.1? Especially since, for anyone with much experience in IPv6 at all, we can look at the former and see the special documentation prefix 2001:db8::/32 at a glance, then see that the subnet identifier is "0:a" and the host identifier is "101" and we're good. That dot delimited version doesn't look so good next to that, does it?
You should expect that avoiding IPv6 will mean paying extra in the not too distant future.
If your computer only knows how to send packets to 4-octet IP addresses, how does it communicate with other computers that have the new longer addresses you're proposing?
> The last thing I want is every device in my home having a globally addressable IP address.
But you're totally okay with them having globally routed private realm IPv4 addresses. Good to know.
Hell, your wireless provider has almost certainly set up a special backdoor for them to get this information about anyone they want without even having to write a letter or speak to a human being. It's a pain in the ass to read and respond to all those letters. It's a pain in the ass to have to write them. Everyone is happier when the cops just log into the LE portal and take whatever data they want.
Everyone loves cops, and everybody wants to help them fight crime and stuff! You love the cops, don't you? Of course, you do. Now, shut up and go back to whining about the fact your location services cache got backed up in the clear to your personal computer.
Which would be relevant if the UDID of the device were being sent to the global database. Gee, I wonder what the letter says about that. I wonder what identifiers competing devices with location services send. I wonder if anybody actually cares about trivial details like that.
Overly clever client-server application programmers using the client private IP address as a unique client identifier, formatting them on the wire with inet_ntop, and the server failing when it can't parse them. Stupidity like that.
You're probably going to be surprised when you find out how many web applications fail comically, when their clients come from IPv6-only hosts through a NAT64+DNS64 gateway, because stupid web coders think clients have to have an IPv4 address to communicate with their server.
It's a non-trivial number. A lot of them are proprietary enterprise applications. My employers have a raft of them. People are beginning to notice that IPv6 transition isn't something can ignore for much longer.
There is a code-signing facility in Mac OS X.
It's optional for 3rd-party applications, but many of the system components make use of it. If people want to run Samba on Mac OS X, there is this thing called MacPorts where you can find its port of Samba, plus lots and lots and lots of other GPLv3 software, and none of it requires an Apple code signature to run.
That may or may not be what you want. Choose wisely.