Live data from Hacker News

Blockers to IPv6 Adoption

labs.ripe.net

91–100 of 154 posts

Re: Blockers to IPv6 Adoption

#91
post #70

Earlier quoted context omitted.

Pretty much, yes. Other security issues with random routers appear to be way more common.

EDIT: My mistake, see comment below.

This is the typical function on a consumer router: https://bt.i.lithium.com/t5/image/serverpage/image-id/53294i...

What do you see?

Re: Blockers to IPv6 Adoption

#92
post #82

Earlier quoted context omitted.

What percentage of IPv6-supporting routers have implemented and activated those privacy extensions?

It's a feature of the client device, not the router, and is implemented in all major operating systems. They are not perfect though, since at least the original design was purely timer-based, which left some tracking potential.

Thanks for the correction, and yeah, there you go.

Re: Blockers to IPv6 Adoption

#93

I see IPv6 as a privacy issue. It will enable clients to be individually identified without needing to rely on cookies and fingerprinting anymore. NAT is great in that it obscures individual machines without too much lose of functionality.

couldn't you get around this by wrapping all tcp/udp connections in an encrypted manner say a tunnel and using dns+tls to encrypt dns queries? Sure it's not as easy as just using NAT but not having to translate via NAT to get to the internet sounds good to me. Access points wouldn't need to route anymore would they?

Re: Blockers to IPv6 Adoption

#94
post #16

I've enabled ipv6 on my ubuntu server recently and it was 100x slower. The only solution I found is to go back to ipv4: https://askubuntu.com/questions/759524/problem-with-ipv6-sud...

That AskUbuntu question does not describe a scenario that is "slower". 0% progress and 100% packet loss is no IP connectivity, not "slower".

Re: Blockers to IPv6 Adoption

#95

I think the author is approaching this the wrong way, it's trivial to show the advantages listed are mostly not true. The marginal benefits are more than negated by the risks and costs of IPv6. IPv6 is not the product that needs to be sold, and deploying it usually has negative cost benefit on short term, for most businesses. IPv6 needs to be deployed today because the internet literally cannot move forward without i…

The IT director for a global corporation will care, once the bottom line is being effected and he will have to implement it. Profits will not be allowed to suffer.

Re: Blockers to IPv6 Adoption

#96
post #76
post #46

Earlier quoted context omitted.

Very weird, the Comcast consumer lines support IPv6 quite well. Their default is to give a /60, which seems appropriately overkill. Generally it "just works", and my roku, android phones, and similar average over 50% of the packets on IPv6. Comcast seems like one of the largest deployments of IPv6 for normal consumers outside of the cell companies.

> Their default is to give a /60, which seems appropriately overkill. A /60 is pathetically small, with SLAAC you have 16 (!!) subnets for your whole network. With people having multiple computers and multiple phones, this is not enough even for a normal household of 3 people. If you are a IT person, with multiple computers and VMs, forget it. The recommended size of block that every ISP should give is /48 (RFC 6177)…

On a business account you get a /56 and on MetroE you get a /48 or more. Given the huge majority of consumers only ever use a /64, giving a /60 seems reasonable.

Re: Blockers to IPv6 Adoption

#97
post #23

I wonder if anyone has tried making their home network IPv6 only? How did that work out for you? The reason I ask is (as described in the article) I've nearly run out of RFC1918 space because of dozens of machines, gadgets and many more virtual machines. (For complicated reasons to do with the VPN routing, I cannot use 10.x).

Quite a few folks have done it using DNS64/NAT64, I might set it up. Most of my traffic is IPv6 at home.

Re: Blockers to IPv6 Adoption

#98
post #89

Earlier quoted context omitted.

EDIT: My mistake, see comment below.

Interesting. Name and shame a few brands/models? That stuff needs to be widely warned about.

You know, I really have to apologize, because it seems I missed a critical detail that changed the entire story. Thanks to both of you for making me go double-check.

What happened was I vividly recalled seeing "stateless" as the default option for the router I had in mind over a year ago. Which was indeed correct. However, in response to the other comment I went back and checked again, and just noticed that "stateless" was in fact under the NAT page, not the firewall. The IPv6 firewall page is rather hidden so it's something I forget about completely, as I don't use IPv6. Looking there, the firewall page indeed does say it blocks unrelated input traffic by default.

This wasn't the entire story though, because I could also remember that ip6tables -L was empty when I checked it. I now see, though, that this must have been because when I had done this check, IPv6 was turned off, and that made the router purge all the rules. I had always assumed it was never setting them up in the first place.

Frankly as of right now I can't really verify what actually happens because I don't immediately get an IPv6 address when I enable it. I trust it does what you say. That said, I'm still not sure how I could rely on this fact being true everywhere. With IPv4 it's pretty much a given that you will hit a NAT due to the lack of enough IPv4 addresses, but with IPv6 they could easily assign you an IP address, so what guarantee is there that the router has things set up this way? It still seems like a risk vs. no-risk, with the same resulting decision.

Re: Blockers to IPv6 Adoption

#99

Earlier quoted context omitted.

EDIT: My mistake, see comment below.

This is the typical function on a consumer router: https://bt.i.lithium.com/t5/image/serverpage/image-id/53294i... What do you see?

Thanks for asking; you made me realize this was my mistake -- please see: https://news.ycombinator.com/item?id=17345328

Re: Blockers to IPv6 Adoption

#100

Earlier quoted context omitted.

This, whilst technically correct, isn't necessarily end-users experience of things. Yes NAT doesn't block packets, however without explicit configuration traffic from the Internet will be very unlikely to flow into an RFC1918 addressed network from the Internet. So effectively it does prevent traffic inbound in the same way a firewall does. Yes you can punch holes in NAT, but that's an explicit action (well side-step…

You can achive precisely 100% exactly the same functionality with a firewall without NAT, indeed you need that sorta functionality to implement NAT to begin with. All you need is a default deny inbound traffic rule, this isnt some kind of arcane thing that is so much harder than NAT for end users.

Of course you can, the point I was making was that NAT provides effectively the same outcome, not that it wasn't possible with a firewall.
Post reply on HN