Hacker News new | comments | show | ask | jobs | submit login

Regardless of your feelings on NAT, it exists, its deployed, and it needs to be part of the conversation from the start. If you want people to move off NAT, then it really needed to be gradual. Look at Perl 5 to 6 for how bad this stuff can go (heck, even Python 2 -> 3 was painful).

How about you add the additional 96-bits to the protocol (why 128-bits - that's boil the ocean numbers) and then the protocol sees all the 0.0.0.0 numbers as a short cut for a standard 32-bit range (I supposed with bits above and below for the eventual address expansion) while the : notation is the real full address. Then my day one experience is install the new software that is 128-bit aware and leave all my configs alone since I already have been assigned those in the IPv4 address space. Now we can do some phase 2 to get rid of the evil NAT and clean other clean up.

There are a lot of much smarter people than myself, and I cannot believe someone didn't have a great suggestion to cause a minimum impact on all the folks running systems in the field. I hate burn the bridges system conversion.

holy heck, you edit this one, glad I waited




Your suggestions are gibberish, that would be a far more hacky protocol, and would still require upgrading every node.

You gain absolutely nothing via this approach.


> Regardless of your feelings on NAT, it exists, its deployed, and it needs to be part of the conversation from the start.

Why?

> If you want people to move off NAT, then it really needed to be gradual.

Why?

> How about you add the additional 96-bits to the protocol

Yeah, that's a common variant of "they should just have made it backwards compatible".

> (why 128-bits - that's boil the ocean numbers)

That is not how efficient routing works. You cannot expect to fill the complete address space unless you spend excessive amounts of resources on the routing equipment, which has exactly one effect: Boiling the oceans (and/or slowing down the network). In order to keep routing efficiency up, you need a far larger address space than the theoretical minimum required to contain all nodes, because that is how you keep routes aggregated, and therefore the routing tables in the core of the network small, so you can use cheap equipment to move massive amounts of data at low prices.

> and then the protocol sees all the 0.0.0.0 numbers as a short cut for a standard 32-bit range (I supposed with bits above and below for the eventual address expansion) while the : notation is the real full address. Then my day one experience is install the new software that is 128-bit aware and leave all my configs alone since I already have been assigned those in the IPv4 address space. Now we can do some phase 2 to get rid of the evil NAT and clean other clean up.

In other words: You don't have the faintest clue what you are talking about, what you are describing makes no sense, though it sounds somewhat like the common anti-IPv6 crackpot theories.

If you add even a single bit to the address, you have a protocol that is unavoidably completely impossible to interoperate with IPv4. IP is not some markup language, it's a frame format. IPv4 has a fixed sequence of bytes forming the packet header, and in a fixed position in that sequence there are 32 bits for the destination address. Every single IPv4 router and host on the planet uses exactly those 32 bits to make routing decisions. If you insert a bit somewhere, that just moves everything following that bit one bit to the right and therefore makes everything following that bit incomprehensible to every single IPv4 router and host on the planet. The only solution to that is to add support for the additional bit to every single router and host. Sounds familiar?

And it's not just that you have to upgrade every single router and host to complete the transition, it's also that a node that suports the additional bit cannot use that to talk to any node that hasn't been upgraded yet. If you only have an address with the additional bit, and you send a packet to someone who has only a legacy address and doesn't support the new format, they cannot send you a reply, because in order to do so they would have to know how to send a packet to your extended address, and every router along the path would have to be able to do so as well.

So, the only thing that remains that could theoretically have been done would be to reuse the existing IPv4 address space allocations as IPv6 allocations. But first of all, there is no advantage to doing so. The difficult part is adding the protocol support, address allocation isn't difficult. And then, there is a very good reason to start with fresh allocations for IPv6: Routing table fragmentation. The global IPv4 routing table now has ~ 700,000 entries as most ISPs or larger companies have tons of prefixes that they have collected over the decades. The global IPv6 routing table has ~ 50,000 entries, because most ISPs and companies have only one prefix. That means that a pure IPv6 backbone router needs less than a tenth of the TCAM of an IPv4 router, which should considerably reduce costs/improve throughput.

> There are a lot of much smarter people than myself, and I cannot believe someone didn't have a great suggestion to cause a minimum impact on all the folks running systems in the field.

Just as I said: You have no idea how it could have been done, you just know it should have been done better, because doing it better is easy, even though you don't have the slightest clue how.

> I hate burn the bridges system conversion.

Well, great then that IPv6 isn't one of those. You just deploy it in parallel with IPv4, gradually enable IPv6 everywhere, and at some point when you think IPv4 isn't worth it anymore, you switch it off.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: