Subject: globally unique site local addresses

From: "Christian Huitema" <[email-masked]>
Date: Thu, 21 Nov 2002 08:38:41 -0800

During the WG meeting, we agreed to work on the definition of a globally unqiue site local addressing architecture, so that we can eventually deprecate site local addresses. I am listing here so far a couple of points that were made by different speakers, as an introduction to the debate:
 
* we want to remove ambiguity, which is the root cause of many problems occuring when scoped addresses leak.
 
* we may or may not want to prevent routing of these addresses between sites. I guess we should certainly prevent routing between non-consenting sites.
 
* we definitely want the addresses to be provider independent, so they can survive renumbering or intermittent connectivity.
 
* indeed, it would be desirable that the addresses be usable in sites that are not connected.
 
* and we would definitely want the addresses to be free.
 
One of the main point of contention regarded routing. I guess that the consensus is, "just like site local addresses." We don't want to prevent usage in connected sites, but we expect that in these sites the hosts will also have provider based addresses, and that traffic routed out of the site will use the provider addresses.
 
Now, I guess we have to work from there. 
 
-- 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]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 21 Nov 2002 20:14:05 +0200

Christian,

I am not disagreeing with you on this, but I do have a comment
on one point:

> * we may or may not want to prevent routing of these 
> addresses between sites. I guess we should certainly prevent 
> routing between non-consenting sites.

Either we should do or the other.  If we create any ambiguity
on making these addresses routable between sites then we
are creating for a mess - as endpoints would not be able
to know if their packets would be routed or not.

best regards,
John

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 21 Nov 2002 19:35:09 -0500

Hi Christian,

I think that we need to work on understanding the goals of globally-unique,
provider-independent addressing, so that we can properly evaluate the
different proposals that we are likely to see.

In my opinion, the addresses should be routable, although it isn't
necessary that ISPs advertise them in global routing tables.  For
instance, I think it would be good if two "sites" could route their
globally-unique, provider-independent addresses to each other.

I don't know what you mean by "free".  It would be acceptable, in my
opinion, if people had to pay a registration fee for an address block.

In what way is the consensus "just like site locals"?  I think that
we want something better than site-locals that solves the problems
of:

         - persistent addresses to put in configuration files,
                 security filters, etc.
         - addresses that can be used in intermittently connected
                 sites and remain valid
         - addresses that survive ISP renumbering

Without the use of ambiguous addresses.

In addition, there are some other things we should solve that site-locals
don't solve:

         - work properly when two organizations merge
         - be possible to associate with an administrative
                 entity to which they are registered

Are there other problems that we need to solve to make these
addresses a preferrable alternative to site-locals?

Margaret

>* we may or may not want to prevent routing of these addresses between 
>sites. I guess we should certainly prevent routing between non-consenting 
>sites.
>
>* we definitely want the addresses to be provider independent, so they can 
>survive renumbering or intermittent connectivity.
>
>One of the main point of contention regarded routing. I guess that the 
>consensus is, "just like site local addresses." We don't want to prevent 
>usage in connected sites, but we expect that in these sites the hosts will 
>also have provider based addresses, and that traffic routed out of the 
>site will use the provider addresses.
>

---

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Nov 2002 19:45:53 -0800

Steven,

>> Michel Py wrote:
>> Ambiguity is a fail-safe for routes that leak into
>> the DFZ, even though they were not supposed to, and
>> for ISPs that don't filter traffic, even though they
>> were supposed to. In order to remove ambiguity, we
>> must replace the fail-safe it provides by something
>> else, and that something else is IMHO a requirement
>> that router vendors implement the necessary filters
>> as being default configuration.

> Steven Blake wrote:
> What technical problem are you trying to solve? Are
> you trying to prevent inadvertent leakage of prefixes?

Inadvertent, sabotage, hackers, stupidity, ignorance....

> Or are you trying to impose aggregatible prefixes on
> institutions that may be able to afford other
> arrangements?

I don't see the relation? 

Michel.

---

From: Dan Lanciani <[email-masked]>
Date: Thu, 21 Nov 2002 23:04:54 -0500 (EST)

"Michel Py" <[email-masked]> wrote:

|I agree with Charlie.
|
|There could be another model, where the end-site would request the block
|to one of their ISPs and the ISP access the IANA or RIR web site on
|behalf of the customer.

Let's not encourage ISPs to be in the address allocation business any more
than necessary. :)  Besides, what if you don't have an ISP?

|I think that RIRs would be more comfortable with
|this.

We need to get them back in the habit of dealing with consumers. :)

|Also, there is nothing that says that we can't have both Pekka's almost
|unique *and* something like what I proposed which is completely unique
|at the same time.

Absolutely.  What's the point of all these wonderful prefix bits if you
don't use them?

				Dan Lanciani
				ddl@danlan.*com

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Nov 2002 20:30:48 -0500

Hi Brian,

>The only class of solution which I think will truly make everyone happy
>is to come up with an *aggregatable* globally unique address space that
>still has properties 1 and 2.  In other words, some sort of
>provider-independent global address space.  Properties 1 and 2 are much
>easier when the aggregatable property is not required.  The reason we're
>in the state we are today is because this is a hard problem.

I agree that this would be ideal, and I think that there are a
couple of different proposals for how to do this that have been
suggested to the multi6 WG.  I have not reviewed them, yet, though
to see how/if they would meet this need.

Margaret

---

From: [email-masked]
Date: Sun, 24 Nov 2002 16:10:13 +0200

Hi Dan,

> than necessary. :)  Besides, what if you don't have an ISP?

I agree - I think that whatever we do on this topic we MUST NOT assume anything
like ISP intervention.  This is key for home, mobile & adhoc networks
where these kinds of addresses are potentially useful.

best regards,
John

---

From: "Michel Py" <[email-masked]>
Date: Sun, 24 Nov 2002 12:45:44 -0800

Pekka,

> Pekka Nikander wrote:
> Thus, from my point of view, the differences seem to
> boil down into two issues:
>   1. In the mixed space method, you can defer your
>   registration and still have a fairly large probability
>   of succeeding later in registration.
>   2. In the split space method, you can have more
>   confidence that no-one else is using your truly unique
>   prefix.

I agree with the analysis.

> I can't say which is better.

I think that the split space is better, for the following reason: truly
unique is a paid feature. People that pay for the feature will want a
guarantee that they will get what they paid for, which is truly unique,
which means the only model that works is split space.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Nov 2002 08:14:25 -0800

Pekka,

> Pekka Nikander wrote:
> First of all, there is no such thing as an absolute
> guarantee for global uniqueness.  Misconfigurations
> happen.  Thus, the real difference between the "split
> space" and "mixed space" model is that in the split
> space model, *nobody* is *supposed* to configure or
> use a registered prefix, while in the mixed space
> model someone *may* legitimitely use it.  However,
> even in the mixed space model the party having
> preformed the registration has some kind of
> ownership/moral property rights over the prefix,
> giving them more rights over those that haven't
> registered the prefix but happen to be using it
> anyway.

We are not trying to design a protocol that fixes stupidity.

> Now, the case seems to depend on psychology and the
> formulation of rights.  In the split space case the rights
> are easier to formulate, more natural, and stronger in that
> sense.  Nobody is supposed to use your prefix, and therefore
> they are wrong if they use your prefix, and you can sue them
> (or, in Europe, you can dispise and ignore them :-)

Exactly. And this is worth a few bucks, although I would agree that it's
not worth more than a few bucks. But it would be an easier sale to lots
of people, with or without good reasons for it.

More on the split model deal: So far we have discussed a split model
where the address allocation for the "truly unique" is the same as for
the "good enough". I agree that the split model does not bring much, but
I don't agree that it cancels the "use now register later" feature. Even
in a split model, you could have registration of addresses in the block
that is used for the random/hash algorithm, and still have the truly
unique block. In other words, you could register a truly unique prefix
if you register up front, and also register a "good enough" if you used
it without registering and later want to register it.

Note that the proposal I have for "truly unique" is based on geography
and will require split space as it could also be used to seed
identifiers in a dual-space identifier/locator multihoming solution.

Michel.