Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed

Robin Whittle wrote:
[..]
> Is there some formal or informal agreement not to accept
> advertisements for prefixes longer than /48?  I know
> there is such a rule for IPv4 (/24) but am not sure if it is
> formalised anywhere.

Yes there is. In general a /48 is seen as 'the smallest chunk of
globally routeable address space'.

Most ISP's and transits follow Gert Doerings filter recommendations:
http://www.space.net/~gert/RIPE/ipv6-filters.html

I suggest that in addition to the above excellent site, take a peek at
http://www.sixxs.net/tools/grh/ as that has a somewhat more complete
view of the IPv6 DFZ getting quite a few feeds from global providers. It
also has a few other tools that give you different abilities. Oh and not
to forget of course that RIPE has the great RIS system
(http://ris.ripe.net) which gives yet another view on all of this.
Depending on what you are looking for, one of those 3 tools can provide
you with the angle you need.

GRH shows that there are even /64's being announced successfully, though
they don't reach to all ISP's.

> If so, then when an end-user gets a /48 of PI space, as per ARIN
> or AfriNIC policies:
> 
>   http://www.arin.net/policy/nrpm.html#six58
>   http://www.afrinic.net/Registration/afsup-ipv6pi-assignments.htm
> 
> I guess this means they can't split this prefix, for instance for
> load balancing in a multihomed situation or for using with two
> offices in different cities or countries which use different
> providers.

They indeed can't as it will be filtered. The whole idea of IPv6 is
aggregation after all.

This is indeed unfortunate as when one wants to do anycast, as for a few
hosts one ends up abusing a /48.

The other problem is indeed when you have a couple of offices or if you
have a number of hosting sites, each needs it's own /48.

> This would mean the end-user needs a separate /48 for
> each physical office in a different city or country.  Can someone
> confirm this?

Separately physical offices are in effect sites, so that is not an issue
at least RIR wise, but one will have to justify that to the RIR. The
issue though are the RIR policies and the force that is applied to it.

Traffic Engineering, BGP and IPv6 in one sentence with a 'small DFZ'
doesn't work unfortunately and this is currently also one of the
deployment problems for IPv6. All the policies are made for ISP's, even
the ARIN PI ones. They expect 1 prefix to be put into a routing slot in
the DFZ, but in effect if you have a /32 you will want to break that up
and not get all the traffic to your main site and then have to reroute
it to another site. With a /32 or up you can break it into /48s most of
the time though and with a /20 you can add a lot of /32's with ease as
those will never be filtered. The RIR game thus seems to be to get a
huge prefix as then you can split it, or go RIR shopping and get one or
multiple prefixes from every RIR (See GRH's DFP pages on that and you
will soon spot who is doing that :).

For Traffic Engineering and other purposes we really will either have to:
 - simply accept that there will be lot of /48's and /64's in the DFZ
or:
 - really quickly come up with an ID/LOC solution that is deployed
   globally.

Greets,
 Jeroen

Re: [RAM] IPv6 /32 to /48 prefixes and Tree-Bitmap FIB speed

Attachment: signature.asc