Canonical Textual Representation of Four-octet AS Numbers

A single textual representation for four-octet Autonomous System (AS) numbers is defined. The syntax chosen avoids ambiguity with Border Gateway Protocol (BGP) community string representation of AS numbers. A number of forms of representation have been discussed in various routing forums, and this document provides a taxonomy of the various representations that have been considered, and recommends the adoption of a textual representation scheme termed "asdot" notation. It is recommended that only this "asdot" textual representation be used by all documents, systems and user interfaces referring to four-octet AS numbers.

refers to a syntax scheme of representing all AS numbers using decimal integer notation. Using asplain notation an AS number of value 65526 would be represented as the string "65526" and as AS number of value 65546 would be represented as the string "65546". refers to a syntax scheme of representing all AS numbers using a notation of two integer values joined by a period character: <high order 16-bit value in decimal>.<low order 16-bit value in decimal>. Using asdot+ notation, an AS number of value 65526 would be represented as the string "0.65526" and an AS number of value 65546 would be represented as the string "1.10". refers to a syntax scheme of representing AS number values less than 65536 using asplain notation and representing AS number values equal to or greater than 65536 using asdot+ notation. Using asdot notation, an AS number of value 65526 would be represented as the string "65526" and as AS number of value 65546 would be represented as the string "1.10". refers to AS numbers in the range 0.0 - 65535.65535 (using asdot+ notation), or 0 - 4294967295 (using asplain notation). Four-octet AS numbers are defined in refers to AS numbers in the range 1.0 - 65535.65535 (using asdot+ notation) or 65536 - 4294967295 (using asplain notation) refers to AS numbers in the range 0.0 - 0.65535 (using asdot+ notation), or 0 - 65535 (using asplain notation).

To avoid confusion, a single textual notation is useful for documentation, configuration systems, reports, and external tools and information repositories, but it is also necessary to observe that any recommendation regarding notation that changes existing use would represent an unwarranted imposition. The asdot representation represents a reasonable compromise, in that it preserves the current convention of using an asplain representation for two-octet only AS number values, and proposes using the asdot+ notation for four-octet only AS numbers. All systems that generate reports containing AS numbers MUST use this asdot notation to represent the AS number value. Interfaces that accept AS number values MUST accept asdot notation by default, and SHOULD also be capable of correctly interpreting values expressed in asplain and asdot+ notation.

Initially, the ":" was proposed to separate the two-octet components for the four-octet AS number value. It was noted that this representation clashes with use of the ":" character in community attribute syntax in BGP, and the representation of AS numbers in BGP community attributes would be ambiguous as a result of this choice of notation. It has also been pointed out that Routing Protocol Specification Language (RPSL) AS-Set objects use the ":" character to denote sequences of AS objects forming a chain. Since the AS object would have had the ":" character embedded in the instance name, this would have required double-parsing to find four-octet AS number in AS-Set chains. This also is not acceptable. It was also noted that AS numbers are used by network operations staff, and the larger values in the four-octet AS number set when using asplain notation introduces the increased risk of transcription error with these numbers.

[Note: not for publication. No changes are proposed for the IANA, as the IANA AS number registry, http://www.iana.org/assignments/as-numbers, already uses asdot notation.]

The text of the definition of a four-octet AS is taken from . The terminology of "asplain", "asdot" and "asdot+" was originally devised and described by Juergen Kammer in January 2007 . The authors thank Rudiger Volk, Joao Damas, Joe Abley, Peter Koch and Henk Uijterwaal for feedback and extensive comments on this document.

Many programming languages treat xxx.yyy numeric strings as real number values on input, and convert the value internally to a canonical floating point representation. Since the precision cannot be guaranteed to be preserved, this risks changing the value of the four-octet quantity on output, or by mis-placed arithmetical calculation. Care must be taken that asdot notation strings are treated as 'special-purpose strings' on input and output, and parsed correctly to a four-octet quantity. It would be sensible to draft suitable function definitions to define the transform from presentation to internal value, as was done for IPv4 and IPv6 addresses with the inet_pton() and inet_ntop() functions. The and specifications, and systems which manipulate AS numbers need to be reviewed for conformance with asdot textual representation, and for the syntactic implications of this representation.

[Note: This section is not for publication.]

An IANA Considerations section has been added to amend an existing registry. The document now clarifies that it refers to a textual representation, the binary representation used on-the-wire is unaffected by this draft.

The terms "asplain", "asdot" and "asdot+" have been used, reflecting current discussion on this topic. An IANA Considerations section has been removed, as the AS number registry uses asdot notation and no further changes would be required of the IANA registry according to the recommendation made here.

Grammatical errors were corrected. A spellcheck was run.