IPv6 filtering practices (Was: IPv6, multihoming, and customer allocations)
Jeroen Massar
jeroen at unfix.org
Tue Mar 16 14:58:49 UTC 2010
Rick Ernst wrote:
[..]
> I haven't seen anything on the general feel for prefix filtering. I've seen
> discussions from /48 down to /54. Any feel for what the "standard" (widely
> deployed) IPv6 prefix filter size will be?
There have been a lot of discussions on this before.
(See also http://lists.cluenet.de/mailman/listinfo/ipv6-ops)
1) IRR data, use whois.ripe.net to store also your non-RIPE, thus
ARIN,APNIC etc details. This the best place to get your data.
When a prefix is here, accept that size, clearly the ISP intends
to distribute it that way.
2) Allocation size as given by the RIR(*), thus a /32 if the block is
truly a /32 and a /48 when it is a /48.
If you have PI that is PI, if you have PA it is Aggregated by you
the provider, thus don't chop it up into little blocks.
3) Gert Doering's filter recommendations:
http://www.space.net/~gert/RIPE/ipv6-filters.html
Also note that it is your network, accept/reject what you want.
Do remember the little problem that when you accept a /64 from some ISP,
that that prefix has to leak through a lot of little crappy holes to
actually get to you, it is a more specific, but the route might be
really really bad to get there.
As for the /48 vs /56 to end-user discussions, these prefixes are coming
out of PA space and thus should not exist in the DFZ. It is Provider
Aggregated, not PD (Provider Deaggregated) after all.
Greets,
Jeroen
* = Unfortunately it seems that ARIN is giving 1 entity prefixes spread
over multiple blocks, eg four distinct /32's; one can internally
aggregate those of course.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100316/f56c7a52/attachment.sig>
More information about the NANOG
mailing list