Måns Nilsson via NANOG wrote on 01/05/2026 06:30:
2. The construction with so many fascinating moving pieces, some crypto related, combined with a good portion of state in middle boxes is an architectural and scaling disaster.
I recognise this: RFC 1925, section 5:
(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
Also, see sections 4, 6, 6a, 7, 7a, 8 and in particular, sections 11 and 11a:
(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
(11a) (corollary). See rule 6a.
There's nothing new about locator/identifier protocols. We have LISP today, and it works to some degree. It doesn't scale, but sometimes it's good to design, document and build this style of architecture, even if only to show that it doesn't scale. Which bring the discussion back to RFC1925: "it's always something". There's no such thing as a free lunch. In the case of this so-called "ipv8" idea, it's defining a new protocol with a larger address size in the packet header, which despite claims like "I'm trying to be backwards compatible at the FIB level" is not backwards compatible at the FIB layer, and never will be. It will require silicon redesigns, and retooling IP communication stacks to handle the new protocol spec. Sure, there's an indirection layer, but that's not the same thing as backwards compatible. Maybe a better term would be "interoperable to some extent in specific circumstances. T&Cs apply". Skimming around on some randomly-selected text:
Second, the destination ASN is validated against the WHOIS8 registry -- if the destination prefix is not registered as an active route by a legitimately registered ASN holder the packet is dropped. These two steps together eliminate the primary malware command-and-control channel: connection to hardcoded IP addresses without DNS resolution.
The author really needs to think about this a bit harder. or this:
A route that cannot be validated is not installed.
Refusing to install non-validated routes might look like a good idea from a superficial point of view, but all it does is show that the author hasn't thought very hard about the consequences. For example, how do you handle network cold start, i.e. non-primed caches? What happens if your cache session disappears? Low level protocols sit at the bottom of the networking stack. Things are different there and you can't depend on stuff higher up in the stack working the way you might expect it to, because the higher-up stuff only works when the lower-down stuff has established connectivity. If you confuse this, it ends in tragedy. Or there's this:
IPv8 extends OSPF8 [RFC2328], BGP8 [RFC4271] (both iBGP8 and eBGP8), and IS-IS8 with a unified path quality metric -- the Cost Factor (CF).
CF is a 32-bit accumulated metric derived from seven components measured from TCP session telemetry: round trip time, packet loss, congestion window state, session stability, link capacity, economic policy, and geographic distance as a physics floor.
There's some fundamental confusion going on in this paragraph about routing protocols. For starters, it's a bit odd to suggest that you can distill seven separate and entirely independent parameters plucked arbitrarily from multiple different layers up the protocol stack, and somehow flatten them into a single linear 32 bit integer in a way that preserves any meaning. And why seven metrics? Why not eight, in order to include my favourite metric which is missing? Or nine, to include someone else's favourite metric. And how are they calculated? It's really hard to look at a list like this without wondering if it's network design or numerology. That's ignoring the fact that is-is/ospf are link state protocols and ibgp is distance vector, i.e. they do different things in specific contexts. Or this:
For a neighbor recorded as IPv8-capable, the sender constructs a full IPv8 packet:
Where is the definition of the neighbor discovery and capabilities protocol which allows hosts to record which devices are "IPv8-capable"? These are all things randomly plucked out of the text on the basis of: "let's scroll down a couple of pages and see what's written there". I haven't seen anything worth salvaging in the doc. To be honest, I haven't read the entire doc because the bits that I've read look more like they were thrown together on the basis of "this seems like a good idea; into the pot you go". This isn't how protocol design works. Nick