draft-ietf-ngtrans-harden-01.txt   draft-ietf-ngtrans-harden-02.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 June 2000 ESNet
6Bone Backbone Routing Guildelines 6Bone Backbone Routing Guildelines
<draft-ietf-ngtrans-harden-01.txt> <draft-ietf-ngtrans-harden-02.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 223 skipping to change at line 223
Routing of global unicast prefixes outside the 6Bone range (3ffe::/16), and Routing of global unicast prefixes outside the 6Bone range (3ffe::/16), and
routing of global unicast prefixes yet undelegated in the range (3ffe::/16) routing of global unicast prefixes yet undelegated in the range (3ffe::/16)
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.
Sites MAY use Other addressing schemes for Inter-site links, but 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 routing
tables. tables.
3.10 6to4 Prefix (2010::/16) 3.10 6to4 Prefix
The 6to4 prefix, or some portion thereof, MAY be announced The 6to4 prefix, or some portion thereof, MAY be announced
by any pTLA which has a current implementation of 6to4 in their IPv6 by any 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 time of the writing of this docuement, any pTLA MAY announce 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 the 6to4 prefix into global EBGP. However, in order to announce this
block, the pTLA MUST have a 6to4 router active, sourcing this prefix block, 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 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 with 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 any other IPv6 sites. More-specifics MUST NOT be leaked into or across the
IPv6 6Bone backbone. 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. 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 agree to support this testing. These policy
breaks MUST NOT 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 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. As the IPNG working group 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 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 rule slightly, to test new strategies for deployment. However, in the case
skipping to change at line 348 skipping to change at line 356
During this entire qualifying period the Applicant must be During this entire qualifying period the Applicant must be
operationally providing the following: operationally providing the following:
a. Fully maintained, up to date, 6Bone Registry entries for a. Fully maintained, up to date, 6Bone Registry entries for
their ipv6-site inet6num, mntner, and person objects, their ipv6-site inet6num, mntner, and person objects,
including each tunnel that the Applicant has. including each tunnel that the Applicant has.
b. Fully maintained, and reliable, BGP4+ peering and connec- b. Fully maintained, and reliable, BGP4+ peering and connec-
tivity between the Applicant's boundary router with the tivity between the Applicant's boundary router with the
appropriate hierarchy. This includes a high uptime appropriate hierarchy. This includes a high uptime
availability of the site router (greater than 99%). This availability of the site router. This
router must be IPv6 pingable. router must be IPv6 pingable. This criteria is judged by
members of the NGTRANS working group at the time of the request
for pTLA.
c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) c. Fully maintained DNS forward (AAAA) and reverse (ip6.int)
entries for their site's router, and at least one host ser- entries for their site's router, and at least one host ser-
ver system. ver system.
d. A fully maintained, and reliable host server system providing, d. A fully maintained, and reliable host server system providing,
at a mimimum, one or more web pages describing the applicant's at a mimimum, one or more web pages describing the applicant's
project and service on the 6Bone, available via IPv6. This project and service on the 6Bone, available via IPv6. This
server must be IPv6 pingable. server must be IPv6 pingable.
 End of changes. 

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