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 any
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
IPv4 w/1918).
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 not valid.
, 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 deploying
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.
