draft-ietf-ngtrans-harden-03.txt   rfc2772.txt 
INTERNET-DRAFT R. Rockell (Sprint)
Obsoletes: 2546 R. Fink (ESnet)
Category: Informational 6 December 1999
6Bone Backbone Routing Guidelines
<draft-ietf-ngtrans-harden-03.txt>
Status of this Memo Network Working Group R. Rockell
Request for Comments: 2772 Sprint
This document is an Internet-Draft and is in full conformance with Obsoletes: 2546 R. Fink
all provisions of Section 10 of RFC2026. Category: Informational ESnet
February 2000
Internet-Drafts are working documents of the Internet Engineering 6Bone Backbone Routing Guidelines
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 Status of this Memo
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 "work in progress."
The list of current Internet-Drafts can be accessed at This memo provides information for the Internet community. It does
<http://www.ietf.org/ietf/1id-abstracts.txt> not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
<http://www.ietf.org/shadow.html>
This draft expires on 6 June 2000. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment The 6Bone is an Ipv6 testbed to assist in the evolution and
of IPv6. Because of this, it is important that the core backbone of the deployment of IPv6. Because of this, it is important that the core
IPv6 network maintain stability, and that all operators have a common backbone of the IPv6 network maintain stability, and that all
set of rules and guidelines by which to deploy IPv6 routing equipment. 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 IPv6 routing This document provides a set of guidelines for all 6bone routing
equipment operators to use as a reference for efficient and stable equipment operators to use as a reference for efficient and stable
deployment of IPv6 routing systems. As the complexity of the 6Bone deployment of 6bone routing systems. As the complexity of the 6Bone
grows,the adherence to a common set of rules becomes increasingly grows,the adherence to a common set of rules becomes increasingly
important in order for an efficient, scalable backbone to exist. important in order for an efficient, scalable backbone to exist.
Table of Contents Table of Contents
1. Introduction....................................................... 1. Introduction.................................................. 2
2. Scope of this document............................................. 2. Scope of this document........................................ 3
3. Common Rules....................................................... 3. Common Rules for the 6bone.................................... 3
3.1 Link-local prefixes 3.1 Link-local prefixes...................................... 3
3.2 Site-local prefixes 3.2 Site-local prefixes...................................... 4
3.3 Loopback and unspecified prefixes 3.3 Loopback and unspecified prefixes........................ 5
3.4 Multicast prefixes 3.4 Multicast prefixes....................................... 5
3.5 IPv4 compatible prefixes 3.5 IPv4 compatible prefixes................................. 5
3.6 IPv4-mapped prefixes 3.6 IPv4-mapped prefixes..................................... 6
3.7 Default routes 3.7 Default routes........................................... 6
3.8 Yet undefined unicast prefixes 3.8 Yet undefined unicast prefixes........................... 6
3.9 Inter-site links 3.9 Inter-site links......................................... 6
3.10 6to4 Prefixes 3.10 6to4 Prefixes........................................... 7
3.11 Aggregation & advertisement issues 3.11 Aggregation & advertisement issues...................... 7
4. Routing Policies................................................... 4. Routing Policies for the 6bone................................ 7
5. The 6Bone Registry................................................. 5. The 6Bone Registry............................................ 8
6. Guidelines for new sites joining the 6Bone......................... 6. Guidelines for new sites joining the 6Bone.................... 9
7. Guidelines for 6Bone pTLA sites.................................... 7. Guidelines for 6Bone pTLA sites............................... 9
8. 6Bone Operations group............................................. 8. 6Bone Operations group........................................ 11
9. Common rules enforcement........................................... 9. Common rules enforcement for the 6bone........................ 11
10. Security Considerations........................................... 10. Security Considerations...................................... 12
11. References........................................................ 11. References................................................... 12
12. Authors' Addresses................................................ 12. Authors' Addresses........................................... 13
13. Full Copyright Statement..................................... 14
1. Introduction 1. Introduction
The 6Bone is an IPv6 testbed to assist in the evolution and deployment The 6Bone is an IPv6 testbed to assist in the evolution and
of IPv6. Because of this, it is important that the core backbone of the deployment of IPv6. Because of this, it is important that the core
IPv6 network maintain stability, and that all operators have a common backbone of the IPv6 network maintain stability, and that all
set of rules and guidelines by which to deploy IPv6 routing equipment. 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 IPv6 routing This document provides a set of guidelines for all 6bone routing
equipment operators to use as a reference for efficient and stable equipment operators to use as a reference for efficient and stable
deployment of IPv6 routing systems. As the complexity of the 6Bone deployment of 6bone routing systems. As the complexity of the 6Bone
grows,the adherence to a common set of rules becomes increasingly grows,the adherence to a common set of rules becomes increasingly
important in order for an efficient, scalable backbone to exist. important in order for an efficient, scalable backbone to exist.
This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as
defined [RFC 2283], commonly referred to as BGP4+, as the currently defined [RFC 2283], commonly referred to as BGP4+, as the currently
accepted EGP. accepted EGP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
2. Scope of this document 2. Scope of this document
This document is a best-practices Informational document aimed at all This document is a best-practices Informational document aimed at
entities which connect to, or interact with, the 6Bone. IPv6 entities which operate under the 6Bone IPv6 testbed TLA
allocation.
3. Common Rules 3. Common Rules for the 6bone
This section details common rules governing the routing of 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 They are derived from the issues encountered on the 6Bone, with
to the routes advertised, handling of special addresses, and respect to the routes advertised, handling of special addresses, and
aggregation: aggregation:
1) link local prefixes 1) link local prefixes
2) site local prefixes 2) site local prefixes
3) loopback and unspecified prefixes 3) loopback and unspecified prefixes
4) multicast prefixes 4) multicast prefixes
5) IPv4-compatible prefixes 5) IPv4-compatible prefixes
6) IPv4-mapped prefixes 6) IPv4-mapped prefixes
7) default routes 7) default routes
8) yet undefined unicast prefixes (from a different /3 prefix) 8) yet undefined unicast prefixes (from a different /3 prefix)
9) inter-site links issues 9) inter-site links issues
10) 6to4 prefixes 10) 6to4 prefixes
11) aggregation & advertisement issues 11) aggregation & advertisement issues
3.1 Link-local prefixes 3.1 Link-local prefixes
This link-local prefix (FE80::/10) MUST NOT be advertised through either This link-local prefix (FE80::/10) MUST NOT be advertised through
an IGP or an EGP. Under no circumstance should this prefix be seen in either an IGP or an EGP. Under no circumstance should this prefix be
the 6Bone backbone routing table. seen in the 6Bone backbone routing table.
By definition, the link-local prefix has a scope limited to a specific By definition, the link-local prefix has a scope limited to a
link. Since the prefix is the same on all IPv6 links, advertising it in specific link. Since the prefix is the same on all IPv6 links,
any routing protocol does not make sense and, worse, may introduce nasty advertising it in any routing protocol does not make sense and,
error conditions. worse, may introduce nasty error conditions.
Well known cases where link-local prefixes could be advertised by Well known cases where link-local prefixes could be advertised by
mistake include, but are not limited to: mistake include, but are not limited to:
- a router advertising all directly connected network prefixes - a router advertising all directly connected network prefixes
including the link-local one including the link-local one
- subnetting of the link-local prefix - subnetting of the link-local prefix
In such cases, vendors should be urged to correct their code. While In such cases, vendors should be urged to correct their code. While
vendors should be encouraged to fix the problem, the ultimate vendors should be encouraged to fix the problem, the ultimate
responsibility lies on the operator of that IPv6 site to correct the responsibility lies on the operator of that IPv6 site to correct the
problem through whatever means necessary. problem through whatever means necessary.
Should a pTLA discover link-local prefixes coming from another pTLA, Should a pTLA discover link-local prefixes coming from another pTLA,
it is the responsibility of the pTLA leaking the routes to filter these, it is the responsibility of the pTLA leaking the routes to filter
and correct the problem in a timely fashion. Should a pTLA discover that these, and correct the problem in a timely fashion. Should a pTLA
a downstream of that pTLA is leaking link-local prefixes, it is the discover that a downstream of that pTLA is leaking link-local
pTLA's responsibility to ensure that these prefixes are not leaked to prefixes, it is the pTLA's responsibility to ensure that these
other pTLA's, or to other downstreams of that pTLA. 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 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. 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 (Also, it is each pTLA, pNLA, and end-site's responsibility to not
only filter their own BGP4+ sessions appropriately to peers, but to only filter their own BGP4+ sessions appropriately to peers, but to
filter routes coming from peers as well, and to only allow those filter routes coming from peers as well, and to only allow those
routes that fit the aggregation model, and do not cause operational routes that fit the aggregation model, and do not cause operational
problems). problems).
3.2 Site-local prefixes 3.2 Site-local prefixes
Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGP's Site local prefixes (in the FEC0::/10 range) MAY be advertised by
or EGP's within a site. The precise definition of a site is ongoing work IGP's or EGP's within a site. The precise definition of a site is
of the IPng working group, but should generally include a group of nodes ongoing work of the IPng working group, but should generally include
that are operating under one administrator or group of administrators, a group of nodes that are operating under one administrator or group
or a group of nodes which are used for a common purpose. 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, Site-local prefixes MUST NOT be advertised across transit pNLAs,
or leaf-sites. pTLAs, or leaf-sites.
Again, should site-local prefixes be leaked outside of a given site, 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 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 manner, either through filters, or via other means which remove the
operational impact that those prefixes had on the peering sites operational impact that those prefixes had on the peering sites
involved. However, every site SHOULD filter not only outbound on their involved. However, every site SHOULD filter not only outbound on
EGP, but also inbound, in order to ensure proper routing announcements their EGP, but also inbound, in order to ensure proper routing
are not only sent, but also received. announcements are not only sent, but also received.
3.3 Loopback and unspecified prefixes 3.3 Loopback and unspecified prefixes
The loopback prefix (::1/128) and the unspecified prefix (::0/128) The loopback prefix (::1/128) and the unspecified prefix (::0/128)
MUST NOT be advertised by any routing protocol. MUST NOT be advertised by any routing protocol.
The same responsibility lies with the party guilty of advertising the The same responsibility lies with the party guilty of advertising the
loopback or unspecified prefix as in Section 3.1 and 3.2. loopback or unspecified prefix as in Section 3.1 and 3.2.
3.4 Multicast prefixes 3.4 Multicast prefixes
Multicast prefixes MUST NOT be advertised by any unicast routing Multicast prefixes MUST NOT be advertised by any unicast routing
protocol. Multicast routing protocols are designed to respect the protocol. Multicast routing protocols are designed to respect the
semantics of multicast and MUST therefore be used to route packets with semantics of multicast and MUST therefore be used to route packets
multicast destination addresses (in the range of FF00::/8). with multicast destination addresses (in the range of FF00::/8).
Multicast address scopes MUST be respected on the 6Bone. Only global Multicast address scopes MUST be respected on the 6Bone. Only global
scope multicast addresses MAY be routed across transit pNLAs and pTLAs. scope multicast addresses MAY be routed across transit pNLAs and
There is no requirement on a pTLA to route multicast packets at the pTLAs. There is no requirement on a pTLA to route multicast packets
time of the writing of this draft. at the time of the writing of this memo.
Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges)
MAY be routed across a pNLA to its leaf sites. MAY be routed across a pNLA to its leaf sites.
Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs. Site-local multicasts MUST NOT be routed toward transit pNLAs or
pTLAs.
Link-local multicasts and node-local multicasts MUST NOT be routed at Link-local multicasts and node-local multicasts MUST NOT be routed at
all. all.
3.5 IPv4 compatible prefixes 3.5 IPv4 compatible prefixes
Sites may choose to use IPv4 compatible addresses (::a.b.c.d where 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 a.b.c.d represents the octets of an IPv4 address) internally. As
is no real rationale today for doing so, these address SHOULD NOT be there is no real rationale today for doing so, these address SHOULD
used or routed in the 6Bone. NOT be used or routed in the 6Bone.
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit
pNLAs or pTLAs. pNLAs or pTLAs.
Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is the Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is
responsibility of the party who is advertising the route to fix the the responsibility of the party who is advertising the route to fix
problem, either through proper filters, or through other means, while the problem, either through proper filters, or through other means,
it remains in the best interest of all particiapants of the 6Bone to while it remains in the best interest of all particiapants of the
filter both outbound and inbound at their IGP borders. 6Bone to filter both outbound and inbound at their IGP borders.
3.6 IPv4-mapped prefixes 3.6 IPv4-mapped prefixes
IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d represents the 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 octets of an IPv4 address) MAY be advertised by IGPs within a site.
may be useful for some IPv6 only nodes within a site to have such a It may be useful for some IPv6 only nodes within a site to have such
route pointing to a translation device, to aid in deployment of IPv6. a route pointing to a translation device, to aid in deployment of
IPv6.
IPv4-mapped prefixes MUST NOT be advertised by EGPs. IPv4-mapped prefixes MUST NOT be advertised by EGPs.
3.7 Default routes 3.7 Default routes
6Bone core pTLA routers MUST be default-free. 6Bone core pTLA routers MUST be default-free.
pTLAs MAY advertise a default route to any downstream peer (non-pTLA pTLAs MAY advertise a default route to any downstream peer (non-pTLA
site). Transit pNLAs MAY advertise a default route to any of their site). Transit pNLAs MAY advertise a default route to any of their
downstreams (other transit pNLA or leaf site). downstreams (other transit pNLA or leaf site).
Should a default route be redistributed into an EGP and found on any 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 pTLA EGP sessions, it is the responsibility of the pTLA to fix this
problem immediately upon realization of the route's existence, and the problem immediately upon realization of the route's existence, and
responsibility of the guilty pTLA to push the entity from which the the responsibility of the guilty pTLA to push the entity from which
default route was originated, should the default route have originated the default route was originated, should the default route have
from downstream of a pTLA. originated from downstream of a pTLA.
3.8 Yet undefined unicast prefixes 3.8 Yet undefined unicast prefixes
Yet undefined unicast prefixes from a format prefix other than 2000::/3 Yet undefined unicast prefixes from a format prefix other than
MUST NOT be advertised by any routing protocol in the 6Bone. In 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone.
particular, RFC 2471 test addresses MUST NOT be advertised on 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), Routing of global unicast prefixes outside the 6Bone range
and routing of global unicast prefixes yet undelegated in the range (3ffe::/16), and routing of global unicast prefixes yet undelegated
(3ffe::/16) are discussed in section 4, Routing policies, below. in the range (3ffe::/16) are discussed in section 4, Routing
policies, below.
3.9 Inter-site links 3.9 Inter-site links
Global IPv6 addresses must be used for the end points of inter-site Global IPv6 addresses must be used for the end points of inter-site
links. In particular, IPv4 compatible addresses MUST NOT be used for links. In particular, IPv4 compatible addresses MUST NOT be used for
tunnels. tunnels.
Sites MAY use Other addressing schemes for Inter-site links, but these Sites MAY use Other addressing schemes for Inter-site links, but
addresses MUST NOT be advertised into the IPv6 global routing table. these addresses MUST NOT be advertised into the IPv6 global routing
table.
Prefixes for inter-site links MUST NOT be injected in the global routing Prefixes for inter-site links MUST NOT be injected in the global
tables. routing tables.
3.10 6to4 Prefixes 3.10 6to4 Prefixes
The 6to4 prefix, or some portion thereof, MAY be announced The 6to4 prefix, or some portion thereof, MAY be announced by any
by any pTLA which has a current implementation of 6to4 in their IPv6 pTLA which has a current implementation of 6to4 in their IPv6
network. However, as 6to4 implementors gain more operational network. However, as 6to4 implementors gain more operational
experience, it MAY be necessary to change this in some way. experience, it MAY be necessary to change this in some way. At the
At the time of the writing of this docuement, any pTLA MAY announce time of the writing of this docuement, any pTLA MAY announce the 6to4
the 6to4 prefix into global EBGP. However, in order to announce this prefix into global EBGP. However, in order to announce this block,
block, the pTLA MUST have a 6to4 router active, sourcing this prefix the pTLA MUST have a 6to4 router active, sourcing this prefix
announcement. announcement.
This section subject to change, and MAY vary, depending on 6to4 progress This section subject to change, and MAY vary, depending on 6to4
within the NGTRANS working group. progress within the NGTRANS working group.
3.11 Aggregation & advertisement issues 3.11 Aggregation & advertisement issues
Route aggregation MUST be performed by any border router talking EGP Route aggregation MUST be performed by any border router talking EGP
with any other IPv6 sites. More-specifics MUST NOT be leaked into or with any other IPv6 sites. More-specifics MUST NOT be leaked into or
across the IPv6 6Bone backbone. across the IPv6 6Bone backbone.
4. Routing Policies 4. Routing Policies for the 6bone
Leaf sites or pNLAs MUST only advertise to an upstream provider the Leaf sites or pNLAs MUST only advertise to an upstream provider the
prefixes assigned by that provider. Advertising a prefix assigned by prefixes assigned by that provider. Advertising a prefix assigned by
another provider to a provider is not acceptable, and breaks the another provider to a provider is not acceptable, and breaks the
aggregation model. A site MUST NOT advertise a prefix from another aggregation model. A site MUST NOT advertise a prefix from another
provider to a provider as a way around the multi-homing problem. provider to a provider as a way around the multi-homing problem.
However, in the interest of testing new solutions, one may break this 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 policy, so long as ALL affected parties are aware of this test, and
agree to support this testing. These policy breaks MUST NOT affect the all agree to support this testing. These policy breaks MUST NOT
6bone routing table globally. affect the 6bone routing table globally.
To clarify, if one has two upstream pNLA or pTLA providers, (A and B for To clarify, if one has two upstream pNLA or pTLA providers, (A and B
this example), one MUST only announce the prefix delegated to one by for this example), one MUST only announce the prefix delegated to one
provider A to provider A, and one MUST only announce the prefeix 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 delegated by one from provider B upstream to provider B. There exists
no circumstance where this should be violated, as it breaks the no circumstance where this should be violated, as it breaks the
aggregation model, and could globally affect routing decisions if aggregation model, and could globally affect routing decisions if
downstreams are able to leak other providers' more specific delegations downstreams are able to leak other providers' more specific
up to a pTLA. As the IPNG working group works through the multi-homing delegations up to a pTLA. As the IPNG working group works through the
problem, there may be a need to alter this rule slightly, to test new multi-homing problem, there may be a need to alter this rule
strategies for deployment. However, in the case of current slightly, to test new strategies for deployment. However, in the case
specifications at the time of this writing, there is no reason to of current specifications at the time of this writing, there is no
advertise more specifics, and pTLA's MUST adhere to the current reason to advertise more specifics, and pTLA's MUST adhere to the
aggregation model. current aggregation model.
Site border routers for pNLA or leaf sites MUST NOT advertise prefixes Site border routers for pNLA or leaf sites MUST NOT advertise
more specific (longer) than the prefix that was allocated by their prefixes more specific (longer) than the prefix that was allocated by
upstream provider. their upstream provider.
All pTLAs MUST NOT advertise prefixes longer than a given pTLA All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA
delegation (currently /24 or /28) to other pTLAs unless special peering delegation (currently /24 or /28) to other 6bone pTLAs unless special
arrangements are implemented. When such special peering aggreements are peering arrangements are implemented. When such special peering
in place between any two or more pTLAs, care MUST be taken not to leak aggreements are in place between any two or more 6bone pTLAs, care
the more specifics to other pTLAs not participating in the peering MUST be taken not to leak the more specifics to other 6bone pTLAs not
aggreement. pTLAs which have such agreements in place MUST NOT advertise participating in the peering aggreement. 6bone pTLAs which have such
other pTLA more specifics to downstream pNLAs or leaf sites, as this agreements in place MUST NOT advertise other 6bone pTLA more
will break the best-path routing decision. specifics to downstream 6bone 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, The peering agreements across the 6Bone may be by nature non-
and therefore MAY allow transit traffic, if peering agreements of this commercial, and therefore MAY allow transit traffic, if peering
nature are made. However, no pTLA is REQUIRED to give or receive transit agreements of this nature are made. However, no pTLA is REQUIRED to
service from another pTLA. give or receive transit service from another pTLA.
Eventually, the Internet registries will assign prefixes under other Eventually, the Internet registries will assign prefixes under other
than the 6Bone TLA (3FFE::/16). As of the time this document was than the 6Bone TLA (3FFE::/16). As of the time this document was
written in 1999, the Internet registries were starting to assig /35 written in 1999, the Internet registries were starting to assign /35
sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly be sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly
used in the future. be used in the future.
The organizations receiving prefixes under these newer TLAs would be The organizations receiving prefixes under these newer TLAs would be
expected to want to establish peering and connectivity relationships expected to want to establish peering and connectivity relationships
with other IPv6 networks, both in the newer TLA space and in the 6bone with other IPv6 networks, both in the newer TLA space and in the
pTLA space. Peering between new TLA's and the current 6Bone pTLA's MAY 6bone pTLA space. Peering between new TLA's and the current 6Bone
occur, and details such as transit, and what routes are received by pTLA's MAY occur, and details such as transit, and what routes are
each, are outside of general peering rules as stated in this draft, and received by each, are outside of general peering rules as stated in
are left up to the members of those TLA's and pTLA's that are this memo, and are left up to the members of those TLA's and pTLA's
establishing said peerings. However, it is expected that most of the that are establishing said peerings. However, it is expected that
rules discussed here are equally applicable to new TLAs. most of the rules discussed here are equally applicable to new TLAs.
5. The 6Bone Registry 5. The 6Bone Registry
The 6Bone registry is a RIPE-181 database with IPv6 extensions used to The 6Bone registry is a RIPE-181 database with IPv6 extensions used
store information about the 6Bone, and its sites. The 6bone is to store information about the 6Bone, and its sites. The 6bone is
accessible at: accessible at:
<http://www.6bone.net/whois.html>) <http://www.6bone.net/whois.html>)
Each 6Bone site MUST maintain the relevant entries in the 6Bone Each 6Bone site MUST maintain the relevant entries in the 6Bone
registry. In particular, the following object MUST be present for all registry. In particular, the following object MUST be present for all
6Bone leaf sites, pNLAs and pTLAs: 6Bone leaf sites, pNLAs and pTLAs:
-IPv6-site: site description - IPv6-site: site description
-Inet6num: prefix delegation (one record MUST exist for each delegation) - Inet6num: prefix delegation (one record MUST exist for each
delegation)
-Mntner: contact info for site maintance/administration staff. - Mntner: contact info for site maintance/administration staff.
Other object MAY be maintained at the discretion of the sites such as Other object MAY be maintained at the discretion of the sites such as
routing policy descriptors, person, or role objects. The Mntner object routing policy descriptors, person, or role objects. The Mntner
MUST make reference to a role or person object, but those MAY NOT object MUST make reference to a role or person object, but those MAY
necessarily reside in the 6Bone registry. They can be stored within any NOT necessarily reside in the 6Bone registry. They can be stored
of the Internet registry databases (ARIN, APNIC, RIPE-NCC, etc.) within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC,
etc.)
6. Guidelines for new sites joining the 6Bone 6. Guidelines for new sites joining the 6Bone
New sites joining the 6Bone should seek to connect to a transit pNLA or New sites joining the 6Bone should seek to connect to a transit pNLA
a pTLA within their region, and preferably as close as possible to their or a pTLA within their region, and preferably as close as possible to
existing IPv4 physical and routing path for Internet service. The 6Bone their existing IPv4 physical and routing path for Internet service.
web site at <http://www.6bone.net> has various information and tools to The 6Bone web site at <http://www.6bone.net> has various information
help find candidate 6bone networks. and tools to help find candidate 6bone networks.
Any site connected to the 6Bone MUST maintain a DNS server for forward Any site connected to the 6Bone MUST maintain a DNS server for
name lookups and reverse address lookups. The joining site MUST forward name lookups and reverse address lookups. The joining site
maintain the 6Bone objects relative to its site, as describe in MUST maintain the 6Bone objects relative to its site, as describe in
section 5. section 5.
The upstream provider MUST delegate the reverse address translation The upstream provider MUST delegate the reverse address translation
zone in DNS to the joining site, or have an agreement in place to 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 perform primary DNS for that downstream. The provider MUST also
the 6Bone registry inet6num object reflecting the delegated address create the 6Bone registry inet6num object reflecting the delegated
space. address space.
Up to date informatino about how to join the 6Bone is available on the Up to date informatino about how to join the 6Bone is available on
6Bone Web site at <http://www.6bone.net>. the 6Bone Web site at <http://www.6bone.net>.
7. Guidelines for 6Bone pTLA sites 7. Guidelines for 6Bone pTLA sites
The following rules apply to qualify for a 6Bone pTLA allocation. It The following rules apply to qualify for a 6Bone pTLA allocation. It
should be recognized that holders of 6Bone pTLA allocations are expected should be recognized that holders of 6Bone pTLA allocations are
to provide production quality backbone network services for the 6Bone. expected to provide production quality backbone network services for
the 6Bone.
1. The pTLA Applicant must have a minimum of three (3) months 1. The pTLA Applicant must have a minimum of three (3) months
qualifying experience as a 6Bone end-site or pNLA transit. qualifying experience as a 6Bone end-site or pNLA transit. During
During the entire qualifying period the Applicant must be the entire qualifying period the Applicant must be operationally
operationally providing the following: providing the following:
a. Fully maintained, up to date, 6Bone Registry entries for their a. Fully maintained, up to date, 6Bone Registry entries for their
ipv6-site inet6num, mntner, and person objects, including each ipv6-site inet6num, mntner, and person objects, including each
tunnel that the Applicant has. tunnel that the Applicant has.
b. Fully maintained, and reliable, BGP4+ peering and connectivity b. Fully maintained, and reliable, BGP4+ peering and connectivity
between the Applicant's boundary router and the appropriate between the Applicant's boundary router and the appropriate
connection point into the 6Bone. This router must be IPv6 connection point into the 6Bone. This router must be IPv6
pingable. This criteria is judged by members of the 6Bone pingable. This criteria is judged by members of the 6Bone
Operations Group at the time of the Applicant's pTLA request. Operations Group at the time of the Applicant's pTLA request.
c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) c. Fully maintained DNS forward (AAAA) and reverse (ip6.int)
entries for the Applicant's router(s) and at least one host entries for the Applicant's router(s) and at least one host
system. system.
d. A fully maintained, and reliable, IPv6-accessible system d. A fully maintained, and reliable, IPv6-accessible system
providing, at a mimimum, one or more web pages, describing the providing, at a mimimum, one or more web pages, describing the
Applicant's IPv6 services. This server must be IPv6 pingable. Applicant's IPv6 services. This server must be IPv6 pingable.
2. The pTLA Applicant MUST have the ability and intent to provide 2. The pTLA Applicant MUST have the ability and intent to provide
"production-quality" 6Bone backbone service. Applicants must "production-quality" 6Bone backbone service. Applicants must
provide a statement and information in support of this claim. provide a statement and information in support of this claim.
This MUST include the following: This MUST include the following:
a. A support staff of two persons minimum, three preferable, with a. A support staff of two persons minimum, three preferable, with
person attributes registered for each in the ipv6-site object person attributes registered for each in the ipv6-site object
for the pTLA applicant. for the pTLA applicant.
b. A common mailbox for support contact purposes that all support b. A common mailbox for support contact purposes that all support
staff have acess to, pointed to with a notify attribute in the staff have acess to, pointed to with a notify attribute in the
ipv6-site object for the pTLA Applicant. ipv6-site object for the pTLA Applicant.
3. The pTLA Applicant MUST have a potential "user community" that 3. The pTLA Applicant MUST have a potential "user community" that
would be served by its becoming a pTLA, e.g., the Applicant is a would be served by its becoming a pTLA, e.g., the Applicant is a
major provider of Internet service in a region, country, or major provider of Internet service in a region, country, or focus
focus of interest. Applicant must provide a statement and of interest. Applicant must provide a statement and information in
information in support this claim. support this claim.
4. The pTLA Applicant MUST commit to abide by the current 6Bone 4. The pTLA Applicant MUST commit to abide by the current 6Bone
operational rules and policies as they exist at time of its operational rules and policies as they exist at time of its
application, and agree to abide by future 6Bone backbone application, and agree to abide by future 6Bone backbone
operational rules and policies as they evolve by consensus of the operational rules and policies as they evolve by consensus of the
6Bone backbone and user community. 6Bone backbone and user community.
When an Applicant seeks to receive a pTLA allocation, it will apply to When an Applicant seeks to receive a pTLA allocation, it will apply
the 6Bone Operations Group (see section 8 below) by providing to the to the 6Bone Operations Group (see section 8 below) by providing to
Group information in support of its claims that it meets the criteria the Group information in support of its claims that it meets the
above. criteria above.
8. 6Bone Operations Group 8. 6Bone Operations Group
The 6Bone Operations Group is the group in charge of monitoring and The 6Bone Operations Group is the group in charge of monitoring and
policing adherence to the current rules. Membership in the 6Bone policing adherence to the current rules. Membership in the 6Bone
Operations Group is mandatory for, and restricted to, sites connected Operations Group is mandatory for, and restricted to, sites connected
to the 6Bone. to the 6Bone.
The 6Bone Operations Group is currently defined by those members of The 6Bone Operations Group is currently defined by those members of
the existing 6Bone mailing list who represent sites participating in the existing 6Bone mailing list who represent sites participating in
the 6Bone. Therefore it is incumbent on relevant site contacts to join the 6Bone. Therefore it is incumbent on relevant site contacts to
the 6Bone mailing list. Instructions on how to join the list are join the 6Bone mailing list. Instructions on how to join the list are
maintained on the 6Bone web site at < http://www.6bone.net>. maintained on the 6Bone web site at < http://www.6bone.net>.
9. Common rules enforcement 9. Common rules enforcement for the 6bone
Participation in the 6Bone is a voluntary and benevolent undertaking. Participation in the 6Bone is a voluntary and benevolent undertaking.
However, participating sites are expected to adhere to the rules and However, participating sites are expected to adhere to the rules and
policies described in this document in order to maintain the 6Bone as policies described in this document in order to maintain the 6Bone as
a quality tool for the deployment of, and transition to, IPv6 protocols a quality tool for the deployment of, and transition to, IPv6
and the products implementing them. protocols and the products implementing them.
The following is in support of policing adherence to 6Bone rules and The following is in support of policing adherence to 6Bone rules and
policies: policies:
1. Each pTLA site has committed to implement the 6Bone's rules and 1. Each pTLA site has committed to implement the 6Bone's rules and
policies, and SHOULD try to ensure they are adhered to by sites policies, and SHOULD try to ensure they are adhered to by sites
within their administrative control, i.e. those to who prefixes within their administrative control, i.e. those to who prefixes
under their respective pTLA prefix have been delegated. under their respective pTLA prefix have been delegated.
2. When a site detects an issue, it SHOULD first use the 6Bone 2. When a site detects an issue, it SHOULD first use the 6Bone
registry to contact the site maintainer and work the issue. registry to contact the site maintainer and work the issue.
3. If nothing happens, or there is disagreement on what the right 3. If nothing happens, or there is disagreement on what the right
solution is, the issue SHOULD be brought to the 6Bone Operations solution is, the issue SHOULD be brought to the 6Bone Operations
Group. Group.
4. When the problem is related to a product issue, the site(s) 4. When the problem is related to a product issue, the site(s)
involved SHOULD be responsible for contacting the product vendor involved SHOULD be responsible for contacting the product vendor
and work toward its resolution. and work toward its resolution.
5. When an issue causes major operational problems, backbone sites 5. When an issue causes major operational problems, backbone sites
SHOULD decide to temporarily set filters in order to restore SHOULD decide to temporarily set filters in order to restore
service. service.
10. Security Considerations 10. Security Considerations
The result of incorrect entries in routing tables is usually unreachable The result of incorrect entries in routing tables is usually
sites. Having guidelines to aggregate or reject routes will clean up unreachable sites. Having guidelines to aggregate or reject routes
the routing tables. It is expected that using these rules and policies, will clean up the routing tables. It is expected that using these
routing on the 6Bone will be less sensitive to denial of service attacks rules and policies, routing on the 6Bone will be less sensitive to
due to misleading routes. denial of service attacks due to misleading routes.
The 6Bone is an IPv6 testbed to assist in the evolution and deployment The 6Bone is an IPv6 testbed to assist in the evolution and
of IPv6. Therefore, denial of service or packet disclosure are to be deployment of IPv6. Therefore, denial of service or packet disclosure
expected. However, it is the pTLA from where the attack originated who are to be expected. However, it is the pTLA from where the attack
has ultimate responsibility for isolating and fixing problems of this originated who has ultimate responsibility for isolating and fixing
nature. It is also every 6Bone site's responsibility to safely introduce problems of this nature. It is also every 6Bone site's responsibility
new test systems into the 6Bone, by placing them at a strategically safe to safely introduce new test systems into the 6Bone, by placing them
places which will have minimal impact on other 6Bone sites, should bugs at a strategically safe places which will have minimal impact on
or misconfigurations occur. other 6Bone sites, should bugs or misconfigurations occur.
11. References 11. References
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6 [RFC 2471] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address
Testing Address Allocation", RFC 2471, December 1998. Allocation", RFC 2471, December 1998.
[RFC 2546] Durand, A., Buclin, B, "6Bone Routing Practice", [RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC
RFC 2546, March 1999 2546, March 1999
[RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. January 1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 2283, March 1998. "Multiprotocol Extensions for BGP-4", RFC 2283, March
1998.
[RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J.,
Karrenberg, D., Terpstra, M. and J. Yu, Representation Karrenberg, D., Terpstra, M. and J. Yu, Representation
of IP Routing Policies in a Routing Registry. Technical of IP Routing Policies in a Routing Registry. Technical
Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands,
October 1994. October 1994.
12. Authors' Addresses 12. Authors' Addresses
Rob Rockell Rob Rockell
rrockell@sprint.net EMail: rrockell@sprint.net
Bob Fink Bob Fink
fink@es.net EMail: fink@es.net
-end 13. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 112 change blocks. 
357 lines changed or deleted 363 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/