rfc2772.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/2 页


RFC 2772           6Bone Backbone Routing Guidelines       February 2000


   Site border routers for pNLA or leaf sites MUST NOT advertise
   prefixes more specific (longer) than the prefix that was allocated by
   their upstream provider.

   All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA
   delegation (currently /24 or /28) to other 6bone pTLAs unless special
   peering arrangements are implemented. When such special peering
   aggreements are in place between any two or more 6bone pTLAs, care
   MUST be taken not to leak the more specifics to other 6bone pTLAs not
   participating in the peering aggreement. 6bone pTLAs which have such
   agreements in place MUST NOT  advertise other 6bone pTLA more
   specifics to downstream 6bone pNLAs or leaf sites, as this will break
   the best-path routing decision.

   The peering agreements across the 6Bone may be by nature non-
   commercial, and therefore MAY allow transit traffic, if peering
   agreements of this nature are made. However, no pTLA is REQUIRED to
   give or receive transit service from another pTLA.

   Eventually, the Internet registries will assign prefixes under other
   than the 6Bone TLA (3FFE::/16). As of the time this document was
   written in 1999, the Internet registries were starting to assign /35
   sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly
   be used in the future.

   The organizations receiving prefixes under these newer TLAs would be
   expected to want to establish peering and connectivity relationships
   with other IPv6 networks, both in the newer TLA space and in the
   6bone pTLA space. Peering between new TLA's and the current 6Bone
   pTLA's MAY occur, and details such as transit, and what routes are
   received by each, are outside of general peering rules as stated in
   this memo, and are left up to the members of those TLA's and pTLA's
   that are establishing said peerings. However, it is expected that
   most of the rules discussed here are equally applicable to new TLAs.

5. The 6Bone Registry

   The 6Bone registry is a RIPE-181 database with IPv6 extensions used
   to store information about the 6Bone, and its sites. The 6bone is
   accessible at:

         <http://www.6bone.net/whois.html>)

   Each 6Bone site MUST maintain the relevant entries in the 6Bone
   registry. In particular, the following object MUST be present for all
   6Bone leaf sites, pNLAs and pTLAs:





Rockell & Fink               Informational                      [Page 8]

RFC 2772           6Bone Backbone Routing Guidelines       February 2000


   -  IPv6-site: site description

   -  Inet6num: prefix delegation (one record MUST exist for each
      delegation)

   -  Mntner: contact info for site maintance/administration staff.

   Other object MAY be maintained at the discretion of the sites such as
   routing policy descriptors, person, or role objects.  The Mntner
   object MUST make reference to a role or person object, but those MAY
   NOT necessarily reside in the 6Bone registry. They can be stored
   within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC,
   etc.)

6. Guidelines for new sites joining the 6Bone

   New sites joining the 6Bone should seek to connect to a transit pNLA
   or a pTLA within their region, and preferably as close as possible to
   their existing IPv4 physical and routing path for Internet service.
   The 6Bone web site at <http://www.6bone.net> has various information
   and tools to help find candidate 6bone networks.

   Any site connected to the 6Bone MUST maintain a DNS server for
   forward name lookups and reverse address lookups.  The joining site
   MUST maintain the 6Bone objects relative to its site, as describe in
   section 5.

   The upstream provider MUST delegate the reverse address translation
   zone in DNS to the joining site, or have an agreement in place to
   perform primary DNS for that downstream. The provider MUST also
   create the 6Bone registry inet6num object reflecting the delegated
   address space.

   Up to date informatino about how to join the 6Bone is available on
   the 6Bone Web site at <http://www.6bone.net>.

7. Guidelines for 6Bone pTLA sites

   The following rules apply to qualify for a 6Bone pTLA allocation. It
   should be recognized that holders of 6Bone pTLA allocations are
   expected to provide production quality backbone network services for
   the 6Bone.

   1. The pTLA Applicant must have a minimum of three (3) months
      qualifying experience as a 6Bone end-site or pNLA transit.  During
      the entire qualifying period the Applicant must be operationally
      providing the following:




Rockell & Fink               Informational                      [Page 9]

RFC 2772           6Bone Backbone Routing Guidelines       February 2000


      a. Fully maintained, up to date, 6Bone Registry entries for their
         ipv6-site inet6num, mntner, and person objects, including each
         tunnel that the Applicant has.

      b. Fully maintained, and reliable, BGP4+ peering and connectivity
         between the Applicant's boundary router and the appropriate
         connection point into the 6Bone. This router must be IPv6
         pingable. This criteria is judged by members of the 6Bone
         Operations Group at the time of the Applicant's pTLA request.

      c. Fully maintained DNS forward (AAAA) and reverse (ip6.int)
         entries for the Applicant's router(s) and at least one host
         system.

      d. A fully maintained, and reliable, IPv6-accessible system
         providing, at a mimimum, one or more web pages, describing the
         Applicant's IPv6 services.  This server must be IPv6 pingable.

   2. The pTLA Applicant MUST have the ability and intent to provide
      "production-quality" 6Bone backbone service. Applicants must
      provide a statement and information in support of this claim.
      This MUST include the following:

      a. A support staff of two persons minimum, three preferable, with
         person attributes registered for each in the ipv6-site object
         for the pTLA applicant.

      b. A common mailbox for support contact purposes that all support
         staff have acess to, pointed to with a notify attribute in the
         ipv6-site object for the pTLA Applicant.

   3. The pTLA Applicant MUST have a potential "user community" that
      would be served by its becoming a pTLA, e.g., the Applicant is a
      major provider of Internet service in a region, country, or focus
      of interest. Applicant must provide a statement and information in
      support this claim.

   4. The pTLA Applicant MUST commit to abide by the current 6Bone
      operational rules and policies as they exist at time of its
      application, and agree to abide by future 6Bone backbone
      operational rules and policies as they evolve by consensus of the
      6Bone backbone and user community.

   When an Applicant seeks to receive a pTLA allocation, it will apply
   to the 6Bone Operations Group (see section 8 below) by providing to
   the Group information in support of its claims that it meets the
   criteria above.




Rockell & Fink               Informational                     [Page 10]

RFC 2772           6Bone Backbone Routing Guidelines       February 2000


8. 6Bone Operations Group

   The 6Bone Operations Group is the group in charge of monitoring and
   policing adherence to the current rules. Membership in the 6Bone
   Operations Group is mandatory for, and restricted to, sites connected
   to the 6Bone.

   The 6Bone Operations Group is currently defined by those members of
   the existing 6Bone mailing list who represent sites participating in
   the 6Bone. Therefore it is incumbent on relevant site contacts to
   join the 6Bone mailing list. Instructions on how to join the list are
   maintained on the 6Bone web site at < http://www.6bone.net>.

9.  Common rules enforcement for the 6bone

   Participation in the 6Bone is a voluntary and benevolent undertaking.
   However, participating sites are expected to adhere to the rules and
   policies described in this document in order to maintain the 6Bone as
   a quality tool for the deployment of, and transition to, IPv6
   protocols and the products implementing them.

   The following is in support of policing adherence to 6Bone rules and
   policies:

   1. Each pTLA site has committed to implement the 6Bone's rules and
      policies, and SHOULD try to ensure they are adhered to by sites
      within their administrative control, i.e. those to who prefixes
      under their respective pTLA prefix have been delegated.

   2. When a site detects an issue, it SHOULD first use the 6Bone
      registry to contact the site maintainer and work the issue.

   3. If nothing happens, or there is disagreement on what the right
      solution is, the issue SHOULD be brought to the 6Bone Operations
      Group.

   4. When the problem is related to a product issue, the site(s)
      involved SHOULD be responsible for contacting  the product vendor
      and work toward its resolution.

   5. When an issue causes major operational problems, backbone sites
      SHOULD decide to temporarily set filters in order to restore
      service.








Rockell & Fink               Informational                     [Page 11]

RFC 2772           6Bone Backbone Routing Guidelines       February 2000


10.  Security Considerations

   The result of incorrect entries in routing tables is usually
   unreachable sites.  Having guidelines to aggregate or reject routes
   will clean up the routing tables. It is expected that using these
   rules and policies, routing on the 6Bone will be less sensitive to
   denial of service attacks due to misleading routes.

   The 6Bone is an IPv6 testbed to assist in the evolution and
   deployment of IPv6. Therefore, denial of service or packet disclosure
   are to be expected.  However, it is the pTLA from where the attack
   originated who has ultimate responsibility for isolating and fixing
   problems of this nature. It is also every 6Bone site's responsibility
   to safely introduce new test systems into the 6Bone, by placing them
   at a strategically safe places which will have minimal impact on
   other 6Bone sites, should bugs or misconfigurations occur.

11. References

   [RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC 2471] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address
              Allocation", RFC 2471, December 1998.

   [RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC
              2546, March 1999

   [RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
              January 1997.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement  Levels", BCP 14, RFC 2119, March 1997.

   [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 2283, March
              1998.

   [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J.,
              Karrenberg, D., Terpstra, M. and J.  Yu,  Representation
              of IP Routing Policies in a Routing Registry.  Technical
              Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands,
              October 1994.








Rockell & Fink               Informational                     [Page 12]

RFC 2772           6Bone Backbone Routing Guidelines       February 2000


12. Authors' Addresses

   Rob Rockell
   EMail: [e-mail]


   Bob Fink
   EMail: [e-mail]











































Rockell & Fink               Informational                     [Page 13]

RFC 2772           6Bone Backbone Routing Guidelines       February 2000


13. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rockell & Fink               Informational                     [Page 14]