Contiki 2.6: IPv6 For Everything, Everywhere

An anonymous reader writes "The Contiki project just released version 2.6 of its open source operating system for the Internet of Things, used to track city sound pollution, control street lights, read power meters, monitor radiation, among other things. The technology behind it? A really tiny IPv6 stack that fits in a few kilobytes of memory, allowing everything, everywhere to have an IPv6 address."

Comments

Slashdot Warning

[Anonymous Coward]

How can you trust Slashdot editors? For all you know, they could be something other than stargazer; they could be pew pew along the lines of magazine!

Now that you know that this is a possibility, without sufficient experiencementation, you'll have to be extremely wary all editors.

Re:Slashdot Warning

[Anonymous Coward]

besides "Contiki" sounds like a pet name for a gay lover

Broadcast and IPv6

[skydave]

Is it bad that the first thing I thought of when I read the "your-footstool-is-broadcasting-an-IP-address dept" was that IPv6 doesn't support broadcast?

Re:Broadcast and IPv6

[Anonymous Coward]

IPv6 doesn't support broadcast?

Err...

ping6 -I wlan0 ff02::1

There are alots of "All nodes" IPv6 broadcast addresses.

Re:Broadcast and IPv6

[unixisc]

IPv6 doesn't support broadcast. However, a multicast to address ff02::1 would result in a transmission to all nodes within the same local link, resulting in effectively the same thing (In fact, that's how router discovery happens in IPv6). Similarly, one could do a multicast to ff05::1 to reach all nodes in an organization, In other words, there are a lot more scopes in IPv6 that one can address.

IP addresses everywhere

[Anonymous Coward]

Yet Wikipedia admins still checkuserblock thinking it will stop sockpuppets.

Great! Now just solve the routing problem!

[damm0]

Sure, a decent enough platform I guess.

Now, to solve the routing problem! I want to send an email to one of my Contiki buddies down the street. How does the name get resolved and how does a resolved IPv6 address get turned into a route? How about a few miles away? To my buddies in Australia?

And how do we firm critical mass in the mesh, or provide a network effect to get everyone on board?

Finally, let's not forget about the electromagnetic sensitivity problem.

But these are all solvable. Let's go!

We'll let established security protocols solve the application layer problem.

Significance?

[mister2au]

Back in 2008, the same project was quoting "a code size of 11 kilobytes and a dynamic memory usage of less than 2 kilobytes" http://tech.slashdot.org/story/08/10/15/1839209/worlds-smallest-ipv6-stack-by-cisco-atmel-sics

Now we have "fits in a few kilobytes of memory" ...

So this seems to be a nice incremental improvement?

Any experts on embedded systems able to give insight into the importance of (lets say) 16kB in the old version versus (lets again say) 4-6kB including dynamic stack ??

Re:Significance?

[Anonymous Coward]

Any experts on embedded systems able to give insight into the importance of (lets say) 16kB in the old version versus (lets again say) 4-6kB including dynamic stack ??

I happen to be an expert. I fart out of my own asshole at the mere idea of the latter.

Re:Significance?

[Anonymous Coward]

Mostly depends on the device it is going to be built into. If you have devices that run Contiki including uIP (the IP stack) to control relatively simple functions, then this reduction in size means a smaller micro controller will do. That reduces per-device cost in the order of $0.50 - $1, IIRC.

So it mostly depends on whether we're talking about devices where every dollar counts. Think consumer electronics. Street lights -- not so much.

Re:Significance?

[unixisc]

Essentially, what it seems to suggest is that the stack can be hard coded into a micro-controller, if its density is that low, and given the process lithographies that are @ the sweet spot today. I doubt that serial E-squares are manufactured any more, since the densities under discussion can be easily embedded in a microcontroller in either flash or ROM.

Re:Significance?

[TheRaven64]

It's not so much consumer electronics. The main place for Contiki is sensor networks. For example, consider a building with electricity usage and IR / motion sensors in every light fitting. You may have a few thousand sensors in a single building, and you want to make them as cheap as possible.

The problem that Contiki will have in the next few years is that the price of the IC is increasingly limited by the cost of the package at the low end. This means that in a few years you'll be able to buy a 100MHz ARMv7 core with 1MB of RAM and Flash on die for approximately the same cost as a cheap microcontroller. At this point, you may as well use something like a slimmed-down BSD kernel than an embedded OS.

Re:Significance?

[tibit]

Their API is much cleaner than the BSD/Linux accretion disc. Size is only a collateral benefit. You're very much right about the IC pricing being tied to packaging at the low end. I'd still gladly use Contiki no matter how much memory is there.

Re:Significance?

[Anonymous Coward]

This means that in a few years you'll be able to buy a 100MHz ARMv7 core with 1MB of RAM and Flash on die for approximately the same cost as a cheap microcontroller.

But not at the same size or current consumption.
I don't know how Contiki handles sleep modes but the microcontrollers it runs on can get down to an average of 10uA if sleepmodes are implemented correctly. (Wake up at regular intervals and measure/report.)
They also come in 5x5mm sizes with internal oscillators and doesn't really need more than a single external decoupling capacitor.
The ARM processors I have looked at pretty much always needs external oscillator, 10+ capacitors and are really hard to route 2 layer PCB's for.

At the moment ARM and smaller microcontrollers occupy completely different segments of the embedded market and when I look at the last 10 years of development it seems more likely that the ARM will evolve to take more of the desktop/laptop segment and the smaller microcontrollers will grow to replace ARM in the embedded segment.

Re:Significance?

[Anonymous Coward]

Any experts on embedded systems able to give insight into the importance of (lets say) 16kB in the old version versus (lets again say) 4-6kB including dynamic stack ??

Common contemporary MCUs can accommodate this stack, old or new. Consider the STM32F100RB value line MCU; 8KiB of SRAM and 128KiB of code/data in flash. That is among the smallest 32 bit ARM Cortex M3 implementations available.

Most 32 bit MCUs will have similar capacity. The really small parts, 8 bit and many 16 bit devices, will be where the approximately 250% difference in size becomes important. 16 KiB of flash may be all you have in an MSP430, for instance.

There will always be MCUs that are too small for an IP stack, but if you need an IP stack then MCUs that can accommodate it are readily available.

Re:Significance?

[Tailhook]

I agree that high frequency ARMv7s aren't going to put a POSIX stack in every light bulb. Power consumption and the need for external components are just two obvious things precluding that.

... and the smaller microcontrollers will grow to replace ARM in the embedded segment.

For my purposes recent ARM designs are replacing the smaller MCUs. I love the fact that a bog standard 32 bit GNU tool chain is entirely sufficient because the MCU is a straightforward 32 bit thumb2 environment. That means no weird windows-version-x-only crazy-expensive proprietary tool chain that bit rots into obsolescence six months after your turn your back on it. This has a lot of value — enough to make up for the small and ever shrinking component price difference. Powerful on-chip debuggers are another huge win for more capable MCUs.

Where I have the choice I won't go back to the exotic ICE hardware and flaky proprietary tools endemic to really small MCUs.

Re:Great! Now just solve the routing problem!

[Anonymous Coward]

Same as IPv4! It is called DNS. It is called "default route". IPv6 has RA so you don't have to set it up manually. It has IPv6 autoconf via same mechanism. What's the problem???

IpV6 is only twice as big ?

[Anonymous Coward]

So this is going to happen all over again in a few years. SHould have gone with at least four times as big. Those 120 bitts would last twice as long as this IpV6 will. Some times I wonder how internet peiple can be so shirt sited. Stoopid people. Like russian version of Rush Limbaw.

Re:IpV6 is only twice as big ?

[Anonymous Coward]

Yeah I wonder how stupid people can be on the internet too. The number of bits of an IP address has been increased from 64-bit in IPv4 to 256 bits in IPv6. The number of bits has been quadrupled and not doubled. And total number of devices that can be addressed has been approximately increased by 2^(256-64) times, and that was not doubled either.

Re:IpV6 is only twice as big ?

[Anonymous Coward]

Ummmm... IPv4 has 32 bit addresses and IPv6 has 128 bit addresses. The size of the address space in IPv6 is beyond human comprehension. It's big. Very, very, very, (very, very) big. Even bigger than that.

Re:IpV6 is only twice as big ?

[Anonymous Coward]

Yup. Stupid is as stupid does^H^H^H^Hsays.

Re:IpV6 is only twice as big ?

[unixisc]

Given the way IPv6 has demarcated the 'network' and the 'host' space (to use IPv4 terminology temporarily for explaining this) to 64 bits for each, there is now theoretically 18,446,744,073,709,551,616 addresses that can be there within a subnet link. Within the 'network' space, there has been some more demarcation, since 2001:: (and a bunch of more address ranges in the 2000::/3) are the only unicast addresses, and the last word in this 'network' space is the subnet address, there is room for approximately 50 billion network organizations worldwide.

This may be enough, as I've said previously on threads about IPv6, I'd have made the entire top half the global prefix, and then split the lower half b/w subnet and interface ID. I like the idea of fixed lengths though, so that unlike in IPv4, one no longer needs to support subnet masks, and the sheer size suggests that there wouldn't be any reasons for supernetting. People have argued for the need to allow autoconfiguration, and here, if one uses the link layer addresses of ethernet connections, one ostensibly has to allow 48 bits, and if one is using SCSI connections, one has to allow all 64 bits. I still think though that since no network is likely to have anything even close to a billion devices, allowing the last 2 words to be the interface ID (w/ some patched up autoconf) and the previous 2 to be subnet addresses (allowing for nested subnets) would have been more ideal.

Having said all that though, I doubt that any future protocols would have to break compatibility w/ IPv6 the way IPv6 had to break compatibility w/ IPv4. If we do get to 50 billion networks ever, then the next protocol (lets say IPv7) could be different, but it would still have 128 bits, and so the header information wouldn't change to the point of breaking compatibility. Only thing - they might do what I suggested above and redefine the entire top half to be the global prefix, and limit the interface ID to, say, the lower 3 words, leaving 1 word in the middle for the subnet addresses (depending on how most implementations go w/ the current IPv6). And while a lot of equipment would still need to be updated to support the newer protocol, it wouldn't need to be upgraded - unless some moronic manufacturer decides to cost reduce by replacing flash w/ mask ROM in which to contain the IPv6 stack.

Re:IpV6 is only twice as big ?

[Chrisq]

Should have gone with at least four times as big.

But that's enough about your penis, just think yourself lucky that the enlarger worked at all.

Re:IpV6 is only twice as big ?

[petermgreen]

since 2001:: (and a bunch of more address ranges in the 2000::/3)

The whole of 2000::/3 is assigned to the IPv6 internet (not all of it is in use yet though)

there is room for approximately 50 billion network organizations worldwide.

Umm, assuming each network gets a /48 (which is a conservative assumption many ISPs are only giving out a /64 by default and giving larger allocations on request) and a /3 is available for the "IPv6 internet" that leaves 45 bits to define the network. That means about 35 trillion networks can be addressed. To put that number into perspective it's thousands of networks for every person alive on earth today. Granted there will be some wastefulness in allocation (in particular ISPs that are big enough to be allocated a /32 but small enough that they won't ever allocate all 65536 /48s) but I still don't see IPv6 addresses running out any time soon.

And finally remember the current ways of dividing up the IPv6 address are mostly just conventions. There is nothing stopping you using smaller subnets right now if you want (provided you are prepared to give up stateless autoconfiguration), the internet won't know or care.

Re:IpV6 is only twice as big ?

[unixisc]

Most current IPv6 networking gear, from what I understand, recognize boundaries @ the half-way mark. So if someone is using such a router, which is pre-configured to accept Global prefixes that ultimately go to that spot, there's no way they can use part of the interface ID for other purposes. It'd be similar to how in IPv4, there is older equipment that don't recognize CIDR. So if on a global basis, the demarcation boundaries do change, it would be a good idea to rev up the revision# in the IP header, even though the other fields may remain unchanged. So that equipment universally doesn't get confused b/w /64 links, and say /80 links.

Re:IpV6 is only twice as big ?

[Anonymous Coward]

Number of unique devices that can be addressed under IPv4:
2**32=4,294,967,296 = 4 billion devices

Number of unique SUBNETS that can be addressed under IPv6:
2**64=18,446,744,073,709,551,616 = 18 quintillion subnets (each subnet can support that same number of devices).

Number of atoms in this solar system (aside from in the sun): (http://www.madsci.org/posts/archives/may98/892502124.Ph.r.html)
1000000000000000000000000000000000000000000000000000000
Number of devices that can be addressed under IPv6:
340282366920938463463374607431768211456

So until we can make a computer out of 2,938,735,877,055,718 atoms and do this on average for our entire solar system (or leave the system), we should be set.

Re:Great! Now just solve the routing problem!

[SignOfZeta]

Assuming that either the RA support RDNSS, or there's a tiny DHCPv6 client onboard to get that information.

Darn, no mesh

[damm0]

I see, this is about providing an embedded platform for things that want to get on some local Internet drop. It isn't really about creating an Internet from things.

Re:Darn, no mesh

[Guy Harris]

I see, this is about providing an embedded platform for things that want to get on some local Internet drop. It isn't really about creating an Internet from things.

I.e., "the Internet of things" is the same damn Internet as "the Internet of people posting captioned cat pictures to icanhascheezburger.com" - it's not a special Internet for "things", it's just putting a lot more things on the plain old Internet, such as thermostats and smart cards and refrigerators and washing machines and strain gauges and....

Re:Darn, no mesh

[Anonymous Coward]

The internet of things generally refers to mesh networking.

Re:Darn, no mesh

[unixisc]

Doesn't look like it

Re:Darn, no mesh

[Anonymous Coward]

Guess there's a difference between an Internet With Things On It (tm) and an Internet Built From Things (tm).

You won't get mesh networking on these unless they have WiFi. If they do 801.11s could take care of the mesh networking part, but I don't know whether the current routing protocols (eg HWMP) could scale up to carrying the entire Internet, which is possibly the routing proble damm0 meant.

Re:Darn, no mesh

[unixisc]

The IPv6 standard allows a node to have multiple IPv6 addresses. Of course, the implementation would depend on the designer of such devices - if somebody made a garage door opener in a car that could have only one IPv6 address, it would be a case of a bad implementation. Same for any other device - be it a thermostat, a power meter or anything else that could be accessed over a network.

The way I see it, if somebody has an IPv6 link connection at home, that would allow everything that one wants connected - be it the home security system, the garage door, the PC, the AC et al to be connected to that router. Depending on how one wants to do it, one could assign link local addresses or public unicast addresses. If the person doesn't want/need to, say, turn on the AC 15 minutes before pulling into the car parking lot, no need to put those on a public internet, just a private one will do. OTOH, if a person is likely to, from experience, need to open the garage door while away from home, it would make sense to have the garage door assigned a public address as well as a private one, or alternatively, just a private address but connected via a VPN.

Somehow, I'm not getting damm0's point - why would a networking mesh be needed, and what would it achieve? I can think of something useful w/ connecting some of my home items online - like my garage door and garage door opener. But why would I want my toaster, my microwave, my fridge, my cellphone, my thermostat, my TV et al to be a part of such a network (as opposed to just my own home LAN)?

Re:Darn, no mesh

[SignOfZeta]

Just using the public IPv6 prefix given out by your router would be easier than setting up your router to hand out unique local addresses, or using link-local addressing and hoping that all of your devices are on the same physical link. Plus, it would make remote management easier, assuming your theoretical iPhone app doesn't communicate with some kind of master gateway device. An argument can easily be made for both sides in this case.

Re:Darn, no mesh

[unixisc]

You are right, but there may be a lot of people who would not want their toys to be accessible from the public internet. In which case, they are better off using site-unique addresses. Yeah, they'd lose remote management, but it'd all be in a secure LAN, not accessible from outside, but perfectly capable of communicating w/ each other within the home

Re:Darn, no mesh

[mcgrew]

it's just putting a lot more things on the plain old Internet, such as thermostats and smart cards and refrigerators and washing machines and strain gauges and....

Thermostats and strain guages, sure, but why would one need their washing machine, refrigerator, or toaster on the internet? "Just because" is a dumb reason for doing something, especially something that costs cash. Plus, you could already put your thermostat on the internet, this simply allows you to put tinier things on it, because it uses less memory and power.

Re:Darn, no mesh

[Carnildo]

Thermostats and strain guages, sure, but why would one need their washing machine, refrigerator, or toaster on the internet?

The Internet? No, but a home-area network...

I'd love to be able to turn on my dishwasher and washing machine at the same time and have them negotiate usage of the hot-water supply, or have the microwave tell the refrigerator to hold off on starting the compressor for 30 seconds while it finishes up. Having my window box fan and air conditioner consult my home weather station to decide if a back-to-front airflow, a front-to-back airflow, or running the AC would be most effective at cooling is an interesting possibility. I'm sure there are other things a smart home network could do, as well.

Re:Darn, no mesh

[damm0]

I see it as a social engagement in Internet connectivity. Today, we depend on rather large infrastructure companies to provide cellular signal. From a social perspective this is not idea:
  * Near monopoly telecoms set the prices.
  * Infrastructure needs to be deployed everywhere (resulting in near monopolies.)
  * Radio transmissions require a lot of power to get to the local tower (or else suffer poor performance.)
  * Privacy concerns; data must flow through the provider's infrastructure, and the provider must know your general location.

A publicly supported mesh would have to include micropayments in order to incentivize people to put up infrastructure of their own, and would put the network into the hands of the people. Application software remains lucrative, as does hardware. Route negotiations include automated financial negotiations. This is what I'm getting to. And rather that simply trusting our providers to be nice (a rather naive prospect), it becomes intuitively obvious that the network itself is insecure, and that security rests in the identity of the user and their associates.

The result can in fact be highly robust and performant, without centralized nodes that control routing. Devices of all shapes and sizes can join and engage in the mesh, from radio controlled LED christmas lights to basement server farms. There's a kind of routing called Landmark routing which I personally believe is promising. It basically follows the greatest routing algorithm we know; the postal system.

Contiki - Connecting the Next Billion Devices

[Drishmung]

...but not all at the same time. Server slashdotted at time of posting. And lo! Not for the first time. From the link

Contiki was created by Adam Dunkels at SICS in 2003 and was quickly slashdotted. Its impact has been growing ever since.

Plus ça change, plus c'est la même chose.

Re:Contiki - Connecting the Next Billion Devices

[lerxstz]

such a great song

Re:Great! Now just solve the routing problem!

[Anonymous Coward]

And what, pray tell, is the "electromagnetic sensitivity problem"?

Oh good

[Arancaytar]

The Hollywood fantasy of everything everywhere being open to attacks over the internet was such an awesome idea.

I can't wait for "they hacked into the traffic lights" to become an actual statement rather than a punchline.

Re:Oh good

[Dagger2]

I was expecting Slashdot users, of all people, to at least have heard of firewalls... but alas, once again I see how naive my expectations are.

Just to head off the other common complaint, I'd like to mention another recent invention called DNS, which allows people to use textual strings as aliases to IP addresses, saving them from needing to remember the latter all the time.

Re:Oh good

[JSG]

Yes you'd like to think there would firewalls installed on things like traffic lights. However as the fairly recent SCADA attacks demonstrate ...

Re:Oh good

[Anonymous Coward]

Because firewalls are free, require no management, and through PFM prevent all attacks.

Re:Oh good

[tibit]

It's easy, really. SCADA typically runs on some embedded platform, other than Unix, that doesn't come with a built-in firewall, and isn't really kept up-to-date to plug security holes. Sure you could run a traffic light controller on Linux, set up with vnc, firewall and selinux, only letting authenticated VNC traffic through. Alas, there seems to be no one out there who provides a full-featured PLC stack on top of Linux. Most everything runs on Windows XP, CE or Embedded, or some industrial RTOS that's probably swiss cheese in terms of vulnerabilities.

Re:Oh good

[mcgrew]

Just to head off the other common complaint, I'd like to mention another recent invention called DNS

Your thermostat will no more need a dot whatever address than the computer on your desk does. DNS is for web sites, nothing more. As to connecting, it will be as easy as using wifi to connect your two computers, neither of which has a domain name but both of which have IP addresses..

Re:Oh good

[Dagger2]

Do finish the sentence. I guess you wanted to say ", there aren't.", which also implies that they're not behind NAT either.

And if they're not behind NAT in the first place, then the whole original argument of "IPv6 will be less secure than IPv4 because your stuff won't be behind NAT" doesn't even apply, does it?

And if you're thinking of putting them behind NAT "for the security" -- just put them behind a firewall instead. The hardware and software required to do so is the same, and the configuration is very similar. (With a firewall, you also have the option of implementing it on the device itself rather than needing a separate device, although as my sibling poster points out it's kinda rare for embedded hardware to have such support.)

6LoWPAN

[tapspace]

The tech which we're really talking about here is 6LoWPAN, which is IPV6 for these low-power wireless sensor networks. It's a pretty simple software solution, but it's built on some cool stuff. I'm partial to TinyOS over Contiki, but I guess that's just my exposure to it (plus it uses the superb nesC language).

How is Contiki's network organized?

[unixisc]

Arithmetically, this would be possible - Contiki would need just one router, assign an address to everything in the world that needs one, and be off to the races. In practice, of course they'd have many routers, but how do they define their various scopes, like their organization, their sites and so on, so that everything in the 'internet of things' is actually within a/their network?

In IPv6, as we know, there are several scopes, such as local link, site, organization, admin and global. Does Contiki actually make use of all these? I'd actually be interested in a large organization that has such an hierarchical structure, so that the various scopes and networks and sub-networks are appropriately organized to optimize traffic within this internet of things.

Ultimately, this concept could be the killer app that accelarates IPv6 acceptance throughout the internet.

reply from shunky3

[Anonymous Coward]

Shanghai Shunky Machinery Co.,ltd is a famous manufacturer of crushing and screening equipments in China. We provide our customers complete crushing plant, including cone crusher, jaw crusher, impact crusher, VSI sand making machine, mobile crusher and vibrating screen. What we provide is not just the high value-added products, but also the first class service team and problems solution suggestions. Our crushers are widely used in the fundamental construction projects. The complete crushing plants are exported to Russia, Mongolia, middle Asia, Africa and other regions around the world.
http://www.sandmaker.biz
http://www.shunkycrusher.com
http://www.jaw-breaker.org
http://www.jawcrusher.hk
http://www.c-crusher.net
http://www.sandmakingplant.net
http://www.vibrating-screen.biz
http://www.mcrushingstation.com
http://www.cnstonecrusher.com
http://www.cnimpactcrusher.com
http://www.Vibrating-screen.cn
http://www.stoneproductionline.com
http://www.hydraulicconecrusher.net

Re:Great! Now just solve the routing problem!

[unixisc]

Precisely - just do a multicast transmission to address ff02::fb to get to all DNS servers on the local link, or to ff02::1:3 for all DHCP6 servers on the local link. In fact, that's how router advertizements would work.

Re:Great! Now just solve the routing problem!

[Anonymous Coward]

And what, pray tell, is the "electromagnetic sensitivity problem"?

From what I can make of his post, he's saying that electromagnetism gets its feelings hurt easily. So watch your mouth.

Re:Great! Now just solve the routing problem!

[Anonymous Coward]

WiFI interference. eg when your neighbour gets home late and heats up a microwave dinner which you're streaming a porn^H^H^H^Hblockbuster movie.

Re:Great! Now just solve the routing problem!

[LingNoi]

Rain is probably a bigger problem. Not sure about in the states but the topical storms we get over here in monsoon season ruin all signals.

That changes little

[tepples]

Once IPv6 becomes common, administrators of Wikimedia sites and other sites based on user contributions will start blocking sockpuppets by their /64, /56, or even /48, depending on what home ISPs hand out at various service levels.

Re:Great! Now just solve the routing problem!

[Anonymous Coward]

Rain is probably a bigger problem. Not sure about in the states but the topical storms we get over here in monsoon season ruin all signals.

It's not the rain that does that, you imbecile. Try the broadband electromagnetic discharge produced by arc-mode electric current. I.e. lightning. Compared to that a falling drop of water means nothing to your WiFi setup.

This just in....

[Anonymous Coward]

Miller Brewing and Coca-Cola just release their new 'Tra-can' system to allow the two mega-beverage giants to track who buys what where and how long it takes them to consume it. The system is similar to the ill-fated Snack-Trac system that Frito-Lay rolled out two years ago and resulted in half the world's IPV6 addresses being consumed. Miller and Coke promise to recycle the addresses noting 'we are good internet users and always conserve resources.'
In other news Wal-Mart is insisting on all products sold in the store to carry IPV6 addresses for their tracking system. This move has lead China to reserve a full third of all IPV6 addresses still available.
This just in. IPV8 will have 4 times the number of addresses of IPV6. "It will solve the address issue forever" say scientists.

Unlimited is mostly PR, you tend to get 2^16

[Anonymous Coward]

The size of the address space in IPv6 is beyond human comprehension.

I know that you were having a nice HHGG-inspired giggle, but unfortunately a lot of people think that the numbers concerned are a lot bigger than they effectively are.

A /64 is the smallest routable IPv6 block, so in effect there are only 2^64 distinct routable prefixes given by the top 64 bits --- the bottom 64 bits are effectively a sort of "property" field attached to the top 64 and don't increase the real routable address space.

Most people who aren't being restricted to a single routable 64-bit prefix are being given a /48, and (64 - 48) is only 16, so they're being allocated blocks of 2^16 routable addresses, which is not a lot at all --- the old "640k is enough for anybody" quip comes to mind. It's only a lot if you limit yourself to "IPv4 thinking" in which address space was considered a scarce resource. It's now less scarce in IPv6, but nobody could claim that 2^16 routable addresses is a large number.

Personally I think they should have defined IPv6 with 256-bit addresses. It's only double the overhead, but would have given everyone effectively infinite routable addresses to play with, rather than just 2^16. (The fact that big organizations get somewhat larger blocks than a /48 doesn't change this argument, they're still pretty limited.)

IPv6 doesn't really provide a lot of elbow room. Although it seems a large space because we're so used to being packed together like sardines in IPv4, all those other people's elbows out there are in plain sight on the horizon, and I don't think it'll be a long time before we start feeling uncomfortably hemmed in.

2^16 per person is just too small if you want to do interesting things with address space beyond the old IPv4 thinking.

Re:Unlimited is mostly PR, you tend to get 2^16

[unixisc]

Why 256? All they needed to do was divvy up the 128 bits differently. Make the entire top half the Global prefix, where you could have a hierarchical distribution, such as first byte being the RIR, second being the country, and from then on, drilling down to ISP, then customer, then maybe consumer. At the half way mark, have the subnets start and make them 32 bit, so that you'd have 4 billion routable address links, which should be fine. Finally, have 32-bits for the interface ID, which should be fine, since no subnet is going to have even close to that number due to the sheer #collisions it would involve. Yeah, autoconfiguration would be a lot more difficult, if not lost, but honestly, 2 devices having the same automatically generated number shouldn't be a problem if they live in completely different networks.

Re:Unlimited is mostly PR, you tend to get 2^16

[amorsen]

If 65k networks per organization turns out to be a large problem, we can move out of 2000::/3 and change the subnet size to something smaller than /64. Everyone has pretty much decided that having a deterministic non-stateful auto-assigned IP address is undesirable instead of the advantage it was thought to be, and if you give up on any one of those three properties, /96 is plenty.

I doubt it will be a problem in practice. Most organizations fit nicely in IPv4 10/8 with /24 subnets. I've worked for companies where 10/8 was a restraint, but those all had AS numbers and would have no problem acquiring a /32. 2^32 subnets ought to be enough for everyone...

Personally I believe IPv6 should have been designed for better support for /127 or /128 point-to-point-links to end hosts instead. Right now we are emulating broadcast domains over point-to-point ethernet using switches, and then with IPv6 trying to split those into multicast portions. Any switch powerful enough to do multicast (MLD) snooping is powerful enough to run proper routing anyway.

Having full routing to every host would enable many cool inventions, like keeping the same IP address on both wired and Wifi.

Biggest zero-day exploit of all time, OF ALL TIME.

[kheldan]

Sure. Let's do that. Let's make it even easier for malicious types to hack everything.

No. Just, no.