Weekly Routing Table Report

Mailman List Mirror (Read Only)
1

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz@gmail.com>.

Routing Table Report 04:00 +10GMT Sat 21 Sep, 2013

Report Website: http://thyme.rand.apnic.net
Detailed Analysis: http://thyme.rand.apnic.net/current/

Analysis Summary

2

Folks -

If you work for a Internet service provider, please check your readiness
to accept customers with 32-bit ASNs as soon as possible. While we still
have some 16-bit ASNs in ARIN's regional pool, availability is limited and
we do not anticipate receiving additional 16-bit ASN blocks from IANA.

Not being able to use 32-bit ASNs in your network and support systems will
inevitably lead to confusion for those customers who are assigned them.

Thanks!
/John

John Curran
President and CEO
ARIN

3

I look forward to the day when we have proper 32 bit BGP community support
and ASN32s finally become usable on nontrivial networks.

Nick

4

Is there some reference that describes the problems with the use of RFC5668? I was not aware
that there were residual issues here.

regards,

   Geoff

5

It would've been really nice if one could fit more than 16 bit in the
locally administrated part.

Kind regards,

Job

6

I'm sorry, but I'm still confused, as I see your comment as one that relates to the
size of the payload field here, as distinct from the support for 32 bit AS numbers
per se.

   Geoff

7

hence my original comment about being usable on nontrivial transit
networks, where having the size of the community local administrator >=
your customer asn bitfield size is a rather useful feature.

There's also a serious vendor support problem at the moment.

Nick

8

I'd like to see an option for a larger private ASN block - 1K of private ASNs can be quite a pain in really large organizations.

I have seen others mention this in the past - e.g.
http://www.gossamer-threads.com/lists/cisco/nsp/158375

But apparently there's not enough traction to cause movement.

9

For 32 bit ASNs, there's RFC 6996. If you're looking for more 16 bit
private ASNs, you've missed the boat: they're all gone.
Nick

10

Hi,

R. Benjamin Kessler wrote:

I'd like to see an option for a larger private ASN block -
1K of private ASNs can be quite a pain in really large organizations.

I have seen others mention this in the past - e.g.
Carbon60: Managed Cloud Services

But apparently there's not enough traction to cause movement.

In the 32-bit space there is:

4200000000-4294967294 Reserved for Private Use [RFC6996]

which is considerably more than 1,000. The remaining unallocated 16-bit AS
Numbers are 64000-64495.

Regards,

Leo

11

I wonder what the correlation is between sites that haven't deployed
5668, sites that haven't deployed IPv6, and sites that haven't deployed BCP38.