[Folks who are not interested in the details of the IPv6 WGs discussion of
site-local addressing can just hit 'd' now.]
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
This paragraph ignores the fact that site-local addresses in IPv6
were intended to be used quite differently from RFC 1918 addresses
in IPv4. The two biggest differences are:
(1) In IPv4, RFC 1918 addresses are used for isolated networks and/or
networks behind NAT boxes. So, it is uncommon for a single node to
have both RFC 1918 addresses and IPv4 global addresses, and there
is typically no need for applications to choose between them (either
for connection establishment, or when deciding what addresses to transmit
to peers, etc.). However, in IPv6, it was expected that many nodes would
have both global and site-local addresses, and that site-local addresses
would be used on globally-connected networks.
During the IPV6 meeting in SF, we did discuss several options for
limiting the use of site-local addressing, but all of those options
had some sorts of problems associated with them.
(2) RFC 1918 addresses are most commonly used behind NATs. In this case,
there is a middle box that performs translation of those addresses into
global addresses at the site boundary, both in IP headers and at the
application layer (through ALGs). In IPv6, we hope to avoid NAT. Site-local
addresses were expected to be used on globally connected networks without any
Packets to/from site-locals (in the IP headers) would have been dropped, but
there was no explanation of how leaking of IPv6 site-local addresses at the
application level would have been prevented at site borders. One solution
would have been to use some ALG-equivalents in site-border routers that either
translated or dropped the traffic, but that wasn't really
the assumption seemed to be that applications just wouldn't include site-local
addresses at the application layer in any packets that might go outside of the
site. This required some sort of address selection logic in applications.
If one believes that a split-DNS is reasonable to build and deploy
(since many exist it seems self evident),
There is a difference between believing that split DNS is reasonable to
deploy and believing that it is a good architecture for the Internet.
While folks may be quite capable of deploying split DNS, it results in
a more brittle and complex Internet architecture, and I don't think
that we should build an IPv6 addressing architecture that requires it.
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.
Exactly. There are many of these applications defined within the IETF,
by other standards bodies, and/or developed by private enterprises.
In fact, the applications area folks assure me that there are more of
these types of applications deployed than there are simple client-
server applications (that was news to me). IETF applications that fall
into this category include FTP, SIP and (in some uses) HTTP.
(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)
Maybe... There has been a great deal of reticence from application
developers to rely on DNS look-ups for this type of referral, and
it is not all based on DNS reliability. There are many, many nodes that
either do not have a DNS entry or do not know their own DNS name, and
many applications need to work on those nodes.
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::.
True. Any firewall can create this situation. I do understand that folks
will use firewalls and create private address spaces in IPv6. Hey, I even
think that folks may deploy IPv6<=>IPv6 NAT, because there is really nothing
we can do to stop them.
However, I don't think that we should design these sorts of borders into
the IPv6 addressing architecture.
As you know, I was in favor of setting aside a prefix (FECO::, in fact)
for use as private address space (either on disconnected networks, or
behind NATs), but the consensus of the folks in the IPv6 WG meeting
was to deprecate that prefix altogether. There were several compelling
arguments from operators and others that we don't need a special prefix
for disconnected sites... Disconnected sites will need to renumber when
the get globally connected, anyway, and ISPs already have the proper
filtering in place to prevent mistakes from affecting the global
routing tables, etc.
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.
For this purpose, there is no need to have site-locals at all...
The organization can just get a /48 from a provider, ask the provider
to route part, all or none of it, and use any private (non-routed) parts
however they like. I doubt that there are many organizations (other
than the NSA, perhaps) that are afraid that their competition will know
how many subnets they have at the granularity of 2^16... (Ooh, IBM just
asked for another /48 from their provider, what can we infer from that?)
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.
I don't think that anyone is making the argument that private space