Subject: RE: (ipv6) semantics - TLA

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Apr 2002 17:29:58 +0200 (CEST)

On Fri, 29 Mar 2002, Michel Py wrote:

[LIR definition]

> >> The point I am trying to make here is that we need a name or acronym
> >> for "ISPs that receive their addresses directly from a RIR".

> > I think the registry terminology would be Local Internet Registry
> > (LIR). RIRs allocate address space to LIRs.

> I find the LIR definition below somehow inconsistent with RIR and NIR.

Nobody ever said the universe is consistent.

> If one was to follow the same logic, RIR, NIR and LIR would be similar
> (RIR assigns to NIR and LIR, NIR assigns to LIR) except for their scope:

> - RIR : ~continent.
> - NIR : nation.
> - LIR : city / metropolitan area.

Why would you need three levels of bureaucracy for this?

> Indeed, the logical definition for a LIR should be something like "A
> provider-independent organization that assigns PI addresses to end-user
> sites".

This is obviously not how things work: that would make aggregation
impossible.

> It does not mean that the actual function could not be performed
> by an ISP (as mentioned in 6.1.8 of [MHAP]), but the ISP should then be
> clearly wearing two different hats. I am not convinced that making an
> ISP a registry is a good idea in the sense that most people would want a
> registry to be independent from the operators.

People want to get addresses with no hassle. Getting them from your ISP is
the least amount of hassle possible. Getting PI addresses and then get an
ISP to route them for you is more work for everyone.

> Which still leaves us (when RFC2373 is obsolete) with no replacement for
> "TLA" and "pTLA". I still don't understand what is wrong with these.

As a bystander, it seems to me too many people want their own address
space so the whole aggregation idea doesn't work. At least not for the
people who are interested in IPv6 at this point in time.

It doesn't matter too much anyway, because if everyone gets PI space but
the routers can't handle it, only blocks from the largest ISPs will be
routed so everyone will trade in their PI block for a sub-assignment from
one of those large ISPs. And if everyone gets PA space but the routers
suddenly turn out to be able to handle 10 million routes with no problem,
nobody will aggregate, even though the addresses make it possible. (Sort
of what we have now.)

--------------------------------------------------------------------
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: Tue, 2 Apr 2002 15:18:00 -0800

>> Michel Py wrote:
> Iljitsch van Beijnum wrote:

Definitely not. Nevertheless, more consistency has never hurt any
network I have seen.

> Why would you need three levels of bureaucracy for this?

Because it is likely to be easier to deal with a small local registry
that speaks the same language than a huge multi-continent one.

> This is obviously not how things work: that would make aggregation

I don't see why. The only reason behind geographical PI addresses is
that they can be geographically aggregated.

> ISP to route them for you is more work for everyone.

You are making my point. However, I think that a) the provider's PA
addresses and b) the customers geo PI addresses assigned by a registry
are two different things (even if the registry function is actually
manned by the customer's provider(s)).

> space so the whole aggregation idea doesn't work.

Again, it works with geographically aggregatable addresses, and the
point I was trying to make is that "Local Internet Registry" seemed a
good term (consistent with RIR and LIR) to describe the authority that
allocates geo PI addresses to sites, with a strong likeliness that the
function will be delegated to one of the ISPs servicing that area.

Michel.