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

Travis Garrison tgarrison at netviscom.com
Wed Mar 8 21:24:57 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.


We use CGNAT in our network unfortunately. We skip CGNAT for internal resources only, to reduce logging,  load, etc. but all outbound and/or customer to customer traffic goes through the CGNAT. Only public IP addresses are allowed to communicate between customers.


More information about the NANOG mailing list