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