The meaning of the term "namespace" in addressing, computer networking etc.

Established 2009-04-22 Robin Whittle
Last update  2009-07-31  Jump to the update below. But with a new sub-page added 2011-11-02.
../ To the main Ivip page, with background on scalable routing..

To a companion page: ../loc-id-sep-vs-ces/ , added 2010-01-12, on why Locator / Identifier Separation is not the same thing as Core-Edge Separation, and why LISP, in spite of its name, is an example of the latter and not the former.

Added 2011-11-02:

As part of the IETF discussion LISP is not a Loc-ID Separation Protocol, here is a
page lisp-not-loc-id/ on why the LISP protocol does not involve a new namespace and
so why it is not a Locator - Identifier Separation protocol.  See also other threads
around this time, including "The death of John McCarthy - LISP, HIP & GSE".   This
discussion began with criticism of the LISP protocol's name being the same as that of
the LISP programming language.  To this discussion, Brian Carpenter add:

Especially since the IETF "LISP" is a misnomer; it is not a
locator/identifier split. It's a global locator to site locator
mapping. This was pointed out some time ago...

Version 08

The first version was 01.  To see an older version xx, use this directory name with index-xx.html added.  Please don't link to these.
Please suggest improvements and let me know your critiques. I will incorporate them, link to them or note them in some way.


>>>  Summary

>>>  Background and links to mailing list discussions

>>>  Formal definitions of the term "namespace"

>>>  IRTF Name Space Research Group (NSRG) ca. 1999 to 2003

>>>  IRTF use of the term "namespace" in RFC 3869

>>>  Use of "namespace" in Noel Chiappa's late 1990's endpoints.txt and other documents


The exact meaning of the term "namespace" has been the subject of debate on the LISP mailing list in March 2009.

This page is primarily an attempt to analyse previous uses and definitions of the term "namespace" in contexts similar to the current discussion.

Other than the particular uses of "namespace" which I am critiquing, I can find no use of the term which is incompatible with the definition I assume for it.  So I see no reason to believe there is some other significantly different definition of the term.  I found two uses of the term which I regard as "misuses", one of them only a borderline misuse.  It is typical to find terms occasionally misused, or used in a way in which their meaning in the sentence tends to resemble something for which another term would be more apt.  But that doesn't suggest to me a meaning different to the widely accepted meaning was intended.

The best definition I can find is listed below #best. Since the people who used the term "namespace" regarding LISP in ways I am critiquing have not yet supplied an alternative definition, I stand by my critique of these specific instances.


Background and links to mailing list discussions

I think the term "namespace" has been used incorrectly in some discussions regarding the Internet's scalable routing problem - in a way which is misleading to the reader.  I am not suggesting this was done on purpose, but since scalable routing is hard enough to understand, I am keen to identify what I regard as mis-statements which would, ideally, be corrected.  

The concern I have is that there have been explicit claims that LISP (which I assume is intended to be a practical solution to the routing scaling problem) would or may involve separate namespaces for "Locators" (RLOCs)  and "Identifiers" (EIDs).  My current critique is linked to immediately below #20090319 .  First, I link to discussions which precede this.

Sometimes this has been explicitly stated about LISP when I am sure it is not the case (assuming LISP is to be a practical solution to the routing scaling problem) .  In other cases I think the the term "namespace" is used in a way regarding LISP which implies there are separate namespaces for RLOCs and EIDs - but which could simply be misusing the term namespace as if it was a synonym for "range of addresses" or something similar.  For instance, is a range of addresses, or subnet, within the IPv4 global unicast address range, but it does not have a separate namespace from the IPv4 global unicast namespace.

I first raised this in the Routing Research Group (RRG) in 2007:

[RRG] draft-irtf-rrg-design-goals-01  RW 2007-07-14

Other messages along these lines were:

Re: [RRG] On "jack-down" models  RW 2008-03-16

[RRG] Hosts, DFZ, purity & incremental deployment  RW 2008-03-17

There were some threads:

Re: [RRG] On "jack-down" models - independent namespaces  RW 2008-03-18  Tony Li  << Well worth reading  RW

[RRG] Not separate namespaces: Loc-ID-separation, map-encap etc.  RW  2008-0727 << This discussion is specific to LISP.  Dino Farinacci  Brian Carpenter  Dino Farinacci  RW    

#20090319 On 2009, on the LISP list:

Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp)  RW 2009-03-19  (Suggested changes to LISP WG draft Charter)

Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces (and some other threads)
msg00273.html  RW 2009-03-18  Current Critique part 1
Including links to two current LISP I-Ds, an IETF Journal article, a NANOG presentation and a mailing list message which all state or imply that LISP involves separate namespaces for EIDs and RLOCs.
msg00274.html  Noel Chiappa
msg00275.html  Dino Farinacci
msg00288.html  RW 2009-03-19  
msg00289.html  Dino Farinacci
msg00290.html  RW
msg00291.html  Dino Farinacci
msg00292.html  RW Current Critique part 2, with links to where I think namespace is used incorrectly, including in two LISP Internet Drafts.
I should also have mentioned two other presentations which are currently linked to from the LISP site which state that LISP involves separate namespaces for EIDs and RLOCs: (2008-03) (2008-05)

Both of them state:

Why Separate Location from ID?
  Level of Indirection allows us to:
    Keep either ID or Location fixed while changing the other
    Create separate namespaces which can have different allocation properties

msg00293.html  John Zwiebel
msg00294.html  Sam Hartman  (Co-chair of forthcoming LISP WG.)
msg00295.html  Sam Hartman
msg00296.html  Scott Brim
msg00298.html  RW  << More specific now: The IPv4/6 global unicast namespace.
msg00299.html  Sam Hartman

Links to this discussion continued below.

As part of this discussion, Sam Hartman wrote( msg00299.html 2009-03-20), in part:

You've presented one definition of namespace.  I strongly suspect that
there are a lot of other definitions floating around and that the term
was being used loosely. I have not seen a lot of support for your
strict definition of namespaces. However, I think that addressing
Bryan, Lixia and Margaret's concern needs to be addressed by making
this distinction clear. I think that avoiding the term namespace or
defining what we mean by namespace will be more productive than an
argument over its definition and whether we have found the clearly
correct definition for our field. At least as I understand it, your
proposed charter text change in this area seems to do this.

#20090322 In response I wrote this web page, wrote to the LISP list and continued the discussion:

msg00307.html  RW 2009-03-22  I can find only one definition of "namespace"
msg00309.html  RW

msg00310.html  Noel Chiappa
msg00325.html  RW, including a "mathematical" argument why LISP etc. can't be practical with different namespaces for EID and RLOC.

msg00332.html  Noel Chiappa, stating that he believes that one IP address ("bit pattern") could be used both as an EID and as an RLOC:

So if it's _possible_ to use the same bit pattern as
both an EID and an RLOC, 
my guess is people will do it,
no matter what the documents say. And my take
is that,
because of _other_ concerns (e.g. limiting routing
overhead), it 
will be technically possible, which means
people probably will do it no
matter what we say in any

msg00335.html  RW:  Noel has yet to explain how one IP address could be used as an EID and as an RLOC.  The statement that a single address would typically not be used in both EID and RLOC roles is not strong enough.

msg00336.html  Sam Hartman
Sam states "the rough consensus of the participants so far is that there will be cases where the same IP stands both as an EID and a RLOC."
This can only work if there are separate namespaces for EIDs and RLOCs - read on where I disagree that rough consensus can be seen to exist via the list messages.

msg00338.html  RW 2009-03-25 "Consensus? EID and RLOC use of the same address = separate namespace debate"

msg00339.html  RW 2009-03-25 "EIDs MUST NOT be used as LISP RLOCs." (Quoted from draft-farinacci-lisp-12 .)

msg00356.html  John Zwiebel ("This does not say you can't use the same IP address for an EID and for an RLOC.")

msg00365.html  Sam Hartman ("What do you mean that no EID is also an RLOC?  It's not clear to me that in interworking cases this is always true.")

msg00367.html   RW Response to above 2 messages and a link to a new LISP presentation  lisp-2.ppt which mentions separate namespaces.

msg00368.html   Dino Farinacci

msg00369.html   RW

msg00370.html   RW Response to Dow Street's suggested changes to draft Charter which discusses namespaces.

msg00371.html   RW (2009-03-26) Radio silence on the LISP list for a week.

On the LISP, IETF and IESG lists:

msg00380.html   Sam Hartman - draft Charter for review by IESG after discussion on LISP list and in IETF 74 meeting.

(The next 3 are on the IETF list.)

msg56375.html  RW (2009-03-30) Links to previous drafts.  Draft still contains erroneous statement about EIDs potentially being used as RLOCs.

msg56378.html  Sam Hartman.  Noting (correctly) that LISP list participants do not support my critique.

msg56379.html  RW  (2009-03-31)     No-one has shown how using an EID as an RLOC could work or where it is allowed for or required in the LISP I-Ds.

Latest messages here:

#20090730 The debate sprang up again on the LISP list in late July 2009:

msg00747.html  RW (2009-07-30) to Noel Chiappa.

msg00748.html Noel Chiappa responds, referring to the Mobile LISP I-D, which I critique here and in other messages in that thread.

msg00751.html  RW (2009-07-30):  "EID" and "RLOC" are roles - they have never been and are not separate namespaces.  Before Mobile LISP, the set of addresses which could be used in an RLOC role was disjoint from the set which could be used in an EID role.  With Mobile LISP, these are potentially overlapping sets.

Five messages and my reply:

msg00752.html  Dino Farinacci
msg00753.html  Noel Chiappa
msg00754.html  Scott Brim
msg00755.html  Noel Chiappa
msg00756.html  Dino Farinacci

msg00771.html  RW

Formal definitions of the term namespace

The word namespace does not appear in the dictionaries I have to hand: Macquarie Australian Encyclopedic Dictionary 2006; Concise Oxford 1982 or Websters International Dictionary 1890.

The earliest books in Google Books (search term) I could find which used "namespace" in its modern, data-processing sense, were Artificial Intelligence volumes from 1969.  (A 1918 Act of Parliament in Britain here used the term to describe something about ticking a candidate's name on a ballot paper.)

Readily accessible web-based definitions are:

As a noun:  A conceptual space that groups classes, identifiers, etc. to avoid conflicts with items in unrelated code that have the same names.

(I think that in this context, "code" means computer program source code.)

In general, a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allowing disambiguation of items having the same name (residing in different namespaces).

As a rule, names in a namespace cannot have more than one meaning, that is, two or more things cannot share the same name. A namespace is also called a context, as the valid meaning of a name can change depending on what namespace applies.  ...

#best The following seems like the best definition I have encountered:

A namespace is an abstract container or environment created to hold a logical grouping of unique identifiers or symbols (i.e., names). An identifier defined in a namespace is associated with that namespace. The same identifier can be independently defined in multiple namespaces. That is, the meaning associated with an identifier defined in one namespace may or may not have the same meaning as the same identifier defined in another namespace. Languages that support namespaces specify the rules that determine to which namespace an identifier (i.e., not its definition) belongs.

For example, Bill works for company X and his employee ID is 123. John works for company Y and his employee ID is also 123. The reason Bill and John can be identified by the same ID number is because they work for different companies. The different companies in this case would symbolize different namespaces. There would be serious confusion if the two men worked for the same company, and still had the same employee ID.  ...

However, for the last section, I would write:  The different companies in this case both use numeric names for employee numbers, but each company has a different namespace in which those numbers are interpreted.

Some definitions in formal documents:

Namespaces in XML 1.0 (Second Edition) W3C Recommendation 16 August 2006
.. An expanded name is a pair consisting of a namespace name and a local name. ... (BCP 33)

URN Namespace Definition Mechanisms
  For the purposes of URNs, a "namespace" is a collection of uniquely-assigned identifiers.

All the above references concern namespace within the context of either computer programming or the process of a system deciding which of multiple namespaces within which to interpret text strings.

Google supposedly finds 39,000 pages in which mention the term namespace - so it is widely used in this field.  Generally, it seems, it is used for names which are textual, including URNs  and DNS names.  I was unable to find a formal IETF definition of the term.  

IRTF Name Space Research Group (NSRG) ca. 1999 to 2003

The archived Charter for the NSRG is:

The NSRG was a closed group, with no public mailing list archives, apparently started in 1999.

The latest version of their I-D is from September 2003:

According to the RFC 3869 (below) and here , the NSRG did not reach sufficient consensus to make a final recommendation, so the above mentioned expired I-D is all that seems to remain from this work.

The above mentioned I-D does not contain any definition or use of "namespace" but there are several uses of the term "name space", with no definition.  In a separate page, I highlight these: irtf-isrg/

IRTF use of the term "namespace" in RFC 3869

In this RFC, from August 2004, "namespace" is used in a manner which enables some inferences to be made about the meaning the authors ascribed to it:

IAB Concerns and Recommendations Regarding Internet Research and Evolution
Here is some of the text:

3.2. Naming

   The Internet currently has several different namespaces, including IP
   addresses, sockets (specified by the IP address, upper-layer
   protocol, and upper-layer port number), Autonomous System (AS)
   number, and the Fully-Qualified Domain Name (FQDN).  Many of the
   Internet's namespaces are supported by the widely deployed Domain
   Name System [RFC-3467] or by various Internet applications [RFC-2407,

3.2.1. Domain Name System (DNS)


3.2.2. New Namespaces

   Additionally, the Namespace Research Group (NSRG) of the Internet
   Research Task Force (IRTF) studied adding one or more additional
   namespaces to the Internet Architecture [LD2002].  Many members of
   the IRTF NSRG believe that there would be significant architectural
   benefit to adding one or more additional namespaces to the Internet
   Architecture.  Because smooth consensus on that question or on the
   properties of a new namespace was not obtained, the IRTF NSRG did not
   make a formal recommendation to the IETF community regarding
   namespaces.  The IAB believes that this is an open research question
   worth examining further.

   Finally, we believe that future research into the evolution of
   Internet-based distributed computing might well benefit from studying
   adding additional namespaces as part of a new approach to distributed

Use of "namespace" in Noel Chiappa's late 1990's endpoints.txt and other documents

Noel Chiappa's unpublished draft of an Internet Draft is cited in a number of documents and mailing list discussions.

Its only location on the Net seems to be at his old site:

Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture
Noel Chiappa  (If it disappears, let me know, I have a copy here.)

There are at least 44 instances of the word "namespace" in this document and in my view, they are all entirely consistent with the definitions above.

For example:

2 Terminology of Naming and Binding

    Before proceeding to the technical details, it is important to
understand some definitions about objects, names, and related subjects.

    The terms "object" and "name" are hopefully self-explanatory:
it is crucial to differentiate between the thing itself, and any
identifier (in the generic sense) by which we refer to it. In this
paper, whenever the term "name" is used, unless otherwise explicitly
indicated, the meaning given to it is the generic one of "an identifier
(of no specific syntax or properties) for an object".
    Thus, the phrase "name of a host" does *not* refer to an
existing system of printable strings (e.g ""), or somesuch;
it refers, instead, to the abstract concept of an identifier for a
host. (The term "host-name" is used to refer to such printable strings,
at the possible risk of some confusion, because it is of long-standing
use in the networking community.)

    This may seem confusing (and some might suggest use of a
different term for "name"), but the use of the term "name" in this
manner is established in the literature (along with subsidiary
terminology such as "namespace"), and while use of the term "name" has
perhaps been confused in the networking community, it seems a major
distraction to try and tackle that issue now.

2.1 Bindings and Namespaces

    The association between a name and an object is called a
"binding"; bindings may also map from one kind of name for an given
object, to another name.
    It is important to realize that a single instance of an object
(i.e. a member of an "object class") may have more than one name.
Moreover, each of those names may be drawn from the same class of names
(or "namespace"), i.e. a many-to-one binding; alternatively, each of
the names may be from a different namespace, i.e. multiple one-to-one
    For example, the person writing this document is an instance of
the object class of humans, and has several names, from different kinds
of namespaces, such as his 'name' name ('J. Noel Chiappa'), his Social
Security Number (a government supplied personal identification number
in the U.S.A.), etc. However, all the names refer to the same object;
the author.

2.2 Structure and Representation of Names

    The *form* of the names in a namespace is usually driven by the
use to which the name will be put. Any structure in the name is usually
intended to make some operation on or with the name (be it looking it
up in a directory, or whatever) easier. For example, Unix filenames and
DNS names have hierarchical levels, indicated in the name, to allow
them to be looked up in hierachical directories. IP addresses have
structure in them to help them be routed.
    Names may also have multiple "representations", or ways of
encoding the same individual name. For instance, the IP address
"" (in decimal, printed notation) is the same exact name as the
bit string "00010010 00001000 00000000 00001000" in an IP packet
header; they are just different ways of encoding the exact same
information, just as 12 base 8, and 10 base 10, are the same number.

    A collection of bindings in which a system records and looks up
the connections is called a "context" (sometimes loosely referred to as
a "directory", although this term has other meanings). A context may
either map from names for objects to a direct attachment to the object,
or from one class of name for an object to another kind of name for the
same object, or perhaps some other useful mapping.

3 Existing Objects and Namespaces in the TCP/IP Architecture

    The TCP/IP architecture did not make a clear distinction
between objects and the names of those objects; it also used basically
those namespaces which were in the existing NCP protocol architecture;
i.e. addresses, and host-names.

3.1 IP Addresses

    In fact, however, IP addresses are basically the *only* name
used throughout the TCP/IP architecture, however. They are:


3.2 IP Host-Names

    The other existing namespace in the TCP/IP architecture is that
of host-names. Host-names were, and remain, fairly peripheral in the
TCP/IP architecture. Host-names are human-readable strings, which now
contain built in hierarchical structure, and can be looked up in a
distributed, replicated, database called the Domain Name System
[Mockapetris], which maps from DNS names to IP addresses.

#misuse1 Here is what I consider to be a misused of the term, from 1993 or 1994:
A New IP Routing and Addressing Architecture
J. Noel Chiappa

The only namespace for nodes which appears to be useful is a
relatively short, fixed length, pseudo-flat binary identifier.

I think this is a misuse of the term according to the definitions above. The sentence concerns the format of the names, which is quite a different concept from the more abstract notion of a namespace as providing context by which names can be interpreted.  For any given format, such as a 32 bit binary number, and including for any particular way of structuring the meanings of the 2^32 individual names in this range (such as "flat" = without hierarchical structure), there could be multiple separate namespaces by which names of this format could be given meaning.  In practice, the only prominent namespace in computer networking for 32 bit binary numbers is the IPv4 namespace.

Another usage which seems to be consistent with the definitions above is:
        One proposal is that each network attachment point be given a unique
binary flat identifier; this would allow the creation of multiple,
independant, structured namespaces (i.e. address spaces), each of which have a
separate mapping into the first namespace which identifies all attachment
points. The claimed advantages are that it would be possible to experiment
with new addressing schemes, or introduce a new one, or even operate with
several different ones in use at the same time. 

#misuse2 from 2009:

While I think Noel used the term perfectly well in this recent message I think the following use is both technically correct but also tending to depict the namespace, at least where the name are a binary number, as a linear range or space which can be subdivided.  This is from 2009-03-18 :

a chunk of namespace might be allocated to an organization, but it might
further subdivide that chunk, and allocate one part to an office in one
location, and another part to an office elsewhere.

I am not at all trying to criticize Noel or what he wrote.  Just pointing out that like many terms, "namespace" can sometimes be used in ways which may be technically wrong, but look sort-of OK, or which are technically correct but also suggestive (to me at least) that in some way the word is being used as a synonym for something else, such as a "range of" addresses within a linear "space".

(Noel has been contributing highly detailed analysis on namespaces and Internet addressing since before I had ever heard of the Internet.)

My point is that these occasional borderline or (I think) incorrect usages of the term do not indicate there is another meaning for the term.  It is just too loose a use of the term.

In my critique of LISP I-Ds, I think the term has been used so loosely as to be misleading in the context of the highly precise language expected in an I-D.

In my critique of the IETF Journal article, an old 2007 NANOG presentation about LISP-CONS  and the mailing list message, I believe the statements are just plain wrong.  There is no evidence of there being another meaning of "namespace" which is compatible with these statements being truthful.  The usage is either extremely sloppy or ill-informed, since in all my efforts to understand LISP and the widely accepted meaning of "namespace" I cannot see that a practical application of  LISP to the scalable routing problem really could involve separate namespaces for EIDs and RLOCs.