RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)
gtaylor at tnetconsulting.net
Wed Mar 8 18:13:20 UTC 2023
On 3/8/23 5:35 AM, Lukas Tribus 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
I argue that Alice should expect to not receive any traffic from
non-globally routed IPs UNLESS her cloud provider has informed her that
she should expect them.
I'd say that they shouldn't send them to her without her acknowledgement
~> consent to receive them.
> - 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.
Nothing prevents someone from filtering bogons without using RFC 6598 as
justification to do so.
I suspect that there are many people using DFZ feeds that are in effect
filtering bogons and they likely aren't using RFC 6598 as justification.
> 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
As long as the ISP is not duplicating* subnets in their network, then
traffic will pass through links to / from the end user without any
problem. This is predicated on traffic being from the end user's IP and
a globally routed IP. Traffic from 100.64.64.100/24 to 22.214.171.124/24 will
pass through a link using 100.64.100.100/24 without any problem.
The ISP could even duplicate subnets in their network segments that
don't need to communicate with each other, like point to point links.
E.g. R1 & R2 can use 10.10.10.10/31 .11 and R3 & R4 can use the same IPs
without effecting transit traffic as long as said traffic /is/ transit
and not to / from said prefix. The fact that R1 & R2 can't communicate
with R3 nor R4 using said prefix is not an operational problem for
transiting traffic. It is probably quite annoying for the ISP and as
> 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
Both parties can use addresses reserved for the other party. They just
need to be aware of potential problems in doing so.
> Of course a customer can configure 126.96.36.199/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.
Remember, IP addresses / subnets are *locally* *significant*. As long
as you are aware of the scope of /locally/ and how it interacts with
things, then do whatever you want. Just be aware of potential foot
guns. There is such a thing as being overly clever when it comes to
supporting things. But if it works, and you want to support it, then
have a ball and route traffic however you want.
Aside: This is also predicated on interaction between the customer
traffic and the ISP's management traffic. Overlays tend to really
negate this issue and allow the ISP to (re)use any IPs they want as long
as it's in a different routing domain.
> 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.
I would expect -- nay /demand/ -- that any ISP sending traffic to a
co-lo customer from a non-globally routed IP to have said co-lo
customer's consent before doing so.
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
More information about the NANOG