IPv6 ingress filtering

Amos Rosenboim amos at oasis-tech.net
Wed May 15 06:33:07 CEST 2019


Hi,

All the mentioned reasons for filtering were focused on the performance of 6to4, user experience and so on.
As our users get native IPv6 they are probably not impacted by these problems when accessing interactive services.
If they are serving or getting the latest episode of GoT from other users who are using 6to4 I see no reason to interfere.

Thanks for all the advice.

Amos

Sent from my iPhone

On 15 May 2019, at 00:21, David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:



On Tue, May 14, 2019 at 11:22 AM Amos Rosenboim <amos at oasis-tech.net<mailto:amos at oasis-tech.net>> wrote:
Let me just clarify few points:
The suggested filter is not for the protocol, but for the 2002::/16 address space.

Also the traffic I am seeing is between addresses  within this prefix to addresses of our native IPv6 users.

As for policy - we tend to be as permissive as we can, and we certainly wouldn't like to restrict what is left from p2p apps.

If you don't filter traffic for 2002::/16 I would suggest you pay attention to the route you are accepting for 2002::/16. Maybe you shouldn't accept a route for this from an ASN on another continent or maybe just run your own gateway for this function. Oh, and if you run your own gateway you, and your peers and providers, may need to allow traffic sourced from 192.88.99.1 to leave your network, depending on the gateway software you use.

If you do filter traffic for 2002::/16 you probably shouldn't accept a route for 2002::/16 either.

Doing this right is complicated, filtering it is easy. While I personally don't filter 2002::/16, I also don't condemn anyone that does filter it, there are good arguments on both sides.

Amos

Sent from my iPhone

On 14 May 2019, at 18:50, JORDI PALET MARTINEZ <jordi.palet at consulintel.es<mailto:jordi.palet at consulintel.es>> wrote:

Hi Marc,

I don't agree. There are many users with tunnel brokers that use 6in4. If you filter 6to4 as a protocol, you're also filtering all those users' traffic.

Not everybody is lucky enough to have native IPv6 support from its ISP.

Saludos,
Jordi



El 14/5/19 17:46, "Marc Blanchet" <ipv6-ops-bounces+jordi.palet=consulintel.es at lists.cluenet.de<mailto:ipv6-ops-bounces+jordi.palet=consulintel.es at lists.cluenet.de> en nombre de marc.blanchet at viagenie.ca<mailto:marc.blanchet at viagenie.ca>> escribi?:


6to4 has been a good transition technology to help deploy IPv6 in the early days. However, it has intrinsically bad latency issues as its routing is based on the underlying IPv4, which can be pretty bad for non 6to4 destinations (e.g. normal IPv6 addresses). Moreover, its IPv6 in IPv4 tunnelling technology is likely to be filtered by various intermediate devices in the path. My take is that we shall declare 6to4 over and dead, thank you very much for your service. So I would suggest to filter it. If not, users may get latency issues that will go into support calls unncessarily.

Marc.

On 14 May 2019, at 11:24, Amos Rosenboim wrote:
Hello,


As we are trying to tighten the security for IPv6 traffic in our network, I was looking for a reference IPv6 ingress filter.
I came up with Job Snijders suggestion (thank you Job) that can be conveniently found at whois -h whois.ripe.net<http://whois.ripe.net> fltr-martian-v6

After applying the filter I noticed some traffic from 6to4 addresses (2002::/16) to our native IPv6 prefixes (residential users in this case).
The traffic is a mix of both UDP and TCP but all on high port numbers on both destination and source.
It seems to me like some P2P traffic, but I really can't tell.

This got me thinking, why should we filter these addresses at all ?
I know 6to4 is mostly dead, but is it inherently bad ?

And if so, why is the prefix (2002::/16) still being routed ?

Thanks,

Amos Rosenboim
--


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



--
===============================================
David Farmer               Email:farmer at umn.edu<mailto:Email%3Afarmer at umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20190515/2757a8f1/attachment.html 


More information about the ipv6-ops mailing list