rfc1930.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1930            Guidelines for creation of an AS          March 1996


   *    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
        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 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
        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 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
        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 service
        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 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 be used as a reference from
        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
   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
   decisions. Nevertheless, it may occasionally be necessary to split
   up an AS or a prefix into two ASes for policy reasons. Those making



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 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 a prefix
   may be represented as residing in more than one AS, however, this is
   very much the exception rather than the rule. This happens when
   aggregating using the AS_SET attribute in BGP, wherein the concept of
   origin is lost. In some cases the origin AS is lost altogether 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
   tagging their IGP processes. However, this tag does not need to be
   globally 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 private use 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].

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



Hawkinson & Bates        Best Current Practice                  [Page 8]

RFC 1930            Guidelines for creation of an AS          March 1996


10. Reserved AS Numbers

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following 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.

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




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 Equipment
        Corporation, December 1990.

14. Authors' Addresses

   John Hawkinson
   BBN Planet Corporation
   150 CambridgePark Drive
   Cambridge, MA 02139

   Phone:  [phone]
   EMail: [e-mail]


   Tony Bates
   MCI
   2100 Reston Parkway
   Reston, VA 22094

   Phone: [phone]
   EMail: [e-mail]

























Hawkinson & Bates        Best Current Practice                 [Page 10]