Live data from Hacker News

AWS IPv4 Estate Now Worth $4.5B

toonk.io

231–240 of 480 posts

Re: AWS IPv4 Estate Now Worth $4.5B

#231
post #176

Earlier quoted context omitted.

This is the most hilarious "I don't understand anything about the problem, therefore I don't understand how it's hard" comment I've seen this week. > perhaps we could look at the 240.0.0.0/4 reserved for future use block What's the current rate of v4 address space consumption? How long will this block last? > and add more address bytes in the payload or something. This is, by definition, not backward compatible.

I may not have been clear enough in my suggestion. The idea would be to use this unused block as a special block. Not to fill it up with normal IPv4 allocations. See my suggestion as some kind of NAT-PT at scale. With a better marketing name and user experience. The problem is indeed hard because no one manage to find a solution at scale since 3 decades.

No matter what change you make, or how you make it, if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet

This is a fundamental and unresolvable problem with "making it backwards compatible"

Re: AWS IPv4 Estate Now Worth $4.5B

#232
post #212

Earlier quoted context omitted.

These arguments always boil down to these two: "Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible. "Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses. The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels…

The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you). One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same…

Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.

There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself.

Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course).

When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.

Re: AWS IPv4 Estate Now Worth $4.5B

#233

Can we go back in time and hit the designers of IPv6 upside the head? The decision not to make IPv6 backwards compatible, the belief that a beautiful new standard could magically replace something already so widespread... "Naive" is an inadequate word. We are still futzing with the transition 3 decades later, with no end in sight. Grrr, grumble...

Things don't need to be backwards compatible, they just need to have a financial incentive attached. That could either come from the market or from the government. There's a cost to making things backwards compatible and this can be avoided if we just don't. There are countless examples of technologies that weren't backwards compatible but happened anyway. For IPv6 the problem is the incentive isn't coming from the anywhere.

Re: AWS IPv4 Estate Now Worth $4.5B

#234

Earlier quoted context omitted.

> That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim. Imagine this topology: C (client, IPv4-only) R (intermediate ro…

The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it? The inverse situation (IPv6-only client but IPv4-only server) is not really an iss…

[deleted]

Re: AWS IPv4 Estate Now Worth $4.5B

#235
post #212

Earlier quoted context omitted.

These arguments always boil down to these two: "Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible. "Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses. The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels…

The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you). One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same…

You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start.

From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.

Re: AWS IPv4 Estate Now Worth $4.5B

#236
post #168

Earlier quoted context omitted.

Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be. Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging. However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.

IPv6 is backwards compatible. In multiple ways: Option 1: "6to4" https://en.wikipedia.org/wiki/6to4 Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 + DNS64 Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike) Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling Option 4: 6rd https://en.wikipedia.org/wiki/IP…

Reading, not even trying to understand that list makes my brain explode.

Re: AWS IPv4 Estate Now Worth $4.5B

#237
post #212

Earlier quoted context omitted.

The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you). One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same…

You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start. From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.

The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.

Re: AWS IPv4 Estate Now Worth $4.5B

#238

Earlier quoted context omitted.

> Overall we are now much further into the IPv6 migration than djb ever envisioned. That post was written 20 years ago . I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago. > is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients I'm not a network eng…

I have yet to read any IPv6 alternative that can theoretically work or is not just IPv6 in disguise (or something that is implemented in IPv6 in a slightly similar fashion). It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forwa…

I believe the claim is that, IF IPv6 had been a much more minor modification of IPv4, including just a change to the packet structure to have a larger address field, it would have seen more adoption more rapidly than the current version of IPv6 which also changes everything else about the L2-3 stack. Sure, you would have still needed new devices and that would have taken some years, but as long as the network architecture remained the same, it wouldn't have required a quarter century to get to 30% adoption.

I don't know that I believe this claim at all, but it is at least coherent and possible (unlike claims that N-bit addresses could have been added to IPv4 in a backwards compatible manner). Perhaps SLAAC, the focus on routable end user devices etc were indeed major distractions that pulled focus away from a move to a new larger address space - which is the only thing people actually wanted from IPv6.

Re: AWS IPv4 Estate Now Worth $4.5B

#239
post #224
post #163

Earlier quoted context omitted.

No, the minimum allocation is a /24 (for v4) or a /32 (for v6)

Its a /48 for IPv6. Thats what I have in my RIPE Account.

As I understand it, the current policy allocates /48 for special purposes. Normally allocations that small are supposed to come from an LIR, not directly from an RIR.

Re: AWS IPv4 Estate Now Worth $4.5B

#240
post #237

Earlier quoted context omitted.

You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start. From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.

The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.

There's certainly a requirement for them, but it would be good to know what the justification of that requirement was before we know if there's a need. E.g. the justification could be "our SOPs say all network traffic must go through NAT", and if you dig deeper you might find that the SOP was written to save money on IPv4 addresses. That would not indicate a fundamental need.
Post reply on HN