Define "private" and "local" in terms of properties of the relevant IANA registry

[sleevi]

This is a subset of issue #28 , and addresses the Carrier Grade NAT / Special Use address.

Presently, the spec states:

An IPv4 address is a private address if it matches the private address space defined in Section 3 of [RFC1918], a local address if it matches the "loopback" space (127.0.0.0/8) defined in section 3.2.1.3 of [RFC1122] or the "link-local" space (169.254.0.0/16) defined in [RFC3927], and a public address otherwise.

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

• An address is a local address if Source, Destination, and Globally Reachable are False
• An address is a private address if Globally Reachable is False
• Otherwise, an address is a public address

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

[letitz]

That sounds like a great idea. I'll amend the spec.

[letitz]

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:

  • 127.0.0.0/8: Loopback - RFC1122 Section 3.2.1.3
  • 192.0.0.0/24 (unless overridden below): IETF Protocol Assignments - RFC6890 Section 2.1
  • 192.0.0.170/32, 192.0.0.171/32: NAT64/DNS64 Discovery - RFC8880, RFC7050 Section 2.2
  • 192.0.2.0/24: Documentation (TEST-NET-1) - RFC5737
  • 198.51.100.0/24: Documentation (TEST-NET-2) - RFC5737
  • 203.0.113.0/24: Documentation (TEST-NET-3) - RFC5737
  • 240.0.0.0/4: Reserved - RFC1112

• private:

  • 0.0.0.0/8: "This host on this network" - RFC1122 Section 3.2.1.3
  • 10.0.0.0/8: Private-Use - RFC1918
  • 100.64.0.0/10: Shared Address Space - RFC6598
  • 169.254.0.0/16: Link Local - RFC3927
  • 172.16.0.0/12: Private-Use - RFC1918
  • 192.0.0.0/29: IPv4 Service Continuity Prefix - RFC7335
  • 192.0.0.8/32: IPv4 dummy address - RFC7600
  • 192.168.0.0/16: Private-Use - RFC1918
  • 198.18.0.0/15: Benchmarking - RFC2544
  • 255.255.255.255/32: Limited Broadcast - RFC8190, RFC919 Section 7

• public:

  • 192.0.0.9/32: Port Control Protocol Anycast - RFC7723
  • 192.0.0.10/32: Traversal Using Relays around NAT Anycast - RFC8155
  • 192.31.196.0/24: AS112-v4 - RFC7535
  • 192.52.193.0/24: AMT - RFC7450
  • 192.175.48.0/24: Direct Delegation AS112 Service - RFC7534

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 :)

[thejh]

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).

[letitz]

That's fair, and simple enough to fix. How about this alternate definition?

• An address is local if:
  • it is an IPv4 address in the 127.0.0.0/8 subnet
  • it is an IPv6 address equal to ::1
• Otherwise an address is private if Globally Reachable is False
• Otherwise, an address is public

It hardcodes the IPv4 and IPv6 loopback addresses, but otherwise defers to the registry for private vs public distinctions?

[thejh]

I think that sounds reasonable.

[letitz]

It just happens to match the current implementation in Chromium too! 🎉

I'll see how it plays out with the IPv6 special-use registry.

[letitz]

Here's the classification of the IPv6 special-use registry assignments according to the rules laid out in comment #30 (comment).

private:

• ::/128: Unspecified Address - RFC4291
• ::ffff:0:0/96: IPv4-mapped Address - RFC4291
• 64:ff9b:1::/48: IPv4-IPv6 Translat. - RFC8215
• 100::/64: Discard-Only Address Block - RFC6666
• 2001:2::/48: Benchmarking - RFC5180, RFC Errata 1752
• 2001:db8::/32: Documentation - RFC3849
• fe80::/10: Link-Local Unicast - RFC4291
• 2001::/23: IETF Protocol Assignments - RFC2928 - unless otherwise overridden
• fc00::/7: Unique-Local - RFC4193 RFC8190

The following assignments have a Globally Reachable value of N/A... Not sure what to do with those.

• 2001::/32: TEREDO - RFC4380 RFC8190
• 2002::/16: 6to4 - RFC3056

public:

• 64:ff9b::/96: IPv4-IPv6 Translat. - RFC6052
• 2001:1::1/128: Port Control Protocol Anycast - RFC7723
• 2001:1::2/128: Traversal Using Relays around NAT Anycast - RFC8155
• 2001:3::/32: AMT - RFC7450
• 2001:4:112::/48: AS112-v6 - RFC7535
• 2001:20::/28: ORCHIDv2 - RFC7343
• 2620:4f:8000::/48: Direct Delegation AS112 Service - RFC7534

We might want to make an exception for IPv4-mapped addresses, and instead consider the address space of the embedded IPv4 address?

[letitz]

A strict reading of #30 (comment) 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.

[letitz]

Fixed by #31.