--- 1/draft-ietf-ngtrans-harden-01.txt 2006-02-05 00:50:03.000000000 +0100 +++ 2/draft-ietf-ngtrans-harden-02.txt 2006-02-05 00:50:03.000000000 +0100 @@ -1,18 +1,18 @@ INTERNET DRAFT R. Rockell NGTRANS WG Sprint Category: Informational B. Fink -Expires December 1999 ESNet +Expires June 2000 ESNet 6Bone Backbone Routing Guildelines - + 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. @@ -213,47 +213,55 @@ 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. +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 tables. -3.10 6to4 Prefix (2010::/16) +3.10 6to4 Prefix 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. +This section subject to change, and MAY vary, depending on 6to4 progress within the NGTRANS working group. + 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. +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 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 @@ -338,22 +346,24 @@ 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. + availability of the site router. This + 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) 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.