BCP38 considerations in IPv6
Hello NANOGers - What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? Ryan
In message <acd7c570039e58b67bbf64e467f4b12b@192.168.152.50>, Ryan Rawdon writes :
Hello NANOGers -
What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6?
Ryan
You should definitely make sure you block ULA prefixes leaving your site by default. e.g. add unreach admin all from any to fc00::/7 via gif0 add unreach admin all from fc00::/7 to any via gif0 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10 feb 2011, at 22:34, Ryan Rawdon wrote:
What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6?
There's a lot of language in the RFCs about this type of addresses not being forwarded by routers, so filtering shouldn't be necessary. I know that Cisco lets neighbor discovery through before the implicit deny is applied, so specifically allowing link locals for neighbor discovery isn't necessary either. (I would assume other vendors do the same, but it's of course a good idea to check.) The only time you have to be careful is when you do a deny all, because you need neighbor discovery unless you use static neighbor cache entries. ND also uses multicast, so you need to let that through as appropriate, too.
On Thu, 10 Feb 2011, Ryan Rawdon wrote:
What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6?
That's a consideration, and one other candidate which has already been welcomed to my black-hole server: 2001:DB8::/32. I'll leave that as an exercise to everyone to see who's block that is. :-) wfms
On Thu, 10 Feb 2011, Ryan Rawdon wrote:
Hello NANOGers -
What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6?
Have look at some icmpv6 consideration in RFC 4890. Regards, Janos
participants (5)
-
Iljitsch van Beijnum -
Mark Andrews -
Mohacsi Janos -
Ryan Rawdon -
William F. Maton Sotomayor