Live data from Hacker News

How engineers at Digital Equipment Corp. saved Ethernet

spectrum.ieee.org

31–40 of 109 posts

Re: How engineers at Digital Equipment Corp. saved Ethernet

#31
post #14

Earlier quoted context omitted.

There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.

But this was what literally happened. All routers today support NAT and most of them actively use it. Isn't it a magical form of extended IPv4 address space? Could have been easily done in less band-aid fashion instead of chasing IPv6.

[deleted]

Re: How engineers at Digital Equipment Corp. saved Ethernet

#32
post #27

Earlier quoted context omitted.

There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.

I believe it's more along the lines of the concepts in IPv4 are easier to grasp than IPv6, starting with the actual addresses themselves. IPv6 breaks all backwards compatibility. So, it's not unreasonable for people to ask why we can't just break it in a more familiar way? Extending IPv4 into say, IPv7 and using familiar addressing schemes, well understood routing/NAT/DHCP techniques, etc, while providing the same us…

IPv6 breaks less backwards compatibility than many people think. Many get caught up in all of the other changes you can (and often do) do because it makes life better and conflate that with IPv6 not letting them do things the same way. About the only generally true "it breaks backwards compatibility" is the format of the address being longer for the longer address. Netmask, gateways, DHCP, static assignment, and neighbor discovery are all about as 1:1 as one could ask if that's all you care about but it's just a dumb way to do things if you're upgrading everything so then you have SLAAC, a more present link local, DHCP-PD, and so on to hear/think about as well.

E.g. you can still NAT the massive IPv6 private address space with static and/or DHCP assignments without having to change your understanding (addresses would even be darn short too!) but... it's just silly to do.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#33
post #12

Earlier quoted context omitted.

Unfortunately none of those people have explained how it could be done in enough detail that I could try it. Most walk away when pressed but a few press on telling me it is easy so shut up and do it .

Similar to how it has been done with phone numbers. I saw this done in Brazil for example. You add a digit to the front and put all existing address on 0.*. Short number dials are assumed to be 0.*. Update OS and hardware. Then you allocate across the new digit much later as time goes on. The thing with phone infrastructure though is that it is centralized. So may happen in a reasonably coordinated rollout. Global in…

If you had to deal with a hundred million different kinds of dialing software, that method wouldn't work out so well.

> If we could get a five byte address written in hex it would be somewhat user friendly.

For local addresses, you can use fec0::zzzz.

Do you need to memorize or hand-type global addresses very often?

Re: How engineers at Digital Equipment Corp. saved Ethernet

#34
post #14

Earlier quoted context omitted.

There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.

But this was what literally happened. All routers today support NAT and most of them actively use it. Isn't it a magical form of extended IPv4 address space? Could have been easily done in less band-aid fashion instead of chasing IPv6.

[deleted]

Re: How engineers at Digital Equipment Corp. saved Ethernet

#35
post #14

Earlier quoted context omitted.

There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.

But this was what literally happened. All routers today support NAT and most of them actively use it. Isn't it a magical form of extended IPv4 address space? Could have been easily done in less band-aid fashion instead of chasing IPv6.

It is impossible to address hosts behind NAT. Only the public IPv4 address is visible.

It might have been possible to extend IPv4 by having each NAT hop add the internal IPv4 address as option header. Then it would be possible to refer to inside host directly with a list of addresses.

That isn't worth doing now because it would require rewriting everything to deal with the new protocol. For one thing, lots of NAT boxes remove all the option headers. The new protocol wouldn't be reliable.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#36
post #6
post #3

[flagged]

I think the great architectural challenge would be - how does one add that byte to the IP header in a non-breaking way?

There are a bit more than a hundred unused protocol numbers, and the options field has more than enough room to stuff some more address space into it. You'd need enough buy-in to get the protocol number accepted as valid, and could introduce better routing gradually: as long as the OG destination address knows how to send the packet on to the extended-address computer, it'll get where it's going.

The problems, and they are real, show-stopping problems, are more social than technical.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#37

Earlier quoted context omitted.

Similar to how it has been done with phone numbers. I saw this done in Brazil for example. You add a digit to the front and put all existing address on 0.*. Short number dials are assumed to be 0.*. Update OS and hardware. Then you allocate across the new digit much later as time goes on. The thing with phone infrastructure though is that it is centralized. So may happen in a reasonably coordinated rollout. Global in…

The IPv4 address field is fixed size. You can't simply add a digit and deal with it at the telephony company premises like you can with a phone number. You have to rev every piece of equipment and software that can ever touch a packet. At that point, why are you not also fixing other architectural flaws and ensuring that the address space is large enough to accommodate any future needs?

One interesting thing about this idea is that, from a higher level, that's exactly how IPv6 works; the "leading zero" is the IP protocol version field. If that leading zero, er IPv4, is there, the fields of the IP packet are interpreted using IPv4 semantics. If the version field is IPv6, then the IP packet is interpreted using IPv6 semantics.

This is how you configure telephone dial plans. Earlier dialed numbers influence the interpretation of later numbers. You dial a 1, an area code is expected next. You dial 9, you get an outline line. Dial plans are a pretty decent setup and allow scoped dialing, but are limited in their extensibility (you can't have a local number start with 1). In IP, the IP protocol version field influences the interpretation of later fields, logically similar to dial plans.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#38

Earlier quoted context omitted.

Has IPv6 been a failure? All I know is that IPv4 is still around. And without knowing the IP Addresses of devices on my LAN, by home network would be harder to manage!

You can know the IP addresses on your LAN. If you'd like you can assign multiple addresses per interface, so that you have global and local addresses. e.g. local addresses fc00::1 for your router, fc00::2 for your desktop, fc00::3 for your phone, etc. If you want, you can use your global prefix with ::1 ::2 and ::3 for your global addresses too. You don't have to use privacy extensions if you don't want to. Things li…

Addresses starting with fc are reserved.

I would suggest using either fec0 or fd00. Which is still not best practices, but it's a lot closer.

(fec0 is deprecated, and fd is supposed to be followed by a randomly chosen 40 bit site ID but you can lie and say your random number was 0)

Re: How engineers at Digital Equipment Corp. saved Ethernet

#39
post #28

Earlier quoted context omitted.

The IPv4 address field is fixed size. You can't simply add a digit and deal with it at the telephony company premises like you can with a phone number. You have to rev every piece of equipment and software that can ever touch a packet. At that point, why are you not also fixing other architectural flaws and ensuring that the address space is large enough to accommodate any future needs?

> The IPv4 address field is fixed size. So? Make it bigger, call it IPv7, then enjoy. IPv6 has 128 bits for addresses, why can't IPv7 have 128 bits as well, but still use more familiar patterns/techniques borrowed from IPv4? IPv6 threw just about everything out the window... for what reason? Two decades of confusion and resistance... I think at this point in time, people are afraid to say "ya, we overthought the hell…

Nothing in the world can work with IPv7. That means need to update all the software and replace all the hardware. This takes years of effort, and years of time.

What more familiar techniques? How are they going to be worth the millions of man-hours to implement? How are they going to be so much better that people will abandon IPv6 and switch from IPv4? Could this be accomplished by changing part of IPv6?

It is quite possible that you are using IPv6 to access Hacker News without knowing it.

Re: How engineers at Digital Equipment Corp. saved Ethernet

#40
post #3

[flagged]

Has IPv6 been a failure? All I know is that IPv4 is still around. And without knowing the IP Addresses of devices on my LAN, by home network would be harder to manage!

Hacker News added IPv6 support recently. It is quite possible people are using currently using it to access the site.

Google has IPv6 support at 50%. Most of the major sites I use have IPv6. Google, Facebook, Amazon, Youtube.

Post reply on HN