Migrating Industrial Ethernet IPv4 Network
to IPv6
A Phased Approach to IPv6 Transition
Technical Trackwww.odva.org

Enterprise Network

DMZ

Internet
Web Server

App Server

Remote Facility/Vendor
Supervisory Network

Database

Cloud Systems
SCADA

HistorianControl System Network
HMI

Wireless Field Network
Historian

6TiSCH

IEDs/PLCs

Industrial IPv4 Network
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

VPN

page 2www.odva.org

Bigger address space
Efficient routing and packet processing
Directed data flows
Simplified network configuration
Support for new services
Conforming IPv6 implementation must support IPSec

Why Migrate to IPv6
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 3www.odva.org

There’re some common
IPv6 transition
mechanisms that can beused for migrating Industrial
Network…
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 4www.odva.org

Apps

Apps

Apps

Transport (TCP/UDP)

Transport (TCP/UDP)

Transport (TCP/UDP)

IPv4

IPv4

IPv6

IPv6

MAC

MAC

MAC

PhysicalPhysicalPhysicalIPv4 Host

IPv4 Network

Dual-Stack Host

IPv6 Network

Dual-Stack Endpoints
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 5www.odva.org

IPv6 Host

① What the IPv6
address of“foo.example.com”?

② What the IPv4
address of“foo.example.com”?

DNS Server
DNS64 Server④ It’s64:ff9b::c00:21a.

③ It’s192.0.2.26.

IPv4 Network

IPv6 Network

IPv6 Host

IPv4 Server“foo.example.com”(192.0.2.26)

NAT64 Gateway(192.0.2.1)⑤ Packet is sent to64:ff9b::c00:21a.

⑥ Packet istranslated with
src=192.0.2.1 anddst=192.0.2.26.

NAT64 and DNS64
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 6www.odva.org

IPv4 Network
MAP CE

IPv4 Network

IPv6 Network

IPv4 Network

MAP BR

IPv4 Network

IPv4 Network

MAP (Mapping Address + Port)
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 7www.odva.org

The combination of NAT64
and Dual-Stack Endpoints
is the main transition
strategy for Industrial
Network.
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 8www.odva.org

2–3
years

5 - 15years

1-2 years

Time

Stage 1•Migrating fromIPv4-only network
to dual-stacknetwork•IPv4-only and IPv6only nodes co-exist
on the same network•No dual-stacksupport is requiredon endpoints•Intelligence is in the
network

Stage 2

Stage 3•Migrating IPv4only endpoints to
IPv6•No dual-stacksupport is requiredon endpoints•NAT64 is used forcommunication
between IPv4 andIPv6 endpoints

IPv6 Migration Strategy and Stages
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 9www.odva.org•Migrating fromdual-stacknetwork to IPv6only network•All network
endpoints support
IPv6•IPv4 is no longer
needed on the
network

Minimize
network topology
changeSimplify
upgrading
process

Endpoint
upgrade isindependent
from networkchangeWhy We’re Taking this Approach?
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 10www.odva.org

Protect
investment on
existing machine
endpoints forlonger period

Stage 1 – Migrate IPv4Only Network to DualStack Network

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 11www.odva.org

Instead of transforming
the entire Enterprise andControl network to dualstack in one single
motion, it’s better to takea phased approach…

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

Migratethe Control
Network
Migrate theEnterprise
IT network

page 12www.odva.org

MigratetheRemoteSites andFacilities

Dual-Home Gateway
Cloud Server

Application
TCP/UDPTCP/UDPIPv4

IPv6
MAC Layer

Core Network

Physical Layer
M2M Gateway andService Aggregator

Regional Network

Wireless IPv6 Network

Wireless IPv6 Network

Wireless Field Network is Driving IPv6 Adoption
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 13www.odva.org

Migration Path

Migration Path

Migration Path
Migration Path

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 14www.odva.org

Build intelligent networkthat supports both IPv4 andIPv6 endpoints
Preserve existing network
topology and protect
existing network
investment
Separate network migration
completely from IPv6
upgrade on endpoints

Stage 1 Objectives
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 15www.odva.org

Replace regular layer-3 routers andgateways with NAT64-capable devices
via HW and/or SW upgrade

Replace IPv4 DNS servers with DNS64
servers

Install DHCPv6 servers to serve stateful
DHCP requests.

Use a central NMS to manage all NAT64
gateways and DNS64 servers and ensure
consistent configuration across all
systems

What’s Need to be Done for Stage 1
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 16www.odva.org

NAT64 will be used tofacilitate thecommunications between
IPv4 and IPv6 hosts inall three stages. It’s
supported by NAT64
gateway and NAT64 DNS
server, and completelytransparent to endpoints.

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 17www.odva.org

Configure NAT64 Gateway

Configure DNS64 Server•All layer-3 routers and gateways should support NAT64.
•A separate IPv4 address pool should be configured for each NAT64
gateway to facilitate translation.
•To allow IPv4 clients access IPv6 servers, the same static address
mappings must be created on NAT64 gateways for IPv6 servers.
•Routing must be configured properly for IPv4 and IPv6 networks toensure correct path for translated traffic.

•The DNS64 server must support dual-stack and serve DNS
requests from both IPv4 and IPv6 endpoints.
•Every A record should have a corresponding AAAA record withtranslated address, and vice versa (this mapping may be generated
dynamically).
•Configuration on DNS64 servers must be consistent with NAT64
gateways.

NAT64 Configuration
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 18
www.odva.org

Stage 2 – Migrate IPv4-only
Endpoints to IPv6

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 19
www.odva.org

Support each
endpoint to
upgrade to IPv6
independently

Allow different
software andhardware products
to be upgradedindependently

Stage 2 Objectives
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 20www.odva.org

Upgrade servers, employee
desktops, laptops, andimportant IT assets to IPv6
Upgrade HMI, Historian, andother assets on the
Supervisory network to IPv6

Upgrade PLCs, Drives, andother I/O devices to IPv6

What’s Need to be Done for Stage 2
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 21www.odva.org

IPv6-only
Host
accesses
IPv4 Server

IPv4-only
Host
accesses
IPv6 Server

Remote IPv4only Host
accesses
local IPv6
server via
VPN

Communication Scenarios in Stage 2
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 22www.odva.org

••Acquire Destination IPoIPv6 host queries “historian.example.com”o

DNS server finds the A record of 192.0.2.26.

o

DNS64 server translate A record to AAAA recordand returns 64:ff9b::c00:21a.

Contact DestinationoHost sends first packet to 64:ff9b::c00:21a.

oPacket is routed to the default IPv6 gateway,
which is the NAT64 gateway.

oo•

NAT64 gateway re-encapsulates payload in IPv4
packet with the destination IP address of
192.0.2.26 and the source IP address of its
own (192.0.2.1).

Enterprise Network

Translatedestination IPv6
address
64:ff9b::c00:21a
to IPv4 address
192.0.2.26 andvice versa

NAT64 gateway sends the IPv4 packet tohistorian.

DMZ
DNS64 Server

Return AAAA recordof
64:ff9b::c00:21afor“historian.example.
com”

NAT64 Gateway(192.0.2.1)

Supervisory Network

Handle Return TrafficooHistorian accepts request and sends back IPv4
response to NAT64 gateway.

Historian at
192. 0.2.26

NAT64 gateway re-encapsulates payload in IPv6
packet with the destination IP address of thehost and source IP address of
64:ff9b::c00:21a.

Database

Scenario 1 – IPv6-only Host accesses IPv4 Historian (Stateful
NAT64 Translation)
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 23www.odva.org

•Enterprise Network
Mail server at
2001:db8::12
Translate pop3
traffic withdestination IPv4
address 192.0.2.1
to 2001:db8::12
and vice versa•

Return A record of
192.0.2.1 for“pop3.example.com”

DMZ•

DNS64 Server
NAT64 Gateway(192.0.2.1)

Supervisory Network

Historian at
192. 0.2.26

Database•

Configure static address mapping on NAT64 gateway
and DNS64 servero

Map 192.0.2.1/110 to 2001:db8:12/110oCreate A record of 192.0.2.1 for“pop3.example.com”

Acquire Destination IPoIPv4 host queries “pop3.example.com”o

DNS server returns the A record of 192.0.2.1.

Contact DestinationoHost sends first POP3 TCP packet to 192.0.2.1.

oPacket is routed to the default IPv4 gateway, whichis the NAT64 gateway.

o

NAT64 gateway re-encapsulates payload in IPv6
packet with the destination IP address of
2001:db8:12 and the source IP address of
64.ff9b::c00:21a.

o

NAT64 gateway sends the IPv6 packet to the mailserver.

Handle Return TrafficoMail server accepts request and sends back IPv6
response to NAT64 gateway.

o

NAT64 gateway re-encapsulates payload in IPv4
packet with the destination IP address of the host
(192.0.2.26) and source IP address of 192.0.2.1.

Scenario 2 – IPv4-only Host accesses IPv6 Server (Stateless
NAT64 Translation)
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 24www.odva.org

•Remote VPN gateway establishes IPSec VPN tunnel with thelocal VPN gateway on the Supervisory Network, which also
happens to be the NAT64 gateway.

•

Configure static address mapping on NAT64 gateway and
DNS64 server

•

•

o

Map 192.0.2.61 to 2001:db8:66

oCreate A record of 192.0.2.61 for “hmi.example.com”

Supervisory Network

DNS64 Server

HMI at2001:db8::66

Acquire Destination IPoRemote IPv4 host queries “hmi.example.com”. Request is sent
over VPN to the DNS64 server on Supervisor Network.

o

DNS server returns the A record of 192.0.2.61.

Return A record of
192.0.2.61 for“hmi.example.com”

VPN

Contact DestinationoRemote host sends TCP packet to 192.0.2.61.

oPacket is tunneled to the VPN + NAT64 gateway.

o

NAT64 gateway decrypts packet and re-encapsulates payload
in IPv6 packet with the destination IP address of 2001:db8:66
and the source IP address of 64.ff9b::c00:21a.

o•

NAT64 + VPN
Gateway(192.0.2.1)

NAT64 gateway sends the IPv6 packet to the IPv6 HMI.

Handle Return Traffico

HMI accepts request and sends back IPv6 response to NAT64
gateway.

o

NAT64 gateway re-encapsulates payload in IPv4 packet withthe destination IP address of the host (10.10.1.126) andsource IP address of 192.0.2.61. Packet is encrypted and sent
to the remote VPN gateway.

VPN
Gateway

Field Network
Drive
Remote PLC
10.10.1.126

Scenario 3 – Remote IPv4-only Host accesses IPv6 Server
across VPN
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 25www.odva.org

Dependencies on the
IPv4 Infrastructure

IPv4 Address Embeddedin Control Protocols

IPv4-based Management
Tools and Utilities• Using IPv4 address asdevice and service
identifiers• Always assume a fourbyte IP address• Rely on the broadcast
and multicast functionsof IPv4• For example, the
ListIdentity response
message in
EtherNet/IP protocol
contains the IP addressof the responding
device• Ring protocols (e.g.
DLR) may embed IP
address as part of the
payload.
• The EtherNet/IP
configuration objects
may contain IP address
definitions• Existing network andautomation
management tools
present IPv4-based
management interfaces

Issues and Challenges for Stage 2
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 26
www.odva.org

• Industrial protocols need to re-designed to work with IPv6.
• Management tools must be
upgraded to support IPv6.
• Control systems that are
engaged in the same control
loop (e.g. using the same
protocols) should be upgraded
together to avoid any issues
with NAT64.
• I/O devices on the same Ring
topology must be upgraded
together.

Address the Challenges in Stage 2
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 27www.odva.org

Stage 3 – Migrate DualStack Network to IPv6Only Network

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 28
www.odva.org

Support smoothtransition to fullIPv6-only network

Allow different
network segments
to be migrated
independently

Stage 3 Objectives
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 29
www.odva.org

Selectively disable NAT64
functionality on NAT64 gateways andDNS64 servers and test drive IPv6only network

Create small IPv6 pockets byreplacing NAT64 gateways with regular
IPv6 gateways. Merge small IPv6
pockets into bigger IPv6 subnets.

Remove all IPv4 infrastructure assets(e.g. gateway, DNS server, DHCP
server, … etc). And then celebrate!

What’s Need to be Done for Stage 3
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 30
www.odva.org

NAT64 is a complex
technology. Here’s a list ofchallenges we’ve solved andyou need to know…

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 31www.odva.org

Smaller IP
Path MTU on
IPv6
Network

Optional UDP
Checksum on
IPv4
Network

IPv4 and
IPv6
Fragments

Unnecessary
Translation
for DualStack
Endpoints

Different
Endpoints on
the Same
Layer-2
NetworkSpecialProtocols

Common NAT64 Problems
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 32
www.odva.org

IP Multicast

BrokenIPSec VPN

IPv4 Header vs. IPv6 Header

•
•

•

•

The IP Path MTU (Maximum
Transmission Unit) on IPv6 network issmaller due to larger IPv6 header.
To avoid fragmenting translated
payload on IPv6 network, the IP Path
MTU on IPv4 network should be set ata lower value (e.g. 1460).
If not possible to configure the MTU on
IPv4 endpoints, NAT64 gateways must
participate in Path MTU Discovery andnotify IPv4 endpoints of the new MTU
value.
NAT64 gateways must be able tofragment big IPv4 datagrams thatexceed MTU on IPv6 network.

Solution to “Smaller IP Path MTU on IPv6 Network”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 33
www.odva.org

IPv4 Header and UDP Header

•

•
•

•

NAT64 gateway must recalculate TCP and
UDP checksums, which is typically done bycalculate the difference between the twodifferent pseudo-headers.
UDP checksum is mandatory on IPv6
network, but is optional in IPv4.
NAT64 gateway must recalculate UDPchecksum using the entire payload datawhen it receives an UDP datagram with zerochecksum.
If the zero-checksum UDP datagram is alsoa fragment, NAT64 gateway must
reassemble the UDP datagram before recalculating the checksum. If the fragments
arrive out of order, the UDP datagram may
end up being dropped.

Solution to “Optional UDP Checksum on IPv4 Network”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 34
www.odva.org

IPv4 and IPv6 pseudo-headers
Source IP Address•••

IPv6 fragments are handled endto-end. IPv6 router shall neverfragment an IPv6 datagram.
If IP fragments arrive in order,
NAT64 gateway will translate
fragments as they arrive. States
will be maintained on the gateway
to translate following fragments.
If IP fragments arrive out of order,
NAT64 gateway queues fragments
until the first fragment arrives, atwhich time translation will be done
for queued fragments as well.

Destination IP Address
Reserved (0)ProtocolPayload Length

Source IP Address

Destination IP Address

Payload Length
Reserved (0)Solution to “IPv4 and IPv6 Fragments”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 35
www.odva.org

Protocol

•
•

•

•

Some endpoints may support dual-stack,though not required.
To talk to another endpoint, the dual-stackhost needs to know whether to use IPv4 orIPv6. If wrong stack is chosen, unnecessarytranslation may occur.
To solve this problem, separate DNS servers(independent from DNS64 server) should be
configured for IPv4 and IPv6 network
independently. The host should always use
the stack on which a valid DNS record was
returned.
The host should send the query on IPv6
network first. If a valid AAAA record isreturned on IPv6 network, the host must not
send the DNS query on IPv4 network. If forsome reason the host receives valid DNS
records on both networks (e.g. timeout thefirst query too quickly), it’s up to the host to
decide which stack to use for talking to theother endpoint.

Solution to “Unnecessary Translation for Dual-Stack
Endpoints”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 36www.odva.org

• Both IPv4 and IPv6 endpoints
may be on the same layer-2
network (e.g. same VLAN andconnected by same switches).
• NAT64 gateway must be able toperform translation on any
physical or logical interface, andmust handle the scenario where
source and destination endpoints
are connected to the same
physical or logical port.
• IPv4 and IPv6 endpoints should
be grouped into separate layer-2
networks whenever is possible.

Solution to “Different Endpoints on the Same Layer-2
Network”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 37
www.odva.org

• Some protocols embed IP
addresses in the protocol
payload, e.g. FTP, RTSP, PPTP,
SIP, EtherNet/IP… etc.
• You shall only install NAT64
gateways that support ALG(Application Level Gateway)
functionality for these protocols.
• If the NAT gateway doesn’t
support the required ALGs, toavoid service disruption, clientand server endpoints using these
protocols should be migrated to
IPv6 at the same time.

Solution to “Special Protocols”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 38
www.odva.org

•

•

•
•

•

•

Some protocols use IP multicast for communications,e.g. EtherNet/IP. In order to forward such multicast
traffic across the NAT64 boundary, NAT64 gateway
must be able to translate between IPv4 and IPv6
multicast packets.
NAT64 gateway should maintain the one-to-one
mappings between IPv4 and IPv6 multicast
addresses. The mapping entries can be manuallyconfigured or hard-coded.
NAT64 gateway must be able to function as a MLD or
IGMP proxy on each network interface, and translate
MLD and IGMP messages accordingly.
Because multicast IP address is embedded in the
Explicit CIP message setting up the multicast
exchange, NAT64 gateway must implement the CIG
ALG that is capable of translating IP addresscontained in such messages.
When SSM (Source-Specific Multicast) was specified
by an endpoint, NAT64 gateway should translate thesource IP address of the multicast if it knows the
mapping; otherwise, NAT64 gateway will have todrop the source in the translated messages. Notethat when the IGMP version on the IPv4 network is
not 3, all SSM information from MLD will be lost intranslation.
In a CIP environment, if the installed NAT64
gateway cannot meet the requirements oftranslating CIP multicast packets, you should disable
multicast on EtherNet/IP CIP endpoints.

Solution to “IP Multicast”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 39
www.odva.org

•
•

•

IPSec AH and IPSec ESP in Tunnel
Mode breaks because it protects theouter IP header.
A single IPSec ESP session in Transport
Mode generally works across NAT64
gateway. Multiple sessions between an
endpoint and the NAT64 gateway may
not work because PAT cannot be
performed on IPSec ESP. You should
install NAT gateways that support
IPSec pass-through if you need to pass
IPSec VPN traffic through thegateways.
NAT-T negotiation or IPSec-over-UDP(i.e. NAT-T without negotiation) shouldbe always enabled for all IPSec
endpoints.

Solution to “Broken IPSec VPN”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 40
www.odva.org

There’re some NAT64
challenges that are
specific to the Industrial
Control Network…

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 41www.odva.org

Ring Topology

Large Complex
Layer-2 Network

Time
Synchronization

Industrial Specific NAT64 Problems
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 42www.odva.org

Real-Time andDeterministic
Performance• Some ring protocols (e.g. DLR)
embed IP address in the payload.
Such protocol will need updates
to support IPv6 addresses.
• Due to the nature of ring
topology, traffic may go either
direction on the ring. When
there’re multiple exits, traffic
may go in and out of the ring
through different gateway
devices.
• The ring exit/gateway must not
be a layer-3 device, hence not a
NAT64 gateway.

Solution to “Ring Topology”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 43
www.odva.org

•
•

•

IPv4 endpoints on large layer-2
network may be upgraded to IPv6
at different times.
Complex layer-2 control network
makes communication between
IPv4 and IPv6 hosts difficult.
While it’s possible for the same
NAT64 gateway to handle thetranslation “hairpin” style, such
deployment may run into problem
on a large complex network.
If problem does occur, NAT64
gateways need to be installed topartition the complex layer-2
network.

Solution to “Large Complex Layer-2 Network”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 44
www.odva.org

• Timing is a critical aspect ofIndustrial Control Systems.
• Typically PTP (Precision Time
Protocol or IEEE1588) is used
to synchronize time on thecontrol network at a very finelevel.
• Layer-2 PTP should always be
used (i.e. directly over
Ethernet) instead of over UDP
to avoid any potential
problems with NAT64.

Solution to “Time Synchronization”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 45
www.odva.org

•
•

•

The communication between control
systems needs to be real-time anddeterministic.
NAT64 implementation needs tominimize the forwarding delay possibly
by offloading actual translation to
hardware.
To meet the deterministic requirement,
the same technique used on the IPv4
network needs to be carried over to the
IPv6 network (e.g. IEEE TSN). NAT64
gateway must be able to handle thosesignaling protocols and participate in
the actual scheduling operation should
it be on the actual packet path.

Solution to “Real-Time and Deterministic Performance”
Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 46
www.odva.org

Intelligent Network is the
key to IPv6 migration…

Technical Track© 2014 ODVA, Inc.

2014 Industry Conference & 16th Annual Meeting
All rights reserved.

page 47www.odva.org