Subject: RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]

From: "Michel Py" <[email-masked]>
Date: Mon, 8 Sep 2003 08:54:09 -0700

>>> Pekka Savola wrote:
>>> Sure, but there are also other ways to obtain addresses.
 
>> Michel Py wrote:
>> Really? Would you care naming one available today?

> a) talk to your ISP (or one of its upstreams), which his
> hopefully a LIR, or b) talk to any LIR, and pay him e.g.
> 100$/mo.  He'll gladly give you address space even though
> you don't want physical connectivity at all.

Is that what you call a solution available today? You have not been
listening. 1. I don't want to pay for it. 2. I don't want that space to
be reallocated to someone else if the LIR I got it from goes belly up.
Hijacking is less risky.

Now, it a part of each LIR space was earmarked for that purpose and if
there was a RIR policy that says that if LIR space is reallocated to a
new LIR the new LIR has to honor address assignments made by the old one
that would be another story. jj, where's your draft?

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: Pekka Savola <[email-masked]>
Date: Mon, 8 Sep 2003 19:18:33 +0300 (EEST)

On Mon, 8 Sep 2003, Michel Py wrote:
> listening. 1. I don't want to pay for it. 

Too bad.. life sucks sometimes :-).  Do you also want your domain name for 
free? If you're satisfied with a sub-domain, you might get a portion of 
address space from the similar source.

> 2. I don't want that space to

Consider the business model.  If LIR goes belly-up, more often than not
someone else buys its business (at least the customers :-). I don't know
if any LI, with customers, have really ceased operations all (Enterprise
LIRs are a different thing, but irrelevant in this context), but I'd like
to hear if that has happened.

Now, as the new owner of the dead LIR gets paid every year, it has every
incentive to honor the earlier address space assignments.  It can always
get more for itself from RIR.  On the other hand, if you'd only have to
pay a one-time fee, no ISP would like to care about these "private
non-users".  By keeping the cash flow (even a small one, if there are 
enough folks interested in it..) steady, the ISP is happy.

Compare it to paying for the domain names enterprises use.  Not much
difference here, I think.

So, we have a working business model for ISPs to provide locally usable
addresses.  They don't even have to be expensive :-).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 8 Sep 2003 18:34:59 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Michel Py wrote:

> listening. 1. I don't want to pay for it. 2. I don't want 
> that space to be reallocated to someone else if the LIR I got it from goes belly up.
> Hijacking is less risky.

Basically the need is for the possibility to get a globally unique
prefix directly from the RIR's without becoming a LIR and without
paying money for it. The prefix received from the RIR would then
not be allowed to be seen anywhere in the global routing table but
just and only for private interconnects bypassing "the internet".
Also there should be a penalty for people leaking these prefixes.
They could be stuck under the IX prefix assigments with the big
warning that they are completely not globally routable.

I would expect that the RIR's at least would require one to pay
a registration fee and maybe a yearly fee so they can also easily
check if the endsite using the space has not gone bellyup.
Btw good assumption that RIR's won't go belly up :)

> new LIR the new LIR has to honor address assignments made by 
> the old one that would be another story. jj, where's your draft?

Skip the LIR in this case and go directly to the RIR, maybe a sub-rir
which sole purpose is 'distributing' these prefixes. One has to pay
for domain names too, so these should not come for free either even
where it only for the registration and administration costs.

I think if you really want it for free, just hijack some 3ffe::/16
space, that won't be in use for years to come after 2006/6/6 :)

Personally if I would require a /48 I would go to a friendly LIR
and ask them a piece of the pie, I am aware of quite a lot of
friendly ISP's who will do that for a case of beer :)
(You can even get a /32 if you add some onions, but that is a different story :)

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Mon, 08 Sep 2003 18:08:50 -0700

This recent thread is stressing the fact that what is really needed is 
easy access
to stable address space.

Getting this address space from an ISP, a LIR or a RIR is just a minor 
variation.
The point is that this can be solved by policy and does not require to
put anything in the architecture to handle "local" addresses.

	- Alain.

---

From: Andrew White <[email-masked]>
Date: Tue, 09 Sep 2003 11:34:47 +1000

Alain Durand wrote:
> easy access to stable address space.

... without any contingency on the existence or lack thereof of a 'higher
level' address provider.

> put anything in the architecture to handle "local" addresses.

The above clarification is the critical point that many people seem to
miss.  The value of local addresses increases as the deployment scenario
gets SMALLER.

An enterprise might choose to use local addresses so they can have a network
numbering scheme that is independent of their ISP.  However, they could
probably buy this space from real global addresses if they wanted.  Further,
their 'network' as a whole is likely to be 'permanently' connected to the
public internet.

The networks that particularly benefit from local addresses are
intermittently connected.  Note that 'intermittent' doesn't mean a stable
link that goes up and down, but that the 'logical' point of attachment (as
defined by network prefix) may change, even on a daily or sub-daily basis. 
As it happens, the physical point of attachment may change as well.

In a permanently attached network, the division between 'my inside world'
and 'the outside world' is primarily a logical one.  At some point (or
points) we draw a line and say 'that side is in' and 'that side is out'.

In a intermittently attached network this distinction is much more
tangible.  Inside is 'the stable bit'.  Outside is 'the bit that changes and
that I have no control over'.  The home user / research ship / PAN wants
their 'core' network to remain intact and independent of 'outside', but to
have the ability to contact 'outside' if and when it exists.

Side comment: Any 'inherent' security derived from local addresses is only
as good as the default filtering in the internet, and it would be foolish to
trust that implicitly.  From a security standpoint, using a local address
for internal traffic (and preventing some hosts from using any other
address) is functionally equivalent to using a global for the same purpose.

The core benefit of local addresses is independence from address allocation
authorities (and thus a degree of stability).  The price is
non-routeability.

-- 
Andrew White

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Sep 2003 14:53:33 +0200

> put anything in the architecture to handle "local" addresses.

Absolutely true. Indeed, draft-ietf-ipv6-unique-local-addr-00.txt
doesn't put anything in the architecture (unlike FEC0::/10),
and is the simplest way to get easy access to stable address space.

That is also my response to Pekka's and Keith's last postings - yes,
we can administer this usage of RIR space, but it will be simpler 
to administer if we have a separate chunk of space for this.

    Brian