UCLA, CIsco & More Launch Consortium To Replace TCP/IP

alphadogg writes Big name academic and vendor organizations have unveiled a consortium this week that's pushing Named Data Networking (NDN), an emerging Internet architecture designed to better accommodate data and application access in an increasingly mobile world. The Named Data Networking Consortium members, which include universities such as UCLA and China's Tsinghua University as well as vendors such as Cisco and VeriSign, are meeting this week at a two-day workshop at UCLA to discuss NDN's promise for scientific research. Big data, eHealth and climate research are among the application areas on the table. The NDN effort has been backed in large part by the National Science Foundation, which has put more than $13.5 million into it since 2010.

Comments

Great idea at the concept stage.

[Anonymous Coward]

Just don't expect anyone to early adopt except the usual hypebots and yahoos. We can't even get rid of IPv4 and you want do replace TCP entirely.

Re:Great idea at the concept stage.

[Jeremiah Cornelius]

Yeah. And replace UNIX, too. You know? Like Plan 9 and Windows NT.

I ain't holdin' my breath.

Re:Great idea at the concept stage.

[Enry]

This. There's likely trillions of dollars invested in IPv4 that is going to be around for decades. Consider the Internet like highways and train track widths - we're stuck with it for a very long time.

Re:Great idea at the concept stage.

[Anonymous Coward]

Yahoo is not that technologically progressive of a company. It's unlikely that they will adopt it :p

Re:Great idea at the concept stage.

[binarylarry]

You know some kind of ill conceived "content protection" is going be built into this protocol.

Re:Great idea at the concept stage.

[Bengie]

Most IPv4 hardware can't handle modern Internet speeds, which are increasing 50% every year. Some newer tech is improving closer 3x per year. You'll get left in the dust sticking with IPv4 only infrastructure hardware for big networks.

Re:Great idea at the concept stage.

[Jeremi]

This. There's likely trillions of dollars invested in IPv4 that is going to be around for decades. Consider the Internet like highways and train track widths - we're stuck with it for a very long time.

I'm probably missing the point, but isn't NDN just a way to do content-addressable lookup of data? And if so, why would we need to throw out IPv4 in order to use it? We already have lots of examples of that running over IPv4 (e.g. BitTorrent, or Akamai, or even Google-searches if you squint).

Re:Great idea at the concept stage.

[mattack2]

Umm, the "Internet of things" doesn't NEED "modern Internet speeds". Does your fridge or your sprinkler system or whatever need high speed? No, it just "needs" (for people who want that functionality), some kind of comparatively dirt slow communication path.

That's not an argument FOR IPv4 directly, just that your "modern Internet speeds" argument directly doesn't necessarily justify throwing away decades' worth of hardware that is providing people functionality.

Re:Great idea at the concept stage.

[Anonymous Coward]

I can't see it taking off. NDN as described works great for static content (videos, music, etc.) that needs to be replicated to various content caching nodes so as to be "near" the consumers, maybe with the occasional changes updating their hashes and version numbers, but it's totally fucked for anything resembling dynamic content like real time audio/video streams, personalised web pages, internet banking, web mail, etc.

Re:Great idea at the concept stage.

[asmkm22]

Not being able to get rid of IPv4 might be a very good reason to replace TCP/IP entirely. How much traction do you *really* think IPV6 is going to get? My answer to that is something along the lines of "just enough until a better solution comes around."

Re:Great idea at the concept stage.

[santax]

These 'things' add up. I have no need for a expresso machine that is internet-contected, but I'm sure some marketing boy can sell it to my significant other. And I'm sure it will use most of it's packets to send data back to the marketing boy.

Re:Great idea at the concept stage.

[K. S. Kyosuke]

It may not need a lot of bandwidth, but I wonder what kind of data traffic one might expect of it. For measurements and data collection, for example, you may not want to transfer more that a few bytes from a single node every few seconds, but it means sending a packet every few seconds. Suddenly your data is like 10% of all the stuff you're actually transferring. And all the packets have to be routed and processed, even if they are small.

Re:Great idea at the concept stage.

[Anonymous Coward]

Even if they did they would never be able to determine a source address. ((anyone that's ever managed mail servers and had to deal with Yahoo knows exactly what I'm referring too))

Re:Great idea at the concept stage.

[ultranova]

Does your fridge or your sprinkler system or whatever need high speed?

Neither my fridge nor my sprinkler system - especially my sprinkler system - needs any kind of connectivity whatsoever except to spy on me and bombard me with ads where ever I go, both of which do require high speed.

Re:Great idea at the concept stage.

[mattack2]

That's why I specifically said "for people who want that functionality".

I can see wanting your sprinkler system online -- to change it from your couch.. or heck, even from somewhere else (not everyone has automatic rain sensors).

The common "fridge keeps track of what you have in it" idea would be great if it ALSO coordinated with the local grocery store ads that week..

Re:Great idea at the concept stage.

[TheGratefulNet]

citation needed.

I disagree strongly that 'ipv4 hardware' (huh? what IS that, btw? does this imply that ipv6 is not in 'hardware'? how strange to describe things) is not up to modern network speeds. if anything, they can outrun any intermediate link in the chain from you to some random website. wan is still the slow part and always will be; but unless you truly get 1gig speeds to your door, your hardware will be more than enough for anything wan-based.

I truly have no idea where you got this info from, but you are as wrong as could be.

Re: Great idea at the concept stage.

[nan0]

NDN can run over TCP/IP as an overlay. It can improve things without *replacing* them. It's well past concept stage and can be used by application developers. Give it a try !

Re:Great idea at the concept stage.

[Anonymous Coward]

which are increasing 50% every year

For the last 10 years my maximum DSL speed has been hovering around 500Kbps down and 100Kbps up. The wiring in my neighborhood (which is in a city, not the country) is probably 20 years old and I have quite a bit of loss to the DSLAM. Sometimes it's during the summer rainy months. AT&T is now responsible for this wiring and I doubt they will ever bother to fix it for a long time.

Maybe you are lucky but the vast majority of Americans are not seeing this increase. Only in newer neighborhoods where there was proper planning for infrastructure to be easily upgraded.

I can even notice the degraded performance with increased IPv6 header size! So I turned off my IPv6 tunnel.

Re:Great idea at the concept stage.

[Anonymous Coward]

Just call it "NDN.js", then the hypsters will push it heavily.

Re:Great idea at the concept stage.

[bill_mcgonigle]

'ipv4 hardware' (huh? what IS that, btw? does this imply that ipv6 is not in 'hardware'? how strange to describe things)

Not sure what he was on about but, yeah, IPv4 is always in ASIC on big gear and part of the slow IPv6 adoption curve is that there is a lot of big expensive gear deployed with IPv4 in ASIC and IPv6 is only done on the anemic CPU.

We're probably 2 of 5 years into the required replacement cycle, but it is significant. One of the wrinkles with the recent Cisco "Internet is too big" bug was that the hardware has ASIC slots for 1 million IPv4 entries, 500,000 IPv6 entries, but we already have 490K IPv4 entries and if there were as much IPv6 adoption, the combined totals would break out of ASIC today and nobody wants to think about going to the CPU and main memory for core routing, ever.

Re:Great idea at the concept stage.

[TWX]

Sounds to me like you need to revise your access lists and either block it outright, or if it needs that connection to run, QoS it down to where it's not a problem.

Re:Great idea at the concept stage.

[TWX]

For someone that wants this kind of interoperability, they're going to be a lot better off having all of the various devices report to a centralized system, then letting that centralized system send notifications to the various clients like a cell phone or a computer. Also, given that the vast majority of the time the systems would be either idle or within expected parameters, there wouldn't be much of a need for excessive monitoring other than to verify keepalive. Only if the user wants explicit logging would there be a need for constant communication, and I don't think that most people would really find that useful.

I'm still not entirely convinced that the public will buy-in to this concept anyway. After all, we had RS-232-based devices for years and years, and yet most people didn't even link their AV system control ports to each other when all most of those took was a 1/8" phono cable.

I'll tell you what I'd want monitored... The washer and dryer for the laundry so that I know when to go move a load over. The doors on the workshop and the house garage door so that I don't forget to close them if I'm letting a heatsoaked engine vent a bit. The water softener, so that I know when I need to add more potassium chloride. The refrigerators and freezers so that food being stored doesn't spoil. The whole-house energy usage, and the usage on the major systems like the water heaters and the air conditioners, so I can track performance over time to see if a unit is starting to run suboptimally. The amount of data for each of these things is so small that I could do it with 2400 baud RS-232, which is effectively NOTHING compared to broadband speeds.

Re:Great idea at the concept stage.

[TWX]

I expect that the point of an entirely new transmission protocol would be to get rid of all of the vulnerabilities in the current one, rather than having to try to work around them and possibly miss something.

It's not like TCP/IP is the only protocol to have existed, there have been several that people have heard of and quite a few that most people don't know about. Even the OSI model itself was originally intended to be an implementation, rather than an abstraction, but DARPANET was so successful and readily available that it made fleshing-out the OSI model unnecessary.

Re:Great idea at the concept stage.

[Anonymous Coward]

I think that is the point. Video, Images and sound/music don't change (however the stream's capacity does.) The larger the stream, the more packets required to reassemble the frames

Just go go back to the numbers

A 4K video at 3840 X 2160 at YUV444 is 12,441,600 bytes per frame. A TCP/IP v4 packet is 1500 bytes.So 8295 packets must be transferred to in 1/120th of a second to push non-compressed video inside a studio. That just doesn't happen.

Instead we get lossy compression on video entirely because bandwidth constraints don't allow it. 11,943,936,000 bits per second, not including headers/overhead. (yes 12 GIGABITS) is needed to transfer lossless video, stand-alone. Never mind the audio.

What we need is a dynamically adjustable content protocol whereby Someone on a cell phone gets a 960p stream and someone with a 50" TV gets a 2160p stream by streaming just the delta of the stream. eg 2160p isn't downsampled, but rather the stream is made up of deltas from the smallest size so that it can cope with traffic variables. A client would explicitly request a 960p stream ,and the upstream would know to only stream A,B,C,D and not E and F components.

Re:Great idea at the concept stage.

[TWX]

Is it wrong that I don't want my home devices to be reachable from the outside unsolicited?

Re:Great idea at the concept stage.

[Jack Griffin]

Pretty much. Seems like with Linux on the Desktop, incumbency is vastly underestimated, and the horse has already bolted with TCP/IP. Driving on the Right/Left might not be optimal, but it incumbent and it's too entrenched to change.

Re:Great idea at the concept stage.

[torsmo]

Internet speeds, which are increasing 50% every year

Maybe you have access to those speeds. Not everyone does. I'm stil stuck (and there are many in the same boat) with 0.5 Mbps DSL for the past 5 years.

You'll get left in the dust sticking with IPv4

I've already been left in the dust, desire for adopting new tech notwithstanding.

Re:Great idea at the concept stage.

[mark-t]

The reason for the slow ipv6 adoption is that the ISP's don't want to support because everything that anyone needs to access can be accessed by ipv4, and the endpoints don't want to switch to it because they would lose out on all of the ipv4-only connections, so either side sees ipv6 as a superfluous expense that offers zero gain for the forseeable future until such time as we are *literally* out of ip addresses, and the problem has scaled to such an extent that even NAT will not solve it. Then they'll switch.

Re:Great idea at the concept stage.

[thegarbz]

Ignoring the fact that many of the places around the world are growing like mad, and fibre is being put up everywhere, even your local usage would have increased many times over.

10 years ago how many youtube videos were you watching? The provisioned bandwidth may have been the same but the utilisation would have increased, I guarantee it. Also 10 years ago I'd wager you were maybe one of only a handful of people with DSL in the street? I'm willing to bet now that every house has it and multiple 4G connections to various mobile devices too.

Your provisioned line speed has almost zero correlation between bandwidth use on a macro scale.

Re:Great idea at the concept stage.

[mark-t]

You can do that with ipv6 anyways.. and without even bothering with NAT. home devices can be assigned addresses in a local range, and will not be accessible from outside any more than if they were NATted, since IP's in such ranges are explicitly designed by the protocol spec to not be routable. As long as your cable modem adheres to the spec, there is no danger of accessing it from the outside any more than if it were behind a NAT.

Of course, in practice, I expect some kind of NAT solution will be in fairly wide use even in IPv6 anyways, since there will be no lack of use cases where you do not want your device to generally have a globally visible IP and be visible to the outside, but you may still have occasion to want to make requests of services in the outside world, using a local proxy to route the responses to those requests directly to your local IP, even though you do not have a global IP, much like NAT currently operates. This can also be solved by utilizing a global IP and configuring a firewall to block inbound traffic to that IP unless it is in response to a specific request by that device, but this is generally less convenient to configure properly than using a NAT-like arrangement.

Notwithstanding, at least with IPv6, the number of IP's is large enough that every device that anyone might ever want to have its own IP actually can... instead of only satisfying the about 70 or 80% of users, like ipv4 does.

Re:Great idea at the concept stage.

[viperidaenz]

10 years ago youtube didn't exist. It's 8 years old.

Re:Great idea at the concept stage.

[viperidaenz]

TCP supports 64k packets.
1500 bytes is the Ethernet MTU.

Re:Great idea at the concept stage.

[heypete]

Is it wrong that I don't want my home devices to be reachable from the outside unsolicited?

Use a stateful firewall? NAT is not a firewall.

Just because something has a globally unique IP address doesn't mean that it's globally reachable.

Re: Great idea at the concept stage.

[Anonymous Coward]

That's why ipv6 should have simply added 2 octets to the front of IPv4. Then, once it was adopted, clean up the address space by relegating the entire v4 space to "legacy" over time.

Routing/gateways would have been simple. If only 4 octets were requested, then add 2x 00s.

It also means that all the hidden things that make civilization work and have 20 year update cycles would have space to live.

Re:Great idea at the concept stage.

[Anonymous Coward]

Neither my fridge nor my sprinkler system - especially my sprinkler system - needs any kind of connectivity

Agreed. I wouldn't mind being able to check if I turned the oven and coffee brewer off though. Sometimes I forget that I checked that they were off three times before I left, would be nice if I could access my home page and verify.
Would be nice if I could check if the door was locked too, but I don't think I trust internet with that kind of information.

Re: Great idea at the concept stage.

[sexconker]

No, that makes too much sense.
We need super long addresses so we can assign IPs to grains of sand, and we need to use colons everywhere and a shitty fucking collapsing scheme for writing this shit down because the addresses are unintelligible.

Re:Great idea at the concept stage.

[theshowmecanuck]

When America introduced the Susan B Anthony dollar, it didn't fail because it was bad. It failed because the mint didn't remove the paper dollar from circulation combined with the fact that people in general don't like change. Canada introduced a dollar coin and removed the paper dollar from circulation, denying people the choice. The dollar coin has been successfully in circulation for at least 25 years. If you want to get people to adopt a new standard, don't give them the option to use the old one.

Re: Great idea at the concept stage.

[jones_supa]

And replace NAT with public IP addresses with complicated firewall setups.

Re:Great idea at the concept stage.

[jones_supa]

NAT is much simpler to use than setting up a firewall. And why would I want my personal network to use public IP addresses anyway?

For SOHO environments NAT is the perfect tool.

Re:Great idea at the concept stage.

[Anonymous Coward]

Just don't expect anyone to early adopt except the usual hypebots and yahoos. We can't even get rid of IPv4 and you want do replace TCP entirely.

Last time I checked, a lot of sysadmins never liked IPv6 because of the long and unmemorable addresses used, let's hope this new concept is better accepted; I haven't read TFA but I'd assume they'd have thought of that issue this time round.

Re:Great idea at the concept stage.

[TheTurtlesMoves]

NAT is not a firewall. Guessing IPs behinds NATs is easy. IPv6 has much better solutions.

Re:Great idea at the concept stage.

[TheTurtlesMoves]

NAT is NOT a firewall. Meaning that you haven't hid anything and you are not secure. Also NAT is a huge reason why IPSec doesn't work. It breaks the internet.

Re:Great idea at the concept stage.

[qbast]

Well, I am sorry for whatever bumfuckistan you live in. However for most of us speed was going up like crazy in last 10 years. Currently I have 50Mbit/s and that's only because 100Mbit/s would make no sense with wifi. 10 years ago ... I think I had 1Mbit/s.

Re:Great idea at the concept stage.

[jones_supa]

But it does not help to say that NAT is not a firewall. By default it blocks all incoming connections and that's what I want. Yes, I am secure.

However I agree with your comment that IPSec does not work over NAT. That is true and I see a value in having encrypted connections.

Re:Great idea at the concept stage.

[Anonymous Coward]

Erm, that was the GP's point...

Re:Great idea at the concept stage.

[Anonymous Coward]

His point exactly.

Re:Great idea at the concept stage.

[Anonymous Coward]

Not at all, that's why you use a firewall, and you don't confuse network routing functions with security fuctions - just because NAT has some side effects that look like security, does *not* mean that NAT is a security feature.

Re: Great idea at the concept stage.

[Dagger2]

This is pretty much what IPv6 did.

Once you sit down and hash out all of the details of this "just add a few more octets" plan, you end up with roughly what we've already got. Except, of course, we decided to add 12 octets rather than 2, because 48 bits is hilariously too small for the current internet, let alone to handle future growth.

Re:Great idea at the concept stage.

[Anonymous Coward]

This can also be solved by utilizing a global IP and configuring a firewall to block inbound traffic to that IP unless it is in response to a specific request by that device, but this is generally less convenient to configure properly than using a NAT-like arrangement.

Less convenient? In what world? NAT is a collosal pain in the backside, proper firewalls are a piece of cake... (Heck, stateful inspection even predates IPv6 by four years! ;) )

NAT maybe seems simple on your home router where you just switch it on and it just works, but see if you like it so much when you have to work with protocols that like to hide IP addresses inside application traffic, especially when you then throw encryption into the mix, and have multiple NAT layers involved.

Re:Great idea at the concept stage.

[Dagger2]

It's not a firewall. NAT doesn't block incoming connections, it breaks incoming connections (and more besides). We should not be basing the internet around something that does that.

Re:Great idea at the concept stage.

[Shadow99_1]

He's hardly alone. Where I live we didn't have broadband 10 years ago. It was 2006 when Time Warner put in cable broadband in my area with a 5mb/500k speed. Later Verizon added DSL with a 1.5mb/500k speed. in 2010/2001 TW upped or connections to 20mb/1mb as they upgraded their basic equipment to DOSCIS 3.

His experience and mine are far more typical of 90% of the US then yours is. I live within 30 miles of one of the top 100 largest cities in the US and the whole region around us doesn't have a single broadband option beyond TW's 20mb/1mb plan and they only cover 5 cities/towns in a region with hundreds of thousands of people. My aunt lives just outside of a town around here and her only broadband option is a cellular hotspot from Verzon.

Just an FYI the providers covering this region include:
TW @ 20mb/1mb
Cablevision @ 5mb/1mb
Verizon @ 1.5mb/500k
Cellular through the big names (Though don't chose Sprint their network skips towns locally)
Satellite Service

Banks, companies, and the government all want to offer more and more online, but the companies providing internet connectivity are happy to tell us to suck it and not provide matching service to our needs. Verizon specifically was handed gobs of cash from my state for 15 years to role out broadband and three years ago it came to a head where they just told my state government we weren't worth the investment which is why we didn't have broadband 15 years later. My state of course did diddly to them even though they had taken our tax payer money and run with it.

Re:Great idea at the concept stage.

[LordLimecat]

Why are you connecting it to your LAN if you dont want it on the internet?

Sounds to me like you just want to complain.

Re:Great idea at the concept stage.

[Anonymous Coward]

so if they had been thinking correctly then IPv6 would have simply been an address space expansion, instead of the cluster fuck it's become!

Re:Great idea at the concept stage.

[LordLimecat]

ITT people dont understand the OSI model.

Layer 4 vs layer 6: who can tell me where DRM, and NDN, would fall?

Re:Great idea at the concept stage.

[Enry]

Well that and all the vending machines and coin slots that would have to be replaced to handle dollar coins. IIRC only the USPS can handle dollar coins.

Re:Great idea at the concept stage.

[pe1rxq]

And what magic do you propose to use in order to expand the FIXED length address fields in the IPv4 header?

Re:Great idea at the concept stage.

[luis_a_espinal]

This. There's likely trillions of dollars invested in IPv4 that is going to be around for decades. Consider the Internet like highways and train track widths - we're stuck with it for a very long time.

Three words for you: Long term thinking. Replacement of TCP/IP will happen, just not now or in the near future. Tech companies/consortia and academia are simply paving the way. Thank God that not everyone subscribe to the notion of doing something only if it is bound to a near-term execution plan.

Re:Great idea at the concept stage.

[luis_a_espinal]

These 'things' add up. I have no need for a expresso machine that is internet-contected, but I'm sure some marketing boy can sell it to my significant other. And I'm sure it will use most of it's packets to send data back to the marketing boy.

Unless we have hundreds of appliances, or more continuously pinging each other (or dozens sending each other barrage of critical data in an uber-QoS menage-a-trois) those will not add up to require "modern internet speeds".

Re:Great idea at the concept stage.

[oh_my_080980980]

No terrible idea at the concept stage: "..content-based networking is an alternative approach to the architecture of computer networks. Its founding principle is that a communication network should allow a user to focus on the data he or she needs, rather than having to reference a specific, physical location where that data is to be retrieved from."

Solution in search of a problem. Today all the end user focuses on *IS* the data they want. The location doesn't enter into it. When a user searches the internet all they are presented are results of a query. The location isn't part of the search and other than the hyperlink indicating where the data is located, isn't part the of result. So again, the user is not concerned with the location.

I foresee serious security and technical issues.

Re:Great idea at the concept stage.

[Anonymous Coward]

That's the point you muppet.

Re:Great idea at the concept stage.

[TaliesinWI]

NAT is NOT a firewall. Meaning that you haven't hid anything and you are not secure. Also NAT is a huge reason why IPSec doesn't work. It breaks the internet.

Oh look, it's one of those purist types.

If an arbitrary host can't reach through my router and connect to an arbitrary device in my home network, guess what? That's effectively a firewall. Yes it's not a _packet filtering_ firewall, but who cares? The end effect is the same. NAT takes multiple devices that only need to connect to other internet hosts (not be connected to themselves) and lets it work.

In a NAT situation, the return packets from the host my PC is surfing to are translated so it all functions. If that same PC were on a public IP, a stateful firewall would open the return ports so the packets could get back to the PC from the web server. Care to tell me what's insecure about one vs. secure about the other? Unless there's actual inspection going on, those return packets could have the same bad data in them regardless. I'm not "more secure" simply because a slightly smarter device managed to let me make the same de facto connection to a web server that a basic NAT device would. I'm only _truly_ secure if my intermediate device, be it a NAT router or a stateful firewall, can actually inspect the return traffic and stop it from reaching my PC if it's bogus or bad.

And IPSec didn't take off because it was WAY too complex, and stupid parts of it like AH mode and transport mode should have never made it in. There are multiple overlapping ways to do the same thing and there didn't need to be.

Re:Great idea at the concept stage.

[Rich0]

ITT people dont understand the OSI model.

Layer 4 vs layer 6: who can tell me where DRM, and NDN, would fall?

Wherever Congress legislates that it will fall, or maybe it will be up to a Judge to decide.

DRM is just a technical solution to a legal problem, and legal requirements are not written by computer scientists.

Re:Great idea at the concept stage.

[mark-t]

NAT maybe seems simple on your home router where you just switch it on and it just works, but see if you like it so much when you have to work with protocols that like to hide IP addresses inside application traffic, especially when you then throw encryption into the mix, and have multiple NAT layers involved.

That's only because of the way most people use NAT... Typically, either every device on a network utilizes it, or none of them do. There is no strict requirement that this be the case, however.... that's just how home routers are usually built. It is entirely possible to achieve the functionality of NAT where it is desired, while still having devices with globally visible IP's on the same network.

NAT doesn't take anything away from IPv6 because any incentive to use it in the first place with IPv6 isn't the same as it is in IPv4.... It would be much more like a transparent proxy that is available to (possibly specific) local addresses in the local IP range.

Re:Great idea at the concept stage.

[LordLimecat]

Congress does not legislate OSI. OSI is simply the model for what parts of the internet communication fall into what functional category. Layer 1 handles physical signalling, and simply doesnt do DRM no matter how congress legislates; its a model, not an implementation.

Its like arguing that Congress will legislate that your pseudocode has to implement DRM; it simply makes no sense.

In the case of networking, DRM will almost always fall into layer 6 or 7, because it does NOT specify the physical electrical signalling, nor how frames travel within broadcast domains, nor addressing, nor the transport mechanism (though some encryption does appear here), and generally not session (though it could). Usually DRM will be presentation, or most likely application: the end application makes the decision of how to restrict customer access.

I dont think DRM COULD even work at layer 4 or below; certainly not below layer 3.

Re:Great idea at the concept stage.

[Anonymous Coward]

You expect millions of people to start setting up firewalls to use v6 correctly. How can this not be a disaster of epic proportions?

Re:Great idea at the concept stage.

[tlhIngan]

NAT is also great for isolating internal network IPs from external network IPs.

If you don't know why that's that useful, then you've not been on the Internet long enough to have to renumber networks.

Sure IPv6 has auto-configuring and auto-discovery built into it. Great. But like anything "auto" it doesn't work 100%. Fine for small networks where you need to reboot your printer every month or so because your ISP gives you a new prefix, but bigger networks it gets far more interesting.

And what's likely to happen is it's random. You get a new prefix, and everything trying to access the Internet breaks. Then mysteriously recovers after a few hours/days as they realize that oh, the prefix's changed.

Hell, there's probably going to be instances where all hell breaks loose because an ISP gives a prefix that's effectively static, then changes it years down the road, and all of a sudden everything changes its prefix and suffix, resulting in servers that can't communicate anymore (thanks, hard coded IPs!) and all sorts of other havoc.

NAT helps prevent this by keeping the "inside" network IPs static or at least on the whim on the admin, not on the whim of the ISP. (Hell, today some people really get annoyed when their ISP decides to change their static IPv4 allocations).

Yeah, you can do this on IPv6 already thanks to each host having multiple IPs, but developers and everyone else has already shown this is unlikely to happen - they'll just pick the public IP and be done with it.

In the end, what does pure IPv6 accomplish? If you have a firewall, you still break end-to-end connectivity. And the IPv4 NAT model is more "understandable" to people. The real issue is IPv6 offers a lot, when people really just wanted "more addresses". They didn't care for multi-homing, getting preferred routes, QoS (I'm sure ISPs would love that feature to be able to charge for high-priority packets by the packet), and dozens of other features that were thrown in, resulting in a complex mess that's forcing people to re-learn IP networking.

Oh wait, training costs generally result in people not wanting to upgrade software (e.g., Office). perhaps that's also why they're reluctant to upgrade to IPv6, as well.

(It is a perfect opportunity to create an IPv6 compatible upgrade to IPv4. Call it "IPv5" and the only thing is the other stuff is ignored - just treat it as IPv4 with a bigger address space, have in NAT, and everything. No learning other than having to type in more numbers for the IP address, single IP per network card, etc. Just like IPv4, and once everyone is IPv5, well, IPv6 is just feature additions and requires zero additional work, if you choose to use it.).

Re:Great idea at the concept stage.

[suutar]

Focusing on this kind of create-once receive-everywhere thing instead of the traditional create-once receive-once model leads to wanting a better version of multicast than ipv4 does.

Re:Great idea at the concept stage.

[suutar]

Heh. After thinking about it for a few minutes, it seems like bittorrent magnet links may be the best example of NDN in use at this time. "I don't care where you get it from, but this is the file I want. Fetch."

Re:Great idea at the concept stage.

[david_thornley]

How doesn't it block incoming connections. A packet comes in from outside to try to make a connection (or any other reason). My router looks at it, looks at its NAT tables or whatever, realizes it doesn't have instructions on where it goes from the router, and drops the packet. (Am I inaccurate in any way?)

If I have a device, and the firewall is supposed to reject all packets to it, how does that differ from the same device behind the NAT where the NAT has no port forwarding to that device?

Re:Great idea at the concept stage.

[Enry]

If by long term you mean 50 years, I'm fine with that. And as a "hey, if we had to replace TCP/IP today, what could we do?" thought experiment.

But to think that we're going to replace TCP/IP when we can't even replace IPv4, don't for a second think this will happen during our lifetime (well, I might make it another 50 years, but I'll be in my 90s then).

Re: Great idea at the concept stage.

[Anonymous Coward]

Plus there is the fact of where this address points: 2001::48:8080. Am I connecting to a server on port 80 or on port 8080?

Re:Great idea at the concept stage.

[Anonymous Coward]

v6 died because it didn't really solve any problems other than future address exhaustion. For every feature that v6 offered, a better v4 one has been engineered and adopted.

v6 offered no transitional provisions, and the people that designed it dug their heels in and refused to change anything, insisting that it be explicitly incompatible for no fucking reason whatsoever. As a result, the rest of the world went "Well fuck you too!" and here we are.

You know what would have worked? An address space extension to v4 that made sense and was simple to implement. Even if it was as simple as adding 2-4 octets to the address. It would be absurdly easy to transition then. Set a v4.1 flag somewhere in the header. v4.1 stacks/networks would be aware of v4 traffic and could route it as nessissary. v4.1 traffic could be gatewayed to the "old" internet in a nat-ish scheme.

At this point v6 is fucking pointless. All it offers are more addresses, but it doesn't offer anything to solve new issues that have come up when you have billions of world wide devices all talking at once.

Re: Great idea at the concept stage.

[Anonymous Coward]

we decided to add 12 octets rather than 2, because 48 bits is hilariously too small

Then why the fuck did /you/ waste 8 of those octets to tie it to the interface's mac address, which isn't even guaranteed to be unique or meaningful (other than for the ip tracking scum)?

I have dual stack, and my isp is giving me a /64, and despite there being space in there for every grain of sand, I cannot even subnet it, unless I'm going to change every device that should connect to it.

Re:Great idea at the concept stage.

[DigiShaman]

NAT inherently hides your private IP scheme from the outside. It's a form of security via obscurity, but that's not the same thing as true firewall protection. You can still be hacked by guessing what your internal IP scheme is, which for a lot of people is as simple as 192.168.1.x. No, if you want NAT firewall capability, it needs to provide SPI (Stateful Packet Inspection) at minimum. All modern consumer based routers should now do this for the past 8 year or so. The first consumer Linksys routers however, no, just NAT.

Re: Great idea at the concept stage.

[Anonymous Coward]

Umm... IPv6 firewalls are soo much easier to configure than ipv4 nat. And you never ever have to discover that your video conference with granny failed because her nat-box does not support full cone nat.

Re:Great idea at the concept stage.

[Anonymous Coward]

"Maybe you are lucky but the vast majority of Americans are not seeing this increase. Only in newer neighborhoods where there was proper planning for infrastructure to be easily upgraded."

Youre right - all the building done, all the phone networks setup previous to the 90s did not properly plan for the internet. Someone should be held accountable.

Re:Great idea at the concept stage.

[Anonymous Coward]

I live in a neighborhood which I don't think has had a new residence built in over over 30 years (probably over 40). Yet, my speeds have steadily increased - currently over 100Mb/s w/Comcast. Yes, Comcast did dig up the streets about ten years ago to run some new infrastructure and I'm sure that required some planning and money. This is a moderately high density area with a population that, mostly, can't envision having good broadband service so market penetration is high. I think demographics and density had more to do with it than age of the neighborhood.

Re:Great idea at the concept stage.

[sl3xd]

I'm really not sure about the "not replacing IPv4"...

Most Comcast customers have IPv6 now, and it's been silently working for quite some time.

I've taken the time to instrument my connection, and a lot of my traffic is IPv6. (The lion's share of bandwidth is IPv6, but that's easy to pin on Netflix.)

Re:Great idea at the concept stage.

[Archwyrm]

But I want to see a video stream from my sprinkler showing the grass being watered. In 1080p. Otherwise, I'd have to get up and look out the window or something.

Re: Great idea at the concept stage.

[Steve Blake]

Your ISP is an ass. They got at least a /32 from their RIR. If IPv6 allowed say /120 subnets, they would probably be handing you a /120 instead of a /64.

Are you using a router with DHCP-PD? Are you sure it is asking from more than a single /64?

Re:Great idea at the concept stage.

[columbus]

You're right. From the wikipedia page on this: http://en.wikipedia.org/wiki/N... from the 'How it Works' section, they are planning centralized control of the data (ez wipe) and access restrictions to data built into the networking model.

"In many cases, substantial storage is already available, and could be used more efficiently if it could recognize particular content and only keep one copy of it. Since hierarchical structures can exist within the network graph, this mode of distribution could naturally scale content delivery to the size of the audience, and simultaneously reduce up-stream equipment to just the minimum needed to produce the content."
. . .
"In this model, the logical place to put commercial copy control and security is not in consumer equipment, but in the neighboring commercial network nodes. If the node agrees that the consumer has a distribution agreement, then restricted content can be delivered. Such delivery contracts require relatively few, cheap CPU cycles from devices already present near the edge of an ISP's net. If there are commercial restrictions, those may need to be included in the content names, as well."

Re:Great idea at the concept stage.

[stoatwblr]

Why would you want to NAT IPv6?

And you get a /64 for home use anyway.

As for firewalling, you need that anyway, NAT or no NAT. My router does both.

Re:Great idea at the concept stage.

[Anonymous Coward]

You know some kind of ill conceived "content protection" is going be built into this protocol.

Per the wikipedia article;

http://en.wikipedia.org/wiki/Named_data_networking

In this model, the logical place to put commercial copy control and security is not in consumer equipment, but in the neighboring commercial network nodes. If the node agrees that the consumer has a distribution agreement, then restricted content can be delivered. Such delivery contracts require relatively few, cheap CPU cycles from devices already present near the edge of an ISP's net. If there are commercial restrictions, those may need to be included in the content names, as well.

Re:Great idea at the concept stage.

[Anonymous Coward]

Almost all home internet connections, cellular connections, and web hosting in the United States has IPv6...

It's nearly 100% deployed here.

I think the technology is right where it should be at if nearly every device, and connection today supports it and can connect to IPv6 sites..

Re:Great idea at the concept stage.

[sjames]

Nonsense. All NAT could do is make a complicated switchover more complicated and failure prone. What is so bright and shiny about NAT? It's an ugly hack in the first place.

Carriers are already providing routable IPv4 addresses, what's so damned hard about providing a routable /64?

BTW, Comcast is already transitioned. I'm getting a v6 prefix to go with my v4 address now.

Re:Great idea at the concept stage.

[sjames]

No, NAT is not simpler. There's likely a click and drool option on most new AP/routers. It may even be the default by now. I know on mine it's just clicking the enable radio button for "IPv6 firewall protection". That doesn't seem very hard.

Filtering rather than NATing does put a lot less load on the router since it only has to pass/not pass packets rather than rewriting them in both directions.

filtering rather than NAT does make it a lot easier if you want to allow connections on a particular port to more than one or your computers.

Re:Great idea at the concept stage.

[Rich0]

Congress does not legislate OSI.

No, they tend to focus more on the tubes.

You're missing the point. You're making excellent arguments as to why doing DRM at the wrong layer doesn't make sense. However, all it takes is some money in the right pockets and everybody will have to do it anyway.

If you want to white-list the ability to transmit data and what kinds of data you can transmit, then you could certainly enforce that at a pretty low level. For example, you could enforce at the TCP level that you're only allowed to receive packets on port 80 if your IP appears on the list of licensed webservers. You could even forbid receiving packets that contain "GET" followed by a URL without a permit of some kind. Sure, it would be dumb, but we pay our lawmakers to come up with dumb laws and they do a very good job of it.

Re: Great idea at the concept stage.

[mark-t]

That's only applicable when your nat is all or nothing. It is also possible to use a nat like a ran parent proxy for local LAN ips while still doing perfectly normal routin for any global ips. You can easily do this with ipv6 because the ip ranges for thing like LAN-local and globally visible ip addresses is well defined in ipv6

Re:Great idea at the concept stage.

[jones_supa]

You can still be hacked by guessing what your internal IP scheme is

That is not true. It is hard to get such traffic to be routed appropriately, and most public routers drop traffic assigned to private IP ranges anyway.

Re:Great idea at the concept stage.

[Shark]

and climate research are among the application areas on the table.

See, they already know the magic words that get millions of dollars squandered on very silly research. Chances of success or usefulness are irrelevant, they'll get the grants and avoid starvation until the next crackpot idea springs up.

There's a lot of money spent on pretending to care about climate change in both government and industry.

Re:Great idea at the concept stage.

[LordLimecat]

For example, you could enforce at the TCP level that you're only allowed to receive packets on port 80 if your IP appears on the list of licensed webservers.

What you just described is ACLing: You have an access control list that says what IP is allowed in at what port. Thats not DRM, its a standard thing that routers already do.

If you're doing it at a webserver level, its not layer 4, its layer 7.

You could even forbid receiving packets that contain "GET" followed by a URL without a permit of some kind.

Thats layer 7.

It really sounds like you dont understand the distinction between layer 4 and layer 7. Once you are dealing with URLs, the application no longer cares about "TCP", it cares about generic "connections". Layer 4 does transport; it does not deal with URLs or anything else.

Re:Great idea at the concept stage.

[Dagger2]

NAT rewrites addresses; firewalls don't. The former breaks inbound connections and complicates everything for the network admin and for anything that needs to know your IP. There's no reason to do that to yourself unless you absolutely have to.

Re: Great idea at the concept stage.

[Dagger2]

That decision was made almost 20 years ago, and I haven't had much luck finding any records of the discussion about it. I can, however, point out that there's a big difference between numbering networks and numbering hosts. A 48-bit space for numbering hosts is tight; a 64-bit space for numbering networks is not.

And your ISP is supposed to be giving at least a /56, so take your allocation size up with them. If they won't give you more, it's not IPv6's fault, it's their fault.

Re: Great idea at the concept stage.

[Dagger2]

Neither. That's just an IP.

If it was http://2001::48:8080/ then you'd be connecting on port 80. If it was http://[2001::48:8080]:8080/, then it'd be port 8080. It's not the most wonderful syntax, but it's not ambiguous either... and it's not like anybody deals with IPs on a regular basis anyway, because we have this "DNS" thing that saves you from doing it.

Re:Great idea at the concept stage.

[Rich0]

It really sounds like you dont understand the distinction between layer 4 and layer 7. Once you are dealing with URLs, the application no longer cares about "TCP", it cares about generic "connections".

I fully understand that what I just proposed isn't the right way to do things. That is my whole point. You can still pass a law that says that at the IP layer you must search for packets that match some regex and drop them if the destination IP isn't on some whitelist. Obviously that isn't going to work right if packets get fragmented across the search string, but that doesn't mean that legislators can't write a stupid law.

Re: Great idea at the concept stage.

[Anonymous Coward]

Didn't know about the [] around the ip address. Thanks!

Re:Great idea at the concept stage.

[theshowmecanuck]

Same complaint in Canada. When they have no choice, then they do it.

Re:Great idea at the concept stage.

[Muad'Dave]

Read up on jumbo frames.

Re: Great idea at the concept stage.

[sexconker]

I deal with IPs on a regular basis because:

I have shit that I specifically do not want to be resolvable b DNS
I have shit that needs to operate regardless of DNS
I have ACLs and shit that do not allow DNS entries

Re: Great idea at the concept stage.

[sexconker]

Umm... IPv6 firewalls are soo much easier to configure than ipv4 nat. And you never ever have to discover that your video conference with granny failed because her nat-box does not support full cone nat.

NAT has the benefit of blocking all incoming shit by default and being really fucking hard for the common Joe to accidentally fuck up.

Re: Great idea at the concept stage.

[Dagger2]

My recommendations to that are a) use DNS anyway (you can limit which clients get access to which zones, so you can keep them internal if you really want), or at least a hosts file, b) pick your IPs carefully to avoid dealing with horrible addresses, c) copy/paste.

e.g.:
# host he.net
he.net has address 216.218.186.2
he.net has IPv6 address 2001:470:0:76::2

16 characters vs 13 characters isn't too bad, and it's the same effort to copy/paste either way... and if NAT is involved then the v4 side gets silly because you have to deal with two addresses for that machine, which is definitely more effort than those 3 extra characters.

Re:Great idea at the concept stage.

[sjames]

For the vast majority of home and SOHO users, there really isn't a difference. Routers and APs that support v6 in that class are pre-configured with IPv6 rules that provide the same protection as NAT ever did.

Many people are using IPv6 right now and don't even know it. All versions of Windows after XP have IPv6 enebled by default. When their ISP goes v6, the RA packets will be accepted and alakazam!

For that matter, a lot of people were unknowingly using Terado tunneling for IPv6 before that.

Re:Great idea at the concept stage.

[santax]

We will have hundreds. In your street, in your town. I wasn't talking about clientside, I was talking ISP-side and Exchange-side.

Not a chance

[gweihir]

Despite a few decades of research, TCP/IP is still the best thing we know for the task at hand. Yes, it is admittedly not really good at it, but all known alternatives are worse. This is more likely some kind of publicity stunt or serves some entirely different purpose.

Re: Not a chance

[Jahf]

Right on. Because when we know there is no better solution and the current implementation is lack luster we need to keep status quo.

Re: Not a chance

[MightyMartian]

TCP/IP has the singular advantage that it is deeply entrenched, runs on a vast number of devices from supercomputers right down to single-chip computers. Is it perfect? Absolutely not, but it's a proven technology.

I'm sure in the fullness of time it will be replaced, or at least subsumed into some better protocol, and maybe this initiative will be the one that produces its successor... or not. I think TCP/IP is going to be with us for a very long time.

Re:Not a chance

[thegarbz]

Despite decades of research the horse and cart are still the best thing we know for the task at hand. Yes, it's admittedly not really good, but all the known alternatives are worse. This is more likely some kind of publicity stunt or serves some entirely different purpose.

Your statement as shown can be applied to the internal combustion engine, or any other technology. Rejecting any change out of hand without consideration is incredibly sad, if not dangerous to our species future prospects. Yes it's important to take everything with a grain of salt, but everything should be at least considered. It only takes one successful change to have a dramatic impact and improve the lives of many.

This goes for all technology, not just this specific problem.

Re: Not a chance

[Anonymous Coward]

I agree with your points especially with respect to the IP layer. TCP not so much. Currently SCTP is a viable, supported (except unfortunately on a lot of cheap home routers) and in many situations, superior transport protocol.
Having said that, a quick look at the linked wikipedia article seems to place NDN at a higher layer in the protocol stack then TCP/SCTP.

Re: Not a chance

[gweihir]

We do not know whether there is a better solution, but currently we do not have one, despite decades of research. What would you do, start breaking things?

Re: Not a chance

[slack_justyb]

Just like the steam powered car. Those were so totally an awesome idea.

Re:Not a chance

[gweihir]

So you would me following the research in that area for 25 years now call "without consideration"? That is pretty dumb. For the SPECIFIC PROBLEM at hand, there is currently no better solution, despite constant research effort for a few decades. That is why it will not be replaced anytime soon.

I really hate mindless "progress fanatics" like you. No clue at all, insulting attitude and zero to contribute. Moron.

Re: Not a chance

[gweihir]

I agree. The best thing we can do at this time is careful tweaks in congestion control, buffering and error handling, but that is it. Also, if you have reasonable over-provisioning (i.e. >= 200% of what you use), TCP/IP even works pretty well for real-time applications. That is one of the factors that keeps it alive, over-provisioning is a far easier solution to its problems than changing the network, especially as bandwidth is only getting cheaper while the bandwidth actually needed for most applications is pretty stagnant. The only thing with a hunger for unlimited bandwidth is video-streaming, but from what people are willing to pay for, HTDV seems to be the best that really has a market. And once bandwidth increases, while usage does not, basically most problems of TCP/IP go away.

Re: Not a chance

[thegarbz]

I never said you had to accept ideas, just consider them.

Re: Not a chance

[gweihir]

All these ideas have been considered and are continued to be considered. What do you think scientific publishing is? A joke? There is NOTHING THERE at this time. No candidate. New protocols are considered good if they are not too much worse than TCP/IP in general applications. Truth be told, most serious researchers have left that field though, as there is nothing to be gained and everything obvious (after a few years of research) has been discounted.

Really, stop talking trash. You have no clue about the state-of-the-art in that field.

Re:Not a chance

[WaffleMonster]

Your statement as shown can be applied to the internal combustion engine, or any other technology. Rejecting any change out of hand without consideration is incredibly sad

There are only so many hours in a day... ignoring/rejecting silliness out of ignorance is often a practical necessity.

Yes it's important to take everything with a grain of salt, but everything should be at least considered.

"Everything" ...sort of...includes magic unicorns and assorted demon things observed while trip-pin' on mushr00ms...

See also trusted Internets, motor/generator free energy machines and application of ternary logic to prevent IPv4 exhaustion.

It only takes one successful change to have a dramatic impact and improve the lives of many.

Well paying out that $25k to play is sure to improve the life of someone.

Re: Not a chance

[thegarbz]

All these ideas have been considered

Ahh I see now. There's no such thing as a new idea? Even if the old system has problems? Everything that can ever be invented has been invented.

I have to be honest I didn't read past that first sentence. I can only imagine the rest of your post follows this completely retarded preposition.

Re:Not a chance

[thegarbz]

That's the wonderful thing about our world. Not everyone needs to be an expert in everything. But if you proclaim to be then ignoring/rejecting silliness out of ignorance....

Hang on this doesn't compute. If you're ignorant how do you know it's silly again?

I'm not saying everyone needs to check everything about everything. Just that the experts consider the solution.

On the other hand the parent is rejecting new ideas out of hand because it would be changing TCP/IP. That's not examining if a solution is silly or if it violates a law of thermodynamics. That's saying, what we have now works so we shouldn't attempt to try and make it better and I will just ignore anything that anyone says about the topic.

Re:Not a chance

[thegarbz]

That depends, did you actually say you follow the research in the area for 25 years? Did you also look at the proposal in detail and make an assessment? Nope? Didn't think so!

Dammit Jim I'm a progress fanatic not a mind reader.

By the way the definition for progress is "development towards an improved or more advanced condition.".
Based on this I personally think that everyone should be a progress fanatic and it will be sad when all the researches turn into middle managers and naysayers and the world will stop "progressing". May as well close the universities down now, no need for them right? We haven't solved problems in the last 25 years so why even bother looking anymore.

In case you don't realise I'm not saying anything for or against what they are proposing. I'm simply directly attacking the negative tone of your original post.

Re: Not a chance

[Anonymous Coward]

There should be a nickname for the horse and buggy argument like there is for Godwin and nazism.

If a new protocol is implemented it will absolutely have content protection built in at some point.

It will likely break everything that cannot run it. As in everything that came before it. So you include code for legacy support? Suddenly it's bloated and buggy.

Re: Not a chance

[Anonymous Coward]

I won't reject change out of hand. I will be deeply suspicious of anything entrenched commercial interests support to replace something that was not developed with a profit motive though. It is not difficult to imagine a proposal where anonymity is disallowed, tracking is built in, encryption has "approved" back doors, and other person-unfriendly "features". That may not even be the intention, and it could still be the result after law enforcement, the NSA, etc. have their inevitable and unwelcome say in matters. That our current Internet architecture can still drive bad actors like that crazy is reason enough to keep it.

Re: Not a chance

[gweihir]

You probably also believe that they will eventually discover the philosopher's stone, as they may just not have considered the right idea so far.

Rally, this is science. There are border conditions for what is possible and there are no fundamental breakthroughs out of the blue. But there is another good word for people like you: "sucker".

Re: Not a chance

[mlts]

Why should content protection be part of the Internet standard? Why do my devices (routers, computers, etc.) have to have built in DRM which will end up getting cracked, or at least possibly exploited from offshore?

This also is going to be met with a lot of suspicion. Who keeps the keys, gets to keep content locked, owns the license servers, and is able to come in via backdoors mandated as part of the protocol? The UN? Give me a break. China? Sure, we can trust them allright, provided we give them 51% ownership of any venture. It won't be the US because BRIC will sooner create their own network and completely split off.

I don't reject change... but what does this new protocol give me? IPv4 and to a lesser extent IPv6 have been torture tested, are completely open, and one can cobble together adequate defenses against attacks not too expensively (Cisco ASAs on the low end are a couple C-notes, and there are always smaller routers). A protocol based around DRM and content protection, stuff that is made to obfuscate and lock down is not going to be of any benefit to anyone but a few.

To boot, this seems like a complex mess. A network protocol should be brain-dead simple in order to reduce the attack surface, and reduce bugs. Adding DRM at layer 2 is at best will slow things down, at worst, allow the bad guys to hide behind bogus certificates.

Grabbing my tinfoil hat, I'm wondering if this protocol is something that will end up mandated within hours as soon as a "warhol event", or something more known as a "cyber 9/11" happens. I would not be surprised if this is already written and ready to be thrown on the floor as a bill on both houses the second some major security breach happens that causes catastrophic damage.

I'm seeing shades of the Clipper chip again, with the same problems. The bad guys getting access to the backdoors, compromising everyone in a way that cannot be patched, the bad guys closing the backdoors so they can't be investigated by LEOs... and the biggest losers are the good guys.

Re: Not a chance

[phantomfive]

I've used SCTP. It's not particularly better than TCP. It has some things that make it nicer if you are doing all your programming by writing directly to the socket.

But no one actually does that. In practice, even people writing low-level code encapsulate their send/receive in a function or a method, at which point SCTP doesn't give any real advantages. The idea of channels is kind of cool, but for it to be really useful, they would need guaranteed bandwidth (or once again, encapsulating your network code in functions will give you the same result with TCP).

Add to that, the kernel driver code for SCTP isn't well tested (because it's not well used), and SCTP is really a solution looking for a problem.

Re:Not a chance

[phantomfive]

The main difference that I can see for this technology is that the routing takes places based on URL, instead of based on IP address, like it is today.

It's hard for me to see this as a significant improvement. It might make caching somewhat easier, I guess, by pushing the caching mechanism down to the routing layer.

How else is this an improvement? It seems like every problem they are trying to solve has been solved, and more elegantly, as long as you can see the beauty in the multi-layer stack. If you think everything should be squished together, you might like this better.

Re: Not a chance

[thegarbz]

Oh my god this made me laugh.

A sucker is someone who believes something without evidence. What I am is someone who poopoos an idea because I believe we've already figured out the best way of doing something. Trust me we haven't, and we never will. If we had time machines I would suggest going and talking to people with kerosene lamps and tell them one day that they will be able to light their houses through this magical (they will think it is) thing called electricity.

Will we find the philosopher's stone? Nah. Fusion power? Likely. Self driving cars? Likely. A better internet? Likely.

There really is only one thing certain. If people like you were in charge we may as well just close of universities and abandon research altogether. After all, we have already tried everything right?

Trust me we haven't.

Re:Not a chance

[thegarbz]

Which is why I call you a "progress fanatic", "clueless" and a "moron". Thanks for confirming my assessment.

And "progress fanatic" I will gladly put on a t-shit and wear proudly.

The other two labels you have no basis for other than hot-headed hatred of what I have said. Looks like several people agree with me too.
This was fun.

Re:Not a chance

[thegarbz]

Oh I agree it's probably not much of an improvement with technical merits. I was merely calling out the parent's attitude which appears to be that we should abandon all efforts to improve TCP/IP because we haven't had any luck in the past decade.

That's not how science works.

As for technical merits I don't think this standard has much that would warrant the incredible expense of implementing it.

Re: Not a chance

[Carewolf]

The advantage of SCTP is that it is not a retarded implementation of go back N. Which means it can operate efficiently at high speeds on unreliable networks. Also the channels could be easily and automatically used with HTTP to replace the inefficient pipelining. With TCP something like SPDY had to reimplement channels on a higher level.

Re:Not a chance

[Anonymous Coward]

That's rubbish. We're not talking about technology, we're talking about a protocol. I.e. a set of rules implemented in software. Hand in your /. card and go back to elementary school.

Re: Not a chance

[WaffleMonster]

The advantage of SCTP is that it is not a retarded implementation of go back N.

SCTP has all the same limitations as TCP at the SCTP stream level.

Which means it can operate efficiently at high speeds on unreliable networks. Also the channels could be easily and automatically used with HTTP to replace the inefficient pipelining. With TCP something like SPDY had to reimplement channels on a higher level.

This is semantically identical to opening multiple TCP sessions - one for each stream. If you were to lower round trip cost of subsequent session setup in TCP to zero (e.g. fast open extensions) then you essentially have the useful advantage of SCTP without SCTP.

The only benefit SCTP has is multipath failover baked in and you can't even use the extra paths concurrently it only exists as a contingency.

Re: Not a chance

[Anonymous Coward]

"Experts"? What is an "expert"? If a discipline allows "experts" then it crawls with conmen and charlatans. We do have science and scientists, and a true scientist would be offended if called "expert". Leave the talking without proof to marketing people.

Re:Not a chance

[LordLimecat]

UDP is worse?

Re: Not a chance

[oh_my_080980980]

Spoken by someone who doesn't know anything about content-centric networking.

Re: Not a chance

[janeuner]

> If you were to lower round trip cost of subsequent session setup

*waves magic wand*

Well that didn't work...

TLS/SCTP is the application that no one knows that they need.

Re: Not a chance

[bluefoxlucid]

NDN looks like a scheme to tag data and change networks from "addressing a particular node" to "addressing data". This is like changing the Post Office such that a person addresses a particular letter sent to them, rather than having a house number where letters get delivered.

Computer addresses with DNS on top make sense: it's easy to subdivide and route, and name translation allows humans to interact with it. NDN looks like it's trying to make the names the addresses, and make the URIs the names, and make the routers act as caches, and hope it all works; but then how do I address a *computer*? How do I ask for anything other than HTTP?

NDN looks like p2pwww stuff I designed back in 2004, except trying to implement as a network protocol on the routers, rather than an application protocol on the nodes. Even then, I specified digital signatures, encryption, and network namespace isolation: you could have an ICANNWeb which signed certificates for each name (i.e. Microsoft) and, on ICANNWeb, you would put out a message (P2P) for Microsoft://www/windowsxp/support.aspx and get back responses for (have|know|home)--node has a copy recent as per [date], node knows who has a copy recent as per [date], node knows the home is [address]--and select from there. Each resource would be digitally signed with generation date stamp and expiration date stamp, and a new generation date stamp overrides an earlier expiration date stamp.

In short: you'd get on a Gnutella-like network, perform a search, and be told where the resource is. Data was such that you could identify newer, identical, and expired resources. Your node could say, "0-3 hops", then "4-6 hops", incrementally crawling the network; or "3 hops past first response, limit 10". Usually if a node knows another node has a copy, that other node also knows several (it got its copy somehow--by its own request). If a node locates nodes with multiple versions, it provides outdated nodes with provable evidence that they're outdated, so they can drop their caches and learn some other node has a more up-to-date copy. Likewise, when those nodes are queried, they will then re-query the nodes they know have copies, and update them: an update doesn't trigger this cycle--too much traffic.

That's application-level. A locatable, self-caching network which encapsulates all resources in digital signatures and allows for namespaces. It sounds like that's what they're trying to accomplish, but in the transport layer.

Re: Not a chance

[bluefoxlucid]

We need to leverage our core competencies to open new opportunities in content-centric networking!

Re: Not a chance

[WaffleMonster]

*waves magic wand*

Well that didn't work...

TLS/SCTP is the application that no one knows that they need.

Fast open is already shipping in current Linux kernels and you can do the same thing with TLS see RFC5077.

Re: Not a chance

[david_thornley]

There is such a thing as a new idea. It just doesn't necessarily come from the area you're looking at.

There were a lot of impressive horse-drawn buggies, in terms of comfort and capacity for light weight. (We have better material science and machining techniques, so we could do incrementally better today.) That's where personal transport was stalled (not counting the bicycle, which serves somewhat different needs) until somebody managed to make a sufficiently powerful engine sufficiently small. That's an entirely different field from buggy design.

There's also ideas that are not going to catch on, like making current flow in circuit diagrams match the electron flow. Current diagrams work well enough as it is, and it would be a massive pain to change them.

Sure, TCP/IP isn't perfect. However, aside from far too few IP addresses, it isn't really broken, as far as I can tell. We could definitely come up with improvements, but (with the exception of IP addresses), the cost of change may not be worth the benefits. TCP/IPv6 may be sufficiently close to optimal that it's not worth more than incremental changes. Newer science and technology may make it possible to create a much better system, or could just increase efficiency to the point that nobody worries about TCP/IP problems.

Re: Not a chance

[Carewolf]

The advantage of SCTP is that it is not a retarded implementation of go back N.

SCTP has all the same limitations as TCP at the SCTP stream level.

Ehmm. No. TCP is quite special in being byte-oriented. SCTP is message oriented.

Re: Not a chance

[WaffleMonster]

Ehmm. No. TCP is quite special in being byte-oriented. SCTP is message oriented.

By definition a stream is a stream is a stream. Being a stream means you are bound by limits of what you are...a stream. It matters not matter what protocol the stream is implemented over.

A TCP session is HOL'd no different than any individual stream within a given SCTP session.

The only difference is 1:1 correspondence between TCP session and data stream.
This is compared with 1:Many between SCTP session and multiple streams within.

While separate SCTP streams can not HOL each other each individual stream is HOL'd.

Mass media takeover and destruction of 'net

[Eravnrekaree]

This is basically designed to bring the old big media, broadcast ways to the internet. Hence, to basically destroy the Internet, allowing for mass reproduction of centrally created Corporate content, where independant voices are locked out. The protocol is designed for that, mass distribution of corporate created, centrally distributed content to an ignorant, consumption only masses which are treated with disdain and objects of manipulation by the elite. This is to bring big media and the stranglehold they had for so many years on information the public has access to back.

With the Ipv6 transition needed its time to focus on that rather than on this plan to destroy the internet and turn it into the digital equivalent of 100 channels of centrally produced, elite controlled, one way cable television programming designed to psychologically manipulate and control a feeble and dim witted public.

No thanks and get your #%#% hands of my internet.

Re:Mass media takeover and destruction of 'net

[koan]

Yep, that's the gist I get as well.

Re:Mass media takeover and destruction of 'net

[Melkman]

Luckily I don't see this attempt to turn internet into TV taking off. They really seem to see it as an alternative to IP instead of a service running on top of it like the web. IP6 is a really small change compared to it and look at the snales pace with which that is being rolled out.

Re:Mass media takeover and destruction of 'net

[Anonymous Coward]

Supposing they succeed, don't you think there will still be enough demand for a free Internet that someone would still provide it?

If so, then we don't have much to worry about. Market forces will take care of it.

If not, then we have already lost this battle, its just a matter of time before we realize it.

Re:Mass media takeover and destruction of 'net

[Melkman]

Well, I've been wrong about what the majority of people want a lot of times. But being opposed to change seems to be pretty universal. So I got reasonably good hopes for this battle.

Re:Mass media takeover and destruction of 'net

[Em Adespoton]

I get what you're saying, but I don't get how NDN is supposed to replace TCP/IP. Sure, it replaces many things done with UDP, and it even can do some things better than TCP, but it's not going to be replacing IPvX any time soon, just as TCP and UDP and ICMP etc. can happily co-exist.

What I find interesting is that there's been an implementation of NDN/IP for YEARS -- it's called Freenet. Something tells me that the sponsoring groups wouldn't like to see this particular implementation be the first thing to try out their new network layer however....

Re:Mass media takeover and destruction of 'net

[uCallHimDrJ0NES]

I don't think we're going to stop the progression you are describing. The method by which it is achieved may not be the one being discussed by UCLA and Cisco, but it's clear now that what slashdotters call "the Internet" is doomed and has been since all of those rebellions in northern africa/mideast a couple years ago. What most end-users call "the Internet" is just getting started, but certainly the application of it is as a control and monitoring system against dissent rather than a catalyst promoting freedom of information. The point where we have some hope of rallying the population to activism is the point where content providers and governments try to do things like completely disallow offline storage media. But not before then, because the population just plain doesn't understand what they have or what is at stake.

Re:Mass media takeover and destruction of 'net

[Anonymous Coward]

Intriguing. Our species has been changing faster than any other species on the planet since the dawn of self-replicating structures. The widespread resistance to change has not prevented technological advancement from creating a world completely alien to the one in which we evolved.

Despite appearances, it seems that humanity loves change, and is throwing resources at change with reckless abandon.

Re:Mass media takeover and destruction of 'net

[Anonymous Coward]

If so, then we don't have much to worry about. Market forces will take care of it.

Hahaha. Do they also have unicorns and elves in that fantasy land?

Re:Mass media takeover and destruction of 'net

[phantomfive]

and it even can do some things better than TCP

Like what? I've been trying to figure that out, I can't see anything.

Re:Mass media takeover and destruction of 'net

[drewm19801927]

I think you're underestimating the amount of content that normal people produce, and especially the amount of content they would share if sharing it was a more robust experience. There are a LOT of old geezers out there dying every day with domain specific knowledge in their heads that has not been transferred to the internet, mainly because they are not the type of person who is willing to learn a bunch of web technologies and set up a server and use what's left of their money to pay someone to maintain it after they're dead. Sure, people can use centralized services for that, but if data is not profitable to the large corporations hosting it, sooner or later it will be garbage collected too. When YouTube goes down, and someday it WILL, vast swaths of our global culture will evaporate with it because it was all tied to a central service, unlike the sort of system the NDN guys are trying to build. Remember, big media ~already has fancy caching and persistence (for them) mechanisms set up for content delivery that they are heavily invested in. My understanding is that NDN is trying to democratize this, so that content you produce, or that you have an interest in, remains cached on your devices in a way you control, while still being shareable with others.

Re:Mass media takeover and destruction of 'net

[oh_my_080980980]

Exactly. A service sitting on top of IP is fine - not great but fine - but to destroy a technology that as been revolutionary seems a tad bit misguided.

Re:Mass media takeover and destruction of 'net

[0xG]

mass distribution of corporate created, centrally distributed content to an ignorant, consumption only masses which are treated with disdain and objects of manipulation by the elite...[blah blah blah]...psychologically manipulate and control a feeble and dim witted public

As opposed to the current state?

Re:Mass media takeover and destruction of 'net

[Em Adespoton]

and it even can do some things better than TCP

Like what? I've been trying to figure that out, I can't see anything.

Improved use of routing tables/efficient distribution for mass-consumable data (movies, facebook logos, etc). For any problem the Internet was actually designed to solve, it is either equal, or less efficient than TCP over IP.

Basically, this could be a better protocol for any CDNs, but loses all efficiency gains pretty much everywhere else -- which reinforces Eravnrekaree's original point.

Re:Mass media takeover and destruction of 'net

[phantomfive]

Improved use of routing tables/efficient distribution for mass-consumable data (movies, facebook logos, etc).

Isn't this already solved by caching?

Huh

[koan]

No mention of the NSA or GCHQ, one wonders what their contribution will be to a system that tracks you World wide.

Re:Huh

[peragrin]

Don't worry the NSA and GCHQ interests are being covered by China.

Different layers

[Anonymous Coward]

They are also funding a study to replace roads with run-flat tires. Oh, right, different layers.

Re:Different layers

[Stumbles]

Wish I had some mod points.

Now I know why Tsinghua is involved

[Taco Cowboy]

I was puzzled with the involvement of Tsinghua University of China with this thing

After reading your comment it starts to make sense

The China Communist Party needs to regain control of the Internet (at least inside China), that explains why they endorse this new scheme so much

Oh, giant bugging device...

[Anonymous Coward]

So, storage at the network level. Handy way to intercept traffic and store it, without requiring telcos to host equipment.

I wonder how long before certain retention laws come into play...

Corporate Inertia

[Penguinshit]

Unfortunately, as we learned from the debacle of cellular communications, corporate inertia will either squash this or slow gestation until it's stillborn. There is a substantial investment in the current technology of TCP/IP and it still works "just good enough". This change in network would require installation of a twin network alongside the current, with slow adoption in the consumer side. That would be very expensive to build and maintain over numerous financial quarters and thus no MBA-centric company would ever do it in current corporate culture. This takes long-term thinking in a quarter-to-quarter environment. Thus it won't happen for a very long time.

Re:Gangster Computer God Communist Plot

[Anonymous Coward]

And I thought Francis E Dec was dead...

Youtube video by Van Jacobson, from 2006 on this

[Anonymous Coward]

There is a talk on youtube from 2006 by Van Jacobson that describes this idea before it was called named data networking. It is really neat, and I am surprised that it has taken so long for somebody to actually try to implement it.

http://www.youtube.com/watch?v=oCZMoY3q2uM

That's funny

[istartedi]

A bunch of broke folks saddled with student loans are looking to replace UCLA and Cisco; but they didn't bother to announce it.

About time

[Anonymous Coward]

It's about freaking time. TCP/IP was logical for the initial military/ university systems, there needs to be better implementation/restructuring of the internet layers to accommodate the modern multiple billion machines on the web.

Will Linux ever adopt Plan 9

[Anonymous Coward]

BTW, how hard will it be to transform Linux's kernel structure into something that is equivalent to Plan-9?

Re:Will Linux ever adopt Plan 9

[lister king of smeg]

BTW, how hard will it be to transform Linux's kernel structure into something that is equivalent to Plan-9?

not very.

http://www.glendix.org/
http://en.wikipedia.org/wiki/P...
http://en.wikipedia.org/wiki/I...

Re:Will Linux ever adopt Plan 9

[Anonymous Coward]

You answered a different question. The first two are essentially ports of the Plan 9 userspace to Linux, and the third is another OS, the successor of Plan 9.
None of them is even an attempt to "transform Linux's kernel structure into something that is equivalent to Plan-9".

Re:Will Linux ever adopt Plan 9

[Anonymous Coward]

OMFG, there is an alternate universe where everything just works.

Inferno for the Nintendo DS. I am getting nothing done this weekend.

Oh joy, stateful routers...

[steffann]

From the architecture page:

Note that neither Interest nor Data packets carry any host or interface addresses (such as IP addresses); Interest packets are routed towards data producers based on the names carried in the Interest packets, and Data packets are returned based on the state information set up by the Interests at each router hop

Great, NAT-like state in every router...

Re:Oh joy, stateful routers...

[thogard]

And who controls the names and how much does it cost to be a data producer?

Re:Oh joy, stateful routers...

[SuricouRaven]

There's sure to be some approval system, otherwise it'd instantly turn into a tool of massive piracy.

The technology itsself could be good - it just looks like it'll be hampered by business and legal concerns. Which is understandable - the only reason IP wasn't hampered in the same was was a failure to anticipate the magnitude of its impact. If ARPA had known that their technology would one day be used for commiting so many crimes on such a scale, they would certainly have built in some form of control capability to make sure that the government had a way to securely identify everyone and block illegal acts.

About time!

[Anonymous Coward]

But of course Cisco will kill it, their bread and butter is complex product running proprietary protocols.

Baby steps

[PPH]

First, IPv6. If you can handle simple things like that, then we'll let you play with the important stuff.

Oh yeah. Flying cars too.

Re:Baby steps

[Anonymous Coward]

Don't forget ponies. Ponies for everybody.

Replace All

[Anonymous Coward]

"Named Data Networking " -> "Fusion"
"network" -> "power"
"Internet architecture" -> "energy generation"

The article will still make sense, and be about as close to delivering something useful. Which is to say, no credible timeline can be established, no amount of money can be budgeted, and no personnel needs can be forecast.

Only viable as a replacement for a subset of uses

[Anonymous Coward]

All the internet is NOT "give me data named thus." For example, this "NDN" doesn't seem to support logging in to a particular computer, you know, so that you can administer it. It doesn't seem to support sending a file to a particular printer. Maybe it might make an interesting overlay on IP, replacing existing content distribution techniques, like Akamai, but I'm not seeing it replace IP.
      -- david newall

Just in time!

[DarkDaimon]

I'm glad they are starting this now so hopefully by the time we run out of IPv6 addresses, we'll be ready!

All those organisations pushing their own barrow

[Anonymous Coward]

All those organisations pushing their own barrow, with such a broad focus eHealth and climate research? really they'll be able to drum up some standards in no time.

Yeah, that's gonna work

[Chris Mattern]

We can't even get TCP/IP v6 off the ground, and they want to try this?

Re:Yeah, that's gonna work

[Anonymous Coward]

Thats because there's no reason to use ipv6 for internal networks. The only advantage ipv6 has would be on public facing equipment (eg. firewalls) which would then NAT traffic through to an ipv4 address in the companies dmz. Since the number of intranet computers dwarfs public facing internet computers it seems that ipv6 is only a niche technology.

Re:Yeah, that's gonna work

[CyprusBlue113]

Says the guy that doesn't have to manage a network that just outgrew an /8

Re:Yeah, that's gonna work

[Dagger2]

Uh... yes there is.

a) Being able to connect to someone else's (or your own) v6 machine is useful.
b) Not needing NAT is very useful. It's much, much easier to manage a network that doesn't use NAT.

Even putting (a) aside, (b) makes it cheaper and nicer to admin your network. Unless you're a masochist, why wouldn't you want that?

Why do so many have a boner for Plan 9?

[Anonymous Coward]

Can somebody explain to me why so many people have such hard, raging boners for Plan 9?

I tried it out a while ago. It had some interesting ideas, but nothing that truly made the experience significantly better. In fact, I found it quite inferior to Debian Linux in most ways.

I get that some very important UNIX and Bell Labs people worked on it. I get that it had the potential to be revolutionary. But I don't think it was much better than the status quo.

I don't see why people highly revere something that's quite unremarkable.

Re:Why do so many have a boner for Plan 9?

[Anonymous Coward]

oh, that's an easy one. plan 9 is great because one programmer can have a very good grasp of the entire system. the system is so tight and compact, that it is possible to digest and understand the entire kernel in a week or two. i've never had more fun programming. i don't think i could have learned as much as quickly about operating systems, and computing in general without it.

plan 9 is by programmers for programmers. if you want to do something else, then it might not be the system for you.

Re:Why do so many have a boner for Plan 9?

[TWX]

If it's by programmers, for programmers, then why doesn't it have the array of killer apps written for it needed to make it successful in the general user marketplace? Hell, even Linux and BSD variants with their relatively small userbase relative to Microsoft have tens of thousands of decent applets, applications, and suites with lots of choice. I could set up a Linux machine for random users that would give them enough to handle basic professional productivity stuff and web access, even if they'd have trouble wrapping their heads around the nature of the filesystem compared to what they're used to.

Last time I looked into Plan 9, it reminded me of a MacOS 6 fresh install on a Mac Plus, with a puzzle, a clock, and a rudimentary file manager. I didn't see anything that would make the system actually useful to me.

Re:Why do so many have a boner for Plan 9?

[the_B0fh]

He said fun for programmers. He didn't say useful for users.

Re:Why do so many have a boner for Plan 9?

[Anonymous Coward]

Maybe because he meant actual programmers, not "app developer" schlock artists. Plan 9 is really cool for designing dedicated systems for scientific analysis, engineering modeling, and such.

It's not for Flappy Candy games or Facespace crap on iModern U/I's.

Re:Why do so many have a boner for Plan 9?

[Archwyrm]

One could have said the same for Linux and now look at Android..

Re:Why do so many have a boner for Plan 9?

[sjames]

Bits and pieces are sneaking in. For example in KVM, if you mount a host directory in the guest, it's done with 9p.

Plan9 was never intended to be an every day user OS. It's mostly a place to try out new ideas.

So, tell us what we really want to know?

[Anonymous Coward]

How is this going to harm the everyday Internet user? I imagine at the very least it will make it more difficult for two random internet users to connect to each other, because all connections will probably have to be approved by Verisign or some other shit like that.

Remember folks, the age of innovation is over. We are now in the age of control and oppression. Everything "new" is invented for one purpose and only one purpose - to control you more effectively.

I don't see this as so horrible

[sirwired]

I could totally see the two networks running simultaneously. It's completely accurate that TCP/IP sucks for mass content delivery; it's gigantic waste of bandwidth. And for point-to-point interaction this protocol would be massively inefficient.

But why can the two protocols not run on top of the same Layer 2 infrastructure?

Re:I don't see this as so horrible

[BringsApples]

But why can the two protocols not run on top of the same Layer 2 infrastructure?

Because once they do get it rolled out, only "terrorists" (properly pronounced 'tarrists') will be using IPv4 or IPv6.

Re:I don't see this as so horrible

[sociocapitalist]

I could totally see the two networks running simultaneously. It's completely accurate that TCP/IP sucks for mass content delivery; it's gigantic waste of bandwidth. And for point-to-point interaction this protocol would be massively inefficient.

But why can the two protocols not run on top of the same Layer 2 infrastructure?

Or use, you know, like multicast or something...?

Re:I don't see this as so horrible

[SuricouRaven]

Multicast is fine when every reciever wants the same thing at the same time. Good for broadcasting live events. Not very good for things like youtube, where millions of people will want to watch a video but very few of them simutainously, and those that do may want to pause it at any moment and resume playback hours later.

Re:I don't see this as so horrible

[sociocapitalist]

Multicast is fine when every reciever wants the same thing at the same time. Good for broadcasting live events. Not very good for things like youtube, where millions of people will want to watch a video but very few of them simutainously, and those that do may want to pause it at any moment and resume playback hours later.

Agreed but improving the caching mechanism isn't going to remove the requirement of distributing the content, be it simultaneous (with mcast) or just in time. Either way the content still needs to be transmitted and either way it will still consume bandwidth and will still have some type of overhead.

So what it really comes down to is:
  - how efficient a caching mechanism
  - what reduction in overhead

We agree it's more likely to run in parallel - I see it more as an overlay to IP rather than a replacement.

Re:I don't see this as so horrible

[SuricouRaven]

That depends where the cache goes. If it's at the endpoint, you're right. But this allows the cache to be much closer. In the cell tower. In the office router.

You could watch youtube video on a moving train with this. As soon as one person tries to watch the viral video of the day the train's router will store it, so it'll keep working for all even through tunnels and dropouts.

Re:I don't see this as so horrible

[sociocapitalist]

That depends where the cache goes. If it's at the endpoint, you're right. But this allows the cache to be much closer. In the cell tower. In the office router.

You could watch youtube video on a moving train with this. As soon as one person tries to watch the viral video of the day the train's router will store it, so it'll keep working for all even through tunnels and dropouts.

Assuming that the train's caching device could get it to start with - and even then only until the cache is full and gets overwritten by other material while at the same time you also cache a bunch of material that no one else on the train is interested in.

Re:I don't see this as so horrible

[SuricouRaven]

I expect the cache could consist of several terabytes of flash (HDDs not liking vibration) - it'd take a long time for LRU cache management to drop anything.

Even for home users it has potential. Think of things like Windows update. Rather than every PC in the house individually downloading the latest huge upload from MS's server and eating into your connection, only the first one to do so results in internet traffic. The others all fetch it from the router's cache, or from another computer on the network. Even a little SOHO router can comfortably fit a few gigabytes of flash, upgradable via USB stick.

Re:I don't see this as so horrible

[strikethree]

But why can the two protocols not run on top of the same Layer 2 infrastructure?

One protocol is layer 3. The other protocol attempts to usurp layer 3 into its layer 5+ world. Why would anyone agree to such a straitjacket? I dunno. Removing addressing options seems like a pure dick control move. But whatever. Most people do not know enough about anything to even care.

This is BAD. Very very BAD.

[EmagGeek]

In a nutshell, this is applying DRM to all of your connection attempts. You will only be able to make connections that are "authorized" by TPTB.

No more free and open networking.

Re:This is BAD. Very very BAD.

[Anonymous Coward]

Concur, this has the stench content control all over it.

Re:This is BAD. Very very BAD.

[EmagGeek]

Not just content control, but complete and total usage control. Using this technology, ISPs could prevent you opening a connection to anyone they didn't want you to connect to, because all of your outgoing connections would have to be "approved" by their router.

This is all about ending the free and open Internet as we know it today and completely privatizing control over it.

Multicast + caching?

[thegameiam]

As I read the descriptions of NDN, I can't quite see what the difference between NDN and ip multicast is.

If the problem is inefficient use of resources due to over replication, didn't multicast solve that? Add caching boxes, and hey! You just invented IPTV!

SMTP

[mattack2]

As long as you're replacing the "DNA" of the Internet, wouldn't replacing SMTP be a better thing to start with? (To prevent spam, or at least untraceable spam?)

Re:SMTP

[dbIII]

I think we need that form of why a suggestion to stop spam is not new and is not going to be a silver bullet.

The major flaw is any new bandwagon is going to have the spammers climbing aboard as early adopters. Any barriers to entry are going to be more difficult for the general public to negotiate than the spammers, since the spammers have the means to bot, buy or mule their way around them.
With so much distributed malware around, as well as various other means, the spammers can send from trusted addresses. Another barrier is legislative in that the people that pass the laws want to be able to send out political spam at election times, and the weakness built into systems to allow that to happen can be exploited by spammers with a few dollars, bots or a donation into the right pocket.
While a point to point key exchange system sounds good in theory the spammers are going to be more interested in getting a key than most, so it's not going to keep them out unless you have a very short whitelist and give up on the concept of first contact by email.

Re:SMTP

[Sanians]

I think we need that form of why a suggestion to stop spam is not new and is not going to be a silver bullet.

Please, no. That form has rejected far too many good solutions. It's issue is that it insists that we remove spam without changing how email works and what we use it for, as if we can expect something to change even though we refuse to change it. I recall one suggestion got that form as a reply with nothing but the "it won't work for mailing lists" box checked. Is it really too much to tell people running mailing lists to find some other means to do what they do, if it will eliminate spam for everyone else on the planet? We have RSS and Atom feeds which work great for such things as the subscription process is entirely under the user's control. We have web forums which also leave it entirely up to the user whether they receive the messages or not. ...and if those solutions are not sufficient for some reason, then we can invent something else. Email doesn't have to be everything for everyone, and insisting that it must be is essentially insisting that it must be an advertising medium for spammers as well.

Personally, I think XMPP has the problem solved well enough. Their general architecture is superior to email in terms of verifying that you really know where a message came from, so if you receive spam from user@example.com, you know for certain that the message originated from example.com. ...and because each server knows the contact list of its users, it has a good clue about whether that message is spam even before doing any content analysis because it knows if the recipient has user@example.com in their contact list. So if a bunch of messages begin to originate from example.com to users who don't have the sender in their contact list, example.com is going to find itself removed from the network fairly quickly, because there's no culture of "spam is an unavoidable problem" in XMPP, nor is there even a culture of "bulk messaging must be allowed" and so no one can even claim ignorance about what their users are doing.

The end result of this, assuming no breakthroughs in captcha technology, will probably be that users either have to use their ISP's XMPP server, their employer's server, or anyone else who knows them and set up a server for them, or they make a small one-time donation to some random provider on the internet as the ultimate captcha, but "just sign up and start sending messages" disappears as it is too difficult to secure against botnets. ...but for now it seems the spammers don't even care about XMPP, probably because email isn't just low-hanging fruit, it's fruit that has fallen from the tree and has been rotting on the ground for years.

Re:SMTP

[WaffleMonster]

Personally, I think XMPP has the problem solved well enough. Their general architecture is superior to email in terms of verifying that you really know where a message came from, so if you receive spam from user@example.com,

XMPP is embarrassingly similar to email it only seems less spammy because nobody uses it.

...and because each server knows the contact list of its users, it has a good clue about whether that message is spam even before doing any content analysis

Reputation analysis by more voodoo algorithms which assume server is big enough to develop any meaningful clue and not misinterpret results. I'm sick of algorithms... email at the very least used to be reliable...now it is anyone's guess whether a message will be silently dropped for no human understandable reason.

because there's no culture of "spam is an unavoidable problem" in XMPP, nor is there even a culture of "bulk messaging must be allowed" and so no one can even claim ignorance about what their users are doing.

More like a culture of denial. XMPP does NOT meaningfully address spam in any way that matters.

but for now it seems the spammers don't even care about XMPP, probably because email isn't just low-hanging fruit, it's fruit that has fallen from the tree and has been rotting on the ground for years.

Keep on dreamin... they don't care cuz no ones home.

Re:SMTP

[dbIII]

Is it really too much to tell people running mailing lists to find some other means to do what they do,

Yes, but also mainly due to my next point

if it will eliminate spam for everyone else on the planet?

Obviously your strawman example would no do such a thing if it was really that good because it would have been adopted and forced upon those with mailing lists. Let's please keep this an honest discussion without hysterical bullshit that insults the intelligence of the reader.

As for your suggestion, it appears I didn't repeat myself enough above where I said in several ways and giving several reasons "the spammers can send from trusted addresses". Barriers to entry are more difficult for individuals to get past than organised groups of spammers or just one with a couple of mules.

Re:SMTP

[Sanians]

Obviously your strawman example would no do such a thing if it was really that good because it would have been adopted and forced upon those with mailing lists. Let's please keep this an honest discussion without hysterical bullshit that insults the intelligence of the reader.

I often wonder if people are trolling me, or if they're just really bad at making arguments and have terrible social skills. I mean, if anything is a logical fallacy, it's "if it was really that good it would have been adopted." ...and "hysterical bullshit that insults the intelligence of the reader?" Beautiful, man. Beautiful.

There's no greater demonstration of elitism than Slashdot. Everyone defines themselves by their intelligence, and so if you contradict them, not only do they take it personally and feel incredibly insulted, but they lose all respect for you as well, as you're clearly one of those dumb people and as such completely unworthy of their respect. It's impossible to have a rational discussion because they're too busy being offended and responding with insults.

...and perhaps the worst part is when you try to point it out to them, they insist you're trolling them, and you're the one taking things personally and responding with insults, as if you were apparently supposed to ignore all of the butt-hurt and insults in their post. You see, when they do it, it's just a discussion, but when you respond to it by pointing out how dumb and pointless it is, then it becomes trolling.

Anyway, I've had enough of this shit. I'm reprogramming my web browser to take me to reddit.com every time I accidentally type slashdot.org. So, you win. Spam can't be solved ever. Congratulations on your excellent debate skills.

Re:SMTP

[dbIII]

I often wonder if people are trolling me

Your hysterical example seemed to assume I had a very low level of intelligence and no more grasp of the topic than could be picked up in half an hour - so I replied to what I saw as insulting dishonesty with an appropriate response with still some benefit of the doubt. If you don't like the consequences of your actions then don't use such hysterical examples.

Magnet Links

[Anonymous Coward]

Since every single goddamned one of you has used magnet links, you should be comfortable with the idea of requesting objects rather than discussions with particular hosts. Taking this idea and running with it is NDN. It's an excellent network research subject.

It facilitates caching, multipathing... with some more work perhaps network coding to get close to the min-cut bound. Bittorrent is super successful because it's all about the content. Let's give a similar protocol a chance at changing the net.

Re:Magnet Links

[Anonymous Coward]

Magnet links are fucking slow. If you ran a website off of them, it would be worse than dialup. Secondly, us fellow users of Bittorrent are the ones who are controlling the network and are not misusing it for censorship purposes.. With NDN control will fall to ISPs, Big media, and the government with the explicit goal of censorship. How do you eliminate all peer to peer communications? You do it by eliminating the peer to peer part at the network stack. You'll only be able to communicate with each other within a governmental/industry approved namespace, if at all.

ipx/spx

[Anonymous Coward]

Come on! I want my 25 year old CNE to mean something again.

Re:ipx/spx

[Anonymous Coward]

All my Token Ring, ARCNET and DECnet hardware is itching to get in the game again!

Come on guys - it's 2014 not 1994

[dbIII]

Pick up a phone that uses LTE, take a look around the net, then let me known if you hit any page where the phone's use of IPv6 crashed you into the ground with a failure to load the page.

Another False Technology Headline

[statemachine]

If Slashdot editors can't even get the technology headlines correct, how is it better than Reddit, Fark, or any other news aggregator site?

Damn you guys have fallen far.

Replace TCP. Right.

[Anonymous Coward]

Replace TCP. Right. I'll give this the time of day right after we finish rolling out IPv6. Say, fifty years from now?

No Thanks

[Anonymous Coward]

We don't want backdoors.

Why do so many have a boner for Plan 9?

[Anonymous Coward]

Because people are stupid, and don't realize it takes 15 years with millions of people giving feedback to make an OS.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Cisco, the company that gave us IPv6

[Anonymous Coward]

Go look at some of the IPv6 RFCs (they're easy to find - there must be at least a hundred of them). Cisco co-authored almost every single one of them.

IPv6 is a massively overengineered spec that tried to predict the future, comparable to XML and other industry consortium shelfware standards.

IoT will need a protocol similar

[Dharkfiber]

It isn't that TCP/IP won't scale to this but it is extremely tough to make it translate TCP/IP to consumers. A translation protocol is pretty necessary. This can be done with SDN or a made-up protocol. This still sounds like a way that Cisco wants to make itself relevant again. However, I don't see the need to bake in session with layer 3 which is seems like they are doing. It would be better to leave the OSI model as is and create something like a IP-NG implementation that would define application and device fields into the protocol (right now we only have UIDs like MAC).

Named Data Networking?

[Anonymous Coward]

Do you suppose that Named Data Networking could well come from a company called Namesys?

If it did, they'd have a real killer app.

Stop trolling

[Anonymous Coward]

On the other hand the parent is rejecting new ideas out of hand because it would be changing TCP/IP

You just made that up, just like you made up other statements that never happened in your posts (in addition to using completely irrational anecdote and non-applicable metaphor). Go read what the GP wrote again.

Trolling does not make you correct, repeat the lie as often as you prefer and it's still going to be a lie.

A Likely Story....

[mcnster]

After reading the spec, it seems to me that this is a collapse of the HTTP (web) protocol down to the network/transport level. In effect, the internet would become one large heirarchical namespace where clients ("consumers") query the heirarchy of data by uri through Interest Packets and then some server somewhere sends back a Data Packet matching the specified interest. Alot like 20th Century TV, sounds like.

Also there is a provision for packet signature using public-key RSA which makes me think that it would be easy to instruct internet routers to deny passage for all packets not coming from or going to officially sanctioned sources/destinations should the need arise.... makes my paranoid little brain somewhat nervous....

This seems like a fun project to implement over TCP/IP, rather than to replace it. Afterall, there's no shortage of fibre (bandwidth) we could lay, so it makes little sense to abandon the "any peer to any peer" model of the current internet for one that might be better organized just to conserve bandwidth.

The more intelligence we put into the routers and network/transport protocols, the more the internet could start to resemble the old-style telephone company (or cable TV), where the devices on the edges of the network (meaning us) have very little.... creative legroom. This is something that I think we want to avoid.

Re:A Likely Story....

[SuricouRaven]

That's the main selling point. It gives routers a lot more information about what they are routing, allowing them to enforce usage rules. Things like 'only redistribute content signed by those who paid to use our new content distribution system' or 'Do not distribute media from Netflix tagged as licensed for distribution in the US only.'

There's the core of a good idea. CAN is a great idea - power savings, bandwidth savings, faster internet, more reliable, hosting costs slashed. But this starts off with CAN and then layers on top of it layer upon layer of hideous complexity, most of which is designed not to bring faster performace to the end user but rather to provide ISPs with an incentive to deploy it by enabling new business models by which they may screw said end users over.

I doubt many ISPs will let your content benefit from this new technology. They'll be keeping it only for their favored distribution partners. Not least because if it was available to all people, it'd become the single greatest advancement in piracy since the invention of usenet binaries. Can you imagine what would happen if this worked an was open to all? I could distribute a 4GB movie rip to a million people with ease, no messing with p2p networks, it would be no harder than sticking it up on a webserver. So could every dodgy russian website offering free movies. There's no way ISPs could permit that to happen - that's one of the big reasons none have invested in developing simpler CAN technology. This NDN system includes public-key verification of the publisher, so ISPs can make sure their networks only cache and improve the performance of content from trusted partners who have the influence and/or money to get on the whitelist.

The reason the government wants this...

[sigmabody]

For those who don't see why this is bad, consider this:

In order to route/cache by data, the data must be visible to the routing nodes; in essence, you would no longer be able to use end-to-end encryption. You could still have point-to-point (eg: encryption for wireless connections), but everything would be visible to routing nodes, by necessity. This means no more hiding communications from the government (who taps all the backbone routers), no TOR routing, no protection from MTM attacks, by design. You get the promise of more efficiency, at the cost of your privacy/freedom... and guess what, you'll get neither in this case, too.

Re:The reason the government wants this...

[SuricouRaven]

Slight correction: It does include protection from MITM attacks: There's a hash for the content that the endpoint verifies. So it does prevent spoofing content, so long as the endpoint has the correct address. It does't stop your ISP from monitoring exactly what you are getting though - it makes that a whole lot easier, as there's no way the requests could be encrypted.

Re:Only viable as a replacement for a subset of us

[phantomfive]

For example, this "NDN" doesn't seem to support logging in to a particular computer, you know, so that you can administer it. It doesn't seem to support sending a file to a particular printer.

How about, giving your printer a particular name, and giving your computer a particular name? I'm pretty sure they've thought about that particular problem.

Like BitTorrent, but lower level.

[Animats]

I need to read more about this. At first glance, it's kind of like BitTorrent, but at a lower level in the protocol stack. Or like Universal Resource Identifiers (remember those?) at a higher level. The general idea seems to be to make cacheing easier at the expense of making everything else more complex.

Prior Art?

[dutchwhizzman]

Can we please make sure that this talk is well mirrored and universally known? We don't want any patents to be put on this technology to make a few people filthy rich and the rest pay through the nose if this ever succeeds.

Re:Prior Art?

[drewm19801927]

It's the same guy (Van Jacobson) in both the google video and one of the NDN videos. And the catch-22 is that "make sure this talk is well mirrored and universally known" is a big part of what NDN is for.

overlay

[sociocapitalist]

It looks like this would be more likely to be an overlay to TCP/IP than to replace it, with the idea of 'protected' content distribution being a driver.

Of course, as with any other content distribution mechanism, there will no doubt be ways to copy it once it reaches your living room (or wherever).

This looks terrible.

[SuricouRaven]

It looks like they started out with Content Addressible Networking, which is a great idea. Massive bandwidth savings, improved resilience, faster performance, power savings, everything you could want. But then rather than try to impliment CAN properly alongside conventional networking they went for some ridiculous micro-caching thing, over-complicated intermediate nodes that enforce usage rules, some form of insane public-key versioning system validated by intermediate nodes and generally ended up with a monstrosity.

CAN is a great idea. NDN is a terrible implimentation of CAN. The main selling points include having DRM capability built into the network itsself, so if you try to download something not authorised for your country the ISP router can detect and block it. A simple distributed cache would achieve the same benefits with a much simpler design.

There's the core of a great idea in there, burried deep in the heap of over-engineered complexity that appears designed not to bring benefits to performance but rather to allow ISPs to readily decide exactly what content they wish to allow to be distributed and by whome. This thing is designed to allow the network devices to transcode video in real time to a lower bitrate - putting that kind of intelligence in the network is insane!

Re:This looks terrible.

[Anonymous Coward]

You see, the idea is not so much as to create great implementation but for Cisco and VeriSign to make sure they have something to patent and sell.

And whoever is worried about adoption. Stop worriyng. With built in DRM, this thing will be legislated to implement to protect children and fight terrorism.

Re:This looks terrible.

[Anonymous Coward]

Having caching in the network would make it possible for mico publishers to widely distribute their content without building a CDN.
    This might give big content a run for it's money.
    Not sure if I would want it bundled with Internet service or from a third party.

The Internet is often used to content distribution, but there are other apps as well.
    A web page is more often than not a custom page constructed for that particular view.
    Telephony and video conferencing are certainly not cached content.

This NDN stuff seems more like an application to run on the Internet than a replacement for the Internet.
    Kind of like Netflix is an app which for happens to use a large percentage of the b/w, but will eventually get replaced by some other popular app.

If the design matches your complex system, that seems to violate what made the Internet work. Keep the complexity on the edges.
    That would be bad, especially if it were somehow coupled to the IP layer so you could not ignore it when something better comes along.
    NDN should have to compete just like other apps for users.

Given that, it may be terrible or great, but natural market forces will sort that out and if it is terrible it won't be a big deal.

Like a URI?

[Anonymous Coward]

Wikipedia:

a communication network should allow a user to focus on the data he or she needs, rather than having to reference a specific, physical location where that data is to be retrieved from

Dear communication network, the address I gave you is not the address of a specific physical location. I gave you something called a Uniform Resource Identifier that is meant to uniformly identify the resource that I want, so that you can retrieve it from the best specific physical location.

Cache

[flyingfsck]

Yeah, good luck with replacing TCP/IP. This is just a caching system.

We shall see

[Anonymous Coward]

At least it isnt a bunch of incompetent fucks?

GPLv3, really?

[Anonymous Coward]

I wonder what the adoption would be when using this license.

Re:Youtube video by Van Jacobson, from 2006 on thi

[drewm19801927]

It is extremely neat. I do think they need a better spokesperson for the technology, though; Van Jacobson's talks are so crammed with partisan political references they turn me off, despite agreeing with him politically.

Let's rephrase it

[dbIII]

We both know your wonderful example that works perfectly apart from disadvantaging people on mailing lists does not exist and it's somewhat insulting that you think I am gullible enough to take you at your word that such a wonderful example exists.
Understand the reaction now?

...and perhaps the worst part is when you try to point it out to them, they insist you're trolling them

Good reason for that isn't there?

Re:Only viable as a replacement for a subset of us

[SuricouRaven]

I think the idea isn't to replace IP, but to run alongside it.

Replacement for TCP/IP?

[blackanvil]

So, having read the links, it sounds like they want to replace a layer 3 protocol with a layer 4 protocol. This won't work -- you'll still need unique identifiers for source and destination that's machine-translatable for routing, that's aggregatable to avoid routing table bloat, and which interfaces nicely with both layer 2 for transport and layers 4-7 for functionality. Sure, this sounds like a good replacement for the rather awkward DNS lookup and non-intuitive URL syntax, but as a replacement for TCP/IP v4/v6 it is lacking in the necessary functionality.

Thank you lord

[Anonymous Coward]

SDN (hype) can only feed so many startups and mint so many millionaires.
NDN can take it from here...

Isn't this an end run

[Grand Facade]

Isn't this an end run around patent royalties?

um, no

[Anonymous Coward]

If it involves Cisco and Verislime then I want fuck all to do with it

Yet Another Encapsulation

[userw014]

They've been doing this for 4 years now and have only gotten the equivalent of IP headers - source/destination, protocol type, payload length, checksum, and blob-payload ?)

They don't even seem to have the old class A/B/C network numbering or IP options to approximate routing.

This seems to be an attempt to mash up service advertisements (such as are done by ARP broadcasts, BGP/RIP routes, TCP/IP SYN & port-unreachable messages, and DNS resource-records, SMTP, HTTP, and HTML) as well as transport (TCP, SMTP body, MIME encapsulation) into one glorified, hierarchically addressed hairball by making everything keyword/value pairs.

One of the astonishing things about it is that it seems to assume store-and-forward capabilities by some nodes. I don't see that working for streaming data - or big-data (like DNA sequencing.)

It's hard to figure out what problem it's trying to solve. It's offering yet another simplified abstraction of distributed systems for people who hope that calling a brick an orange will make it roll easier.

Replacing the OSI model is more like it

[ZeroWaiteState]

You just thought ATM was dead. It just didn't have DRM yet; the zombie arises anew.

Comment removed

[account_deleted]

Comment removed based on user account deletion