Next Generation MITnet
gist.github.com
gist.github.com
- 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.
The second worst decision would be not auctioning off their 16 million IPv4 addresses, right now, probably at peak value of around $250 million.
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
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.
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.
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.
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.
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 …
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.
Smart man.
Anyone got a guess as to how much money this sale might raise?
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.
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.
With that said, they basically built the Internet so I won't hold it against them.
(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....)
We recently bought a /24 for ~$4k and now use it with Vultr's BGP support.
Did they just say they were going to be funding politics and activism with most of the money?