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

Wed Mar 8 12:35:00 UTC 2023

> You'll have to connect the dots for me here, I'm not seeing the
> problem. The ISP's local network is not "the public Internet."

It very much is.

An autonomous system can contain both "eyeballs" (possibly RFC6598
adressed) and services in datacenters/clouds, it's not *always* a
different ISP.

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.

> They can use RFC6598 and even RFC1918 at their leisure.

No, they really can't and shouldn't use RFC1918 in the public part of
their network, because that will conflict with RFC1918 used by
customers.

Which is the entire point of RFC6598: an address space that does NOT
conflict with private deployments, so that it can actually be used by
the ISP.

RFC1918 : the ISP customer gets to assign it
RFC6598 : the ISP get's to assign it

Of course a customer can configure 8.8.8.0/24 or 100.64.25.0/24 on
their LAN, and a ISP can assign 192.168.0.0/16 to an addressing pool.
That is technically possibly and I'm sure there are folks that are
doing it. But it is not a good idea, it's not RFC compliant and will
lead to issues down the road, which is why we have RFC's and BCP's.

> If they choose to place services on those addresses and you
> want to use them, you'll have to exclude them from your
> local filtering and/or your own internal use. For everybody
> else, they're bogons.

I think my example above may clarify this. It's not about services in
RFC6598. It's about services in public IP space, where clients connect
to *from* RFC6598 IPs, which can and does happen when eyeball and
service are in the same ASN/ISP.

Thanks,
Lukas