Live data from Hacker News

By installing NAT, MIT stifles innovation

blog.achernya.com

111–120 of 188 posts

Re: By installing NAT, MIT stifles innovation

#112
post #95
post #62

Earlier quoted context omitted.

No. IPv6 is great in concept but the world just isn't ready for it yet. Even our Google Wifi access points don't support IPv6 in their latest firmware, so I have no way of using IPv6 even though Comcast supports it. AWS IPv6 support has been sketchy until only this year. Many parts of the world are happily dancing with their IPv4 NAT and their sysadmins have no incentives to support IPv6 whatsoever. Forcing people to…

> Forcing people to use anything is never a good way to promote innovation. Of course it is. That's how innovation happens. They are focused on overcoming a constraint of the system they operate within. In this case, it will be to get around the limitations of the private IPv4 network, or to make the upcoming IPv6 network easier and more appealing to use. Most innovations are to overcome some sort of limitation, whet…

Innovation will happen, but it is heavily misdirected.

What if I'm a biology expert and want to run a server to demo something cool? I should be spending my time doing innovation in biology.

What if I'm a deep learning enthusiast and came up with something cool to demo? I should be spending my time hacking at that.

What if I'm a physics student and want to start a blog?

The majority of MIT students are awesome innovators, but most are not innovators in TCP/IP. Forcing a bunch of people who are not networking specialists and sysadmins to deal with the lack of IPv6 support in the rest of the world is not going to promote innovation where it needs to be.

Re: By installing NAT, MIT stifles innovation

#113

Earlier quoted context omitted.

Nah, NAT doesn't provide the security; firewalling does. Besides, what kind of controlled unclassified information could possibly be residing on dormitory networks?

Sorry, but NAT provides practical security for all but the most pedantic use cases. I'm terrified of IPv6 for this exact reason - it assumes every device will have direct access to the Internet. As we've seen with security cameras and other IoT devices, they just aren't designed to protect themselves and are easily hackable, so making them accessible to the wider Internet is crazy. Firewall options for IPv6 for most…

IPv6 supports NAT...

Re: By installing NAT, MIT stifles innovation

#114
post #101
post #62

Earlier quoted context omitted.

No. IPv6 is great in concept but the world just isn't ready for it yet. Even our Google Wifi access points don't support IPv6 in their latest firmware, so I have no way of using IPv6 even though Comcast supports it. AWS IPv6 support has been sketchy until only this year. Many parts of the world are happily dancing with their IPv4 NAT and their sysadmins have no incentives to support IPv6 whatsoever. Forcing people to…

If your access point wont pass IPv6 traffic - you should consider another AP vendor. I have plenty of older network gear that cannot do IPv6 - but it passes the traffic along un-molested.

I tried 4 different AP vendors (Asus, TP-Link, Cisco) and Comcast did not play nice with them. Random disconnects all the time. Only Google's worked without a hitch. But alas, no IPv6.

(I'm busy and don't have time to deal with this BS. I just need internet access that works.)

Re: By installing NAT, MIT stifles innovation

#115
post #73

Earlier quoted context omitted.

Indeed! If anyone needs to feel the squeeze for IPv4 to make a move to IPv6, it is AWS... which MIT is conveniently selling the IPv4 addresses to!

Sometime, I felt force all IOTs devices, typical laptops, Phones, behind NAT is actually safer for internet as whole. Security via network segmentation. IMO, NAT gateway is good place to lock down and put in network security appliance to track/block all the unwanted connections.

except NAT does neither network segmentation or lock down the network. Those things are done by a router and firewall. Implementing proper security of IoT devices can be solved by A) writing more secure software for IoT devices and B) having a proper firewall solution with sane defaults. Using NAT as a tool to masquerade your IP addres is not secure. see NAT hole punching for example [1]

NAT is terrible from a network engineering perspective, it was mostly a patchwork to deal with the rapid expansion of the internet and the shortage of IPv4 space. IPv6 brings a lot of cool technology to the table in, like MTU path discovery[2], header extensions[3] and proper anycast[4]. It also makes dealing with subnets and network segments a lot more sane and scalable.

[1] https://en.wikipedia.org/wiki/Hole_punching_(networking) [2] https://tools.ietf.org/html/rfc1981 [3] https://www.cisco.com/en/US/technologies/tk648/tk872/technol... [4] https://en.wikipedia.org/wiki/Anycast

Re: By installing NAT, MIT stifles innovation

#117
post #11

A lot of fuss, but if you look at the presentation slide in the middle of the page ( https://4.bp.blogspot.com/-PyyPpTv1p7g/WU7hMEBnm4I/AAAAAAAAE... for reference) it is clear that MIT is not stifling anything or shutting anyone's mouth. MIT is just moving to IPv6. Actually... MIT forcing an entire generation of future engineers to deal with IPv6... That will literally push innovation.

Yes, yes, it’s been three months since the provost triumphantly announced that IPv6 will finally be coming to the campus network, and communication about IPv6 on campus goes back much longer than that, but we have yet to see it in a single building (beyond the buildings where students have set up their own tunnels, and who knows if those will even work with the new network). Meanwhile, the NAT was deployed in twelve…

[deleted]

Re: By installing NAT, MIT stifles innovation

#120
post #8

I'm all for supporting innovation and community services, but I think author is not mentioning other possible causes, like DMCAs, malware and spam (including unintended), which could have damaged the reputation. I just wonder why MIT didn't give more time to move and why it doesn't provide a replacement in eg cloud credits.

If it went down like it did at CMU, IT polarized into a camp that wanted to maintain the traditional stack and a camp that wanted to tear it down and replace it with contemporary cloud services. When the latter won, they wasted no time in salting the earth of the former's territory. Disclaimer: I wasn't actually party to any of this, I heard it second hand, corrections welcome.

I feel like that is different though. In-fact, that transition increased innovation capability in my view as someone who wrote some of the largest reaching on-campus applications at CMU during my time there.

Andrew was pretty dated and virtually everyone I knew was already forwarding their emails through their Gmail anyways. Transitioning to Google Apps was basically cutting out the middle-man while adding on some interesting functionality.

1. Now everyone also had a better calendar system and file sharing with Google Drive within the CMU namespace. This meant that clubs, for example, could create Google Forms that were restricted to actual CMU students with CMU email addresses, and they could use that guarantee to do more interesting things like adding information from the Directory on top of those emails without having to ask for it (such as Major and School).

2. We also got a way to allow people to use their Andrew logins on any student-made website with simple OAuth2 that restricted to using the @andrew.cmu.edu emails on Google Accounts. Before this, apps like ScheduleMan and the StuGov apps (which I developed on when I was there) had to get special permission to use Shibboleth and there were a bunch of restrictions for having those certs including having to run on CMU infrastructure.

Now, any student can create applications with the same login guarantees of only being accessed by CMU students and allow for one-click login and registration (since most relevant information can be obtained by looking up their email in the Directory), vastly increasing the usability of these apps.

In my view, that transition was definitely a net-positive to the CMU ecosystem, in both usability and development.

Post reply on HN