North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: references on non-central authority network protocols

  • From: batz
  • Date: Sun Apr 14 13:40:50 2002

On Fri, 12 Apr 2002, Patrick Thomas wrote:

:I am looking for any and all research (and perhaps your comments),
:references, etc. regarding replacements for the TCP/IP protocol that do
:not require centralized authority structures (central authority to assign
:network numbers).

I think this could use some explaining, as 'centralized' is a pretty 
relative term, even in todays Internet. ARIN, APNIC, RIPE and others(?) 
would qualify as non-centralized, because there is more than just
one of them. If you are in a geographic area served by one of them, 
then you might think it is centralized.  I would say the same for
DNS in its current mutation. 

However, from what I would speculate you are trying to find information
on, you might want to look at the DoD protocol stack, decide what
layer you really need this decentralized functionality on, 
and then see if existing P2P network technologies might fit your 

By looking for a network protocol that doesn't require registration 
authorities, or some sort of enrollment process which would manage
addressing conflicts, you will run into one of two inevitable 

The first being that to ensure reachability, you will need a lower
layer protocol encapsulating your decentralized one (think of it
as a social contract), as communications protocols aren't terribly 
useful when you can't see or talk to anyone.  

The second being that you will have to dispense with the
possibility of unique identifiers, and accept the conflicts 
inherant in the collisions this causes. It is up to you 
to decide if this is consistent with the requirements of 
your protocol. 

Someone mentioned that people could simply generate their own 
"addresses" using public keys, which is theoretically possible, 
but we've seen how that works in usenet, where for one person
to send an encrypted message to another, their message has to be 
propagated to absolutely everyone for the intended recipient to read it. 
It doesn't scale.  

Multicasting doesn't solve this either, as you have to register 
as part of a group to recieve the broadcasts. It's efficient, but
you still have this issue of registration authorities to enroll you
in a multicast group. 

So, as far as getting rid of centralized authority on a network, you 
just have to redefine "centralized" to mean something less 
abstract and more connected to the community of users, and redefine
"authority" as a service instead of an administrator.  

You also have to decide what level you want that service to take place:
Process, interface, segment, subnet, route, ASN, route, subnet, segment,
interface, process. :)