rfc1786.txt

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

   white list.  Together these lists comprise all ASes in the world
   reachable from AS Z.

                            "W"
                           <--->
                       ...           AS Z .... NET 3
                           <--->
                            "B"

   It is quite possible to implement the policy for traffic originating
   in AS Z: AS Z will only accept announcements for networks in white
   ASes on the white link and will only accept announcements for
   networks in black ASes on the black link.  This causes traffic from
   networks within AS Z towards white ASes to use the white link and
   likewise traffic for black ASes to use the black link.

   Note that this way of implementing things makes it necessary to
   decide on the colour of each new AS which appears before traffic can
   be sent to it from AS Z.  A way around this would be to accept only
   white announcements via the white link and to accept all but white
   announcements on the black link.  That way traffic from new ASes
   would automatically be sent down the black link and AS Z management
   would only need to keep the list of white ASes rather than two lists.

   Now for the unimplementable part of the policy.  This concerns
   traffic towards AS Z.  Consider the following topology:

           B AS ---)                    "W"
           W AS ---)                    --->
           B AS ---)>>  AS A  ---> ...           AS Z .... NET 3
           B AS ---)                    --->
           W AS ---)                    "B"

   As seen from AS Z there are both black and white ASes "behind" AS A.
   Since ASes can make routing decisions based on destination only, AS A
   and all ASes between AS A and the two links connecting AS Z can only
   make the same decision for traffic directed at a network in AS Z, say
   NET 3.  This means that traffic from both black and white ASes
   towards NET 3 will follow the same route once it passes through AS A.
   This will either be the black or the white route depending on the
   routing policies of AS A and all ASes between it and AS Z.




Bates, et al.                                                   [Page 8]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   The important thing to note is that unless routing and forwarding
   decisions can be made based on both source and destination addresses,
   policies like the "black and white" example cannot be implemented in
   general because "once joined means joined forever".


   Access Policies

   Access policies contrary to routing policies are not necessarily
   defined in terms of ASes. The very simplest type of access policy is
   to block packets from a specific network S from being forwarded to
   another network D. A common example is when some inappropriate use of
   resources on network D has been made from network S and the problem
   has not been resolved yet. Other examples of access policies might be
   resources only accessible to networks belonging to a particular
   disciplinary group or community of interest.  While most of these
   policies are better implemented at the host or application level,
   network level access policies do exist and are a source of
   connectivity problems which are sometimes hard to diagnose. Therefore
   they should also be documented in the routing registry according to
   similar requirements as outlined above.



   Routing vs. Allocation information

   The RIPE database contains both routing registry and address space
   allocation registry information. In the past the database schema
   combined this information. Because RIPE was tasked with running both
   an allocation and routing registry it seemed natural to initially
   combine these functions.  However, experience has shown that a clear
   separation of routing information from allocation is desirable. Often
   the maintainer of the routing information is not the same as the
   maintainer of the allocation information.  Moreover, in other parts
   of the world there are different registries for each kind of
   information.

   Whilst the actual routing policy objects will be introduced in the
   next section it is worthy of note that a transition from the current
   objects will be required. Appendix G details the basic steps of such
   a transition.

   This split in information represents a significant change in the
   representational model of the RIPE database. Appendix F expands on
   the reasons for this a little more.






Bates, et al.                                                   [Page 9]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   Tools

   The network operators will need a series of tools for policy routing.
   Some tools are already available to perform some of the tasks. Most
   notably, the PRIDE tools [3] from the PRIDE project started in
   September 1993 as well as others produced by Merit Inc [4] and CERN
   [5].

   These tools will enable them to use the routing policy stored in the
   RIPE routing registry to perform such tasks as check actual routing
   against policies defined, ensure consistency of policies set by
   different operators, and simulate the effects of policy changes.

   Work continues on producing more useful tools to service the Internet
   community.




































Bates, et al.                                                  [Page 10]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


4.  The Routing Registry and the RIPE Database

   One of the activities of RIPE is to maintain a  database  of European
   IP networks, DNS domains and their contact persons along with various
   other kinds of network management information. The database content
   is public and can be queried using the whois protocol as well as
   retrieved as a whole.  This supports NICs/NOCs all over Europe  and
   beyond  to  perform their respective tasks.

   The RIPE database combines both allocation registry and routing
   registry functions.  The RIPE allocation registry contains data about
   address space allocated to specific enterprises and/or delegated to
   local registries as well as data about the domain name space. The
   allocation registry is described in separate documents [6,7] and
   outside the scope of this document.


   Database Objects

   Each object in the database describes a single entity in the real
   world.  This  basic  principle  means that information about  that
   entity  should  only  be  represented  in   the corresponding
   database  object and not be repeated in other objects.  The whois
   service can automatically display referenced objects where
   appropriate.

   The types of objects stored in the RIPE database are summarized in
   the table below:


   R   Object      Describes                        References
   ____________________________________________________________________

   B   person      contact persons

   A   inetnum     IP address space                 person
   A   domain      DNS domain                       person

   R   aut-num     autonomous system                person
                                                    (aut-num,community)
   R   as-macro    a group of autonomous systems    person, aut-num
   R   community   community                        person
   R   route       a route being announced          aut-num, community

   R   clns        CLNS address space and routing   person


   The first column indicates whether the object is part of the
   allocation registry (A), the routing registry (R) or both (B).  The


Bates, et al.                                                  [Page 11]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   last column indicates the types of objects referenced by the
   particular type of object.  It can be seen that almost all objects
   reference contact persons.

   Objects are described by attributes  value  pairs,  one  per line.
   Objects  are  separated by empty lines. An attribute that consists of
   multiple lines should  have  the  attribute name  repeated on
   consecutive lines.  The information stored about network 192.87.45.0
   consists  of  three  objects,  one inetnum object and two person
   objects and looks like this:









































Bates, et al.                                                  [Page 12]

RFC 1786        Representing IP Routing Policies in a RR      March 1995



   inetnum:   192.87.45.0
   netname:   RIPE-NCC
   descr:     RIPE Network Coordination Centre
   descr:     Amsterdam, Netherlands
   country:   NL
   admin-c:   Daniel Karrenberg
   tech-c:    Marten Terpstra
   rev-srv:   ns.ripe.net
   rev-srv:   ns.eu.net
   notify:    [e-mail]
   changed:   [e-mail] 940110
   source:    RIPE

   person:    Daniel Karrenberg
   address:   RIPE Network Coordination Centre (NCC)
   address:   Kruislaan 409
   address:   NL-1098 SJ Amsterdam
   address:   Netherlands
   phone:     [phone]
   fax-no:    [phone]
   e-mail:    [e-mail]
   nic-hdl:   DK58
   changed:   [e-mail] 920826
   source:    RIPE

   person:    Marten Terpstra
   address:   RIPE Network Coordination Centre (NCC)
   address:   PRIDE Project
   address:   Kruislaan 409
   address:   NL-1098 SJ Amsterdam
   address:   Netherlands
   phone:     [phone]
   fax-no:    [phone]
   e-mail:    [e-mail]
   nic-hdl:   MT2
   notify:    [e-mail]
   changed:   [e-mail] 931230
   source:    RIPE



   Objects are stored and retrieved in this tag/value format.  The RIPE
   NCC does not provide differently formatted reports because any
   desired format can easily be produced from this generic one.






Bates, et al.                                                  [Page 13]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   Routing Registry Objects

   The main objects comprising the routing registry are "aut-num" and
   "route", describing an autonomous system and a route respectively. It
   should be noted that routes not described in the routing registry
   should never be routed in the Internet itself.

   The autonomous system (aut-num) object provides contact information
   for the AS and describes the routing policy of that AS.  The routing
   policy is described by enumerating all neighboring ASes with which
   routing information is exchanged.  For each neighbor the routing
   policy is described in terms of exactly what is being sent
   (announced) and allowed in (accepted).  It is important to note that
   this is exactly the part of the global policy over which an AS has
   direct control. Thus each aut-num object describes what can indeed be
   implemented and enforced locally by the AS concerned.  Combined
   together all the aut-num objects provide the global routing graph and
   permit to deduce the exact routing policy between any two ASes.

   While the aut-num objects describe how routing information is
   propagated, the route object describes a single route injected into
   the external routing mesh. The route object references the AS
   injecting (originating) the route and thereby indirectly provides
   contact information for the originating AS. This reference also
   provides the primary way of grouping routes into larger collections.
   This is necessary because describing routing policy on the level of
   single routes would be awkward to impractical given the number of
   routes in the Internet which is about 20,000 at the time of this
   writing.  Thus routing policy is most often defined for groups of
   routes by originating AS.  This method of grouping is well supported
   by current exterior routing protocols.  The route object also
   references community objects described below to provide another
   method of grouping routes.  Modification of aut-num object itself and
   the referencing by route objects is strictly protected to provide
   network operators control over the routing policy description and the
   routes originated by their ASes.

   Sometimes even keeping track of groups of routes at the AS level is
   cumbersome. Consider the case of policies described at the transit
   provider level which apply transitively to all customers of the
   transit provider. Therefore another level of grouping is provided by
   the as-macro object which provides groups of ASes which can be
   referenced in routing policies just like single ASes. Membership of
   as-macro groups is also strictly controlled.

   Sometimes there is a need to group routes on different criteria than
   ASes for purposes like statistics or local access policies. This is
   provided by the community object.  A community object is much like an



Bates, et al.                                                  [Page 14]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   AS but without a routing policy.  It just describes a group of
   routes. This is not supported at all by exterior routing protocols
   and depending on aggregation of routes may not be generally usable to
   define routing policies.  It is suitable for local policies and non-
   routing related purposes.

   These routing related objects will be described in detail in the
   sections below.