Folks, as we over-ran this morning, we will be having a second session at 10am Lisbon time in the same room (Floriana III) tomorrow (Friday) morning. The only topic will be IPv6 routing recommendations. I apologise to those of you for whom this clashes with travel plans or ENUM, but the agenda is always subject to change, and the chairs felt this was better than to try to rush the discussion during the coffee break (and we were, briefly, scheduled to be on Friday morning anyway). As a reminder, I attach the current draft of the document. Rudiger has already commented that he believes it should use the word 'deaggregation' less. Jerome from RENATER has also explained that it doesn't cover his requirements which are to break up an aggregatable block even further. The current draft of the (basic) slides is here: <http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads//presentations/Thursday/Routing%20WG/Evans-IPv6_Routing_Recommendations.HfIV.pdf> I hope to see you tomorrow. 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 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.