Live data from Hacker News

Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

seam.cs.umd.edu

51–60 of 60 posts

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#51
post #46

Earlier quoted context omitted.

V6-V6 sure, that doesn't need nat. It's the V6->V4. NAT is preferably to dual stack. I don't want to double my administration efforts by maintaining a v4 and a v6 network on every machine and every router, which appears to be best practice. Let me deploy v6, and only v6, but still interoperate with v4 until everyone has migrated. As for nat being a cludge, lets assume I have a simple small office network with two ind…

What I've been told is both ISP's v6 prefix should be advertised with different priorities to the clients, which also yields the net bonus that applications that are stateless (UDP) or use MP-TCP can seamlessly fail over or adapt to network conditions without the intervention of another network device. I don't have easy access to multiple V6-PD enabled providers to test this theory, and as someone with quite the neck…

> What I've been told is both ISP's v6 prefix should be advertised with different priorities to the clients

That basically doesn't work with real clients. They'll do dumb stuff like use address from provider A to send through the router advertising addresses from provider B. And take forever to do anything in response to prefixes that are advertised as no longer usable or simply no longer advertised.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#52

Earlier quoted context omitted.

I think it could be argued that the flaws in IPv6 are significant enough to result in an scenario where IPv4 is never actually retired and therefore IPv6 is never fully adopted. Its been decades, but still IPv6 is deployed (at best) as a parallel network that effectively doubles management/maintenance overhead. And at worst sites just add an IPv6 reverse proxy.

What do you think are the biggest flaws in IPv6?

I've been advocating for this for a long long time. Just NAT to IPv6 or IPv4 and go about your business.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#53
post #6

What is the rational reason, if any, for bringing up things like these? The time to have this discussion would have been in like 1993 or so. Now, IPv6 is what we have, and the standards are what they are, flaws and all. The only reason I can think of is psychological: People don’t want to learn new things, so they find reasons to dislike the new thing to be able to pretend they don’t need to learn it.

I think it could be argued that the flaws in IPv6 are significant enough to result in an scenario where IPv4 is never actually retired and therefore IPv6 is never fully adopted. Its been decades, but still IPv6 is deployed (at best) as a parallel network that effectively doubles management/maintenance overhead. And at worst sites just add an IPv6 reverse proxy.

Retiring IPv4 was never a strong goal of IPv6. The "inter-" in internet was always about "interoperability" between networks and side-by-side networks that interoperate was always the plan. Dual stack IPv4/IPv6 was in part chosen because it doesn't sweep the interoperability problems under the rug like some of these old "IPv4 extended" proposals did. You are never going to upgrade all devices at once and you were always going to have two networks, it was just a little bit easier with some of the other proposals to pretend it was one network if you squinted really hard and ignored all the interoperability problems that would crop up in practice because devices didn't update to understand the extensions.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#54
post #21

Earlier quoted context omitted.

We are way past the critical mass for IPv6, it has enough momentum to become predominant "internet" in the next decade or so. Thinking that it won't happen is pretty ludicrous at this point

My concern is that v4 may never be decommissioned. Sure, v6 could become predominant, but fundamentally there being two separate protocols running in parallel is a failed migration. On a much smaller scale it's analogous to migrating from mariadb to postgres, but the migration takes 50 years and you end up realistically maintaining both.

IPv4 may never be decommissioned, in the same way that unencrypted HTTP may never be decommissioned. But it can sure be completely marginalized.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#55
post #39
post #6

What is the rational reason, if any, for bringing up things like these? The time to have this discussion would have been in like 1993 or so. Now, IPv6 is what we have, and the standards are what they are, flaws and all. The only reason I can think of is psychological: People don’t want to learn new things, so they find reasons to dislike the new thing to be able to pretend they don’t need to learn it.

2012 wasn't a bad time to discuss alternate options. Now is maybe a little late, but that's arguable. There's a whole generation of people and experience that wasn't able to enter the discussions in 1993 and is available now. Maybe new eyes or experienced eyes would have a better solution. The problem is clearer now than then. IPv6 makes many changes to address many problems, but maybe only address space is a real pr…

If we open up the issue for discussion again, what we will get is some Google/Cloudflare protocol which “incidentally” centralizes everything.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#56
post #27

Earlier quoted context omitted.

I believe that the comment is not a personal opinion but a reflection of the acceptance rate of IPv6. If most of the web still uses IPv4 and not using IPv6 is still defended with the "people against new things" arguments, it shows that there is at least one thing that prevents people from using it. Considering that the new kid on the block is 26 years old, I think, there is more than one.

Any new protocol is going to have adoption costs. The "issue" with ipv6 is that for a lot of people/organizations, the tolerable cost of adoption is still pretty much zero. Adding yet another protocol to the mix would not make that better.

By no means I did support the use of another protocol. All I focused on was that the IPv6 could not be a huge success over IPv4. For the previous 26 years, pros weren't enough to eliminate the cons. At least the overall usage ratio can be comprehended this way.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#57
post #51

Earlier quoted context omitted.

What I've been told is both ISP's v6 prefix should be advertised with different priorities to the clients, which also yields the net bonus that applications that are stateless (UDP) or use MP-TCP can seamlessly fail over or adapt to network conditions without the intervention of another network device. I don't have easy access to multiple V6-PD enabled providers to test this theory, and as someone with quite the neck…

> What I've been told is both ISP's v6 prefix should be advertised with different priorities to the clients That basically doesn't work with real clients. They'll do dumb stuff like use address from provider A to send through the router advertising addresses from provider B. And take forever to do anything in response to prefixes that are advertised as no longer usable or simply no longer advertised.

Is this conjecture or something you’ve tested or known to be tested? V6 devices are actually expected to be able to understand multiple route advertisements and I know for sure they do properly understand the mix of link-local, ULA and public prefixes.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#58
post #51

Earlier quoted context omitted.

> What I've been told is both ISP's v6 prefix should be advertised with different priorities to the clients That basically doesn't work with real clients. They'll do dumb stuff like use address from provider A to send through the router advertising addresses from provider B. And take forever to do anything in response to prefixes that are advertised as no longer usable or simply no longer advertised.

Is this conjecture or something you’ve tested or known to be tested? V6 devices are actually expected to be able to understand multiple route advertisements and I know for sure they do properly understand the mix of link-local, ULA and public prefixes.

I tested it; I was trying to get failover (preferably automated failover) between DSL and LTE on IPv6. Should be simple: advertise from DSL as normal priority (would do high priority, but I can't change how the modem advertises it), advertise from the LTE as low priority, somehow make the DSL modem advertise deprecated or at least stop advertising when it's disconnected.

V6 devices are expected to understand that and do the right thing, but Windows (10) doesn't, Linux was worse, and I don't remember what Android did and I didn't get around to testing FreeBSD, and that's all the OSes I have.

If you've got experience otherwise, I'd love to know, one of these days I need to setup IPv6 again, but what I'd really like to do is too much work, so I'm IPv4 only for the foreseeable future.

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#59
post #38

Earlier quoted context omitted.

> Literally everything about IPv6 is easier and better That's not true, at a simple level typing "ping 10.34.56.22" is far easier than "ping df99:eff2:245a:46vv:2cmm:dfaa:41ff:2211" The benefits of ipv6 may outweigh ipv4, but by claiming "everything is easier and better" is disingenuous and a reason so many still refuse to move.

Your example is mostly a non-issue if you have working DNS. Which ... I know is a big assumption in a lot of networks, especially small to medium sized businesses, it seems. I don't know why DNS is such an issue for so many companies, but I can't help but think people would be more positive about ipv6 if we could get internal DNS solved first.

You may think it's a none issue, however it simply disproves the "literally everything" hyperbole

Re: Enhanced IP: IPv4 with 64 Bit Addresses (2012) [pdf]

#60

Earlier quoted context omitted.

Can't forget the SIP (Simple Internet Protocol) proposal https://datatracker.ietf.org/doc/html/rfc8507

Of course that SIP (not my one) and Paul Francis's PIP were what got merged to become IPv6. The rationale was that 128 bit addresses allowed all the flexibility of address hierarchies from PIP within a fixed length address. With hindsight, we've never really tried to use that flexibility in the real world, but the capability is there if we need it.

> With hindsight, we've never really tried to use that flexibility in the real world, but the capability is there if we need it.

Maybe not in public networks, but if you run your own network you can easily make use of auto-subnetting.

e.g. see [0], [1]

[0] https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_ne... [1] https://summit.riot-os.org/2021/wp-content/uploads/sites/16/...

Post reply on HN