Comcast, the United States largest ISP, has a vested interest in IPv6. They've been posting their progress on a web-page:
http://www.comcast6.net/
For those wondering when they'll get a v6 capable ISP, and I know many of my readers are technically inclined enough to desire such, it is coming. I haven't dropped by the site in a while, it doesn't update much, but they did present at IETF recently and posted their slides. One slide-deck in particular is interesting.
Down on page 5:
NAT has been a network security 'best practice' for years. While firewalls provide robust network security, hiding the IP-space behind the firewall makes planning an attack on that IP-space take longer. A fact that has been enshrined in the PCI-DSS standards.
IPv6 NAT exists now, which it didn't shortly after IPv6 was ratified. The question remains over what addresses you use to replace the obsolete-in-v6 RFC1918 addresses we all know and love. The answer to that is one of two types of addresses:
Running 'in the clear' will be an absolute boon to server-in-the-home folks. Get a domain from registrar-of-choice and set up your DNS records to point to the server on your home /64 and away you go. Want to play with multiple web-servers? No problem! Everyone can use port 80 on their very own IPv6 address, no need to monkey with :8080 :8008 and so on. Of course, terms-of-service violations may get this behavior whacked, but I can guarantee it'll happen regardless of what the TOS forbids.
Whole suites of protocols and applications just plain work better when there isn't a NAT gateway getting in the way. Peer-to-peer networks of all kinds are a LOT easier to maintain without NAT. We're still years and years from a fully featured pure-v6 Internet experience, but I like the way it looks from here.
http://www.comcast6.net/
For those wondering when they'll get a v6 capable ISP, and I know many of my readers are technically inclined enough to desire such, it is coming. I haven't dropped by the site in a while, it doesn't update much, but they did present at IETF recently and posted their slides. One slide-deck in particular is interesting.
Down on page 5:
* Delegated prefix is minimally a /64 by default for trial (LAN-Ââ€side)That is a subnet being allocated to customers, not a single IPv6 address. Clearly, Comcast is leaving it up to customers to figure out if they want to use some kind of address-translation or just use straight-up public IPv6 addresses on their home network. This kind of thing is exactly what the authors of IPv6 had in mind, and not coincidentally is one of the biggest critiques of IPv6... the role of NAT.
NAT has been a network security 'best practice' for years. While firewalls provide robust network security, hiding the IP-space behind the firewall makes planning an attack on that IP-space take longer. A fact that has been enshrined in the PCI-DSS standards.
IPv6 NAT exists now, which it didn't shortly after IPv6 was ratified. The question remains over what addresses you use to replace the obsolete-in-v6 RFC1918 addresses we all know and love. The answer to that is one of two types of addresses:
- If your home network is completely flat, you only have one subnet, then Link Local addresses (fe80:/8) will work just fine. These addresses are explicitly non-routed, so a NAT gateway at the edge of the network is required.
- If your home network has multiple subnets, Unique Local addresses are what you want. Unlike Link Local, ULA's are routeable. NAT is optional, but your home-ISP is vanishingly unlikely to agree to route those addresses.
- Comcast is handing out a /64 subnet to you, so your attacker already knows what your IP space looks like.
- A /64 provides a mind bogglingly huge number of potential addresses. 2^64 worth! That's vastly, vastly larger than the entire 2^32 IPv4 address space. While the nature of IPv6 autoprovisioning reduces the actual number of addresses that are likely to be provided, scanning it is still very infeasible.
- Unless you set up your own domain to provide it, Comcast will not be providing forward or reverse DNS lookups to your /64-worth of IP addresses. This greatly reduces the ability of attackers to recon your network.
Running 'in the clear' will be an absolute boon to server-in-the-home folks. Get a domain from registrar-of-choice and set up your DNS records to point to the server on your home /64 and away you go. Want to play with multiple web-servers? No problem! Everyone can use port 80 on their very own IPv6 address, no need to monkey with :8080 :8008 and so on. Of course, terms-of-service violations may get this behavior whacked, but I can guarantee it'll happen regardless of what the TOS forbids.
Whole suites of protocols and applications just plain work better when there isn't a NAT gateway getting in the way. Peer-to-peer networks of all kinds are a LOT easier to maintain without NAT. We're still years and years from a fully featured pure-v6 Internet experience, but I like the way it looks from here.
"2^64 worth! That's two IPv4 Internet's worth of IP addresses."
Technically, it is an IPv4 Internet of IPv4 Internets' worth (2^64 = 2^32 * 2^32). Two IPv4 Internets would just be 2^32 * 2 or 2^33. Such a thing would undoubtedly only see us through another year or so of expansion at the current exponential rates.
ARG, exponent-fail! Take me back to... um... 7th grade!
PCI DSS requires NAT? I don't have a copy of the standard at hand but all I recall is that it requires a stateful firewall (which is not the same as NAT) and default deny for inbound AND outbound traffic. Can you cite which point in the PCI DSS specifies NAT?
As of the 1.1.1 version, which we had to deal with, section 1.3.7 was pretty clear that it required RFC1918 addresses. As of the 1.2 version, this is what it required:
1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).
Hard to get more clear then that. However, in October of this year and unbeknownst to me, they changed things. Not only is the document harder to read, but they clarified that section.
1.3.8 Do not disclose private IP information from internal addresses and routing information to unauthorized parties. Note: Methods to obscure IP addressing may include, but are not limited to: Network Address Translation (NAT) Placing servers containing cardholder data behind proxy servers/firewalls or content caches, Removal or filtering of route advertisements for private networks that employ registered addressing, Internal use of RFC1918 address space instead of registered addresses.
This newer version is a lot more IPv6 friendly. Our Telecom folk will be pleased with this.