On Jun 1, 2013, at 12:35 AM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
On 01/06/2013 15:00, John C Klensin wrote:
--On Friday, May 31, 2013 17:23 -0700 Randy Bush <randy(_at_)psg(_dot_)com>
wrote:
< rant >
the sad fact is that the ietf culture is often not very good at
listening to the (ops) customer. look at the cf we have made
out of ipv6. the end user, and the op, want the absolute
minimal change and cost, let me get an ipv6 allocation from
the integer rental monopoly, flip a switch or two, and get 96
more bits no magic. 15 years later, dhcp is still a cf, i
have to run a second server (why the hell does isc not merge
them?), i can not use it for finding my gateway or vrrp exit,
... at least we got rid of the tla/nla classful insanity. but
u/g? puhleeze.
Randy,
I suggest that characterizing that set of issues as IETF versus
Ops is probably not completely right either.
It was more complicated. I was actually running a team that ran site
network ops at the time, and (since DHCP was not yet deployable),
IPv4 was then a serious nuisance to manage, compared say to Novell
Netware and, even, Appletalk. There were good reasons we wanted
stateless auto-configuration and unlimited subnet size, to mention
two IPv6 bells and whistles. If DHCP had already been deployed,
our opinion might have been different.
Yes, it was more complicated, but the sad part is that DHCP was widely deployed
in V4 long before V6 was a viable transport for real work on the Internet.
Operators kept asking for DHCP and kept being slapped down by zealots who
refused to listen to / consider why the Ops were asking for this.
I *really* want to make sure that my CEO always gets the same address, and want
him to be assigned specific DNS servers and use a certain gateway. The folk who
manage the DHCP are the "Internal Services Infrastructure Group" (aka "The
windows monkeys") and I'm sure as heck not giving them access to my router to
twiddle knobs on it.
For example, with
IPv6, the IETF has proposed multiple transition solutions with
no roadmap as to which one to apply under what circumstances and
growing evidence that some of those solutions are unworkable in
practice and others are incompatible with what are claimed to be
fundamental and important features of the Internet.
It turns out that as soon as you envisage a network in which some
nodes only support 32 bit addresses and other nodes can't get
a globally unique 32 bit address, you are forced into a world
of hurt that requires some combination of NAT, tunnels and
dual-stack. That is completely independent of the design of
IPng, and we knew it 1994.
Yes, hindsight always makes things *much* clearer. It also provides a nice
sandbox to stand on….
Anyway, I think that going down the path of "There are warts in V6, I want a
refund!" is not helpful. What I hope we can try and focus on is how we can
improve understanding of what the customer (operators, users) actually wants,
how and where the protocols of the future will be used, how we can incorporate
changes as we get feedback and understand new requirements, etc.
I was not intending to point fingers (although I realize I did), but rather to
try show places where the protocol could have improved with a better
understanding of what folk were looking for / with more operator input...
So while your criticism is valid that we collectively came up
with too many such combinations, that collective mistake was
(IMHO) not a result of the design of IPv6 as such. It was more
caused by the design of human beings.
I'd go further -- some of the issue is (IMO) caused by the consensus driven
nature of how we do things. We all have different sets of interests and
different priorities. Because of a need to achieve consensus, we end in
something kind of like horse-trading. We add features to appease some set of
folk, and compromise on other bits to appease others. I suspect that if one or
two folk had designed this, soup-to-nuts, we'd have ended up with something
cleaner.
It doesn't
take a skilled operations person to understand that is a
problem; someone with a pointy head and barely enough clue to
figure out what a "bit" is much less how many of them are in
various addresses can derive a "don't be the first person on the
block" or "don't migrate if you can figure out an alternative"
lesson from that.
Similarly, various applications folks within the IETF have
pointed out repeatedly that any approach that assigns multiple
addresses, associated with different networks and different
policies and properties, either requires the applications to
understand those policies, properties, and associated routing
(and blows up all of the historical application-layer APIs in
the process) or requires request/response negotiation that TCP
doesn't allow for (and blows up most of the historical
application-layer APIs).
It's true, but to avoid that, I think we'd have to abolish
cellular telecommunications, Wi-Fi, and competition between
providers.
Not sure I agree.
Most apps on my iPhone seem to work just fine while I wander in and out of my
house and move from WiFi to cellular.
As for competition between providers -- folk have been doing this with e.g BGP
for years. Most CPE lets you easily swap between providers (by moving a wire
:-)) and some let you share multiple by NATing (yes, I know, I know) some
sessions to one and others to the other provider...
One of the original promises about
IPv6 was no need for changes to TCP and consequent transparency
to most applications. Ha!
Right, but again - only part of that is due to the change of
address size and socket API details. Most of it is due to
multiple connectivity. That was going to happen anyway.
I have never been convinced that "longer addresses and nothing
else" was the only viable solution for IPng,
Don't forget, BTW, that even "just" changing address size
from 32 to 64 would have blown up almost every app written to
BSD sockets (since Real Programmers Don't Use Structures and
almost everybody used to stick addresses into uint_32).
There never was a free lunch on the table.
Yes, IP is fundamental plumbing, and folk make assumptions about how the
plumbing works / take shortcuts.
Changing fundamental plumbing is hard, and requires changes to all the
fittings, valves, etc.
W
Brian
but I don't think
it requires an advanced degree in economics to understand that,
if the incentives to do something don't exceed the costs and
risks of doing it, one shouldn't expect a lot of rational folks
to charge off and do it. A complex system with high deployment
costs and risks and a dubious set of advantages is not a story
that is going to sell itself. And, again, it doesn't require a
sophisticated operator to figure that out.
None of this takes away from your rant (or Warren's). But I
suggest that, on several of the dimensions you identify, the
operators are not being singled out for abusive treatment
because we don't listen to each other or elementary
decision-making or economic realities either... at least where
broad issues, rather than fine-tuning of a spec are concerned.
john
--
There were such things as dwarf gods. Dwarfs were not a naturally religious
species, but in a world where pit props could crack without warning and pockets
of fire damp could suddenly explode they'd seen the need for gods as the sort
of supernatural equivalent of a hard hat. Besides, when you hit your thumb with
an eight-pound hammer it's nice to be able to blaspheme. It takes a very
special and straong-minded kind of atheist to jump up and down with their hand
clasped under their other armpit and shout, "Oh,
random-fluctuations-in-the-space-time-continuum!" or "Aaargh,
primitive-and-outmoded-concept on a crutch!"
-- Terry Pratchett