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

[vinton cerf]

inline - a couple of comments

On Wed, May 20, 2026 at 4:22 PM Dave Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> 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..)
>
well, could one argue the endpoint at the IP layer gets you to the host,
TCP gets you to a process and after that it is an application layer
question?

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

>
> 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.
>
yes that was a very valuable notion - not unlike the telco demarc.

>
> 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.
>
A colleague applied for an AS to make his dual homing work

>
> 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?
>
it doesn't in the sense that the routing isn't done on that identifier in
the case of the Internet.
The routing is done on the basis of IP address.

>
> 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
>
> dhc at dcrocker.net
> bluesky: @dcrocker.bsky.social
> mast: @dcrocker at mastodon.social
> +1.408.329.0791
>
> Volunteer, Silicon Valley Chapter
> Northern California Coastal Region
> Information & Planning Coordinator
> American Red Cross
> dave.crocker2 at redcross.org
> --
> 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
>