Assume that no vendor in its collective right mind would deploy
new address translation gear (or firmware) that couldn't cope
with having addresses from the same pool on the "inside" and
"outside" and that we are willing to let the marketplace punish
those who are not in their right minds, the topic of whether a
separate address range is needed to maintain inside/outside
distinctions becomes strictly one of legacy gear -- dealing with
deployed CPE gear that is hard or impossible to replace on a
near-term schedule and, quite bluntly, crappy.
In that context, questions like Pete's make perfect sense
because they are questions about how to patch around said legacy
gear while causing minimum damage to today's assumptions about,
e.g., routable and non-routable addresses.
I think there is an unstated premise in Pete's question that the set of customers behind that legacy gear has a stable usage pattern of private addresses. That is, if the current set of customers behind that legacy gear uses 10/8 then use of any other RFC 1918 address on the CGN is "safe". I do not think that is a safe assumption.
I also strongly suspect that any vendor in its collective right mind which had available a solution like using 172.16/12 would have done so long before enduring the pain of being nibbled to death by the IETF's ducks. It's not like these guys haven't read RFC 1918 and simply assumed 10/8 was the only network available.
Even if the answer is "no, there are no devices that both have
172.16/12 wired in and that can't handle overlapping 'inside'
and 'outside' address pools", it doesn't necessarily make
allocating an address pool to this use desirable. But that is
the other question:
Where is the stopping point? If 172.16/12 works for
carrier-grade NATs, will we need a new allocation (possibly the
one requested in the present I-D) for peering-point-grade NATs?
If that allocation is made, will we need another one for
country-boundary-NATs or RIR-boundary-NATs? Conversely, if we
make the requested allocation (rather than using 172.16/12 or
something else already reserved), does that fix anything or just
bring the "next NAT layer, next allocation" question a little
closer?
I think this boils down to a recommendation to reject the request entirely, a point of view with which I have a great amount of sympathy (heck, if that point of view wants to come over to my house, I'll give it dinner, a good wine, and a spot in the guest room). I have no illusions that making this allocation is a good idea; it's just a question of whether it is the right bad idea for the moment. But I personally remain convinced that shifting this pain onto folks who used some part of the private address space as it was described is sufficiently wrong-headed that it simply will not work. It is better to either hold your nose and allocate or stick to your guns and reject.
Once again, my personal opinion, not reflective of those held by my employer, spouse, hot tub-maintainer, or the man on the street.
regards,
Ted
john
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf