IPv6 ingress filtering

[David Farmer]

On Tue, May 14, 2019 at 11:22 AM Amos Rosenboim <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>
> 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 en nombre de
> 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 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
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: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20190514/a425c176/attachment.htm>