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

Wed Mar 8 22:28:30 UTC 2023

> On 9 Mar 2023, at 08:41, William Herrin <bill at herrin.us> wrote:
> 
> 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/

Correct, you can’t use 100.64/10 for any service expected to be reached
by customers.  CPE shouldn’t see traffic from 100.64/10 with the possible
exception of ICMP ERROR messages. Even advertising a 100.64/10 address as
next hop is problematic for dual homing CPE.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org