bgp filter guide bogon prefixes 192.88.99.0/24
Hi All, First I wanted to thank you for the great bgp filter guide you provide. It is awesome to see crucial information collected and published openly for everyone. I am in the process of implementing more and better filters and while looking over the bogon prefixes v4 I stumbled upon the prefix 192.88.99.0/24 . You cite rfc7562 as a reference for adding this prefix to the bogon list and therefore not accepting this prefix but as far as I can see this the rfc clearly states "Networks SHOULD NOT filter out packets whose source address is 192.88.99.1" . If I do not accept a route to 192.88.99.0/24 I effectively blackhole that network to my customers and block returning packets to 192.88.99.1 from my and my customers networks. I checked other bogon lists that I could find, like team-cymru or kees (https://github.com/coloclue/kees/blob/e353ca9a06bca19147dcc6f607290cfd593033...), who do not include 192.88.99.0/24 in their bogon prefix list. Can you tell me the reasoning behind the decision to include this prefix in your bogon list? Best Regards Julian Julian Lannert Network Engineer e-shelter services GmbH Eschborner Landstraße 100 60489 Frankfurt am Main T: +49 69 7801-2422 F: +49 69 7801-2139 julian.lannert@e-shelter.com www.e-shelter.com Geschäftsführer: Ingmar Dilßner Volker Ludwig Rupprecht Rittweger Florian Winkler Sitz der Gesellschaft: Hattersheim am Main Amtsgericht Frankfurt am Main HRB 77478 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
personal opinion here. On 25/06/2019 10:41, Lannert, Julian wrote:
Can you tell me the reasoning behind the decision to include this prefix in your bogon list?
Reading rfc7526[0] """ 6. Operational Recommendations (...) Internet service providers that do not operate an anycast relay but do provide their customers with a route to 192.88.99.1 SHOULD verify that it does in fact lead to an operational anycast relay (...) 7. IANA Considerations (...) "Deprecated (6to4 Relay Anycast)" and added a reference to this RFC. (...) """ Reading the above. It makes sense to include it since status has changed to deprecated. rfc7526 is from May 2015. Job only recently-ish included 192.88.99.0/24 in the guide (June 2018) [1]. Reading writeup[2] """ Technical Summary (...) It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. (...) """ In the light of 6to4 should be less-and-less supported by newer products. It makes perfect sense to start explicitly blocking the prefix in the DFZ, too. /christoffer [0]: https://tools.ietf.org/html/rfc7526 [1]: https://github.com/NLNOG/bgpfilterguide/commit/488ad78 [2]: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/shepherdw...
Hi all, Thanks for reaching out! It is always enjoyable to see people use the things that we created! :-) Christopher is spot-on. This aspect of global 6to4 anycast experiment has been deprecated, because we've come to learn that relying on 6to4 proved to be a challenge. If you look at IANA's "IPv4 Special Registry" https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... we can confirm that the 192.88.99.0/24 prefix no longer is assigned for the purposes of 6to4. At the time when RFC 7526 was written it was perhaps too early to have IETF consensus on whether recommending or mandating a degree of packet filtering or route filtering the 192.88.99.0/24 prefix. This is why there is a bit of a time gap between the publication of the RFC and me actually recommending to add the prefix to your bogon list. As an anecdotal datapoint: NTT's Global IP Network (AS 2914) added "192.88.99.0/24 le 32" and "2002::/16 le 128" to its bogon filters in June 2018 and has not received any notifications that this posed an issue for any of our customers or partners. See https://seclists.org/nanog/2018/Jun/411 Kind regards, Job On Tue, Jun 25, 2019 at 2:40 PM Hansen, Christoffer <christoffer@netravnen.de> wrote:
personal opinion here.
On 25/06/2019 10:41, Lannert, Julian wrote:
Can you tell me the reasoning behind the decision to include this prefix in your bogon list?
Reading rfc7526[0] """ 6. Operational Recommendations
(...) Internet service providers that do not operate an anycast relay but do provide their customers with a route to 192.88.99.1 SHOULD verify that it does in fact lead to an operational anycast relay (...)
7. IANA Considerations
(...) "Deprecated (6to4 Relay Anycast)" and added a reference to this RFC. (...)
"""
Reading the above. It makes sense to include it since status has changed to deprecated. rfc7526 is from May 2015. Job only recently-ish included 192.88.99.0/24 in the guide (June 2018) [1].
Reading writeup[2] """ Technical Summary
(...) It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. (...) """
In the light of 6to4 should be less-and-less supported by newer products. It makes perfect sense to start explicitly blocking the prefix in the DFZ, too.
/christoffer
[0]: https://tools.ietf.org/html/rfc7526 [1]: https://github.com/NLNOG/bgpfilterguide/commit/488ad78 [2]: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/shepherdw...
Hi Christoffer, Job, All, thanks for the quick feedback. This is exactly the kind of feedback I hoped for to have the right arguments prepared if colleagues/managers do not support activating this filter on our network 😊 Did not think about looking for documentation at IANA which totally makes sense. Also good to hear that as2914 filters the route for a year now and did not encounter any problems. Thanks all for sharing your reasoning! Best Julian -----Original Message----- From: Job Snijders <job@instituut.net> Sent: Tuesday, June 25, 2019 2:59 PM To: Christoffer Hansen <christoffer@netravnen.de> Cc: Lannert, Julian <julian.lannert@e-shelter.com>; NLNOG <nlnog@nlnog.net> Subject: Re: [NLNOG] bgp filter guide bogon prefixes 192.88.99.0/24 Hi all, Thanks for reaching out! It is always enjoyable to see people use the things that we created! :-) Christopher is spot-on. This aspect of global 6to4 anycast experiment has been deprecated, because we've come to learn that relying on 6to4 proved to be a challenge. If you look at IANA's "IPv4 Special Registry" https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... we can confirm that the 192.88.99.0/24 prefix no longer is assigned for the purposes of 6to4. At the time when RFC 7526 was written it was perhaps too early to have IETF consensus on whether recommending or mandating a degree of packet filtering or route filtering the 192.88.99.0/24 prefix. This is why there is a bit of a time gap between the publication of the RFC and me actually recommending to add the prefix to your bogon list. As an anecdotal datapoint: NTT's Global IP Network (AS 2914) added "192.88.99.0/24 le 32" and "2002::/16 le 128" to its bogon filters in June 2018 and has not received any notifications that this posed an issue for any of our customers or partners. See https://seclists.org/nanog/2018/Jun/411 Kind regards, Job On Tue, Jun 25, 2019 at 2:40 PM Hansen, Christoffer <christoffer@netravnen.de> wrote:
personal opinion here.
On 25/06/2019 10:41, Lannert, Julian wrote:
Can you tell me the reasoning behind the decision to include this prefix in your bogon list?
Reading rfc7526[0] """ 6. Operational Recommendations
(...) Internet service providers that do not operate an anycast relay but do provide their customers with a route to 192.88.99.1 SHOULD verify that it does in fact lead to an operational anycast relay (...)
7. IANA Considerations
(...) "Deprecated (6to4 Relay Anycast)" and added a reference to this RFC. (...)
"""
Reading the above. It makes sense to include it since status has changed to deprecated. rfc7526 is from May 2015. Job only recently-ish included 192.88.99.0/24 in the guide (June 2018) [1].
Reading writeup[2] """ Technical Summary
(...) It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. (...) """
In the light of 6to4 should be less-and-less supported by newer products. It makes perfect sense to start explicitly blocking the prefix in the DFZ, too.
/christoffer
[0]: https://tools.ietf.org/html/rfc7526 [1]: https://github.com/NLNOG/bgpfilterguide/commit/488ad78 [2]: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/she pherdwriteup/
participants (3)
-
Hansen, Christoffer -
Job Snijders -
Lannert, Julian