[routing-wg] IPv6 Routing Recommendations.

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.