There is a lot of noise about treating SL special, but as you note an
application can ignore that a 1918 address is somehow different from
other address. If an application were to do the same and just use a SL
as any other address, it will work just fine until one of the
participants is on the outside of the filtering router (also true for
for multiparty apps, the probability that this will happen is within
epsilon of 1.
If one believes that a split-DNS is reasonable to build and deploy
(since many exist it seems self evident)
no. there are lots of unreasonable things in this world. split DNS is
a hack that works only in limited situations, and even then it doesn't
work well. it makes assumptions about application behavior that are
, then an application should
only see a SL in a DNS response if the query originates in the same
private address region.
DNS is irrelevant. you can't fix SLs by fixing DNS, even if you could
fix DNS, which you can't. it's not reasonable for a DNS server to
assume that the party making the query is the party that will use the
address. actually DNS caching depends on DNS producing consistent
results no matter who is making the query, and DNS caching is not don't
exclusively by DNS servers.
This again will work fine
bzzzt. wrong again.
The place SL starts to have trouble is when a multi-party app does
referrals based on obtained addresses rather than names.
which is a perfectly reasonable thing to do. it's how the Internet was
designed to work.
One reason that some people like private space is that they don't have
to expose to their competitors what internal networks they are
and which office is coordinating that.
there are far better ways to solve that problem than by crippling apps.
We need to get past the arguments that private space == nat,
no that's not the problem. the problem is that scoped addresses are
dysfunctional. NAT has nothing to do with it.