rfc2772.txt

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

Network Working Group                                         R. Rockell
Request for Comments: 2772                                        Sprint
Obsoletes: 2546                                                  R. Fink
Category: Informational                                            ESnet
                                                           February 2000


                   6Bone Backbone Routing Guidelines


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   The 6Bone is an Ipv6 testbed to assist in the evolution and
   deployment of IPv6. Because of this, it is important that the core
   backbone of the IPv6 network maintain stability, and that all
   operators have a common set of rules and guidelines by which to
   deploy IPv6 routing equipment.

   This document provides a set of guidelines for all 6bone routing
   equipment operators to use as a reference for efficient and stable
   deployment of 6bone routing systems. As the complexity of the 6Bone
   grows,the adherence to a common set of rules becomes increasingly
   important in order for an efficient, scalable backbone to exist.


















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


Table of Contents

   1. Introduction..................................................  2
   2. Scope of this document........................................  3
   3. Common Rules for the 6bone....................................  3
       3.1 Link-local prefixes......................................  3
       3.2 Site-local prefixes......................................  4
       3.3 Loopback and unspecified prefixes........................  5
       3.4 Multicast prefixes.......................................  5
       3.5 IPv4 compatible prefixes.................................  5
       3.6 IPv4-mapped prefixes.....................................  6
       3.7 Default routes...........................................  6
       3.8 Yet undefined unicast prefixes...........................  6
       3.9 Inter-site links.........................................  6
       3.10 6to4 Prefixes...........................................  7
       3.11 Aggregation & advertisement issues......................  7
   4. Routing Policies for the 6bone................................  7
   5. The 6Bone Registry............................................  8
   6. Guidelines for new sites joining the 6Bone....................  9
   7. Guidelines for 6Bone pTLA sites...............................  9
   8. 6Bone Operations group........................................ 11
   9. Common rules enforcement for the 6bone........................ 11
   10. Security Considerations...................................... 12
   11. References................................................... 12
   12. Authors' Addresses........................................... 13
   13. Full Copyright Statement..................................... 14

1. Introduction

   The 6Bone is an IPv6 testbed to assist in the evolution and
   deployment of IPv6. Because of this, it is important that the core
   backbone of the IPv6 network maintain stability, and that all
   operators have a common set of rules and guidelines by which to
   deploy IPv6 routing equipment.

   This document provides a set of guidelines for all 6bone routing
   equipment operators to use as a reference for efficient and stable
   deployment of 6bone routing systems. As the complexity of the 6Bone
   grows,the adherence to a common set of rules becomes increasingly
   important in order for an efficient, scalable backbone to exist.

   This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as
   defined [RFC 2283], commonly referred to as BGP4+, as the currently
   accepted EGP.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].



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


2. Scope of this document

   This document is a best-practices Informational document aimed at
   IPv6 entities which operate under the 6Bone IPv6 testbed TLA
   allocation.

3. Common Rules for the 6bone

   This section details common rules governing the routing of the 6Bone.
   They are derived from the issues encountered on the 6Bone, with
   respect to the routes advertised, handling of special addresses, and
   aggregation:

      1) link local prefixes

      2) site local prefixes

      3) loopback and unspecified prefixes

      4) multicast prefixes

      5) IPv4-compatible prefixes

      6) IPv4-mapped prefixes

      7) default routes

      8) yet undefined unicast prefixes (from a different /3 prefix)

      9) inter-site links issues

      10) 6to4 prefixes

      11) aggregation & advertisement issues

3.1 Link-local prefixes

   This link-local prefix (FE80::/10) MUST NOT be advertised through
   either an IGP or an EGP.  Under no circumstance should this prefix be
   seen in the 6Bone backbone routing table.

   By definition, the link-local prefix has a scope limited to a
   specific link. Since the prefix is the same on all IPv6 links,
   advertising it in any routing protocol does not make sense and,
   worse, may introduce nasty error conditions.

   Well known cases where link-local prefixes could be advertised by
   mistake include, but are not limited to:



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


   -  a router advertising all directly connected network prefixes
      including the link-local one

   -  subnetting of the link-local prefix

   In such cases, vendors should be urged to correct their code. While
   vendors should be encouraged to fix the problem, the ultimate
   responsibility lies on the operator of that IPv6 site to correct the
   problem through whatever means necessary.

   Should a pTLA discover link-local prefixes coming from another pTLA,
   it is the responsibility of the pTLA leaking the routes to filter
   these, and correct the problem in a timely fashion. Should a pTLA
   discover that a downstream of that pTLA is leaking link-local
   prefixes, it is the pTLA's responsibility to ensure that these
   prefixes are not leaked to other pTLA's, or to other downstreams of
   that pTLA.

   Failure to filter such routes in a timely fashion may result in the
   manual shutting down of BGP4+ sessions to that pTLA, from other
   pTLA's.

   (Also, it is each pTLA, pNLA, and end-site's responsibility to not
   only filter their own BGP4+ sessions appropriately to peers, but to
   filter routes coming from peers as well, and to only allow those
   routes that fit the aggregation model, and do not cause operational
   problems).

3.2 Site-local prefixes

   Site local prefixes (in the FEC0::/10 range) MAY be advertised by
   IGP's or EGP's within a site. The precise definition of a site is
   ongoing work of the IPng working group, but should generally include
   a group of nodes that are operating under one administrator or group
   of administrators, or a group of nodes which are used for a common
   purpose.

   Site-local prefixes MUST NOT be advertised across transit pNLAs,
   pTLAs, or leaf-sites.

   Again, should site-local prefixes be leaked outside of a given site,
   it is the responsibility of the site to fix the problem in a timely
   manner, either through filters, or via other means which remove the
   operational impact that those prefixes had on the peering sites
   involved. However, every site SHOULD filter not only outbound on
   their EGP, but also inbound, in order to ensure proper routing
   announcements are not only sent, but also received.




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


3.3 Loopback and unspecified prefixes

   The loopback prefix (::1/128) and the unspecified prefix (::0/128)
   MUST NOT be advertised by any routing protocol.

   The same responsibility lies with the party guilty of advertising the
   loopback or unspecified prefix as in Section 3.1 and 3.2.

3.4 Multicast prefixes

   Multicast prefixes MUST NOT be advertised by any unicast routing
   protocol. Multicast routing protocols are designed to respect the
   semantics of multicast and MUST therefore be used to route packets
   with multicast destination addresses (in the range of FF00::/8).

   Multicast address scopes MUST be respected on the 6Bone.  Only global
   scope multicast addresses MAY be routed across transit pNLAs and
   pTLAs.  There is no requirement on a pTLA to route multicast packets
   at the time of the writing of this memo.

   Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges)
   MAY be routed across a pNLA to its leaf sites.

   Site-local multicasts MUST NOT be routed toward transit pNLAs or
   pTLAs.

   Link-local multicasts and node-local multicasts MUST NOT be routed at
   all.

3.5 IPv4 compatible prefixes

   Sites may choose to use IPv4 compatible addresses (::a.b.c.d where
   a.b.c.d represents the octets of an IPv4 address) internally. As
   there is no real rationale today for doing so, these address SHOULD
   NOT be used or routed in the 6Bone.

   The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.

   IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit
   pNLAs or pTLAs.

   Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is
   the responsibility of the party who is advertising the route to fix
   the problem, either through proper filters, or through other means,
   while it remains in the best interest of all particiapants of the
   6Bone to filter both outbound and inbound at their IGP borders.





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


3.6 IPv4-mapped prefixes

   IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d represents the
   octets of an IPv4 address) MAY be advertised by IGPs within a site.
   It may be useful for some IPv6 only nodes within a site to have such
   a route pointing to a translation device, to aid in deployment of
   IPv6.

   IPv4-mapped prefixes MUST NOT be advertised by EGPs.

3.7 Default routes

   6Bone core pTLA routers MUST be default-free.

   pTLAs MAY advertise a default route to any downstream peer (non-pTLA
   site). Transit pNLAs MAY advertise a default route to any of their
   downstreams (other transit pNLA or leaf site).

   Should a default route be redistributed into an EGP and found on any
   pTLA EGP sessions, it is the responsibility of the pTLA to fix this
   problem immediately upon realization of the route's existence, and
   the responsibility of the guilty pTLA to push the entity from which
   the default route was originated, should the default route have
   originated from downstream of a pTLA.

3.8 Yet undefined unicast prefixes

   Yet undefined unicast prefixes from a format prefix other than
   2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone.
   In particular, RFC 2471 test addresses MUST NOT be advertised on the
   6Bone.

   Routing of global unicast prefixes outside the 6Bone range
   (3ffe::/16), and routing of global unicast prefixes yet undelegated
   in the range (3ffe::/16) are discussed in section 4, Routing
   policies, below.

3.9 Inter-site links

   Global IPv6 addresses must be used for the end points of inter-site
   links. In particular, IPv4 compatible addresses MUST NOT be used for
   tunnels.

   Sites MAY use Other addressing schemes for Inter-site links, but
   these addresses MUST NOT be advertised into the IPv6 global routing
   table.





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


   Prefixes for inter-site links MUST NOT be injected in the global
   routing tables.

3.10 6to4 Prefixes

   The 6to4 prefix, or some portion thereof, MAY be announced by any
   pTLA which has a current implementation of 6to4 in their IPv6
   network.  However, as 6to4 implementors gain more operational
   experience, it MAY be necessary to change this in some way.  At the
   time of the writing of this docuement, any pTLA MAY announce the 6to4
   prefix into global EBGP. However, in order to announce this block,
   the pTLA MUST have a 6to4 router active, sourcing this prefix
   announcement.

   This section subject to change, and MAY vary, depending on 6to4
   progress within the NGTRANS working group.

3.11 Aggregation & advertisement issues

   Route aggregation MUST be performed by any border router talking EGP
   with any other IPv6 sites. More-specifics MUST NOT be leaked into or
   across the IPv6 6Bone backbone.

4. Routing Policies for the 6bone

   Leaf sites or pNLAs MUST only advertise to an upstream provider the
   prefixes assigned by that provider. Advertising a prefix assigned by
   another provider to a provider is not acceptable, and breaks the
   aggregation model. A site MUST NOT advertise a prefix from another
   provider to a provider as a way around the multi-homing problem.
   However, in the interest of testing new solutions, one may break this
   policy, so long as ALL affected parties  are aware of this test, and
   all agree to support this testing.  These policy breaks MUST NOT
   affect the 6bone routing table globally.

   To clarify, if one has two upstream pNLA or pTLA providers, (A and B
   for this example), one MUST only announce the prefix delegated to one
   by provider A to provider A, and one MUST only announce the prefeix
   delegated by one from provider B upstream to provider B. There exists
   no circumstance where this should be violated, as it breaks the
   aggregation model, and could globally affect routing decisions if
   downstreams are able to leak other providers' more specific
   delegations up to a pTLA. As the IPNG working group works through the
   multi-homing problem, there may be a need to alter this rule
   slightly, to test new strategies for deployment. However, in the case
   of current specifications at the time of this writing, there is no
   reason to advertise more specifics, and pTLA's MUST adhere to the
   current aggregation model.



Rockell & Fink               Informational                      [Page 7]