On Jun 1, 2013 11:52 AM, "John C Klensin" <john-ietf@xxxxxxx> wrote:
>
> Brian,
>
> I really need to stop posting to this thread -- I have other
> things to do and I don't believe the conversation is leading to
> anything actionable. Second-guessing is fairly useless at this
> point and there are at least a few things that we know in
> retrospect that we couldn't have known in 1993-1995. I continue
> to believe that many of the IPv6 impediments have been economic
> and deployment policy issues that we did understand in 1993 but
> didn't pay enough attention to, but some of the technical stuff
> was, and is, more complicated. On the technical side, I believe
> that there was a general belief in 1993 that we would be able to
> map out a unified, clear, transition strategy for IPv6 and give
> simple advice about it. In retrospect, that was probably
> naive... and I believe that confused messages about transition,
> especially to people who won't make their deployment decisions
> based on complex and subtle technical issues, have been part of
> the problem.
>
I think there is something here that is interesting, and that is the interplay between paper design, evolution, and ultimately the emergent complex dynamical system we call the internet ... which is almost completely zero compliant to the e2e principle. Not that e2e is the wrong principle, but ipv4 could not support it as of 10+ years ago. Hence, nearly every internet node is behind a stateful device (cpe or cgn nat) or server load balancer. There is also widespread disbelief in how dns operates in the real world (not everyone gets the same answer).
Yet, corners of the ietf call this real world internet of middleboxes as broken. As some of it is broken, so you have things like SPDY and ICE/STUN/TURN/464XLAT/MAP/6RD to bust through it. Mutation happens.
That said, the teaching moment here is look back and realize the internet was not engineered, if was emerged.
Given that the internet is not engineered and that it is a greedy collection of self optimizing nodes that mutate, how do we make it go fast, bigger, better given the few levers we have.
CB
> More inline.
>
> --On Saturday, June 01, 2013 16:35 +1200 Brian E Carpenter
> <brian.e.carpenter@xxxxxxxxx> wrote:
>
> >...
> > 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, as I think Vint says, it is always more complicated. But
> translating the above into the perspective of a decision-maker
> who has to decide if, when, and how to deploy IPv6, those
> requirements weren't very compelling. Some of the organizations
> that had the need were already running some member of the family
> of LAN protocols in which every node continually broadcast its
> identity and location, or were getting by with BOOTP. Others
> just didn't perceive the problem as a need rather than, at most,
> an inconvenience. IPv6 would have made things better, but
> almost no one actually was going to convert to it for that
> reason given the other costs of conversion. Then given your
> explanation, IETF came along with an IPv6-killer in the form of
> DHCP and reduced the motivation further.
>
> The standardization and deployment of DHCP was entirely
> reasonable. But we knew that DHCP was coming -- RFC 1531 was
> published several months before even the IPng solicitation in
> RFC 1550 and the DHC WG had been around, IIR, some time longer
> -- so assuming that the configuration issues were going to be a
> major driver to IPv6 doesn't speak well for the IETF's ability
> to think about and understand complete systems and relationships
> among protocols a decade ago (I have no reason to claim we have
> gotten either better or worse -- so much for cross-area review
> at the systems, rather than nits, details, and religion, levels).
>
> > 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.
>
> Sorry, Brian. I may just be naive, but I see a difference
> between the same protocol with an extended address format and a
> different protocol that coexists more or less well. They may
> be formally no different, but the transition strategy
> implications are, IMO, very different in part because the former
> involves only a single address space with issues accessing part
> of it while the latter implies everything we have seen played
> out in recent years. In particular, one protocol with an
> extended address format doesn't ever require dual stack and, for
> short-form addresses, it doesn't require address translation,
> just packing and unpacking.
>
> And yes, even with a different protocol, I think rejecting the
> ideas Mike O'Dell and others pushed about embedding IPv4
> addresses in IPv6 ones was a significant setback from a
> deployment incentives and costs standpoint.
>
> > 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.
>
> What you see as "design of human beings" I see as either failure
> to be able to get things right the first time or two or as a
> different sort of failure to understand the whole system and act
> on it. In the first case, it would imply that we didn't
> understand the implications of IPv6 nearly as well as we thought
> we did when we started telling people to deploy it. In the
> second... well, we have extensive debates from time to time
> about the problems associated with approving competing standards
> to accomplish just about the same job. Even when we do approve
> competing protocols, we usually try to insist on good
> explanations of applicability. But, unless I've missed a series
> of important conversations, IPv6 conversion/ transition methods
> have been largely exempt from those discussions and
> requirements.
>
> Whatever the causes, even if they are "design of humans", the
> results don't do anything positive for either the deployment of
> IPv6 or the credibility of the IETF.
>
> >...
> >> 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.
>
> An interesting response. I guess I'm still naive enough to
> believe in hourglasses and IP-over-<whatever> models. Today, my
> applications absolutely do not need to know anything beyond IPv4
> addresses and TCP (or UDP or RTP or...) in order to use those
> physical environments today. And, as long as there are routers
> in the network --routers that can be fairly straightforward for
> edge networks, even multihomed ones-- the applications don't
> need to know about routing and route optimization either.
>
> >> 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.
>
> In the last decade or so, I've set up several multiply-connected
> IPv4 LANs with load-sharing and fall over provisions for
> various people/ businesses. I may not know much (and don't),
> but I know a lot more than the SOHO-provider ISPs do and are
> willing to supply. The routing setup is simple enough that even
> my rather small brain (I won't even play a routing expert on TV)
> could handle it and none of these sites have PI space that they
> can get routed. They do have one-one NATs facing both LANs so
> the applications don't know a thing about the connectivity
> setup. The setup isn't optimal and the routing decisions aren't
> either, but it works and it would take a lot to convince me that
> getting from there to optimal is worth the trouble. For IPv6,
> I've either got to replicate the setup (hence one less incentive
> to convert) or I've got to deal with a significantly more
> complex applications setup and teach the applications to be
> routing-path-sensitive (some incentives in terms of performance,
> but really high cost, especially when one includes the
> observation that, if something goes wrong with the connectivity
> setups that are in use now, it is possible to call the relevant
> ISP and whine while the more optimized setups are ones they
> don't want to support except, maybe, for large customers and
> specific contractual agreements.
>
> That problem actually does scale, at least to analogues, and
> turns into another example in which we have made IPv6 and IPv6
> transition a much more costly undertaking than would predict to
> rapid deployment without our being able to show huge advantages
> to the operators (even of small edge networks) rather than
> advantages to the network (some tragedy of the commons elements
> there, but we knew about that problem).
>
> >> 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.
>
> Absolutely. No change involves a free lunch and any change from
> something that is perceived as working satisfactorily (or even
> nearly so) is going to require either an ability to make
> commandments, a way to externalize the costs, or a fairly
> serious incentive structure. That was my key point, and
> Warren's, and I think Randy's. It may be worth noting that
> those conditions were very clear when IPv4 was deployed: the
> advantages of moving off the NCP environment were fairly well
> understood and accepted in the community, the costs for many
> installations were borne by the agencies who provided
> connectivity and insisted on conversion, and it was very clear
> that a flag day requirement could be imposed and enforced.
>
> Let me stress that, unlike some others, I'm not an IPv6-hater.
> I'm painfully aware that almost any engineering design could be
> made to come out differently if different design constraints
> were assumed or different priorities were chosen for
> optimization. I continue to hope for IPv6 deployment and try to
> think about ways to help even while I'm pessimistic about the
> situation we find ourselves in and the stumbling blocks we have
> allowed to rest in the path (those that we have caused and those
> that come from other sources). I don't think this is "IETF
> versus the Ops" either although that may be the effect: I think
> what what Randy, Warren, and others have said about those
> relationship are much more about symptoms of different
> interests, criteria, and cultures then they are about
> intentionally bad behavior, even though getting the assumptions
> and practices about those relationships wrong may aggravate the
> symptoms.
>
> The mistake I think we made was in not adequately considering
> the transition and incentive issues as a fundamental and
> critical part of the design and solution space rather than,
> e.g., something that could be sorted out later as long as the
> protocol was ok (or nearly so). Sadly, I'm not at all sure we
> have learned that lesson.
>
> best,
> john
>