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


.  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.


.  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).


.  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.


.  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.


.  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.]


.  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.


.  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.


.  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.


.  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]