draft-ietf-ngtrans-6bone-routing-00.txt
Bob Fink
rlfink@lbl.gov
Tue, 05 May 1998 06:36:37 -0700
> From: Buclin, Bertrand
> Sent: Friday, May 01, 1998 10:15 AM
> To: '6bone@isi.edu'
> Subject: draft-ietf-ngtrans-6bone-routing-practice-00.txt
>
> Dear all,
>
> you'll find below the new draft for the 6Bone Routing Practices. It
> replaces the draft-ietf-ngtrans-6bone-routing-issues-02.txt that was
> presented at the Los Angeles IETF meeting, and includes the comments
> made there and through private mail messages.
>
> Unfortunately, my co-author Alain has had an accident recently (not
> life threatening) which will keep him out of business for a couple of
> months. Please provide your comments either directly to me or more
> generally to the 6Bone mailing list (6Bone@isi.edu).
>
> Regards,
>
> Bertrand Buclin
> AT&T Labs Europe
INTERNET DRAFT Alain Durand
NGTRANS WG IMAG
30 April, 1998 Bertrand Buclin
Expires 30 October, 1998 AT&T Labs Europe
6Bone Routing Practice
<draft-ietf-ngtrans-6bone-routing-00.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
This draft expires October 30, 1998.
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 (like RIPng)
and Exterior Gateway Protocols (like BGP4+).
2 Basic principles
The 6bone is structured as a hierarchical network with pseudo TLA
(pTLA), pseudo NLA (pNLA) and leaf sites. 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.
BGP4+ is the mandatory routing protocol used for exchanging routing
information among pTLAs.
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:
- 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.
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, RFC1897 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.
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 5 other backbone 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, but 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 an RPSL database 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.
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. 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 bring evidences it
meets the above criteria.
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 takes the form of a mailing list
(operations@6bone.net) and is derived from the data in the 6Bone
registry.
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 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 Author address
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
E-Mail: 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
E-Mail: Bertrand.Buclin@ch.att.com