--On Wednesday, April 04, 2012 21:31 -0400 Steven Bellovin
<smb(_at_)cs(_dot_)columbia(_dot_)edu> wrote:
v6 is not the protocol I would have chosen. For that matter,
it's not the protocol I pushed for, as hard as I could, in the
IPng directorate. At this point -- with all of its technical
mistakes, IETF omissions, and difficulty of converting, we're
stuck with it; we simply do not have time -- even if we agreed
now on what we should have done, way back when -- to start
over. Do the arithmetic... Assume we know, today, the basic
structure of a perfect replacement for v4. It would take a
minimum of 3 years to get through the IETF, not because of
...
By my arithmetic, it's a
dozen years minimum, *after* we've agreed on the basic design.
I agree with Steve in almost all respects. Also somewhat agree
with Dave Meyers: NATs were inevitable the moment we adopted
CIDR and effectively started encouraging the RIRs to push back
on allocating fragmented and/or small blocks, if not even
sooner. Now we could (and I think did) reasonably assume
(perhaps as part of retrospectively less-reasonable assumptions
about how quickly IPng/IPv6 would be deployed and how CIDR would
disappear -- the latter assumption followed on the early
assumption that CIDR was mostly about address conservation
rather than about routing tables) that they would not become
associated with other issues and have a long life as a result.
The latter is, IMO, really key, not whether or not we would have
NATs.
Because of the problems that Steve points out of timing to get
another solution out there (perhaps fortunately, that constraint
applies to anyone else who wanted to start on a new "next
generation" protocol suite too), I don't see a lot of point in
putting energy into asking "what if" or bemoaning the state we
find ourselves in except insofar as it actually helps us to move
forward. I'm trying to avoid that except where understanding
how we got here seems useful to avoiding repeating prior
mistakes. I do think it is worthwhile to look at where we are
today and, in particular, how we should balance trying to better
understand the real obstacles to IPv6 adoption and doing
something about them (obstacles that include the perceptions we
and others are continuing to create) against IPv6 Cheerleading
sessions that try to change perceptions in their own ways but do
nothing about those problems (or, IMO, worse, dismiss them as
unimportant).
In the message to which Steve responded, Noel included:
Part of the real problem has been that the IETF failed to
carefully study, and take to heart, the operational
capabilities which NAT provided (such as avoidance of
renumbering, etc, etc),
Part of that really does have to do with the question of how we
move forward. The "etc, etc" above covers a lot beyond NATs in
a renumbering context. At least IMO, we failed to do the
comprehensive analysis on what those issues were. Consequently,
in a problem that seems to persist to this day, we haven't been
able to make a coherent "if you have situation X, you should do
Y" chart or tell a corresponding story.
I'm personally particularly sensitive to customer support issues
for relatively small end-networks that have no serious on-site
technical support capability (residential networks, SOHO
arrangements (where the office is either remote from a larger
facility or primary), relatively isolated branch offices, etc.).
I have been worrying for some time that NAT arrangements with
1918 space create an "almost all networks are the same, even
down to the addresses used" situation, which is hugely
convenient from the standpoint of support, especially if the
support personnel are not, themselves, experts. I'm delighted
that we finally have a HOMENET WG but concerned that if we were
serious about IPv6 and understood that set of issues, we would
have had that WG a decade ago. Worse, my inference from
discussion in the meeting of that WG last week is that a large
fraction of the participants _still_ don't understand the issues.
Others have worried more about renumbering and, well, etc., etc.
Unlike some others, I'm still not convinced that there is
anything fundamentally wrong with the IPv6 design although I
believe that we could have made it either easier to deploy or
that we could have offered more incentives for deployment. But
I think we have done a terrible job until now of identifying,
organizing, and presenting realistic scenarios and corresponding
transition models.
As an exercise, I'd like everyone to try to think about the
decision process of an IT executive who is trying to decide when
and how to deploy IPv6. Let's make the problem easy by assuming
that she understands the broad issues and believes that she will
have to deploy IPv6 sooner or later (a belief that is by no
means universal). She needs to deal with several complex
questions and tradeoffs among them including:
(i) Networks grow, so conversion costs for existing (at
the time) facilities will be larger in the future than
they are now... probably worse yet if measured in
constant dollars.
(ii) Support costs and [re]training of people are an
important part of the equation. The end users who are
being supported probably barely know how to work a web
browser, believe a "route" is something they follow on
the way to the grocery store, and understand "address"
mostly as something their houses have exactly one of
each. Worse, it may be in the IT Department's interest
to keep it that way -- users who know enough to start
messing with machine or router configurations are often
_very_ expensive to support. As one of many
consequences of this, equipment and configurations that
are easy to support have a huge and continuing economic
advantage over arrangements that provide more options
and flexibility at the cost of complexity. In many
cases, judgments will get made about ease of support and
training on one generation of equipment and, if the
answers aren't right, it will make sense to wait for the
next generation (possibly after trying to beat vendors
up, possibly not).
(iii) It is very dangerous to start deployment before
all of the ducks are lined up. If key concepts or
equipment are not available, or not fully understood,
after conversion works starts, the consequences are
likely to be very nasty. In particular, about the worst
thing she can do (measured in job [in]security, if
nothing else) is to start deployment and then stop or
fail, having invested considerable resources with no ROI.
At least the third of these involves some speculation and
reading of omens (which is part of why she presumably gets paid
the big bucks). But the signals the IETF sends are really
important in that regard. Part of the signal we are sending now
(and have been sending for a long time) is that we are willing
to let a thousand flowers bloom wrt both transition strategies
and configuration decisions, that, inevitably, there are a lot
of weeds mixed in there with the flowers, and that if we know
how to tell a flower from a weed, we aren't telling. That is
actually ironic given how outraged we get in other areas when a
non-standard solution (or a solution proposed by standardization
in another body) comes along that might confuse the marketplace
vis-a-vis IETF work). But, to our hypothetical executive, it is
pretty easy to read the message we are sending as "the IETF
doesn't really understand how people in my situation should
deploy IPv6, so I should probably wait until they do".
Worse, if some snake-oil purveyor (NAT or otherwise) then comes
along and says "I know how you can avoid converting with IPv4
until you are good and ready, if ever", she is getting a message
that is more clear, and more attractive under the circumstances,
than the one she is getting from the IETF.
And "decision-maker at ISP supporting small networks" or "small
business" can be substituted for "IT Executive" in the above
without significant other change. The details are different and
the tradeoffs may be, but the fundamental issues aren't.
john