⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1930.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 2 页
字号:
Network Working Group                                       J. HawkinsonRequest for Comments: 1930                                    BBN PlanetBCP: 6                                                          T. BatesCategory: Best Current Practice                                      MCI                                                              March 1996          Guidelines for creation, selection, and registration                      of an Autonomous System (AS)Status of this Memo   This document specifies an Internet Best Current Practices for the   Internet Community, and requests discussion and suggestions for   improvements.  Distribution of this memo is unlimited.Abstract   This memo 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 is expected to 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.Table of Contents   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 .....................................   10Hawkinson & Bates        Best Current Practice                  [Page 1]RFC 1930            Guidelines for creation of an AS          March 19961. Introduction   This memo 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 is expected to 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.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 Internet   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: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 routers      under a single technical administration, using an interior 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 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 one or more IP prefixes 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   routing 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   information 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        Best Current Practice                  [Page 3]RFC 1930            Guidelines for creation of an AS          March 1996                    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 symmetrical.   In order for traffic towards NET2 to flow, announcement and   acceptance 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   example, 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 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   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   neighboring ASes), and as an identifier of the AS itself.   In routing terms, an AS will normally use one or more interior   gateway protocols (IGPs) when exchanging reachability information   within its own AS. See "IGP Issues".Hawkinson & Bates        Best Current Practice                  [Page 4]RFC 1930            Guidelines for creation of an AS          March 19964. 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   prefix, containing many longer prefixes, per AS). This may mean that   some re-engineering may be required in order to apply the criteria   and guidelines 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   registration 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 cur-        rent 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        Best Current Practice                  [Page 5]

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -