Closed sleevi closed 3 years ago
That sounds like a great idea. I'll amend the spec.
I went through the IPv4 registry to see how the above proposal would play out concretely.
Here are the special-use registrations classified by address space:
local
:
private
:
public
:
I'll want to dig into a few of these a bit more to understand whether the classifications make sense, but on a surface level they look good :)
I think it's noteworthy that this will classify things like TEST-NET-1 as local
; so if a private network uses these (in violation of the RFC?), that would allow the network to gain access to 127.0.0.1
?
If addresses of the same type are allowed to interact freely, then local
must be restricted to addresses that operating systems won't route onto the network (independent of what the router tells the local machine about the private network).
That's fair, and simple enough to fix. How about this alternate definition?
local
if:
127.0.0.0/8
subnet::1
private
if Globally Reachable
is Falsepublic
It hardcodes the IPv4 and IPv6 loopback addresses, but otherwise defers to the registry for private
vs public
distinctions?
I think that sounds reasonable.
It just happens to match the current implementation in Chromium too! :tada:
I'll see how it plays out with the IPv6 special-use registry.
Here's the classification of the IPv6 special-use registry assignments according to the rules laid out in comment https://github.com/WICG/cors-rfc1918/issues/30#issuecomment-728980926.
private
:
The following assignments have a Globally Reachable
value of N/A
... Not sure what to do with those.
public
:
We might want to make an exception for IPv4-mapped addresses, and instead consider the address space of the embedded IPv4 address?
A strict reading of https://github.com/WICG/cors-rfc1918/issues/30#issuecomment-728980926 yields that both TEREDO an 6to4 should be considered public
, as their Globally Reachable
bit is not explicitly False
. I think this makes sense as a default stance, since it gives less privileges to such IP addresses.
I'll amend the algorithm to handle the IPv4-IPv6 mapped addresses: in that case, apply the algorithm to the encapsulated IPv4 address.
Will send a PR to fix the spec.
Fixed by #31.
This is a subset of issue #28 , and addresses the Carrier Grade NAT / Special Use address.
Presently, the spec states:
However, the "source of truth" for these reservations is the relevant IANA registry, which captures all of the relevant reservations (such as what @thejh raised with RFC6598)
With this approach, the following rules should give equivalent results, but support the full spectrum of reserved allocations
This isn't perfect, as there are still reserved address spaces that would be treated as public.
However, this also matches Chrome's current implementation, and would cover the situation raised in Issue #28 regarding VMs