On Mon, Jun 18, 2018 at 4:28 PM, Job Snijders <[email protected]> wrote:
> Dear working group,
>
> Feedback welcome - should 2002::/16 still be accepted in the DFZ?
>
> Kind regards.
>
> Job
>
> ---------- Forwarded message ---------
> From: Job Snijders <[email protected]>
> Date: Mon, 18 Jun 2018 at 23:08
> Subject: Time to add 2002::/16 to bogon filters?
> To: NANOG [[email protected]] <[email protected]>
>
>
> Dear all,
>
> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
>
> It is kind of strange that in the default-free zone (where we don’t
> announce defaults to each other) - we will propagate what is effectively an
> IPv4 default-route, in the IPv6 DFZ.
>
> IETF has politely abandoned the prefix:
> https://tools.ietf.org/html/rfc7526
>
RFC7526 most certainly does not deprecate or abandon the prefix 2002::/16.
>From Section 4 of RFC7526;
This document formally deprecates the anycast 6to4 transition mechanism
defined in [RFC3068] and the associated anycast IPv4 address 192.88.99.1.
...
The basic unicast 6to4 mechanism defined in [RFC3056] and the
associated 6to4 IPv6 prefix 2002::/16 are not deprecated.
>
> Wes George highlighted operational problems from accepting 2002::/16 on
> the data-plane slide 6:
> http://iepg.org/2018-03-18-ietf101/wes.pdf
>
I don't see a slide 6, slide 5 proposes to "Reject DNS queries from
2002::/16 and just let it fall back to IPv4." That seems reasonable to me
because by definition a 6to4 host should have IPv4 connectivity, and doing
DNS over 6to4 seems like a really bad idea even if 6to4 is working for you.
However, it's a long way from completely bogonising 2002::/16
> Is there still really any legit reason left to accept, or propagate,
> 2002::/16 on EBGP sessions in the DFZ?
>
Section 6 of RFC7526 has several recommendations, filtering 2002::/16 is
not generally one of them. However, if your customers are not using 6to4 at
all, then filtering 2002::/16 probably won't hurt anything. But that is not
the same thing as saying that 2002::/16 is a bogon in all situations, and
that is not supported by RFC7526. If you have other data to support
bogonising 2002::/16 I'm happy to listen.
>
> Kind regards,
>
> Job
>
--
===============================================
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
===============================================
