RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

Wed Mar 8 21:41:45 UTC 2023

On Wed, Mar 8, 2023 at 4:35 AM Lukas Tribus <lukas at 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/