Subject: Fwd: The IESG Approved the Expansion of the AS Number Registry

From: Russ Housley <[email-masked]>
Date: Mon, 27 Nov 2006 14:16:33 -0500

I believe that this note should have been CCed to this mail list.  I 
believe this action is of general interest.

Russ

>To: IANA <[email-masked]>
>From: IESG Secretary <[email-masked]>
>Date: Mon, 27 Nov 2006 09:56:13 -0500
>Cc: [email-masked]
>Subject: The IESG Approved the Expansion of the AS Number Registry
>
>Dear IANA,
>
>The IESG has approved the expansion of the size of the AS Number
>registry described in draft-ietf-idr-as4bytes-12.txt before the approval
>of the document. Please expand the AS Number space to include the
>values 65536 through 4294967295, initially marked as "Held by IANA".
>
>Allocations can be made to the RIRs prior to the publication of
>this RFC.
>
>Thank You,
>The IESG

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 27 Nov 2006 14:22:03 -0500

On Mon, 27 Nov 2006 14:16:33 -0500

> believe this action is of general interest.
Do you want me to forward this to the NANOG list?
> >registry described in draft-ietf-idr-as4bytes-12.txt before the
> >approval of the document. Please expand the AS Number space to
> >include the values 65536 through 4294967295, initially marked as
> >"Held by IANA".
> >

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Thomas Narten <[email-masked]>
Date: Mon, 27 Nov 2006 21:43:49 -0500

> Do you want me to forward this to the NANOG list?

I don't see that as necessary (though certainly not harmful). I don't
think anyone is chomping at the bit for these...

To get an ASN, folk go to the RIRs. The RIRs have policies in place
for requesting/obtaining ASNs.

But, with the expanded space, there is an issue of how to transition
to the larger numbers. This is a software problem as much as
anything. Until all software understands the bigger numbers, people
will want to continue using the 16-bit ones.

Meanwhile, to encourage the migration to 4-byte ASNs, the RIRs have
been developing a globally-coordinated policy for how to transition to
4-byte ASNs (hi Geoff!). The first step of that process, effective
January 1, 2007, is to allow requestors to obtain 4-byte ASNs (if they
specifically request them). But, in order for the RIRs to be able to
offer them, IANA has to give them some. Hence, the IESG action
mentioned in the note.

See http://www.arin.net/policy/proposals/2005_9.html for more details.

Thomas

---

From: [email-masked]
Date: Wed, 29 Nov 2006 11:18:53 +0000

> anything. 

Indeed, there is a software issue here which does not
seem to have been carefully considered.

>Until all software understands the bigger numbers, people

The IESG message talked about numbers from 65536 to some
big number. Here suddenly, we see a reference to some
number of bits.

> Meanwhile, to encourage the migration to 4-byte ASNs, the RIRs have

Now there is a reference to some number of bytes. What is going
on here? Is this a question of moving the maximum number
from 65535 to something much larger or is it a matter of
creating new notation to reflect the details of the BGP
protocol change?

Some people have been pushing to make the internal details
of the BGP protocol externally visible even though the new
ASNs are defined in such a way that any 32-bit numbers which
happen to be equal to a 16-bit number are treated as if they
were the old 16-bit number. In other words, if you were allocated
64999 as a 16-bit ASN, you have the right to use 64999 as a
32-bit ASN.

Because of this, some people are demanding that a new notation
be developed to place a punctuation character, either a dot
or a colon, between the two 16-bit segments or between the
2nd and the 3rd byte, if you want to count bytes. Using this
system, there can be no such thing as AS 65536 as was stated
in the IESG message. Instead, that 32 bit quantity will be 
referred to as 1.0 or 1:0.

On the NANOG list it has already been pointed out that a lot
of network management software cannot handle such notation and
in some cases, 1.0 could be interpreted as the IP address 
1.0.0.0. It has been confirmed that one widely used PERL 
library interprets x.y as IP address x.0.0.y.

Because of this I think it would be useful for the IETF
to publish a draft defining the notation for AS numbers
so that we can either keep it simple or, if a new notation
is to be used, then publicly state the issues of software 
which needs to be changed. Such a draft should really come
from the WG which extended the AS number in the first 
place.

--Michael Dillon

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 29 Nov 2006 14:30:05 +0100

[email-masked] wrote:

> on here?

I think we're mixing up the number of bits reserved and the decimal
representation.  So far, 16 bits were used, or 2 bytes, the extensions
use 32 bits on the wire.  16 bits can be used for an unsigned decimal
number up to 65536, so it does make some sense to use that instead
of a string of 0's and 1's.

> library interprets x.y as IP address x.0.0.y.

I think this is a bug.

> from the WG which extended the AS number in the first 

There is:

   Canonical Textual Representation of 4-byte AS Numbers
   draft-michaelson-4byte-as-representation-02

describing the format of ASN32 and

   RPSL extensions for 32 bit AS Numbers
   draft-uijterwaal-rpsl-4byteas-ext-01.txt

describing what has to be changed in RPSL based tools for ASN32.  For
the latter draft, there is no good place in the IETF right now, but I
do welcome comments.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

# Lawyer: "Now sir, I'm sure you are an intelligent and honest man--"
# Witness: "Thank you. If I weren't under oath, I'd return the compliment."

---

From: Joe Abley <[email-masked]>
Date: Wed, 29 Nov 2006 09:15:39 -0500

On 29-Nov-2006, at 08:30, Henk Uijterwaal wrote:

>> in some cases, 1.0 could be interpreted as the IP address 1.0.0.0.  
>> It has been confirmed that one widely used PERL library interprets  
>> x.y as IP address x.0.0.y.
>
> I think this is a bug.

If it is, it's a very long-standing one. For example, see INET(3)  
which I think is of 4.2BSD vintage, and which appears to have similar  
semantics to the mentioned perl library:

INTERNET ADDRESSES
      Values specified using the `.' notation take one of the  
following forms:

            a.b.c.d
            a.b.c
            a.b
            a

      When four parts are specified, each is interpreted as a byte of  
data and
      assigned, from left to right, to the four bytes of an Internet  
address.
      Note that when an Internet address is viewed as a 32-bit  
integer quantity
      on the VAX the bytes referred to above appear as ``d.c.b.a''.   
That is,
      VAX bytes are ordered from right to left.

      When a three part address is specified, the last part is  
interpreted as a
      16-bit quantity and placed in the right-most two bytes of the  
network
      address.  This makes the three part address format convenient  
for speci-
      fying Class B network addresses as ``128.net.host''.

      When a two part address is supplied, the last part is  
interpreted as a
      24-bit quantity and placed in the right most three bytes of the  
network
      address.  This makes the two part address format convenient for  
specify-
      ing Class A network addresses as ``net.host''.

      When only one part is given, the value is stored directly in  
the network
      address without any byte rearrangement.

>> is to be used, then publicly state the issues of software which  
>> needs to be changed. Such a draft should really come
>> from the WG which extended the AS number in the first place.
>
> There is:
>

The draft above received significant operator criticism.

The consensus I saw on NANOGm, for example, was that there was (a) no  
useful reason to be able to distinguish between a 16-bit AS number  
and a 32-bit AS number less than 65536, (b) no good reason to use  
punctuation to separate the most- and least-significant 16 bits of  
the 32-bit ASN, and (c) every reason to think that the most sensible  
representation was just "bigger decimal numbers".

Joe

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 29 Nov 2006 09:14:10 -0800 (PST)

On Wed, 29 Nov 2006, Joe Abley wrote:

>>> in some cases, 1.0 could be interpreted as the IP address 1.0.0.0. It has 
>>> been confirmed that one widely used PERL library interprets x.y as IP 
>>> address x.0.0.y.
>> 
>> I think this is a bug.
>
> If it is, it's a very long-standing one. For example, see INET(3) which I 
> think is of 4.2BSD vintage, and which appears to have similar semantics to 
> the mentioned perl library:

I fail to see that as being stopping point. ASN is not an address and 
should not be passed to INET library - after all you do not pass just
a number to the ASN-library just because its a number? Also note that
for ASNs the bounds for A.B parts (0-65535) are completely different then 
A.B.C.D for ip address (0-255).

BTW - 3 or more "." is also commonly used in representing phone numbers
and I'm sure other things too.

> The consensus I saw on NANOGm, for example, was that there was (a) no useful 
> reason to be able to distinguish between a 16-bit AS number and a 32-bit AS 
> number less than 65536, (b) no good reason to use punctuation to separate the 
> most- and least-significant 16 bits of the 32-bit ASN, and (c) every reason 
> to think that the most sensible representation was just "bigger decimal 
> numbers".

I did not see any consensus on that issue when it was brought to NANOG-m.
There was critisicm but its not anywhere near that majority said this 
notation is bad - in fact I think its the other way around and most 
thought it was fine.

As far as reasons:
  1. We do not use full 32-bit number when talking about ip address for
     good reasons - it would make things more difficult for humans who
     need to remember and communicate them [ok - there are other historic
     rasons too and CIDR based use as well...]. We put "-" and "." for
     phone numbers eventhough there its not like 32-bit number and its
     all same digits no matter with or without "-". Its all largelye due
     to that large numbers are not natual to humans... So as number like
     18.101 is easier then 1179749 and that helps when you're doing
     manual debugging.
  2. There is are reasons to believe that ASNs can be assigned so that
     in new notation 2.x would indicate its ARIN and 3.x is RIPE region.
     Its not necesarrily relevent for every case, but it does help.
  3. Several different punctuation marks were explored on several lists
     including ppml - generally people thought that "." was easiest due
     to its use in ip addresses. You seem to argue the other way around...

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Thu, 30 Nov 2006 05:03:26 +1100

>will want to continue using the 16-bit ones.

I had a shot at documenting this in the form of a presentation slide 
pack. Even if you continue to use a 16 bit ASN indefinitely things 
may need to change:

http://www.potaroo.net/presentations/2006-10-11-asns.pdf

>See http://www.arin.net/policy/proposals/2005_9.html for more details.

and http://www.potaroo.net/ispcol/2005-08/as.html for a (much longer) 
look at the role of ASNs and the way in which expanded AS numbers are 
to be transitioned in from a technical perspective

regards,

    Geoff

---

From: Joe Abley <[email-masked]>
Date: Wed, 29 Nov 2006 15:41:12 -0500

On 29-Nov-2006, at 12:14, william(at)elan.net wrote:

>>>> 1.0.0.0. It has been confirmed that one widely used PERL library  
>>>> interprets x.y as IP address x.0.0.y.
>>> I think this is a bug.
>>
>> which I think is of 4.2BSD vintage, and which appears to have  
>> similar semantics to the mentioned perl library:
>
> I fail to see that as being stopping point.

I didn't suggest it was. I was just responding to the thought that  
the interpretation of x.y as x.0.0.y has some history.

>> The consensus I saw on NANOGm, for example, was that there was (a)  
>> no useful reason to be able to distinguish between a 16-bit AS  
>> number and a 32-bit AS number less than 65536, (b) no good reason  
>> to use punctuation to separate the most- and least-significant 16  
>> bits of the 32-bit ASN, and (c) every reason to think that the  
>> most sensible representation was just "bigger decimal numbers".
>

Interesting. I didn't notice any support for separating the 32-bit  
quantity into two sections, but I remember many people decrying the  
need for any separator at all.

The principal argument against "." specifically was that it will  
instantly break all deployed AS_PATH regular expressions (or at  
least, potentially cause regex comparisons to provide surprising  
results).

I'm not making an argument for against ggm's draft (although I can if  
that seems useful :-) I was merely passing on my memory of the NANOG  
thread.

Joe

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 29 Nov 2006 12:52:04 -0800 (PST)

On Wed, 29 Nov 2006, Joe Abley wrote:

> Interesting. I didn't notice any support for separating the 32-bit quantity 
> into two sections, but I remember many people decrying the need for any 
> separator at all.

I'd have to look at archive but I was not left with impression that people 
were against it rather they were noting changes that would have to be made.

> The principal argument against "." specifically was that it will instantly 
> break all deployed AS_PATH regular expressions (or at least, potentially 
> cause regex comparisons to provide surprising results).

I'm pretty sure it would be some time before tools are available that will
provide AS_PATH in new format and even then I've a feeling same tools will
give user an option to get data with ASN in new format or get it with ASN 
as a 64-bit number. Note that large number of existing ASN-processing 
scripts would break any way you go if they are doing bound checking...

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Thu, 30 Nov 2006 03:04:05 -0800

Hi,

On Nov 29, 2006, at 12:52 PM, william(at)elan.net wrote:
>> quantity into two sections, but I remember many people decrying  
>> the need for any separator at all.
> I'd have to look at archive but I was not left with impression that  
> people were against it rather they were noting changes that would  
> have to be made.

Obviously, 32-bit ASNs are 32 bit binary values and could be  
represented in an infinite number of ways. IANA has chosen to use the  
textual convention documented in draft-michaelson-4byte-as- 
representation-02 for the expansion of the ASN registry found at  
http://www.iana.org/assignments/as-numbers since, as that draft  
mentions:

    This notation has been informally adopted by at least one vendor,  
and
    used consistently in presentations in the Regional Internet Registry
    (RIR) community towards the deployment of 4-byte AS numbers.

Rgds,
-drc