RE: IPv6 "bloat" history
Hello Ohta-san > > - there's no way to know if 2 locations are OK (anycast) > > If you mean IPv6 anycast to allow 2 or more hosts sharing an anycast address, > it is just broken not useful for any purpose and ignored. One case I have in mind is when one wants to bundle multiple physical interfaces as one logical P2MP interface that reaches different routers, e.g., for server multihoming. There's a single owner and a single address, but it is presented to both routers on different physical interfaces and can be routed to any of those. Then the routers inject the address in some overlay and may fight unless they realize that they work on behalf of the same end point. Basically I'm talking about a proper L3 abstraction for cases where LAG / Etherchannel are used today. K8S needs a unique IP like that. > Instead, IPv4 style anycast is widely deployed for IPv6. I guess you mean the one we configure on a server loopback for load balancing? Certainly. The end result is the same for the routing (weighted ECMP) so for all I know we can use the same signals. Keep safe; Pascal
Re: IPv6 "bloat" history
Pascal Thubert (pthubert) wrote: You can't expect people still working primarily on v6 have much sense of engineering. That includes me Sorry for confusion. I mean "people still working primarily on v6" are people who insist on IPv6 and ND as is, because any required repair on it would delay the day when IPv6 is fully deployed. Worse, actually, though they insist packet format stay same, semantics has been randomly changing a lot as they wish. As broadcast/multicast packets are first sent to APs as unicast packets with ACKs, snooping by APs should be reliable at L2. Well, up to the N retries. After that the stack is not even aware that the multicast was not delivered. That is a unicast problem. But, I understand your point. That is, though it can be remedied by upper layer ACKs, there can be NACKs but no ACKs for DAD. Oh but that's just the beginning of the story; Yup. yes we mostly can form an initial state and it mostly appears to work and people are mostly satisfied. And then you realize: - there's no way to know how long the device will you that address With some interval, an AP can unicast fake DAD to the device, I think, though it wastes power to do so. > - there's no clean way to > know is an address is still in use (e.g., without reviving it in the > host stack) See above, though I don't think it clean. - there's no way to know which is the most recent location of the address (unless you have a fine time distribution and that costs) Yup. - there's no way to know if 2 locations are OK (anycast) If you mean IPv6 anycast to allow 2 or more hosts sharing an anycast address, it is just broken not useful for any purpose and ignored. Instead, IPv4 style anycast is widely deployed for IPv6. - there's no way to know for sure that the claimer is the owner You may use IPSEC, though securely configuring security key for IPSEC is at least as difficult as securely configuring address without IPSEC, which means requiring cryptographic security for DHCP is a bad idea. Certainly a bad guy doing impersonation and DOS can play havoc in such network, but at least between good guys we get something we can operate. I'm sure there are a lot of security holes in or around IPv6 I haven't noticed yet. I'm not saying that snooping DHCP is fully deterministic but it's orders of magnitude better than snooping SLAAC when it comes to forming a state like an association than SLAAC. Of course. So, by snooping DAD, which is ugly, ARP table can be constructed. A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, start populating the hot-line before you turn the lights on I merely said "constructed", which does not imply "maintained". E.g., a DAD coming from the wire that is sent over the wireless is not deterministically delivered and a duplicate is often missed. Even with a single AP, as DAD to terminals is multicast (from the AP) and unreliable, duplicate is often missed. I do not need to continue the endless list do I? If you think people still working primarily on v6, with my meaning, have much sense of engineering, you should. Masataka Ohta
RE: IPv6 "bloat" history
> > Pascal Thubert (pthubert) wrote: > > > You're perfectly correct. This is exactly what the registration would > > be for. I'm concerned about its adoption that I do not see coming on > > Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot > > worse*. > > You can't expect people still working primarily on v6 have much sense of > engineering. That includes me > > > * APs today snoop DHCP; DHCP is observable and stateful, with a > > lifetime that allows to clean up. So snooping it is mostly good enough > > there. The hassle is the SL in SLAAC which causes broadcasts and is > > not deterministically observable; this problem is specific to IPv6. We > > already have the registration to avoid snooping DHCP and SLAAC; yet we > > do not observe any adoption in mainline APs and STAs. > > As broadcast/multicast packets are first sent to APs as unicast packets with > ACKs, snooping by APs should be reliable at L2. Well, up to the N retries. After that the stack is not even aware that the multicast was not delivered. Oh but that's just the beginning of the story; yes we mostly can form an initial state and it mostly appears to work and people are mostly satisfied. And then you realize: - there's no way to know how long the device will you that address - there's no way to know how many addresses the device will form - there's no way to know how many addresses the device has already formed and which (at least MLD can do that) - there's no clean way to know is an address is still in use (e.g., without reviving it in the host stack) - there's no way to know which is the most recent location of the address (unless you have a fine time distribution and that costs) - there's no way to know if 2 locations are OK (anycast) - there's no way to know for sure that the claimer is the owner Snooping DHCP you expect: - one address per MAC (that's it's pretty limiting but that protects the network) - A MAC address or least a unique ID to differentiate duplicates (but not recognize a thief) - An upper bound for the state lifetime based on the lease Certainly a bad guy doing impersonation and DOS can play havoc in such network, but at least between good guys we get something we can operate. I'm not saying that snooping DHCP is fully deterministic but it's orders of magnitude better than snooping SLAAC when it comes to forming a state like an association than SLAAC. Knowing that you base things like EVPN on such state, using SLAAC is building on sand. Ideally you'd want: - a negotiated contract for a number of addresses with a lifetime, etc - a provable ownership so we route to the legitimate owner and can do SAVI - a sense of mobility so we can route the packets to the latest location - a sense of anycast vs unicast so we can install routing properly based on that - the capability to indicate whether the address should be redistributed, a sense of weight in ECMP, etc... We've done just that, and with that, we're effectively providing a deterministic state that we can redistribute in routing or ARP/ND proxy. In the case of EVPN that gives this: https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling Then again, retrofitting the ND registration for IPv4 addresses is piece of cake, but IPv4 is DHCP only and the pain does not really feel; so people may not be inclined to make the steps for IPv4. To be seen. > > So, by snooping DAD, which is ugly, ARP table can be constructed. A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, start populating the hot-line before you turn the lights on 😊 > > A problem, however, is that there is no ACK above L2, that is, there is no > end to end ACK, which means, if something goes wrong above L2, the result can > be weird. Yes, and all the other things above. E.g., a DAD coming from the wire that is sent over the wireless is not deterministically delivered and a duplicate is often missed. I do not need to continue the endless list do I? Keep safe; Pascal > > Masataka Ohta
Re: IPv6 "bloat" history
Pascal Thubert (pthubert) wrote: You're perfectly correct. This is exactly what the registration would be for. I'm concerned about its adoption that I do not see coming on Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot worse*. You can't expect people still working primarily on v6 have much sense of engineering. * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs. As broadcast/multicast packets are first sent to APs as unicast packets with ACKs, snooping by APs should be reliable at L2. So, by snooping DAD, which is ugly, ARP table can be constructed. A problem, however, is that there is no ACK above L2, that is, there is no end to end ACK, which means, if something goes wrong above L2, the result can be weird. Masataka Ohta
RE: IPv6 "bloat" history
Fun, I had a parallel experience with NEMO that I implemented in IOS. But I mostly read the fate of MIP and NEMO as a lack of ask. Which is similar to the lack of desire today for the uplifts we made to IPv6 as a whole, and ND in particular. Anyway, RPL has a lot to do with what we learned there, including the abstract objective function that yields the metrics you are talking about, typically including things like ETX/ETX^2, RSSI and LQI. So yes, things that make sense eventually emerge. Keep safe. Pascal > -Original Message- > From: William Allen Simpson > Sent: jeudi 31 mars 2022 14:10 > To: nanog@nanog.org > Cc: Pascal Thubert (pthubert) ; Masataka Ohta > > Subject: Re: IPv6 "bloat" history > > On 3/31/22 7:44 AM, William Allen Simpson wrote: > > [heavy sigh] > > > > All of these things were well understood circa 1992-93. > > > > That's why the original Neighbor Discovery was entirely link state. > > > > ND link state announcements handled the hidden terminal problem. > > Also, it almost goes without saying that the original ND tried to handle the > near-far problem. For example, where I'm talking to a far away AP streaming > to the TV in front of me. > > At my home, I've had to wire the TV. Streaming to the AP, then the AP > sending the same traffic over the same wireless band to the TV caused lots of > drops and jitter. > > The near-far problem can be detected and solved. That's the reason for the > Metric field. > > Furthermore, one of the messages in this thread mentioned trying to backport > v6 features to v4. > > We've already been down that road. IPsec and MobileIP were developed for v6. > After quitting the v6 project(s), I'd backported both of them to v4. Like > v6, then they were assigned to others who ruined them. > Committee-itis at its worst.
RE: IPv6 "bloat" history
Don't sigh! You envisioned it and we built it, William. We have IPv6 mesh networks with thousands on nodes per mesh deployed around you. The standard is called WI-SUN. WI-SUN totals millions of nodes deployed in North America; so what you described cannot not only be envisioned as you did, it can be built and deployed at scale, even on low power far reach wireless. The core L3 components for Wi-SUN are RFC 8505 which is your link state ND thingy, RFC 6550 that does the routing over what OSPF called P2MP and which really means non-transitive, and RFC 9010 that redistribute the former in the latter. We are now working on registering multicast, anycast and prefixes in the same model. It's just that the wired world (including operators) are mostly unaware of these capabilities. Whether they are even interested is not a given either. Louis the XVth said "après moi le déluge". I read pretty much the same thing on the list in the recent days as a migration strategy. Certainly, complaining from a comfort zone is a lot easier than acting out to solve the problem. "La critique est aisée mais l'art est difficile" is another good one. I claim that bashing at the IETF for IPv6 as it was 20 years ago is unfair and that a little refresh / resync is in order. If what we produced since in an attempt to solve the issues you describe can help, then ask for it, amend it, say something, so something. Today, decoupling the L1/2 (physical) network from the L3 abstractions of subnet and link is totally doable. This yields a world of possibilities for deployments. For all those (or the very few) who care, there's https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-06 Keep safe; Pascal PS : When I say that DHCP mostly does the trick is not that I like it, but that customers (think EVPN) are reasonably happy with the result, while SLAAC is a lot worse for pretty much the whole collection of its design points, and cherry on the cake, the onlink model. > -Original Message- > From: William Allen Simpson > Sent: jeudi 31 mars 2022 13:44 > To: nanog@nanog.org > Cc: Pascal Thubert (pthubert) ; Masataka Ohta > > Subject: Re: IPv6 "bloat" history > > On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote: > > * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime > that allows to clean up. So snooping it is mostly good enough there. The > hassle is the SL in SLAAC which causes broadcasts and is not > deterministically observable; this problem is specific to IPv6. We already > have the registration to avoid snooping DHCP and SLAAC; yet we do not observe > any adoption in mainline APs and STAs. > > > > [heavy sigh] > > All of these things were well understood circa 1992-93. > > That's why the original Neighbor Discovery was entirely link state. > > ND link state announcements handled the hidden terminal problem. > (That is, where node A can hear node B, node B can hear node C, and node C > can hear node A, but A cannot hear C.) ND LSAs are/were flexible enough to > handle both AP (cell) and mesh (AMPR) networks. > > Thus, it was not reliant on central Access Points. We envisioned mesh > networks were the future. Each node should handle its own discovery and > routing. > > SLAAC is bloat. > > RIPv6 is bloat. > > DHCPv6 is bloat. > > Those are reasons operators have been complaining about IPv6.
Re: IPv6 "bloat" history
On 3/31/22 7:44 AM, William Allen Simpson wrote: [heavy sigh] All of these things were well understood circa 1992-93. That's why the original Neighbor Discovery was entirely link state. ND link state announcements handled the hidden terminal problem. Also, it almost goes without saying that the original ND tried to handle the near-far problem. For example, where I'm talking to a far away AP streaming to the TV in front of me. At my home, I've had to wire the TV. Streaming to the AP, then the AP sending the same traffic over the same wireless band to the TV caused lots of drops and jitter. The near-far problem can be detected and solved. That's the reason for the Metric field. Furthermore, one of the messages in this thread mentioned trying to backport v6 features to v4. We've already been down that road. IPsec and MobileIP were developed for v6. After quitting the v6 project(s), I'd backported both of them to v4. Like v6, then they were assigned to others who ruined them. Committee-itis at its worst.
Re: IPv6 "bloat" history
On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote: * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs. [heavy sigh] All of these things were well understood circa 1992-93. That's why the original Neighbor Discovery was entirely link state. ND link state announcements handled the hidden terminal problem. (That is, where node A can hear node B, node B can hear node C, and node C can hear node A, but A cannot hear C.) ND LSAs are/were flexible enough to handle both AP (cell) and mesh (AMPR) networks. Thus, it was not reliant on central Access Points. We envisioned mesh networks were the future. Each node should handle its own discovery and routing. SLAAC is bloat. RIPv6 is bloat. DHCPv6 is bloat. Those are reasons operators have been complaining about IPv6.
RE: IPv6 "bloat" history
Hello Ohta-san > An ARP table entry can be created when an IP address is assigned during > registration process and destroyed if the registration is invalidated. > > Or, do I misunderstand anything? You're perfectly correct. This is exactly what the registration would be for. I'm concerned about its adoption that I do not see coming on Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot worse*. The IoT world already adopted the registration model, though. Millions of nodes on 802.15.4 radios are deployed to prove it works. We even redistribute RFC 8505 in routing protocols that carry host routes in IoT networks (RPL), which is how we avoid your lookup issue on a wide low power mesh network. Extending the registration to IPv4 is easy, we could even use mapped addresses and be done. But what magic will trigger attention / adoption when adoption is not showing in IPv6? Keep safe; Pascal * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that allows to clean up. So snooping it is mostly good enough there. The hassle is the SL in SLAAC which causes broadcasts and is not deterministically observable; this problem is specific to IPv6. We already have the registration to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in mainline APs and STAs. > -Original Message- > From: Masataka Ohta > Sent: mardi 29 mars 2022 10:57 > To: Pascal Thubert (pthubert) ; nanog@nanog.org > Subject: Re: IPv6 "bloat" history > > Pascal Thubert (pthubert) wrote: > > > I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. > > But to few people in mainstream networks realize what you just said. > > I found, theoretically by reading 802.11 specification, broadcast/multicast > reliability problem and reported to > IPv6 WG about 20 years ago. So, I'm pleased to know that some people > recognize it as a real problem and worked on it. Thank you. > > > It started long long ago with the idea to use inverse ARP for the > > registration, I guess it is still doable but I am not optimistic about > > adoption considering that v6 is a lot worse with more addresses and > > DAD. > > Aren't IP addresses are assigned from APs? Then, the APs can construct ARP > table without actually running ARP or inverse ARP, I'm afraid. > > > We are editing the piece on proxy ARP at this very moment at .11me. > > APs are indeed supposed to proxy both v4 and v6. What is less clear is > > how they form a deterministic state for that. > > An ARP table entry can be created when an IP address is assigned during > registration process and destroyed if the registration is invalidated. > > Or, do I misunderstand anything? > > Masataka Ohta
Re: IPv6 "bloat" history
Pascal Thubert (pthubert) wrote: I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. But to few people in mainstream networks realize what you just said. I found, theoretically by reading 802.11 specification, broadcast/multicast reliability problem and reported to IPv6 WG about 20 years ago. So, I'm pleased to know that some people recognize it as a real problem and worked on it. Thank you. It started long long ago with the idea to use inverse ARP for the registration, I guess it is still doable but I am not optimistic about adoption considering that v6 is a lot worse with more addresses and DAD. Aren't IP addresses are assigned from APs? Then, the APs can construct ARP table without actually running ARP or inverse ARP, I'm afraid. We are editing the piece on proxy ARP at this very moment at .11me. APs are indeed supposed to proxy both v4 and v6. What is less clear is how they form a deterministic state for that. An ARP table entry can be created when an IP address is assigned during registration process and destroyed if the registration is invalidated. Or, do I misunderstand anything? Masataka Ohta
Re: IPv6 "bloat" history
Hello Ohta-San I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. But to few people in mainstream networks realize what you just said. It started long long ago with the idea to use inverse ARP for the registration, I guess it is still doable but I am not optimistic about adoption considering that v6 is a lot worse with more addresses and DAD. We are editing the piece on proxy ARP at this very moment at .11me. APs are indeed supposed to proxy both v4 and v6. What is less clear is how they form a deterministic state for that. Regards, Pascal > Le 28 mars 2022 à 15:55, Masataka Ohta a > écrit : > > William Allen Simpson wrote: > > > After so many times reinventing the wheel, IP uber alles is a > > better goal. Speaking as somebody familiar with the effort. > > I'm afraid you misunderstand my point. > >> John Gilmore recently gave a good history of the ARP origin. > > ARP is perfectly good for CSMA/CD but not so good > for CSMA/CA where broadcast/multicast is unreliable. > > So, with wifi, we should rely on repeated beacon from > base stations for AR of the base stations and rely on > unicast from clients to register them to base stations, > which should act as proxy for communications between > clients, which is a totally different protocol from ARP. > > Without such recognition today, wifi users should be > suffering from some inefficiencies when link is congested, > which is often the case. > > Other link technology should also require AR mechanism > of its own. > > As such, performing AR with IP is not so meaningful. > Worse, even DHCP, which assumes reliable broadcast, > does not work so efficiently over congested wifi. > >Masataka Ohta
Re: IPv6 "bloat" history
William Allen Simpson wrote: > After so many times reinventing the wheel, IP uber alles is a > better goal. Speaking as somebody familiar with the effort. I'm afraid you misunderstand my point. John Gilmore recently gave a good history of the ARP origin. ARP is perfectly good for CSMA/CD but not so good for CSMA/CA where broadcast/multicast is unreliable. So, with wifi, we should rely on repeated beacon from base stations for AR of the base stations and rely on unicast from clients to register them to base stations, which should act as proxy for communications between clients, which is a totally different protocol from ARP. Without such recognition today, wifi users should be suffering from some inefficiencies when link is congested, which is often the case. Other link technology should also require AR mechanism of its own. As such, performing AR with IP is not so meaningful. Worse, even DHCP, which assumes reliable broadcast, does not work so efficiently over congested wifi. Masataka Ohta
Re: IPv6 "bloat" history
On 3/23/22 2:25 AM, Masataka Ohta wrote: William Allen Simpson wrote: Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic. To make "IP uber alles", link-dependent adaptation mechanisms between IP and links are necessary. So, "ND uber alles" is a wrong goal. Meant to reply to this separately. I've implemented on the order of 35+ protocols, most of them predating IP. My first IP implementation was 1979 for the Perkin-Elmer 7/16. The link layer was X.25 to talk to Merit and over Telenet (not telnet -- Telenet was a provider in those days). John Gilmore recently gave a good history of the ARP origin. Note that for PPP, we also had to negotiate a link layer shim. Some folks then grabbed that effort, instead of building their own, resulting in such monstrosities as PPP over Ethernet. After so many times reinventing the wheel, IP uber alles is a better goal. Speaking as somebody familiar with the effort.
Re: IPv6 "bloat" history
On 3/23/22 2:25 AM, Masataka Ohta wrote: William Allen Simpson wrote:   6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol (PIP) had some overlapping features, so we also asked them to merge with us (July 1993). More complexity in the protocol header chaining. With the merger, Paul Francis was saying he was unhappy because PIP is dead. So the merger is not voluntary for him and the added complexity is technically meaningless. He seemed happy at the Amsterdam 1993 meeting, but as time went on he was sidelined. Likewise, I eventually regretted having joined with the others. We lost control of the main ideas. For example, originally V6 was designed to use shortest path first interior routing. All the announcements were Link State, everything was in place. I still wince at the memory of the PARC meeting where Eric stated that RIP was good enough for V4, so it is good enough for V6. Then he was assigned to be my "co-author". So I quit. What you know as Neighbor Discovery was not the original design. Nor was RIPv6 needed. When I was giving a talk at Google 25 years later I was asked why that happened (by a then member of the IAB). A sore spot, long remembered. Committee-itis at its worst. IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop. Then the committees added back the hop by hop processing (type 0). Terrible! Really? But, rfc1710 states:   The SIPP option headers which are currently defined are: Hop-by-Hop Option Special options which require hop by hop    processing Yep, that was one of the reasons I quit. Digging out my files, I'd forked my documents by July 17, 1994. (That's the last date I'd touched them, so it was before then.) RFC 1710 was later. Also, I registered IPvB with Jon Postel. These are all old nroff files, but I could hand format a bit and post things here. Not that it makes much difference today, yet some of my ideas made it into Fibre Channel and InfiniBand.
Re: IPv6 "bloat" history
William Allen Simpson wrote:  6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol    (PIP) had some overlapping features, so we also asked them to merge    with us (July 1993). More complexity in the protocol header chaining. With the merger, Paul Francis was saying he was unhappy because PIP is dead. So the merger is not voluntary for him and the added complexity is technically meaningless. IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop. Then the committees added back the hop by hop processing (type 0). Terrible! Really? But, rfc1710 states: The SIPP option headers which are currently defined are: Hop-by-Hop Option Special options which require hop by hop processing Admittedly, I was also skeptical of packet shredding (what we called ATM). Packet shredding harmed router architecture, not protocols. Many routers are shredding packets internally for no good reason. Instead, ATM-centric view that "all the world will be covered by ATM and global IP could be used only over ATM" harmed protocols including IPv6 a lot. Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic. To make "IP uber alles", link-dependent adaptation mechanisms between IP and links are necessary. So, "ND uber alles" is a wrong goal. Yes, we were also getting a push from Fermi Labs and CERN for very large numbers of nodes per link, rather than old ethernet maximum. And the reason was that they want to use IPv4 and DECNET without being annoyed by *dual* *stack* routers! That's the underlying design for Neighbor Discovery. Less chatty. Just wrong requirement. Large Ethernet segments work poorly by itself. Worse, even if some L3 might be causing additional damages, the damages won't go away if IPv6 is added. Turns out it was the administration's IBM that had been clogging the campus. SNA? Masataka Ohta
Re: IPv6 "bloat" history
Admitting to not having read every message in these threads, but would like to highlight a bit of the history. IMnsHO, the otherwise useful history is missing a few steps. 1) The IAB selected ISO CLNP as the next version of IP. 2) The IETF got angry, disbanded, replaced, and renamed IAB. 3) On the Big-Internet list, my Practical Internet Protocol Extensions (PIPE) was an early proposal, and I'd registered V6 with IANA. I was self-funding. PIPE was cognizant of the needs of ISPs and deployment. 4) Lixia Zhang wrote me that Steve Deering was proposing something similar, and urged us to pool our efforts. That became Simple Internet Protocol (SIP). We used 64 bit addresses. We had a clear path for migration, using the upper 32-bits for the ASN and the old IPv4 address in the lower 32-bits. We had running code. 5) The IP Address Extension (IPAE) proposal had some overlapping features, and we asked them to merge with us. That added some complexity. 6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol (PIP) had some overlapping features, so we also asked them to merge with us (July 1993). More complexity in the protocol header chaining. 7) The result was SIPP. We had 2 interoperable implementations: Naval Research Labs, and KA9Q NOS (Phil Karn and me). There were others well underway. 8) As noted by John Curran, there was a committee of "powers that be". After IETF had strong consensus for SIPP, and we had running code, the "powers that be" decided to throw all that away. 9) The old junk was added back into IPv6 by committee. There was also a mention that the Linux IP stack is fairly compact and that IPv6 is somewhat smaller than the IPv4. That's because the Linux stack was ported by Alan Cox from KA9Q NOS. We gave Alan permission to change from our personal copyright to GPL. It has a lot of the features we'd developed, such as packet buffers and pushdown functions for adding headers, complimentary to BSD pullup. They made SIPP/IPv6 fairly easy to implement. On 3/22/22 10:04 AM, Masataka Ohta wrote: Owen DeLong wrote: IPv6 optional header chain, even after it was widely recognized that IPv4 options are useless/harmful and were deprecated is an example of IPv6 bloat. Extensive use of link multicast for nothing is another example of IPv6 bloat. Note that IPv4 works without any multicast. Yes, but IPv6 works without any broadcast. At the time IPv6 was being developed, broadcasts were rather inconvenient and it was believed that ethernet switches (which were just beginning to be a thing then) would facilitate more efficient capabilities by making extensive use of link multicast instead of broadcast. No, the history around it is that there was some presentation in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast Multiple Access)in general, is multicast capable though not broadcast capable, which was blindly believed by most, if not all excluding *me*, people there. Both Owen and Masataka are correct, in their own way. IPv4 options were recognized as harmful. SIPP used header chains instead. But the whole idea was to speed processing, eliminating hop-by-hop. Then the committees added back the hop by hop processing (type 0). Terrible! Admittedly, I was also skeptical of packet shredding (what we called ATM). Sadly, the Chicago NAP required ATM support, and that's where my connections were located. It should be noted that IPv6 was less bloat because ND abandoned its initial goal to support IP over NBMA. Neighbor Discovery is/was agnostic to NBMA. Putting all the old ARP and DHCP and other cruft into the IP-layer was my goal, so that it would be forever link agnostic. > There is still a valid argument to be made that in a switched > ethernet world, multicast could offer efficiencies if networks were > better tuned to accommodate it vs. broadcast. That is against the CATENET model that each datalink only contain small number of hosts where broadcast is not a problem at all. Though, in CERN, single Ethernet with thousands of hosts was operated, of course poorly, it was abandoned to be inoperational a lot before IPv6, which is partly why IPv6 is inoperational. Yes, we were also getting a push from Fermi Labs and CERN for very large numbers of nodes per link, rather than old ethernet maximum. That's the underlying design for Neighbor Discovery. Less chatty. Also, my alma mater was Michigan State University, operating the largest bridged ethernet in the world in the '80s. Agreed, it was "inoperational". My epiphany was splitting it with KA9Q routers. Suddenly the engineering building and the computing center each had great throughput. Turns out it was the administration's IBM that had been clogging the campus. Simple KA9Q routers didn't pass the bad packets. That's how I'd become a routing over bridging convert. Still, there are data centers with thousand por
