So far, we’ve had two previous articles in this series:
In Part 1 - Background – we set the stage for the debate with some background on why IP has started to make its way into historically closed and proprietary AMI meter networks.
In Part 2 – The Case for IPv6 we gave the IPv6 evangelists in our group a chance to make their case for mandating the newer protocol in the solution.
In this part 3 of the series we had planned to have a discussion of public addressability but instead we’ve opted to try and draw some conclusions from the group.
Apples and Oranges
They look very similar on the surface, but it can be notoriously difficult to make meaningful comparisons across AMI projects that exist in different geographic, regulatory and business environments.
The driving factors behind a significant technical decision may be completely absent in an otherwise very similar AMI implementation resulting in a different technical solution.
It is for these reasons that we decided to give each member of the group a chance to “sum up” their point of view instead of trying to synthesize a single conclusion that all of us could agree on.
We hope that this approach will provide the best coverage of the many factors that influenced this debate.
To avoid accusations of favouritism I’ve ordered the opinions by contributor’s last name. J
Let's first summarise the benefits of IPv6 as outlined in the previous post:
- More efficient and lower latency as it requires no address translation;
- Security designed in from the start;
- Supports many more addresses than IPv4; and
- IPv6 eventually replaces IPv4 and is thus more future proof.
In my view the efficiency gains are likely to be of limited benefit to AMI applications as there are usually no stringent latency requirements (unlike in SCADA systems for example). Furthermore the security solutions that have been designed around IPv4 are good enough, have been standardised and are now implemented by most vendors. AMI devices are unlikely to be addressable on the public Internet and any one system is unlikely to exceed the IPv4 private network space; the address space limitations of IPv4 are therefore not a significant concern.
At some point equipment manufacturers will start to drop support for IPv4. The previous post argues that this will be later rather than earlier and I agree, especially as far as networking equipment is concerned. But what about end points i.e. meters or in home communication modules? It is not clear when manufacturers will start to offer IPv6 only versions. My personal view is that this is still some way off. There are too many installed networks. Producing IPv6 only devices will not save a significant amount on manufacturing cost and limit the market into which devices can be sold.
Given the arguments above, mandating IPv6 is not necessary when procuring an AMI solution today. The risk of inflating costs by excluding cost effective and well-tested solutions outweighs the technical benefits. On the other hand, IPv6 is the future and does have some benefits. I would therefore include IPv6 as a selection criterion, but not assign much weight to it.
This position will need to be revised and I can see the weighting assigned to the IPv6 criterion increasing over time until it becomes a mandatory requirement in 5 to 10 years time.
I like new things – the shinier the better – and IPv6 has lots of new “things” many of which we’ve discussed in this series. There is no doubt in my mind that IPv6 will be better than IPv4 and that it will continue to slowly replace IPv4 as the dominant protocol.
However, “new” in the software domain is generally regarded as a “bad thing” most notably from the security and reliability perspectives.
That’s not a criticism of today’s developers or the software development life cycle – just an observation that has been proven time and time again. The only way to identify and fix the defects that are guaranteed to exist in new software is to have it used as widely as possible for as long as possible.
IPv4 implementations have been subject to some of the most extensive production usage possible and there are still bugs being identified in code paths that have not been touched for years.
IPv6 has only just started on this journey and it is going to be a bumpy one – made worse by the amount of new firmware involved in the embedded and AMI world. Every device that is going to participate in the new IPv6 network will contain new firmware implementations of the IPv6 stack. There will be conflicting vendor interpretations of the standard, software and interoperability defects and revisions as IPv6 deployment grow. Delivering fixes to all of these firmware images and maintaining the requisite configuration management across the inventory of AMI meters will be a challenge.
To mitigate these risks I would defer the introduction of IPv6 software on the AMI meter for as long as possible.
How long is that?
The answer depends on whether the AMI meter vendor offers a viable upgrade path that will allow the move to IPv6 once the velocity of defect discovery has settled down to an acceptable level.
If there is an upgrade path via firmware update delivered over-the-air (OTA) then I would be happy to leave IPv6 out of the meter selection mandatory criteria.
On the other hand if the vendor does not offer an upgrade path then the risk of deploying meters with new and relatively untested firmware has to be measured against deploying meters that will remain on IPv4 for their useful life e.g. ten years.
IPv6 is essential to the success of future smart metering AMI solutions. When considering the long-term future, several core technical aspects demand more attention than they do with today's AMI needs whereby IPv4 is deemed adequate. The driving change forces behind the next generation of AMI solution will be:
- Internet of Things
- Security; and
- Distributed architecture.
The Internet of Things (IoT) is the next edition of the Internet itself some call it Web 3.0. The definition for this next generation of the Internet has evolved and changed from what we saw it as just five years ago. It is still an immersive environment, but not one based upon avatars and games whereby the user is emulated within the simulated virtual world. It is now a real world scenario whereby the user is immersed within their own physical environment and the devices surrounding them wrap the user in a dynamic bubble that maps and remaps as they move about their daily chores. In this same way, the IoT will make and break machine-to-machine relationships on demand and generate dynamic connections when needed to fulfill a request or a requirement. In the AMI environment, this will manifest as meters communicating with other meters, controllers, sensors and devices (or things) that share data. These things effectively move from a model that shares simple data towards one of information exchange and derived knowledge that is used to save energy, manage costs, control the smart home, and make lives better. Ultimately, we will migrate from this reactive knowledge world to one based upon predictive wisdom within the fabric of the AMI network.
Once you connect all of these things together, these ad-hoc networks pose a new potential risk. Therefore a new level of security and protection of data and privacy is necessary. The threat is serious. If someone could attack your immersive bubble wrapping around you and your family as well as the myriad devices within the fabric of your IoT model, then they may be able to do harm or control aspects of life or your environment that are undesired. Protecting against such intrusions is therefore essential. The IoT needs to operate within a trusted DMZ. The AMI solution needs to be protected within this same trusted DMZ so as to avoid these same risks and to ensure that these AMI devices and things can function as expected within a safe and protected environment.
In order for all of these changes to take place, then we will see a change to the fundamental architecture to the web itself and therefore by extension to the AMI network. We will move from a centralized model to a distributed model. The new model will share both client/sever designs as well as peer-to-peer designs in a hybrid approach. It will become autonomous and create many mini webs and not just one massive Internet. It will be a web of webs numbering into the billions. A hybrid architecture that is mostly distributed in nature will result.
It is for these key drivers that we must have IPv6. The number of connections will explode exponentially as the number of devices will be in the many billions. IPv4 cannot support this volume of IP addresses. Next generation AMI networks need to have security and privacy by design built-in to the fabric of the addressing schema that only IPv6 can provide and not simply a bolt-on after-thought approach like IPv4 employs today. With the change to the core architecture, the biggest change will come with the loss of a centralized approach, which is depended upon heavily by today's IPv4 designs. The core needs of Network Address Translation (NAT) and Dynamic Host Configuration Protocol (DHCP) servers will change dramatically and IPv4 will not be able to support this new model for the dynamic wrap around web. Only IPv6 can meet these future needs.
I am asked this question on a regular basis when I take questions after presentations about emerging Internet of Things technologies.
I am quite clear on the answer for the general IoT case, and more so for the case of AMI network infrastructure: IPv4 is quite sufficient. Through the use and re-use of reserved networks such as 10/8, we're never going to run out of addresses.
My first observation is that there are enough risks to the security of Smart Metering systems, without having them all publicly addressable and routable. Hiding them behind a diodic NAT gateway at least keeps them safe from prying eyes, port-scans, ping discovery, and most DOS attacks. For situations where a HES needs to gain direct access to an AMI device, private networks, either physical, or virtual using VPNs, enable host computer systems and AMI devices to appear to be on the same network enough to give the access required.
Secondly, the world is moving away from thinking about connectivity at the Network Services layer, and moving up the stack to the Application Services layer (OSI layer 4). This way of thinking brings the physical instantiation of a system closer to the mental model of the solution architect and implementer. Enterprise Messaging and other middleware messaging paradigms enable applications to talk to other applications, and more importantly allow the implementers to think about the solution in terms of functional entities communicating with each other. Of course, there needs to be the underlying network layers to support application level messaging, but those lower layers are just enablers for the application level messaging, and as long as they are sufficiently rich to support the patterns of interaction that the applications wish to use, then they will be fit for purpose.
For example, MQTT (http://mqtt.org) is an application-level publish-and-subscribe messaging protocol, widely used in M2M applications including AMI. All connections in MQTT are originated by the client - the meter in the AMI case. Once established, a keep-alive protocol is established between client and broker (server), and communication is two way as long as the connection is maintained. The client re-connects whenever the connection drops. There are numerous possible connectivity patterns using MQTT based on time, the need to publish data, and the likelihood and urgency of messages being delivered to the client.
In the extreme case of an unexpected urgent message from the broker, a "shoulder-tap" using an out-of-band signaling mechanism tells the client to "call home" and thus receives the waiting message. This is rarely needed, though, as maintenance of the client-to-broker connection can usually be arranged to cover the expected communications patterns for any given application.
So, IPv4 with diodic NAT gateways will enable billions of services to connect securely and communicate and collaborate as members of the Internet of Things, of which AMI devices will form a small part.