Subject: Re: Draft: PI addressing derived from AS numbers

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 4 Feb 2003 07:44:12 +0100

> This would create a terrible precedent. In the long run, we can expect:
> - People that have swamp space lobbying for v6 PI also, on the grounds
> that if people that have an ASN get v6 PI space they should get it too.
> Actually, swamp space holders have on paper a better reason than ASN
> holders to get v6 PI space.

Why? They still need an AS to get it announced. Either by themselves or 
through someone else.

> - AS numbers being extended to 32 bits. Then people that get ASNs above
> 64k will also strongly lobby to get PI on the grounds that it's not 
> fair
> that early adopters only get it.

It's still a size we can handle.

> If we had no other choice, I would support this as being not as bad as
> unrestricted PI. But it's still unaggregatable, and we do have a better
> choice: GAPI.

It's fast and it works. Go for it.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Feb 2003 10:34:52 +0100 (CET)

On Tue, 4 Feb 2003, Kurt Erik Lindqvist wrote:

> > fair that early adopters only get it.

> It's still a size we can handle.

32 bits??? I don't think so...

> It's fast and it works. Go for it.

I hope you're talking about GAPI here.

The whole ASN == PI thing doesn't work because every multihomer can get
an AS number so every multihomer can get PI space so we're right back at
square one.

A much better way to do this would be to take the globally unique site
local addresses for this. We can give two blocks of globally unique site
local addresses to each organization that wants them: one that is
guaranteed to be non-routable, and one that may or may not be routable.
Then we agree to all carry the first X 10k worth of those globally
unique potentially routable site local address blocks (GUPRSLABs?). When
the number of those prefixes in the v6 table hits 20k, 40k, 60k or
whatever, all bets are off and either we have built some MHAP-like
mechanism to map from these PI addresses to PA addresses or we admit
failure and go back to v4. Or we assign these addresses geographically
and start doing geographical aggregation if we can't come up with
anything better before the v6 table explodes.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Feb 2003 11:49:29 +0200 (EET)

> an AS number so every multihomer can get PI space so we're right back at

The point of the model, as far as I thought it, at least was that:

- those who already have an AS number, fine-- go for it (these would
possibly contribute to some 1,000+ routes in IPv6 DFZ, the absolute number
is peanuts, but of course there may be some layer 8 (and up) avalanche
effects) 

- those who don't, forget about it, use other mechanisms

ASN-PI model extended to 32 bits seems like a wrong thing to me: instead
of a sunset, it just increases the need for otherwise perhaps an
unnecessary technology change (as4bytes), and depletes the current AS 
number space.

-- 
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: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Feb 2003 11:27:34 +0100 (CET)

> is peanuts, but of course there may be some layer 8 (and up) avalanche

Where do you get this? There are more than 25000 AS numbers out there.
At some point, most of those networks will want to run IPv6.

> - those who don't, forget about it, use other mechanisms

It is very easy to get an AS number: if you want to multihome, you
qualify. It's not even very expensive: $500 in the ARIN and APNIC
regions last time I checked and no charge from RIPE if requested through
a RIPE member. The hard part about multihoming in IPv4 is the address
space. But if an AS number automatically means IPv6 PI space, that part
won't be a problem either.

This is what we in Dutch call an "open einde regeling" (open end
arrangement): you know where it starts, but you can't know where it ends
and thus how expensive it will be.

> unnecessary technology change (as4bytes), and depletes the current AS

What's the alternative? Say to the 64511th person to request an AS
number we're all out?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Feb 2003 12:34:48 +0200 (EET)

> At some point, most of those networks will want to run IPv6.

Ok, my rough estimate was off a bit, but I was considering those parties 
that could be running v6 in about 3 years or so.

As for the rest, e.g. http://bgp.potaroo.net/1221/bgp-active.html

lists 10305 origin-only AS's.  A little less than that, say 9000, is the 
current number we're talking about.  Note that the mechanism is only 
applicable to origin-only AS's, and some of those can get addresses from 
sTLA space too.

Not so bad in paper, IMO..
 
> and thus how expensive it will be.

It ends at AS32768.

> What's the alternative? Say to the 64511th person to request an AS

There are still over 2^15 AS numbers to waste.  Considerably more, less 
than a half of about 29K AS numbers are actually even being used..

Long-term solution: make a better policy for doling them out; avoid 
advocating situations where you (unnecessarily) need one.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Feb 2003 11:54:13 +0100 (CET)

> It ends at AS32768.

Any particular reason why we should leave 31744 perfectly good AS
numbers unused?

> than a half of about 29K AS numbers are actually even being used..

Try to reclaim them... That's very hard.

> advocating situations where you (unnecessarily) need one.

This is not "the internet way"! Paying people to go through complex
request procedures and then paying other people to review those request
means wasting money twice. If we're going to waste money anyway, let's
waste it on bigger hardware and smarter protocols, not on bureaucracy.

BTW, the fact that you don't see an ASN in your tables doesn't mean it
isn't legitimately used. For instance, most of you will not see AS12945.
It is used to peer over the AMS-IX, but in order not to contribute to
the global routing table unnecessarily we have our stuff aggregated by
the upstream.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Feb 2003 14:31:02 +0200 (EET)

> Any particular reason why we should leave 31744 perfectly good AS

Because I don't want a proposal like this exhaust the 16bit AS number 
space.
 
> Try to reclaim them... That's very hard.

Agreed, but that's what should be done before declaring loss.
 
> waste it on bigger hardware and smarter protocols, not on bureaucracy.

The question is where an AS number would be used.  If the 16bit number was
too low for all ISP's etc., sure .. but I'm not really convinced that's 
the case, especially if v4 multihoming is eliminated.

Also, sometimes using ASN's seems to be unnecessary, something you could
very well avoid altogether or replace with private AS numbers.
 
> the global routing table unnecessarily we have our stuff aggregated by

Yes, there are cases like this.. but often these are also ones where a
(public) AS number would not really be strictly necessary.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 10 Feb 2003 08:07:44 +0100

> At some point, most of those networks will want to run IPv6.

Just look in Philip Smiths routing summary that are also in my slides 
from RIPE i Amsterdam and also posted by me here a while ago.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 10 Feb 2003 08:12:05 +0100

> Try to reclaim them... That's very hard.
Nope. And this has been discussed in RIPE over the last year (to do 
this more effectively ) and is already in place in APNIC I think.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 10 Feb 2003 08:01:36 +0100

> 32 bits??? I don't think so...

This again depends on the timeline. As there is also a cost involved I 
still don't believe that we will have a billion multihomed networks 
tomorrow. sorry,

> I hope you're talking about GAPI here.

I am not.

> an AS number so every multihomer can get PI space so we're right back 

Yes. But it works. We know the dangers. And we can control it.

> local addresses for this. We can give two blocks of globally unique 

...which breaks a lot of current applications.

> failure and go back to v4. Or we assign these addresses geographically

Currently we won't get to v6 because it is broken and does not provide 
the functionality needed.

We need time and a new design. There, I have said the magic word :).

Global aggregation etc to me is starting to feel like a lot of ductape.

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Feb 2003 15:58:04 +0100

Kurt Erik Lindqvist wrote:
...
> the functionality needed.

Think carefully before you write things that the IPv6-haters might
misuse. 

The reason we have this WG is to work towards solutions for one
thing that IPv6 with PA addresses doesn't fix in the IPv4 model.
For whatever reason, we can't get past the problem statement stage,
but it really isn't going to advance things to say that IPv6
is "broken" when the reality is much deeper than any of the
specifics of IPv6.

> We need time and a new design. There, I have said the magic word :).

We need, probably, a two layer approach. That has been proposed
often enough. We just need to work out which version to use 
and see how to add it to IPv6.

> Global aggregation etc to me is starting to feel like a lot of ductape.

Nobody has explained how we can have log scale tables and real time
convergence times without aggregation. 

    Brian

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Feb 2003 10:34:22 -0500

On Monday, Feb 10, 2003, at 09:58 America/Montreal, Brian E Carpenter 

> is "broken" when the reality is much deeper than any of the

I'll try an alternate phrasing, which is one I happen to believe:

	The routing architecture shared by IPv4 and IPv6 is broken at least
	with respect to mobility and to multi-homing.  Mobility needs to be
	to be a first-order property of the routing architecture, not an
	awkward hack add-on with limited deployability.  Multi-homing also
	needs to be supported as a first-order property of the routing
	architecture.  This means that multi-homing needs to be supported
	in a manner that scales to global IP network sizes well beyond the
  	size of today's deployed Internet.  Multihoming a given site ought not
	need to be known or visible in the default-free-zone of an ISP that is
	not directly connected to that multi-homed site.

Ran
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Feb 2003 11:22:27 -0500

> The routing architecture shared by IPv4 and IPv6 is broken at least with
> respect to mobility and to multi-homing.

perhaps these consderations were not taken into account in the original
designs, and hence may deserve a kinder phrasing than "broken"

> Multihoming a given site ought not need to be known or visible in the
> default-free-zone of an ISP that is not directly connected to that
> multi-homed site.

as this is not intuitively obvious, it needs motivation/justification

randy

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 10 Feb 2003 17:42:18 +0100

> Think carefully before you write things that the IPv6-haters might

Well, unless we fixes the problems at hand - they will be right. And 
unless we starting "facing the truth" - they will be right.

> but it really isn't going to advance things to say that IPv6

Well, unless we soon get forward, the IPv6 effort will have been 
wasted. You won't get enterprises to IPv6 without a solution to multi6, 
and with no enterprises there is no revenue for the ISPs, with no 
revenue for the ISPs they won't deploy IPv6. It's as simple as that.

> is "broken" when the reality is much deeper than any of the

Agreed.

> and see how to add it to IPv6.

Agreed.

> convergence times without aggregation.

I miswrote the above. I meant Geo aggregation.

- kurtis -

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Feb 2003 14:45:37 -0500

On Monday, Feb 10, 2003, at 11:22 America/Montreal, Randy Bush wrote:

>> with

Fair.  Please substitute "sub-optimal" for broken and accept
my apologies for poor wording.

> as this is not intuitively obvious, it needs motivation/justification

Also fair.

RFC-3221 has words on this topic that are far more elegant
than my own words could ever be.

Thanks,

Ran
[email-masked]