As per Relevance of the word hawkinson, we have this rfc below:
Network Working Group J.
Request for Comments: 1930 BBN
BCP: 6 T.
Category: Best Current Practice
March 1996
Guidelines for creation, selection, and
of an Autonomous System (AS
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
This memo discusses when it is appropriate to register and utilize
Autonomous System (AS), and lists criteria for such. ASes are
unit of routing policy in the modern world of exterior routing,
are specifically applicable to protocols like EGP (Exterior
Protocol, now at historical status; see [EGP]), BGP (Border
Protocol, the current de facto standard for inter-AS routing;
[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which
Internet is expected to adopt when BGP becomes obsolete; see [IDRP]).
It should be noted that the IDRP equivalent of an AS is the RDI,
Routing Domain Identifier
Table of
1. Introduction ............................................ 2
2. Motivation .............................................. 2
3. Definitions ............................................. 2
4. Common errors in allocating ASes ........................ 5
5. Criteria for the decision -- do I need an AS? .......... 5
5.1 Sample Cases ........................................... 6
5.2 Other Factors .......................................... 7
6. Speculation ............................................. 7
7. One prefix, one origin AS ............................... 8
8. IGP issues .............................................. 8
9. AS Space exhaustion ..................................... 8
10. Reserved AS Numbers .................................... 9
11. Security Considerations ................................ 9
12. Acknowledgments ........................................ 9
13. References ............................................. 9
14. Authors' Addresses ..................................... 10
Hawkinson & Bates Best Current Practice [Page 1]
RFC 1930 Guidelines for creation of an AS March 1996
1.
This memo discusses when it is appropriate to register and utilize
Autonomous System (AS), and lists criteria for such. ASes are
unit of routing policy in the modern world of exterior routing,
are specifically applicable to protocols like EGP (Exterior
Protocol, now at historical status; see [EGP]), BGP (Border
Protocol, the current de facto standard for inter-AS routing;
[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which
Internet is expected to adopt when BGP becomes obsolete; see [IDRP]).
It should be noted that the IDRP equivalent of an AS is the RDI,
Routing Domain Identifier
2.
This memo is aimed at network operators and service providers
need to understand under what circumstances they should make use
an AS. It is expected that the reader is familiar with
protocols and will be someone who configures and operates
networks. Unfortunately, there is a great deal of confusion in
ASes should be used today; this memo attempts to clear up some
this confusion, as well as acting as a simple guide to today'
exterior routing
3.
This document refers to the term "prefix" throughout. In the
classless Internet (see [CIDR]), a block of class A, B, or C
may be referred to by merely a prefix and a mask, so long as such
block of networks begins and ends on a power-of-two boundary.
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
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
Hawkinson & Bates Best Current Practice [Page 2]
RFC 1930 Guidelines for creation of an AS March 1996
The classic definition of an Autonomous System is a set of
under a single technical administration, using an interior
protocol and common metrics to route packets within the AS,
using an exterior gateway protocol to route packets to other ASes
Since this classic definition was developed, it has become
for a single AS to use several interior gateway protocols
sometimes several sets of metrics within an AS. The use of
term Autonomous System here stresses the fact that, even
multiple IGPs and metrics are used, the administration of an
appears to other ASes to have a single coherent interior
plan and presents a consistent picture of what networks
reachable through it
To rephrase succinctly
An AS is a connected group of one or more IP prefixes run by
or more network operators which has a SINGLE and CLEARLY
routing policy
Routing policy here is defined as how routing decisions are made
the Internet today. It is the exchange of routing
between ASes that is subject to routing policies. Consider the
of two ASes, X and Y exchanging routing information
NET1 ...... ASX <---> ASY ....... NET
ASX knows how to reach a prefix called NET1. It does not
whether NET1 belongs to ASX or to some other AS which
routing information with ASX, either directly or indirectly; we
assume that ASX knows how to direct packets towards NET1.
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 NET
from ASY. Policy comes into play when ASX decides to announce NET1
ASY
For traffic to flow, ASY has to accept this routing information
use it. It is ASY's privilege to either use or disregard
information that it receives from ASX about NET1's reachability.
might decide not to use this information if it does not want to
traffic to NET1 at all or if it considers another route
appropriate to reach NET1.
In order for traffic in the direction of NET1 to flow between ASX
ASY, ASX must announce that route to ASY and ASY must accept it
ASX
Hawkinson & Bates Best Current Practice [Page 3]
RFC 1930 Guidelines for creation of an AS March 1996
resulting packet flow towards NET
<<===================================
|
|
announce NET1 | accept NET
--------------> + ------------->
|
AS X | AS
|
<------------- + <--------------
accept NET2 | announce NET
|
|
resulting packet flow towards NET
===================================>>
Ideally, though seldom practically, the announcement and
policies of ASX and ASY are symmetrical
In order for traffic towards NET2 to flow, announcement
acceptance of NET2 must be in place (mirror image of NET1).
almost all applications connectivity in just one direction is
useful at all
It should be noted that, in more complex topologies than
example, traffic from NET1 to NET2 may not necessarily take the
path as traffic from NET2 to NET1; this is called
routing. Asymmetrical routing is not inherently bad, but can
cause performance problems for higher level protocols, such as TCP
and should be used with caution and only when necessary. However
assymetric routing may be a requirement for mobile hosts
inherently asymmetric siutation, such a satelite download and a
upload connection
Policies are not configured for each prefix separately but for
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
in both the exchange of exterior routing information (
neighboring ASes), and as an identifier of the AS itself
In routing terms, an AS will normally use one or more
gateway protocols (IGPs) when exchanging reachability
within its own AS. See "IGP Issues".
Hawkinson & Bates Best Current Practice [Page 4]
RFC 1930 Guidelines for creation of an AS March 1996
4. Common errors in allocating
The term AS is often confused or even misused as a convenient way
grouping together a set of prefixes which belong under the
administrative umbrella, even if within that group of prefixes
are various different routing policies. Without exception, an AS
have only one routing policy
It is essential that careful consideration and coordination
applied during the creation of an AS. Using an AS merely for the
of having an AS is to be avoided, as is the worst-case scenario
one AS per classful network (the IDEAL situation is to have
prefix, containing many longer prefixes, per AS). This may mean
some re-engineering may be required in order to apply the
and guidelines for creation and allocation of an AS that we
below; nevertheless, doing so is probably the only way to
the desired routing policy
If you are currently engineering an AS, careful thought should
taken to register appropriately sized CIDR blocks with
registration authority in order to minimize the number of
prefixes from your AS. In the perfect world that number can,
should, be as low as one
Some router implementations use an AS number as a form of tagging
identify interior as well as exterior routing processes. This
does not need to be unique unless routing information is
exchanged with other ASes. See "IGP Issues".
5. Criteria for the decision -- do I need an AS
* Exchange of external routing
An AS must be used for exchanging external routing
with other ASes through an exterior routing protocol. The cur
rent recommended exterior routing protocol is BGP, the
Gateway Protocol. However, the exchange of external
information alone does not constitute the need for an AS.
"Sample Cases" below
* Many prefixes, one
As a general rule, one should try to place as many prefixes
possible within a given AS, provided all of them conform to
same routing policy
Hawkinson & Bates Best Current Practice [Page 5]
RFC 1930 Guidelines for creation of an AS March 1996
* Unique routing
An AS is only needed when you have a routing policy which
different from that of your border gateway peers. Here
policy refers to how the rest of the Internet makes
decisions based on information from your AS. See "
Cases" below to see exactly when this criteria will apply
5.1 Sample
* Single-homed site, single
A separate AS is not needed; the prefix should be placed in
AS of the provider. The site's prefix has exactly the same rout
ing policy as the other customers of the site's
provider, and there is no need to make any distinction in rout
ing information
This idea may at first seem slightly alien to some, but it high
lights the clear distinction in the use of the AS number as
representation of routing policy as opposed to some form
administrative use
In some situations, a single site, or piece of a site, may
it necessary to have a policy different from that of
provider, or the rest of the site. In such an instance, a sepa
rate AS must be created for the affected prefixes. This situa
tion is rare and should almost never happen. Very few stub
require different routing policies than their parents.
the AS is the unit of policy, however, this sometimes occurs
* Single-homed site, multiple
Again, a separate AS is not needed; the prefixes should
placed in an AS of the site's provider
* Multi-homed
Here multi-homed is taken to mean a prefix or group of
which connects to more than one service provider (i.e. more
one AS with its own routing policy). It does not mean a
multi-homed running an IGP for the purposes of resilience
An AS is required; the site's prefixes should be part of
single AS, distinct from the ASes of its service providers
This allows the customer the ability to have a different repre
sentation of policy and preference among the different
providers
Hawkinson & Bates Best Current Practice [Page 6]
RFC 1930 Guidelines for creation of an AS March 1996
This is ALMOST THE ONLY case where a network operator
create its own AS number. In this case, the site should
that it has the necessary facilities to run appropriate
protocols, such as BGP4.
5.2 Other
*
Routing policy decisions such as geography, AUP (Acceptable
Policy) compliance and network topology can influence
of AS creation. However, all too often these are done
consideration of whether or not an AS is needed in terms
adding additional information for routing policy decisions
the rest of the Internet. Careful consideration should be
when basing AS creation on these type of criteria
* Transition / "future-proofing
Often a site will be connected to a single service provider
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
need it. The AS number space is finite and the limited
of re-engineering needed when you connect to another
provider should be considered as a natural step in transition
*
AS number application forms have historically made no
to routing policy. All too often ASes have been created
because it was seen as "part of the process" of connecting
the Internet. The document should be used as a reference
future application forms to show clearly when an AS is needed
6.
1) If provider A and provider B have a large presence in
geographical area (or other routing domain), and many customers
multi-homed between them, it makes sense for all of those
to be placed within the same AS. However, it is noted that
should only be looked at if practical to do so and fully
between customers and service providers involved
2) Sites should not be forced to place themselves in a separate
just so that someone else (externally) can make AS-based
decisions. Nevertheless, it may occasionally be necessary to
up an AS or a prefix into two ASes for policy reasons. Those
Hawkinson & Bates Best Current Practice [Page 7]
RFC 1930 Guidelines for creation of an AS March 1996
external policy may request the network operators make such
changes, but the final decision is up to those network
who manage the prefixes in question, as well as the ASes
them. This is, of course, a trade off -- it will not always
possible to implement all desired routing policies
7. One prefix, one origin
Generally, a prefix can should belong to only one AS. This is
direct consequence of the fact that at each point in the
there can be exactly one routing policy for traffic destined to
prefix. In the case of an prefix which is used in neighbor
between two ASes, a conscious decision should be made as to which
this prefix actually resides in
With the introduction of aggregation it should be noted that a
may be represented as residing in more than one AS, however, this
very much the exception rather than the rule. This happens
aggregating using the AS_SET attribute in BGP, wherein the concept
origin is lost. In some cases the origin AS is lost altogether
there is a less specific aggregate announcement setting
ATOMIC_AGGREGATE attribute
8. IGP
As stated above, many router vendors require an identifier
tagging their IGP processes. However, this tag does not need to
globally unique. In practice this information is never seen
exterior routing protocols. If already running an exterior
protocol, it is perfectly reasonable to use your AS number as an
tag; if you do not, choosing from the private use range is
acceptable (see "Reserved AS Numbers"). Merely running an IGP is
grounds for registration of an AS number
With the advent of BGP4 it becomes necessary to use an IGP that
carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS].
9. AS Space
The AS number space is a finite amount of address space. It
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
allocated and a little under 600 ASes are actively routed in
global Internet. It is clear that this growth needs to be
monitored. However, if the criteria applied above are adhered to
then there is no immediate danger of AS space exhaustion. It
expected that IDRP will be deployed before this becomes an issue
IDRP does not have a fixed limit on the size of an RDI
Hawkinson & Bates Best Current Practice [Page 8]
RFC 1930 Guidelines for creation of an AS March 1996
10. Reserved AS
The Internet Assigned Numbers Authority (IANA) has reserved
following block of AS numbers for private use (not to be
on the global Internet):
64512 through 65535
11. Security
There are few security concerns regarding the selection of ASes
AS number to owner mappings are public knowledge (in WHOIS),
attempting to change that would serve only to confuse those
attempting to route IP traffic on the Internet
12.
This document is largely based on [RIPE-109], and is intended to
a wider scope than purely the RIPE community; this document would
exist without [RIPE-109].
13.
[RIPE-109]
Bates, T., Lord, A., "Autonomous System Number
Form & Supporting Notes", RIPE 109, RIPE NCC, 1 March 1994.
URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt
[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",
STD 18, RFC 904, International Telegraph and Telephone Co.,
April 1984.
[IDRP
Kunzinger, C., Editor, "OSI Inter-Domain Routing
(IDRP)", ISO/IEC 10747, Work In Progress, October 1993.
[CIDR
Fuller, V., T. Li, J. Yu, and K. Varadhan, "
Inter-Domain Routing (CIDR): an Address Assignment
Aggregation Strategy", RFC 1519, BARRnet, cisco, MERIT, OARnet
September 1993.
Hawkinson & Bates Best Current Practice [Page 9]
RFC 1930 Guidelines for creation of an AS March 1996
[OSPF
Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[ISIS
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Multi
Protocol Environments", RFC 1195, Digital
Corporation, December 1990.
14. Authors'
John
BBN Planet
150 CambridgePark
Cambridge, MA 02139
Phone: +1 617 873 3180
EMail: jhawk@bbnplanet.
Tony
2100 Reston
Reston, VA 22094
Phone: +1 703 715 7521
EMail: Tony.Bates@mci.
Hawkinson & Bates Best Current Practice [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
