I wrote a response to Brian's original statement then deleted it because I assumed others would ignore it as clearly last minute and ill-researched. Apparently, that was wrong. There are enterprises that currently use 172.16/12. (There are enterprises which use every tiny piece of RFC 1918 space.)
Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172.16/12 (and, for that matter ever bit of 1918 space). That's irrelevant and still does not address my question. The question is whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE.
Darling Pete,
TYPING YOUR QUESTION IN CAPS DOESN'T MAKE IT THE RIGHT QUESTION.
An enterprise that has numbered into this space and gets put behind a CGN by a provider will have no direct control over this equipment, and it might happen in the *future* after the allocation we're discussing here has been made. Asking whether anyone has this pain right now presumes a steady state in the deployment of CGN, which, sadly, seems awfully unlikely.
To put this another way, you can't solve the problem of equipment which cannot have internal and external interfaces being in the same pool by moving to this, in other words; you just move the pain from users of one RFC 1918 pool to users of another.
That statement does not logically follow from "all 1918 address space is used". You are missing a premise: "There exists equipment that is used in all of that space that can't handle identical addresses on the interior and exterior interface."
No, I think that premise is mis-stated. Premise 1: There exists equipment that can't handle identical addresses on the interior and exterior interface. Premise 2: it may be deployed now or in the future for customers using any part of the RFC 1918 allocation *because those using the RFC 1918 allocations had no prior warning that this might create a collision*. Conclusion: You cannot avoid identical addresses on the interior and exterior interface by using any part of the RFC 1918 allocation.
So the question I posed was, "Does any of *that* equipment use 172.16/12 (or 10.x/16) space?" Nobody has said "yes".
Any exhaustive attempt to categorize that would be single-point in time and therefore useless.
And *I'm* still not claiming that the answer is "No." I simply don't know. But I'm inclined to hear from anybody to indicate that there is *any* evidence that the answer is "Yes". That would make me much more comfortable in concluding that new specialized address space is the better horn of this bull to throw ourselves on.
CGNs are, in my humble opinion, an abomination unto Nuggan. Whether or not we throw ourselves onto this horn to enable them is, at best, a decision that keeping the abomination in a pen is better than having it flow over the countryside in squat space. But the worst decision we could make is to try to pull a /12 out of RFC 1918 space for this purpose; it will be at best simply ignored and at worst ensure yet another group's ox gets gored.
Your humble and obedient servant,
Ted
pr
-- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf