--On Friday, December 02, 2011 10:06 -0800 Ted Hardie
<ted(_dot_)ietf(_at_)gmail(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf