IAB and "private" numbering

This is practical engineering, not theoretical science. Practical
engineering is about *trade-offs*.

We were seeing address space requests for huge deployments with a real
low probability to ever be routed anywhere beyond a quite local domain.
There are huge deployments of this kind now and happily so without
unnecessary using finite address resources.

The drawbacks were known and discussed. Note that 1627<1918. Clear
warnings were written into 1918; it is one of the more "operational"
RFCs, certainly at the time. We also discussed the possibility of NATs
but it was out-of-scope for 1918; we discussed application layer
gateways though; we did not anticipate any NAT deployments beyond a very
local scale.

Would we rather have run out of unallocated unique IPv4 address space at
some point in the past? Would an alternative have been ready by then?

(Would we rather run out of unallocated IPv4 address space on -say- 31-Dec-2005?
Will IPv6 be ready for prime time then?)

One of the instigators and co-author of RFC1918.

There are some resources, like IP addresses and AS numbers, the proper
operation of which hinges on their uniqueness.


Does this concern make sense?
Does this course of action make sense?
Is there a(nother) better venue than the IAB?
What do people think?

(Yeah, I did read the rest of the thread, but am replying to the original message.)

I think there are a few dilemmas in this topic.

One stems from the RIR's duty to provide stewardship of the number resources they administer. The other is the dividing line between protocol design (IAB) and operations (RIRs).

One concern from this is number resources depletion, which is why, in my estimation, there are people measuring things like announced space and time to network with AS numbers. (I'm referring to work Geoff Huston, Tony Hain, and Henk U of RIPE have presented in numerous locations in the past few months.)

When a resource is becoming scarce, there's a push to try and be certain that it is being used efficiently, with efficiency measured in terms of time to depletion. With this in mind, if a resource is used privately, why can't it be used publicly too by some deserving? (I ask this rhetorically as an example.)

Stewardship also means uniqueness too, or at least uniqueness in some scope. (A 48 bit number could be a "hardware address" or a combination IPv4 and port number, as an example of stretching.) To achieve this, the RIRs would naturally assign an number to anyone deserving, regardless of how the network is connected.

Combine that with a third dimension, that the RIRs are run in the context of some sort of public trust, there are folks that will want to check up on them. That's where we get folks probing the exposed data (via whois, say) and seeing what they can get to. I think this is where the assumption of a "public internet" comes from.

This is a three-way conflict centered on the RIRs. There's the whole matter of the benefit vs. pain of scoped (as in site local, link local, RFC 1918) addressing. That's a matter for the protocol engineers to figure out, I think that is something the IAB would be concerned about - if not so already.

I don't think that you want to have the directory services of the RIRs (whois today) flag addresses as public use or private use, but you do what the defined protocol scope clearly indicated. The reason for not labelling public or private is that there are multiple private (if there is indeed one true public). If you see two private addresses, can they see each other?

In as much as we don't want the RIR's in the routers, we shouldn't put the routers into the RIRs. The outcome of this is that folks probing and prodding the data in the RIRs ought to not expect to see all the resources registered therein on the public Internet.

It would tempting to say not to worry about unseen resources, to assume they are in the private areas of the world. However, there are probably resources that are "lost" - allocated in the days when IANA was a small part of ISI and things were done on paper. In the effort to stop depletion, these should be reclaimed, but deciding what is lost versus what is in private use is ... a dilemma.

My experience in this is tied to DNS and lame delegations. Just like the routing table issue, we have delegations into places that are not reachable. A name server may be situated in a way in which "it can see out" but "we cannot see in." The problem with these seems to be some past implementations of DNS that looped as a result of lame delegations (in this case situations in which the desired name server[s] are not reachable).

Maybe this is where the IAB steps in, and looks for documents showing how members of a network, whether the public or a private network, can either protect themselves from trying to reach unreachable areas, or to set up stub or proxy services to absorb ill-fated traffic destined to an unreachable address. I'm not sure this is feasible - the DNSOP WG seems to have killed, or is about to kill a document on "don't publish unreachable things in the DNS." As much as that sounds useful, there was no energy in the group to finish the document. A lack of energy tells me something.

Scoped addresses do run afoul of the theory that a network is a collection on mutually reachable endpoints. Once you scope an address, you've lost the theory of the network layer. Still, it does work to do this, so it's not that it's impossible, it's that the theory needs to be, umm, scoped. I've thought far less about this, but that's the kind of thing that the IAB might weigh in on, if there is the energy to do so.

All I know is that I've had bad experiences with duplicated or
overlapping address spaces. One particularly bad one was spending two
months developing templates for combinations of NAT / NAPT for Internet
/ VPN access (e.g. NAT to Internet, not VPN; NAT to VPN, not Internet;
NAPT to Internet, NAT to VPN, different "to" address spaces for NAT to
the Internet and NAT to the VPN etc. etc.). In addition to developing
these solutions I also sat scratching my head for two months asking "why
not just give them public address space, restoring uniqueness to their
addressing, so I can work on improving the product rather than just
developing work arounds ?". Spending time on work arounds, as well as
building protocol and other limitations into the network that will be
encountered in the future, isn't a good trade-off in my