The "issues with IPv6" are with education, operation, configuration.
I personally ran WiFi networks with 8000+ wireless clients on a single /64 subnet (my employer's CiscoLive conference), and assisted/consulted in running the networks with more than 25000 clients on a single /64 subnet (Mobile World Congress).
The default kinda suck, and the bugs may happen. but the statement "IPv6 is not ready for production" is wrong.
I'd be happy to volunteer a reasonable amount of time to work with the OP or others having a network of >1000 hosts, to debug the issues like this, time permitting, vendor independent. (glass houses and all that).
There are bazillion knobs in IPv6 and a lot of things can be fixed by just tweaking the defaults (which kinda suck).
Network of <500-700 nodes generally don't need to bother much. It's not optimal a lot of times with the defaults but it will work.
EDIT:
the seeming "charity" of volunteering the time isn't. I want to understand what is broken, so we can bring it up back to IETF and get it fixed + make better educational publicity to prevent folks shooting themselves in the foot. It'll make it to the stacks in another decade, but it will.
IPv6 is powering nontrivial millions of hosts now - so the correct words to use "needs tweaking for my network", not "not ready for production". Let's see what the tweaks are and if we can incorporate them into the protocol, if necessary.
Playing devil's advocate: your experiences of "CiscoLive conference" and "Mobile World Congress" sound like conferences, which are the kind of scenario where most hosts are connected to the network for less than a day each time.
If I understood it correctly, his privacy addresses issue wouldn't show up in that scenario, since it needs several days using the same network connection continuously for each host to accumulate enough privacy addresses.
University campus typically have similar, although a bit less dynamic pattern of usage, than conference type scenarios. We actually observed on different (not just conference, but also campus) that wireless networks in general seem to have the same curve of connection duration distribution, though with different parameters. (If you have a large WiFi net, and would like to collaborate on re-confirming or disproving this hypothesis, please let me know).
The privacy addresses refresh depends on 2 factors:
2) frequency of reconnection. Some platforms (iDevices in particular) decide to make a new the IPv6 address every time they reconnect. Great for privacy (And that's exactly how I ran the abovementioned networks, also take a look at the http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi... for the observed leave/join stats), but if the infra does not have enough leeway to accomodate the extra addresses.
In any case even then not all is lost - clear the "A" bit in the RA to turn off the SLAAC, and use DHCPv6. Poor Android clients will be off the IPv6 grid because they don't bother to implement IPv6 for the reasons left unnamed here, but the rest of the gear will work just fine, with a single, predictable address, that an admin controls.
So, again - it all depends on the local situation and there's no unsolvable problems. There are existing and production-proven solutions.
You imply that DHCPv6 allows admin control, but as I understand it, it is not guaranteed that the request (DUID) can be mapped to a known device (MAC) (Type 1 DUID).
Especially with installation media, it is just not feasible to custom script them to force Type1 usage. This makes bringup and configuration mgmt just rely on IPv4 to get an identity.
I'm running into difficulties with this in our campus deployment. - I need static addresses in DNS (DDNS is just dirty, especially with DNSSEC) and also reverse records for kerberos.
If you talk install, then with most of today's PXE ROMS first thing you want to do is to bootstrap into iPXE to get IPv6 support.
That gives you also the support for pulling in your install via HTTP, with passing the UUID via the parameter in the boot URI.
You can then drag this parameter all the way to the final boot of the client.
I've done a PoC for a zero-touch install setup where you boot up a fresh empty machine and after a while of unattended magic it ends up with the Ubuntu installed and configured to a hostname set to its UUID. The address is registered via DDNS but not direct from the client - it's done via call-home server.
IPvFoo independent and no need to tag to MAC address or any address family whatsoever.
I've a 20-page write-up draft with scripts and all, though needs a ton more polishing for the real world. If it's of use to you, drop me an email, I can send - would be interesting to hear your opinion on that.
I spent a few days designing a thing like this for server deployment, but it was merely pen and paper notes, I would love to read through the draft you've written.
Couldn't find your email in profile - drop me an email at ayourtch at gmail / cisco dot com.
It's too raw to just be dumped on the web, and I'd be curious to hear from a few folks doing this as a "day job" about the usefulness if I were to invest more time in it.
And somehow juniper (and juniper support engineers for large routers) is unaware of these things? I'm skeptical. Particularly for ongoing problems where second and third level support get involved.
Don't be so surprised. There can be corporate-political problems to engineers solving the problem. For example, the official marketing line is "we support feature X!", and while the engineer wants to say "that doesn't work right, turn that shit off" he can't really do that.
Or maybe the solution is to not use Juniper for ipv6. I really don't know. It's possible that Juniper's development process and goals prevented solid ipv6 support - another case where even if their engineers were aware, they couldn't do anything to help this guy.
I wouldn't be surprised if this turns out to be a MIT-environment-specific issue.
E.g. Juniper support wasn't aware of it because they assumed no one would try to use stateless configuration in what would generally be a managed environment using dhcpv6.
Quite a few large environments use SLAAC and they work just fine (though I work for cisco so a bias is quite possible ;-).
But there's certainly something specific to MIT's setup that makes it melt down in such a spectacular fashion with v6. "Forwarding loops" (preexisting?) from the blog raise some suspicion.
The local environment frequently has a huge impact - and for the most extreme/"obvious" cases it took me to recreate the setup in the lab and show folks how it works fine with their config and traffic to make them believe that it was not just stupidly broken - because in their environment they could reproduce the bug every time!
Normally when the big dogs for a product get called in it is to find out why their product has an issue, they are the code experts for that. This doesn't mean they are inherently experts in every protocol their product happens to be using.
Shooting themselves or shooting an innocent and necessary technology. I personally see IPv6 adoption going to a full stall if users are told that advertisers found a way to tattoo cookies on their machines. I am worried by the hostile view on privacy addresses in that article and many of the comments.
Seriously, tracking via your v6 address is a minor concern. Browsers already provide more than enough information to an advertiser to do a really good job of tracking a person as he changes his attach point to the Internet.
Let me ask you a question. (Please address this question, and not some hypothetical situation that isn't covered by this question.) If the combination of my User Agent string, screen resolution, and installed browser plugins uniquely identifies my PC, why should I be concerned that I also have a stable, globally unique IP address?
I agree. This is not great. Though I believe that if this start being used, browser vendors will crack down on this (it is shocking that they give away so much information). But I read that this technique still leaves thousands (if not hundred of thousands) of collisions (particularly on more standardised mobile platforms) so I don't expect that to ever be widely used.
But the fact that there is a leak somewhere else in the house isn't an excuse to create another leak.
Also, browsers evolve and react relatively quickly. Not the IP protocol. When you see how hard it is to switch from IPv4 to IPv6, I don't think I will live to see IPv8! So making a disastrous decision from a privacy point of view in IPv6 will have long and lasting consequences. It's not because Chrome v30something is broken that we should leave a flaw in the IP design.
On "still leaves thousands (if not hundred of thousands) of collisions", here's some research:
"In 2010, Eckersley demonstrated that benign characteris-
tics of a browser's environment, like the screen dimensions
and list of installed fonts, could be combined to create a
unique device-speci c ngerprint [7]. Of the half million
users who participated in Eckersley's experiment, 94.2% of
those using Flash or Java had a unique device ngerprint,
and could thus be identi ed and tracked without the need
for stateful client-side technologies, such as browser or Flash
cookies."
Yeah but keep in mind that as soon as you install or update anything on your machine your signature changes. And I would be surprised if there was less than hundreds of thousands collisions on Android or iOS browsers.
In any way this is a flaw in the current versions of the browsers, but by no mean a structural flaw that justifies giving up randomized IPv6.
Who's talking about removing IPv6 "privacy" addresses from the standard?
I am addressing your assertion ("I personally see IPv6 adoption going to a full stall if users are told that advertisers found a way to tattoo cookies on their machines.") with facts that demonstrate that today, even behind an IPv4 double-layered CGN, your web browser makes your machine just as trackable as if you had a single, globally-unique IP address.
(In fact, if you've a mobile device of any sort, your web browser makes you more trackable than IPv6 [as deployed] does, as your address changes as you change attach points, but your device and browser fingerprint does not.)
ay is addressing your misunderstanding of the effectiveness of browser and device fingerprinting.
Neither of us are talking about removing "privacy" addresses.
The question is not about removing privacy addresses from the protocol but whether users will be able to use them. If network administrators, or more worryingly ISP force onto users things like RFC7217 then I think this is a problem. All I am saying is that I am a bit worried of reading lots of comments advocating effectively static IPs.
I wonder if the genie is not already out of the bottle anyway. I think pretty much every recent version of windows that support IPv6 has randomized IPs turned on by default so this will require a lot of efforts to reverse this.
I am not expert enough to form an opinion on the problem described in the article but it looks to me more like a problem with the implementation of multicast than with randomized IPs, and therefore disabling randomized IPs (the solution the author opted for ultimately) is in my opinion not something I would like to see generalized.
And again browser fingerprinting is a short term problem. How many versions of each of the major browsers have we seen in 20 years, versus how many versions of the IP protocol have we seen over the same period?
> The question is not about removing privacy addresses from the protocol...
This is correct. The issue at hand is talking about just how short-sighted and mis-informed this statement is:
"I personally see IPv6 adoption going to a full stall if users are told that advertisers found a way to tattoo cookies on their machines."
The only person who's talking about IPv6 "privacy" addresses is you. I don't understand why you keep bringing them up in a conversation about the effectiveness of browser fingerprinting.
I skimmed RFC 7217. It's not incompatible with "privacy" addresses. The RFC in question even mentions the orthogonality:
"The method specified in this document is orthogonal to the use of temporary addresses [RFC4941], since it is meant to improve the security and privacy properties of the stable addresses that are employed along with the aforementioned temporary addresses."
I don't see what your problem is.
If you're not interested in talking about the effectiveness or lack thereof of browser fingerprinting techniques, then I've no interest in continuing this conversation with you.
whether to allow the randomized addresses or not is a choice available today with no protocol changes whatsoever.
A network admin can turn off the "A" bit on the prefix in the router advertisements and turn on "M", and the compliant hosts will use DHCPv6 to get the address, which one will allocate statically per-user. This is exactly the same as "no privacy addresses".
ay's comment is great. You dodging my question? Not great.
I have to ask, have you even visited panopticlick? Go visit, using the browser that you typically use to browse the web. Slow your roll, and take time to actually understand what the site is telling you.
Also: "I believe that if this start being used, browser vendors will crack down on this".
You... are clearly not aware of what's happening in the Internet advertising space.
Visit https://panopticlick.eff.org/ (I mean it. Do this. Don't just blow hot air.) and ask yourself which of those things that the browser has been happily giving away for ages could easily be removed without breaking much of the useful functionality of the web.
Well, I thought my comments did answer your question.
- the fact that this signature works today (and I am not convinced it is actually so unique and stable to be really useful, again you don't have flash or java on iOS nor can you really customize the browser, so you will have lots of collisions) doesn't mean it will forever, for instance flash, java and silverlight are on their way out of the browser. And the more plugins and fonts you have, the more unique your signature is, the more likely it will change as a result of updating something (typically at least once a month) and therefore the less likely it will be useful to tracking you (your identity changes regularly).
- the fact that there is a flaw already doesn't mean we should introduce another one.
- IP protocol is evolving much more slowly than browsers and therefore a flaw in the IP protocol is a lot more problematic than a flaw in a current version of the browser.
If you're not convinced that browser fingerprinting is a useful tool in an advertiser's tracking toolkit, then you need to read what the EFF, lcamtuf, and other security researchers have to say. Or, you could just go work for a grey or black-hat internet advertiser.
It seems to me that the presence of a "bazillion knobs" is a bug in itself. A stable system can not depend on puny humans for its operation—nor should a design be able to blame puny humans for its failure.
The maxim "every tuneable parameter is a design weakness" applies for top-down design, but not so much for something as foundational as the IP layer.
In the 70s, TCP's inventors imbued it with solid fundamentals, but could not have anticipated how the protocol would need to evolve in the future w.r.t. security and performance. For IPv6, there are unknowns that will only encountered at scale, and implementors are hugely motivated to play fast and loose with the spec. (TCP Fast Open converts!)
Bottom-up systems have inherent wiggle room, and shipping them with sensible defaults is only possible in the short term. That's not to say we should design over-complicated systems, but just that fine tuners are not a weakness.
It's a very noble goal, and a pity HN has only one upvote per reader :-)
But, designing a ship that 10 years post-release can fly and dig under ground on a whim is a pretty high bar - and would be interesting to learn of successes elsewhere, if you know.
Some of the "weird" IPv6 knobs today are actually very useful, though from what I know, I must've been one of the first known instances to abuse some of the non-defaults at a 10K+ users' scale.
So, I'd say - keep "no knobs" as a goal, but still leave the dirty knobs somewhere to turn in case of emergency. You'd be thanked, if by accident your protocol get used 15 years later :-)
> My philosophy for a long time has been "every tunable parameter is a design weakness, and every one that must be tuned is a bug."
It's completely true that good defaults are essential. But no one person is competent to make a decision for everyone everywhere. It should always be possible to change something but ideally it shouldn't be necessary.
The interesting thing about software: excepting DRM, it's always possible to change something. Don't like a "fixed" parameter in your IP stack? Patch your kernel.
I'm honestly surprised people don't take more advantage of "tuning the source" as an solution to providing end-user flexibility (the only project that I can think of that does is nginx.) Maybe it's because we have "dev ops" (devs who end up doing ops) but no "op devs" (operators who know how to code.)
It's still possible even with DRM, it's just more work. You have to get out a debugger and write new code.
But what I meant was that you shouldn't try to make modifications impossible. Yes, it's futile anyway, but it's a bad idea independent of that.
If you've designed the system right then the users shouldn't need to modify it. So if they do it's a signal that you've missed something and then you can improve it. Whereas if you declare yourself the final authority and refuse to facilitate user modifications, or worse actively interfere with them, then any mistakes you make are silently uncorrectable.
100% agreed. This is why I'm liking elementary OS so much. I still need to pop into the command line for some things, but the standard GUI software is less excessively configurable than most. They have an HIG and a small community of developers who actually pay attention to it.
A lot of it is based on the GNOME core applications, so it's similar. I haven't used GNOME enough to say more than that. For the people who want extra options, there's elementary-tweaks, similar to gnome tweak tool.
How many users will want to change the file naming or folder hierarchy convention for their music library if they're managing them through a GUI application? Why is there a big list of "visible columns" checkboxes instead of setting that by right-clicking the columns? Does crossfade really need a whole tab for a checkbox and slider (and why does it need a checkbox when 0 seconds implies no fading)? Do people actually use crossfade anyway? I never have.
In short, there's room to clean a lot of things up. Even if it's minor, doing it across the entire system makes things a lot nicer. Plus there are some additional system-wide standardization features that elementary is doing, which should prevent a lot of inconsistency from software from all reinventing the wheel in different ways:
How many users will want to change the file naming or folder hierarchy convention for their music library if they're managing them through a GUI application?
I do.
Do people actually use crossfade anyway?
Yes.
The past decade has shown a disturbing trend in design. B-level designers think they can ape Apple by optimizing for the middle of the bell curve and alienating the edges. The problem is that the actual distribution of feature usage is multidimensional in a big way, and these designers delete features on one axis that otherwise very average users absolutely depend on.
There's the saying that 80% of users use 20% of features, but no users use the same 20%.
I'm not saying it's ideal for everyone, but it's an Ubuntu derivative, and it will continue to exist alongside Ubuntu. Noise will exist alongside Rhythmbox. I like a lean, well integrated player as the baseline "everyone gets this by default" option. Out of curiosity, what's the naming/organization system that you use, and is there a reason you don't like "Music/Artist/Album/# - Song.mp3"?
And re:crossfade, if people other than me really use it, then my complaint is that they added an entire "playback" tab in the settings for it. If there's only one playback setting, give it a header under General. It's the visual equivalent of a "for i in range(0):" loop; all it does is make your interface harder to read.
Noise is still an early version and I'm sure there are features that will be added, but "Print CD jewel case insert" isn't on the high priority list. That might have been neat when iTunes first added it, but it's just more cruft now. 1% of people might burn CDs in iTunes today, and only 1% of that 1% will even realize they could print an insert to go with it.
Even on OS X where every computer ships with a pretty effective (if not always snappy) media player, there are plenty of alternatives for people who don't like iTunes.
> and is there a reason you don't like "Music/Artist/Album/# - Song.mp3"?
There are tons of reasons I don't like that format. It's extremely limiting and it only applies to a few genres of music. It tries to fit all music into a rigid hierarchy of bands, albums, and tracks, a hierarchy which applied to a reasonable amount of popular music from the '70s to the '00s, and it makes me wonder if the designers of music players ever listen to anything else.
Suppose the song is a collaboration. Which artist directory does it go in?
Suppose the song is a promo track that you downloaded from a band's website or from Bandcamp. What's the album? What's the track number? What happens when the track is eventually released on an album?
Suppose the "song" is the third movement of Bach's Unaccompanied Cello Suite No. 1 (BWV 1007) as performed by Yo-Yo Ma. Who's the artist? What's the album? (If you're going to say "the album that Yo-Yo Ma's recording was released on", you'll have to be more specific.)
Now can you give answers that put things in the same organizational scheme when it's the second chorale of Wachet Auf (BWV 140) as performed by the Bach Cantata Pilgrimage, directed by John Eliot Gardiner?
Suppose the song is Monstrous Turtles, by Zircon, a remix of Koji Kondo's "Super Mario World" music, released as OCRemix #1558. Is "OCRemix" an album under "Zircon"? Is it track number 1558? What about the fact that most OCRemixes are not by Zircon? Does it go in the same place if you download it from Zircon's web site instead of OCRemix?
> There are tons of reasons I don't like that format. It's extremely limiting and it only applies to a few genres of music. It tries to fit all music into a rigid hierarchy of bands, albums, and tracks, a hierarchy which applied to a reasonable amount of popular music from the '70s to the '00s, and it makes me wonder if the designers of music players ever listen to anything else.
And here are Rhythbox's five options for library folder naming.
Your library sounds like a perfect case for unchecking the "Keep Music folder organized" and just managing it yourself, since there's no single pattern that will work for the whole thing. Incidentally, that's the one library organization option that elementary OS has.
And taking another look at Rhythmbox, either there's no option for "Let me organize my own damn files," or they hid it somewhere unrelated. Maybe you can launch it with a command line flag to do that...
Millions of people are using it today, one and a half decades after it was conceived. It's not perfect but nothing is.
If you have examples of tech to compare with - please bring them in!
EDIT: and yeah, a lot of knobs does sound like a bit of a poor design, but on the other hand, today, 1.5 decades later, I am grateful I can tweak some of the defaults!
Again, if you know something knob-less that'd get flawlessly deployed in 15 years after it was designed - shout, would be very useful to try and learn from that success!
The nearest comparison to IPv6 is DNSSEC. IPv6 has done a little better, but that's not saying much. Both suffer from massive over engineering, and lots of false starts and back pedaling over the years. Trying to solve too many problems, and therefore failing to solve the one problem that's of immediate concern.
False starts and backpedaling are also known as "iterating". It's disappointing that many of the planned features never got production-ready. But the protocol is now more likely to be implemented than ever before, which is the primary "feature" to which all others are secondary.
I was looking for the example of the sparkly unicorn protocol from 2000 the people seem to evoke, which does not need any knobs and is available on every device to update some other protocol from 1970s.
(I suppose the hard meta-question to protocol designers is: how do you make sure your children will not hate you for the protocol you have imposed on them today ?)
UTF-8 updating ASCII is probably the best example of this going well. And even then there was a terrible mistake made in the design of Korean encodings which had to be fixed.
Both yours and tedunangst example (SSH) have one important commonality which is not present in IP: they become immediately available to two parties as soon as these two parties upgrade.
With IP, all the intermediate nodes need to upgrade to use the new protocol (tunneling tricks aside).
This difference would probably be a significant factor in the speed of adoption. Tunneling obviously can emulate the 2-party model, but then we're left with the problem of managing the crazy amount of tunnels (and security issues) and sunsetting them.
I have no experience with Korean and Unicode but, I guess, it's jamo composition?
With it, there are two distinct and not-really-compatible (since anyone in real world practice rarely cares about Unicode normalization) ways to specify a single Hangul character. And that should make text processing a bit painful.
Anyone who writes software to deal with unicode really better care about unicode normalization!
You are going to have all sorts of edge case bugs and unexpected behaviors if you don't, definitely not limited to Hangul. There are multiple un-normalized ways to write all sorts of on-screen glyphs, including Latin alphabet ones.
I thought wbl meant something to do with the combination of Korean and UTF-8, whereas jamo composition is no more related to UTF-8 than any other unicode encoding.
They moved the Korean encodings at one point in the early 1990's. Luckily this was before anyone used it, but it was still a big mess. I don't know why they had to move it.
...and thanks to the knobs for being able to workaround the day1 bug uncovered just this year in at least one of the widely used vendor's server implementations while getting the fix.
But yes, with just 2 parties involved into any instance of the protocol enabling easy upgrade/downgrade path, and tight engineering it is indeed a beautiful protocol.
I would say IPv4 had that property. Not exactly knobless but there are reasons it replaced just about every other networking protocol in existence and simplicity and robustness probably had a lot to do with that. Of course hierarchical routing was a huge feature for the Internet but not necessarily compelling enough to drive out every other LAN protocol.
> I would say IPv4 had that property. Not exactly knobless
I can tell you haven't tried creating/setting up your own router with NATing, separate subnets (secure, insecure), inbound and outbound VPNs, firewalling and traffic shaping. Or basically anything non-trivial with IP in general.
The amount of knobs which you can (and must) set correctly for this thing to fly is enough to give an experienced engineer severe paranoia.
Actually I have done most of those things at one time or another.
I'm not saying IPv4 is simple (especially if you want to do complex things with it) but it works well when configured correctly and is simple enough to be deployed in businesses of all sizes as well as home networks.
I didn't get involved with networking much until shortly after most other protocols were rapidly disappearing but the fact that IPv4 replaced IPX, DECNET, AppleTalk, etc in only a few years time suggests that it probably wasn't that much of a nightmare to set up, even in it's early days.
My concern with IPv6, based on this post, is that it may have lost some of the robustness and relative simplicity of IPv4. I mean layer 3 <-> layer 2 address mapping is fundamental to any network and if that's breaking with IPv6 it could be a pretty serious issue.
It's free, very high quality content, and it is written as if you co-design the new IP protocol together with the author - you start from "why" and arrive to "how".
Absolutely that's why all network pros advise against tuning the timings for a v4 network even though in some edge cases it can help unless you really really know what you are doing.
How can you be so certain that the author's issue is not real?
If you have enough information to be sure that the author's situation isn't a genuine problem with IPv6, why don't you also have enough information to say what the administrator's mistake is, and its solution?
I don't mean to be snarky considering your generous offer to help, but your certainty that the problem isn't with IPv6 seems odd, given the specificity of the author's description and analysis.
That's not what I said. There are plenty of very real and very painful ways to shoot oneself in the foot with IPv6, especially in a larger kind of network that I can imagine the folks at MIT have.
But based on my experience with running the real-world IPv6 networks of large scale, there has to be a better solution than just "turning off IPv6" - even if it is a great interim band-aid after being up for 40 hours! (and I emphasize with that!)
The blog entry says: "The most serious issue is that there appear to be bridge loops occasionally being created". IS this something related to IPv6 ? Specific to IPv6 ? What's the root cause ? IPv6 with default settings in a larger net has very nonlinear behavior in the case of unreliable connectivity, and can make the situation worse.
The other issue, multicast group overload, should be solvable by making the switches blind to MLD.
This will make it as "bad" as IPv4, but in todays' network size it will work fine because IPv4 works, mostly. Meantime they would need to kick their vendor's representative to have it fixed.
Also, a nit about the whole issue at hand: the "worst offender" is iOS, which will create a new privacy address everytime you disconnect and reconnect to WiFi. And if you were to "fix" that, imagine the wrath of the "privacy advocates" about this.
Privacy addresses in IPv6 are very valuable for a reason that due to a fast refresh cycle they help to uncover a lot of corner cases that would otherwise pop up with a kind of "shrug, something weird" type of RCA. And fix them before the IPv6 usage hits 50% (cf my comments on the other thread).
(From the privacy standpoint, privacy addresses are a pretty entertainingly weird construct.)
So to summarize this somewhat long-winded post: no question there's a problem. Whether it's in "IPv6 the protocol" or "IPv6 the vendor implementation" or "IPv6 the configuration" is another story. And that'd be something to understand and fix - but needs more info/context/legwork IMO.
I have dealt with MIT network admins who while not infallible are pretty darn competent. If people like this don't know or cannot fix the problem then there is a very real issue with the process by a which ipv6 is taught. It is not reasonable to have a super duper airplane if the pilots you have cannot fly it safely.
The complexity and general human unfriendliness is a major downgrade from ip4 to ip6.
By no means there's any doubt in MIT admins' competency. Just that by reading the encounter, I feel sorry for the cards they've been dealt with, so to say:
1) a s/w hang for which there was no way to advance in a getting a solid RCA. This alone is a very hard one, and I know the ugly feeling both from the customer's side and from the vendor's side when all you have as an action plan is to try to reduce the potential exposure to what you think the problem is. I've been there myself multiple times, both as a customer, and as a vendor support.
2) Bridge loops. You can fix an active loop by disconnecting links, but root-causing such a problem is not a piece of cake, by far.
4) TCAM overload (?) due to privacy addresses rotation. "TCAM space dedicated to IPv6 multicast is only 3,000 entries. That would be just barely enough to support all of CSAIL". The network gear frequently allows to re-carve the TCAM space - maybe they might have taken some space from IPv4 which is by default is provisioned much more generously (for various reasons outside the scope for this thread).
Besides just brute-forcing, there might be other strategies in dealing with the temporary addresses - actually shortening the valid lifetime and bringing it closer to the preferred lifetime should work. This gives me some useful material to update my IPv6 troubleshooting talk with.
So, no, MIT folks are by far not stupid - it's the problem that is complicated - and, after staying up for 40 hours, whatever helps to reduce the pain is good.
But I'm confident there's more learning here to be done from this unfortunate incident.
I personally ran WiFi networks with 8000+ wireless clients on a single /64 subnet (my employer's CiscoLive conference), and assisted/consulted in running the networks with more than 25000 clients on a single /64 subnet (Mobile World Congress).
The default kinda suck, and the bugs may happen. but the statement "IPv6 is not ready for production" is wrong.
I'd be happy to volunteer a reasonable amount of time to work with the OP or others having a network of >1000 hosts, to debug the issues like this, time permitting, vendor independent. (glass houses and all that).
There are bazillion knobs in IPv6 and a lot of things can be fixed by just tweaking the defaults (which kinda suck).
Network of <500-700 nodes generally don't need to bother much. It's not optimal a lot of times with the defaults but it will work.
EDIT:
the seeming "charity" of volunteering the time isn't. I want to understand what is broken, so we can bring it up back to IETF and get it fixed + make better educational publicity to prevent folks shooting themselves in the foot. It'll make it to the stacks in another decade, but it will. IPv6 is powering nontrivial millions of hosts now - so the correct words to use "needs tweaking for my network", not "not ready for production". Let's see what the tweaks are and if we can incorporate them into the protocol, if necessary.