On Fri, May 17, 2019 at 6:38 AM Gert Doering <gert@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@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
===============================================
> 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@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
===============================================
