Re: IP namespace

Thomas Johannsen <> Thu, 14 May 1992 13:11 UTC

Received: from by ietf.NRI.Reston.VA.US id aa00761; 14 May 92 9:11 EDT
Received: from by NRI.Reston.VA.US id aa04676; 14 May 92 9:17 EDT
Received: from [] by NRI.Reston.VA.US id aa04670; 14 May 92 9:17 EDT
Received: from JP-GATE.WIDE.AD.JP by with Internet SMTP id <>; Thu, 14 May 1992 07:13:50 +0100
Received: from by (5.65+1.6W/2.8Wb-jp-gate/1.2) with SMTP id AA28646; Thu, 14 May 92 15:13:38 JST
Received: from ([]) by (4.1/2.7W) id AA02593; Thu, 14 May 92 15:13:34 JST
Received: from by (4.0/6.4J.6-92/2) id AA26006; Thu, 14 May 92 15:13:33 JST
Received: by (4.1/6.4J.6-91/1/29) id AA00266; Thu, 14 May 92 15:13:32 JST
Date: Thu, 14 May 92 15:13:32 JST
From: Thomas Johannsen <>
Return-Path: <>
Message-Id: <>
Subject: Re: IP namespace

> > 
> > 2) Below o=IP we have non-leaf-entries for each IP address group
> > (according to A, B, C class adresses).  [ ... ] Within the proper
> > class address you'll find all (valid) IP [addresses[ [ ... ]
> > 
> (2) is much better (or at least, it is what I had in mind :-)). I'm somewhat
> puzzled by your characterizing it as an alternative to a separate hierarchy,
> because if I understood (2) correctly, you've described a separate hierarchy
> that happens to be rooted at someplace other than the root of the DIT. 

Your interpretation is right, my term wasn't well thought.

> I only have one little quibble with (2) which is that I still think
> there is insufficient hierarchy. If I understood what you're suggesting
> in (2) correctly, you're proposing carving up the IP address space
> into three large subtrees, respectively for class A, B, C addresses.
> Underneath each 'subtree' is again a large flat space containing
> all addresses in that class. My objection to the large flat space are
> the same as in (1).

No, I have another thing in mind. Each network address (within class A, B, and
C)  would get its own subtree.

E.g.,, ..,, ..., would
all be non-leafs ("sub"s). 

These non-leaf-entries are immediate subordinates of the "IP namespace root"
and hold themselves only leaf entries (node-IP-addresses). 

                        o=IP (or whatever you like)
        I            I                                  I
   sub=   sub=  .....sub= ...
       I                                I                  I
    +--+------+                  +------+----              I
    I         I                  I                         I
IP= IP= .......IP= IP= ...

> What little thinking I've done on this subject has however been along
> the lines of (2) except that I want to carve up the namespace into
> a hierarchy so that subtrees corresponding to a IP network can be delegated
> to the 'owner' of the network assignment. 

And here we meet on the question of delegating each subtree to its owner (might
he run a DSA or not).

> 	(a) that scheme has a lifetime that will hopefully
> 	    be measured in months due to the big-internet work
> 	    on classless, enormously scaleable IP addressing and
> 	    routing. There are already discussion within the
> 	    DNS context as to how to carve up INADDR.ARPA in the
> 	    future, and by going this route, we're essentially
> 	    investing in a scheme that could easily be obsolete
> 	    by the time it is deployed.

I've heard there is something going on. Making IP addresses classless should not
be a problem for the scheme. I'd appreciate any structure telling me what a
subnetwork is and expressing this in the name. 

> 	(b) you end up with interior nodes like and 
> which don't really 'belong' to anybody but
> 	    are instead public resources. This is a minor problem
> 	    which could easily be handled the same way we're handling
> 	    the infrastructure between national nodes and organizational
> 	    nodes (in the case of the U.S. these would be the 
> 	    U.S. state/equivalents and the U.S. counties within states),
> 	    but is a problem nonetheless.

There should be some network center doing the maintance. But actually I didn't
think about that problem before.

> 	(c) by representing IP addresses by their byte components,
> 	    some semantic information is lost, for example the
> 	    fact that 128.1 (just to pick an example) is a network
> 	    in its own right, and that it is not the case that
> 	    128.1 is a subnet of a larger network This
> 	    only gets worse when the Internet stops 'hard coding'
> 	    in distinctions between network-component and host-component

To stress my point once more: I'm *not* going to have a multilevvel tree like

    .....   .. ... ...

because there is no use in asking "what belongs to". 

I hope I made myself clear now. Sorry for the not very well chosen explanation
last time :-)

> [That said, this is still closest to the ideal for me, since I can't think
>  of anything better at the momement.]

Does anybody come up with a better solution?

> Wengyik