INTERNET DRAFT                                                  R. Rockell
NGTRANS WG                                                          Sprint
Category: Informational                                           B.  Fink
Expires December 1999                                                ESNet

                  6Bone Backbone Routing Guildelines

                <draft-ietf-ngtrans-harden-01.txt>

Status of this Memo

This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its Areas, and it Working
Groups.  Note that other groups may also distribute working documents as
Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six months,
and may be updated, replaced, or obsoleted by other documents at
any time.  It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".

The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html


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

1. 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 guildelines by which to deploy IPv6 routing
equipment. This document provides a set of guildelines for all IPv6
routing equipment operators to use as a reference for efficient and stable
deployment of IPv6 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 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].

2. Scope of this document.

This document is a best-practices document aimed at all entities which
connect to, or interact with, the 6Bone.

3. Common Rules

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 prefix and 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

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:

- 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 Leaf-node'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 1:fit the aggregation model, and 2: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
discussed in 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 unwantedly 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.

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

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

3.6. IPv4-mapped prefixes

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

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

3.10 6to4 Prefix (2010::/16)

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.

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

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.

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

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 pTLAs MUST NOT advertise prefixes longer than a given pTLA
delegation (currently /24 or /28) to other pTLAs unless special peering
arrangements are implemented. When such special peering aggreements are in
place between any two or more pTLAs, care MUST be taken not to leak the more
specifics to other pTLAs not participating in the peering aggreement. pTLAs
which have such agreements in place MUST NOT advertise other pTLA more
specifics to downstream 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 other TLAs than the 6Bone
one (currently 3FFE::/16). The organizations bearing those TLAs will
establish a new IPv6 network, parallel to the already establised 6Bone.
Peering beetween these new TLA's and the current 6Bone pTLA's MAY occur, and
details such as transit and what routes are received by each, outside of
general peering rules as stated in this draft, are left up to the members
of those TLA's and pTLA's that are establishing said peerings.

5. The 6Bone Registry

The 6Bone registry is a RIPE-181 database with IPv6 extensions used to store
information about that 6Bone, and its sites. Each 6Bone site MUST maintain
the relevant entries in the 6Bone registry (currently whois.6bone.net). In
particular, the following object MUST be present for all 6Bone leaf sites,
pNLAs and pTLAs:

-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 database (RIPE, InterNIC, APNIC)

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 candidate pNLAs or pTLAs.

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 object relative to its site, and in particular the IPv6-site and the
Mntnr objects.

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 a 6Bone registry
objects reflecting the delegated address space (Inet6num).

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 this entire qualifying period the Applicant must be
     operationally providing the following:

     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 connec-
        tivity between the Applicant's boundary router with the
        appropriate hierarchy.  This includes a high uptime
        availability of the site router (greater than 99%). This
        router must be IPv6 pingable.

     c. Fully maintained DNS forward (AAAA) and reverse (ip6.int)
        entries for their site's router, and at least one host ser-
        ver system.

     d. A fully maintained, and reliable host server system providing,
        at a mimimum, one or more web pages describing the applicant's
        project and service on the 6Bone, available via IPv6.  This
        server must be IPv6 pingable.

   2. The pTLA Applicant MUST have the ability and intent to provide
      "production-like" 6Bone backbone service to provide a robust
      and operationally reliable 6Bone backbone. Applicants must pro-
      vide a statement and some supportable information to support
      this claim.  This MUST include the following:

     a. a support staff of two persons minimum, 3 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 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 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 some
      supportable information to 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 appli-
      cation, 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 a candidate site seeks to become a pTLA site, it will apply for pTLA
status to the 6Bone Operations group (see below) by bringing evidences it
meets the criteria above to said group.

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. Members of the 6Bone operations group also SHOULD
   be affiliated with an operational Ipv6 site attached to the 6Bone in
   some fashion.

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.

10.  Security Considerations

     The result of falacious 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 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 member's
     responsibility to safely introduce new test systems into
     the 6Bone, by placing them at a strategically safe place which
     will have minimal impact on other ipv6 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 (deceased), "IPv6
              Testing Address Allocation", RFC 2471, December 1998.

   [RFC 2546] Durand, A., Buclin, B, "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.

Any comments can be sent to rrockell@sprint.net
This document expires December, 1999.