Network Working Group G. Michaelson
Internet-Draft APNIC
Intended status: Informational October 15, 2006
Expires: April 18, 2007
Canonical Textual Representation of 4-byte AS Numbers
draft-michaelson-4byte-as-representation-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Michaelson Expires April 18, 2007 [Page 1]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
Abstract
A single textual representation for 4-byte Autonomous System (AS)
numbers is defined, to avoid any confusion in interpreting the two
2-byte quantities of which it is comprised. The syntax chosen avoids
collision with Border Gateway Protocol (BGP) community string parsing
of AS numbers. It is recommended that only this textual
representation be used by all documents and systems referring to
4-byte AS numbers.
Michaelson Expires April 18, 2007 [Page 2]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
1. Nomenclature
4 Byte AS numbers are defined in [IDR4BYTES]
4-byte AS numbers are represented using a syntax of
< high order 16 bit value in decimal > . < low order 16 bit value in
decimal >
Accordingly, a 4-byte AS number of value 65546 (decimal) would be
represented as the string "1.10".
Michaelson Expires April 18, 2007 [Page 3]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
2. Terminology
"2-byte only AS numbers" refers to AS numbers in the range 0 - 65535.
"4-byte only AS numbers" refers to AS numbers in the range 1.0 -
65535.65535 (decimal range 65,536 - 4,294,967,295)
"4-byte AS numbers" refers to AS numbers in the range 0.0 -
65535.65535 (decimal range 0 - 4,294,967,295)
Michaelson Expires April 18, 2007 [Page 4]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
3. Discussion
To avoid confusion, a single textual notation to represent a 4-byte
AS number is defined. This is for use in documentation,
configuration systems, and external tools and information
repositories.
2-byte only AS numbers MAY be represented as a 16 bit value decimal
number, with no leading zeros, or ".". They may also be represented
as 4-byte AS numbers.
4-byte AS numbers MAY be represented identically as 2-byte only AS
numbers, if their value lies in the range 0 - 65535. Otherwise, they
MUST be represented identically as for 4-byte only AS numbers. For
values in the range 0 - 65535 the canonical 4-byte AS number
representation is 0. < 16 bit decimal value > .
all other 4-byte AS numbers take a non-zero value in the high order
16 bit decimal value.
4-byte only AS numbers MUST be represented as two pairs of 16-bit
decimal values with no leading zeros, separated by the "." character.
The first decimal value is the high-order 16 bits, the second decimal
value is the low order 16 bits.
During the transitional period, when not all systems understand 4
byte AS numbers, it may be neccessary to continue to use two
notations to represent the 16-bit values which represent the AS
numbers 0 - 65535. These 2 byte AS numbers need a canonical textual
representation in 4-byte AS number representation.
Once all systems are converted to using 4-byte AS numbers, only 4
byte AS number representation should be used.
Michaelson Expires April 18, 2007 [Page 5]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
4. Historical Approaches
Initially, the ":" was proposed to separate the 2-byte components.
However this clashes with use of the ":" character in community
attribute syntax in BGP and this would have required changes to the
routing systems code base in ways which are not acceptable.
Routing Protocol Specification Language (RPSL) [RFC2622] [RFC4012]
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 4-byte AS number in AS-Set chains. This also
is not acceptable.
The "." denoted representation does not present these problems.
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.
Therefore it seems sensible to formalize its use as the preferred
representation of a 4-byte AS numbers across the board.
Michaelson Expires April 18, 2007 [Page 6]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
5. IANA Considerations
This document recommends changes to an existing IANA Registry, the as
number assignments registry.
This document makes changes to the IANA Considerations text in
[IDR4BYTES] as follows:
It is recommended that upon approval of this document, the IANA will
change the rules for representation of the assignments in the
"AUTONOMOUS SYSTEM NUMBERS" registry located at
http://www.iana.org/assignments/as-numbers
New line in the registry will be:
1.0 - 65535.65535 Reserved by the IANA
maintained subsequently in the documented textual representation as
assignments are made to the RIR.
Michaelson Expires April 18, 2007 [Page 7]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
6. Acknowledgements
This proposal was motivated by a discussion with Geoff Huston. The
text of the definition of a 4-byte AS is taken from [RIPE2005-12]
The author thanks Rudiger Volk, Joao Damas, Joe Abley, Peter Koch and
Henk Uijterwaal for feedback and extensive comments on this draft.
Michaelson Expires April 18, 2007 [Page 8]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
7. Implementation Notes
Many programming languages treat xxx.yyy numeric strings as real
number values on input, and convert internally to a canonical
floating point representation. Since the precision cannot be
guaranteed to be preserved, this risks changing the value of the 32-
bit quantity on output, or by mis-placed arithmetical calculation.
Care must be taken that 4-byte AS numbers are treated as 'special-
purpose strings' on input and output, and parsed correctly to a 32
bit 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 [RFC2622] and [RFC4012] specifications, and systems which
manipulate AS numbers need to be reviewed for conformance with 4-byte
AS number textual representation, and for the syntactic implications
of this representation.
Michaelson Expires April 18, 2007 [Page 9]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
8. Changes since the -01 draft
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.
Michaelson Expires April 18, 2007 [Page 10]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
9. Informative References
[IDR4BYTES]
Vohra, Q. and E. Chen, "draft-ietf-idr-as4bytes-12",
Dec 2005, <http://www1.ietf.org/internet-drafts/
draft-ietf-idr-as4bytes-12.txt>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
June 1999.
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
"Routing Policy Specification Language next generation
(RPSLng)", RFC 4012, March 2005.
[RIPE2005-12]
Huston, G., "4-Byte AS Number Policy", Dec 2005, <
http://www.ripe.net/ripe/policies/proposals/2005-12.html>.
Michaelson Expires April 18, 2007 [Page 11]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
Author's Address
George Michaelson
Asia Pacific Network Information Centre
Level 1, 33 Park Road
Milton, Queensland 4064
AU
Phone: +61 7 3858 3100
Email: ggm@apnic.net
Michaelson Expires April 18, 2007 [Page 12]
Internet-Draft Canonical Textual Form of 4-byte ASN October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Michaelson Expires April 18, 2007 [Page 13]
