@edbilodeau @eloy There was a ton accomplished my #MIT Project Athena / IS&T (and Project Andrew at CMU) by staff members in the 80s and 90s, with things like Kerberos coming out as a result. Lots of this was to fill niches in Workstation software. Ironically some of these underly some Microsoft protocols. Student groups like MIT's SIPB were also tightly coupled into this

Lots of that staff left for various reasons, and universities shifted to using off the shelf products. Sadly MIT as a whole is now way behind (eg, very little IPv6) and I suspect the same is true of other schools.

That said, the people leaving schools to go work in industry had a huge impact on how many large Internet companies operate. Aspects of the MIT network certainly influenced how #Akamai was architected in the early days, and some of those patterns seeded how some of the other largest tech companies designed things.

@markd @becomingwisest @jschauma #Akamai has made #IPv6 dualstack the default for around a decade for new customer configurations. I talk some about why customers don't dual-stack (and why they should!) in https://www.akamai.com/blog/trends/10-years-since-world-ipv6-launch

Many customer sites have been on long enough to pre-date the switch of the default, but we do still see some rate of opting out. Some top reasons include:

* Operationally conservative and lack of understanding of the value ("if it isn't broke don't fix it" or "seems safer"), or have trouble justifying the effort to make the change safely with testing.
* Lack of support in their log processing and/or header processing and/or advanced business logic for IP handling. For example, companies may be using a third-party anti-fraud product which doesn't support IPv6. With Akamai's large base of Enterprise customers this is frustratingly common and the "just hash the IPv6 to an IPv4" makes things worse rather than helping.
* Auth tokens bound to IP addresses. (eg, setting it via IPv4 and validating via IPv6 fails, or vice-versa -- see https://www.akamai.com/blog/developers/why-you-shouldn-t-tie-ip-addresses-to-tokens )
* Custom or uncommon clients which break in the presence of IPv6. This is rare but I've seen it, for example some local streaming provider may have a user base with old Smart TVs that interact poorly with some ISP's somewhat broken IPv6 setup. I hear this less now, but it used to be common even a few years ago.

Note that it's worth checking both the "www" and apex name version of some of these, as in some cases the apex example.com name is IPv4-only but redirects to a dualstack "www" name due to CNAME-at-the-apex limitations.