[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05
Network Working Group G. Michaelson
Internet-Draft G. Huston
Expires: June 4, 2008 APNIC
December 2, 2007
Canonical Textual Representation of Four-octet AS Numbers
draft-michaelson-4byte-as-representation-05
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 June 4, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
A taxonomy of textual representations for four-octet Autonomous
System (AS) numbers is defined. The 'asdot' textual representation
is recommended. The syntax chosen avoids ambiguity with Border
Gateway Protocol (BGP) community string representation of AS numbers.
It is recommended that this textual representation be used by all
documents, systems and user interfaces referring to four-octet AS
numbers.
Michaelson & Huston Expires June 4, 2008 [Page 1]
Internet-Draft Canonical Textual Form of Four-octet ASN December 2007
1. Introduction
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.
2. Terminology
asplain
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".
asdot+
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".
asdot
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".
four-octet AS numbers
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 [RFC4893]
Michaelson & Huston Expires June 4, 2008 [Page 2]
Internet-Draft Canonical Textual Form of Four-octet ASN December 2007
four-octet only AS numbers
refers to AS numbers in the range 1.0 - 65535.65535 (using asdot+
notation) or 65536 - 4294967295 (using asplain notation)
two-octet only AS numbers
refers to AS numbers in the range 0.0 - 0.65535 (using asdot+
notation), or 0 - 65535 (using asplain notation).
3. Representation of AS Number Values
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.
4. Consideration of Approaches to AS number representation
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) [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 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
Michaelson & Huston Expires June 4, 2008 [Page 3]
Internet-Draft Canonical Textual Form of Four-octet ASN December 2007
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.
5. IANA Considerations
[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.]
6. Acknowledgments
The text of the definition of a four-octet AS is taken from
[RIPE2005-12].
The terminology of "asplain", "asdot" and "asdot+" was originally
devised and described by Juergen Kammer in January 2007 [KAMMER2007].
The authors thank Rudiger Volk, Joao Damas, Joe Abley, Peter Koch and
Henk Uijterwaal for feedback and extensive comments on this document.
7. Implementation Notes
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.
Use of the POSIX 'regexp' function requires care, since the full-stop
character is used to denote 'any char' and can be matched by a
decimal digit. Thus AS1.1 can match AS101, AS121 etc, unless the dot
is escaped in the pattern match as AS1\.1 in this instance. This
risk has been present for some time, and depended on the textual
representation of an AS being 1:1 with the imputed binary value. In
reality, AS pattern matching should be interpreted, and applied to
the binary value, not a specific representation.
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
Michaelson & Huston Expires June 4, 2008 [Page 4]
Internet-Draft Canonical Textual Form of Four-octet ASN December 2007
inet_pton() and inet_ntop() functions.
The [RFC2622] and [RFC4012] 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.
8. Changes
[Note: This section is not for publication.]
8.1. 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.
8.2. Changes since the -02 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.
8.3. Changes since the -03 draft
Grammatical errors were corrected.
A spellcheck was run.
8.4. Changes since the -04 draft
More grammatical errors were corrected.
Commentary on REGEXP was added.
9. References
Michaelson & Huston Expires June 4, 2008 [Page 5]
Internet-Draft Canonical Textual Form of Four-octet ASN December 2007
9.1. Normative References
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS
Number Space", RFC 4893, May 2007.
9.2. Informative References
[KAMMER2007]
Kammer, J., "AS Number Formats", Jan 2007,
<http://quagga.ncc.eurodata.de/asnumformat.html>.
[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., "four-octet AS Number Policy", Dec 2005, <
http://www.ripe.net/ripe/policies/proposals/2005-12.html>.
Authors' Addresses
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
Geoff Huston
Asia Pacific Network Information Centre
Level 1, 33 Park Road
Milton, Queensland 4064
AU
Phone: +61 7 3858 3100
Email: gih@apnic.net
Michaelson & Huston Expires June 4, 2008 [Page 6]
Internet-Draft Canonical Textual Form of Four-octet ASN December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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 & Huston Expires June 4, 2008 [Page 7]
Html markup produced by rfcmarkup 1.122, available from
https://tools.ietf.org/tools/rfcmarkup/