On Fri, May 17, 2019 at 6:38 AM Gert Doering <[email protected]> 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:[email protected] 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 ===============================================
