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

The mistakes and missed opportunities in the design of IPv6

ipv6.hanazo.no

Post reply on HN
Print view View original

61–70 of 73 posts

Re: The mistakes and missed opportunities in the design of IPv6

#61

Post by cryptonector »

IPv6 did not tackle the router-side problem with CIDR: huge routing tables. In 1994 CIDR was causing a lot of hurt in the then backbone because routers needed more and more memory to hold ever larger routing tables. Keeping routing the same except adding more bits to the address space merely made the problem worse except for the hope that the address space wouldn't be too fragmented, and that something like the DNS A6 RR type (failed) would resolve address portability concerns.

IPv6 could have had a way to explicitly identify in the IPv6 header the route to the destination by AS number. I don't mean that applications should have been aware of AS numbers -- that could have been a system feature, or a first border gateway feature.

This would have made routers cheaper by making their routing tables much smaller (2^16 routes max) and would have made number portability easier by making it more tolerable to have huge IP->AS lookup tables outside the core routers. Though on the flip side it might have led to more fragmentation of the address space, so maybe it's better the way it is.

Re: The mistakes and missed opportunities in the design of IPv6

#62

Post by cryptonector »

zorked wrote: post #8
blueflow wrote: post #6

> IPv6 chose to have addresses on the interface connecting to the network instead of having addresses on the node. In contrast to IPv4, IPv6 supports multiple addresses on an interface, where each of the address has different properties. IP Addresses were always interface-bound. And you always could have multiple addresse on the same interface. Your IPv4 loopback device has 2^24 addresses bound to it right in this mo…

Having several IPv4 addresses per physical interface is a bit of an extension. It is called IP aliasing in Linux and it wasn't always there.

IPv4 itself doesn't say anything about how many addresses you could have on an interface, not that I recall.

Re: The mistakes and missed opportunities in the design of IPv6

#63

Post by cryptonector »

Hikikomori wrote: post #54
blueflow wrote: post #53

Earlier quoted context omitted.

You changed your interface to not implement RFC 5735: 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher-level protocol to an address anywhere within this block loops back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback. -- https://datatracker.ietf.org/doc/html/rfc5735#section-3 An ICMP Ping is a datagram in the sense of…

No, I'm just on a mac. Also: This is ordinarily implemented using only 127.0.0.1/32 for loopback.

On Linux it has a larger netmask and you can have multiple loopback addresses.

Re: The mistakes and missed opportunities in the design of IPv6

#64

Post by parliament32 »

zorked wrote: post #8
blueflow wrote: post #6

> IPv6 chose to have addresses on the interface connecting to the network instead of having addresses on the node. In contrast to IPv4, IPv6 supports multiple addresses on an interface, where each of the address has different properties. IP Addresses were always interface-bound. And you always could have multiple addresse on the same interface. Your IPv4 loopback device has 2^24 addresses bound to it right in this mo…

Having several IPv4 addresses per physical interface is a bit of an extension. It is called IP aliasing in Linux and it wasn't always there.

Not quite. The kernel documentation notes that IP aliasing was the original way to have multiple IPs per interface, but is now obsolete, as multiple IPs are directly supported now (and by "now" I mean 2009-ish, with the introduction of iproute2): https://docs.kernel.org/networking/alias.html

In addition, the manpage for ip-address makes this clear:

> The address is a protocol (IP or IPv6) address attached to a network device. Each device must have at least one address to use the corresponding protocol. It is possible to have several different addresses attached to one device. These addresses are not discriminated, so that the term alias is not quite appropriate for them and we do not use it in this document.

https://linux.die.net/man/8/ip

Re: The mistakes and missed opportunities in the design of IPv6

#65

Post by cryptonector »

kemotep wrote: post #60
Borg3 wrote: post #24

I kinda agree with the arcticle. Here is my ideal IPv6: http://borg.uu3.net/~borg/?ipv6 It basically means, you grab IPv4 implementation, extend address space to 64bit, call it IPv6, vioala. Problem solved. IPv4 was battle proven for years. It mistakes were sorted out (CIDR addressing, ARP poisoning, DHCP/BOOTP, etc). It was widely understood. NAT is okey, CGNAT is not. The only problem was the address space. And the…

If one of the main blockers in ipv6 adoption is updating routers and switches and all the networking gear and endpoints to support the new address scheme, how in the world would your “just extend ipv4 to 64 bits” solve that problem specifically? 123.123.123.123/48 or whatever would be completely useless and dropped by an incompatible router and a server wouldn’t know what the hell to send its packets back to if it ev…

> If one of the main blockers in ipv6 adoption is updating routers and switches and all the networking gear and endpoints to support the new address scheme, how in the world would your “just extend ipv4 to 64 bits” solve that problem specifically?

By reducing the amount of work needed in order to get the new thing implemented. IPv4 is super simple by comparison to IPv6. I'd say there's at least an order of magnitude more complexity and legacy in IPv6 than in IPv4. Just look at the number of IPv4 vs IPv6 RFCs.

> 123.123.123.123/48 or whatever would be completely useless and dropped by an incompatible router [...]

It would still have been a new protocol, just able to share a lot of source code with IPv4.

Re: The mistakes and missed opportunities in the design of IPv6

#66

Post by cryptonector »

Re-reading https://apenwarr.ca/log/20170810 (linked elsewhere in this thread as well), right the thing that should have been solved first as the introduction of a TCP and UDP replacement suite that could handle mobility, since then switching IP versions at layer 3 would be much easier. But 30 years ago mobility wasn't as critical as 20 years ago and the IETF didn't foresee it. Also, introducing new transport protocols is quite difficult due to middleboxes -- at least that was the experience with SCTP, but a TCP that solves mobility would probably lead to middleboxes getting fixed quickly.

Re: The mistakes and missed opportunities in the design of IPv6

#67

Post by cryptonector »

oftenwrong wrote: post #29

I recommend reading The world in which IPv6 was a good design by apenwarr: https://apenwarr.ca/log/20170810 It has been submitted many times here: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... You will find at the end that it has received an update of sorts here: https://tailscale.com/blog/two-internets-both-flakey

Thanks for this. Yes, the key mistake was not tackling mobility before the iPhone.

Re: The mistakes and missed opportunities in the design of IPv6

#68

Post by ArchOversight »

cryptonector wrote: post #63
Hikikomori wrote: post #54

Earlier quoted context omitted.

No, I'm just on a mac. Also: This is ordinarily implemented using only 127.0.0.1/32 for loopback.

On Linux it has a larger netmask and you can have multiple loopback addresses.

On MacOS it has a larger net mask, but the OS doesn't respond to any address within that range automatically.

  lo0: flags=8049 mtu 16384
   options=1203
   inet 127.0.0.1 netmask 0xff000000
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
   nd6 options=201

Re: The mistakes and missed opportunities in the design of IPv6

#69

Post by sph »

rcxdude wrote: post #25
sph wrote: post #21

Earlier quoted context omitted.

IPv6 isn't difficult to implement, and complexity is not the reason we're still stuck in IPv4 land. We are stuck here because the Internet runs on devices no one cares enough/has enough budget to update.

At this point it's not so much the basic devices, it's very rare to have hardware still around that doesn't support ipv6, it's more the configuration of the networks themselves, as any given network needs to have its own set of decisions made on address allocation, etc to actuallly support it. And, since it's used by fewer people and there always needs to be a fallback to ipv4, for most networks the if ipv6 is broken…

> flip a switch and it'll mirror your ipv4 setup so you don't have to think about it until you locally need more address space

If you think about it, that is what dual-stack is. You don't have to do anything unless you want more address space.

The issue is that often locally one doesn't need more address space, but the Internet as a whole does.

Re: The mistakes and missed opportunities in the design of IPv6

#70

Post by Borg3 »

bluGill wrote: post #45
Borg3 wrote: post #24

I kinda agree with the arcticle. Here is my ideal IPv6: http://borg.uu3.net/~borg/?ipv6 It basically means, you grab IPv4 implementation, extend address space to 64bit, call it IPv6, vioala. Problem solved. IPv4 was battle proven for years. It mistakes were sorted out (CIDR addressing, ARP poisoning, DHCP/BOOTP, etc). It was widely understood. NAT is okey, CGNAT is not. The only problem was the address space. And the…

That is what they did. The number of bits is a detail. There is no way to use a different number of bits and remain compatible.

This is what they did NOT! Just read IPv6 related RFCs. A lot of differences. If they did that in 1997, we would probably be on IPv6 long time ago...
Post reply on HN