[routing-wg] Fwd: Time to add 2002::/16 to bogon filters?
- Previous message (by thread): [routing-wg] Fwd: Time to add 2002::/16 to bogon filters?
- Next message (by thread): [routing-wg] New on RIPE Labs: Measuring the Adoption of RPKI Route Origin Validation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
David Farmer
farmer at umn.edu
Tue Jun 19 01:15:44 CEST 2018
On Mon, Jun 18, 2018 at 4:28 PM, Job Snijders <job at ntt.net> wrote: > Dear working group, > > Feedback welcome - should 2002::/16 still be accepted in the DFZ? > > Kind regards. > > Job > > ---------- Forwarded message --------- > From: Job Snijders <job at ntt.net> > Date: Mon, 18 Jun 2018 at 23:08 > Subject: Time to add 2002::/16 to bogon filters? > To: NANOG [nanog at nanog.org] <nanog at nanog.org> > > > 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: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.ripe.net/ripe/mail/archives/routing-wg/attachments/20180618/0ff383db/attachment.html>
- Previous message (by thread): [routing-wg] Fwd: Time to add 2002::/16 to bogon filters?
- Next message (by thread): [routing-wg] New on RIPE Labs: Measuring the Adoption of RPKI Route Origin Validation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]