--On Friday, December 02, 2011 10:06 -0800 Ted Hardie <ted.ietf@xxxxxxxxx> wrote: >... >> 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. Agreed. But let me also suggest that there is another assumption that is perhaps equally unsafe or unreasonable. Even if one concedes that replacing the CPE gear in low-end networks is completely unfeasible in any short period of time, that does not imply that such networks cannot be renumbered. Those CPE devices typically contain the DHCP servers that allocate addresses to devices on the relevant end-user LAN. Virtually all of them can be configured or patched to use different addresses. And, especially if we believe that renumbering is plausible enough to make lots of our other protocols and assumptions work, changing the address ranges they assign has to be within the realm of possibility. So a different (and narrower) version of Pete's question is whether there are devices out there that (i) use a particular range of 1918 addresses, (ii) do so stably, and (iii) cannot plausibly be reconfigured to use something else (or a smaller range). We disagree in that I think that question is still interesting.. but not very interesting. > 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. Unless either (i) it had already figured out that trying to use pieces of 1918 space was a dead end that would lead them to needing a new allocation later (see my "stopping point" comments) and had concluded that, however painful the process would be today, it would be worse a few years down the road or (ii) they have more sinister motives, perhaps those that kre's reasoning suggests. >> 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. >... > 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). Yes, it does. Someday, I'll accept that invitation on behalf of the point of view. > 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. If we disagree at all, it is only because I don't see enough advantages or disadvantages of trying to use some chunk of 1918 space relative to allocating new public space to justify choosing one over the other. From my point of view, this is just a bad idea that solves no useful problem. If might delay a few. It might cause some ISPs, for a while, to use IETF-designated space (of one flavor or the other) rather than squatting, but almost all of the argument for doing this is based on the assumption that the use of more traditional space (dedicated/public or 1918) is not possible because that space has been used up or soon will be. But that argument is for dragging the wolf away from the door and a few meters down the block, hoping it won't come back. Sorry, but that isn't consistent with wolf-behavior or ISP behavior: tactics that are justified on the basis of "we don't have enough addresses to do this right" are tactics that are intrinsically going to bring people back to the well over and over again. So, yes, I think we should just reject this... and that we should reject enabling/ encouraging any other solutions that are intended to be IPv4-preserving rather than IPv6-enabling and transitional. It may still be reasonable for us to do protocol work to enable those who intend to do this sort of thing to do it correctly and consistently. But, as far as making IPv4 address allocations to permit them to hide a bit longer from IPv6 -- taking those addresses away from those who really have IPv6 deployment and transition plans-- it is better to Just Say No. > Once again, my personal opinion, not reflective of those held > by my employer, spouse, hot tub-maintainer, or the man on the > street. As is mine. best, john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf