IoTv6?

[technix]

For new IoT designs, should I put IPv6 capabilities in consideration, at least shared-stack capabilities? The IP stack can be written in IPv6 and IPv4 features and addresses can be mapped to IPv6 equivalents using a shim.

I am probably one of those unicorns that have IPv6 Internet access in my home. And my home network can support IPv6-exclusive hosts thanks to DNSv6/NATv6.

[Jeroen3]

Only if you also fix the year 2038 bug.

[ataradov]

I would say, no. Don't waste your time. There is plenty of IPv4 address space to go around, and it is not going away. If anything, you will be opening up one more attack surface.

[technix]

I would say, no. Don't waste your time. There is plenty of IPv4 address space to go around, and it is not going away. If anything, you will be opening up one more attack surface.

I am interested in what additional attack surface a shared-stack implementation would face.

[Jeroen3]

More code that doesn't get monthly updates.

[ataradov]

I am interested in what additional attack surface a shared-stack implementation would face.

It is more code => more stuff to exploit. I'm not saying there are specific vulnerabilities, but I don't even know what code you are using.

[technix]

I am interested in what additional attack surface a shared-stack implementation would face.

It is more code => more stuff to exploit. I'm not saying there are specific vulnerabilities, but I don't even know what code you are using.

The code as an straight IPv6-only network stack, and a small IPv4-to-IPv6 shim that translates IPv4 packets to IPv6 and vice versa if the addresses falls within the ::ffff:0:0/96 range.

[ataradov]

The code as an straight IPv6-only network stack, and a small IPv4-to-IPv6 shim that translates IPv4 packets to IPv6 and vice versa if the addresses falls within the ::ffff:0:0/96 range.

That kind of attitude leaves wide open holes. I bet Intel though their ME crap was solid, but it turned out not so much. There is no way you can prove there are no holes.

If you want to include that, please do, chances are I'm not going to use your thing anyway.

[technix]

The code as an straight IPv6-only network stack, and a small IPv4-to-IPv6 shim that translates IPv4 packets to IPv6 and vice versa if the addresses falls within the ::ffff:0:0/96 range.

That kind of attitude leaves wide open holes. I bet Intel though their ME crap was solid, but it turned out not so much. There is no way you can prove there are no holes.

If you want to include that, please do, chances are I'm not going to use your thing anyway.

I'd rather see someone at least review some IoTv6 code. IPv6 was created to accommodate IoT in the first place.

[ataradov]

IPv6 was created to accommodate IoT in the first place.

IPv6 was created when IoT fad was not even in the plans.

There is no practical need for IPv6 anywhere. Your device will be behind NAT with any IPv4 address it likes. You need to be incredibly dumb to put it directly on the Internet.

[technix]

IPv6 was created to accommodate IoT in the first place.

IPv6 was created when IoT fad was not even in the plans.

There is no practical need for IPv6 anywhere. Your device will be behind NAT with any IPv4 address it likes. You need to be incredibly dumb to put it directly on the Internet.

When did I say I don't firewall IPv6 traffic?

On IPv4 I often have to resort to protocols like DNS-SD to discover the nodes' addresses, and renumbering mobile nodes is a nightmare.

On IPv6 I can just use fixed 64-bit node addresses and observe NDP router advertisements to establish the network prefix. Yes there is DHCPv4 and DNS-SD but all those protocols require the node to send something before it can be addressed. IPv6 is much easier to set up.

[Kjelt]

I would say any new IoT device should be able to support IPv6.
It does not have to support both IPv4 and IPv6 simultaneously you can let the user choose.
But for some applications like sensors where you want to place a couple of hundred in one building IPv6 might be more convenient than IPv4.
For home use and small numbers of devices I would still choose IPv4 since not many consumers have IPv6 knowledge and might have problems in their home setup with older routers.

[technix]

I would say any new IoT device should be able to support IPv6.
It does not have to support both IPv4 and IPv6 simultaneously you can let the user choose.
But for some applications like sensors where you want to place a couple of hundred in one building IPv6 might be more convenient than IPv4.
For home use and small numbers of devices I would still choose IPv4 since not many consumers have IPv6 knowledge and might have problems in their home setup with older routers.

That is the point of a shimmed IPv6 stack. The main IP stack is IPv6-only so it works under IPv6 environment. The shim performs what is essentially NAT64 for minimized attack surface and IPv4 compatibility.

[mrpackethead]

[/quote] IPv6 was created when IoT fad was not even in the plans.
There is no practical need for IPv6 anywhere. Your device will be behind NAT with any IPv4 address it likes. You need to be incredibly dumb to put it directly on the Internet.
[/quote]

Absolute bollocks.  Its why 30% of the mobile networks in the  world are now ipv6 only.. oh and most users dont' even know. and you'll see the transistion of the rest in the next 3-5 years compelted.

[nctnico]

IPv6 was created to accommodate IoT in the first place.

IPv6 was created when IoT fad was not even in the plans.
There is no practical need for IPv6 anywhere. Your device will be behind NAT with any IPv4 address it likes. You need to be incredibly dumb to put it directly on the Internet.

I agree. An IoT device doesn't belong on internet.

[westfw]

An IoT device doesn't belong on internet.

that would be "irony", right?

[nctnico]

An IoT device doesn't belong on internet.

that would be "irony", right?

IntranetOfThings 

[dimkasta]

IPv6 would be very interesting in a big IoT architecture with MANY nodes.
With its enhanced auto configuration, enhanced network administration abilities, improved QoS control etc, it can fit very well with simplifying and fine-tuning the management and operation of a big fleet of connected devices.
However, as we have discussed before, most IoT applications today are limited in numbers and basically just glorified networked devices.

If you are just interested in covering the most basic functionality (address assignment and/or basic routing), then I would not bother. I do not see IPv6 becoming a requirement for mainstream connectivity any time soon.

[mrpackethead]

IPv6 was created to accommodate IoT in the first place.

IPv6 was created when IoT fad was not even in the plans.
There is no practical need for IPv6 anywhere. Your device will be behind NAT with any IPv4 address it likes. You need to be incredibly dumb to put it directly on the Internet.

I agree. An IoT device doesn't belong on internet.

It can, and it may well be quite safe to do so.  Its no dumber than putting a web server on the intenret.. and theres a lot of those....

[dimkasta]

It can, and it may well be quite safe to do so.  Its no dumber than putting a web server on the intenret.. and theres a lot of those....

The amount of how dumb it is to put something on the internet, is a matter of doing your due diligence both on how fit it is for the internet, and on how to implement it. Oh and on how legal it is to put it on the internet.
It is the same with web servers. It is pretty dumb to put all of them on the internet. Some of them belong in an intranet, or in a DMZ.
And not all of them are fit for applications that require extra security. Think bank server vs blog server.

That is the real challenge of IoT today.
Creating safety standards, implementations and/or regulations for an architecture that is not well defined yet, to cover applications that do not yet exist.

Anyway, for now, for all intents and purposes, IoT is pretty much a marketing hype thing.
Treat your devices as any other networked device and you should be fine if you do your homework and you do not do stupid stuff

[technix]

IPv6 was created when IoT fad was not even in the plans.

When IETF created IPv6 they were anticipating a quick increase of Internet-connected devices and decided to assign each grain of sand on Earth its address block. Increase of Internet-connected devices eh?

[gmb42]

FYI,

Verizon have announced that there'll be no static public IPv4 addresses issued after June 30 2017, here.

[nctnico]

IPv6 was created when IoT fad was not even in the plans.

When IETF created IPv6 they were anticipating a quick increase of Internet-connected devices and decided to assign each grain of sand on Earth its address block. Increase of Internet-connected devices eh?

But at that time worms, ransom ware, hacked internet routers, etc where unheard off. Making something possible from a technical point of view doesn't mean it is a wise thing to do.

[janoc]

But at that time worms, ransom ware, hacked internet routers, etc where unheard off. Making something possible from a technical point of view doesn't mean it is a wise thing to do.

That you are quite mistaken, actually. IPv6 was formalized in 1998, at that time we had stuff like the Morris worm, CIH, OneHalf, Happy99 worm. Melissa worm appeared in 1999, ILOVEYOU worm in 2000, 2001 brought Nimda, Sircam and plenty of other such self-propagating plague. Spam and hacking attacks were also completely routine.

That we didn't have hacked home routers and ransomware doesn't mean that internet security wasn't a major problem already, especially with the millions of Windows PCs that have just gained Internet connectivity back in that era and had more holes than Swiss cheese.

Also, why do you think IPv6 originally included IPsec as mandatory if not for security reasons?

I personally wouldn't be worried by IPv6 stack being a security hole - by itself it cannot do that much. If the rest of the system is decent, it wouldn't be any more a security hole than an IPv4 stack. A more relevant question is whether that IoT device will have useful life long enough to actually see the rollout of IPv6 in its intended application. If not, then it is a pointless exercise and waste of resources. Right now it is still really rare to see consumer electronics to support IPv6 meaningfully, including things like domestic routers and such - many don't support it at all (!) or at best can handle packet routing and DHCPv6. So if OP is planning to rely on some of the more advanced features of IPv6, they will likely be very disappointed and face nightmarish support issues due to all kinds of broken hardware out there.

Autodiscovery is still best handled using things like Zeroconf or DNS-SD, regardless of whether the device uses IPv4 or v6 - you will likely want to configure/advertise more things than only an IP address and DNS. That is where Zeroconf or DNS-SD shine, literally allowing to advertise and discover every coffee machine in the building.

[Kjelt]

IPv6 had a huge boom thanks to the mobile phone industry. If you look at the charts, it is going slow in absolute numbers but the growth is exponential.
The wait is for big countries like China to switch, the most IP providers are already ready for it, and it is for the customer to set the switch on it home router to support it or not.

[technix]

But at that time worms, ransom ware, hacked internet routers, etc where unheard off. Making something possible from a technical point of view doesn't mean it is a wise thing to do.

That you are quite mistaken, actually. IPv6 was formalized in 1998, at that time we had stuff like the Morris worm, CIH, OneHalf, Happy99 worm. Melissa worm appeared in 1999, ILOVEYOU worm in 2000, 2001 brought Nimda, Sircam and plenty of other such self-propagating plague. Spam and hacking attacks were also completely routine.

That we didn't have hacked home routers and ransomware doesn't mean that internet security wasn't a major problem already, especially with the millions of Windows PCs that have just gained Internet connectivity back in that era and had more holes than Swiss cheese.

Also, why do you think IPv6 originally included IPsec as mandatory if not for security reasons?

I personally wouldn't be worried by IPv6 stack being a security hole - by itself it cannot do that much. If the rest of the system is decent, it wouldn't be any more a security hole than an IPv4 stack. A more relevant question is whether that IoT device will have useful life long enough to actually see the rollout of IPv6 in its intended application. If not, then it is a pointless exercise and waste of resources. Right now it is still really rare to see consumer electronics to support IPv6 meaningfully, including things like domestic routers and such - many don't support it at all (!) or at best can handle packet routing and DHCPv6. So if OP is planning to rely on some of the more advanced features of IPv6, they will likely be very disappointed and face nightmarish support issues due to all kinds of broken hardware out there.

Autodiscovery is still best handled using things like Zeroconf or DNS-SD, regardless of whether the device uses IPv4 or v6 - you will likely want to configure/advertise more things than only an IP address and DNS. That is where Zeroconf or DNS-SD shine, literally allowing to advertise and discover every coffee machine in the building.

If all the hardware I sells comes from the same ONU which also becomes part of the autoconfigured IPv6 address, I can use plain NDP to discover compatible devices.

[technix]

Here is an use case that might make sense for an IoTv6 setup: self-monitoring solar panels in a solar farm or building-integrated photovoltaics setup.

In a BIPV setup each window is a solar panel. (There are dye-based solar panels that absorbs IR and UV wavelengths while transparent to visible light) Now for a skyscraper there will be a high amount of panels sitting in the network. Here the huge address space of IPv6 can come to help making all those panels addressable. (There is SLIPv6 that tunnels IPv6 on top of UART, and SLIPv6 is routable)

[Jeroen3]

Are there more than 16 million solar panels on a building? (10.0.0.0/8)

But yes, for an IoT it would be a solution. But building automation isn't IoT, it stays local.

[nctnico]

IPv6 had a huge boom thanks to the mobile phone industry. If you look at the charts, it is going slow in absolute numbers but the growth is exponential.
The wait is for big countries like China to switch, the most IP providers are already ready for it, and it is for the customer to set the switch on it home router to support it or not.

Growth numbers  From 1 to 3 users is a 200% growth!

[janoc]

IPv6 had a huge boom thanks to the mobile phone industry. If you look at the charts, it is going slow in absolute numbers but the growth is exponential.
The wait is for big countries like China to switch, the most IP providers are already ready for it, and it is for the customer to set the switch on it home router to support it or not.

Growth numbers  From 1 to 3 users is a 200% growth!

You have no clue, no offense. Practically all mobile networks and backbones are IPv6 already, completely transparent to the end users. That you don't see it on your home DSL doesn't mean it isn't used (and likely even that DSL works with it, if you enable it and/or configure your computer for it.

Some data:
https://www.vyncke.org/ipv6status/
http://www.worldipv6launch.org/measurements/
https://www.apnic.net/community/ipv6-program/data/

[nctnico]

IPv6 had a huge boom thanks to the mobile phone industry. If you look at the charts, it is going slow in absolute numbers but the growth is exponential.
The wait is for big countries like China to switch, the most IP providers are already ready for it, and it is for the customer to set the switch on it home router to support it or not.

Growth numbers  From 1 to 3 users is a 200% growth!

You have no clue, no offense. Practically all mobile networks and backbones are IPv6 already.

It is not about how far IPv6 has been rolled out but about the way Kjelt tries to argue this (which is completely wrong). And it really doesn't matter whether the backbones support IPv6 or not. The equipment at the subscriber also needs to support it in a way it actually works. This means not according to specs but according to general concensus about how the specs should be interpreted. Remember when every browser rendered a web page differently? Well, IPv6 is in that stage. Ofcourse you have to make your own choice about being an early adopter or not. I wait until there is a benefit to IPv6 which makes me money.

[madires]

IMHO IPv6 should be standard for any new device. For me it's a "must have" otherwise I wouldn't buy it. Security-wise IPv6 has similar attack vectors as IPv4 but the biggest problem are stacked extension headers. The last few years several security issues were addressed and fixed in most IP stacks.

[coppice]

You have no clue, no offense. Practically all mobile networks and backbones are IPv6 already, completely transparent to the end users. That you don't see it on your home DSL doesn't mean it isn't used (and likely even that DSL works with it, if you enable it and/or configure your computer for it.

The cellular network I use was the first one in the world to be fully IPv6 ready. There was heavy advertising about it at the time from everyone who had any involvement in bringing that about. To this day they still won't resolve an IPv6 address for a customer phone.

[technix]

The answer to IPv6 for IoT is "YES".
Whether you want to use a dedicated 6 to 4 gateway / router or whether you want to use a 6-WSN to 6-LAN / 6-WAN gateway is up to you.  But generally many or most IoT devices will be comfortable on IPv6 using 6LowPAN.

So far my projects have been requiring wired connections (as PoE is used to deliver power along with command and control) and I have plain IPv6 Internet access within my Intranet as well as DNS64/NAT64. So I can safely go IPv6-only on the IoT devices?

[coppice]

I think that if your IoT device communicates over 6LowPan you should probably provide IPv6 support, and maybe miss out the whole IPv4 thing entirely. 

[ebclr]

I would evaluate, Is the security a really relevant issue on your class of devices? Are your IOT connected to a missile launch system?

Do your system have enough bandwidth, or information, to make anyone interested in exploit you system

It's worth elevate the security level on a higher level than the actual commercially available networks?

If you reply no go ahead and set Ipv6 or even better set any kind of enable/disable register and let decide later if turn on or off

[mubes]

There is quite a varied amount of knowledge being expressed in this thread!

Should you implement IPv6 in a new development?  Yes.  If you're concerned about back compatibility then some form of shimming or address translation can be provided, but the world is slowly and reluctantly being dragged into a v6 network...the last major holdouts really being the consumer ISPs who, in many cases, haven't really figured out how to spell IPv6 yet, unfortunately.  At the very least the autoconfig capabilities of v6 will be helpful to you.

Even in an individual home there's probably a lot more v6 in use than you expect. Many machines (Macs and Linux in particular, I don't do 'doze, so I have no idea what the state of play is there) will try a v6 connection before they try a v4 one, so there's a lot more v6 going on than most people realise....aided by the autoconfig abilities.  In 'walled gardens' v6 deployment is very common (e.g. 3GPP makes it 'mandatory' with v4 optional) although the advantages of v6 are not really very widely exploited because of concerns of back compatibility.

I can assure you that 'IoT' was a consideration from the very earliest days of v6 development. Christian Huitemas book "IPv6, the new Internet Protocol" is a good readable introduction to how the decisions about v6 came to be made, but it was written in 96 so it's rather outdated now.  Of course, it wasn't called 'IoT' back then, but one of the primary drivers was the requirement for address space expansion without 'middleboxes' (which is what things like NATs are) which break the end-to-end model.   The fact that we didn't really get away from middleboxes meant they ended up becoming more intelligent and its arguable that things like TR-069 (and even OSGi) came about because of the discontinuity in the L3-addressible network.

Back in the late 1990s and early 2000s you can find terms like "Networked Appliances" and "Pervasive Home Networking" ... the marketeers hadn't got hold of the subject back then.  Similarly, there wasn't really anything like WiFi that provided cheap ubiquitous connectivity (that started hitting the market with stuff like the Lucent Orinico cards in about 2000) so it was still difficult for people to make the intuitive leap to fully connected homes when most of them were still on dialup. A series on Home Networking started in IEEE Commag in around 2003 ish and eventually changed its name to Networked Appliances perhaps a year later.

The end-to-end model is really useful for things like QoS and simple configuration.  Folks tend to get hung up on the fact that their v6 network is no longer obfuscated by a NAT but a NAT is not a firewall and there is no reason why your edge-of-home router cannot still provide firewalling (or even address obfuscation if you really want it) in a v6 environment as easily as in a v4 one.

Ah, a trip down memory lane. Anyway, yes, IPv6 isn't going away, and it's (too) slowly becoming mainstream. New devices should as a minimum be dual stack, and v6 only if you've only got the choice of one.

Regards

DAVE

[westfw]

Lack of IPv6 is one of the things that makes me very nervous about using "module/chip with built-in TCP/IP" solutions (Wiznet, CC3000, etc.)

This came out today: 

Landmark IPv6 Report Published: State of Deployment 2017

[nctnico]

Lack of IPv6 is one of the things that makes me very nervous about using "module/chip with built-in TCP/IP" solutions (Wiznet, CC3000, etc.)

This came out today: 

Landmark IPv6 Report Published: State of Deployment 2017

And how long will it take before IPv4 is phased out at the user's side? I expect at least 2 decades. If it where to be sooner then Wiznet et al would be bringing IPv6 solutions to the market right now. Before thinking about phasing out IPv4 IPv6 has to be available for every user in a way it works reliable like IPv4 does. Otherwise you'd need dual stack solutions which just complicate things because you'd need to detect/adjust which kind of network is available. Count on at least another decade because it means replacing millions of internet routers.

[jwm_]

For anything that does pure local communication I have dropped ipv4 completely. Peer to peer on same lan ipv6 stacks are so much smaller and simpler to implement than ipv4 ones and can fully self configure with no DHCP or other routers needed. IPSEC is also simpler to implement and you can end up with something a lot more secure.  For anything like local lightweight sensor nets ipv6 is the way to go if you can.

I also get ipv6 to my home. It's great to have a full publicly routeable /64 to play with.

[coppice]

Lack of IPv6 is one of the things that makes me very nervous about using "module/chip with built-in TCP/IP" solutions (Wiznet, CC3000, etc.)

The CC3000 is actually a series of parts and the latest ones have IPv6 support. All embedded solutions are a risk, if you expect more than a few years life from them. Even if you have access to all the source code, to modify it for future needs, you have no idea today whether the memory resources will be sufficient to handle security requirements a few years from now.

This came out today: 

Landmark IPv6 Report Published: State of Deployment 2017

They've been publishing highly optimistic IPv6 deployment information for years. Some have shown massive availability here in Hong Kong for a number of years. In reality the huge global data centres in Hong Kong have had IPv6 support for years, but not a single consumer can resolve an IPv6 address on either a wired or cellular internet connection.

[madires]

All day long bots with Chinese IPv4 addresses are running ssh dictionary attacks against my servers. There are also some bots from other countries, but the majority originates from China. I haven't seen any attacks via IPv6 yet.

[Kjelt]

All day long bots with Chinese IPv4 addresses are running ssh dictionary attacks against my servers. There are also some bots from other countries, but the majority originates from China. I haven't seen any attacks via IPv6 yet.

Yeah well all is relative, bots can scan all ipv4 addresses multiple times per day, and i mean ALL.
When a new ipv4 address appears it is scanned within 10 minutes.
iPv6 full range scan takes longer than this planet exists 
But when you're IPv6 address is known once (google, shodan etc) you have the same issues.

[jwm_]

No, ipv6 addresses cannot be guessed/scanned like that. You are not just given one ip, but Heather an entire 64 bit range.  First 64 bits are how it gets routed to your endpoint, last 64 is for you too stick your Mac address in to get your whole 128bit address. (Though many implementations choose a new random last 64 bits on boot that's different each time). It is infeasable to scan just 64 bits, let alone 128. When if your public endpoint is found, you can refill your local addresses and be hidden again.

[mrpackethead]

They've been publishing highly optimistic IPv6 deployment information for years. Some have shown massive availability here in Hong Kong for a number of years. In reality the huge global data centres in Hong Kong have had IPv6 support for years, but not a single consumer can resolve an IPv6 address on either a wired or cellular internet connection.

Google is reporting 18% of traffic is gets is IPv6.  more than 50% of the US Mobile carriers are now IPv6.       I'm asusming you are saying a single consumer in China?     I've had Ipv6 at home for several years from my isp.

[nctnico]

They've been publishing highly optimistic IPv6 deployment information for years. Some have shown massive availability here in Hong Kong for a number of years. In reality the huge global data centres in Hong Kong have had IPv6 support for years, but not a single consumer can resolve an IPv6 address on either a wired or cellular internet connection.

Google is reporting 18% of traffic is gets is IPv6.  more than 50% of the US Mobile carriers are now IPv6.

That still doesn't mean the end users get an IPv6 address. They might just get a private IPv4 address which is translated using NAT to IPv6.

[agehall]

That still doesn't mean the end users get an IPv6 address. They might just get a private IPv4 address which is translated using NAT to IPv6.

That would be a very strange and stupid way of doing it. I've never heard of a telco doing anything like that and I've worked with quite a few of them.

[nctnico]

That still doesn't mean the end users get an IPv6 address. They might just get a private IPv4 address which is translated using NAT to IPv6.

That would be a very strange and stupid way of doing it. I've never heard of a telco doing anything like that and I've worked with quite a few of them.

Read what Coppice wrote. It all depends on which parts of the network get upgraded and how their administration and traffic recording systems are setup. As I wrote before: it only makes sense to upgrade to IPv6 if it at least doesn't cost extra money.

[X]

IPv6 was created when IoT fad was not even in the plans.

When IETF created IPv6 they were anticipating a quick increase of Internet-connected devices and decided to assign each grain of sand on Earth its address block. Increase of Internet-connected devices eh?

They would be fine with a 64-bit scheme. 18+ pentillion addresses is plenty, and the IP address will be a bit easier to remember and enter correctly. Even if you were to assign a block of 65536 addresses for each person or location (which is plenty), you get 281+ trillion addresses available. Plenty of addresses for the foreseeable future. There is absolutely no need to give each person an entire 64-bit space. If someone wants to have a huge farm of over 65536 bitcoin miners, that's for them to sort out.

I am not sure IPv4 will go away, because it can be useful in private LANs (eg. CCTV) that don't need such a huge address space. An IPv4 packet header is about 1/4 of the size of an IPv6 header, making it efficient for sending many packets of small quantities of data, and with lower latency.

[madires]

That still doesn't mean the end users get an IPv6 address. They might just get a private IPv4 address which is translated using NAT to IPv6.

NATting between IPv4 and IPv6 is hideous, because there are several fundmental differences between both protocols. No sane network engineer would do that without a pressing reason. Usually the internet access for end users is a proper dual stack or DS lite (one public IPv4 address shared by several users). 

[madires]

Read what Coppice wrote. It all depends on which parts of the network get upgraded and how their administration and traffic recording systems are setup. As I wrote before: it only makes sense to upgrade to IPv6 if it at least doesn't cost extra money.

The lack of public IPv4 address space forces everyone to "upgrade" to IPv6. I don't think the next Google or Facebook will be able to run with just a /24 IPv4 (that's what you can get from ARIN)

[jwm_]

They would be fine with a 64-bit scheme. 18+ pentillion addresses is plenty, and the IP address will be a bit easier to remember and enter correctly. Even if you were to assign a block of 65536 addresses for each person or location (which is plenty), you get 281+ trillion addresses available. Plenty of addresses for the foreseeable future. There is absolutely no need to give each person an entire 64-bit space. If someone wants to have a huge farm of over 65536 bitcoin miners, that's for them to sort out.

The point of the /64 is not for more address space (that is what the first 64 bits of the address gives) the last 64 bits is to allow automatic configuration, it obviates the need for ARP, RARP, BOOTP, DHCP (for simple setups) etc. The last 64 bits are your EUI-64 (or your MAC address). So everyone inherently has a unique ipv6 address without any need for central coordination or parceling them out via single points of failure. It greatly simplifies IP implementations, especially for ad-hoc networks. basically every segment of a LAN is automatically a valid ipv6 network where everyone has a unique address with zero setup or need to build up caches of ARP tables.

You can even do cool things like make the bottom 64 bits a strengthened hash of your public key for creating IPSec session keys, so you get automatic authenticated encryption without centralized coordination or trusted third parties. The address you connect to is its own authenticator.

Lots of fun stuff can be done with the big IPv6 address space, and an embedded implementations can be a fraction of the size of an ipv4 one.

[madires]

I am not sure IPv4 will go away, because it can be useful in private LANs (eg. CCTV) that don't need such a huge address space. An IPv4 packet header is about 1/4 of the size of an IPv6 header, making it efficient for sending many packets of small quantities of data, and with lower latency.

The IPv4 header is 20 bytes, the IPv6 header is 40 bytes. And don't worry too much about the effiecieny of small packets. They are inefficient anyway (ratio between header and payload).

[madires]

It greatly simplifies IP implementations, especially for ad-hoc networks. basically every segment of a LAN is automatically a valid ipv6 network where everyone has a unique address with zero setup or need to build up caches of ARP tables.

You still need MACs for your LAN. ARP was replaced by ND in IPv6. So you have a neigbhor cache instead of an ARP cache.

[madires]

You can even do cool things like make the bottom 64 bits a strengthened hash of your public key for creating IPSec session keys, so you get automatic authenticated encryption without centralized coordination or trusted third parties. The address you connect to is its own authenticator.

How can a known EUI-64 interface address give me a benefit for security?

[technix]

You can even do cool things like make the bottom 64 bits a strengthened hash of your public key for creating IPSec session keys, so you get automatic authenticated encryption without centralized coordination or trusted third parties. The address you connect to is its own authenticator.

How can a known EUI-64 interface address give me a benefit for security?

Try guess my 64-bit prefix. Oh and with one ND broadcast packet all nodes will drop the original prefix and move entirely to a new one. Cat and mouse much?

[madires]

We're talking about the interface ID, not the prefix. Anyway, the interface ID stays the same with SLAAC. You can change your prefix as often as you like, the interface ID will identify you. Or you could enable PE. BTW. IPv6 has no broadcasts, it uses multicast to address multiple systems at once.

[X]

The point of the /64 is not for more address space (that is what the first 64 bits of the address gives) the last 64 bits is to allow automatic configuration, it obviates the need for ARP, RARP, BOOTP, DHCP (for simple setups) etc.

Simple setups can use static IPs even with IPv4, without any of this.

The last 64 bits are your EUI-64 (or your MAC address). So everyone inherently has a unique ipv6 address without any need for central coordination or parceling them out via single points of failure. It greatly simplifies IP implementations, especially for ad-hoc networks. basically every segment of a LAN is automatically a valid ipv6 network where everyone has a unique address with zero setup or need to build up caches of ARP tables.

At the expense of privacy, now that your MAC address is also exposed. MAC addresses tend to stay the same for a particular device and also survive reboots.

You can even do cool things like make the bottom 64 bits a strengthened hash of your public key for creating IPSec session keys, so you get automatic authenticated encryption without centralized coordination or trusted third parties. The address you connect to is its own authenticator.

How can you do that when you have the bottom 64 bits occupied with a MAC address? XOR the key with the MAC?

If somehow the MAC address can be encrypted with a 64-bit block cipher (eg. Blowfish) or XORed with a value known only to devices within the network, then you get to eliminate the "ARP" table and have some improvement in privacy, as you can change the key.

Lots of fun stuff can be done with the big IPv6 address space, and an embedded implementations can be a fraction of the size of an ipv4 one.

Provided you use an IPv6-only stack.

I am not sure IPv4 will go away, because it can be useful in private LANs (eg. CCTV) that don't need such a huge address space. An IPv4 packet header is about 1/4 of the size of an IPv6 header, making it efficient for sending many packets of small quantities of data, and with lower latency.

The IPv4 header is 20 bytes, the IPv6 header is 40 bytes. And don't worry too much about the effiecieny of small packets. They are inefficient anyway (ratio between header and payload).

My mistake, the IPv4 header is 1/2 the size of IPv6 header. In some protocols like NTP, the efficiency of sending small packets is quite important.

[nctnico]

You can even do cool things like make the bottom 64 bits a strengthened hash of your public key for creating IPSec session keys, so you get automatic authenticated encryption without centralized coordination or trusted third parties. The address you connect to is its own authenticator.

How can a known EUI-64 interface address give me a benefit for security?

Try guess my 64-bit prefix. Oh and with one ND broadcast packet all nodes will drop the original prefix and move entirely to a new one. Cat and mouse much?

MAC addresses can be guessed because the variety in numbers isn't so great (in many cases just 16 bits). Also it wouldn't surprise me if there are other attack vectors you don't even know about as well and changing prefixes won't help. All in all it is very unwise to have devices on a public IP address because one way or another it will allow someone to deliver traffic to the device and hack it. As a fundamental rule you don't want foreign traffic on your network so it is wise to use a local (non routable) IP range whether you are using IPv4 or IPv6. A statefull firewall should allow devices to access hosts on internet (just like every country has border security). That gives a first layer of protection.

[theatrus]

Note that Thread is effectively a 6LowPan network - it will bridge to v4, but it has a lot of advantages to other systems.

Ironically, a lot of IoT host devices hosted in AWS (and some in GCP) are whats holding back end to end IPv6, since a lot of consumer networks (i.e., my Comcast connection and cell phones) are all IPv6 native.

[jwm_]

Simple setups can use static IPs even with IPv4, without any of this.

static IPs are a far far cry from plug and play. every device needs some sort of UI to set the IP, someone centralized needs to assign and keep track of them. And manual record keeping needs to happen. This is opposed to plug in and they talk. zero config.

At the expense of privacy, now that your MAC address is also exposed. MAC addresses tend to stay the same for a particular device and also survive reboots.

The requirement that the MAC be the last 64 bits is only true for link local addresses, where they will inherently know your MAC anyway to stick in the ethernet frame. For globally routable addresses you can put whatever you want in there. Almost every linux distro by default now chooses a brand new random number for externally visible addresses. And there is nothing keeping them from rolling a new one every time it boots or every hour if they want to.

Global routing requires routing table entries anyway so the MAC mapping just lives there so there isn't really any extra overhead. There is of course nothing keeping you from using your MAC address as the last 64 bits of your public ipv6 address, some operating systems still default to doing that.

The nice thing about the last 64 bits being unique is there is no need for a centralized DHCP server to ensure unique addresses for everyone. If you have ever dealt with a DHCP failure, or a bridging of two LANs, it is a huge mess. backup DHCP server has slightly different records? it starts reassigning the same IP. accidentally plug an ethernet cable into the wrong hub in the closet and a server starts talking on another lan, all hell breaks lose. There are a HUGE class of failure modes that just go away.

There is no back and forth between the routers and hosts, there is a plain broadcast giving the first 64 bits, no negotiation, you just connect, listen for the advertisement of the first 64 bits and append your unique last 64 bits and start talking, done. The route advertisers are fully stateless and can be duplicated with no ill effects. They can be rebooted without a bunch of stale leases causing issues etc.

How can you do that when you have the bottom 64 bits occupied with a MAC address? XOR the key with the MAC?

If somehow the MAC address can be encrypted with a 64-bit block cipher (eg. Blowfish) or XORed with a value known only to devices within the network, then you get to eliminate the "ARP" table and have some improvement in privacy, as you can change the key.

you can assign the last 64 bits however you want except on the very specific automaci ad-hoc link local network. Including hash of public key, random number, your MAC reversed and xored with your birthday or you can manually assign them sequentially if you really want and are a mild masochist.

Here is a blog post I made about utilizing one of the private namespaces for painless IPSEC accross your local lan. http://notanumber.net/archives/196/simple-ipsec-home-network

Lots of fun stuff can be done with the big IPv6 address space, and an embedded implementations can be a fraction of the size of an ipv4 one.

Provided you use an IPv6-only stack.

For local IoT-like lab equipment stuff the devices just speak IPv6 IPSEC as the computers that talk to them can speak IPv6 dual stack. Most lab equipment doesn't need to talk to the internet at large but would really like to automatically be able to talk and pair on the local network to each other and computers plugged into it for the UI.  IPv6 really shines here and there is no need to have an IPv4 implementation on the devices themselves.