>When IPv6 becomes the standard, which currently it is not, we will provide support for it.

Except that it won't become the standard if nobody adopts it.

I never said it was a good reason :/

Why do I need or want native IPv6? Everything works fine on IPv4 NATed behind my home router.

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.

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.

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.

That's (IMO) pretty terrible default behavior.

1) Is it easy for a somewhat technical person to change? 2) If you don't mind telling, who's your ISP?

There's an IETF standard that says IPv6 home routers should have a default deny firewall. http://tools.ietf.org/html/rfc6092#page-15 Some people are trying to get it changed: http://tools.ietf.org/html/draft-v6ops-vyncke-balanced-ipv6-...

Both of those are Informational documents, not Standards. :) Documents like this one are Standards: http://tools.ietf.org/html/rfc2616

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.)

Since Comcast is handing out /128s, now you get to enjoy the thrill of IPv6 and NAT!

I don't know where you are, but I'm a Comcast customer in San Francisco.

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.

Comcast should give you up to a /60 if you ask for it, no matter where you are:

https://secure.dslreports.com/forum/r28725662-IPv6-ALL-areas...

Indeed, I can get a /60 here in the Bay Area.

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.

I released the lease for two, three days and I now have a /60. Yay!

I'll try to play around with my network this weekend. It might be mis-configured, or I might just be stupid.

Thanks much for the information!

I'm getting a /64 on my airport express. I do subscribe to blast plus, however I have never contacted comcast about ipv6

indeed, i assumed they were handing out a /128 because their ipv6 faq said they were handing out a /128.

I really wish that they would update that FAQ. :/

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).

> When IPv6 becomes the standard ... we will provide support for it.

Here's a standard you can refer them to: http://tools.ietf.org/html/rfc6540