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

[Grant Taylor via NANOG <nanog () nanog org>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature