On 3/8/23 6:17 AM, Victor Kuarsingh wrote:
This was the intention of the RFC. As this space was intended to be used with an AS's network to service CGN needs. That CGN boundary likely ends before a given customer and/or neighboring network, so it would make sense that downstream and neighboring networks would filter at their borders.
Trying to block RFC6598 at the host level can potentially be problematic as the network that host is connected to may be using RFC6598 space. If a provider did not seek my consent before sending me non-globally routed traffic I would consider such traffic to be invalid ~> bogon and assume that replies thereto wouldn't make it back to the client and
I would assume ~> expect that any operator of a system being deployed with a globally routed IP to be well aware if there system was expected to handle non-globally routed IPs or not. E.g. at $DAY_JOB we /explicitly/ configured systems to allow ~> support non-globally routed IPs from RFC 6598 Shared Address Space et al. clients. Either you're outside of the CGN context or you are explicitly aware that you are inside of the CGN context. Or said another way - either you're only communicating with the globally routed Internet -- thus no non-globally routed IPs -- or your are explicitly aware that you may be communicating with non-globally routed IPs. treat it like the errant configuration that -- I believe -- it is.
It is true an ISP's network would be part of the Internet, but the part which is servicing CGN zones would not part of the generally reachable part of the Internet (inbound, all ports, all protocols). The CGN zone within the ISP network is as much part of the Internet as a home network would be (non-routable addresses used to service an upstream NAT).
I think that anything that has a non-globally routed IP has "access to the Internet". Conversely to be "on the Internet" requires a globally routed IP address. I believe "the CGN zone ... home network" qualify as "access to the Internet" and very. -- Grant. . . . unix || die