Subject: Globally Unique Private Addresses and Scoped Architecture

From: "Michel Py" <[email-masked]>
Date: Tue, 8 Apr 2003 11:32:05 -0700

Charlie,

> Charles E. Perkins wrote:
> I think we should concentrate on defining a set of unique,
> provider-independent == non-aggregable addresses to fulfill
> the needs of those who had wanted to use site-local addresses.

:-)

> We would also specify that the default-free zone MUST NOT
> contain routes for such addresses.

Indeed, but this is not going to be enough. A "MUST NOT" policy alone
can not enforce the public un-routability of private addresses. The only
way to make sure that addresses are not routable on the public Internet
is to suppress the demand for routing them. There currently is a strong
and unfulfilled demand for globally routable PI.

Example that works (WRT to being un-routable on the public Internet that
is): RFC1918. Although we occasionally see these on the public Internet,
it's due to misconfiguration. No customer is going to see their upstream
and offer them money to leak or route RFC1918 addresses, because it
achieves nothing (because RFC1918 addresses are ambiguous). No demand,
no routing. Since what we are talking about here is to remove ambiguity,
we must provide a replacement for what ambiguity provides in terms of
enforcing the non-public-routability.

Example that would not work without add-ons: Allocate a block of regular
addresses (let's say, 2003::/16) to the purpose of globally-unique
non-globally-routable addresses. This will create the demand from
end-sites to go to their providers and indeed ask them to route them to
be used as non-aggregatable PI, with the result of routing table bloat.

What is required in order to get globally-unique, non-globally-routable
addresses are three things:
- Policy: the default-free zone MUST NOT contain routes for
  such addresses. 
- Default blackholing: some strong normative language mandating
  implementations (vs. policy) to blackhole by default routes
  traffic for the private prefix.
- Some kind of architectural limitation such as site-local
  + scoped architecture.

The combination of all three is required:
- The policy alone is not enough because ISPs will take the customer's
money at the risk of being labeled as bad boys.
- The normative language alone is not enough as we have no way to force
implementers to code it.
- The architectural limitation alone is not enough as one will likely
come up with a dirty hack to route SLs globally if need be. For example,
globally routing site-locals will likely force the network
administrators to hack the scope of site-locals to make it global, but
again this alone would not be a big enough a deterrent compared to
having global PI.

A combination of any two would not be a powerful enough deterrent
either.

What we are dealing here is risk management. The risk is that the good
intention of globally unique private addresses is transformed into the
bad situation of global unaggregatable PI. Zero risk does not exist, and
the only way of lowering the odds of this happening is to put so many
hurdles on the way that it won't effectively happen. To this effect, the
proposed deprecation of site-locals is a serious blow as it suppresses
the architectural limitation and therefore creates demand for sites to
pay their ISPs to "forget" to filter their prefixes and transform a
non-routable globally unique prefix into a de-facto routable globally
unique prefix.

Why do site-locals provide that architectural limitation: because even
if a network administrator changes the scope of his/her site-locals to
global, it's not enough to make them work, as lots of destination sites
would keep the default scope and dump the return traffic to a site-local
address.

In other words, with site-locals and scoped architecture, what is
required to transform Globally Unique Site Locals into global PI is:

{
   {
      1) Almost NONE of the implementations compliant with the
      default blackholing requirement.
         = and =
      2) Almost EVERY provider passively violating the "default-
      free zone MUST NOT contain routes for GUSL" policy.
   }
      = or =
   3) Almost EVERY provider actively violating the "default-free
   zone MUST NOT contain routes for GUSL" policy by configuring
   their routers to ignore the default blackholing.
}
   = and =
{
    4) Almost NONE of the implementations making scope checks
    resulting in almost ALL of them allow forwarding traffic
    to a site-local address outside of the site.
       = or =
    5) Almost ALL network administrators hacking the scope of
    their site-local addresses to global.
}

As I said above there is no zero risk but the above conditions look
pretty bad. Remove 4) and 5) and it instantly becomes a tempting target.

Site-locals are not the only way, but {1,2,3} above are not sufficient
deterrents meaning we have to provide a replacement for {4,5}.

Michel.

--------------------------------------------------------------------
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: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 09 Apr 2003 13:55:53 +0200

> enforcing the non-public-routability.

when IPv4 customers come to their ISP and offer them money in order to 
route RFC 1918 addresses to places the customer is not directly connected 
to, we usually call the result a provider provisioned VPN.

Demand seems widespread.

So if we roll out globally unique non-routable addresses, we should not be 
at all surprised to see that ISPs will actually route them if offered 
enough money; it's simpler (and therefore cheaper) for them than 
configuring a VPN.

(of course this only works in v4 if the two ends have coordinated their RFC 
1918 deplyment plans. There are a lot of cases when they do.)

                      Harald

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 Apr 2003 17:39:05 +0700

Date:        Wed, 09 Apr 2003 13:55:53 +0200
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | when IPv4 customers come to their ISP and offer them money in order to 
  | route RFC 1918 addresses to places the customer is not directly connected 
  | to, we usually call the result a provider provisioned VPN.
  | 
  | Demand seems widespread.

Yes, this is fine, there's nothing wrong with this, and no reason not
to support it.

  | So if we roll out globally unique non-routable addresses, we should not be 
  | at all surprised to see that ISPs will actually route them if offered 
  | enough money; it's simpler (and therefore cheaper) for them than 
  | configuring a VPN.

They don't need to be globally unique for this, just unique within the
relevant domain (area).

  | (of course this only works in v4 if the two ends have coordinated their RFC 
  | 1918 deplyment plans. There are a lot of cases when they do.)

Yes, of course.   And with SL addresses, with 2^38 different numbers to
choose from (instead of the 256 + 16 + 1 in 1918 - plus subnets of those
"classful" numbers) all it takes is sane guidance to make this trivial
in all but the rarest/unlikiest circumstances, without even requiring
co-ordination.

If the ISPs can make this work for the customers, why would anyone want
to stop them?

That is, I have seen here in the past hour or so while I have been glancing
at some of the past couple of days ipng list traffic, that people seem to
be specifying "non-routable" as a goal.   That's absurd, why would anyone
explicitly want a non-routable address, even assuming that such a thing
could be constructed?

The goal is, or should be, that routability is not a requirement.  That is,
that we need some address space for which it can't be guaranteed that
routing will work.   As much as anyone chooses to make it work, for money,
or for other reasons, that's just fine.   But in the design of the
address space, other attributes, like address stability, are more
important, and we don't compromise those, at all, to assist with making
the addresses routable.

For what it is worth, this is exactly what FEC0::/10 gives us now.

kre

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 10 Apr 2003 08:24:29 -0700

Hello Robert,

>They don't need to be globally unique for this, just unique within the
But global uniqueness means we don't need scoping in the (unicast)
address architecture.   It means that scoping can be done as part of
route table management instead.  I thought that was the point of the
exercise (or at least one important point).

>             ........... that people seem to
I think we need addresses that are not allowed to be "globally routable",
but are still unique.  I certainly agree that these addresses should 
still be
routable according to the needs of the local administration.

To be precise, though, we do want non-routable addresses too;
they're the link-local addresses.

Regards,
Charlie P.,

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 11 Apr 2003 08:24:01 +1000

G'day kre ... herewith some wild speculation about what people
actually mean when they say ...

> They don't need to be globally unique for this, just unique within the

I think most of the push for uniqueness is the site-merger situation ...
tricky if both sites happen to have chosen FEC0:DEAD:BEEF:/48.  Easy
if they've picked those bits at random though, so that's not a big
issue.

> If the ISPs can make this work for the customers, why would anyone want

:-) That's the kind of thing I keep saying too :-)

> be specifying "non-routable" as a goal.

Not as a 'goal', just as a recognized limitation.  And what people
really mean is 'non-route-aggregable', to differentiate from more
majestic efforts trying to get globally routable provider independent
addressing.

> For what it is worth, this is exactly what FEC0::/10 gives us now.

Yeah, I think people have issues with some of the more complex bits
of scoping though.  I'd propose to replace the tricky bits with
a strict scope(source) == scope(destination) for all packets, which
seems to clear up issues like 'convexity' quite nicely :-)

-----Nick