Hacker News new | comments | show | ask | jobs | submit login
Next Generation MITnet (github.com)
106 points by zx2c4 9 days ago | hide | past | web | 41 comments | favorite





So they knew that IPv4 address space is nearing exhaustion, and they that they are using only 2 mln out of 16 mln addresses yet they decided to wait until now? And instead of returning the addresses (like Stanford did) they want to sell them?

Why not sell them?

- It's not clear to me who benefits from just giving IP addresses back to ARIN. I guess it means everyone (presumably mostly telcos and cloud providers) get IP addresses a little bit cheaper.

- I'm not sure why MIT is under some special obligation to give back their old, pre-ARIN addresses that they got in the early days of the Internet relative to the variety of corporations who still own the blocks from the same regime including Halliburton for example.


Sort of reflects on MIT's business school (Sloan) vs. Stanford's, I'd say.

Why business schools rather than institutes as a whole, bureaucratic structure, beliefs of particular powerful people on campus, etc.? I'm not sure what this comparison has to do with Sloan and GSB.

MIT found a way to monetize something that Stanford had given away for free. Not saying it's right, but it's a business decision. Also, it's a joke. People seem to be taking it rather seriously, which says more about their levels of (in)security than anything.

This has been said many times in many places before, but the decision not to design IPv6 such that it is backwards-compatible with IPv4 is one of the worst technical decisions ever made, at least when it comes to organically adopting a new standard.

The second worst decision would be not auctioning off their 16 million IPv4 addresses, right now, probably at peak value of around $250 million.


There are a whole host of standards to support interoperability between v4-only->v6, v4/v6->v4, v6-only->v4 addressing. I know it doesn't answer your complaint, but really there is little "backwards compatible" to be done with 32 bits of address + 16 bits of port that doesn't look like another version of NAT, and we all know how much the tech community loves to hate on NAT.

The transition hasn't really been that bad, it's picking up pace precisely because there is increasingly valuable commercial logic in doing so (v4 addresses cost a fortune, as you noted!)

I've been surprised on a number of occasions recently to notice I've been communicating by v6 from public wifi, other peoples' homes, etc. Progress is slow but it is also sure.

In the UK, once BT flick the switch on their home offerings, there will be very few significant sources of v4 traffic left in the UK still awaiting transition


> we all know how much the tech community loves to hate on NAT

This, I think, is the unpopular but true reason the IPv6 transition has been slow. It ties together two changes, "get rid of IPv4" and "get rid of NAT", and making a business case for doing both of those simultaneously is very hard. Lots of people understand NAT. Lots of vendors understand NAT. Lots of managers understand NAT. ("NAT", of course, means "PAT with implicit firewall," but "NAT" is the term people use.) You can get the same security and privacy benefits and an equally good or even better design without NAT, but that's not what people are used to.

If IPv6 had been a straightforward extension of IPv4 to 128 bits instead of a bunch of cool and reasonable and backwards-incompatible ideas, the transition would probably be done already. The tradeoff, of course, is we'd still be on the same quality of architecture we have on IPv4.


How exactly would this straightforward extension of IPv4 to 128 bits look like? How would it differ from how IPv6 today looks like?

Frankly I can't see any way (that has at least some degree of sanity), to make a backwards-compatible replacement for IPv4 with significantly more address space than IPv4.


No implication that NAT is bad. 6to4 space (and RFC 4193 space, if needed) would be explicitly okay for use with NAT, like RFC 1918 space. Allow NAT from IPv6 on the inside to IPv4 on the outside, as well as IPv6-to-IPv6 NAT.

Extend ARP to support IPv6 addresses instead of designing NDP. Use DHCPv6 like DHCPv4. Don't have SLAAC; encourage the use of existing techniques (static addressing or DHCP). Don't have RAs.

Don't have privacy addresses, because they're not needed, because NAT is expected. Don't have Teredo, because again, you're expected to get IPv6 addressing from some NAT technology.

Note that I'm not super advocating for extending the IPv4 space to IPv6, except via 6to4 if you want to. IPv6 continues to be its own space. But the advantage here is that you don't have compatibility problems from clients that support RDNSS and not DHCPv6 (looking at you, Android) or vice versa, because the way you do things in IPv6 is just like the way you do them in IPv4 and you can use the existing software stack with just a different typedef. You don't have problems with IPv6's infatuation with multicast and aging network architectures that only begrudgingly support it and fall back to broadcast quickly (cf. https://blog.bimajority.org/2014/09/05/the-network-nightmare... ); you're only using network features that IPv4 already requires your hardware to support. And so forth.

No implicit 64/64-bit split in addresses, where if you want to build an equivalent architecture to IPv4 NAT, you must have at least a /64 (there are plenty of service providers that give you a /128, and your only option becomes NAT66). With IPv4, if you get so much as a /31, you can usefully put two computers behind it. With IPv6, there's no way to implement, say, SLAAC with a /127; you have to use static addressing or DHCPv6. And you lose privacy addresses, which means you have less effective privacy than IPv4 NAT.

That's the sort of thing I mean by "backwards compatible."

Once we're on IPv6, by all means, convince everyone that you have better ways of doing everything. But if you tie the IPv6 transition to "NAT is bad and if you need it you suck", "multicast is great and if you don't support it you suck", etc., the only thing you'll succeed in doing is delaying the IPv6 transition.


You can still do NAT with IPv6. At least the Linux kernel supports it.

> but the decision not to design IPv6 such that it is backwards-compatible with IPv4 is one of the worst technical decisions ever made

No. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space. Adding an IP Option to IPv4 packets that could carry extra address bits was not an option -- IP options aren't preserved much at all on the Internet: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-...

Furthermore, even if most routers didn't drop IP options, adding address space via IP option in a packet that old devices would nevertheless parse would have been hell operationally.

IPv6 has its flaws and its weirdnesses (multicast, mobility, slaac, etc.) might not all look so good as they did in the 90s, but the one thing that was unambiguously done right was a clear separation of address spaces from IPv4.


It would have been difficult to design it in a truly backwards compatible way, but it would have been nice for the the two protocols to be able to interoperate (ie, a packet could have an IPv4 source address and a destination IPv6 address, and vice versa). There's a draft RFC about this [1], but realistically speaking, it's probably far too late for anything to be done.

[1] https://tools.ietf.org/html/draft-omar-ipv10-01


The first RFC for IPv6 was published by Xerox PARC in 1995. This was right before the Internet started to grow exponentially, so I can imagine the people who designed it was not planning a super soft/organic transition, and they probably considered that good backward-compatibility with IPv4 would be too hard and not really necessary.

Assuming Amazon paid them money for the IP addresses (which are now allocated for EC2 use) it's kind of a shame.

A more forward-thinking deal would have bartered for, say, a lifetime allocation of Amazon Web Services credit.

For the past 5-10 years timeshare computing has grown in popularity again, this time on third-parties' computers. Given this reality and the changes it implies for MITnet -- lots of students and staff spin up "a server" to do experiments that they don't want to host on local physical machines -- it would have been smart for MIT to negotiate some perpetual timeshare credit with Amazon rather than just straight-up cash.

Then (my theory continues) MIT could have allotted some of its information-processing credit for research use and some for student use. They could have given each student a basic quota with the vendor, and reserved some additional information-processing for student projects.

And instead of hiring some full-time staffer to coordinate the distribution of timeshare credit to worthy projects ("I need 100 hours of EC2 c4.large for my thesis") they could have done something really clever and asked students themselves to divvy up the credit via an advisory organization of technically minded folks.

Imagine that -- MIT could have helped support some kind of student information processing board …


> A more forward-thinking deal would have bartered for, say, a lifetime allocation of Amazon Web Services credit.

You'd prefer an unlimited gift card over cash? Amazon is a top provider in cloud services now, but you'd be betting a lot on them in the future and essentially locked into their platform (if you wanted to get fair value for the IP addresses). Cash is a much safer deal, and as noted they will invest it anyway.


Money that is put into an endowment fund effectively is a lifetime credit for anything.

Previous discussion (where I originally posted this gist): https://news.ycombinator.com/item?id=14150854

> David Clark, a Senior Research Scientist at our Computer Science and Artificial Intelligence Lab (CSAIL) quickly saw the importance of these addresses and requested an early allocation of them, both to support research and eventually to support all of computing at MIT. We hold a block of 16 million IPv4 addresses.

Smart man.

Anyone got a guess as to how much money this sale might raise?


This was (indirectly) on HN yesterday... https://news.ycombinator.com/item?id=14150854

I'm seeing numbers between $10-$20 per IP, but this is also probably a bulk sale so there might be a discount... Say +/- $250 million?

Perfect time to sell them off as the IPv4 shortage tightens and IPv6 hasn't reached critical mass yet.


> but this is also probably a bulk sale so there might be a discount

I was thinking the opposite - isn't the block (or a sub-block) worth more in bulk than its constituent addresses?

In the same way that a complete collection of N Foobars has more value to a Foobar collector than N times the average value of a collectable Foobar.


Is there any way that I could buy an IP from the MIT address block? As a memento.

Microsoft charges $0.004/h for a static IP. That's $35 annually and $280M/year for 8 million addresses. So perhaps the sale will give MIT a billion?

They're selling the addresses, not renting them.

based on [1], prices seem to hover around 10-15$/ip. So, 80 million maybe?

[1]: https://ipv4marketgroup.com/broker-services/buy/


They should do the responsible thing and give it to ARIN. They don't 'own' the IPs and really have no right to sell them.

With that said, they basically built the Internet so I won't hold it against them.


They have a pre-ARIN allocation, so the rules are different. I also have a pre-ARIN allocation (only a /24 though.)

ARIN doesn't 'own' the IPs either.

(The fact that MIT refused to recognize ARIN's rights over the IP space was historically why ARIN never gave MIT an IPv6 prefix, or so I hear....)


I've never signed the legacy registration agreement for my IP space, either. I've had it since 1993, before ARIN existed.

What did you do with it ?

I have it routed to a rack at a local datacenter. I use it for hosting personal projects, etc.

Wow, they only use 2 million out of the 16 million addresses in their stockpile? It would be interesting to be able to trade IPv4 addresses on an exchange.

There's stuff like http://www.ipv4auctions.com/

We recently bought a /24 for ~$4k and now use it with Vultr's BGP support.


You should see the other companies that hold /8's apple for example owns 17.0.0.0/8 and barely uses any of their 16 million addresses

Won't this just delay the adoption of IPv6?

Depends, some who cant migrate will keep living on these, and maybe later switch. Maybe even helping those migrating to do so by ensuring future customers in a while.

No, because adoption of IPv6 is limited by other factors (budget, laziness, bugs, etc.) than IPv4 scarcity.

" Our intention is not only to advance our own agenda, but to help shape the future of the on-line world. For instance, non-technical issues are now shaping the future of the Internet as much as, if not more than, technical innovation."

Did they just say they were going to be funding politics and activism with most of the money?


No. They're more likely to be talking about social-science research, and tools to apply that research. How about better tools to understand public sentiment, to analyze or sort content, to facilitate positive online interaction? How those tools are used might be political, but the science and technology behind them are not.

It was only a matter of time before this happened, I've been trying to come up with ballpark estimates as to how much they could have sold the /9 for but I can't seem to find too many numbers on how much a block of ip address actually costs.

$11-15 per IP and that was what I was seeing three years ago. So if that lower end is still valid (would seem unlikely) then something over $90 million.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: