rfc2546.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 564 行 · 第 1/2 页

Network Working Group                                          A. Durand
Request for Comments: 2546                                          IMAG
Category: Informational                                        B. Buclin
                                                        AT&T Labs Europe
                                                              March 1999


                         6Bone Routing Practice

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 (1999).  All Rights Reserved.

1.  Introduction

   The 6Bone is an environment supporting experimentation with the IPv6
   protocols and products implementing it. As the network grows, the
   need for common operation rules emerged. In particular, operation of
   the 6Bone backbone is a challenge due to the frequent insertion of
   bogus routes by leaf or even backbone sites.

   This memo identifies guidelines on how 6Bone sites might operate, so
   that the 6Bone can remain a quality experimentation environment and
   to avoid pathological situations that have been encountered in the
   past. It defines the 'best current practice' acceptable in the 6Bone
   for the configuration of both Interior Gateway Protocols (such as
   RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC
   2283]).

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

2.  Basic principles

   The 6Bone is structured as a hierarchical network with pseudo Top
   Level Aggregator (pTLA) sites, pseudo Next Level Aggregator (pNLA)
   sites and leaf sites. This topology supports the IPv6 address
   aggregation architecture as described in [1]. The 6Bone backbone is
   made of a mesh interconnecting pTLAs only. pNLAs connect to one or
   more pTLAs and provide transit service for leaf sites.




Durand & Buclin              Informational                      [Page 1]

RFC 2546                 6Bone Routing Practice               March 1999


   pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing
   protocol for exchanging routing information among them.

   Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY
   use a simple default route to their ISP.

3.  Common Rules

   This section details common rules governing the routing on the 6Bone.
   They are derived from 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 prefix & unspecified prefix

    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) aggregation & advertisement issues

3.1  Link-local prefix

   The link-local prefix (FE80::/10) MUST NOT be advertised through
   either an IGP or an EGP.

   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:






Durand & Buclin              Informational                      [Page 2]

RFC 2546                 6Bone Routing Practice               March 1999


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

3.2  Site-local prefixes

   Site local prefixes (in the FEC0::/10 range) MAY be advertized by
   IGPs or EGPs within a site. The precise definition of a site is
   ongoing work discussed in the IPng working group.

   Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs.

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.

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

   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.

   Obviously, 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)
   internally.  As there is no real rationale today for doing that,
   these addresses SHOULD

   NOT be used in the 6Bone.




Durand & Buclin              Informational                      [Page 3]

RFC 2546                 6Bone Routing Practice               March 1999


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

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

3.6  IPv4-mapped prefixes

   IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is 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.

   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 their pNLAs. Transit pNLAs MAY
   do the same for their leaf sites.

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 of the 6Bone range
   (3FFE::/16) is discussed in section 4, Routing policies, below.

3.9  Inter-site links

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

   Prefixes for those links MUST NOT be injected in the global routing
   tables.

3.10  Aggregation & advertisement issues

   Route aggregation MUST be performed by any border router.

   Sites or pNLAs MUST only advertise to their upstream provider the
   prefixes assigned by that ISP unless otherwise agreed.





Durand & Buclin              Informational                      [Page 4]

RFC 2546                 6Bone Routing Practice               March 1999


   Site border router MUST NOT advertise prefixes more specific than the
   /48 ones allocated by their ISP.

   pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless
   special peering agreements are implemented. When such special peering
   agreements are in place between any two or more pTLAs, care MUST be
   taken not to leak the more specific prefixes to other pTLAs not
   participating in the peering agreement.

4.  Routing policies

   6Bone backbone sites maintain the mesh into the backbone and provide
   an as reliable as possible service, granted the 6Bone is an
   experimentation tool.  To achieve their mission, 6Bone backbone sites
   MUST maintain peerings with at least 3 (three) other back bone sites.

   The peering agreements across the 6Bone are by nature non-commercial,
   and therefore SHOULD allow transit traffic through.

   Eventually, the Internet registries will assign other TLAs than the
   6Bone one (currently 3FFE::/16). The organizations bearing those TLAs
   will establish a new IPv6 network, parallel to the 6Bone. The 6Bone
   MIGHT interconnect with this new IPv6 Internet, b ut transit across
   the 6Bone will not be guaranteed. It will be left to each 6Bone
   backbone site to decide whether it will carry traffic to or from the
   IPv6 Internet.

5.  The 6Bone registry

   The 6Bone registry is a RIPE-181 database with IPv6 extensions used
   to store information about the 6Bone. Each 6Bone site MUST maintain
   the relevant entries in the 6Bone registry (whois.6bone.net). In
   particular, the following objects MUST be present:

   - IPv6-site: site description

   - Inet6num: prefix delegation

   - Mntner: coordinate of site maintenance staff

   Other objects 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 must
   not necessarily reside in the 6Bone registry, they can be stored
   within any of the Internet registry databases (RIPE, InterNIC, APNIC,






Durand & Buclin              Informational                      [Page 5]