[123814] in North American Network Operators' Group
IPv6 filtering practices (Was: IPv6, multihoming,
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Tue Mar 16 10:59:52 2010
Date: Tue, 16 Mar 2010 15:58:49 +0100
From: Jeroen Massar <jeroen@unfix.org>
To: Rick Ernst <nanog@shreddedmail.com>
In-Reply-To: <d066472f1003160738m50708743q8d49ef36d1aa7a68@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF706FAE634C39CB009F15022
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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" (wi=
dely
> 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
* =3D 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.
--------------enigF706FAE634C39CB009F15022
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
iEYEARECAAYFAkufnK0ACgkQKaooUjM+fCMbrACdGusB694w6fsUdQhzKvhtpZQG
CjAAoJyJR1FGJuyVXJvdjueQtSp9HqT5
=d1kB
-----END PGP SIGNATURE-----
--------------enigF706FAE634C39CB009F15022--
