CircleID

Thoughtful piece, Geoff, a great read, thanks for making it available.

If I can paraphrase, IPV6 is offering a featureless upgrade that solves no apparent immediate problems for most (if not all) of us. Why bother?

You argued down the cases for extinction, evolution, or revolution of IP protocols. The other alternative I see is a feature laden upgrade with market appeal - maybe an IPV7 that solves some compelling problems? That might apeal to the market, but not to the purveyors of simplicity in base protocols. So are we stuck where we are?

Or do we (or someone else) just pave over IP and start again in the same way that IP paved over legacy telecommunications protocols?

I am of the view that a 'feature laden' IPv7 (or whatever number we would be up to) would in fact be a design problem of attempting to make a different set of design tradeoffs within the same set of fundamental engineering constraints that lie behind all contextless packeting switching environments. The problem that such an exercise faces is twofold: one it would take some time to develop as there is certainly nothing 'hovering in the wings' at the moment, and, secondly, there is this horrible suspicion that the design effort would end up with once more nothing much different, as the set of trade-offs are in fact much the same as they have always been.

After all the basic constructs of contextless packet switching are to expose to the network switching elements information relating to the location of the intended destination, the location of the purported source, some information relating to the progress so far of the packet within the network, and some rudimentary information relating to the reason for the packet. There's not a whole lot of room to wriggle around within this set of constraints, so I suspect that we are stuck with this IP architecture.

That lead me to thinking along the lines of "well what IS the true driver for IPv6 (or indeed moving to any packet switching protocol from the current IPv4 base) and this line of thinking lead me to the "volume over value transition" that is the thesis of the article.

I suspect that the next step we are looking at as an industry is true commoditization of the essential "raw" service of simple packet switching. i.e. removing from the industry all pretence of "value-adding" the network service offering. Of course this is a message that neither the current incumbents nor the service industries that supports these incumbents are too keen on hearing right now.

I've spent some time trying to deploy IPv6 in different environments over the past couple of years.  I used to have the license plate "ip6arpa" but have turned that in for a generic one, a reflection of my optimism.

As a consumer of Internet services, I would adopt IPv6 for one of two reasons.  If there was some service I wanted that was only available over IPv6, I'd adopt.  If adoption of IPv6 was significantly cheaper than IPv4, I would switch.  The fact that IPv6 has more addresses is not important to me, as a consumer.  It's "what does the network do for me" that matters, not "how does the network do it for me."

As an engineer, there's no feature of IPv6 that beats IPv4 hands down.  Sure there are the extra addresses available, no question, but that is of little use given other limitations plus other stop-gap measures added to IPv4.  IPv4 has NAT, has DHCP.  Some believe NAT is evil, I can understand why, but it does extend the address space.  (In real life, society can deal with drive-on-the-right and drive-on-the-left.)

I don't mean to say that NAT and DHCP make up for the shortfall in addresses in IPv4.  One limiting factor is still routing.  IPv6 hasn't solved the IPv4 routing problems.  There are discussions towards "provider independent" address space policies in IPv6 - which disrupts aggregation of routes.  In IPv4, there is a lot of provider independent space - a lot of it the "legacy" space (that is, mostly pre-RIRs) that is assigned without regard to topology.  If this happens in IPv6 we will wind up with a network in which everything is addressed, but you won't know how to get there.  IPv6 needs to make sure this won't happen.

(I have always been concerned about lack of advances in IPv6 routing.  The 6Bone existed for IPv6 operations research - and still for <5 months more - but used tunnels over IPv4.  I couldn't see - when I had a 6Bone network - how it provided a way to experiment with routing.)

The need for provider independent space is driven by two factors.  One, consumers of IP services have been burned by ISPs going out of business or suffering network-wide failures.  Two, it is not easy to re-address a consumer network, which is needed when your ISP goes out of business and you are still profitable.  It's not just a host address issue, it is a firewall and DNS issue (to name two applications that "burn in" IP addresses into configurations).

It is said IPv6 provides security.  With IPSEC, it did provide a leap forward, but IPv4 was able to add this.  Security on the wire isn't all that needs to be provided though.  "Con games" like fake websites and outright attacks on credit card databases are still in play.  So, saying IPv6 "improves security" is a hollow claim, even if it does require stepped up security.

Is IPv6 an exercise in futility?  No, I don't think so.  But it is hard to justify adopting it because it offers so little new.  It attacks issues some engineers see as critical, but it doesn't necessarily solve the problems at the services level.  This is why I have a hard time convincing people we need to go to v6.

In the article, IPv6 is said to not be a reaction but rather an example of "centrally planned development." This strikes me as an odd compliment to IPv6 because I recall the same sentiment being an insult to OSI.  OSI was committee driven, a planned and studied approach to replacing the status quo of communications pre-IPv4.  IPv4 zoomed by because it "reacted" to needs, not anticipated trends.  (Having been raised in a IPv4 "household," the phrase "centrally planned" makes me think of the "evil, wrong way of thinking.")

"If not IPv6, then what?" That's the most powerful question the IPv6 proponents can put forward.  But that's arguing from weakness.  IPv6 will come when it is needed, not because it's the last one left at the dance.

As Ed Lewis pointed out - there's no "killer app" that's driving v6 adoption .. nothing that can't be done over existing v4 networks.

High amounts of hype from IPv6 advocates make an interesting constrast to less than visible performance / deployment of v6

And the concept of a device rich internet with every single toaster and microwave having a v6 stack is far, far away into the future (and tell you the truth, I dont want my toasters and microwaves on the internet, or even on my LAN).  Adds all kinds of security complexities there - bolting v6 or any other kind on IP stack on devices that were meant to toast bread, or cook food or whatever.

Entertainment - gaming / TV over IP might help. Largescale deployment to network otherwise intelligent devices (radar / scanners or whatever else the DoD is networking together) might help.  But unless it is largescale and more or less universally in use, it is not going to drive v6 deployment at all.

Successors to v6?  Jim Fleming maybe, or that chinese company that was trumpeting an "ipv9" :)

Or maybe when Vint Cerf's vision of IP networks across outer space comes through, THAT might probably drive v6, or v12 or whatever.

We're seeing the same old mistakes in IP allocation for v6, mistakes that characterized the early v4 networks, handing out class A, B and C space without any thought to the future.

Soon (!) we'll have IPv12. And then we'll have the IGSIS (Intergalactic WSIS) with little green men and tentacled aliens fulminating about how those *$^#$^#$ earthlings hogged all the usable v12 space so that they have nothing at all available for their own use.

You know, everytime I read another IPv6 or anti-NAT related article, I really have to wonder if people are making some assumptions I am not getting.

Why does end-to-end matter at the transport (protocol) level, honestly? 

I mean, I don't care if my data is going over copper, fiber, microwave, 802.11, or what.  It gets converted five ways from last Sunday during transmission.  Why do I care if it remains IPv4 end-to-end or not?  Why should my applications care if they are running on IPv6 or what?  (If the applications do care, that's a badly designed application—they've tied their application into network layer dependencies.  Of course many applications *have* done this, using IPv4 specific implementations and—tada!—locked themselves out of IPv6.)

Heck, my data might get stored on optical media, magnetic media, solid state memory, whatever.  A hundred different media formats and systems, but as long as my applications access them through a common *interface* and can get out what I put in, why should I care about the specifics of what happens internally? 

NAT is not an abberation.  NAT is the network fumbling, evolving (badly) towards a way of creating a layer of abstraction.  Encapsulation, abstraction, common interfaces that can be reused without worrying about a particular implementation—some basic software engineering principles, ya know?

Arguing for an end-to-end model is like arguing that everyone in the planet should only use one company's word processing file format.  Or one manufacture's image format.  Keep it simple, no competing, confusing formats.  Don't think about conversion or improvements.  Conform.  Conform.  Conform.  One of the key benefits of the digital world has been the ability to convert things between formats, not be locked into formats.  We convert images/videos to bits and back again, sounds, text, etc. to electronic representations—copy, search, transform, convert.  Trying to argue for a universal, one-size-fits-all network protocol is against the very nature of what makes the digital medium so revolutionary! 

The vision of all these devices running IPv6 stacks is cute, but is an evolutionary dead-end that a monocultural deployment represents.  I doubt you can convince me that IPv6 is the end-all-be-all, protocol perfection that will never be replaced.  Yet, when a replacement shows up, how will you deal with all of this device-to-device communication between IPv6 devices you refer to?  How will you upgrade them, this magnitude more quantity of devices?  Communicate with them?  Will you require all the world to upgrade each device they have that now has IPv6 built in?  I doubt it.

*Conversion between protocols is a requirement!* It is ultimately the only way forward, not dead-end-to-dead-end, monolithic/mono-culture systems, because we will always, always run into the problem of converting between protocols/media as we move forward.  Where would the network be if we mandated that data originating on copper could not be converted for transmission onto fiber?  Or wireless?

Now that we've outgrown our IPv4 box, people are looking at IPv6 and saying "This is a bigger box and therefor better!", but the issue is *it's still a box* no matter hw you paint it.  A dead-end in every direction one might want to progress in—if not today, then in a decade from today.  Why should I be interested in paying the cost of upgrading from one prison to another prison with only incremental value, and may have to pay to upgrade to yet another larger prison later?  *That's* the question that really holds things back. 

Get application/service makers to stop tying things to a specific box/protocol.  Once users (and your devices) can communicate freely *between* different protocols through standard interfaces, they can have the choice, the freedom to live in the protocol/box most suited to their needs without giving up anything—and if they don't like any of the ones available, they can make their own while still being able to interoperate.  That's evolution, by definition, and also your revolution, breaking out of the prisons of dead-end-to-dead-end.  Copper, fiber, or wireless—I can make that choice for my network and still have my applications work.  Give me that chioce for my *transport* protocols, and take IP down off its pedestal.  If we had that choice to choose between IPv4 and IPv6 the way we could between copper and wireless, then IPv6 adoption would be well on its way.  IPv4 and IPv6 are anti-choice in their end-to-end models, and thus mutually exclude each other, which hampers the adoption.

People may be forced into the IPv6 box, simply because they're squeezed out of the IPv4 box due to lack of room, but they won't like it.  All the value right now is in the IPv4 box, and the dead-end-to-dead-end model makes the two boxes try to exclude one another.  The revolution, the value and incentive, will come when some figures out a way to successfully build a door between the boxes—that allows people to build doors into other boxes, whenever and where-ever they want.  That's the difference between a prison and room—a room has a door you can open yourself.  The end-to-end architecture is a prison, because it has no doors to other protocols.

As it stands IPv6 is neither evolutionary or revolutionary compared to IPv4.  It's just a bigger prison.  When you realize this, all the value in the proposition goes away.

NAT works reasonably well, and problems can be adapted to at application level. Global public addressability can be also solved at application level, like Skype proves. SIP addresses could be another standard set of handles to negotiate connections to private addresses through Teredo like proxies.

IPv6 transition requires a lot of work, most notably because of a need to upgrade all software from the bottom IP routing level up to the applications.

It also requires re-building and re-testing of lots of tricky, untried and often not-yet-available IPv6 packet filtering and firewalling, which your security guys will not do until IPv6 is mainstream. This is a very difficult chicken-and-egg problem. Due to security problems, two organizations starting IPv6 experiments typically can not communicate, and the promised new global addressing is useless.

Or actually it works right now, because the firewalls don't yet block Teredo, because the security guys don't know about this horrible Teredo technology which allows global incoming connections to any private addresses inside!

Then what to do in the future? I strongly suggest that if not as a solution, at least as inspiration you should look at the 9P protocol, the factotum "security agent" and Plan 9 OS networking. Currently 9P (also incluced in the latest Linux kernels) provides you a simplistic byte stream over TCP, but any transport/network level could be used, allowing innovations transparently to higher levels, transparently to the security architecture, and certainly transparently to applications and users. The lower levels could use IPv4, IPv6, or any other future technologies, now considered to be "link" level. Note that new here can co-exist with the old, as long as global IPv4 connectivity is available as a legacy. In the future, when the lower levels bifurcate and fragment, the 9P level would allow global connectivity.

For hate or for love, note that in a way 9P is UUCP for the next millenium. It has the same historical origins in Bell Labs Unix world, uses the same node name based station-to-station source addressing and is strongly file oriented, leaving lower levels up to the implementation.

Why is end-to-end important?

That is a good question.  In short, end-to-end is important in TCP/IP - technically important even if it seems invisible to policy and other layers.

The OSI defintion of the Network Layer and the Transport layer assumes that "everything is reachable." These are layers 3 and 4 counting up the stack.  Layers 1 and 2 (Physical and Link) took care of moving a "frame" of data from one electronic thing to another.  Layers 3 and 4 are defined to be the glue that holds all the little pieces in place, creating the network.

I know that when I trot out the argument that "X" was an original assumption, so it is important, this seems like I am saying that "well, son, that's the way things are." But what I mean to impress is that a lot of the succeeding development has occurred assuming "X" and therefore detailing why "X" is important could take a lot of time.

For example, one crucial feature of the IP network is congestion control.  Unlike telephony, datagrams (or packets) in the Network (3) Layer are sent out without prior reservation of resources.  When a computer originates a packet, the packet is placed into a frame (layer 1/2) and shipped to an interconnection device, such as a router.

The router has to read in the frame with the packet, and "in real time" put the packet into a newly made frame and ship it out another interface.  Inside a router, packets without frames (waiting for forwarding decisions and/or a frame buffer to be made available) use up memory.  Memory is one such resource that is needed, yet is unreserved.

Congestion control is the process of limiting the number of packets being originated so that the resources in the network are not overwhelmed.  If they are, packets are dropped resulting in more and more retries (they way IP networks overcome losses).

TCP/IP performs congestion control at the two endpoints of the data transfer - the originator of the packet and the destination.  The originator increases the rate of packet generation until no acknowledgement from the destination is received - testing the limits of the path.  Once the limits are known, the orginator settles into a rate just below what can be borne.  Whenever the destination fails to acknowledge the data, the rate is lowered.  Periodically, higher rates are tried again to see if the network has been freed up.

This process is designed to be end-to-end.  The intermediate elements don't do anything but pass the packets, or drop them if there's a problem.  The benefit of the end-to-end here is that the two communicating parties are getting the best estimate of what's available.

What if we don't do this end-to-end?  That means we are approaching communications with either a reservations policy (as in the PSTN) or are doing store-and-forward.  Reserving resources means committing a resource for more time that is it being used, one of the perceived "wastes" in the PSTN.  (Arguably, hearing someone humm into the phone isn't a waste.)

Store-and-forward is the more intuitive alternative.  It requires large buffers to hold the communications going across the network and it also makes streaming of real-time data almost impossible (to manage).  Having to wait to hear a 512 byte datagram at 100Mbps before retransimitting is nothing, having to listen to MB's of a message before retransimitting (at the same rate) takes considerable time.

More significantly, operating a reservation or store-and-forward network means putting more intelligence into the core of the network.  A more intelligent core has always been a criticism of PSTN networks in the eyes of the TCP/IP community.  The less intelligence in the core the more adaptable the network is - i.e., the less is assumed about the traffic flowed the easier it is to innovate at the edges.

NAT is a band-aid to the problem of managing address space.  It does it's job and application protocols can be hardened against the way it breaks end-to-end.  However, by its nature it disrupts the flow, slowing it down (more significantly for some flows and less noticiable forothers).  NAT boxes are one piece of a more "intelligent core", along with firewalls, all of which result in higher operations costs of the core as well as increasing its rigidity.

I am sure there are features other than congestion control that depend on end-to-end, but it is the one that leaps to mind.  Climbing up the logical ladder, store-and-forward in the Network and Transport layers means putting into the network what we really need to keep out, namely "intelligence." In a nutshell, this is (one reason) why technicians clamor of end-to-end in the (TCP/IP) Internet.  "End-to-end" is a basic assumption of the design of the TCP/IP protocols.

Quote: I know that when I trot out the argument that “X” was an original assumption, so it is important, this seems like I am saying that “well, son, that’s the way things are.” But what I mean to impress is that a lot of the succeeding development has occurred assuming “X” and therefore detailing why “X” is important could take a lot of time.

Irrevelant.

You need to show *why the assumption still holds true*.  We have accomplished a lot within the frame of Newtonian physics, but it has since been proved to be insufficient at larger and smaller scales.  The end-to-end assumption may have been true *at the time and scale of the original Internet*—it does not follow that that, and other, assumptions scale to the size and needs of the Internet as it is today.  If the assumption is no longer true, all the successes of yesteryear are worth remembering, but simultaneously insufficient to carry us forward.  I am not as concerned with faithfully emulating past successes as I am with ensuring the possibility of future break-throughs.

I am asserting, in part, that the end-to-end assumption, combined with the scale of the Internet as it is today, the magnitude of the devices and systems out there, and the variety, leads ultimately to dead-end design because the end-to-end protocol architecture not only excludes other protocols, it excludes its own successors.  This hampers further development and progress of the network—such as the adoption of IPv6.  That, I can hold out as a concrete case to support my assertion that the end-to-end model itself hampers the development of the network—the only way IPv6 is going forward is by breaking the end-to-end model and having IPv4/IPv6 cross-connectivity.  The assumption of end-to-end only survives by breaking, not by its adherance.

You have not convinced me that end-to-end is the *only* way of doing congestion control.  Nor have you convinced me that it is of such worth as to over-ride the issues of being locked in another dead-end-to-dead-end protocol.  The fact that my data is able to be transported over ethernet frames, sonet frames, PPP framing, etc., and still survive does not lend any support to this proposition. 

You have not addressed why my applications should care, at the application level, why the transport protocol is end-to-end or not, insofar as the application's needs for network connectivity are met.  It is by no means clear that the end-to-end box is the only solution, nor the best solution.

The congestion 'control' mechanism as you describe it make it sound even more wasteful than the alternatives.  An applications grabs as much bandwidth from the network as it can, regardless of how much it actually needs, until it reaches the point where it cannot grab any more, and backs off.  Then it constantly probes to see if it can't get any more.  This does not sound like actual congestion control any more than removing all the traffic signals from a city sounds like congestion control—everyone should drive forward as much and as fast as they can, until they bump into something, then they should constantly push and shove to try to go faster.  You may need a better way of explaining it to actually make it sound efficient. 

Intelligence is coming to the network.  You can fight it, or you can try to figure out how to best use it.  This is not a mark of failure, but a mark of the success of the network.  We do not have cars with impact sensors, crumple zones, air bags, anti-lock breaks, automatic transmissions, puncture-resistant tires, air conditioning, computer-controlled fuel injection because the concept of the automobile was a failure.  Rather, we have these things because the automobile was a success, and such a success that we in turn require the complexity and the intelligence within the vehicle itself to manage the additional performance efficiently.  There are no doubt people who bemoan the complexity of today's automobile, waxing nostalgic for when automobiles were simple and you could cobble one together in the junkyard.  (There are probably individual cells that bemoan the inefficiencies of having multi-celluar organisms with brains and digestive systems and all that overhead.)

The intelligent network should be looked at as an opportunity, not feared.  I fail to see the ultimate benefit in keeping intelligence out of the network.  "Keep things as simple as possible - but no simpler." is not the same as "Keep things brain dead."

Success is complex and takes work.  Failure is simple and doesn't.

Perhaps my comments were not understood.

If you read my first two paragraphs, you'll see I am addressing why end-to-end is important to TCP/IP.  The Internet today is TCP/IP, or largely TCP/IP.  An unwritten assumption of mine is that the question about end-to-end is about today's Internet.

Sure, there are ways to build communications in other ways, ways in which end-to-end is not a given.  TCP/IP was the result of design decisions made way back when.  Perhaps it is time to review the requirements, the interplantery network study is one such effort.  End-to-end is probably not viable there.

For a better description of the TCP/IP congestion control there are textbooks.  For a generic understanding of the problem, I have always favored a book by Andrew Tannenbaum.  I forget the title, it as written in the 1980's.  That text presents the problems of communications in a theoretical manner, the concepts transcend implementations.  In it, for instance, you'll see why the ALOHA protocol probably isn't best for a X window clients 1 AU away from the server.

Concerning intelligence in the network, I think a lot has been learned from the building of the PSTN.  Trying to make a network "smart" means teaching it one way of business, which is one rationale for Voice over IP work.  Many PSTN concerns are now looking to TCP/IP protocols to improve on their smart network cores.  (Make the service smart, not the underlying pipes.)

I have been told that the Internet serves about 1 billion people.  With estimates that the population of the earth is about a magnitude greater than that, the Internet has a lot of room for growth.  For all the progress to date, I'd be foolish to believe that it can scale one more order of magnitude.  If there is a better way to build the Internet, I'll all for it.  I just haven't seen a better alternative yet.

The problem with analogies is that you have to apply them appropriately.  Yes, cars are becoming smarter but not in the same was as we talk about "smart" or dedicated networks.  My car is "smart" for my commute to work - small, lightweight, agile.  Even though it has an air bag, it isn't so good for hauling trash to the dump.  I need my truck for that, it too has an air bag, but more importantly a large, open, washable bed.  The air bag intelligence isn't helpful when the vehicle is doing its job, it's helpful when there is a failure.

Quote: "If you read my first two paragraphs, you’ll see I am addressing why end-to-end is important to TCP/IP.  The Internet today is TCP/IP, or largely TCP/IP.  An unwritten assumption of mine is that the question about end-to-end is about today’s Internet."

To clarify, my concern is not about today's Internet.  My concern is how we will get to tomorrow's Internet, and the Internet after that, and the one after that. 

Quote: "I have been told that the Internet serves about 1 billion people.  With estimates that the population of the earth is about a magnitude greater than that, the Internet has a lot of room for growth.  For all the progress to date, I’d be foolish to believe that it can scale one more order of magnitude.  If there is a better way to build the Internet, I’ll all for it.  I just haven’t seen a better alternative yet."

I agree.  If it cannot scale one more order of magnitude, then something else will be needed.  My concern is, when that something else developed, how will we get there?  The end-to-end design is a prison, even in IPv6.  Given how bad the transition from IPv4 to IPv6 is, when the time comes that something better than IPv6 is needed, what will *that* transition be like?  Have we learned anything yet? 

With those concerns, I see no reason to move to IPv6, but to try to explore better architectures, one that allow for transitions between protocols and growth, now, rather than repeating the mistakes we are seeing in the IPv4 to IPv6 transition.  So, insofar as the original article title goes, I'm leaning towards IPv6 extinction.  We need to be working on the alternatives that will allow us to reach that order of magnitude more growth—not necessarily an alternative to IPv6 per se, admittedly, but to remove the end-to-end design and acknowledge that there will be *something* after IPv6 that IPv6 devices will have to communicate with.  If we build devices and applications now with the understanding that the end-to-end assumption will not/is not holding true any longer, then future transitions will be much smoother and our ability to advance networking technologies and bring them to deployment faster will be improved.

Again, I assert: The end-to-end design assumption does not hold true for the scale and scope that the Internet has grown to and is growing beyond.  I hold the troubled transition of IPv4 to IPv6 as an example of why the end-to-end design assumption now harms the development of the network going forward.  Regardless of past successes, there is no indication that the benefits of continuing this design mindset into tomorrow are greater than the penalties.

So as with regards to the original article, I feel there is no clear value gained from the IPv6 transition, architecture-wise, because we'll just have to go through a whole new round of transition in the future which will eat up any benefits gained from IPv6 for the short time we have it. 

Quote: "The problem with analogies is that you have to apply them appropriately.  Yes, cars are becoming smarter but not in the same was as we talk about “smart” or dedicated networks.  My car is “smart” for my commute to work - small, lightweight, agile.  Even though it has an air bag, it isn’t so good for hauling trash to the dump.  I need my truck for that, it too has an air bag, but more importantly a large, open, washable bed.  The air bag intelligence isn’t helpful when the vehicle is doing its job, it’s helpful when there is a failure."

Oh, I agree with that entire statement, in all parts, and likewise twist it:  I'd like to be able to use different transport protocols/vehicles as appropriate to the job, commute vs. hauling trash.  Except, again, the end-to-end design principle excludes the possibility of having multiple protocols and having them work together.  I certainly feel that people should be able to choose the vehicles appropriate to their transportation needs, and I feel like-wise about network transport protocols.

Hi Kim, Edward. The correct analogy is roads, not cars. An ideal road has to be flat and straight, end-to-end. Any intellect or complexity of the road is nothing but a problem. Vehicles may evolve and car vendors may innovate without rebuilding the road network.
Regarding the revolution scenario. I've experimented with infinitely-scalable, billions-of-devices, self-configured, potentially-extremely-cheap, unmanned routing scheme (see TAMARA). Exactly the case of "volume, not value". It is not a too complicated task; after dropping some legacy concepts the desired result might be achieved for IPv6 (IMO). But, I found no interest and no funding.

But, I found no interest and no funding.

Welcome to the monoculture of dead-end to dead-end.  If you're not conforming, you're not performing, so there's no interest in developing alternatives or variations.

Kim,

I wouldn't be so harsh to Victor.  You could be right, not being able to get funding is a sign that an idea is not meeting a need, sometimes it is just the sales job.  But a lack of funding may be shortsightedness on the part of the mainstream.  Truthfully, it is rarely the latter case.

The important thing for a researcher is to avoid becoming quixotic (http://en.wiktionary.org/wiki/quixotic) or stuck on solving irrelevant problems.

I've often asked myself if IPv6 has become a quixotic quest.  Does it meet the need or has it become a cause unto itself?  No doubt IPv4 addresses are nearing their capacity, but is IPv6 the answer?  Is it the answer because it's the "last one left at the dance?"

Is it the answer because it’s the “last one left at the dance?”

Well, the mindset appears to be that there should be only one at the dance (i.e. the dead end to dead end conformity).  Given that IPv6 is already out in the real world deployments and dancing, proposing an alternative would have to either interoperate with IPv6 perfectly—i.e. just IPv6 all over again—or be require some form of adaptation/conversion (NAT) between not only IPv6 but IPv4, too.  The dead end to dead end mindset rules out conversion, IPv6 is already out there, and thus there cannot be alternatives to choose among.  So, Victor finds neither interest or funding.

I suspect that in part IPv6 has become a cause unto itself for some folks—some parties have an invested self-interest in IPv6.  Equipment makers, software vendors, etc. who want to keep selling IPv6 upgrades to current gear.  And of course there are people who probably have their reputations and/or egos tied up in the matter.  (Heh.  Look at me!)

To some extent, IPv6 is vastly important to the IETF, to keep the IETF relevant—if there were alternative network protocols, if one could convert/communicate freely between protocols as one can do between copper/fiber/wireless, then the IETF/IP might have competition.  It's a vested interest of the IETF as an organization (not necessarily that of its members) to lock out other protocols.  That's not saying that the IETF is consciously acting like that, just that it does benefit from promoting an dead end to dead end mindset that requires only the protocols of the IETF be used and that 'breaks' if some competitor tried to interoperate with it with a different solution.

(Slightly off topic, but has anyone ever considered how the 'end-to-end' mindset facilitates the development of 'digital rights management'?  I would prefer to view the network as 'gateway to gateway', that there might always be NAT, a conversion from one physical media to another, from one protocol to another, from one format to another.  The data flow does not 'end' at my computer—maybe it gets sent over Bluetooth to a PDA, copied onto an MP3 player, printed out and faxed, etc.  Having a model that insists there are 'end points' and that traffic should only be between these (dead) ends, would seem to facilitate the DRM mindset because it gives something, the end point, to lock files and data in to.  If instead the IP address was never viewed as the final, absolute end point, that there might always be NAT or another conversion of data afterwards, and another after that, and another after that, and that that conversion was required for the network to work, that the conversion of data between network protocols and formats was an integral part of communication, I suspect DRM proponents would have a tougher time of developing solutions.  It would be harder to identify an 'end' machine to lock data to.)

No doubt IPv4 addresses are nearing their capacity, but is IPv6 the answer?

I don't think we may run out of IPv4 literally; it is more like Achilles never catching up with the tortoise. The problem is that we aren't living in the IPv4 world, but we did not get into IPv6 either. The current state of things may be described as "post-IPv4", "ex-IPv4" or even "undead IPv4".
Problems of this state are self-evident. For example, current bleeding-edge very-promising technologies of STUNT/traversal/punching/libjingle/whatever are just a poor reinvention. That technologies are obviously
1) more complex
2) more expensive
3) less effective
4) less reliable
...than our old friends UDP and TCP. People don't innovate but fight consequences instead. Of course, it is bad from engineering/architectural viewpoint but it is good for business. In a world of no NATs Skype Inc doesn't worth much. I think, this road of shame may last for several decades and be "profitable", yes. Why don't charge sites for "premium access"? Why don't charge for IPv4 addresses, finally?

So, my opinion is that IPv6 is not that quixotic, but it is not commercial also until there are tons of small devices crying for connectivity and convergence (one more chicken-and-egg).

BTW, I just figured out that TAMARA could be transparently compatible with IPv6. What a surprise! So, I still believe in the hourglass model and the end-to-end principle :)

Regarding Bluetooth and PDA I think that better way is to assign IPs to that devices. Use any medium you want and any technology you want; just identify every destination with an IP address. Under some assumptions, including no address scarcity, this works, so why not? (Scarcity of numbers is a truly strange problem, isn't it?)

BTW, Kim. I think, your remarks correspond not actually to the end-to-end principle, but to its simplest understanding (which prevails today).
There are other variants. E.g. in TAMARA hosts are identified by prefixes, not addresses. So, there are actually no "dead ends": each host may freely host own network. Still, it is end-to-end in the sense of "dumb network" and "complexity at the edges".

What is this "TAMARA" of which you speak? I can find no network protocols by that name with a Google search.

TAMARA is more of a concept than a protocol. It was discussed above.