IPv6 ingress filtering

[David Farmer]

On Fri, May 17, 2019 at 6:38 AM Gert Doering <gert at space.net> wrote:

> Hi,
>
> On Thu, May 16, 2019 at 01:51:51PM -0700, Nick Buraglio wrote:
> > 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".
>
> Filtering it would allow the client to fall back to IPv4, instead of
> letting it go onward with poor IPv6.
>
> Unless you run a local relay you'll be hard pressed today to find any
> case where 2002:: to *non* 2002:: traffic won't be significantly worse
> than "just do IPv4" (in terms of "latency", "reliability", "packet loss").
>
> 2002:: to 2002:: is usually OK, as it follows the IPv4 path between
> both sides (thus, same latency, packet loss, etc).
>

A few questions;

Are you generating ICMPv6 toward non-2002::/16 sources for traffic destined
to 2002::/16?
Are you generating ICMPv6 toward 2002::/16 source for traffic destined to
non-2002::/16?
For the later, where are you getting the route for 2002::/16 from?

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: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20190517/1e994ddc/attachment.htm>