Re: IPv8 / BGP8 / CF

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
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/H34JOOHJCFJI536V2MMBN6VJYO72WRUH/