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

Sun May 24 22:10:25 PDT 2026

 Not sure whether to put this message here or under the packet radio thread. 
Going back a little a further in time..
Packet Radio also incorporated new ideas on addressing: it used logical addressing.  The PRU (Packet Radio Unit)'s address was hardwired (Assigned at manufacturing so it was unique and had global scope).  Things like hosts, TIUs, stations, and gateways/routers were attached devices that had an ID.   lt sounds like the ID for the attached devices was determined/created automatically and probably only local in scope (This is my best guess and I haven't found any corroboration yet). The radios had a device table that stored which radio had which attached device. PRUs learned about attached devices from data packets and a supporting protocol. I also think the device ID number space was divided up so you knew the kind of attached device by its ID.
So consider the radio address/ID as the location. The attached device ID is location agnostic. If a packet reached the last radio in the route and the device was no longer attached, the packet would be dropped. FYI, I never tried moving attached devices to different radios in the network but the protocols were designed to handle this case.
I also think device handling in packet radio may have changed over time as the protocols matured. The reference (1)  given below, and used in this email  to help my memory, is from the time of  the SURAN program( LPRs). When I left BBN, I thought SURAN was going to use CAP 7 (stationless) from the packet radio program as the starting point for its protocols. The SURAN  protocols were called SURAP (SUrvivable RAdio Protocol)  My recollections make me want to confirm what was in the radio versus what the station did to assist the radios, especially regarding attached devices.  I haven't been able to find the relevant documentation.
I also found this statement interesting.
"In addition, the PRNET offers generic logical addressing. Generic addressing allows a device to request service from any other device in a general category, e.g., any name server or any gateway. The packet is addressed to an ID that may belong to more than one device. The network will deliver the packet to the closest device with the requested generic ID." (1)
Sounds like anycast doesn't it?

While we are on this topic, this SRI technical report in DTIC might be of interest. 
"Name Assignment in Computer Networks", Raphael Rom
https://apps.dtic.mil/sti/html/tr/ADA123854/(Don't forget to scroll down if you don't see anything about the report.)
1) Jubin, John and Tornow, Janet."The DARPA Packet Radio Network Protocols", Proceedings of the IEEE, Vol. 75, No. 1.,  January 1987.
barbara      On Wednesday, May 20, 2026 at 07:59:57 PM PDT, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:  
 Some comments on this topic.
I believe the Reconstitution Protocol (RP) relied on separating location and identity (ADA184755 in DTIC if you lost the reference to the final report). Section 3 (Background) might be the most interesting section for this discussion.  

Here is another reference I just tried to find to see what it might say about the thoughts/design behind RP but  I wasn't successful.  I don't recall ever seeing this paper even though i worked on RP (gateway portion).
Z Su, JE Mathis, "Internetwork accomodation of network dynamics: Naming and addressing", Proceedings of 7th International Conference on Computer Communications, pp. 681-685, November 1984.
If someone finds/has a copy, please let me know.
When I joined the RP project. I am pretty sure Jim Mathis told me we couldn't visibly change the IP protocols.  i think the solution tried in the RP experiments reflects this constraint. I always wondered where that requirement originated as I  thought IP protocols were still experimental. In RP we changed how the IP address was created (gateway-centric for location component)  and added RP gateways that could supply the information needed to keep TCP connections working in a dynamic environment (routing and support for host/endpoint IP address creation). Things still worked for non RP hosts and gateways which was a requirement.
It has been a long time since i thought about and did work in this area. I must admit i am not familiar with the ILNP documents (pretty much out of the IETF  for quite some time) so i just started to take a look. I noticed there is no reference to RP in RFC 6740. I feel I would need to spend a lot more time to understand the contribution/differences  as compared to RP. However  I did notice a few things off the top of my head. In particular, this RFC says
  "The key idea proposed for ILNP is to directly and specifically change
  the overloaded semantics of the IP Address." 

To me this is pretty much what RP did. I can see what i think are probably going to be area of differences, like whether both endpoints need to be involved. (BTW, if both endpoints need to be involved how does a host determine whether another host supports ILNP in a mixed environment? Do you even need to know this???? I didn't see this discussed but that could be my fault.
In this RFC, i also saw this statement when i was trying to find more info about what a locator actually is.
"Locator values are used only at the network layer. Locators are not used in end-to-end transport state. For example, Locators are not used in transport-layer session state or application-layer session state." I don't understand this statement because of the TCP pseudo header used for the TCP checksum computation in V4 and V6. The TCP pseudo header includes the source and destination IP address. Did i misinterpret how the ILNP IP address will be constructed and disseminated in the IP packet header based on my knowledge of how RP works (no address length change required and the information for source and destination is in the same space used by the current addresses) 
Also it seems to me that for V6, fragmentation/MTU should be discussed in the ILNP documents.  I haven't seen anything looking very quickly. For those not familiar with V6, fragmentation occurs at the source. In V4 it is done in the router/gateway. FYI, I have heard Path MTU Discovery doesn't work because of choices made in deployments of technology.   I discovered other people are looking into this problem but not sure if/how these new ideas impact this work.
Does this design really require what i think look like fundamental changes and so perhaps not backward compatible/transparent with current implementations of IPV4 and IPv6? Is there a document that specifically covers some of my questions that I overlooked it somehow in my quick search?
Some other slightly random thoughts. 
I  think RP relied on the trustworthiness of all components (Redirects weren't questioned for example).  I can't remember knowing much regarding creating the end point portion of the protocol. I am thinking along the lines of whether RP made sure that another entity in the network didn't already have, or recently used, what would be used in the IP address field for a new device in that network. 
I wish i still had RP details in head. My memory could be wrong. I also didn't join the project at the beginning (Working on the Navy Ada gateway)   so i am sure i missed more discussions on  the design and  associated protocols.  
In case you are wondering why you can't find some kind of write-up on this effort as a PRTN, Packet Radio program probably ended 2 or 3 years earlier.  I am guessing no more submissions could be made to this series of documents .
In an  earlier email on this list, we already have had a brief exchange regarding the apparent decision that dynamic dns was not going to be addressed in the early 80s. Dynamic DNS was brought up at a packet radio meeting in 1983.
Composed this on my cell phone. Hope there aren't too many bugs in this message.

barbara

    On Tuesday, May 19, 2026 at 03:58:07 AM PDT, Vint Cerf via Internet-history <internet-history at elists.isoc.org> wrote:  

 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
-- 
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

-- 
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