Subject: Fwd: Status of the 16-bit AS Number space

From: Russ Housley <[email-masked]>
Date: Thu, 23 Apr 2009 11:13:12 -0400

I thought that the whole community would like to be aware of this status.

Russ

>From: Michelle Cotton <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Date: Wed, 22 Apr 2009 20:52:18 -0700
>Subject: Status of the 16-bit AS Number space
>
>Dear IESG,
>
>This is to let you know what we now have fewer than 10 blocks of 
>16-bit AS Numbers left in the IANA free pool.
>
>Yesterday we allocated two blocks of 1,024 AS Numbers to ARIN, as 
>per the Global Policy for Allocation of ASN Blocks to Regional 
>Internet Registries, which was ratified by the ICANN board in July last year.
>
><http://www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm>http://www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm
>
>The unallocated 16-bit AS Number space is now 54272-64511. The full 
>registry can be viewed at:
>
><http://www.iana.org/assignments/as-numbers/as-numbers.xml>http://www.iana.org/assignments/as-numbers/as-numbers.xml
>
>We agreed to notify the IESG when we got to this point in the AS 
>Numbers registry.  Please let me know if you have any questions or comments.
>
>Kind regards,
>
>Michelle Cotton
>IANA

---

From: john heasley <[email-masked]>
Date: Thu, 23 Apr 2009 08:41:04 -0700

> I thought that the whole community would like to be aware of this status.

My understanding is that the registries have not been reassigning ASNs
that are returns but were not allocated from IANA as part of a block.
AS1 for example, would not be reallocated if it were returned.  So, in
theory there are far more available than this lets on.

>> Yesterday we allocated two blocks of 1,024 AS Numbers to ARIN, as per 
>> the Global Policy for Allocation of ASN Blocks to Regional Internet 
>> Registries, which was ratified by the ICANN board in July last year.
>>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Steve Crocker <[email-masked]>
Date: Thu, 23 Apr 2009 11:46:01 -0400

I strongly advise against quick reallocation of returned AS numbers.   
Returned AS numbers should stay out of service for a substantial  
period of time.

The same should be true for other deactivated quantities such as  
addresses, but that's a larger discussion.

Steve

On Apr 23, 2009, at 11:41 AM, john heasley wrote:

>>> per
>>> <http://www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm 
>>> >http://www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm
>>>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Apr 2009 08:52:00 -0700

Is there a parallel report on the current usability of 32-bit AS numbers? 

--Paul Hoffman, Director
--VPN Consortium

---

From: john heasley <[email-masked]>
Date: Thu, 23 Apr 2009 08:58:58 -0700

Thu, Apr 23, 2009 at 11:46:01AM -0400, Steve Crocker:
> Returned AS numbers should stay out of service for a substantial period 
> of time.

why?  because someone somewhere might have policy with one of these ASNs
hard-coded?  I believe they've been doing this since at least 1999, a far
longer moratorium than necessary.  obviously there is some other goal.

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Apr 2009 12:31:05 -0400

--On Thursday, April 23, 2009 11:46 -0400 Steve Crocker
<[email-masked]> wrote:

> I strongly advise against quick reallocation of returned AS
> numbers.  Returned AS numbers should stay out of service for a
> substantial period of time.
> 
> The same should be true for other deactivated quantities such
> as addresses, but that's a larger discussion.

Does another generalization of that principle explain why ICANN
has encouraged and enabled (or at least done nothing to
discourage) rapid turnover and reuse of domain names?  If only
because of inherent slowness in RIR processes, returned AS
numbers and addresses do stay out of service for some period of
time (one can debate whether the time is sufficiently
"substantial") but, unlike domain names, they are not
reallocated in minutes after being released.  

Given the use of domain names in locators and the risks of
someone picking up an undesired target if the ownership of the
domain name changes, wouldn't most of the same considerations
that apply to AS numbers and addresses at those layers of the
stack apply to DNS names at the application layer?

    john

---

From: Geoff Huston <[email-masked]>
Date: Fri, 24 Apr 2009 06:13:47 +1000

You, and the community, may find these two AS number use reports  
helpful.

The first, http://www.potaroo.net/tools/asn16/ looks at the levels of  
consumption of the 16 bit AS number space and makes some predications,  
based on curve fitting to recent usage data, as to the anticipated  
lifetime of this number pool.

The second, http://www.potaroo.net/tools/asn32/ looks at the entirety  
of the 32 bit AS number pool.

regards,
  Geoff Huston

On 24/04/2009, at 1:13 AM, Russ Housley wrote:

>> This is to let you know what we now have fewer than 10 blocks of 16- 
>> bit AS Numbers left in the IANA free pool.
>>

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Apr 2009 06:53:15 +0900

Geoff Huston wrote:

> You, and the community, may find these two AS number use reports  helpful.

It's quite interesting to see the lack of scalability of multihoming
by routing is destroying the Internet.

> lifetime of this number pool.

According to http://bgp.potaroo.net/as2.0/bgp-active.html, most ASes
are used with /24 prefixes seemingly for punching holes.

It's not surprising that 32-bit AS space will exhaust in near future
just like 32-bit address space is exhausting and the only solution
is to deply end-to-end scalable multihoming AND restrict top level
aggregator space, both of which IPv6 failed to do.

							Masataka Ohta

---

From: Phillip Hallam-baker <[email-masked]>
Date: Thu, 23 Apr 2009 10:52:36 -0700

What are the potential consequences of multiple assignments of the  
same AS?

My initial reaction was that this would be very bad

But that is not necessarily the case and we might have a CIDR type  
workaround possible

Sent from my iPhone