On Wed, Mar 8, 2023 at 4:35 AM Lukas Tribus <lukas@ltri.eu> wrote:
Perhaps I should have started this topic with a very specific example:
- ISP A has a residential customer "Bob" in RFC6598 space - ISP A CGNATs Bob if the destination is beyond it's own IP space - ISP A doesn't CGNAT if the destination is within its IP space (as explained in the OP, this means reducing state and logging) - ISP A has a cloud customer "Alice" running mail/webservers, which is of course using public IP address space - when Bob access Alice's mail/webserver, the source IP will show RFC6598 addressing - if Alice filters RFC6598, Bob can't connect - Alice should not drop RFC6598, it should threat RFC6598 just like every other public IP subnet - only ISPs (which Alice is not) should drop RFC6598 on its network borders
RFC6598 filters belong on network borders to other autonomous systems, not in a datacenter on a mail/webserver.
Hi Lukas, Thanks for the clarification. As others have said: the error lies in the base conditions of your reasoning, not team-cyrmu's bogon list. The bogon list is designed to be used unmodified at one particular kind of location only: the BGP-speaking link between two different Autonomous Systems. Anywhere else you might choose to use it, you must first exclude or override the filtering for locally used addresses. Perhaps the folks maintaining the bogon list can document the need to exclude locally used addresses when employing it elsewhere, and that for the purposes of the bogons list, "local" includes your immediate ISP. I can see how the latter part of that might not be completely obvious. Regarding the specific example, I'm dubious that ISP A should be presenting Alice with Bob's un-natted 100.64/10 address. The RFC does allow ISP A to use the address space that way, but there have been several discussions here and in the groups where the RFC was first envisioned and debated to the effect that the ISP sending traffic to a customer with source addresses in 100.64/10 would be unwise due to the possibility of overlap and/or filtering issues. The more common example in these debates was ISP A using a 100.64/10 address for a DNS resolver or smtp relay intended to be used by only the downstream customers. The issue with using the addresses that way was that if the downstream customer had more than one ISP, it would be unable to differentiate between ISPs for 100.64/10 destinations. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/