draft-ietf-idr-autosys-guide-03.txt   rfc1930.txt 
Network Working Group J. Hawkinson Network Working Group J. Hawkinson
INTERNET-DRAFT Panix Request for Comments: 1930 BBN Planet
Category: Standards Track T. Bates BCP: 6 T. Bates
<draft-ietf-idr-autosys-guide-03.txt> MCI Category: Best Current Practice MCI
May 1995 March 1996
Guidelines for creation, selection, and registration Guidelines for creation, selection, and registration
of an Autonomous System (AS) of an Autonomous System (AS)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet Best Current Practices for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet Community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Distribution of this memo is unlimited.
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 Abstract
This draft discusses when it is appropriate to register and utilize This memo discusses when it is appropriate to register and utilize an
an Autonomous System (AS), and lists criteria for such. ASes are the Autonomous System (AS), and lists criteria for such. ASes are the
unit of routing policy in the modern world of exterior routing, and unit of routing policy in the modern world of exterior routing, and
are specifically applicable to protocols like EGP (Exterior Gateway are specifically applicable to protocols like EGP (Exterior Gateway
Protocol, now at historical status; see [EGP]), BGP (Border Gateway Protocol, now at historical status; see [EGP]), BGP (Border Gateway
Protocol, the current de facto standard for inter-AS routing; see Protocol, the current de facto standard for inter-AS routing; see
[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the
Internet will eventually adopt when BGP becomes obsolete; see Internet is expected to adopt when BGP becomes obsolete; see [IDRP]).
[IDRP]). It should be noted that the IDRP equivalent of an AS is the It should be noted that the IDRP equivalent of an AS is the RDI, or
RDI, or Routing Domain Identifier. Routing Domain Identifier.
Table of Contents Table of Contents
1. Introduction ............................................ 2 1. Introduction ............................................ 2
2. Motivation .............................................. 2
2. Motivation .............................................. 3 3. Definitions ............................................. 2
4. Common errors in allocating ASes ........................ 5
3. Definitions ............................................. 3 5. Criteria for the decision -- do I need an AS? .......... 5
5.1 Sample Cases ........................................... 6
4. Common errors in allocating ASes ........................ 6 5.2 Other Factors .......................................... 7
6. Speculation ............................................. 7
5. Criteria for the decision -- do I need an AS? .......... 6 7. One prefix, one origin AS ............................... 8
8. IGP issues .............................................. 8
5.1 Sample Cases ........................................... 7 9. AS Space exhaustion ..................................... 8
10. Reserved AS Numbers .................................... 9
5.2 Other Factors .......................................... 8 11. Security Considerations ................................ 9
12. Acknowledgments ........................................ 9
6. Speculation ............................................. 8 13. References ............................................. 9
14. Authors' Addresses ..................................... 10
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 1. Introduction
This memo discusses when it is appropriate to register and util- This memo discusses when it is appropriate to register and utilize an
ize an Autonomous System (AS), and lists criteria for such. ASes Autonomous System (AS), and lists criteria for such. ASes are the
are the unit of routing policy in the modern world of exterior unit of routing policy in the modern world of exterior routing, and
routing, and are specifically applicable to protocols like EGP are specifically applicable to protocols like EGP (Exterior Gateway
(Exterior Gateway Protocol, now at historical status; see [EGP]), Protocol, now at historical status; see [EGP]), BGP (Border Gateway
BGP (Border Gateway Protocol, the current de facto standard for Protocol, the current de facto standard for inter-AS routing; see
inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the
Routing Protocol, which the Internet will eventually adopt when Internet is expected to adopt when BGP becomes obsolete; see [IDRP]).
BGP becomes obsolete; see [IDRP]). It should be noted that the It should be noted that the IDRP equivalent of an AS is the RDI, or
IDRP equivalent of an AS is the RDI, or Routing Domain Identif- Routing Domain Identifier.
ier.
2. Motivation 2. Motivation
This memo is aimed at network operators and service providers who This memo is aimed at network operators and service providers who
need to understand under what circumstances they should make use need to understand under what circumstances they should make use of
of an AS. It is expected that the reader is familiar with routing an AS. It is expected that the reader is familiar with routing
protocols and will be someone who configures and operates Inter- protocols and will be someone who configures and operates Internet
net networks. Unfortunately, there is a great deal of confusion networks. Unfortunately, there is a great deal of confusion in how
in how ASes should be used today; this memo attempts to clear up ASes should be used today; this memo attempts to clear up some of
some of this confusion, as well as acting as a simple guide to this confusion, as well as acting as a simple guide to today's
today's exterior routing. exterior routing.
3. Definitions 3. Definitions
This document refers to the term ``prefix'' throughout. In the This document refers to the term "prefix" throughout. In the current
current classless Internet (see [CIDR]), a block of class A, B, classless Internet (see [CIDR]), a block of class A, B, or C networks
or C networks may be referred to by merely a prefix and a mask, may be referred to by merely a prefix and a mask, so long as such a
so long as such a block of networks begins and ends on a power- block of networks begins and ends on a power-of-two boundary. For
of-two boundary. For example, the networks: example, the networks:
192.168.0.0/24 192.168.0.0/24
192.168.1.0/24 192.168.1.0/24
192.168.2.0/24 192.168.2.0/24
192.168.3.0/24 192.168.3.0/24
can be simply referred to as: can be simply referred to as:
192.168.0.0/22 192.168.0.0/22
The term ``prefix'' as it is used here is equivalent to ``CIDR The term "prefix" as it is used here is equivalent to "CIDR block",
block'', and in simple terms may be thought of as a group of one and in simple terms may be thought of as a group of one or more
or more networks. We use the term ``network'' to mean classful networks. We use the term "network" to mean classful network, or "A,
network, or ``A, B, C network''. B, C network".
The definition of AS has been unclear and ambiguous for some The definition of AS has been unclear and ambiguous for some time.
time. [BGP-4] states: [BGP-4] states:
The classic definition of an Autonomous System is a set of The classic definition of an Autonomous System is a set of routers
routers under a single technical administration, using an inte- under a single technical administration, using an interior gateway
rior gateway protocol and common metrics to route packets within protocol and common metrics to route packets within the AS, and
the AS, and using an exterior gateway protocol to route packets using an exterior gateway protocol to route packets to other ASes.
to other ASes. Since this classic definition was developed, it Since this classic definition was developed, it has become common
has become common for a single AS to use several interior for a single AS to use several interior gateway protocols and
gateway protocols and sometimes several sets of metrics within sometimes several sets of metrics within an AS. The use of the
an AS. The use of the term Autonomous System here stresses the term Autonomous System here stresses the fact that, even when
fact that, even when multiple IGPs and metrics are used, the multiple IGPs and metrics are used, the administration of an AS
administration of an AS appears to other ASes to have a single appears to other ASes to have a single coherent interior routing
coherent interior routing plan and presents a consistent picture plan and presents a consistent picture of what networks are
of what networks are reachable through it. reachable through it.
To rephrase succinctly: To rephrase succinctly:
An AS is a connected group of IP networks run by one or more An AS is a connected group of one or more IP prefixes run by one
network operators which has a SINGLE and CLEARLY DEFINED routing or more network operators which has a SINGLE and CLEARLY DEFINED
policy. routing policy.
Routing policy here is defined as how routing decisions are made in Routing policy here is defined as how routing decisions are made in
the Internet today. It is the exchange of routing information the Internet today. It is the exchange of routing information
between ASes that is subject to routing policies. Consider the case between ASes that is subject to routing policies. Consider the case
of two ASes, X and Y exchanging routing information: of two ASes, X and Y exchanging routing information:
NET1 ...... ASX <---> ASY ....... NET2 NET1 ...... ASX <---> ASY ....... NET2
ASX knows how to reach a prefix called NET1. It does not matter 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- whether NET1 belongs to ASX or to some other AS which exchanges
ing information with ASX, either directly or indirectly; we just routing information with ASX, either directly or indirectly; we just
assume that ASX knows how to direct packets towards NET1. Likewise assume that ASX knows how to direct packets towards NET1. Likewise
ASY knows how to reach NET2. ASY knows how to reach NET2.
In order for traffic from NET2 to NET1 to flow between ASX and ASY, 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; ASX has to announce NET1 to ASY using an exterior routing protocol;
this means that ASX is willing to accept traffic directed to NET1 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 from ASY. Policy comes into play when ASX decides to announce NET1 to
ASY. ASY.
For traffic to flow, ASY has to accept this routing information and 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- use it. It is ASY's privilege to either use or disregard the
mation that it receives from ASX about NET1's reachability. ASY might information that it receives from ASX about NET1's reachability. ASY
decide not to use this information if it does not want to send 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 traffic to NET1 at all or if it considers another route more
appropriate to reach NET1. appropriate to reach NET1.
In order for traffic in the direction of NET1 to flow between ASX and 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 ASY, ASX must announce that route to ASY and ASY must accept it from
ASX: ASX:
resulting packet flow towards NET1 resulting packet flow towards NET1
<<=================================== <<===================================
| |
skipping to change at page 5, line 22 skipping to change at page 4, line 22
AS X | AS Y AS X | AS Y
| |
<------------- + <-------------- <------------- + <--------------
accept NET2 | announce NET2 accept NET2 | announce NET2
| |
| |
resulting packet flow towards NET2 resulting packet flow towards NET2
===================================>> ===================================>>
Ideally, though seldom practically, the announcement and acceptance Ideally, though seldom practically, the announcement and acceptance
policies of ASX and ASY are identical. policies of ASX and ASY are symmetrical.
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- In order for traffic towards NET2 to flow, announcement and
ple, traffic from NET1 to NET2 may not necessarily take the same path acceptance of NET2 must be in place (mirror image of NET1). For
as traffic from NET2 to NET1; this is called asymmetrical routing. almost all applications connectivity in just one direction is not
Asymmetrical routing is not inherently bad, but can often cause per- useful at all.
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- It should be noted that, in more complex topologies than this
warding technology routing policies must eventually be expressed in example, traffic from NET1 to NET2 may not necessarily take the same
these terms. path as traffic from NET2 to NET1; this is called asymmetrical
routing. Asymmetrical routing is not inherently bad, but can often
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 and
inherently asymmetric siutation, such a satelite download and a modem
upload connection.
Policies are not configured for each prefix separately but for groups Policies are not configured for each prefix separately but for groups
of prefixes. These groups of prefixes are ASes. of prefixes. These groups of prefixes are ASes.
An AS has a globally unique number (sometimes referred to as an ASN, An AS has a globally unique number (sometimes referred to as an ASN,
or Autonomous System Number) associated with it; this number is used or Autonomous System Number) associated with it; this number is used
in both the exchange of exterior routing information (between neigh- in both the exchange of exterior routing information (between
boring ASes), and as an identifier of the AS itself. neighboring ASes), and as an identifier of the AS itself.
In routing terms, an AS will normally use one or more interior gate- In routing terms, an AS will normally use one or more interior
way protocols (IGPs) when exchanging reachability information within gateway protocols (IGPs) when exchanging reachability information
its own AS. See ``IGP Issues''. within its own AS. See "IGP Issues".
4. Common errors in allocating ASes 4. Common errors in allocating ASes
The term AS is often confused or even misused as a convenient way of 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 grouping together a set of prefixes which belong under the same
administrative umbrella, even if within that group of prefixes there administrative umbrella, even if within that group of prefixes there
are various different routing policies. Without exception, an AS must are various different routing policies. Without exception, an AS must
have only one routing policy. have only one routing policy.
It is essential that careful consideration and coordination be It is essential that careful consideration and coordination be
applied during the creation of an AS. Using an AS merely for the sake 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 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- one AS per classful network (the IDEAL situation is to have one
fix, containing many networks, per AS). This may mean that some re- prefix, containing many longer prefixes, per AS). This may mean that
engineering may be required in order to apply the criteria and guide- some re-engineering may be required in order to apply the criteria
lines for creation and allocation of an AS that we list below; and guidelines for creation and allocation of an AS that we list
nevertheless, doing so is probably the only way to implement the below; nevertheless, doing so is probably the only way to implement
desired routing policy. the desired routing policy.
If you are currently engineering an AS, careful thought should be If you are currently engineering an AS, careful thought should be
taken to register appropriately sized CIDR blocks with your registra- taken to register appropriately sized CIDR blocks with your
tion authority in order to minimize the number of advertised prefixes registration authority in order to minimize the number of advertised
from your AS. In the perfect world that number can, and should, be prefixes from your AS. In the perfect world that number can, and
as low as one. should, be as low as one.
Some router implementations use an AS number as a form of tagging to Some router implementations use an AS number as a form of tagging to
identify interior as well as exterior routing processes. This tag identify interior as well as exterior routing processes. This tag
does not need to be unique unless routing information is indeed does not need to be unique unless routing information is indeed
exchanged with other ASes. See ``IGP Issues''. exchanged with other ASes. See "IGP Issues".
5. Criteria for the decision -- do I need an AS? 5. Criteria for the decision -- do I need an AS?
* Exchange of external routing information * Exchange of external routing information
An AS must be used for exchanging external routing information An AS must be used for exchanging external routing information
with other ASes through an exterior routing protocol. The with other ASes through an exterior routing protocol. The cur-
current recommended exterior routing protocol is BGP, the Border rent recommended exterior routing protocol is BGP, the Border
Gateway Protocol. However, the exchange of external routing Gateway Protocol. However, the exchange of external routing
information alone does not constitute the need for an AS. See information alone does not constitute the need for an AS. See
``Sample Cases'' below. "Sample Cases" below.
* Many prefixes, one AS * Many prefixes, one AS
As a general rule, one should try to place as many prefixes 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 possible within a given AS, provided all of them conform to the
same routing policy. same routing policy.
* Unique routing policy * Unique routing policy
An AS is only needed when you have a routing policy which is An AS is only needed when you have a routing policy which is
different from that of your border gateway peers. Here routing different from that of your border gateway peers. Here routing
policy refers to how the rest of the Internet makes routing policy refers to how the rest of the Internet makes routing
decisions based on information from your AS. See ``Sample decisions based on information from your AS. See "Sample
Cases'' below to see exactly when this criteria will apply. Cases" below to see exactly when this criteria will apply.
5.1 Sample Cases 5.1 Sample Cases
* Single-homed site, single prefix * Single-homed site, single prefix
A separate AS is not needed; the prefix should be placed in an 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- 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- ing policy as the other customers of the site's service
vider, and there is no need to make any distinction in routing provider, and there is no need to make any distinction in rout-
information. ing information.
This idea may at first seem slightly alien to some, but it This idea may at first seem slightly alien to some, but it high-
highlights the clear distinction in the use of the AS number as lights the clear distinction in the use of the AS number as a
a representation of routing policy as opposed to some form of representation of routing policy as opposed to some form of
administrative use. administrative use.
In some situations, a single site, or piece of a site, may find 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- it necessary to have a policy different from that of its
vider, or the rest of the site. In such an instance, a separate provider, or the rest of the site. In such an instance, a sepa-
AS must be created for the affected prefixes. This situation is rate AS must be created for the affected prefixes. This situa-
rare and should almost never happen. Very few stub sites require tion is rare and should almost never happen. Very few stub sites
different routing policies than their parents. Because the AS is require different routing policies than their parents. Because
the unit of policy, however, this sometimes occurs. the AS is the unit of policy, however, this sometimes occurs.
* Single-homed site, multiple prefixes * Single-homed site, multiple prefixes
Again, a separate AS is not needed; the prefixes should be Again, a separate AS is not needed; the prefixes should be
placed in an AS of the site's provider. placed in an AS of the site's provider.
* Multi-homed site * Multi-homed site
Here multi-homed is taken to mean a prefix or group of prefixes 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 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 one AS with its own routing policy). It does not mean a network
multi-homed running an IGP for the purposes of resilience. multi-homed running an IGP for the purposes of resilience.
An AS is required; the site's prefixes should be part of a An AS is required; the site's prefixes should be part of a
single AS, distinct from the ASes of its service providers. single AS, distinct from the ASes of its service providers.
This allows the customer the ability to have a different This allows the customer the ability to have a different repre-
representation of policy and preference among the different ser- sentation of policy and preference among the different service
vice providers. providers.
This is ALMOST THE ONLY case where a network operator should This is ALMOST THE ONLY case where a network operator should
create its own AS number. In this case, the site should ensure create its own AS number. In this case, the site should ensure
that it has the necessary facilities to run appropriate routing that it has the necessary facilities to run appropriate routing
protocols, such as BGP4. protocols, such as BGP4.
5.2 Other factors 5.2 Other factors
* Topology * Topology
Routing policy decisions such as geography, AUP (Acceptable Use Routing policy decisions such as geography, AUP (Acceptable Use
Policy) compliance and network topology can influence decisions Policy) compliance and network topology can influence decisions
of AS creation. However, all too often these are done without of AS creation. However, all too often these are done without
consideration of whether or not an AS is needed in terms of consideration of whether or not an AS is needed in terms of
adding additional information for routing policy decisions by adding additional information for routing policy decisions by
the rest of the Internet. Careful consideration should be taken the rest of the Internet. Careful consideration should be taken
when basing AS creation on these type of criteria. when basing AS creation on these type of criteria.
* Transition / ``future-proofing'' * Transition / "future-proofing"
Often a site will be connected to a single service provider but Often a site will be connected to a single service provider but
has plans to connect to another at some point in the future. 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 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 need it. The AS number space is finite and the limited amount
of re-engineering needed when you connect to another service of re-engineering needed when you connect to another service
provider should be considered as a natural step in transition. provider should be considered as a natural step in transition.
* History * History
AS number application forms have historically made no reference AS number application forms have historically made no reference
to routing policy. All too often ASes have been created purely to routing policy. All too often ASes have been created purely
because it was seen as ``part of the process'' of connecting to because it was seen as "part of the process" of connecting to
the Internet. The document should act as reference to future the Internet. The document should be used as a reference from
application forms to show clearly when an AS is needed. future application forms to show clearly when an AS is needed.
6. Speculation 6. Speculation
1) If provider A and provider B have a large presence in a 1) If provider A and provider B have a large presence in a
geographical area (or other routing domain), and many customers are geographical area (or other routing domain), and many customers are
multi-homed between them, it makes sense for all of those customers 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 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 should only be looked at if practical to do so and fully coordinated
between customers and service providers involved. between customers and service providers involved.
2) Sites should not be forced to place themselves in a separate AS 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- just so that someone else (externally) can make AS-based policy
sions. Nevertheless, it may occasionally be necessary to split up an decisions. Nevertheless, it may occasionally be necessary to split
AS or a prefix into two ASes for policy reasons. Those making exter- up an AS or a prefix into two ASes for policy reasons. Those making
nal policy may request the network operators make such AS changes, external policy may request the network operators make such AS
but the final decision is up to those network operators who manage changes, but the final decision is up to those network operators
the prefixes in question, as well as the ASes containing them. This who manage the prefixes in question, as well as the ASes containing
is, of course, a trade off -- it will not always be possible to them. This is, of course, a trade off -- it will not always be
implement all desired routing policies. possible to implement all desired routing policies.
7. One prefix, one origin AS 7. One prefix, one origin AS
Generally, a prefix can should belong to only one AS. This is a 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 direct consequence of the fact that at each point in the Internet
there can be exactly one routing policy for traffic destined to each 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 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 between two ASes, a conscious decision should be made as to which AS
this prefix actually resides in. this prefix actually resides in.
With the introduction of aggregation it should be noted that an AS With the introduction of aggregation it should be noted that a prefix
can occasionally be represented as residing in more than one AS, how- may be represented as residing in more than one AS, however, this is
ever, this is very much the exception rather than the rule. This hap- very much the exception rather than the rule. This happens when
pens when aggregating using the AS_SET attribute in BGP, wherein the aggregating using the AS_SET attribute in BGP, wherein the concept of
concept of origin is lost. In some cases the origin AS is lost alto- origin is lost. In some cases the origin AS is lost altogether if
gether if there is a less specific aggregate announcement setting the there is a less specific aggregate announcement setting the
ATOMIC_AGGREGATE attribute. ATOMIC_AGGREGATE attribute.
8. IGP Issues 8. IGP Issues
As stated above, many router vendors require an identifier for tag- As stated above, many router vendors require an identifier for
ging their IGP processes. However, this tag does not need to be glo- tagging their IGP processes. However, this tag does not need to be
bally unique. In practice this information is never seen by exterior globally unique. In practice this information is never seen by
routing protocols. If already running an exterior routing protocol, exterior routing protocols. If already running an exterior routing
it is perfectly reasonable to use your AS number as an IGP tag; if protocol, it is perfectly reasonable to use your AS number as an IGP
you do not, choosing from the reserved range is also acceptable (see tag; if you do not, choosing from the private use range is also
``Reserved AS Numbers''). Merely running an IGP is not grounds for acceptable (see "Reserved AS Numbers"). Merely running an IGP is not
registration of an AS number. grounds for registration of an AS number.
With the advent of BGP4 it becomes necessary to use an IGP that can With the advent of BGP4 it becomes necessary to use an IGP that can
carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS]. carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS].
9. AS Space exhaustion 9. AS Space exhaustion
The AS number space is a finite amount of address space. It is 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 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 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- allocated and a little under 600 ASes are actively routed in the
bal Internet. It is clear that this growth needs to be continually global Internet. It is clear that this growth needs to be continually
monitored. However, if the criteria applied above are adhered to, monitored. However, if the criteria applied above are adhered to,
then there is no immediate danger of AS space exhaustion. It is then there is no immediate danger of AS space exhaustion. It is
expected that IDRP will be deployed before this becomes an issue. expected that IDRP will be deployed before this becomes an issue.
IDRP does not have a fixed limit on the size of an RDI. IDRP does not have a fixed limit on the size of an RDI.
10. Reserved AS Numbers 10. Reserved AS Numbers
The Internet Assigned Numbers Authority (IANA) has reserved the fol- The Internet Assigned Numbers Authority (IANA) has reserved the
lowing block of AS numbers for private use (not to be advertised on following block of AS numbers for private use (not to be advertised
the global Internet): on the global Internet):
64512 through 65535 64512 through 65535
11. Security Considerations 11. Security Considerations
There are few security concerns regarding the selection of ASes. There are few security concerns regarding the selection of ASes.
AS number to owner mappings are public knowledge (in WHOIS), and AS number to owner mappings are public knowledge (in WHOIS), and
attempting to change that would serve only to confuse those people attempting to change that would serve only to confuse those people
attempting to route IP traffic on the Internet. attempting to route IP traffic on the Internet.
12. Acknowledgments 12. Acknowledgments
This document is largely based on [RIPE-109], and is intended to have 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 a wider scope than purely the RIPE community; this document would not
exist without [RIPE-109]. exist without [RIPE-109].
13. References 13. References
[RIPE-109] [RIPE-109]
Bates, T., Lord, A., "Autonomous System Number Application Form Bates, T., Lord, A., "Autonomous System Number Application
& Supporting Notes", RIPE 109, RIPE NCC, 1 March 1994. Form & Supporting Notes", RIPE 109, RIPE NCC, 1 March 1994.
URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt. URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt.
[BGP-4] [BGP-4]
Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
1654, T.J. Watson Research Center, cisco Systems, July 1994. RFC 1654, T.J. Watson Research Center, cisco Systems, July 1994.
[EGP] [EGP]
Mills, D. "Exterior Gateway Protocol formal specifications", RFC Mills, D., "Exterior Gateway Protocol Formal Specifications",
904, STD 18, International Telegraph and Telephone Co., 1 April STD 18, RFC 904, International Telegraph and Telephone Co.,
1984. April 1984.
[IDRP] [IDRP]
Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol (IDRP)", Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol
ISO/IEC 10747, Work In Progress, October 1993. (IDRP)", ISO/IEC 10747, Work In Progress, October 1993.
[CIDR] [CIDR]
Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless
Routing (CIDR): an Address Assignment and Aggregation Strategy", Inter-Domain Routing (CIDR): an Address Assignment and
RFC 1519, BARRnet, cisco, MERIT, OARnet, September 1993. Aggregation Strategy", RFC 1519, BARRnet, cisco, MERIT, OARnet,
September 1993.
[OSPF] [OSPF]
Moy, J., "OSPF Version 2", RFC 1583, March 1994. Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[ISIS] [ISIS]
Callon, R., Gunner, C., "Use of OSI IS-IS for Routing in TCP/IP and Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Multi-
Multi-Protocol Environments", draft-ietf-isis-tcpip-01.txt, WORK IN Protocol Environments", RFC 1195, Digital Equipment
PROGRESS, July 1994. Corporation, December 1990.
14. Authors' Addresses 14. Authors' Addresses
John Hawkinson John Hawkinson
Panix BBN Planet Corporation
1200 Warburton Ave., Suite 57 150 CambridgePark Drive
Yonkers, NY 10701-1057 Cambridge, MA 02139
phone: +1 617 253 7788 Phone: +1 617 873 3180
email: jhawk@panix.com EMail: jhawk@bbnplanet.com
Tony Bates Tony Bates
MCI MCI
2100 Reston Parkway 2100 Reston Parkway
Reston, VA 22094 Reston, VA 22094
phone: +1 703 715 7521 Phone: +1 703 715 7521
email: Tony.Bates@mci.net EMail: Tony.Bates@mci.net
 End of changes. 48 change blocks. 
218 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/