Subject: RE: Enforcing unreachability of site local addresses

From: "Michel Py" <[email-masked]>
Date: Sat, 23 Nov 2002 15:56:01 -0800

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-masked]
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-masked]
--------------------------------------------------------------------

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Nov 2002 19:56:09 -0500

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

---

From: Mark Smith <[email-masked]>
Date: 24 Nov 2002 12:36:18 +1100

> addresses for use as local addresses in Internet connected sites.

Firstly, let me say that I'm a "guppy" type person :-)

I agree renaming or creating a different allocation than fec0::/10 would
be a good idea.

However, I think it is important to ensure that the name implies that
these GUPIs are only supposed to be used in an aquarium (of any size),
rather than the deep blue ocean.

Maybe they could be "internal, globally-unique, provider-independent"
addresses or IGUPIs ("iguppy" or "igoopy"). (I'd prefer globally-unique,
provider-independent, internal" address space - but GUPII is not as good
sounding acronym :-) ).

I think the DNS issues might be a bit simpler as well :

1) If the DNS returns an IGUPI address, the device assumes it can get to
it, and lets ICMP dest unreachables or connection timeouts tell it
otherwise. The device's IGUPI address would be used as the source
address.

2) If the DNS returns a global address, the device assumes it can get to
it, and lets ICMP dest unreachables or connection timeouts tell it
otherwise. The device's global address would be used as the source
address.

As for the source address of the DNS request itself :

1) If the DNS server address is a global address, the device uses its
global address as the source address. This would be typical for a
residential user for example.

2) If the DNS server address is a IGUPI address, the device uses its
IGUPI address as the source address. This would be typical for an
enterprise / corporate user for example.

A DNS server may have to return either a global or IGUPI address based
on the source address of the request, for a single query. Still, with
only two types of destination addresses, and IGUPIs probably preferred
over globals, I don't think it is all that complicated.

(sorry about using the IGUPI acronym I came up with in the above, just
doing a test drive on it, seems to work ok, at least for me anyway :-)
).

Mark.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 00:06:06 -0500

> addresses for use as local addresses in Internet connected sites.

I've started calling them PIGs for Provider Independent Globals :)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 27 Nov 2002 13:35:24 +0100

> global addresses by all nodes.  If we also allow them to be

Ok, I am behind on email....

....but how on earth did we end up in this discussion? From what I 
remember of the voting in Atlanta we had consensus for a limited 
version of site-locals...not creating a separate address structure? I 
mean if we are concerned about an allocation for GUPI we could use ::/0 
right? It's not going to leak to the Internet anyway....

- kurtis -

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 12:25:33 -0500

> version of site-locals...not creating a separate address structure?

as I recall, we had consensus for limiting site-locals,
as well as widespread support for the idea that PI globals were needed.

it's not an either-or.

Keith

---

From: "Alan E. Beard" <[email-masked]>
Date: Wed, 27 Nov 2002 12:54:24 -0500 (EST)

> as well as widespread support for the idea that PI globals were needed.

My memory of the discussions accords with the summary given by Keith
above.  In addition, the general tenor of the discussion indicated to me
that the two issues were linked: that consensus on limiting site-locals
was contingent upon initiation of an effort to design a workable scheme
for privately-routable PIs, with the global routing of PIs left for
subsequent discussion.

AEB

-- 
Alan E. Beard
<[email-masked]>
AEBeard Consulting
4109 Chelsea Ln
Lakeland FL 33809
863.815.2529

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Nov 2002 22:14:28 +0000

> as well as widespread support for the idea that PI globals were needed.

if my memory serves me right we had consensus on limiting site-locals
somewhat, i.e not pushing multi-site support.

we also had consensus that _working_ on non-routable global PI
addresses sounded like an interesting idea.

until we see some real proposals on the table, there is nothing to
reach consensus about with regards to GUPIs.

/ot

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 17:45:52 -0500

> somewhat, i.e not pushing multi-site support.

e.g. perhaps.  not i.e.   the question wasn't nearly that precise.
(which is part of why I objected to the question being asked in that way)
 
> addresses sounded like an interesting idea.

again, I think that's a slight rephrasing.  this question wasn't 
precise either but there was clearly widespread interest and belief
that global PI addresses would relieve some of the burden on SLs.

> reach consensus about with regards to GUPIs.

nobody is claiming consensus on any specific GUPI proposal yet -
we're still trying to figure out what the issues are and the 
general shape of something that might fly.

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Nov 2002 10:57:31 +0900

>>>>> On Wed, 27 Nov 2002 22:14:28 +0000, 
>>>>> Ole Troan <[email-masked]> said:

> addresses sounded like an interesting idea.

This is exactly what I have as the result of the meeting.

> reach consensus about with regards to GUPIs.

I agree.  And, as the chairs just suggested, what we need at this
stage is a concrete proposal as an internet-draft.  I guess we have
had enough discussion and we don't need more on the list.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------