Henk Uijterwaal wrote:
Larry,
The big difference is that existing tools can potentially break if the syntax is changed in existing attributes. I agree that adding new attributes is undesirable, but I see a couple alternatives. The first would be to use straight integer notation for the AS numbers instead of the "." notations.
The IESG has asked for a standard notation for ASN32 when processing draft-ietf-idr-as4bytes. draft-michaelson-4byte-as-representation was written to suggest the "x.y" notation. This draft is likely to be accepted soon.
My draft follows this "x.y" notation simply because I don't think that it is a good idea to have 2 different formats for the same thing. At least, it'd drive me nuts if I had to type 1.0 in one place (my router CLI, for example) and 65536 in another (an RPSL tool) when referring to the same thing.
The tool could convert from "x.y" when processing for submission, so you wouldn't have to deal with 2 different formats.
This is actually compatible with the RFC 2622 flex macro for AS numbers (as Mark Prior noted) and would likely be compatible with existing tools.
An AS has been a 16 bit number forever (in terms of the lifetime of the Internet) and authors have implicitly used that when writing their tools. That means: regular int's (or even short unsigned ints) in the code, checks on input that numbers entered are below 65536 and/or 5 digits, arrays dimensioned to 65536, etc. All this code will have to be checked and updated. I would definitely not feel comfortable using code with numbers outside the range of the original spec.
The original spec doesn't specify a range. Some code will have problems with numbers greater than 16-bit, others won't. Certainly fewer implementations will have issues with 32-bit numbers than "x.y" notation.
Note that RFC3779 uses a straight integer for 32-bit ASN's (as opposed to the dotted character bitstrings for IPv4 numbers), so this is not unprecedented.
I seriously doubt that the authors of RFC3779 had ASN32 in mind when they wrote that RFC. I also think that this is a good example of why things have to be checked; a regular C integer (31 bits plus sign bit) in your code will fail for ASN 32768.0. It should be an unsigned int.
Actually, they did have 32 bit AS numbers in mind. That's why they defined the following in the RFC -- Autonomous System number - a 32-bit number that identifies an autonomous system. I'm not sure if this is actually compatible with the ASN.1 INTEGER definition, but they definitely had the foresight to allow for 32-bit AS numbers.