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

The world in which IPv6 was a good design (2017)

apenwarr.ca

Post reply on HN
Print view View original

291–300 of 318 posts

Re: The world in which IPv6 was a good design (2017)

#291

Post by [deleted] »

mike_d wrote: post #267
ianburrell wrote: post #226

Earlier quoted context omitted.

I think major failure of Kubernetes was not being IPv6-only from the beginning. Its model of every pod having own address works much better with IPv6 where addresses are cheap. With IPv4, it needs complicated overlay networks. The cluster boundary would also make a good place for NAT64 proxy. Kubernetes didn't get IPv6 support until later, and it sounds like it isn't reliable yet.

> I think major failure of Kubernetes was Heh. Kubernetes as a whole was a failed project at Google that got open sourced.

[deleted]

Re: The world in which IPv6 was a good design (2017)

#292

Post by pknomad »

Dagger2 wrote: post #222
pknomad wrote: post #185

Earlier quoted context omitted.

I work for a federal space where IPv6 native is a mandate. As someone who's working on k8s, we often have to build and patch everything ourselves to support that mandate. Want to pull a helm chart from a github repo? Gotta either dual stack the node or run a reverse proxy to make that happen. I'd love to be at a point where everyone just dual stacked everything so that one day we can flip off the IPv4 switch.

Try NAT64. It'll let v6-only clients reach v4-only websites.

Interesting. I'll take a look! Thanks!

Re: The world in which IPv6 was a good design (2017)

#293

Post by systems_glitch »

greyface- wrote: post #266
systems_glitch wrote: post #265

Earlier quoted context omitted.

Interesting, thanks! I'll have to see if I can get OpenBSD to do that.

On OpenBSD, you can dump the ND cache with `ndp -an`. You'd still have to map MAC addresses to hostnames somehow.

Ah hah, thanks! I can probably just correlate them with DHCPv4 leases.

Re: The world in which IPv6 was a good design (2017)

#294

Post by RavSS »

WorldMaker wrote: post #251
arka2147483647 wrote: post #164

Earlier quoted context omitted.

> Point A: IPv6 is broken because it didn't go far enough Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it. Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. We have jumbo frames, why not jumbo addresses?

> Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. IPv6 supports dotted quad notation, if that is your problem with it. You can absolutely write a 128-bit IPv6 address with the last 32 bits in 123.123.123.123 notation if that makes you feel happier. ::ffff:123.123.123.123 Technically, there's nothing stopping you from building a qui…

> IPv4 has a fixed header size (period)

Unless I'm mistaken, I would not say it's fixed due to the rarely used IP options field that varies depending on the IHL field. It has a variable size within a range. There might be a way to get "jumbo addresses" but it would have to be terribly hacked onto the design of the header as it is, which is one reason for IPv6's existence.

https://en.wikipedia.org/wiki/Internet_Protocol_version_4#He...

Re: The world in which IPv6 was a good design (2017)

#295

Post by LinuxBender »

justcool393 wrote: post #286
BizarroLand wrote: post #210

Earlier quoted context omitted.

Yeah, that's smart. There's no need for everything to be uniquely identified on the internet anyway, right? Why would someone halfway around the world need to be able to ping my smart fridge after all? Even for tech support purposes, people shouldn't have the ability to directly test my appliances firewall capabilities. Actually, now that I've done the math, why not just extend IPv4 into hexadecimal? Once again, none…

> what's not to love about it hexadecimal, unironically. the url of http://[2002:914b1:::1] is one of my major sticking points for IPv6. i'd rather just have it be 16 octets or even 8 decimal quartets where each thing is required. http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246 would've at least looked a bit better than it is. would've been super easy too. imagine the convo: "what's google's DNS IP in IPvX?" "oh it'…

"oh it's just 8.8.8.8.8.8.8.8.8.8.8.8.8.8.8.8"

I think what you are saying is that it should be turned into a jingle so everyone can dial it fast. [1]

[1] - https://www.youtube.com/watch?v=5m6qutSER9Q [video][11s]

Re: The world in which IPv6 was a good design (2017)

#296

Post by WorldMaker »

RavSS wrote: post #294
WorldMaker wrote: post #251

Earlier quoted context omitted.

> Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. IPv6 supports dotted quad notation, if that is your problem with it. You can absolutely write a 128-bit IPv6 address with the last 32 bits in 123.123.123.123 notation if that makes you feel happier. ::ffff:123.123.123.123 Technically, there's nothing stopping you from building a qui…

> IPv4 has a fixed header size (period) Unless I'm mistaken, I would not say it's fixed due to the rarely used IP options field that varies depending on the IHL field. It has a variable size within a range. There might be a way to get "jumbo addresses" but it would have to be terribly hacked onto the design of the header as it is, which is one reason for IPv6's existence. https://en.wikipedia.org/wiki/Internet_Protoc…

My understanding of options is that many routers and/or firewalls consider it a dangerous and deprecated field and are most likely to drop packets that use them, especially when they are variably sized.

That also gets back to the point that almost all of IPv4 is too "known" as a design and every field accounted for in some router and/or firewall logic somewhere by the time IPv6 was designed.

Re: The world in which IPv6 was a good design (2017)

#297

Post by WorldMaker »

justcool393 wrote: post #288
WorldMaker wrote: post #251

Earlier quoted context omitted.

> Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. IPv6 supports dotted quad notation, if that is your problem with it. You can absolutely write a 128-bit IPv6 address with the last 32 bits in 123.123.123.123 notation if that makes you feel happier. ::ffff:123.123.123.123 Technically, there's nothing stopping you from building a qui…

To be honest, the hex strings make it much harder to remember imo, especially with the terrible syntax of nothing between a colon being a 0. Even having them be 16-bit integers would've been find imo

If you think you have a better notation idea for 128-bit numbers, build your own address converter and try it?

The obvious other notations for numbers that large to compare to are the various notations people use for UUIDs/GUIDs.

I personally find IPv6's designed notations one of the easier ones to use, especially because of that :: fill with zeroes shortcut to focus on the easier separation of prefix versus suffix. (For a network you control you likely only need to remember the prefix, and then suffix is whatever numbering scheme you want to implement so it may be algorithmic and simply ordered ::1, ::2, ::3, etc. Also, the regular pattern of a colon every four hex digits versus say the strange group order of UUIDs is nice. Trying to write the notation of a UUID without software help is much more painful than IPv6 address notation, I think.) But also, I have a bit of dyscalculia (my brain catches all the individual digits in a number but not always their correct order) and hex works much better for me at remembering or visualizing long numbers.

Re: The world in which IPv6 was a good design (2017)

#298

Post by schoen »

fanf2 wrote: post #202
schoen wrote: post #68

Earlier quoted context omitted.

We should probably have auctions for IPv4 space to encourage more efficient use. Not that we have some kind of authority to require this, but we've often suggested this in connection with our proposal to prepare to allocate 240/4. While one can say that there's no way that IPv4 demand can ever be "satisfied" (which seems right to me), one can also imagine a different quantity demanded at $0.50/address than at $0.00/a…

There are auctions for IPv4 space, though they did not really become a thing until after the RIRs ran out of IPv4 blocks. The price per address is about $50.

Yes, and hopefully we can use that kind of mechanism to allocate 240/4 in a way that achieves very high utilization.

Re: The world in which IPv6 was a good design (2017)

#299

Post by cyberax »

greyface- wrote: post #282
cyberax wrote: post #281

Earlier quoted context omitted.

Snooping table sizes are typically around 16k entries. IGMP/ND packets are almost always punted to the CPU, so once the CPU is saturated, switches typically either fall back to broadcast or stop forwarding multicasts. It's not a good outcome either way.

This varies widely by switch model, and 16k is on the low end. I looked at a few random Cisco and Arista switch datasheets just now and saw numbers ranging from 16k to 768k (usually 25% to 100% of the unicast MAC table size of the same switch). Unicast MAC table space is scarce, too, and suffers the same failure modes when filled. You don't see people claiming this makes IPv4 over Ethernet infeasible. Do proper capac…

> Unicast MAC table space is scarce, too, and suffers the same failure modes when filled.

Yup.

> You don't see people claiming this makes IPv4 over Ethernet infeasible

Actually, people DO claim that. Flat Ethernet doesn't scale, and you need to use routing to break up broadcast domains.

Re: The world in which IPv6 was a good design (2017)

#300

Post by greyface- »

cyberax wrote: post #299
greyface- wrote: post #282

Earlier quoted context omitted.

This varies widely by switch model, and 16k is on the low end. I looked at a few random Cisco and Arista switch datasheets just now and saw numbers ranging from 16k to 768k (usually 25% to 100% of the unicast MAC table size of the same switch). Unicast MAC table space is scarce, too, and suffers the same failure modes when filled. You don't see people claiming this makes IPv4 over Ethernet infeasible. Do proper capac…

> Unicast MAC table space is scarce, too, and suffers the same failure modes when filled. Yup. > You don't see people claiming this makes IPv4 over Ethernet infeasible Actually, people DO claim that. Flat Ethernet doesn't scale, and you need to use routing to break up broadcast domains.

> Actually, people DO claim that [MAC table limits make IPv4 over Ethernet infeasible]. Flat Ethernet doesn't scale, and you need to use routing to break up broadcast domains.

This has nothing to do with unicast MAC table limits, and everything to do with ARP's O(n^2) scaling property. You use just as many MAC table entries in a network with 10 VLANs of 100 hosts as you do with 1 VLAN of 1000 hosts. Ethernet scales fine; ARP doesn't.

Post reply on HN