> Its not that 'we don't want to change because its to much work'. Its > that the Internet architecture assured us that the hour glass model > applied, that the network topology would remain abstracted within what > to us is an opaque address space. One of the number one reasons its so > easy for new application layer technologies to be deployed is that a > developer doesn't need to know or care about any layer below TCP (or, in > rare cases, UDP). If the lower layers want to change that hour glass > model then we're talking about a serious breach of contract with the > layers above it and a dangerous blow to the hour glass model. This is a good sounding story, except that it's never really been true. You could choose to ignore the topology of the network, and ignorance works much of the time. Way back in the dark ages, it was not uncommon to have multi-homed HOSTS: one leg on the ARPANET, the other arm on some local LAN segment. The application and/or network stack on that machine was left with a decision to choose which interface address it ought to use when binding some local association endpoint address. It's "easy" when the other end is on the same network; e.g., directly attached. The Internet architecture never gave the end system some mechanism to help it make this binding decision when trying to communicate with non-local peers. There are hacks in implementations; like the local resolver having some sorting policy for the A records returned when doing a DNS query, with the assumption that the application was going to try them in turn. But that was just a hack. There was no protocol to ask the network "which of address should I use to talk to this remote end system?" So here we are today, a couple of decades later, with the promise of a different type of end-system multi-homing (having multiple addresses on a single) interface due to IPv6 multi-provider multihoming with provider specific addresses, and still no means to decide which of the alternatives are preferable when deciding to launch some traffic into the network. Adding one more site-local address doesn't make this problem any harder to solve, I think. louie