I'm tightening up some network-edge filters, and in the process of testing filtering with IPv6, I found that there is a lot of ICMP link-local (fe80::) to ff02:: activity at an IX. Is any of this necessary? I am wary of over-filtering that cuts down functionality and doesn't increase security. What of the IANA-reserved IPv6 addresses can be safely blocked on ingress/egress at the network edge?
Hey,
I'm tightening up some network-edge filters, and in the process of testing filtering with IPv6, I found that there is a lot of ICMP link-local (fe80::) to ff02:: activity at an IX. Is any of this necessary? I am wary of over-filtering that cuts down functionality and
Dunno, ff02::1 would be very necessary (i.e. ND), ff02:: I have no idea. But you should do yourself favor, before you drop ICMP packets, allow ND: set from next-header icmp6 set from icmp-type router-solicit set from icmp-type router-advertisement set from icmp-type neighbor-solicit set from icmp-type neighbor-advertisement set from hop-limit 255 set then count icmp:nd set then accept It doesn't really matter how many times this is mentioned on how many forums, people will continue to break IPV6 ND by filtering it incorrectly. I regularly have customers complaining we've broken IPV6, when ND stops working, due to implementation change in our end using different combinations of GUA/LL than what their filter permits. And customers often remain unconvinced, offering 'it works on N other providers just fine'. IPv6 is too hard, we don't understand how ND works. -- ++ytti
On 3/16/21 17:15, Saku Ytti wrote:
Dunno, ff02::1 would be very necessary (i.e. ND), ff02:: I have no idea. But you should do yourself favor, before you drop ICMP packets, allow ND:
Not that you should see it over an exchange point, but LDPv6 runs over ff02::2. In case that's your style, be careful not break that on your core-facing side. Mark.
Hi, You can check special ipv6 registry from to drop/filter at transit/peering connections: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specia... https://ipgeolocation.io/resources/bogon.html ::/128Node-scope unicast unspecified address ::1/128Node-scope unicast loopback address ::ffff:0:0/96IPv4-mapped addresses ::/96IPv4-compatible addresses 100::/64Remotely triggered black hole addresses fc00::/7Unique local addresses (ULA) fe80::/10Link-local unicast fec0::/10Site-local unicast (deprecated) ff00::/8Multicast (Note: ff0e:/16 is global scope and may appear on the global internet.) 2001:10::/28Overlay routable cryptographic hash identifiers (ORCHID) -->depreceated 2001:20::/28Orchidv2 2001:db8::/32Documentation prefix 2001::/32Teredo 2001:2::/48Benchmarking But you should be careful with ND & and link-local addresses like Pete mentioned. And i think it is good practice to drop IP traffic sourced with your own IP addresses against spoofing (unless you have remote sites with your own addresses etc.) 2001::/23 IETF protocol assignments, be careful with what you drop inside this block also. -----Original Message----- From: NANOG <nanog-bounces+ercin.torun=turkcell.com.tr@nanog.org> On Behalf Of Saku Ytti Sent: Tuesday, March 16, 2021 6:16 PM To: Pete Ashdown <pashdown@xmission.com> Cc: nanog@nanog.org Subject: [EXTERNAL]:Re: IPv6 filtering at network edge? Hey,
I'm tightening up some network-edge filters, and in the process of testing filtering with IPv6, I found that there is a lot of ICMP link-local (fe80::) to ff02:: activity at an IX. Is any of this necessary? I am wary of over-filtering that cuts down functionality and
Dunno, ff02::1 would be very necessary (i.e. ND), ff02:: I have no idea. But you should do yourself favor, before you drop ICMP packets, allow ND: set from next-header icmp6 set from icmp-type router-solicit set from icmp-type router-advertisement set from icmp-type neighbor-solicit set from icmp-type neighbor-advertisement set from hop-limit 255 set then count icmp:nd set then accept It doesn't really matter how many times this is mentioned on how many forums, people will continue to break IPV6 ND by filtering it incorrectly. I regularly have customers complaining we've broken IPV6, when ND stops working, due to implementation change in our end using different combinations of GUA/LL than what their filter permits. And customers often remain unconvinced, offering 'it works on N other providers just fine'. IPv6 is too hard, we don't understand how ND works. -- ++ytti <p></p> [https://s.turkcell.com.tr/SiteAssets/Genel/mail/mail-imza.jpg] <https://www.turkcell.com.tr/pasaj?utm_source=email&utm_medium=imza&utm_campaign=tanitim> Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir. TURKCELL bu mesajin icerdigi bilgilerin doğruluğu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve TURKCELLin goruslerini yansitmayabilir Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. ________________________________ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TURKCELL. This e-mail has been scanned for all known computer viruses.
participants (4)
-
ERCIN TORUN -
Mark Tinka -
Pete Ashdown -
Saku Ytti