On 01/06/2013 15:00, John C Klensin wrote: > > --On Friday, May 31, 2013 17:23 -0700 Randy Bush <ra...@psg.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. > 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. 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. > 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. > 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. 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 > > > >
