[ih] Why did location/identity separation not happen? (Was: Internet without entrenched factions?)

Tue May 19 03:57:41 PDT 2026

Trying to reconstruct some of the discussion [could be faulty memory here]

Given the net/host structure as an "address", one can imagine a routing
table with entries of the form "net/host" and doing a lookup in a FIB to
see what the next hop is. I know I had that pretty clearly in mind. I also
had in mind that a host could be connected to more than one network and
that somehow, a packet destined for that host needed to be delivered to the
right spigot on that host. Maybe "to the right spigot" is where the
reasoning was weak? The domain name concept, mapping names into host/net
addresses derived from the earlier host.txt files of the Arpanet and
supported the possibility of multi-homing if the mapping revealed more than
one destination net/host address for a given host. Ironically, especially
with the arrival of the WWW, a single net/host address could be the
destination for more than one domain name.

What apparently seemed clear to me at the time is the the table could just
as well have had an "end-point ID" and that the forwarding table could have
end-point IDs in them. The routing system (think BGP, IS-IS, etc) would
need to speak somehow to the topology of paths that could reach that
endpoint. But then the question of scalability arose. If the end-point ID
space were flat, the routing tables would not have hierarchy to support
compressed representations of the topology of the global system.  The
scaling question continued to nag me and the notion of autonomous systems
each with an internal and external routing mechanism (IGP for intra-AS and
BGP for extra-AS) mirrored the original Internet networks (Arpanet, SATNET,
PRNET) which had internal routing capability and address spaces and relied
on "gateways" to help Internet packets find their way to a destination. The
global routing system needed to know what sequence of gateways would lead
to the destination network. A multi-homed host would have different
addresses depending on the path taken to the destination network. If there
is a flaw in this reasoning, it may be the notion that a network (AS) is
the destination. If the notion of destination had been framed as "ID of
destination host" the other routing choice might have been more obvious.
The flat name space of end-point IDs still raised the question how the
routing tables would scale. By 1981 I was well into trying to promote the
existing implementations to various computer manufacturers, etc, so making
a major change at that point seemed to serious impede progress. Most hosts
were single-homed and domain names could map into multiple net/host
addresses if necessary for hosts with more than one network address.

v

On Tue, May 19, 2026 at 4:22 AM Greg Skinner via Internet-history <
internet-history at elists.isoc.org> wrote:

> Comments inline
>
> On May 17, 2026, at 4:02 AM, Noel Chiappa via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> >> From: Ole Troan
> >
> >> Back to history. IPv6 should have had identifier/locator split from the
> >> start. I wasn't there, but I understood it was close with Mike O'Dell's
> >> 8+8 and GSE proposals? Anyone who can shed more light on what happened
> >> and why that path was not chosen?
> >
> > I wasn't paying very close attention by then, so I don't know for sure
> why
> > 8+8/GSE didn't get support, but I would guess that it was for many of the
> > same reasons that earlier attempts to add location/identity separation
> to the
> > internetworking architecture (i.e. the 'basic, high-level picture', used
> in
> > the Internet) failed to catch on.
> >
> > Those, I believe, I am very well qualified to muse about, since I'm
> pretty
> > certain (if my memory is failling me in this, which might well be
> possible, I
> > hope someone will correct me) was the first person in the Internet
> technical
> > community (which was, at the time, pretty well entirely encompassed in
> the
> > IETF/IRTF groups) to suggest, and push, adding separation of location and
> > identity to that architecture.
> >
> > (The basic idea, of course, originated with Jerry Saltzer, in his paper
> "On
> > the Naming and Binding of Network Destinations". As soon as I saw it, I
> > realized the crucial flaw in the then-current internet architecture
> which it
> > pointed out, and took steps to get it re-published as an RFC - RFC 1498
> - to
> > make it easily accessible to the Internet technical community; it had
> > originally been published in a somewhat obscure journal. I can't
> remember if
> > Jerry provided me with a machine-readable copy of the text, for that; I
> have
> > a vague memory that that had been lost, and I had to re-type it all from
> a
> > hard copy.
> >
>
> I found a Local Network Note that is very similar to RFC 1498 that is
> dated 3 March 1981. [1] (More on this later.)
>
> > Also, the version of the idea that I pushed had one major change from
> Jerry's
> > original: he had proposed recognizing four classes of entities -
> "services,
> > nodes, attachment points, and routes [i.e. paths]". Dave Oran suggested
> to me
> > (in a conversation at a meeting in LA, if memory serves - the memory is
> still
> > fairly vivid) that physical hosts were the wrong thing, it needed to be
> > something more abstract, and I instantly saw the correctness of his
> point.
> >
> > I drew on Clark's original "fate-sharing" thinking, used in the early TCP
> > work, to replace 'node/host' with 'endpoint' - defined as "a fatesharing
> > region" ("a boundary drawn around a set of state and/or computations such
> > that it lives or dies as a unit"), which is "one participant of an
> end-end
> > communication" ("the fundamental agent [in] end-end communication").
> Excerpts
> > here are from:
> >
> >  http://chiappa.net/~jnc/tech/endpoints.txt
>
> > "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet
> > Architecture". )
> >
>
> I had to go to the Internet Archive to access this paper. [2]
>
> > Anyway: what, from my perception, were the reason(s) that separation of
> > location and identity failed to catch on in the Internet technical
> community?
> > It can, I believe, be put, whimsically but pithily, as 'there were too
> many
> > programmers in that technical community'. (This may irritate people; I
> don't
> > care, I'll be gone before too long. I don't say it to irritate _anyone_,
> but
> > because I believe it is accurate.)
>
> > Whhaaatttt? […]
>
> > To less whimsically explain what I said at the start , I think the vast
> > majority of the members of the IETF technical community could only see
> the
> > value in a significantly new direction if they had seen it fully
> constituted,
> > in a working system.
>
> IMO,  this is not unreasonable, especially if those programmers answer to
> managers who have to deal with practical constraints, such as budgets.
>
> Anyway, back to RFC 1498, since these issues were known at the time the
> TCP and IP IENs that preceded their corresponding RFCs were written, what
> did other people in Saltzer’s group think about this?  For that matter,
> what did DCA think about this?  Were they ever approached with any of these
> concerns, such as how much more difficult mobility, etc. would be without
> location/identity separation?
>
> Finally, it seems to me that the LISP project has taken this up. [3] Is
> that not sufficient?  They seem to have support from industry, working
> code, use cases, etc.  Maybe it’ll be more widely adopted.
>
> --gregbo
>
> [1] https://web.mit.edu/~saltzer/www/publications/lnn/csr-lnn-028.pdf
> [2]
> https://web.archive.org/web/20070112102344/http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt
> [3] https://www.lispers.net
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>

-- 
After July 1, Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102

Until July 1, send postal/overnight deliveries to:
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 650-224-2788