Re: [arch-d] Treating "private" address ranges specially

[Brian E Carpenter <[e-mail]>]

On 01-Apr-21 13:17, Joseph Touch wrote:
> 
> 
>> On Mar 31, 2021, at 1:27 PM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> On 31-Mar-21 22:07, Ted Hardie wrote:
>>
>> <snip>
>>
>>> The document's description of the address space architecture is:
>>>
>>>
>>>      2.1. IP Address Space
>>>
>>> Every IP address belongs to an IP address space, which can be one of three different values:
>>>
>>> 1. local: contains the local host only. In other words, addresses whose target differs for every device.
>>>
>>> 2. private: contains addresses that have meaning only within the current network. In other words, addresses whose target differs based on network position.
>>>
>>> 3. public: contains all other addresses. In other words, addresses whose target is the same for all devices globally on the IP network.
>>
>> The problem is that this classification is worse than heresy; it's nonsense.
> 
> How is this different from RFC6890?

While 6890 is better than what came before, I'm afraid that it still doesn't capture reality (and therefore the IANA registry doesn't either, which is no fault of IANA).

>> 1) local. That seems trivially true
> 
> Again, RFC6890?
> 
> ...
>> 2) private. There is no definition of "private" address in any IETF document. 
> 
> RFC1918??

Yes, you're right, it does use the word "private". But that is in some old out-dated address space where things are relatively simple. In any case, the definition proposed in the cited document doesn't seem to limit itself to that, but tries to extrapolate the same categories to IPv6 and that simply doesn't work.

> 
>> 3) public. Ditto. Globally reachable != public.
> 
> AFAICT, those are equivalent terms; there are lots of “not officially private”, “not officially local” addresses that are not globally reachable either (e.g., most things behind NATs).
> 
> So at best, this hierarchy isn’t ill defined or lacking RFC authority; it’s just incomplete.

I really don't agree. There is a class of address prefixes that are *potentially* globally reachable and therefore potentially public, but there is no way to know by looking at a specific address. So there is no algorithm to reliably return "private" or "public". When I worked for the Network 9 company, you would have needed quite a large table to know which 9.x.y.z addresses were public and which were private. When you installed the corporate VPN, it didn't install a single route to 9/8. It installed a local routing table with a page or two of prefixes. The sort of algorithm proposed here would simply return "public" for any such address. (Try the attached Python script.)

Regards
   Brian