draft-ietf-ngtrans-harden-00.txt   draft-ietf-ngtrans-harden-01.txt 
INTERNET DRAFT R. Rockell INTERNET DRAFT R. Rockell
NGTRANS WG Sprint NGTRANS WG Sprint
Category: Informational B. Fink Category: Informational B. Fink
Expires December 1999 ESNet Expires December 1999 ESNet
A. Durand
IMAG
B. Buclin
AT&T Labs Europe
6Bone Hardening Effort 6Bone Backbone Routing Guildelines
<draft-ietf-ngtrans-harden-00.txt> <draft-ietf-ngtrans-harden-01.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with all This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet Drafts are working documents of Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its Areas, and it Working the Internet Engineering Task Force (IETF), its Areas, and it Working
Groups. Note that other groups may also distribute working documents as Groups. Note that other groups may also distribute working documents as
Internet Drafts. Internet Drafts.
skipping to change at line 49 skipping to change at line 45
1. Abstract 1. 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 deployment
of IPv6. Because of this, it is important that the core backbone of IPv6. Because of this, it is important that the core backbone
of the IPv6 network maintain stability, and that all operators have of the IPv6 network maintain stability, and that all operators have
a common set of rules and guildelines by which to deploy IPv6 routing a common set of rules and guildelines by which to deploy IPv6 routing
equipment. This document provides a set of guildelines for all IPv6 equipment. This document provides a set of guildelines for all IPv6
routing equipment operators to use as a reference for efficient and stable routing equipment operators to use as a reference for efficient and stable
deployment of IPv6 routing systems. As the complexity of the 6Bone grows, deployment of IPv6 routing systems. As the complexity of the 6Bone grows,
the adherence to a common set of rules becomes increasingly important in the adherence to a common set of rules becomes increasingly important in
order for an efficient backbone to exist. order for an efficient, scalable backbone to exist.
This document uses BGP4+ as the currently accepted EGP. This document uses BGP4+ as the currently 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 document aimed at all entities which This document is a best-practices document aimed at all entities which
skipping to change at line 91 skipping to change at line 87
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) aggregation & advertisement issues 10) aggregation & advertisement issues
3.1 Link-local prefix 3.1 Link-local prefix
This link-local prefix (FE80::/10) MUST NOT be advertised through either an This link-local prefix (FE80::/10) MUST NOT be advertised through either an
IGP or an EGP. 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. 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 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 routing protocol does not make sense and, worse, may introduce nasty error
conditions. conditions.
Well known cases where link-local prefixes could be advertised by mistake Well known cases where link-local prefixes could be advertised by mistake
include, but are not limited to: include, but are not limited to:
- a router advertising all directly connected network prefixes including the - a router advertising all directly connected network prefixes including the
skipping to change at line 132 skipping to change at line 129
operational problems). operational 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 or 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 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 discussed in the IPng working group, but should generally include a group of
nodes that are operating under one administrator or 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. administrators, or a group of nodes which are used for a common purpose.
Site-local prefixes MUST NOT be advertised to transit pNLAs, pTLAs, or Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, or
leaf-sites. leaf-sites.
Again, should site-local prefixes be leaked unwantedly outside of a given 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 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 manner, either through filters, or via other means which remove the
operational impact that those prefixes had on the peering sites involved. operational impact that those prefixes had on the peering sites involved.
However, every site SHOULD filter not only outbound on their EGP, but also 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, inbound, in order to ensure proper routing announcements are not only sent,
but also received. but also received.
skipping to change at line 229 skipping to change at line 226
are discussed in section 4, Routing policies, below. 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 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. In particular, IPv4 compatible addresses MUST NOT be used for tunnels.
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 routing
tables. tables.
3.10 Aggregation & advertisement issues. 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 Route aggregation MUST be performed by any border router talking EGP with
any other IPv6 sites. any other IPv6 sites. More-specifics MUST NOT be leaked into or across the
IPv6 6Bone backbone.
4. Routing Policies 4. Routing Policies
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 another prefixes assigned by that provider. Advertising a prefix assigned by another
provider to a provider is not acceptable, and breaks the aggregation model. 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 A site MUST not advertise a prefix from another provider to a provider as a
way around the multi-homing problem. way around the multi-homing problem.
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 for
this example), one MUST only announce the prefix delegated to one by provider 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 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 from provider B upstream to provider B. There exists no circumstance where
this should be violated, as it breaks the aggregation model, and could this should be violated, as it breaks the aggregation model, and could
globally affect routing decisions if downstreams are able to leak other globally affect routing decisions if downstreams are able to leak other
providers' more specific delegations up to a pTLA. 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 Site border routers for pNLA or leaf sites MUST NOT advertise prefixes more
specific (longer) than the prefix that was allocated by their upstream specific (longer) than the prefix that was allocated by their upstream
provider. provider.
All pTLAs MUST NOT advertise prefixes longer than a given pTLA All 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 pTLAs unless special peering
arrangements are implemented. When such special peering aggreements are in 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 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 specifics to other pTLAs not participating in the peering aggreement. pTLAs
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/