[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
Network Working Group                                      G. Michaelson
Request for Comments: DRAFT                                        APNIC
Expires December 2006


             Canonical representation of 4-byte AS numbers

draft-michaelson-4byte-as-representation-01.txt


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.

Proposed canonical 4-byte AS representation

Abstract

   A single representation for 4-byte AS numbers is proposed, to avoid
   any confusion in interpreting the two 2-byte quantities that make
   them. The syntax chosen avoids collision with BGP community string
   parsing of AS numbers.

   It is recommended that only this representation be used by all
   documents and systems referring to 4-byte AS numbers.






Michaelson                                                      ^L[Page 1]


INTERNET DRAFT                                                 July 2006


Nomenclature

   4 Byte AS numbers are defined in [1].

   It is proposed that 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".

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)

Discussion

   To avoid confusion, a single notation to represent a 4-byte AS value
   is required. This is for use in documentation, configuration systems,
   and external tools and information repositories.

   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.

   It is believed that the ":" character would also interfere with the
   parsing of RPSL objects. 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 RIR community towards the
   deployment of 4-byte AS. Therefore it seems sensible to formalize its
   use as the preferred representation of a 4-byte AS across the board.

Author's Note:

   This proposal was motivated by a discussion with Geoff Huston. The
   text of the definition of a 4-byte AS is taken from [2].

   The author thanks RĂ¼diger Volk and Joao Damas for feedback and
   comments on this draft.


Michaelson                                                      ^L[Page 2]


INTERNET DRAFT                                                 July 2006


Security Considerations

   Many systems 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 mathematical calculation.

   Care must be taken that 4-byte AS 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.

   RPSL needs to be reviewed for conformance with 4-byte AS
   deployment, and for the syntactic implications of this
   representation.

Author's  Address:

   George Michaelson
   APNIC
   Level 1, 33 Park Road, Milton, Q4064 Australia

References

[1] http://www1.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-12.txt
[2] http://www.ripe.net/ripe/policies/proposals/2005-12.html

Comments & Feedback

    Comments are solicited and should be addressed to the working group's
    mailing list at idr@ietf.org and/or the author.

Authors email address

    ggm@apnic.net

Copyright Declaration

    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



Michaelson                                                      ^L[Page 3]


INTERNET DRAFT                                                 July 2006


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.














































Michaelson                                                      ^L[Page 4]