doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2546.txt b/doc/rfc/rfc2546.txt
new file mode 100644
index 0000000..eee6021
--- /dev/null
+++ b/doc/rfc/rfc2546.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+
+RFC 2546                 6Bone Routing Practice               March 1999
+
+
+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 registry is available to find out candidate ISPs.
+
+   Any site connected to the 6Bone MUST maintain a DNS server for
+   forward name looking and reverse address translation. The joining
+   site MUST maintain the 6Bone registry objects relative to its site,
+   and in particular the IPv6- site and the MNTNER objects.
+
+   The upstream ISP MUST delegate the reverse address translation zone
+   in DNS to the joining site. The ISP MUST also create 6Bone registry
+   objects reflecting the delegated address space (inet6num:).
+
+   Up to date information about how to join the 6Bone is available on
+   the 6Bone Web site at http://www.6bone.net.
+
+7.  Guidelines for 6Bone pTLA sites
+
+   6Bone pTLA sites are altogether forming the backbone of the 6Bone. In
+   order to ensure the highest level possible of availability and
+   stability for the 6Bone environment, a few constraints are placed
+   onto sites wishing to become or stay a 6Bone pTLA:
+
+   1. The site MUST have experience with IPv6 on the 6Bone, at least as
+      a leaf site and preferably as a transit pNLA under an existing
+      pTLA.
+
+   2. The site MUST have the ability and intent to provide "production-
+      like" 6Bone backbone service to provide a robust and operationally
+      reliable 6Bone backbone.
+
+   3. The site MUST have a potential "user community" that would be
+      served by becoming a pTLA, e.g., the requester is a major player
+      in a region, country or focus of interest.
+
+   4. Must commit to abide by the 6Bone backbone operational rules and
+      policies as defined in the present document.
+
+   When a candidate site seeks to become a pTLA site, it will apply for
+   it to the 6Bone Operations group (see below) by bringing evidences it
+   meets the above criteria.
+
+
+
+
+
+
+
+Durand & Buclin              Informational                      [Page 6]
+
+RFC 2546                 6Bone Routing Practice               March 1999
+
+
+8.  6Bone Operations group
+
+   The 6Bone Operations group is the body in charge of monitoring the
+   adherence to the present rules, and will take the appropriate actions
+   to correct deviations. Membership in the 6Bone Operations group is
+   mandatory for, and restricted to, any site connected to the 6Bone.
+
+   The 6Bone Operations group is currently defined by those members of
+   the existing 6Bone mailing list, i.e., 6bone@isi.edu, who represent
+   sites participating on the 6Bone. Therefore it is incumbent on
+   relevant site contacts to join the 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
+
+   Participation in the 6Bone is a voluntary and benevolent undertaking.
+   However, participating sites are expected to adhere to the rules
+   described in this document, in order to maintain the 6Bone as quality
+   tool for experimenting with the IPv6 protocols and products
+   implementing them.
+
+   The following processes are proposed to help enforcing the 6Bone
+   rules:
+
+   - Each pTLA site has committed when requesting their pTLA to
+     implement the rules, and to ensure they are respected by sites
+     within their administrative control (i.e. those to who prefixes
+     have been delegated).
+
+   - When a site detects an issue, it will first use the 6Bone registry
+     to contact the site maintainer and work the issue.
+
+   - If nothing happens, or there is disagreement on what the right
+     solution is, the issue can be brought to the 6Bone Operations
+     group.
+
+   - When the problem is related to a product issue, the site(s)
+     involved is responsible for contact the product vendor and work
+     toward its resolution.
+
+   - When an issue causes major operational problems, backbone sites may
+     decide to temporarily set filters in order to restore service.
+
+
+
+
+
+
+
+
+Durand & Buclin              Informational                      [Page 7]
+
+RFC 2546                 6Bone Routing Practice               March 1999
+
+
+10.  Security Considerations
+
+     The result of bogus 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
+     guidelines, routing on the 6Bone will be less sensitive to denial
+     of service attacks due to misleading routes.
+
+     The 6Bone is a test network. Therefore, denial of service, packet
+     disclosure, are to be expected.
+
+11.  Acknowledgements
+
+     This document is the result of shared experience on the 6Bone.
+     Special thanks go to Bob Fink for the hard work make to date to
+     direct the 6Bone effort, to David Kessens for the 6Bone registry,
+     and to Guy Davies for his insightful contributions.
+
+12.  References
+
+   [1]        Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 2373, July 1998.
+
+   [RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6
+              Testing Address Allocation", RFC 2471, December 1998.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+Durand & Buclin              Informational                      [Page 8]
+
+RFC 2546                 6Bone Routing Practice               March 1999
+
+
+13.  Authors' Addresses
+
+   Alain Durand
+   Institut d'Informatique et de Mathematiques Appliquees de Grenoble
+   IMAG BP 53
+   38041 Grenoble CEDEX 9 France
+
+   Phone : +33 4 76 63 57 03
+   Fax   : +33 4 76 51 49 64
+   EMail: Alain.Durand@imag.fr
+
+
+   Bertrand Buclin
+   AT&T International S.A.
+   Route de l'aeroport 31, CP 72
+   CH-1215 Geneve 15 (Switzerland)
+
+   Phone : +41 22 929 37 40
+   Fax   : +41 22 929 39 84
+   EMail: Bertrand.Buclin@ch.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand & Buclin              Informational                      [Page 9]
+
+RFC 2546                 6Bone Routing Practice               March 1999
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand & Buclin              Informational                     [Page 10]
+