Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blockers to IPv6 Adoption

labs.ripe.net

Post reply on HN
Print view View original

31–40 of 154 posts

Re: Blockers to IPv6 Adoption

#31

Post by andrewaylett »

guidedlight wrote: post #24

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.

https://tools.ietf.org/html/rfc4941 defines IPv6 privacy extensions, which mitigate that issue.

One of the few benefits of an extended roll-out of IPv6 is that there's been time for people to identify issues like this and get fixes rolled out widely before systems started relying on the old behaviour.

Re: Blockers to IPv6 Adoption

#32

Post by atemerev »

Of course it is the NAT. It always was the NAT. NAT is the easy thing, nearly effortless, that dramatically improves network security — there is a "bastion host" (router) and private network computers, almost impossible to be accessed from the outside without breaking the bastion host first. This is good security, and with NAT, everybody was getting it for free. With IPv6, it doesn't work this way, everybody needs to know how to set up proper packet filtering, ACLs, and whatsnot. It is really easy to misconfigure the network, especially in the unfamiliar environment which is IPv6. Huge loss for security. Of course IPv6 adoption suffers.

Re: Blockers to IPv6 Adoption

#33

Post by mort96 »

y0ghur7_xxx wrote: post #14

I deployed a dual ipv4 + ipv6 stack on my home lan a few years ago. I got myself a /48 from hurricane electric, and did everything like it's in the book: SLAAC for subnets, fixed addresses on servers, every device had a public ipv6 and the firewall allowed or denied stuff. Everything worked as it should work. One day something stopped working on the he tunnel, and as I was about to debug what went wrong, I just asked…

"You can have a gazillion IP addresses with IPv6" isn't necessarily that interesting, but "You can have one IP address with IPv6", or "You can have on IP address per device with IPv6", or "You can get rid of NAT with IPv6", are very interesting.

Re: Blockers to IPv6 Adoption

#34

Post by okket »

atemerev wrote: post #32

Of course it is the NAT. It always was the NAT. NAT is the easy thing, nearly effortless, that dramatically improves network security — there is a "bastion host" (router) and private network computers, almost impossible to be accessed from the outside without breaking the bastion host first. This is good security, and with NAT, everybody was getting it for free. With IPv6, it doesn't work this way, everybody needs to…

Actually, I don't know one CPE IPv6 router that ships _without_ blocking the home network from the outside by default.

Re: Blockers to IPv6 Adoption

#35

Post by kazen44 »

jjeaff wrote: post #10
kojon99 wrote: post #7

Performance? How exactly is ipv6 more performing? It even has bigger headers. Why would ipv6 be more reliable than ipv4? I’d say it’s the opposite: many times I’ve found websites with AAAA registers that pointed to a dead server. I mean, if you’re going to blame cgn for your problems, let’s steep to your level. Analytics? Forensics? So you’re telling me ipv6 destroys my privacy. How is that a pro argument?

I'm by no means am expert in this space, but I was working on some routing issues lately and doing some speed testing with my router. The specs on the router claimed that the highest speeds could be reached with ipv6 support because you could then avoid the overhead of nat for your ipv4 addresses. So that may be what they are referring to. Nat does create overhead.

Also, it has a simpler checksum to calculate and a far simpler header. The header is larger but has far less fields. This should make packet processing faster aswell.

Also, MTU path-discovery is a pretty big deal in terms of performance, as IPV6 does not allow packet fragmentation. Which should improve performance aswell.

Re: Blockers to IPv6 Adoption

#36

Post by 4ad »

lwhalen wrote: post #17

Comcast is my biggest blocker to IPv6 adoption. I maintain a static v4 block with them, they tell me I have to give that up if I want a v6 block. Until I give up v4, v6 works on my network right up to the Comcast modem, and is promptly dropped on the floor. Regrettably, that is 'no bueno' for a multitude of reasons. :-(

Here in Vienna, the "local Comcast" started deploying IPv6. However, they stopped providing real IPv4 for IPv6 customers, and instead do CGN. Well thanks, but no thanks.

Re: Blockers to IPv6 Adoption

#37

Post by kazen44 »

y0ghur7_xxx wrote: post #14

I deployed a dual ipv4 + ipv6 stack on my home lan a few years ago. I got myself a /48 from hurricane electric, and did everything like it's in the book: SLAAC for subnets, fixed addresses on servers, every device had a public ipv6 and the firewall allowed or denied stuff. Everything worked as it should work. One day something stopped working on the he tunnel, and as I was about to debug what went wrong, I just asked…

IPv6 brings some pretty nice features in terms of network engineering.

the major one is a vastly smaller BGP routing table, which is becoming more and more of an issue.[1]

We need IPv6 to remove the horrible IPV4 space fragmentation.

http://bgphelp.com/2017/01/01/bgpsize/

Re: Blockers to IPv6 Adoption

#38

Post by skrause »

atemerev wrote: post #32

Of course it is the NAT. It always was the NAT. NAT is the easy thing, nearly effortless, that dramatically improves network security — there is a "bastion host" (router) and private network computers, almost impossible to be accessed from the outside without breaking the bastion host first. This is good security, and with NAT, everybody was getting it for free. With IPv6, it doesn't work this way, everybody needs to…

It's actually just as easy with IPv6. All you need is a stateful firewall which allows all outgoing connections and only allows incoming packets for already established connections. This was the default setting on my home router and behaves exactly like a NAT.

Re: Blockers to IPv6 Adoption

#39

Post by kelnage »

m0dest wrote: post #22

Decades from now, the story of IPv6 will be a cautionary tale about the danger of ignoring incentives when enhancing open standards. So much of the spec seems to have been designed in an idealist vacuum that the promoters are blind to its own failures. The addresses are ugly and impossible to memorize but that shouldn't matter because... There are no performance advantages but that was out of scope because... There a…

Isn't the same true of HTTPS (first developed in 1994, but has only seen wide usage recently, outside of specific use-cases), or even programming languages like Python 3? At the end of the day, it seems to me that incumbent internet technologies that are widely used will always see slow incremental change to a new incompatible version, regardless of how small the changes or how many improvements there are, without significant and clear external incentives. Such incentives are very hard to manufacture - so foresight of upcoming issues (such as IPv4 address space depletion) will always seem premature until they actually occur. But it certainly doesn't make forward planning a bad idea.

Re: Blockers to IPv6 Adoption

#40

Post by atemerev »

okket wrote: post #34
atemerev wrote: post #32

Of course it is the NAT. It always was the NAT. NAT is the easy thing, nearly effortless, that dramatically improves network security — there is a "bastion host" (router) and private network computers, almost impossible to be accessed from the outside without breaking the bastion host first. This is good security, and with NAT, everybody was getting it for free. With IPv6, it doesn't work this way, everybody needs to…

Actually, I don't know one CPE IPv6 router that ships _without_ blocking the home network from the outside by default.

It is easy enough with home routers (packet filtering is hidden from the user, and no need to configure it). It is much harder for corporate networks where you need to configure everything yourself and maintain ACLs. No more easy default option.
Post reply on HN