Good people of the IPv6 Working Group, It was suggested to me that for some strange reason you may also be interested in this document and discussion... Best regards, Rob -------- Original Message -------- Subject: [routing-wg] IPv6 Routing Recommendations. Date: Wed, 23 Feb 2011 14:39:18 +0800 From: Rob Evans <rhe@nosc.ja.net> To: routing-wg@ripe.net All, You may remember that back in the mists of time (about a year ago) we had a document that updated RIPE-399 with some IPv6 routing recommendations. After the meeting last May, the authors were to go away and take out mention of any specific suggestions on filtering (e.g. /36). Over the past 12 months, Philip and I have been hard at work constantly refining this document to reflect the changing nature of the IPv6 routing table. Well, kind-of. Anyway, my laziness aside, appended is the document as it stands at the moment. Comments and discussion please! Rob RIPE Routing Working Group Recommendations on IPv6 Route Aggregation ==================================================================== Rob Evans Philip Smith Introduction ============ Recent discussion has shown there is a limited requirement to be able to advertise more specific prefixes from an IPv6 Provider Aggregatable (PA) allocation where a Local Internet Registry (LIR) contains several networks which are not interconnected, or for traffic engineering purposes. This document recommends such advertisements are limited in both length and scope. It is intended to supplement the working group's Recommendations on Route Aggregation [RIPE-399]. Background ========== The IPv6 address allocation and assignment policy for the RIPE region [V6-ALLOC] only allows LIRs to obtain more than the minimum PA allocation if they can demonstrate address utilisation that requires it. This fits with the address space management principle of conservation. However, as understood in the RIPE Routing Working Group's Recommendations on Route Aggregation [RIPE-399], there are occasionally requirements for the advertisement of more specific routes from within an allocation. With a few ISPs currently filtering at the minimum PA allocation (/32) within the relevant address ranges, this can cause significant difficulties for some networks wishing to deploy IPv6. Some reasons for wanting to advertise multiple prefixes from a PA allocation could be: - The LIR has several networks that are not interconnected. - Traffic engineering: A single prefix that covers an LIR's entire customer base may attract too much traffic over a single peering link This document is only concerned with IPv6 Provider Aggregatable (PA) allocations, and does not discuss Provider Independent (PI) prefixes. Recommendation ============== It is suggested that prefix filters allow for prudent subdivision of an IPv6 allocation. The operator community will ultimately decide what degree of subdivision is supportable, but the majority of ISPs accept prefixes up to a length of /48 within PA space. Advertisement of more specific prefixes should not be used unless absolutely necessary and, where sensible, a covering aggregate should also be advertised. Further, LIRs should use BGP methods such as NO_EXPORT [RFC-1997], [AS-PATHLIMIT], or provider-specific communities, as described in [RIPE-399] to limit the propagation of more specific prefixes in the routing table. Discussion ========== There is a valid need for some LIRs to advertise more than one IPv6 PA prefix. As either obtaining more address space and advertising more /32 prefixes, or advertising more specific prefixes within an already allocated /32 have the same impact on the routing table, it is suggested that the latter approach is taken to prevent address space wastage. It is understood that this may not cover all possibilities. There may be circumstances where sites will have to consider the suitability of Provider Independent addresses, or LIRs may have to consider mechanisms of obtaining more than a /32 of Provider Aggregatable space. References ========== [V6-ALLOC] http://www.ripe.net/ripe/docs/ipv6policy.html [RIPE-399] http://www.ripe.net/ripe/docs/ripe-399 [RFC-1997] http://www.rfc-editor.org/rfc/rfc1997.txt [AS-PATHLIMIT] http://tools.ietf.org/html/draft-ietf-idr-as-pathlimit-03 Work in Progress.