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
I disagree.
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 customers.
I disagree. 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 8.8.8.8/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 such discouraged.
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 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.
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