Skip to main content

Guidelines for creation, selection, and registration of an Autonomous System (AS)
draft-ietf-idr-autosys-guide-03

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 1930.
Authors John A. Hawkinson , Tony J. Bates
Last updated 2013-03-02 (Latest revision 1995-05-02)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 1930 (Best Current Practice)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-idr-autosys-guide-03
Network Working Group                                       J. Hawkinson
INTERNET-DRAFT                                                     Panix
Category: Standards Track                                       T. Bates
<draft-ietf-idr-autosys-guide-03.txt>                                MCI
                                                                May 1995

           Guidelines for creation, selection, and registration
                       of an Autonomous System (AS)

Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   This draft discusses when it is appropriate to register and utilize
   an Autonomous System (AS), and lists criteria for such.  ASes are the
   unit of routing policy in the modern world of exterior routing, and
   are specifically applicable to protocols like EGP (Exterior Gateway
   Protocol, now at historical status; see [EGP]), BGP (Border Gateway
   Protocol, the current de facto standard for inter-AS routing; see
   [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the
   Internet will eventually adopt when BGP becomes obsolete; see
   [IDRP]). It should be noted that the IDRP equivalent of an AS is the
   RDI, or Routing Domain Identifier.

Hawkinson & Bates       Expires 6 November, 1995                [Page 1]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

Table of Contents

   1. Introduction ............................................    2

   2. Motivation ..............................................    3

   3. Definitions .............................................    3

   4. Common errors in allocating ASes ........................    6

   5. Criteria for the decision -- do I need an AS?  ..........    6

   5.1 Sample Cases ...........................................    7

   5.2 Other Factors ..........................................    8

   6. Speculation .............................................    8

   7. One prefix, one origin AS ...............................    9

   8. IGP issues ..............................................    9

   9. AS Space exhaustion .....................................   10

   10. Reserved AS Numbers ....................................   10

   11. Security Considerations ................................   10

   12. Acknowledgments ........................................   10

   13. References .............................................   10

   14. Authors' Addresses .....................................   12

1. Introduction

   This memo discusses when it is appropriate to register and util-
   ize an Autonomous System (AS), and lists criteria for such.  ASes
   are the unit of routing policy in the modern world of exterior
   routing, and are specifically applicable to protocols like EGP
   (Exterior Gateway Protocol, now at historical status; see [EGP]),
   BGP (Border Gateway Protocol, the current de facto standard for
   inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain
   Routing Protocol, which the Internet will eventually adopt when

Hawkinson & Bates       Expires 6 November, 1995                [Page 2]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

   BGP becomes obsolete; see [IDRP]). It should be noted that the
   IDRP equivalent of an AS is the RDI, or Routing Domain Identif-
   ier.

2. Motivation

   This memo is aimed at network operators and service providers who
   need to understand under what circumstances they should make use
   of an AS. It is expected that the reader is familiar with routing
   protocols and will be someone who configures and operates Inter-
   net networks. Unfortunately, there is a great deal of confusion
   in how ASes should be used today; this memo attempts to clear up
   some of this confusion, as well as acting as a simple guide to
   today's exterior routing.

3. Definitions

   This document refers to the term ``prefix'' throughout. In the
   current classless Internet (see [CIDR]), a block of class A, B,
   or C networks may be referred to by merely a prefix and a mask,
   so long as such a block of networks begins and ends on a power-
   of-two boundary. For example, the networks:

        192.168.0.0/24
        192.168.1.0/24
        192.168.2.0/24
        192.168.3.0/24

   can be simply referred to as:

        192.168.0.0/22

   The term ``prefix'' as it is used here is equivalent to ``CIDR
   block'', and in simple terms may be thought of as a group of one
   or more networks. We use the term ``network'' to mean classful
   network, or ``A, B, C network''.

   The definition of AS has been unclear and ambiguous for some
   time.  [BGP-4] states:

        The classic definition of an Autonomous System is a set of
        routers under a single technical administration, using an inte-
        rior gateway protocol and common metrics to route packets within
        the AS, and using an exterior gateway protocol to route packets
        to other ASes.  Since this classic definition was developed, it
        has become common for a single AS to use several interior

Hawkinson & Bates       Expires 6 November, 1995                [Page 3]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

        gateway protocols and sometimes several sets of metrics within
        an AS.  The use of the term Autonomous System here stresses the
        fact that, even when multiple IGPs and metrics are used, the
        administration of an AS appears to other ASes to have a single
        coherent interior routing plan and presents a consistent picture
        of what networks are reachable through it.

   To rephrase succinctly:

        An AS is a connected group of IP networks run by one or more
        network operators which has a SINGLE and CLEARLY DEFINED routing
        policy.

   Routing policy here is defined as how routing decisions are made in
   the Internet today.  It is the exchange of routing information
   between ASes that is subject to routing policies. Consider the case
   of two ASes, X and Y exchanging routing information:

                NET1 ......  ASX  <--->  ASY  ....... NET2

   ASX knows how to reach a prefix called NET1.  It does not matter
   whether NET1 belongs to ASX or to some other AS which exchanges rout-
   ing information with ASX, either directly or indirectly; we just
   assume that ASX knows how to direct packets towards NET1.  Likewise
   ASY knows how to reach NET2.

   In order for traffic from NET2 to NET1 to flow between ASX and ASY,
   ASX has to announce NET1 to ASY using an exterior routing protocol;
   this means that ASX is willing to accept traffic directed to NET1
   from ASY. Policy comes into play when ASX decides to announce NET1 to
   ASY.

   For traffic to flow, ASY has to accept this routing information and
   use it.  It is ASY's privilege to either use or disregard the infor-
   mation that it receives from ASX about NET1's reachability. ASY might
   decide not to use this information if it does not want to send
   traffic to NET1 at all or if it considers another route more
   appropriate to reach NET1.

   In order for traffic in the direction of NET1 to flow between ASX and
   ASY, ASX must announce that route to ASY and ASY must accept it from
   ASX:

Hawkinson & Bates       Expires 6 November, 1995                [Page 4]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

                    resulting packet flow towards NET1
                  <<===================================
                                    |
                                    |
                     announce NET1  |  accept NET1
                    --------------> + ------------->
                                    |
                        AS X        |    AS Y
                                    |
                     <------------- + <--------------
                       accept NET2  |  announce NET2
                                    |
                                    |
                   resulting packet flow towards NET2
                   ===================================>>

   Ideally, though seldom practically, the announcement and acceptance
   policies of ASX and ASY are identical.

   In order for traffic towards NET2 to flow, announcement and accep-
   tance of NET2 must be in place (mirror image of NET1). For almost all
   applications connectivity in just one direction is not useful at all.

   It should be noted that, in more complex topologies than this exam-
   ple, traffic from NET1 to NET2 may not necessarily take the same path
   as traffic from NET2 to NET1; this is called asymmetrical routing.
   Asymmetrical routing is not inherently bad, but can often cause per-
   formance problems for higher level protocols, such as TCP, and should
   be used with caution.

   It is important to realise that with current destination based for-
   warding technology routing policies must eventually be expressed in
   these terms.

   Policies are not configured for each prefix separately but for groups
   of prefixes.  These groups of prefixes are ASes.

   An AS has a globally unique number (sometimes referred to as an ASN,
   or Autonomous System Number) associated with it; this number is used
   in both the exchange of exterior routing information (between neigh-
   boring ASes), and as an identifier of the AS itself.

   In routing terms, an AS will normally use one or more interior gate-
   way protocols (IGPs) when exchanging reachability information within
   its own AS. See ``IGP Issues''.

Hawkinson & Bates       Expires 6 November, 1995                [Page 5]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

4. Common errors in allocating ASes

   The term AS is often confused or even misused as a convenient way of
   grouping together a set of prefixes which belong under the same
   administrative umbrella, even if within that group of prefixes there
   are various different routing policies. Without exception, an AS must
   have only one routing policy.

   It is essential that careful consideration and coordination be
   applied during the creation of an AS. Using an AS merely for the sake
   of having an AS is to be avoided, as is the worst-case scenario of
   one AS per classful network (the IDEAL situation is to have one pre-
   fix, containing many networks, per AS). This may mean that some re-
   engineering may be required in order to apply the criteria and guide-
   lines for creation and allocation of an AS that we list below;
   nevertheless, doing so is probably the only way to implement the
   desired routing policy.

   If you are currently engineering an AS, careful thought should be
   taken to register appropriately sized CIDR blocks with your registra-
   tion authority in order to minimize the number of advertised prefixes
   from your AS.  In the perfect world that number can, and should, be
   as low as one.

   Some router implementations use an AS number as a form of tagging to
   identify interior as well as exterior routing processes.  This tag
   does not need to be unique unless routing information is indeed
   exchanged with other ASes. See ``IGP Issues''.

5. Criteria for the decision -- do I need an AS?

   *    Exchange of external routing information

        An AS must be used for exchanging external routing information
        with other ASes through an exterior routing protocol. The
        current recommended exterior routing protocol is BGP, the Border
        Gateway Protocol. However, the exchange of external routing
        information alone does not constitute the need for an AS. See
        ``Sample Cases'' below.

   *    Many prefixes, one AS

        As a general rule, one should try to place as many prefixes as
        possible within a given AS, provided all of them conform to the
        same routing policy.

Hawkinson & Bates       Expires 6 November, 1995                [Page 6]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

   *    Unique routing policy

        An AS is only needed when you have a routing policy which is
        different from that of your border gateway peers. Here routing
        policy refers to how the rest of the Internet makes routing
        decisions based on information from your AS. See ``Sample
        Cases'' below to see exactly when this criteria will apply.

5.1 Sample Cases

   *    Single-homed site, single prefix

        A separate AS is not needed; the prefix should be placed in an
        AS of the provider. The site's prefix has exactly the same rout-
        ing policy as the other customers of the site's service pro-
        vider, and there is no need to make any distinction in routing
        information.

        This idea may at first seem slightly alien to some, but it
        highlights the clear distinction in the use of the AS number as
        a representation of routing policy as opposed to some form of
        administrative use.

        In some situations, a single site, or piece of a site, may find
        it necessary to have a policy different from that of its pro-
        vider, or the rest of the site. In such an instance, a separate
        AS must be created for the affected prefixes. This situation is
        rare and should almost never happen. Very few stub sites require
        different routing policies than their parents. Because the AS is
        the unit of policy, however, this sometimes occurs.

   *    Single-homed site, multiple prefixes

        Again, a separate AS is not needed; the prefixes should be
        placed in an AS of the site's provider.

   *    Multi-homed site

        Here multi-homed is taken to mean a prefix or group of prefixes
        which connects to more than one service provider (i.e. more than
        one AS with its own routing policy). It does not mean a network
        multi-homed running an IGP for the purposes of resilience.

        An AS is required; the site's prefixes should be part of a

Hawkinson & Bates       Expires 6 November, 1995                [Page 7]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

        single AS, distinct from the ASes of its service providers.
        This allows the customer the ability to have a different
        representation of policy and preference among the different ser-
        vice providers.

        This is ALMOST THE ONLY case where a network operator should
        create its own AS number. In this case, the site should ensure
        that it has the necessary facilities to run appropriate routing
        protocols, such as BGP4.

5.2 Other factors

   *    Topology

        Routing policy decisions such as geography, AUP (Acceptable Use
        Policy) compliance and network topology can influence decisions
        of AS creation. However, all too often these are done without
        consideration of whether or not an AS is needed in terms of
        adding additional information for routing policy decisions by
        the rest of the Internet. Careful consideration should be taken
        when basing AS creation on these type of criteria.

   *    Transition / ``future-proofing''

        Often a site will be connected to a single service provider but
        has plans to connect to another at some point in the future.
        This is not enough of a reason to create an AS before you really
        need it.  The AS number space is finite and the limited amount
        of re-engineering needed when you connect to another service
        provider should be considered as a natural step in transition.

   *    History

        AS number application forms have historically made no reference
        to routing policy. All too often ASes have been created purely
        because it was seen as ``part of the process'' of connecting to
        the Internet. The document should act as reference to future
        application forms to show clearly when an AS is needed.

6. Speculation

   1) If provider A and provider B have a large presence in a

Hawkinson & Bates       Expires 6 November, 1995                [Page 8]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

   geographical area (or other routing domain), and many customers are
   multi-homed between them, it makes sense for all of those customers
   to be placed within the same AS. However, it is noted that case
   should only be looked at if practical to do so and fully coordinated
   between customers and service providers involved.

   2) Sites should not be forced to place themselves in a separate AS
   just so that someone else (externally) can make AS-based policy deci-
   sions. Nevertheless, it may occasionally be necessary to split up an
   AS or a prefix into two ASes for policy reasons. Those making exter-
   nal policy may request the network operators make such AS changes,
   but the final decision is up to those network operators who manage
   the prefixes in question, as well as the ASes containing them. This
   is, of course, a trade off -- it will not always be possible to
   implement all desired routing policies.

7. One prefix, one origin AS

   Generally, a prefix can should belong to only one AS. This is a
   direct consequence of the fact that at each point in the Internet
   there can be exactly one routing policy for traffic destined to each
   prefix. In the case of an prefix which is used in neighbor peering
   between two ASes, a conscious decision should be made as to which AS
   this prefix actually resides in.

   With the introduction of aggregation it should be noted that an AS
   can occasionally be represented as residing in more than one AS, how-
   ever, this is very much the exception rather than the rule. This hap-
   pens when aggregating using the AS_SET attribute in BGP, wherein the
   concept of origin is lost. In some cases the origin AS is lost alto-
   gether if there is a less specific aggregate announcement setting the
   ATOMIC_AGGREGATE attribute.

8. IGP Issues

   As stated above, many router vendors require an identifier for tag-
   ging their IGP processes. However, this tag does not need to be glo-
   bally unique. In practice this information is never seen by exterior
   routing protocols. If already running an exterior routing protocol,
   it is perfectly reasonable to use your AS number as an IGP tag; if
   you do not, choosing from the reserved range is also acceptable (see
   ``Reserved AS Numbers''). Merely running an IGP is not grounds for
   registration of an AS number.

   With the advent of BGP4 it becomes necessary to use an IGP that can
   carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS].

Hawkinson & Bates       Expires 6 November, 1995                [Page 9]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

9. AS Space exhaustion

   The AS number space is a finite amount of address space. It is
   currently defined as a 16 bit integer and hence limited to 65535
   unique AS numbers. At the time of writing some 5,100 ASes have been
   allocated and a little under 600 ASes are actively routed in the glo-
   bal Internet. It is clear that this growth needs to be continually
   monitored. However, if the criteria applied above are adhered to,
   then there is no immediate danger of AS space exhaustion. It is
   expected that IDRP will be deployed before this becomes an issue.
   IDRP does not have a fixed limit on the size of an RDI.

10. Reserved AS Numbers

   The Internet Assigned Numbers Authority (IANA) has reserved the fol-
   lowing block of AS numbers for private use (not to be advertised on
   the global Internet):

                           64512 through 65535

11. Security Considerations

   There are few security concerns regarding the selection of ASes.

   AS number to owner mappings are public knowledge (in WHOIS), and
   attempting to change that would serve only to confuse those people
   attempting to route IP traffic on the Internet.

12. Acknowledgments

   This document is largely based on [RIPE-109], and is intended to have
   a wider scope than purely the RIPE community; this document would not
   exist without [RIPE-109].

13. References

   [RIPE-109]
        Bates, T., Lord, A., "Autonomous System Number Application  Form
        &   Supporting  Notes",  RIPE  109,  RIPE  NCC,  1  March  1994.
        URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt.

Hawkinson & Bates       Expires 6 November, 1995               [Page 10]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

[BGP-4]
     Rekhter, Y. and T. Li,  "A Border Gateway Protocol 4 (BGP-4)",  RFC
     1654, T.J. Watson Research Center, cisco Systems, July 1994.

[EGP]
     Mills, D. "Exterior Gateway Protocol  formal  specifications",  RFC
     904,  STD  18,  International  Telegraph and Telephone Co., 1 April
     1984.

[IDRP]
     Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol  (IDRP)",
     ISO/IEC 10747, Work In Progress, October 1993.

[CIDR]
     Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless  Inter-Domain
     Routing  (CIDR):  an  Address Assignment and Aggregation Strategy",
     RFC 1519, BARRnet, cisco, MERIT, OARnet, September 1993.

[OSPF]
     Moy, J., "OSPF Version 2", RFC 1583, March 1994.

[ISIS]
     Callon, R., Gunner, C., "Use of OSI IS-IS for Routing in TCP/IP and
     Multi-Protocol Environments", draft-ietf-isis-tcpip-01.txt, WORK IN
     PROGRESS, July 1994.

Hawkinson & Bates       Expires 6 November, 1995               [Page 11]
INTERNET-DRAFT      Guidelines for creation of an AS            May 1995

14. Authors' Addresses

John Hawkinson
Panix
1200 Warburton Ave., Suite 57
Yonkers, NY 10701-1057

phone: +1 617 253 7788
email: jhawk@panix.com

Tony Bates
MCI
2100 Reston Parkway
Reston, VA 22094

phone: +1 703 715 7521
email: Tony.Bates@mci.net

Hawkinson & Bates       Expires 6 November, 1995               [Page 12]