Comcast’s Xfinity Internet Now the World’s Largest Native IPv6 Deployment
corporate.comcast.com
corporate.comcast.com
Currently ~2.53% of traffic going through Google is over IPv6. Adoption Rates:
Belgium: 4.1%
Peru: 4.26%
USA: 4.88%
France: 4.91%
Germany: 5.24%
Romania: 7.63%
Switzerland: 9.47%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.
Also, do you have a DOCSIS 3 modem?
> 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!
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).
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.
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?
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.
As an implementation - have you had a look at any firmware from consumer-level routers recently? Sorry, more anecdata. The only flaw I can remember is http://upnp.org/news/documents/UPnPForum_IGDSecurity_PressRe...
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.
> ...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.
1) Is it easy for a somewhat technical person to change? 2) If you don't mind telling, who's your ISP?
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.
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.)
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.
I have a /64 assigned to me through Prefix Delegation ( http://en.wikipedia.org/wiki/Prefix_delegation ). My router talks to Comcast's router over a link-local address.
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.
https://secure.dslreports.com/forum/r28725662-IPv6-ALL-areas...
Indeed, I can get a /60 here in the Bay Area.
Thanks much for the information!
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.
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).
Except that it won't become the standard if nobody adopts it.
Here's a standard you can refer them to: http://tools.ietf.org/html/rfc6540
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.
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.
$ ping6 news.ycombinator.com
unknown host
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 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...)
in terms of percentage deployment, Google Fiber is at #4 with 67.05% .