- March 15, 2011
Automation.com, March 2011
ODVA is taking IPv6 seriously because it could have major implications for existing EtherNet/IP installations and product developers. This is not unique to EtherNet/IP, the change has an impact on all Ethernet devices and infrastructure including business, industrial, home, and mobile communications.
By Bill Lydon, Editor - March 2011
ODVA 2011 Annual Meeting Topic
ODVA is taking IPv6 seriously because it could have major implications for existing EtherNet/IP installations and product developers. This is not unique to EtherNet/IP, the change has an impact on all Ethernet devices and infrastructure including business, industrial, home, and mobile communications. No EtherNet/IP device today can communicate with IPv6 devices.
In a technical session at the recent ODVA annual meeting titled, IPv6 for EtherNet/IP: Is the Sky Falling, or Just an Acorn?, Brian Batke, Principal Engineer, and Paul Brooks, Business Development Manager, both of Rockwell Automation, discussed the implications of the IP address shift to IPv6 on EtherNet/IP. This change has the potential to create incompatibilities between EtherNet/IP products and the plant Ethernet infrastructure including switches and routers.
Background – Running Out of IP Addresses
The existing IP addresses based on IPv4 are not enough to support the growing number of users. The pool of available IPv4 addresses is expected to be depleted sometime in mid-2011. At that time, new IPv4 addresses will cease to be assigned by IANA (Internet Assigned Numbers Authority www.iana.org ) and the Regional Internet Registries and replaced with IPv6 addresses. IPv6 provides a 128 bit IP address, which is significantly larger than IPv4’s 32 bit, and IPv6 inherently supports multicast.
IPv4 address example: 192.0.2.235
IPv6 address example: 2001:CDBA:0000:0000:0000:0000:3257:9652
The very large IPv6 address space supports a total of 2128 (about 3.4×1038) addresses, which are approximately 5x1028 addresses for each of the roughly 6.5 billion people alive in 2006. While this seems like a large number, consider the addresses consumed by most business people with multiple IP addresses (home internet, cell phone, laptop, etc.)
IPv6 allows private addressing with Unique Local Addresses (ULA). A Unique Local Addressing in IPv6 cannot be routed on the Internet. These devices will always have to remain behind a router.
IPv6 does not support IGMP which is used by EtherNet/IP. Rather it has Multicast Listener Discovery (MLD) that is similar in function to IGMP but MLD is a sub-protocol of ICMPv6 rather than a separate protocol.
IPv6 has clever support for mobility with Mobile IPv6 that allows a node to maintain a persistent “home address” as it moves to different network locations.
The China Next Generation Internet (CNGI) project is a five year plan initiated by the Chinese government in 2003 with the purpose of gaining a significant position in the future development of the Internet through the early adoption of IPv6. The first Chinese next generation Internet, the CNGI-CERNET2, was completed in 2005. As of October 2009, the CNGI effort comprises six nationwide backbone networks and 39 GigaPOPs, which extends the next generation footprint to over 20 major cities and over 300 academic, industrial, and government research campuses within China. Five backbones are commercial (operated by China Telecom, China Unicom, China Netcom/CSTNET, China Mobile, and China Railcom), with an additional academic research network operated by CERNET, which is known as CNGI-CERNET2. China showcased CNGI and the IPv6 network infrastructure at the 2008 Olympics in Beijing for the website www.beijing2008.cn.
United States Federal Government
The Obama administration's CIO informed federal agencies in a memo September, 28, 2010 that they must run native IPv6 on their Web, email, ISP, and DNS servers and services by the end of fiscal year 2012, and their internal client applications by fiscal year 2014. You can read the memo at: http://www.cio.gov/Documents/IPv6MemoFINAL.pdf. This initiative puts a large commercial emphasis on conversion to IPv6 in the United States.
Internet Protocol Security (IPsec) is mandatory in IPv6 and is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite. It can be used in protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host). Some other Internet security systems in widespread use, such as Secure Sockets Layer (SSL), Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers of the TCP/IP model. Hence, IPsec protects any application traffic across an IP network. Applications do not need to be specifically designed to use IPsec. The use of TLS/SSL, on the other hand, must be designed into an application to protect the application protocols.
Many suggest that the Smart Grid is the “killer app” for IPv6. If millions of new Smart Grid devices require Internet connectivity, it seems clear that they will need IPv6 addresses. IPv6 support is likely to be needed if EtherNet/IP is to be seriously considered for Smart Grid applications.
Existing EIP Application Scenarios
It was noted that the majority of discussion on IPv6 deployment is oriented towards Internet Service Providers and IPv6 clients accessing an IPv4 Internet.
Most EtherNet/IP applications reside within an enterprise network and it may be a long time before IPv6 is required. RTU applications using a 4G wireless network are the first EtherNet/IP applications that will likely require IPv6 support (e.g., water/wastewater, oil and gas, etc.).
The presentation at the ODVA meeting summarized EtherNet/IP changes required for IPv6 compatibility. Simply including an IPv6 stack in an EtherNet/IP device is not sufficient to enable the devices to then communicate via EtherNet/IP. A number of changes to the protocol are required, as well as definition of how certain IPv6 features should commonly be used by EtherNet/IP devices. The following are anticipated changes to the EtherNet/IP protocol and specification to support IPv6:
- ListIdentity response. The response to the ListIdentity command (used for network browsing) includes the IPv4 address of the responding device. Either a new command or a new response item is needed.
- Fwd Open Request/Response. The Fwd Open request and response (used to establish CIP connections between devices) typically includes IPv4 addresses – in particular when multicast connections are being established. New structures are needed to communicate IPv6 addresses in the Fwd Open request/response.
- TCP/IP Interface Object. An EtherNet/IP device’s IPv4 address and related items are configured via the TCP/IP Interface Object. At present this object has no support for IPv6 configuration. Either new object attributes are required, or more likely, a new object needs to be defined to support IPv6 configuration and diagnostics.
- IP Address Conflict Detection. IPv4 Address Conflict Detection (ACD) is currently defined for EtherNet/IP. For IPv6, ACD is defined as part of the Neighbor Discovery Protocol. In order to support IPv6 the EtherNet/IP specification will need to clarify the usage of the Neighbor Discovery Protocol in the specific context of EtherNet/IP device behavior.
- IP Multicast Usage. EtherNet/IP devices use IP multicast when transmitting data on a multicast CIP connection. At present only IPv4 multicast usage is defined, including mechanisms for assigning specification must include details on usage of IPv6 multicast addresses and the Multicast Listener Discovery protocol (MLD), which replaces IGMP. We have rules now for how to generate multicast addresses and how those get used, this would have to change.
- Device Level Ring (DLR) Protocol. Several aspects of DLR would be impacted by IPv6 support:
- 4-byte source IP address field in DLR header
- 4-byte IP address field in Sign-On message payload
- 4-byte IP addresses in DLR Object attributes: Last Node on Port 1, Last Node on Port 2, Ring
- Supervisor Address, Ring Participants List.
- CIP Safe would need to have changes.
Recommendations were made to provide for device consistency. The EtherNet/IP specification should clarify what aspects of IPv6 – including whether to use a dual IPv4/IPv6 stack – are required, recommended, and optional for EtherNet/IP devices. In addition, further investigation work was recommended to assess the impact of required features such as IPsec on resource-limited devices.
The presenters stated, “…incorporating IPv6 support into EtherNet/IP is largely a future-proofing exercise, a number of potential user benefits could result from work to include IPv6 support, and include:”
- Simplified Device Commissioning. While some invention would likely be required, adding IPv6 support would be an opportunity to make use of IPv6 Autoconfiguration and Neighbor Discovery features to define common behavior to simplify IP configuration during device commissioning and device replacement scenarios.
- Security. The requirement that IPv6 nodes implement IPsec has the potential to address the security issues of device authentication and message encryption in a proven and standard way. Further work would be needed to determine whether IPsec is an appropriate answer to EtherNet/IP security questions.
- Opportunity for Protocol Improvements. Definition of IPv6 support in EtherNet/IP would create a new class of EtherNet/IP implementation, and would present the opportunity for additional protocol and feature improvements not bound by backward-compatibility concerns.
Thoughts & Observations
Continue to use existing IPv4 investments while determining exactly how and when to fully adopt IPv6 standards.
Keep up to date on how your vendors plant to utilize IPv6 with industrial IPv4 networks “underneath” them.
Companies that dictate IPv6 enterprise networks to gain its advantages, including greater security, would pose a problem for existing installations. The presenters believe this is not a likely scenario in the short term for industrial networks.
In order to avoid surprises it would seem a good idea to advise IT departments that it may be some time before controls and automation will be IPv6 and that existing controls will be IPv4 for a long time to come. Work with IT to define a transition plan to IPv6 rather than waiting for the IT department to dictate a change.
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe