« Upgrades finished! | Main | Minor updates »

Old knowledge makes for bad articles

AppleInsider's article "Apple's secret "Back to My Mac" push behind IPv6" is one of those articles that means well, but contains so many glaring errors that even if they had a point to make, I can't even finish reading the silly thing. I'm not going to deconstruct the entire thing, but let's take a look at two of the most glaring issues.

First, the way "Prince McLean" talks about subnet masking, while somewhat correct, (Apple doesn't "own" any IP addresses. It has the 17.0.0.0/8 netblock assigned to them. That's a more important distinction than you may think) is a bit out of date. McLean talks about "Class A", "Class B" etc., and the problems caused by those classes. That part is correct, the problem is, it's also rather out of date, by about 15 years. In 1993, the IETF came out with RFCs 1518 and 1519, which created what we call "CIDR" or Classless Inter-Domain Routing. It's a mouthfull, but here's the gist:

Prior to CIDR, there were 3 basic levels of netblock assignment:

Class A, which was 16 million addresses. An example of this is Apple's 17.0.0.0/255.0.0.0 netblock.

Class B, which was 65,536 addresses, such as Microsoft's 207.46.0.0/255.255.0.0 netblock

Class C, which was 256 addresses, and the most common. Class C netblocks use a 255.255.255.0 subnet mask

CIDR dumps the classes for a finer parsing of the subnet mask for address assignment. So the CIDR equivalent of Apple's netblock would be 17.0.0.0/8. This tells me that Apple's netblock starts at 17.0.0.0, and contains 24 bits worth of addresses. Which is the same as the old scheme, so what's the benefit? Well, let's say you're an ISP and a client wants to sign on with you. That client has 4 computers that need "real" Internet IP addresses, and the rest of their computers will be handled via NAT, or network address translation. In that case, you'd give them a netblock that had a /30 mask, or 2 bits worth of addresses. 2² = 4 addresses.

CIDR allowed IANA, the people who really "own" IP addresses, and registries that work with IANA to reclaim a lot of unused IP Addresses, which did much to alleviate the IPv4 address space problem. True, you still have to use a contiguous subnet mask, so if our mythical client needed 6 addresses, you'd either have to give them a /29, or 8 contiguous addresses, or a /30 and a /31. It's not as fine-grained as we might like it to be, but it's a lot better than the old Class system.

So McLean is a bit behind the times with their riff on netblock assignments.

Where McLean really shows a lack of knowledge about the state of the art in network gear is in the part about NAT. I don't know who told them about NATs, but they left out a lot. For example:

Additionally, each hidden system on the inside needs some way to map the ports it uses to the ports of the outside, public address. If the NAT forwards public port 80 web traffic to one internal machine acting as a web server, it can't also forward traffic on port 80 to another machine. This causes problems for any service that wants to use specific ports, including video conferencing, torrent downloads, media streaming, file transfers, screen sharing, and so on, blocking multiple machines hidden behind NAT from being accessible at once over the same customary port.

McLean leaves out quite a few modern tricks like using DNS to route traffic. Let's say you have three web servers, server1.company.com, server2.company.com,server3.company.com. All of them work on port 80. If traffic management was stuck back 10-15 years ago, you'd have to have all three servers directly exposed to the internet, so they could have "real" IP addresses. There was no effective way to put them behind a NAT. However, nowadays, if you have modern gear, and your DNS servers/routers/firewalls are set correctly, then you can have a set of rules that say: "If you get an http request for server1.company.com, then route that to internalserver1. If you get an http request for server2.company.com, route that to internalserver2, and so on. You can manage traffic by DNS name, protocol, (so you could have HTTP for server1.company.com go to one box and FTP for server1.company.com go to another), or other options. The networking world has come a long way since the days when you all you had was IP address and port.

This bit:

NAT has also become an important part of the external security diapers that are used to protect Microsoft's Windows. Without a layer of NAT in the router's firewall, a Windows PC would expose all number of unsecured ports to public tampering. A remotely addressable Windows PC on the Internet will almost instantly become infected by malicious probes looking for its wide-open back doors.

is just a MacMac diatribe, and should be dismissed as the bullshit it is. NAT does not enable a firewall to protect a network. In fact, you don't need NAT at all for a firewall to work. NAT can add a very thin layer of protection to a network, but really, it's just there to make it cheaper and easier to put a lot of machines on the internet. (You try buying a /18 or higher netblock. That shit ain't cheap) McLean is also rather rigid on their definition of security. If there's no functional or business reason for a machine to have a "real" internet address, then there's no point in giving them one. Putting stuff out on the public internet because you can is stupid. I can shoot myself in the foot. That doesn't make it a good idea.

This paragraph:

Neither NAT nor an external firewall is really required when a computing system is property secured. The security crisis resulting from putting Microsoft's software, which was only ever originally designed to operate within an "assumed to be secure" LAN environment, on the open Internet has resulted in people thinking that PCs shouldn't be publicly addressable for their own good

is just fucking ignorant. Just because your box is "properly secured" doesn't mean it should be directly on the internet. Add the standard MacMac screed, and then dump this paragraph in the can as well.

Basically, McLean is kind of ignorant of modern networking. Some other points:

One big feature is security: all IPv6 traffic can be encrypted via a built-in component of the protocol. There's no need to wrap the old FTP protocol with a layer of encryption or use SSH, no need to turn on SSL to secure the web, no need to encrypt each email or each IM conversation and each video conference. Everything can be encrypted at the network layer in IPv6 using IPSec. This can be automatic and invisible to applications; existing, higher level security protocols such as SSL or TLS require applications to be specifically designed to support them. With IPv6, apps get network encryption "for free."

Translation: "I have no fucking clue as to the other uses of encryption and SSL, but because I don't like them, I'll dismiss them as unnecessary thanks to the magic of IPv6." SSL is also used as a way to prove you are who you say you are, and that the other server is who it says it is. That has value far beyond encryption.

Another one:

However, a real barrier to wide adoption of IPv6 lies with the routers everyone uses; if they are unable to accommodate IPv6 traffic, they will prevent users inside from accessing IPv6 traffic outside, even if their OS supports it. Many commercial routers are just now adding support for IPv6, and many consumer routers don't support it at all.

Maybe that Linksys shit McLean uses is "just now adding support for IPv6", but the grownup routers have had it for some time.

This sentence however shows that McLean really has no clue about the world of networking beyond his home Wi-Fi cloud:

Routers typically run BSD or Linux; Microsoft's software dominance on the desktop isn't even relevant in the world of routers.

No, most routers run IOS, aka Cisco's router OS.

In short, this is a bunch of MacMac poofery from a lamer rumors site, and should not be taken seriously on any level. There's just too many instances of the author not having a fucking clue about the modern state of networking to take him seriously. AKA: Don't get your facts from a site that has no use for them.

Technorati Tags:
AppleInsider has teh dumb

Categories: Mac Matters, Network Notes

Posted by John C. Welch at 17:31 | Permalink

Comments

Warning for Notes users: The commenting system uses HTML.
I know this will be scary for some of you, especially Notes fans. However, open standards, rah-rah.
If you want to use less-than or greater-than signs, or other similar characters that HTML reserves,
you'll simply have to learn to do it the HTML way. Luckily, HTML is kind of popular, no matter what
your re-educators have told you, and you can easily find help on the intertubes.

AppleInsider's article \"Apple's secret \"Back to My Mac\" push behind IPv6\" is one of those articles that means well, but contains so many glaring errors that even if they had a point to make, I can't even finish reading the silly thing. I'm not going to deconstruct the entire thing, but let's take a look at two of the most glaring issues.\n\nFirst, the way \"Prince McLean\" talks about subnet masking, while somewhat correct, (Apple doesn't \"own\" any IP addresses. It has the 17.0.0.0/8 netblock assigned to them. That's a more important distinction than you may think) is a bit out of date. McLean talks about \"Class A\", \"Class B\" etc., and the problems caused by those classes. That part is correct, the problem is, it's also rather out of date, by about 15 years. In 1993, the IETF came out with RFCs 1518 and 1519, which created what we call \"CIDR\" or Classless Inter-Domain Routing. It's a mouthfull, but here's the gist:\n\nPrior to CIDR, there were 3 basic levels of netblock assignment:

Class A, which was 16 million addresses. An example of this is Apple's 17.0.0.0/255.0.0.0 netblock.
Class B, which was 65,536 addresses, such as Microsoft's 207.46.0.0/255.255.0.0 netblock
Class C, which was 256 addresses, and the most common. Class C netblocks use a 255.255.255.0 subnet mask

The problem with this system was when an entity only needed say, 18 addresses. Sure, there were things like partial Class C netblocks, but if you got a Class C block and didn't need/use those addresses, well, you're talking about a lot of waste when you look at the whole Internet.\n\nCIDR dumps the classes for a finer parsing of the subnet mask for address assignment. So the CIDR equivalent of Apple's netblock would be 17.0.0.0/8. This tells me that Apple's netblock starts at 17.0.0.0, and contains 24 bits worth of addresses. Which is the same as the old scheme, so what's the benefit? Well, let's say you're an ISP and a client wants to sign on with you. That client has 4 computers that need \"real\" Internet IP addresses, and the rest of their computers will be handled via NAT, or network address translation. In that case, you'd give them a netblock that had a /30 mask, or 2 bits worth of addresses. 2² = 4 addresses. \n\nCIDR allowed IANA, the people who really \"own\" IP addresses, and registries that work with IANA to reclaim a lot of unused IP Addresses, which did much to alleviate the IPv4 address space problem. True, you still have to use a contiguous subnet mask, so if our mythical client needed 6 addresses, you'd either have to give them a /29, or 8 contiguous addresses, or a /30 and a /31. It's not as fine-grained as we might like it to be, but it's a lot better than the old Class system.\n\nSo McLean is a bit behind the times with their riff on netblock assignments.\n\nWhere McLean really shows a lack of knowledge about the state of the art in network gear is in the part about NAT. I don't know who told them about NATs, but they left out a lot. For example:

Additionally, each hidden system on the inside needs some way to map the ports it uses to the ports of the outside, public address. If the NAT forwards public port 80 web traffic to one internal machine acting as a web server, it can't also forward traffic on port 80 to another machine. This causes problems for any service that wants to use specific ports, including video conferencing, torrent downloads, media streaming, file transfers, screen sharing, and so on, blocking multiple machines hidden behind NAT from being accessible at once over the same customary port.

Well, if the only way to handle traffic through a NAT was at Layer 3, and you could only use IP addresses and ports, that would be more or less correct. However, things have come a long way since traffic management only lived at Layer 3. \n\nMcLean leaves out quite a few modern tricks like using DNS to route traffic. Let's say you have three web servers, server1.company.com, server2.company.com,server3.company.com. All of them work on port 80. If traffic management was stuck back 10-15 years ago, you'd have to have all three servers directly exposed to the internet, so they could have \"real\" IP addresses. There was no effective way to put them behind a NAT. However, nowadays, if you have modern gear, and your DNS servers/routers/firewalls are set correctly, then you can have a set of rules that say: \"If you get an http request for server1.company.com, then route that to internalserver1. If you get an http request for server2.company.com, route that to internalserver2, and so on. You can manage traffic by DNS name, protocol, (so you could have HTTP for server1.company.com go to one box and FTP for server1.company.com go to another), or other options. The networking world has come a long way since the days when you all you had was IP address and port.\n\nThis bit:

NAT has also become an important part of the external security diapers that are used to protect Microsoft's Windows. Without a layer of NAT in the router's firewall, a Windows PC would expose all number of unsecured ports to public tampering. A remotely addressable Windows PC on the Internet will almost instantly become infected by malicious probes looking for its wide-open back doors.

is just a MacMac diatribe, and should be dismissed as the bullshit it is. NAT does not enable a firewall to protect a network. In fact, you don't need NAT at all for a firewall to work. NAT can add a very thin layer of protection to a network, but really, it's just there to make it cheaper and easier to put a lot of machines on the internet. (You try buying a /18 or higher netblock. That shit ain't cheap) McLean is also rather rigid on their definition of security. If there's no functional or business reason for a machine to have a \"real\" internet address, then there's no point in giving them one. Putting stuff out on the public internet because you can is stupid. I can shoot myself in the foot. That doesn't make it a good idea.\n\nThis paragraph:

Neither NAT nor an external firewall is really required when a computing system is property secured. The security crisis resulting from putting Microsoft's software, which was only ever originally designed to operate within an \"assumed to be secure\" LAN environment, on the open Internet has resulted in people thinking that PCs shouldn't be publicly addressable for their own good

is just fucking ignorant. Just because your box is \"properly secured\" doesn't mean it should be directly on the internet. Add the standard MacMac screed, and then dump this paragraph in the can as well.\n\nBasically, McLean is kind of ignorant of modern networking. Some other points:

One big feature is security: all IPv6 traffic can be encrypted via a built-in component of the protocol. There's no need to wrap the old FTP protocol with a layer of encryption or use SSH, no need to turn on SSL to secure the web, no need to encrypt each email or each IM conversation and each video conference. Everything can be encrypted at the network layer in IPv6 using IPSec. This can be automatic and invisible to applications; existing, higher level security protocols such as SSL or TLS require applications to be specifically designed to support them. With IPv6, apps get network encryption \"for free.\"

Translation: \"I have no fucking clue as to the other uses of encryption and SSL, but because I don't like them, I'll dismiss them as unnecessary thanks to the magic of IPv6.\" SSL is also used as a way to prove you are who you say you are, and that the other server is who it says it is. That has value far beyond encryption. \n\nAnother one:

However, a real barrier to wide adoption of IPv6 lies with the routers everyone uses; if they are unable to accommodate IPv6 traffic, they will prevent users inside from accessing IPv6 traffic outside, even if their OS supports it. Many commercial routers are just now adding support for IPv6, and many consumer routers don't support it at all.

Maybe that Linksys shit McLean uses is \"just now adding support for IPv6\", but the grownup routers have had it for some time.\n\nThis sentence however shows that McLean really has no clue about the world of networking beyond his home Wi-Fi cloud:

Routers typically run BSD or Linux; Microsoft's software dominance on the desktop isn't even relevant in the world of routers.

No, most routers run IOS, aka Cisco's router OS.\n\nIn short, this is a bunch of MacMac poofery from a lamer rumors site, and should not be taken seriously on any level. There's just too many instances of the author not having a fucking clue about the modern state of networking to take him seriously. AKA: Don't get your facts from a site that has no use for them.\n\n\n\n

Technorati Tags:\nAppleInsider has teh dumb\n