Re: [tae] The internet architecture

Bryan Ford wrote:

> To throw in my quick $.02 (and perhaps invite more discussion :) ), I
> think we absolutely need to migrate both networking APIs and transport
> layer protocols themselves toward a model where an "endpoint" is an
> opaque (to the transport/application) variable-length string of some
> kind, and the transport/application shouldn't even care much if any what
> exactly the string is.  The string could potentially be a DNS name, a
> dotted IPv4 address, a colonificated IPv6 address, a hex-encoded HIP
> cryptographic host identifier, a UIA personal name, ...  And sure, the
> semantics of these different kinds of "endpoint strings" will vary
> depending on what they actually are, and for network management purposes
> they won't all be equivalent or interchangeable, but for purposes of
> normal transport and application protocol operation - i.e., "gimme a
> TCP-like connection to the endpoint named 'X'", why should transports
> and applications need to care?  

Sigh.  Maybe this is unfair, but it seems to me that people keep wanting
to take (relatively) straightforward, bulletproof interfaces and replace
them with fragile ones that depend on extra layers of indirection, and
additional services that (a) can fail, (b) don't share fate with the
endpoints and (c) are likely to be very sensitive to configuration
errors, all for the sake of some notion of architectural purity.

I won't claim that you can't do it, or that it's a fundamentally bad
idea on its face.  I *will* claim that it's a fundamentally bad idea if
you don't do very careful engineering on it to make sure that the
resulting system is as reliable was it would be without the extra layer
of indirection - and that includes accounting for the ability of people
to misconfigure things.

> Just think how much easier the IPv4 to IPv6 transition would have been if nothing above the IP layer cared
> exactly what an IP address looks like or how big it is.

It wouldn't have made much difference at all, partly because due to
other warts in the IPv6 architecture (like the desire to push the cost
of multihoming to all endpoints rather than the core [*]), applications
have even more need to deal directly with addresses in IPv6 than they do
in IPv4 - even in a pure IPv6 world.

The other reason it wouldn't have made much difference is because
transitioning applications to IPv6 is actually much easier than
transitioning networks.

Keith

[*] Not that I blame the routing guys for wanting to move the cost of
multihoming out of the core.  But pushing those costs onto hosts and
applications was moving those costs even further away from those who
benefit from multihoming, than was the case in IPv4.

_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae