Fwd: Re: RPSL support for 32 bit ASN
Larry J. Blunk
Thu Sep 14 22:40:48 CEST 2006
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.
[ rpslng Archive ]