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. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf