Subject: ASN-based prefixes for leaf ASes

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 17 Mar 2004 10:21:12 -0600

I'm starting here with the posit that the global routing table will contain
at least one prefix (/48 or shorter in the case of IPv6) from each ASN.
Obviously if this doesn't hold, the following discussion isn't valid...

Leaf ASes in the IPv6 world are expected to get a /48 prefix allocation
(from an RIR) as they do in the IPv4 world.  Given the size of a /48, it's
reasonable to expect the vast majority of these ASes will only need a single
prefix for IPv6, whereas in IPv4 they might have hundreds.  Since these ASes
already have an ASN and only need a single prefix, it seems logical to
assign a prefix to each AS based on their ASN.

This would reduce pressure on the "normal" prefix allocation process used by
non-leaf ASes.  In fact, a "normal" prefix need only be allocated to a leaf
AS when they demonstrate that their ASN-based prefix has been fully utilized
or bona fide technical reasons why the AS cannot use a single prefix.  A
non-leaf AS may (?) use ASN-based addresses for their internal use, but must
not assign any such addresses to customers.  To reduce advertisements,
non-leaf ASes may choose not to use their ASN-based prefix and instead give
themselves an internal allocation from one of their "normal" prefixes.

Given the number of 16-bit ASNs currently assigned, it seems reasonable to
assume an extension to 32-bit ASNs will occur within the lifetime of IPv6.
Thus, a single /16 prefix for all ASN-based allocations would be required.

The largest problem I see with this is that ASNs are permanently assigned,
or at least so far no recovery process is defined and no rent is charged.
This means that ASN-based allocations would be similarly permanent.  This
might be good or bad depending on your view of the RIRs.

Thoughts?

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Mar 2004 19:15:15 +0200 (EET)

> Thoughts?

Been there, done that, gotten flamed about it :-).

draft-savola-multi6-asn-pi-01.txt

(Well, I don't like that proposition either..)

p.s. the correct forum may be multi6.

-- 
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: Bill Manning <[email-masked]>
Date: Thu, 18 Mar 2004 09:57:31 -0800 (PST)

% On Wed, 17 Mar 2004, Stephen Sprunk wrote:
% > Thoughts?
% Been there, done that, gotten flamed about it :-).

	Not flamed, simply pointed out that this was the method
	used and documented for preliminary IPv6 address delegations ...
	before the creation of the 6bone.  The expectation was/is that
	the RIRs should be setting prefix delegation policies and
	the IETF should work on protocols.

% 
% draft-savola-multi6-asn-pi-01.txt
% (Well, I don't like that proposition either..)
% p.s. the correct forum may be multi6.

	Actually, the correct forum would be the RIR public policy mtgs.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 2004 10:27:17 +0100

Bill,

>         the IETF should work on protocols.

However, that expectation applies to stable, well understood technology.
It seems entirely possible that multi6 will come up with a direction
that would require some new thinking, and the initial technical discussion
of that would belong in the IETF (as was the case for CIDR). But that
discussion doesn't belong on this list, and doesn't belong on the
multi6 list either, until we have made some architectural progress there.
So I think we should just leave it for now...

>         Actually, the correct forum would be the RIR public policy mtgs.

Not yet IMHO, see above.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Bill Manning <[email-masked]>
Date: Fri, 19 Mar 2004 08:12:49 -0800 (PST)

% >         ...  simply pointed out that this was the method
% >         used and documented for preliminary IPv6 address delegations ...
% >         before the creation of the 6bone.  The expectation was/is that
% >         the RIRs should be setting prefix delegation policies and
% >         the IETF should work on protocols.
% 
% However, that expectation applies to stable, well understood technology.
% It seems entirely possible that multi6 will come up with a direction
% that would require some new thinking, and the initial technical discussion
% of that would belong in the IETF (as was the case for CIDR). But that
% discussion doesn't belong on this list, and doesn't belong on the
% multi6 list either, until we have made some architectural progress there.
% So I think we should just leave it for now...

	sure, fine.  Just pointing out the ASN based, prefix assignment
	hack is -very- old and has been abandoned by the IETF in
	favor of the processes we currently use.

% > % draft-savola-multi6-asn-pi-01.txt
% > % (Well, I don't like that proposition either..)
% > % p.s. the correct forum may be multi6.
% > 
% >         Actually, the correct forum would be the RIR public policy mtgs.
% 
% Not yet IMHO, see above.

	actually, I think it is imprudent to not include the
	RIR public policy fourm in any discussions on new address
	assignment plans.  YMMV of course.

%    Brian
% > --bill
% Brian E Carpenter 
% Distinguished Engineer, Internet Standards & Technology, IBM

--bill

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 21 Mar 2004 20:34:46 -0600

Thus spake "Bill Manning" <[email-masked]>
> favor of the processes we currently use.

That doesn't mean abandoning it completely was a good idea.  That system
also didn't provide a mechanism for non-leaf ASes to get non-ASN-based
allocations, which severely limited its scalability.  We've jumped from one
extreme to the other, when perhaps using both systems in parallel might be
most efficient.

> assignment plans.  YMMV of course.

I agree and invite input from ARIN members.  NOTE: Please include in your
comments whether you're a leaf or non-leaf AS.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 22 Mar 2004 02:50:24 -0600

Thus spake "Stephen Sprunk" <[email-masked]>
> comments whether you're a leaf or non-leaf AS.

I forgot that PPML wasn't copied on the original message...  To clarify:

My proposal was that automatic /48 allocations be made to anyone with an
ASN, based on the premise that every AS will advertise at least one PI
block.

These allocations would not allow sub-assignment (i.e. by non-leaf ASes).
Non-leaf ASes might use their ASN-based allocation for internal use, or
might ignore the ASN-based allocation in favor of "normal" TLA allocations
to minimize the number of advertised prefixes; the ASN-based allocation
should not count against non-leaf ASes for measuring utilization of "normal"
TLA allocations.  Leaf ASes would not be granted "normal" TLA allocations
without either evidence their ASN-based prefix was substantially consumed or
reasonable technical justification for multiple prefixes, e.g. for varying
BGP policies.

Some may note this is somewhat similar to 3ffe:: allocations to 6bone sites,
which were deprecated once RIR-based IPv6 allocations were standardized.
The major difference is that I propose it mainly apply to leaf ASes.  IMHO,
ASN-based allocations still make sense for leaf ASes, and forcing leaf ASes
through the RIR process for initial allocations is suboptimal if one accepts
the premise that every AS will advertise at least one PI prefix.

S

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Mar 2004 16:32:08 +0100

> Thus spake "Bill Manning" <[email-masked]>
...

> comments whether you're a leaf or non-leaf AS.

I didn't mean to imply that input from the RIRs was unwanted - on the contrary,
input from them is essential. I did mean to say that the basic technical consensus 
on whether we should go in this sort of direction at all needs to be formed here 
(IETF) and that is why I made an analogy with the early history of CIDR.

fwiw I'm not convinced that ASN-based prefixes are a good idea, for reasons that
others have stated.

  Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 22 Mar 2004 07:52:29 -0600

Thus spake "william(at)elan.net" <[email-masked]>
> On Mon, 22 Mar 2004, Stephen Sprunk wrote:
> If I remember right /48 is not a PI block (or rather it may not be within
> ARIN region which uses different terminology), /48 are expected to be
> allocated by ISPs (LIRs) to customers with their own network (rather when
> its individual device and then its /64) but its  provider-dependent
> (i.e. PA) as far as its being assigned by ISP where as PI would be
> micro-allocation directly by RIR

/48 is the size ISPs are supposed to hand out to leaf sites (with or without
an ASN), so that's the logical size of direct allocations to leaf sites.
This also allows encoding a 32-bit ASN in the prefix while only consuming a
/16 overall.  I say 32-bit ASN because it's clear the 16-bit space will run
out before IPv6 is retired; this could be changed to a 16-bit ASN if we
really want to assign a /32 to each leaf AS, but that seems like overkill.

> Now as far as assigning /48 for every ASN, lets not do it just yet - some
> ASNs may need larger blocks then just /48

It's hard to envision a leaf AS needing more than 64k subnets, but in that
case they could request a "normal" allocation from their RIR.

S

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 22 Mar 2004 02:42:02 -0800 (PST)

Now if you compare the policies for IPv4 ARIN does have a policy that
multihoming (i.e. = has ASN) is an automatic justification for /24 from 
one of the upstreams. Its not unreasonable to expect this to be extended 
to IPv6 and say that multihoming is justification for /48 from one of the 
upstreams or from RIR - however saying that is redundant as running 
independent network with multiple devices is already justification for /48 
from the LIR or upstream no matter if network it is multihomed or not :)

Now as far as assigning /48 for every ASN, lets not do it just yet - some 
ASNs may need larger blocks then just /48 and besides that there are way 
too many ASNs out there that are not used at all (getting close to 50%) 
and for those that are used some are used for special network preferences 
by the same provider that may not need separate /48. So just having ASN
out in whois does not mean they really need an /48 - that ASN holder must 
actually ask for it! 

However, what I would be for is allowing for micro-allocations from ARIN
(and this can/should be larger then /48 probably) so as to boostart use of 
IPv6. Currently if ASN holder is not a member of ARIN, they should request
ip block from their ISP or become member of ARIN and pay for that IPv6 block
$2500/year, I think we should allow for companies with ASN to be able to 
directly request IPv6 space from ARIN (micro-allocation) if their ISP
does not have yet have IPv6 space and that "ipv6 startup micro-allocations"
should cost less then regular full ipv6 blocks - possibly no extra money
if they are already paying yearly maintanance fee of $100/yr for ASN).

-- 
William Leibzon
Elan Networks
[email-masked]