Subject: RE: Globally Unique Private Addresses and Scoped Architecture

From: "Michel Py" <[email-masked]>
Date: Wed, 9 Apr 2003 14:19:42 -0700

Charlie,

> Charles E. Perkins wrote:
> O.K.  The agreement seems to be that some providers
> would try to route provider-independent addresses,
> if offered enough money.  Is that correct?

Yes.

> Do you mean, that we should discourage providers
> from routing provider-independent addresses?

Yes, see below for details. More than discourage is needed.

> Do you still believe this if such addresses are
> forbidden from inclusion in the default-free zone?

Yes, see below too.

There is demand for two kinds of globally unique addresses:
globally-unique-private and "scalable PI". Unfortunately "scalable PI"
is an oxymoron, which is why we need to reduce the risk of
globally-unique-private becoming globally-unique-not-private with means
PI and routing table bloat.

The demand for PI is strong (yesterday at the ARIN meeting
micro-allocations were discussed); solutions are being developed that
would provide what could look like scalable PI and smell like scalable
PI but these are not there yet.

> It seems to me that we "should" be able to enforce
> his directly, if it's specified as an important part
> of IPv6 scalability. Mistakes might happen, but they
> could be corrected within hours,
> and typically that amount of deviation from "goodness"
> wouldn't upset the overall scalability of the aggregated
> route advertisements.

I'm not worried about someone doing a honest mistake and making a filter
SNAFU. Today, if someone announces 192.168.1.0/24 to the DFZ, who cares?
nobody and the reason is because it's obviously a mistake. What I am
worried is it becoming standard practice.

> It just has to be that most of the DFZ community does
> effectively exclude and nullify advertisement of provider-
> independent (i.e., non-aggregable) addresses.

Network administrators will not buy this. Half of the reason people want
private addresses is because they "own" the address and therefore don't
have to renumber if they switch ISPs, and the other half is that these
addresses are not publicly routable. The non-routability on the public
Internet is guaranteed by ambiguity as of today.

It is futile do discuss the rationale why people want private addresses.
Unless you have a good plan to educate masses (an RFC does not strike me
as one) people will continue to use them. The real question is whether
they will use the ones we provide or hijack a prefix of their own
choosing.

Since we can't really guarantee that globally-unique-private will stay
private, we need to provide a solution that has acceptable odds in terms
of non-routability.

In other words:

The need for global PI will prevail over the need for
globally-unique-private for the simple reason that administrators have a
backup plan for globally-unique-private if they pervert the mechanism we
develop: hijack a prefix.

The reason network administrators will not believe that operators will
nullify PI advertisement is because these very same administrators are
the ones that will be asking these very same operators to do the exact
opposite in exchange for cash. 

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: "Michel Py" <[email-masked]>
Date: Wed, 9 Apr 2003 17:42:26 -0700

Dan,

| Michel Py wrote:
| Unfortunately "scalable PI" is an oxymoron, which is why we need
| to reduce the risk of globally-unique-private becoming globally-
| unique-not-private with means PI and routing table bloat.

> Dan Lanciani wrote:
> IMHO, it is impossible to reduce the risk as stated. That is,
> we might be able to prevent globally-unique-globally-visible-
> in-the-routing-table, but that isn't quite the same thing.

IMHO, what you wrote above is the risk that is impossible to reduce in
the current situation.

> Once we have any globally unique ownable address space we can
> make it not-private with auto-tunnels analogous to those
> used for 6to4.

That would not bother me.

> All that is required is agreement on a lookup mechanism,

What you are talking about is a dual-space system. It's not simple but
fortunately it already exists.

> and I believe that the desire for PI space is strong enough to
> produce such an agreement in the market regardless of what the
> IETF may do.

You might be right.

> Now, I happen to think that ownable address space would be a
> good thing, but it would seriously alter the economics of pure
> provider-controlled allocations.

Ah this is really not a surprise coming from you. A way to make sure
that ISPs won't bill by the IP address. But be careful, they might make
you pay extra just because you own an address instead :-)

Michel.

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 10 Apr 2003 17:11:40 -0400 (EDT)

Charlie Perkins <[email-masked]> wrote:

|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 think you have to be at least a little careful here about that pesky
source address selection issue.  If I tell machine A to connect to machine
B using machine B's globally unique local address, I want to be sure that
machine A uses its local address as the source even if it has a global and
even if global/local communication is otherwise allowed.  Without this
constraint the connection will not have the stability of the locals.  The
intuitively obvious mechanisms of source address selection may make this
work correctly without explicit scope; however, if scope-like notions *are*
introduced (in particular, the common suggestion to always prefer a global
if it is available) the system will break.  In other words, I think you have
to either completely eliminate scope considerations (no fair putting in a few
simple tweaks to "fix" mobile IP or such) or else you are stuck with supporting
a complete and fully specified scoping mechanism.

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 10 Apr 2003 18:10:39 -0400 (EDT)

Erik Nordmark <[email-masked]> wrote:

|> IMHO, it is impossible to reduce the risk as stated.  That is, we might be
|> able to prevent  but
                  ^ deleted important context
|> that isn't quite the same thing.  Once we have any globally unique ownable
|> address space we can make it not-private with auto-tunnels analogous to those
|> used for 6to4.  All that is required is agreement on a lookup mechanism, and
|> I believe that the desire for PI space is strong enough to produce such an
|> agreement in the market regardless of what the IETF may do.  Now, I happen to
|
|Dan,
|
|In my head this "lookup mechanism for auto-tunneling" is merely a
|different way of stating that we need to separate identifiers and locators
|and have a lookup mechanism to map from an identifier to a (set of) locator(s).

No.  I've suggested separate identifier/locator schemes in the past (as you
know) but they have generally been shot down on the grounds that we don't
understand the issues well enough yadda yadda yadda.  Here the globally
unique ownable space is part of the total space and is no more a separate
identifier than is any 6to4 address.  Like 6to4 addresses such ownable globals
require special considerations to reach, but they are just as capable of
conducting a conversation with a "real" global as is any 6to4 address.  I
suspect that ingress filtering will be used to prevent optimization of the
PI->PA route (without filtering you could omit the tunnel) but that won't
be much of a deterrent.

|If that's what you mean I agree with it, and I think the IETF can gather
|enough ideas to be able to engineer a reasonable solution to this problem.

It's doubtful that the IETF will "engineer" an identifier/locator solution
any time soon for exactly the reasons that they have not already done so.
I've given up on such solutions.  Fortunately, auto-tunnels and a lookup
mechanism are so trivial that they can be glued together with no help from
the IETF.

|One question I have is whether we today know enough to know what
|the structure should be of the identifier or whether the desired structure
|of the identifier depends on what type of lookup system we design.

This is the kind of unanswerable meta question that has always put identifier/
locator solutions on permanent hold.  We will never know "enough" to know that
we have made the right choice, so we make no choice.  Besides, it's clear that
at this point even if we agreed on a separate identifier/locator model it is
too late to retrofit it to the existing spec.  Let's accept that and move on.

|I'm concerned about defining the
|globally-unique-globally-visible-in-the-routing-table format
|until we at least know that we can build a scalable and robust lookup
|function for it.

Nobody said anything about such a format.  We are talking about a globally
unique address space that is *not* visible in the public routing table.
This was proposed as a way to replace the functionality lost with site-locals,
remember?  Once it exists we can turn it into PI space without putting any
burden on the core routing tables, but that is just a bonus.  Let's not use
that bonus as an excuse to defer solving the problem that GUSL/whatever was
supposed to solve.

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 10 Apr 2003 18:26:38 -0400 (EDT)

Robert Elz <[email-masked]> wrote:

|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?

There seem to be some folks who are strongly opposed to allowing users to own
PI space that can be routed.  Knowing this, some of us who want to have *some*
kind of local address space have resigned ourselves to the fact that such space
must be crippled in order not to be vetoed by the former group.  However, it
seems that some of the folks in the first group are also arguing against the
ambiguity of site-locals even though ambiguity is the only obvious way to
sufficiently cripple the address space and prevent routability.  As I've tried
to point out in the past few messages, any globally unique ownable address
space can be turned into PI space with auto-tunnels in the manner of 6to4, all
without putting any burden on the core routing tables.  That's for the best,
IMHO, but it presents something of a quandary for folks who want neither
ambiguous site-locals nor ownable PI space...

					Dan Lanciani
					ddl@danlan.*com