'Morning all, With my co-chair hat off and on the hat-stand behind me... During the discussion in RIPE 58 and on the address-policy mailing list for 2009-06 ('Removing Routing Requirements from the IPv6 Address Allocation Policy') there was a feeling that there should still be a document that recommends aggregation of announced prefixes. Attached is a first draft of such a document. Please follow up on the routing-wg mailing list with comments and discussion. Thanks, Rob -- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG 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 deaggregate 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 limited deaggregation of an allocation. With many ISPs currently filtering at the minimum PA allocation (/32) within the relevant address ranges, this can cause 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 does not discuss deaggregation of an IPv6 Provider Independent (PI) prefix. Recommendation ============== It is suggested that prefix filters allow for prudent subdivision of an IPv6 allocation. For example, deaggregation of up to at least four bits longer than the minimum PA prefix -- this would mean up to a /36 with the current allocation policy. Obviously longer prefixes can be exchanged with mutual agreement between neighbouring autonomous systems, and the operator community will ultimately decide what degree of subdivision is supportable. Deaggregation 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. The recommendation that a /36 be the minimum size routed is not to be used for any other purpose -- such as address allocation for multihomed customers. Customers of LIRs must still be able to justify address requirements in line with current RIPE policy. 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. The prefix length of /36 has been chosen as it falls on the next 'nibble' boundary which aids readability of addresses and DNS delegation, whilst not allowing uncontrolled growth of the routing table. This figure is, however, somewhat arbitrary and the level of deaggregation that is supportable will be determined by best current practices that emerge from the operator community as IPv6 deployment increases. References ========== [V6-ALLOC] http://www.ripe.net/ripe/docs/ipv6policy.html [RIPE-399] http://www.ripe.net/ripe/docs/ripe-399.html [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.