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

On 5/19/2026 3:57 AM, Vint Cerf via Internet-history wrote:
> Ironically, especially
> with the arrival of the WWW, a single net/host address could be the
> destination for more than one domain name.

Any third-party hosting service is likely to do this.

Hence, any multi-tenant email gateway service displays a version of 
this.  Certainly the CSNet gateway did.

Before the domain name system was deployed, this was instantiated with 
something akin to 2-level source routing.  But that was no longer 
necessary with the deployment of the MX construct.  So, circa 1985 and 
before the Web.

I don't know whether the gatewaying that PARC did, early on, qualified 
as an even earlier example.  Integrated enterprise-oriented processing 
typically wouldn't, except for differential handling, depending on 
sub-domain.

btw, note that most advertising that gives a domain name typically gives 
it as www...., although that is typically no longer needed.  Except 
sometimes.



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

End-point has always been an intuitively appealing, but IMO problematic, 
term.  Is it an interface?  A host?  An application? (And which layer of 
an application service?  I always thought of an email address as 
defining an endpoint.  Until I dealt with EDI over email, where the 
receiving email inbox was only an intermediary, and an EDI identifier 
indicated that ultimate end-point..)

The Irvine Ring was nifty for using application id's in the interface 
table, but no, that probably wouldn't scale even in an enterprise, 
never-mind a global Internet. (I took it as significant that MIT's 
adoption of the Irvine Ring included dropping the name table.)

Name, address, route is not just a set of constructs.  It describes a 
sequence that needs to happen, one way or another. Having Domain /Names/ 
be referred to as Internet /addresses/ suggests that sometimes portions 
of the sequence can be a matter of operational use, rather than mapping 
to new information.  (Name at one level of handling; address at another.)

Jon Postel's being stuck with me as an office-mate made him my permanent 
explainer of networking concepts. This included his noting that the TCP 
and IP checksums were intentionally very weak.  Partly to limit the 
overhead on hardware of the day, but also because they were intended for 
end-to-end use in a network that is largely reliable.  That is, as 
needing only occasionally to detect the lost of a packet.

In a network segment with more serious problem, he suggested, a stronger 
and more responsive mechanism would be needed.

It's worth wondering whether TCP/IP would have been designed differently 
if the end-to-end experience were typically much less reliable.  I'm 
guessing the easiest path would have been a standardized reliability 
link layer, below IP, independent of whatever was native to the segment.

Anyhow, this distinction between local-vs-global mechanisms made (and 
makes) a lot of sense to me.  Including for routing and relaying. So any 
discussion of design should make the distinction and deal with it 
explicitly.  What is the global mechanism?  What does it rely on, for 
local handling?  How is that local handling achieved?

Not being a routing guy, I've assumed that Routing Table vs. FIB are an 
example?



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

You describe the use of the construct for routing, but I think it has 
another distinctive benefit.  Namely institutionalizing authority 
boundaries.

This is lacking from other services, except indirectly.  For email, MX 
can be taken that way, but note that there is nothing in a domain name 
to mark the boundary.  (But then, neither is there anything in an IP 
address.)



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

Perhaps it did not anticipate the extent of service intermediation or 
the scale of it that develop.  (And, perhaps, while the Internet 
architecture learned to be cautious about what it relies on from the 
infrastructure, it might still rely on too much, at least sometimes?)

So... my home network is dual-homed.  To two, independent ISPs. Through 
NATs.  I don't have an A/S.  I am not aware of any capability, deployed 
as scale, that deals with that model usefully.

Yet I suspect there should be.  And clearly not down in the deep 
infrastructure.  (Hence my bias towards a session-layer mechanism, above 
TCP.)



> If the notion of destination had been framed as "ID of
> destination host" the other routing choice might have been more obvious.

When someone makes a point like this, I always ask why domain name does 
not or should not serve that role?

There is usually a claim that the construct needs to be at a lower 
level, but I've never fully understood why.

d/

-- 
Dave Crocker

[email protected]
bluesky: @dcrocker.bsky.social
mast: @[email protected]
+1.408.329.0791

Volunteer, Silicon Valley Chapter
Northern California Coastal Region
Information & Planning Coordinator
American Red Cross
[email protected]
-- 
Internet-history mailing list
[email protected]
https://elists.isoc.org/mailman/listinfo/internet-history
-
Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history