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 <[email protected]> wrote: > > > On Thu, May 16, 2019 at 1:20 PM Sander Steffann <[email protected]> > 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:[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 > =============================================== >
