On Thu, Dec 1, 2011 at 11:44 PM, John C Klensin <[email protected]> wrote:
> > 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
