<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 8, 2023 at 7:43 AM Lukas Tribus <<a href="mailto:lukas@ltri.eu">lukas@ltri.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> The think that you have to remember to do is to exclude locally<br>
> significant (100.64/10, RFC 1918, et al.) from those filters /or/<br>
> account for them in another way.<br>
<br>
You know all this if you are the network operator.<br>
<br>
If you are the customer of the ISP, let's say a datacenter/cloud<br>
customer and you are deploying Web or Mailservices, you have no idea<br>
whether this ISP will route RFC6598 traffic to you or not and you<br>
certainly will not get informed by the ISP if that ever changes. You<br>
only know about this once you are dropping production traffic from<br>
clients in 100.64/10 and a trouble ticket has found it's way to you<br>
("residential customers of the same ISP can't reach your cloud<br>
services").<br>
<br>
That is why RFC6598 is suggesting to drop this traffic on autonomous<br>
system borders. The RFC is not suggesting to drop this traffic<br>
elsewhere.<br></blockquote><div><br></div><div>This was the intention of the RFC.  As this space was intended to be used with an AS's network to service CGN needs.  That CGN boundary likely ends before a given customer and/or neighboring network, so it would make sense that downstream and neighboring networks would filter at their borders.  All that said, if for some reason, a downstream network has 100.64/10 assigned to direct links on an interconnection, that may be a problem.  That type of deployment model was not within the intention of RFC6598 (using the block for non-CGN use cases).</div><div><br></div><div>Trying to block RFC6598 at the host level can potentially be problematic as the network that host is connected to may be using RFC6598 space.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> Bogons is just a list of IPs that shouldn't be on the open Internet.<br>
<br>
Which, for RFC6598 is misleading because RFC6598 space is used within<br>
(but not beyond) ISP networks. "The internet" includes ISP networks.<br></blockquote><div><br></div><div>It is true an ISP's network would be part of the Internet, but the part which is servicing CGN zones would not part of the generally reachable part of the Internet (inbound, all ports, all protocols).   The CGN zone within the ISP network is as much part of the Internet as a home network would be (non-routable addresses used to service an upstream NAT).  </div><div><br></div><div>Victor Kuarsingh </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> The Team Cymru bogon's list is a tool and like all tools, it can be<br>
> mis-used and become a foot gun.<br>
<br>
Which is why proper description, documentation and education is important.<br>
<br>
<br>
<br>
Thanks,<br>
Lukas<br>
</blockquote></div></div>