John C Klensin wrote:
...
For most of the cut section, consider that while 'good practice' says to
use names, reality is that too many apps still grab the address for
random reasons.
But, obviously, I'm not understanding something. Could you
explain?
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).
If one believes that a split-DNS is reasonable to build and deploy
(since many exist it seems self evident), then an application should
only see a SL in a DNS response if the query originates in the same
private address region. This again will work fine and the existing
sending rules might cause the stack to order that one first so that any
long-lived internal connections would survive an external renumbering
event.
The place SL starts to have trouble is when a multi-party app does
referrals based on obtained addresses rather than names. Since the app
can't know which parties are on which side of the routing filter, it
can't pass the correct addresses around. (One could argue that if it
passed a name then the split-DNS would return the correct address to the
querier based on his location, but that frequently gets shouted down
based on unreliability of DNS) It is also possible that one of the
participants is only accessible via the private address space, so there
is a failure mode where some participants can see each other while
others can't. This will always be true, and has nothing to do with the
well-known prefix FEC0::.
The other place SL is criticized is for it's intentional ambiguity.
While this doesn't prevent random announcements into the global table,
it does provide a clear bogon for the route filters. Again this is not a
problem until two parties try to route between each other without
coordinating. Since there are 58 bits allocated for local
administration, one would hope that multiple organizations could find a
way to interconnect private networks without conflict. The argument
against this is that people won't do it so we have to force them to
register for some yet to be defined public space that is not routable.
Since we know that ISP's will do whatever the customer pays for, it is
only a matter of time until 'unroutable' prefixes start showing up in
the global table. The intentional ambiguity prevents that.
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. If they are suddenly required to
register for public space for every internal use network, they are more
likely to pick random numbers than tip of the competition. What they
want is space that for all intents and purposes to apps looks like
global space, but they don't have to expose it, know it will be filtered
at the border, and backed up by a filter at the ISP. So for these
purposes there is no need to treat SL as a special case.
Others are looking for a well-known filter than can be embedded in
appliances so they are easy to sell to Joe-sixpack and only accessable
from the home network. There may be apps that want to leverage the
well-known filter to simplfy the life of Joe-sixpack. Consider the case
of file sharing between nodes on an intermittently connected network. If
the mount dropped evertime there was a connect event, Joe-sixpack would
find another product. In this case there may be a reason for the app to
treat SL as a special case, but this is something the app developer
wants to do and is willing to do the extra work to make it happen. There
are complex proposals for RA options, but so far none of them work for
the node that needs to be seen both internally and externally.
We need to get past the arguments that private space == nat, because use
of private space predates nat, and its only relationship is that it
facilitated nat as an address preservation tool. No matter what the WG
does, there will continue to be private space used in various parts of
the network. There will also be filtering in the network, so app
developers have to deal with scope no matter how badly they want to
avoid it. By clearly defining the address range for limited scope use,
applications have the opportunity to use or avoid it at will. If the app
passes names and the split-DNS infrastructure is operating correctly,
there is no need for the app to care about the filters.
If there really is some magic in FEC0::, I am willing to refocus my
drafts from a PI mechainsm to a globally unique address space with no
need to register. Since it results in a /64 per cubic meter 1km deep,
there is no real potential for conflict.
Tony