Comcast had been somewhat unstable for me since they rolled out IPV6 in my area. Before that 4 years of being rock solid.
On the bright side - dual stack indeed works, even though neither IPV4 nor IPV6 can keep ping going without dropping any packets for more then few minutes.
I think last time I checked SNR was close to perfect, with nothing interesting going on in the cable modem logs (I will definitely double check tonight). I got SB6141, so DOCSIS 3 is a go.
It's too bad that other providers are not offering this yet. For example, my provider says:
> At this time Optimum is not providing IPV6 addresses. In the future we will support users wishing to connect to IPv6-only sites. Currently, web site operators today are compatible with both IPv4 and IPv6 to ensure their sites are reachable by everyone. When IPv6 becomes the standard, which currently it is not, we will provide support for it.
If you don't have native IPv6 yet, ask your ISP why!
Because to traverse that NAT, you need to either forward ports manually in your router (one of those activities that seems second nature to techies but is obscure to everyone else) or use UPnP (an ugly, insecure hack). IPv6 solves the need to resort to this.
How is UPnP more insecure than having a publicly routable IP address? Assume that the machine running UPnP behind a NAT and the machine with the publicly routable IP both have correctly configured firewalls.
Define correctly - most consumer routers will respond to a uPNP forwarding request from anywhere - what if that's a Java applet running on a compromised ad network?
So what if it is? Even if the uPnP daemon on that router is so broken that it responds to requests from the WAN that configure forwarding rules for machines on the LAN, how is this less secure than having a publicly routable IP for every one of the machines on the LAN?
To answer your question, assume that "correctly" is at least as secure as the default Windows Firewall configuration (with user-entered exceptions for video games and whatnot).
A java applet can make the request from your LAN IP, and forward whatever port to whatever other port - as well as whatever other odd features are baked into the uPnP daemon.
Anyway, the advantage for a developer is that we no longer have to do silly NAT traversals and deal with broken/incomplete NAT implementations.
Security, as always, is left as an exercise to the reader. You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with.
Not having to deal with a NAT is a godsend. I know. I've had a block of publicly routable IPv6 addresses for five or eight years now.
I notice that you haven't addressed the question I asked in the first comment of mine that you responded to, and again in the second comment. I effectively asked "How is uPnP more insecure than giving the machines on your LAN publicly routable IP addresses?". I've heard people say that uPnP is insecure, but I haven't heard anyone back up that assertion with any information. Even something as weak as anecdata! I asked the question that I did in order to understand the reasoning behind that assertion.
> You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with.
I don't. I'm curious, which one you'd rather deal with, and why?
> I've heard people say that uPnP is insecure, but I haven't heard anyone back up that assertion with any information.
uPnP as a spec doesn't seem to have any security (authentication/authorization) baked in. I'd find you a reference from upnp.org but they're making it difficult to search.
Even with a good implementation, if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like.
I know, I've accepted the risk too by keeping uPnP turned on in my network.
> You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with.
I don't want to deal with any more NAT implementations. It wasn't so long ago that the size of the tables on consumer-grade routers were small enough that BitTorrent et-al would fill the NAT & TCP tables and cause disconnections or router crashes.
NAT is a hack and we should be moving away from it.
Thanks for providing some information. I'm aware that uPnP is a large standard. Frankly, the only parts of the spec that I or any software that I run cares about are Service Discovery and IGDP.
> ...if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like.
Yes and no. The uPnP daemons that I've worked with are based on miniupnp. They all have a setting that only allows a machine to forward ports to itself. Other uPnP daemons might not have such a setting.
> I know, I've accepted the risk...
What risk? I'll ask yet again. :) How is having an automated port forwarder (even one that will forward any port to any machine on your LAN for any reason) more risky than having a publicly routable IP address assigned to each and every machine on your LAN?
If you've already answered this, I apologize for not catching on.
> NAT is a hack...
So you'd rather manage firewalls and/or running services? That's the path that I like best.
EDIT: I've read Rapid7's report on the miniupnp & etc. vulnerabilities that they found. The fun thing there is that they found implementation bugs. The issues that they raised have nothing to do with uPnP itself.
Although the ipv6 addresses are all technically globally routable, my (ISP-provided) router defaults to not routing new incoming connections through to addresses on the LAN. Outgoing TCP connections work fine. So in effect you get the same security as NAT.
Given the quality of MSFT's and Apple's firewalls, and the ease of use of MSFT's (I assume Apple's is easy to use, but I have no direct experience), I cannot agree that a default DENY firewall policy is a good default configuration. We'd be back in the world where consumers would need something uPnP to manage firewall rules on their router.
I can agree that refusing to route requests to things like port 445/tcp is reasonable.
It's definitely not ideal (blocking end-to-end routing defeats a lot of the point of IPv6) but i understand the security POV. It is straightforward to change, about the same complexity as forwarding a port was on IPv4 (click around in web ui for a minute or two).
The router is an AVM FritzBox 7340, the ISP is Snap (New Zealand).
I have no idea if this setting is common or not for IPv6 deployments.
Thank you very much for the information. I, too understand why that would be the default configuration. It's very good to hear that it's not a pain to change.
Do you know if you can set that FritzBox up to just act as a DSL->Ethernet bridge and pass through packets to another device that does all the routing? (Sorry if that doesn't make sense. I'm not a professional network nerd, so my terminology might be confused.)
I know, a /64 isn't a /56 or even a /48 like they should be handing out, but it's a far cry from a /128. Where are you seeing /128s being handed out? Are you sure that your router isn't misconfigured in some way?
If you're basing your information on the info here: http://www.comcast6.net/index.php/ipv6-deployment-faq do know that it's out of date. The bug mentioned in Toastman and Shibby builds has been fixed for quite a while. (Indeed, I'm running unmodified Shibby on my router [with some firewall rules to patch over some crappy daemon interface binding decisions that the guy made.].)
EDIT: agawa reports that Comcast is handing out /60s. I'll play around a bit with my network this weekend and see what I've misconfigured/misunderstood.
So, it looks like I can ask for a /60, and I get offered a /60 and a /64. (I can ask for a /61, and I get offered a /61 and a /64.) Unfortunately, the /64 is offered with a higher priority, so the router uses that.
A thread on dslreports.com indicates that this might be because I had a recently released lease on the /64, so I'm gonna release the lease for three or four days to see if that will fix the issue.
Lets ask the other question too: why do I not want IPv6?
It seems to me that NAT serves a very useful role in terms of helping to hide information about your internal network (the devices on that network, their roles and activity, etc).
I'm not well versed in IPv6 address assignment or Comcast's setup, but IIRC there are scenarios (SLAAC?) where IPv6 IP Addresses include an Interface Identifier that is derived from the manufacturer assigned hardware address. Which would allow a device's activity to be tracked over time and across the different networks it connects to. Which can reveal information about the type of device and potential vulnerabilities (to those who have access to the hardware address assignment database). Which can even reveal information about who purchased the device (to those who have access to purchase records that contain the device's hardware address).
Anyone who's rolled out IPv6 on a large internal network or public facing site, why did you bother? Right now it seems like more work and complexity for exactly zero benefit.
- IPv6 multicast addressing is a real boon on an internal network; the ability to address entire classes of nodes with one address.
For example, in IPv4 how would you implement a quick all-routers heartbeat script? In IPv6, just ping ff02::2.
- Multihomed hosts are a cinch ( scope identifiers make it easy ), and inversely so are unihomed hosts with multiple addresses. No messing with virtual interfaces like IPv4 requires, just bung another IPv6 address onto the interface. I have some hosts with > 10 addresses on one interface, each aligned to a particular service.
- Link-local addressing just works without any need for messing with DHCP and ARP like IPv4 requires. A new client joins the network, immediately generates a LL address and is addressable, all without external assistance. It's beautiful.
- Router Advertising in my experience has proven much more reliable than DHCP, and much faster. There are still some issues with rogue RAs, however.
Once I noticed that Comcast was IPv6 enabled in my area switching it on was as easy as checking a couple of boxes in my airport express. One was to enable IPv6 and the other was to block incoming IPv6 connections.
I have not noticed any issues since enabling it. Dual stack seems to work well. As browsers seem to choose whichever is faster I have seen some behaviour where Google thought I was accessing gmail from multiple locations at the same time when infact I had switched from IPv4 to IPv6.
Funny thing is, this site runs behind Cloudflare, where IPv6 is available by checking one box. Although that will cause IPv6 addresses to appear in the CF-Connecting-IP header, so perhaps the devs can't figure out how to manipulate them, or they just don't care.
I think IPv6 is similar to XHTML. Not backwards compatible with no clear benefit for most users. I'll wait for what follows (HTML5), or at least wait as long as I can.
It's not going to play out like HTML5. There was no real urgency to replace HTML4, so we could wait until something better than XHTML came along. The IPv4 address shortage is urgent, so we're going to have to use one of solutions available now, which is either IPv6 or carrier-grade NAT. IPv6 may have its flaws, but carrier-grade NAT is far worse. While an ordinary user might not see the difference, website operators certainly will, since carrier-grade NAT makes it impossible to track and block abuse (without substantial collateral damage).
I imagine that HN uses IP addresses extensively for bans and voting-ring detection. Already, some ISPs (e.g. T-Mobile) are giving users public IPv6 addresses and private IPv4 addresses that are NAT'd. In order to distinguish between different users of these ISPs, HN would need to support IPv6.
Other ISPs are worse and are just doing carrier grade NAT without IPv6 (mainly in Europe/Asia, though Verizon has announced they will start doing this to some of their DSL customers in the US). For these users, HN supporting IPv6 would do no good, except to show to these ISPs that there is a point to them deploying IPv6. (Yes, one site is just a drop in the ocean, but if everyone did their part and adopted IPv6...)
Meanwhile, Charter cable's IPv6 page hasn't been updated in over a year, including hints at business test deployments in Q42012. I'm sure there is someone behind the scenes working on it, but nobody I have asked (I'm a fiber business customer) seems to know who to talk to, or when its getting rolled out.
Currently ~2.53% of traffic going through Google is over IPv6. Adoption Rates: