IPv6 ingress filtering

[Nick Buraglio]

Native IPv6 is clearly the right way to implement the service. However, my
question is "why filter 2002::/16?". It doesn't pose any more risk than a
native IPv6 address and there are some reasons to use it. Filtering it is
wrought with the possibilities for poor customer experience. My stance is
typically "don't filter $stuff unless you can identify a well defined
risk".

nb


On Thu, May 16, 2019 at 11:34 AM David Farmer <farmer at umn.edu> wrote:

>
>
> On Thu, May 16, 2019 at 1:20 PM Sander Steffann <sander at steffann.nl>
> wrote:
>
>> Hi David,
>>
>> > While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and
>> RFC 7526 is quite clear that 2002::/16 is still valid. However, it is
>> perfectly permissible to filter it, if that is the policy a network
>> operator wishes to enforce.
>>
>> With the 6to4 anycast relays deprecated the only 6to4 traffic should be
>> src 2002::/16 and dst 2002::/16. Sites that are not using 6to4 themselves
>> can filter 2002::/16. Everybody else will only see IPv4+proto41 traffic,
>> which is not impacted by that filter.
>>
>
> NO! RFC3056 Includes a gateway functionality it is just not Anycast.  It
> is possible to locally gateway traffic to native IPv6 and then you would
> get traffic sourced from 2002::/16 and then you need to send traffic to a
> return gateway.  Now, most traffic you are seeing is probably coming from
> the public anycast gateways that are still running, but it doesn't have to
> be. As I said elsewhere in the thread, it complicated and filtering is
> easy. Read RFC7526 very carefully, if you care, if you don't just filter it.
>
> Thanks
> --
> ===============================================
> 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: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20190516/d71f9c3b/attachment.html