Assuming that RFC1918 addresses mean "local" network is wrong. It means "private". Many large enterprises use RFC1918 for private, internal web sites.
One internal site I spend hours a day using has a 10.x.x.x IP address. The servers for that site are on the other side of the country and are many network hops away. It's a big company, our corporate network is very very large.
A better definition of "local IP" would be whether the IP is in the same subnet as the client, i.e. look up the client's own IP and subnet mask and determine if a packet to a given IP would need to be routed through the default gateway.
The article spends a lot of effort defining the words "local" and "private" here. It then says:
> Note that local -> local is not a local network request
So your use case won't be affected.
The computer I use at work (and not only mine, many many of them) has a public IP address. Many internal services are on 10.0.0.0/8. How is this being taken into account?
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are all private addresses per RFC1918 and documents superseding it(5735?). If it's like 66.249.73.128/27 or 164.13.12.34/12, those are "global" IP.
1: https://www.rfc-editor.org/rfc/rfc1918
Yes that's the point: many of our work PCs have global public IPs from something like 128.130.0.0/15 (not this actual block, but something similar), and many internal services are on 10.0.0.0/8. I'm not sure I get exactly how the proposal is addressing this. How does it know that 128.130.0.0/15 is actually internal and should be considered for content loaded from an external site?
The proposal doesn't need to address this because it doesn't even consider the global public IP of 128.130.0.0/15 in your example. If you visit a site on 10.0.0.0/8 that accesses resources on 10.0.0.0/8 it's allowed. But if you visit a random other site on the internet it will be (by default) forbidden to access the internal resource at 10.0.0.0/8.
My reading is this just adds a dialog box before browser loads RFC1918 ranges. At IP layer, a laptop with 128.130.0.123 on wlan0 should not be able to access 10.0.10.123:80, but I doubt they bother to sanity check that. Just blindly assuming all RFC1918 and only RFC1918 are local should do the job for quite a while.
btw, I've seen that kind of network. I was young, and it took me a while to realize that they DHCP assign global IPs and double NAT it. That was weird.
Your computer's own IP address is completely irrelevant. What matters is the site hostname and the IP address it resolves to.
People believe that "my computer" or "my smartphone" has an Internet address, but this is a simplification of how it's really working.
The reality is that each network interface has at least one Internet address, and these should usually all be different.
An ordinary computer at home could be plugged into Ethernet and active on WiFi at the same time. The Ethernet interface may have an IPv4 address and a set of IPv6 addresses, and belong to their home LAN. The WiFi adapter and interface may have a different IPv4 address, and belongs to the same network, or some other network. The latter is called "multi-homing".
If you visit a site that reveals your "public" IP address(es), you may find that your public, routable IPv4 and/or IPv6 addresses differ from the ones actually assigned to your interfaces.
In order to be compliant with TCP/IP standards, your device always needs to respond on a "loopback" address in 127.0.0.0/8, and typically this is assigned to a "loopback" interface.
A network router does not identify with a singular IP address, but could answer to dozens, when many interface cards are installed. Linux will gladly add "alias" IPv4 addresses to most interface devices, and you'll see SLAAC or DHCPv6 working when there's a link-local and perhaps multiple routable IPv6 addresses on each interface.
The GP says that their work computer has a [public] routable IP address. But the same computer could have another interface, or even the same interface has additional addresses assigned to it, making it a member of that private 10.0.0.0/8 intranet. This detail may or may not be relevant to the services they're connecting to, in terms of authorization or presentation. It may be relevant to the network operators, but not to the end-user.
So as a rule of thumb: your device needs at least one IP address to connect to the Internet, but that address is associated with an interface rather than your device itself, and in a functional system, there are multiple addresses being used for different purposes, or held in reserve, and multiple interfaces that grant the device membership on at least one network.
Ideally, in an organization this should be a centrally pushed group policy defining CIDRs.
Like, at home, I have 10/8 and public IPv6 addresses.
As far as I understand that doesn't matter. What matters is the frame's origin and the request.
Is it a gross generalization to say that if you're visiting a site whose name resolves to a private IP address, it's a part of the same organizational entity as your computer is?
The proposal here would consider that site local and thus allowed to talk to local. What are the implications? Your employer whose VPN you're on, or whose physical facility you're located in, can get some access to the LAN where you are.
In the case where you're a remote worker and the LAN is your private home, I bet that the employer already has the ability to scan your LAN anyway, since most employers who are allowing you onto their VPN do so only from computers they own, manage, and control completely.
> Is it a gross generalization to say that if you're visiting a site whose name resolves to a private IP address, it's a part of the same organizational entity as your computer is?
Yes. That's a gross generalization.
I support applications delivered via site-to-site VPN tunnels hosted by third parties. In the Customer site the application is accessed via an RFC 1918 address. It is is not part of the Customer's local network, however.
Likewise, I support applications that are locally-hosted but Internet facing and appear on a non-RFC1918 IP address even though the server is local and part of the Customer's network.
Access control policy really should be orthogonal to network address. Coupling those two will enivtably lead to mismatches to work around. I would prefer some type of user-exposed (and sysadmin-exposed, centrally controllable) method for declaring the network-level access permitted by scripts (as identified by the source domain, probably).
Don't some internet providers to large scale NAT (CGNAT), so customers each get a 10.x address instead of a public one? I'm not sure if this is a problem or not. It sounds like it could be.
It wouldn’t be important in this scenario, because what your own IP address is doesn’t matter (and most of us are sitting behind a NAT router too, after all).
It would block a site from scanning your other 10.x peers on the same network segment, thinking they’re “on your LAN” but that’s not a problem in my humble opinion.
Many years ago, before it was dropped, IP version 6 had a concept of "site local" addresses, which (if it had applied to version 4) would have encompassed the corporate intranet addresses that you are talking about. Routed within the corporate intranet; but not routed over corporate borders.
Think of this proposal's definition of "local" (always a tricky adjective in networking, and reportedly the proposers here have bikeshedded it extensively) as encompassing both Local Area Network addresses and non-LAN "site local" addresses.
fd00::/8 (within fc00::/7) is still reserved for this purpose (site-local IPv6 addressing).
fc00::/8 (a network block for a registry of organisation-specific assignments for site-local use) is the idea that was abandoned.
Roughly speaking, the following are analogs:
169.254/16 -> fe80::/64 (within fe80::/10)
10/8, 172.16/12, 192.168/16 -> a randomly-generated network (within fd00::/8)
For example, a service I maintain that consists of several machines in a partial WireGuard mesh uses fda2:daf7:a7d4:c4fb::/64 for its peers. The recommendation is no larger than a /48, so a /64 is fine (and I only need the one network, anyway).
fc00::/7 is not globally routable.
So in my case, I guess I need to blame the unconfigurable cable router my ISP provided me with? Since there's no way to provide reservations for IPv6 addresses. :-/
Right. OpenWRT, for example, will automatically generate a random /48 within fd00::/8 to use as a ULA (unique local addressing) prefix for its LAN interfaces, and will advertise those prefixes to its clients. You can also manually configure a specific prefix instead.
e.g. Imagine the following OpenWRT setup:
ULA: fd9e:c023:bb5f::/48
(V)LAN 1: IPv6 assignment hint 1, suffix 1
(V)LAN 2: IPv6 assignment hint 2, suffix ffff
Clients on LAN 1 would be advertised the prefix fd9e:c023:bb5f:1::/64 and automatically configure addresses for themselves within it. The router itself would be reachable at fd9e:c023:bb5f:1::1.
Clients on LAN 2 would be advertised the prefix fd9e:c023:bb5f:2::/64 and automatically configure addresses for themselves within it. The router itself would be reachable at fd9e:c023:bb5f:2::ffff.
Clients on LAN 1 could communicate with clients on LAN 2 (firewall permitting) and vice versa by using these ULA addresses, without any IPv6 WAN connectivity or global-scope addresses.