The IPv6 WG putting a "MUST" in a spec does not put code in
a router. There are already implementations of IPv6 that
do not "black-hole" this set of TBD globally-unique, provider-
independent addresses, so our solution must not depend on all
routers black-holing packets to/from these addresses.
In order to be useful, globally-unique/provider-independent
addresses need to be routable. To be maximally useful, the
routing boundaries for these addresses need to be set by
administrators, not automatically enforced at specific routing
protocol (or other) boundaries. Different sets of addresses
should also be able to have different boundaries -- I might
have one prefix for local traffic within the marketing
department (folks who can use the fancy printer), one set
that is local to the company, and one that is local to my
customer/client extranet, for example. Unlike the current
site-local proposals, this would work because the addresses
are not ambiguous, and a longest-match selection would
result in choosing an address in the same local prefix for
communication with another local address in that prefix.
But, how would that work with DNS? Good question -- I'm
still working on an answer... :-).
I understand the concern about "leaking" these addresses, but
I think that some folks may misunderstand the impact of
leaking at different levels. There are concerns associated
with:
- leaking these addresses in the DNS
- leaking these addresses in upper-layer protocol
packets
- leaking these addresses in routing protocols
- leaking packets to/from these addresses across
intended boundaries.
All of these issues are present for any sort of private addressing,
and I don't think that the use of globally-unique local addresses
will significantly complicate any of these issues.
I think that we should stop calling these addresses "site-local",
as that is prone to confusion. We would create a separate set
of globally-unique/provider-independent (GUPI? Pronounced
"guppy" or "goopy", depending on how much you like them? :-))
addresses for use as local addresses in Internet connected sites.
We could still have site-local addresses (FECO::/10), which can be
used for disconnected networks (and perhaps other cases -- we
haven't really decided how widely to use them yet). If we limit
them to disconnected sites, they could be treated exactly like
global addresses by all nodes. If we also allow them to be
used on connected networks (for intermittently attached networks,
for example), we probably want to change the default address
selection rules to prefer globals (of both sorts) over SLs.
Margaret
At 03:56 PM 11/23/2002 -0800, Michel Py wrote:
Christian,
This is a more detailed version of what I proposed a month ago. I will
emphasize that we need something more than a MUST in an RFC to enforce
this: We need the site-local black hole and the site-local BGP route
discard to be *default* configuration in routers, and to be impossible
to remove by accident. This is no big thing to do for router vendors to
implement, we just need to reach consensus on it.
Michel.
-----Original Message-----
From: Christian Huitema
Sent: Saturday, November 23, 2002 10:37 AM
To: [EMAIL PROTECTED]
Subject: Enforcing unreachability of site local addresses
One of the point in the discussion of the "globally unique" site local
addresses has been the discussion of their usage. In particular, if the
new addresses are globally unique, how do we prevent them from being
globally routed and creating a mess in the global routing tables; and,
on a related note, how do we make sure that they are actually local?
The issue is clearly complex. There are legitimate scenarios in which
two sites might want to create some kind of backdoor connection
independent of any ISP connection, in a way similar to the various
"extranet" scenarios that are common today; it could also be used in a
merger situation. There are also illegitimate scenarios in which a
powerful customer would pressure an ISP to simply advertize their
globally unique /48.
I believe that Bob Hinden provided the beginning of the answer when he
proposed that all routers would have a default black-hole for the site
local prefix. The implementation would be the following:
1) In a local site, advertise the subnet routes in the IGP, possibly a
default route for the site, and a black-hole for the site local prefix.
This guarantees internal connectivity to the valid subnets, and
unreachability for all other sites.
2) In an extranet scenario, import in the IGP an explicit route for the
"friendly" sites, and point it to the specific backdoor connecctions to
these sites. This will override the blackhole.
3) At a border router, discard all BGP route that point to the site
local prefix or subsets of it.
4) At a site border router or firewall, perform ingress filtering and
discard all externally sourced packets in which the source address
pretends to belong to the internal site.
The combination of 1 and 3 presents a powerful disencentive against the
"leakage of routes" risk: a powerful customer might pressure a local
ISP, but that would be to no avail since the packets would be dropped by
the next hop. I believe that the combination of the four rules will
provide the desired locality benefits without having to resort to
ambiguity as an enforcement mechanism.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
