Comcast begins IPV6 deployment | Hacker News Reader

Comcast begins IPV6 deployment

blog.comcast.com

104 pointspwg55 comments

IPv6 is going to open a floodgate of innovation. All kinds of things are going to become so much easier to develop and more robust without the Internet-breaking devil incarnate known as NAT.

Like what?

Well, companies selling firewall software are going to have a great time.

Voice of IP is going to be simpler. No longer will Skype have to punch holes in the firewall/NAT using various different tricks to do bi-directional communication. Since this takes advantage of the fact that everything is routed it is going to be simpler to open up devices to the outside world without having to worry about having the right ports forwarded. Setting up a game server to play with friends is going to be simpler. NAT no longer standing in the way will help with VPN.

NAT traversal was always a pain the behind...

Because every device is setup in a super secure manor that it can be on the Internet? Let's not kid ourselves devices will sit behind firewalls for quite a bit longer

Sure, devices can sit behind a firewall and I highly suggest implementing a border firewall anyway, but in the long run it will be easier. Devices can still use UPnP to dynamically ask the border firewall to open up ports, and instead of having a finite number of ports because of a single IP address that is being used to NAT now each device behind the firewall could technically ask for 65535 different ports to be allowed through the firewall dynamically.

Now Bobby can run his game server on port 2275 and Billy can run his game server on port 2275 both connect to the same cable modem, and each will be able to get their own traffic routed to them.

Stateful firewalls and NAT are distinct concepts. We can and will be using stateful firewalls long after we kick NAT to the curb.

One way to think of NAT is that it's a hack to IPv4 that uses the port field to add an additional two-bytes of ephemeral IP address space, resulting in 48-bit addresses.

You get a lot more than 2 bytes, because your NAT tables can map both sender and receiver (IP, TCP port) tuples to a connection.

How does that work? You add two bytes to the address and somehow that makes the address longer by more than 2 bytes?

His point is that full-blown NAT/PAT is really 2 + 4 + 2 = 8 bytes on top of the base IP address for your system.

The tuple for a connection is:

source IP = 4 bytes

source port = 2 bytes

dest IP = 4 bytes

dest port = 2 bytes

For 12 bytes, or (in theory) 96 bits of ephemeral address space.

Okay, but I don't see how that increases the address by more than 2 bytes. Without NAT, you've got 4-byte addresses. The source/dest tuples have an 8-byte space, but each IP address is only 4 bytes. If the tuple space for NAT is 12 bytes, then each address is 6 bytes, or 2 bytes larger than without NAT.

It doesn't seem very meaningful to talk about tuple space, because we don't assign a tuple to each host. If we had 2^8 addresses, we wouldn't be nearly so worried about IP address exhaustion. But we don't have 2^8 addresses. We have 2^8 tuples.

You could have multiple hosts on the internal network appear to the outside world as the same (IP, TCP Port) tuple because they are connected to external different addresses.

To illustrate, let's say my network's external IP address is X. Let's choose some port number Y. A packet addressed to X:Y could be going to any one of several machines on my internal network, because the NAT uses the source (not just the destination) as part of its lookup. So X:Y does not uniquely identify a machine... it's only part of the total address.

Ah, I see what you mean now. Thank you for clarifying.

All routers that I interact with support port forwarding via UPnP so applications can open ports themselves. For example, BitTorrent clients like Transmission use this to set up port forwarding automatically.

The challenge will be in networking the enterprises that have decided to deploy RFC 4193 internally (and there are a lot of them), and are only deploying globally routable IPv6 addresses outside their firewall.

Interesting rollout strategy. The people that connect one computer directly to their router don't seem like the kind of people that would care about IPv6. But starting small is better than not starting at all, and this is a great move. Someday my house will have a /48 without requiring any tunnels :)

They're minimizing the number of variables in the initial deployments. DHCPv6 only, no third-party gateways. Massively reduces the number of things that can break.

Comcast has been working on IPv6 for years, and they've got senior technical people who know it inside out, but it needs to disseminate throughout the organization all the way down to the front-line support people. That's going to be hard enough even before third-party gear is brought into the picture.

For the first step of their rollout, having few people actually using it is probably a bonus, not a problem. Start small, then work up.

That demographic also includes people who run their own routers for their home network. My modem issues a single IP to a gateway box of my own, for example.

Nope. Comcast is dual-stacking, that means no tunnels and no gateways. This initial deployment is a single IPv6 IP to one physical computer running either Windows Vista, Windows 7 or OS X Lion. It's an initial end-user modem test and will keep the external variables to a minimum.

How do they know that single computer isn't doing DHCP/NAT for other computers? Are they doing nmap OS fingerprinting and banking off the assumption that people using Windows/OSX wouldn't be doing that, but people using Linux might be?

NAT basically doesn't exist in the IPv6 world. Realize that Comcast is optimizing for the 95% of their customer base that just wants something to work. Clearly their will be another 5% that will always go off the beaten path - and will likely be responsible for their own support.

I understand that. I'm wondering how Comcast would be able to selectively roll this out. How do they know the person who has a single computer connected directly to the modem doesn't have more computers behind it? Since they would currently be using IPv4, I would say NAT is a very real possibility.

There are two perspective here. One is what Comcast is prepared to support - and they've identified a minimally useful environment, that allows them to start off slowly, and eliminates as many possible variables from the equation as they can. No /48 routing, (no routers on the CPE at all), no proxying, no RFC 4193, no stateless auto configuration, no 4941 privacy extension. That is from the perspective of Comcast and what they'll support.

Then, there is the perspective of what the end user can do (with or without telling comcast) - obviously, in the IPv4 case, you can PAT/NAT to your heart's content, and Comcast will be none the wiser.

So - depending on whether you want to stay within the confines of what Comcast is "officially" supporting, or working with the realm of what you know will work - you may or may not want to NAT4 (I personally would have no problems doing it)

Which brings us back to the question of IPv6 - I don't think there is any mechanism to allow multiple hosts to hide behind a single IPv6 address, so, from that perspective, the "What will Comcast support" and "What will I do" - turn out to be the same perspective. :-)

You can run NAT using IPv6 without issues using OpenBSD's pf firewall for example, so yes, you can "hide" multiple hosts behind a single IPv6 address.

There aren't any widely deployed standards for NAT66. There are some drafts and ideas, but nothing commercially standard. I'd be hesitant to trust these implementations. You're better off using a firewall than a half-baked IPv6 NAT at this point.

I was simply pointing out that an implementation exists. Whether it is complete or not I can't speak to because I haven't used it. Although, I do tend to trust the OpenBSD crew when it comes to implementing functioning code.

This is correct. More specifically, Comcast will be using 6-to-4. If you're wondering if your router is compatible, Wikipedia does maintain a reasonably up-to-date list of known compatible routers: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_r...

The weak link of Comcast for a while was their lack of not providing IPv4 forwarders on IPv6 DNS servers. Many public DNS servers (including Google DNS) are also in the same boat.

On a somewhat unrelated hardware note, Comcast actually supports IPv6 on the Motorola Surfboard 6121, contrary to what their compatibility list suggests. The 6121 is simply a revision of the 6120, and typically they provision 6121s as a 6120 with 6120 firmware.

I think 6to4 is over; it's time for native dual stack.

Does this mean I’ll finally, finally be able to get a static IP (albeit an IPv6 one) for my apartment? Or are they going to ultimately pull some obscene perversion out of their hat whereby you have to pay stratospheric business-class rates to actually get an IPv6 address, and their justification is because it comes bundled with an infuriating potpourri of cut-rate “business-class” nonsense that no one wants (web hosting, email, etc.)? The fact that I can’t just pay $10/month (or whatever) for a static IP on my residential broadband connection is so exasperating.

It's Comcast, how do you think it's going to work?

Static vs. dynamic is orthogonal to IPv6. I would expect that "residential" service will continue to use dynamic addresses for the foreseeable future.

Wasn't one of the reasons for the deployment of dynamic IPs to residential users (as opposed to LAN environments) the reduced number of IPs required, since you'd have a pool all clients could share?

IPv6 doesn't have that problem, and it seems to me that keeping them fixed is probably cheaper in terms of billing and accountability.

Perhaps that was the original goal, but now-a-days its pretty rare for a customer to turn off his or her modem, so its unlikely a customer would ever give up an ip address that could be used by someone else.

If pooling was the true original reason for dynamic IPs, it usefulness for that purpose has already passed, regardless of IPv6.

They'll do whatever is cheaper and then they'll tell you it's dynamic (or "not guaranteed to be static") as an incentive for some customers to upgrade to business service.

I could definitely see scenarios where you end up connecting to a different CMTS and thus it's cheaper for them to assign a new prefix rather than carry your old prefix in their IGP. Or something like that.

It depends.. if they're issuing /64's, they're actually issuing networks, not host addresses anymore. I'd rather not have my entire network be renumbered every 6 hours when my DHCP updates.

So now we just need a stateful ipv6 dhcpd in something like TomatoUSB. Someone has probably already done that.

I want to get in on this. Even if I can only get a single IPv6 address on my gateway I can do NAT6 on my internal devices without an issue.

The questions I need to go find answer for are:

1. What do I need to do for Comcast to give me an IPv6 address? 2. What for my FreeBSD gateway do I need to modify to do DHCPv6 (stateful)? 3. What modifications do I need to make to my Firewall rules that currently assume NAT? 4. What is the easiest way for me to take the /64 and split it up so that even my test virtual machines now have direct accessible IP addresses (currently adding static routes using DHCP, which is a pain in the behind!)? 5. Start verifying that all internal devices that are requesting IPv6 and are using IPv6 are also fire-walling it correctly and all services are prepared for it. I can firewall at the border (gateway) at the moment, but eventually I don't want to police that traffic. 6. How will this interact with my IPv4 10/8 network I have set up? 7. What legacy devices are on my network that do not speak IPv6? 8. How does this change services that broadcast themselves widely and freely (looking at you mDNSResponder, Samba, UPnP media servers)?

These questions are just the ones I can think of at the moment. It is going to be interesting to see how this all works out, and I feel like I am going to have to learn networking all over again.

Don't waste your time with #1. It's limited to systems running either Windows Vista, Windows 7 or OS X Lion. It's a test for the premise modems. It makes sense for them to do this a first time roll out to test the systems and support personnel.

However, it's an excellent time to make sure you can answer all your other questions.

They don't need to know what I am actually running. Each time I have had to call tech support they always ask me what router I am using, and I tell them it is a stock Linksys router. I can just as easily claim that I am running OS X Lion (which I am, just not directly on the cable modem)...

Please don't do this. They're doing these tests in a specific order, in specific markets, with specific people for a reason.

Assuming he's a big boy and can handle his own networking issues, I don't see why him doing this should effect their testing.

Because they want to test dual-stack. That means a real IPv6 address to each and every device. By only giving out a /128 you can't get a real address to all the devices behind the router.

So long as he doesn't call up tech support and complain when something doesn't work, I don't see what the issue could be.

What exactly about "minimization of variables" do you not understand?

What makes you think I don't understand the concept?

Edit: If I am off here, I want to know.

Comcast was doing "tests" for a long time in a variety of forms across the country. Those tests are over and have been for a while. This is gradual but very much live deployment, albeit with a limited enabled "feature set".

"Even if I can only get a single IPv6 address on my gateway I can do NAT6 on my internal devices without an issue."

Can you say a bit more about this? I haven't actually seen any implementations of NAT that will allow you to do NAT/PAT for multiple internal IPv6 hosts onto a single external IPv6 address. Does such a thing exist? If I were asked today, I would say "No." - but I clearly could be wrong.

I am using OpenBSD's pf firewall and you can specify IPv6 addresses the same way you would IPv4 addresses for NAT, so I could translate many internal IPv6 addresses to a single outside IPv6 address without issues.

I can do NAT66 on my internal devices without an issue.

Except the issue of doing IPv6 completely wrong.

Sure ... but it is a simple stop for testing purposes. I already run a test network on IPv6 (only, no IPv4) that is using internal only IP addresses much like 10/8.

Publicly-facing websites not v6-enabled, yet: http://ready.chair6.net/?url=comcast.com http://ready.chair6.net/?url=comcast.net

"As the world gets faster, it turns out that the glacial changes of years and decades are become more important, not less." -- Seth Godin (http://sethgodin.typepad.com/seths_blog/2010/08/resilience-a...)

I can't believe no one else has hit on this yet... They're limiting the number of IPV6 ip's per home to 1. They want to be able to offer a UNIQUE IP to EVERY DEVICE in your home. How long until there's a CHARGE PER DEVICE? =\

From the article: "When we begin our support for home gateway devices late this year, we initially plan to use a default IPv6 prefix allocation that is a /64 in length, providing over 18 quintillion IPv6 addresses."

Reply on news.ycombinator.com