[ghshephard]

Good question - It's not the APIs that are the issue, it's the actual IPv6 addresses in the packets on the wire that we need. All of our remote devices (typically on the order of 5 million+ for larger customers) have IPv6 addresses. We can use tunnel routers to get the traffic over IPv4 networks to the destination, but the applications themselves are addressing the devices with IPv6 addresses - which means, at least on the network segments that our many applications servers are running on, we need to have IPv6 routing working.

Everything we've done assumes an IPv6 network - trying to squish large device networks into IPv4 is just a losing battle for a huge number of reasons (address mobility, address conflict, large number of downstream devices (20,000+) per network segment, etc...)

[harryh]

Oh wow. I dunno what you're doing where you have customers with 5M devices but that definitely sounds like a very good reason to want to get on IPv6!

Medical devices of some kind? Just guessing.

[ghshephard]

Couple different classes of customers - utilities are the existing (Electric/Gas/Water meters) and IoT (Sensors, Street Lights, Parking) are the up and coming.

Both of them lend themselves well to mesh networking application, and mesh networks, in which any one of the 5mm+ deployed devices might appear in any one of the 10,000+ network segments, and in which we just want to concatenate the MAC address and Network segment to get a network address (basically SLAAC) - really makes IPv6 a pretty good fit.

[harryh]

Neat! Sounds like a fun problem to work on.