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.