--- 1/draft-ietf-ngtrans-harden-00.txt 2006-02-05 00:50:01.000000000 +0100 +++ 2/draft-ietf-ngtrans-harden-01.txt 2006-02-05 00:50:01.000000000 +0100 @@ -1,22 +1,18 @@ INTERNET DRAFT R. Rockell NGTRANS WG Sprint Category: Informational B. Fink Expires December 1999 ESNet - A. Durand - IMAG - B. Buclin - AT&T Labs Europe - 6Bone Hardening Effort + 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. @@ -39,21 +35,21 @@ 1. Abstract 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 the IPv6 network maintain stability, and that all operators have a common set of rules and guildelines by which to deploy IPv6 routing equipment. This document provides a set of guildelines for all IPv6 routing equipment operators to use as a reference for efficient and stable deployment of IPv6 routing systems. As the complexity of the 6Bone grows, 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Scope of this document. This document is a best-practices document aimed at all entities which @@ -81,21 +77,22 @@ 8) yet undefined unicast prefixes (from a different /3 prefix) 9) inter-site links issues 10) aggregation & advertisement issues 3.1 Link-local prefix 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. 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, but are not limited to: - a router advertising all directly connected network prefixes including the @@ -122,21 +119,21 @@ operational problems). 3.2 Site-local prefixes 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 discussed in the IPng working group, but should generally include a 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. -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. 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 manner, either through filters, or via other means which remove the operational impact that those prefixes had on the peering sites involved. 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, but also received. @@ -219,40 +216,57 @@ 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. Prefixes for inter-site links MUST NOT be injected in the global routing 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 -any other IPv6 sites. +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. 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. +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 specific (longer) than the prefix that was allocated by their upstream provider. All pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other pTLAs unless special peering 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 specifics to other pTLAs not participating in the peering aggreement. pTLAs