Secure IPv6 Network Architecture for a State Department of Transportation

Introduction and FISMA Compliance Requirements

A State Department of Transportation (DOT) network must support modern IPv6 connectivity while maintaining strict security and regulatory compliance. The impetus for migrating to IPv6 includes IPv4 address exhaustion and the need to mitigate IPv4-specific vulnerabilities (e.g. NAT limitations and fragmented security policies). Under the Federal Information Security Management Act (FISMA), the DOT’s network must align with NIST security controls and guidelines. This design leverages IPv6 features to improve security and scalability, but recognizes that IPv6 is not inherently more secure than IPv4 – it introduces new protocol behaviors that must be managed. The architecture described here emphasizes security, scalability, and manageability using industry-standard practices and a minimal set of well-integrated components. Key objectives include strong network segmentation, robust IPv6-specific security controls, secure routing, and comprehensive monitoring/logging to meet FISMA requirements for risk management and continuous monitoring. All recommendations cite best practices from authoritative sources such as NIST, DHS/CISA, and relevant federal guidance.

Network Topology and Segmentation Strategy

A segmented network topology is critical for both security and performance. The DOT’s network is divided into multiple security zones, each separated by firewalls or routers implementing access controls. Major zones include:

Corporate IT Network (Enterprise Zone): Standard business IT infrastructure (user workstations, office LANs, business servers).
Operational Technology (OT) Network: This includes SCADA systems, Intelligent Transportation Systems (ITS), traffic control devices, sensors, and other connected infrastructure. These systems form an ICS/SCADA environment requiring special protections.
ICS DMZ (Industrial Demilitarized Zone, “Level 3.5”): An intermediary network segment between the corporate IT and OT networks. This zone houses jump servers, data historians, application gateways, and patch management servers that need to communicate between IT and OT, and it terminates all connections between these zones.
External DMZ (Extranet/Perimeter Zone): A zone for external connectivity – e.g. connections to federal systems, contractor networks, and the public Internet. This zone hosts external-facing services (web portals, email, VPN gateways) and implements Trusted Internet Connection (TIC) guidelines for secured external access.
Management Network: A separate segment for out-of-band management of network devices and critical servers. This network is tightly controlled and accessible only to authorized administrators, ensuring secure management channels.

Figure: Example of a tiered network architecture aligning with the Purdue Model, separating Enterprise (IT) and Operations (OT) networks with an intermediate ICS DMZ (Level 3.5). The OT network (Levels 0-3) includes field devices, PLCs, and control systems, while the IT network (Level 4-5) is an external/corporate zone. All cross-zone communication passes through secured conduits (firewalls in DMZs) with policies enforcing least privilege.

Each zone is further segmented by function and trust level. For example, within the OT network, systems are segmented according to the Purdue Model levels for ICS security. Field devices and controllers (Levels 0-1) reside in isolated subnets that connect to site-level control networks (Level 2). Supervisory and control center systems (Level 3) aggregate OT data and interface with the ICS DMZ (Level 3.5). This layered segmentation limits lateral movement; even if an attacker compromises one segment, they cannot freely traverse the entire network.

Firewalls at key junctions enforce segmentation. A firewall between the Corporate IT network and the ICS DMZ allows only explicitly authorized traffic (e.g. historian data, specific API calls) to pass, blocking all else by default. Similarly, a firewall between the ICS DMZ and the core OT network strictly permits only the necessary industrial protocols (e.g. secure SCADA protocols, telemetry data) to flow, and can implement unidirectional rules or data diodes if appropriate for safety. This DMZ approach ensures that corporate and Internet traffic is kept away from sensitive OT devices, greatly reducing exposure. All connections between IT and OT terminate in the DMZ, where additional security inspection and mediation can occur. For example, a corporate user accessing an ICS historian would connect to a proxy or replicated database in the DMZ rather than directly into the control network.

External connectivity is confined to the External DMZ. For Internet-bound traffic, the DOT can leverage a TIC-compliant secured gateway that supports IPv6. External partner connections (to federal agencies or contractors) should terminate in an isolated extranet segment, with dedicated firewall rules or VPN concentrators governing these links. No direct external connections into the core corporate or OT networks are allowed – all are brokered via the DMZ with strict access controls and monitoring. This mitigates the risk from external threats and provides a single choke point for applying federal security standards to inbound/outbound traffic. In line with zero trust principles, even internal segments authenticate and validate traffic; for instance, an office subnet communicating with a data center subnet may pass through an internal firewall or router ACL enforcing least privilege on allowed protocols.

Overall, the segmented topology supports least privilege access, containment of potential breaches, and clear trust boundaries. It aligns with NIST guidance for isolating critical systems: “services should be controlled at the firewall between corporate and ICS network segments”. By separating IT and OT and introducing DMZs, the design creates layers of defense that protect critical transportation infrastructure while still enabling necessary data flow.

IPv6 Address Planning and Allocation

The DOT should develop an IPv6 addressing plan that is hierarchical, scalable, and easy to manage. Unlike IPv4, IPv6 provides an enormous address space, allowing the DOT to assign generous prefixes to sites and segments rather than conserving addresses per device. Best practice is to base the addressing structure on locations and functions (sites and zones), not on individual device counts. For example, each major site or region (e.g. headquarters, district offices, data centers, field hubs) can be assigned a dedicated prefix (such as a /48), from which that site’s subnets are derived. NIST guidelines note that site allocations are commonly /48, /56, or /64 prefixes from the organization’s larger block. A larger site like the main data center might get a /48, whereas smaller field locations could get /56, depending on the overall prefix obtained from the ISP or state IT authority. This site-based allocation supports route summarization (aggregation) at the core, reducing routing table size and simplifying access control by prefix.

Within each site, subnets should be sized at a standard /64 prefix, which is recommended for LAN segments in IPv6. Using consistent prefix lengths (typically /64 for subnets) simplifies network operations and is generally required for features like stateless address autoconfiguration. The addressing plan should use hierarchical, nibble-aligned subnets – meaning that prefix boundaries align on 4-bit (hex digit) increments – to make addresses more readable and to cleanly fit into nybble boundaries. For instance, the DOT could use an addressing scheme where:

The first portion of the IPv6 address (global routing prefix) identifies the DOT’s allocation (e.g. **2001:0db8:**xxxx::/32 assigned by a registry or ISP).
The next bits designate the site or region (e.g. **2001:0db8:**SSSS:0000::/48 for site “S”).
Within the site’s /48, a range of /64 subnets are defined. For example, 2001:0db8:SSSS:0100::/64 for the Corporate LAN at that site, ...:0200::/64 for the OT network at that site, ...:0F00::/64 for the site’s DMZ, etc. Each functional network gets a distinct /64. By incrementing subnets in hex (such as 0x0100, 0x0200, etc.), the boundaries are clean and easier to recognize.

This structure not only aids human comprehension but also allows firewall rules and route filters to be applied per-site or per-zone (e.g. a rule might allow OT network prefixes to talk to ICS DMZ prefixes but not others). The Washington State IPv6 guidelines echo this approach: plan for addressing based on number of sites (not devices), reserve blocks for infrastructure, and lay out subnets in equal sizes within each hierarchy level. The “end user device count is no longer a factor” in IPv6 design – every subnet has ample addresses, so design instead for operational logic (sites, departments, security zones).

Address types and usage: All devices needing routable network access should get global unicast IPv6 addresses, eliminating the need for NAT. IPv6’s huge address space means even internal devices can have unique, routable addresses – an approach encouraged by the NSA and federal guidelines to avoid NAT if possible. Non-routable Unique Local Addresses (ULA) (fc00::/7) can be used for purely internal communication that will never leave the DOT network (for example, a back-end management network or certain isolated OT segments). However, any system that requires external connectivity (to the Internet or partner networks) should be assigned a global IPv6 address for end-to-end reachability. If ULAs are used, those systems should also have a global address when they need to communicate externally, since NAT is generally avoided in IPv6. The design strives for an IPv6-only or dual-stack minimal environment, so that eventually no address translation is needed at the network edge; end-to-end addressing improves transparency and security (e.g. easier to trace and correlate addresses).

Static vs. dynamic addressing: For critical infrastructure components and servers, static or stable addresses are recommended for reliability and ease of management. For example, routers, firewall interfaces, and servers (including SCADA master stations or traffic management servers) should have manually assigned IPv6 addresses. This avoids issues where auto-generated addresses might change (e.g. if a network interface card is replaced, a new EUI-64 based address could be formed). One strategy is to give such devices meaningful, structured interface IDs, such as numbering them sequentially or encoding the function in the last 64 bits. This makes it easy to identify a device from its IP (for instance ...:0200::1 might always be the primary router on a subnet, ...:0200::50 a specific PLC controller, etc.). End-user devices (like employee workstations or mobile devices) can use dynamic addressing – either Stateless Address Autoconfiguration (SLAAC) or DHCPv6 – depending on the DOT’s preference for host tracking. SLAAC is convenient but generates addresses (often random “privacy” addresses) that change over time for privacy reasons, complicating auditing. In an enterprise environment, many agencies opt for DHCPv6 for address assignment to user devices, for better control over address issuance and easier logging of MAC/DUID to IP mappings. The DOT can deploy DHCPv6 servers in each subnet (or use relay to central servers) to hand out addresses and record leases. Note, however, that DHCPv6 uses a DHCP Unique Identifier (DUID) for clients, which can sometimes make tracking less straightforward than IPv4’s MAC-based leases. Administrators should ensure their IP Address Management (IPAM) systems and logs correlate DUIDs to device identities for audit and incident response purposes.

Finally, the addressing plan should reserve ranges for infrastructure such as point-to-point links, loopback addresses, and anycast addresses. For instance, allocate a specific /64 out of each site’s block for router loopbacks and inter-router links (possibly using /126 or /127 for point-to-points). This avoids mixing infrastructure addresses with user subnets. All allocations should be documented in an IPAM database. As the state DOT transitions, it’s important to track which devices are IPv6-capable and which are not, planning upgrades for those that are not IPv6-ready. This ensures that as IPv6 becomes the primary protocol, no critical device is left behind unaddressable.

Secure Routing Protocol Options

Routing in the IPv6 network must be both robust and secure. The architecture should use modern routing protocols that support IPv6 natively and configure them with authentication and integrity protections to prevent route spoofing or hijacking. For internal routing (within and between DOT sites), OSPFv3 (Open Shortest Path First version 3) is a strong choice as it is designed for IPv6. OSPFv3 operates separately from OSPFv2 (which was for IPv4). Unlike OSPFv2 which had options for cleartext or MD5 authentication, OSPFv3 does not include built-in authentication fields – instead, it relies on IPv6’s IPsec for security. RFC 4552 (OSPFv3 Authentication/Confidentiality) specifies using IPsec AH or ESP to secure OSPFv3 packets. In practice, this means configuring routers to apply IPsec in transport mode for OSPF traffic: using the AH header (or ESP with null-encryption) to ensure integrity and authentication of routing updates. This prevents an attacker from injecting false routes. Because OSPFv3 sends updates to multicast addresses, manual keying may be needed (since IKE doesn’t work with multicast). The DOT should implement a robust process for distributing and periodically changing these manual keys (or use group key management solutions if available) to maintain routing security. Alternatively, the DOT could consider other IGPs like IS-IS for IPv6, which also supports IPv6 and can be run in a single multi-protocol instance; IS-IS can be secured with Hash-based authentication on LSPs. If the network is a Cisco-only environment, EIGRP for IPv6 is another option, which supports IPv6 natively and can use keyed MD5/HMAC for route update authentication. Regardless of protocol, route authentication is mandatory – all interior routers should reject any routing update that is not properly authenticated.

For external routing (e.g. between the DOT network and an ISP or to a state/federal backbone), BGP will be the typical protocol. BGP can carry IPv6 routes (using MP-BGP extensions). The DOT should ensure eBGP sessions are secured with mechanisms like BGP TTL Security (limiting the allowable hop count for BGP packets to prevent off-path spoofing) and TCP MD5 or TCP-AO authentication on BGP sessions. When exchanging routes with external partners, implement prefix filtering and route policies to only accept/donate the necessary IPv6 prefixes – this prevents route injection attacks or inadvertent advertisement of DOT internal networks. If connecting to the broader Internet, the DOT should consider deploying Route Origin Validation (RPKI) for BGP, which helps ensure the authenticity of route announcements.

Within the internal network, the DOT may also leverage IPv6’s abundant addresses to simplify routing in some cases. For example, using a unique /48 per site means core routers can carry summary routes for each site rather than thousands of individual /64s, improving scalability. If certain sensitive networks (like OT control subnets) require additional isolation, the DOT could run them in a separate VRF or routing instance, even with separate OSPF processes, and only import/export specific routes via firewall or gateway devices. This way, even at the routing level, corporate and ICS routes can be kept distinct and only a controlled subset are shared through the ICS DMZ.

Routing infrastructure security: All routers and layer-3 switches must be configured to filter routing protocol traffic at segment boundaries – e.g. no OSPFv3 from an end-device VLAN, no RAs from unauthorized segments, etc. This ties into first-hop security (discussed later) but is worth noting: the network should drop any unexpected routing advertisements. Additionally, enable anti-spoofing measures like uRPF (Unicast Reverse Path Forwarding) on routers where appropriate to prevent packets with forged source addresses (IPv6 uRPF can be applied similar to IPv4, and is an effective anti-spoofing control).

Finally, as part of FISMA’s contingency planning controls, ensure the network has routing redundancy and failover. IPv6 can run on redundant core links and support rapid convergence. Protocols like OSPFv3 should be tuned for fast hello/dead timers on critical links (while considering stability), and if using multi-homing with BGP, employ BGP best practices for fast failover (BFD, etc.). Secure routing is not only about preventing malicious changes but also about resiliency (availability is a security goal). Thus, the architecture uses dynamic routing with authentication to quickly adapt to network changes or outages while resisting attacks on the control plane.

IPv6-Specific Security Controls

Deploying IPv6 brings new protocol features that require dedicated security controls. The following IPv6-specific measures will harden the DOT’s network against common IPv6 threats:

Router Advertisement (RA) Guard: IPv6 hosts learn network configuration from ICMPv6 Router Advertisements. Attackers can abuse this by sending rogue RAs (e.g. a malicious device pretending to be a router could redirect traffic). RA Guard is a feature typically on switches that filters out unauthorized RAs on ports where legitimate routers are not expected. The DOT should enable RA Guard on all access switches/ports in host subnets – only ports leading to actual routers (or trusted systems) should allow RA messages. This prevents rogue devices from tricking hosts into using a bogus default gateway or man-in-the-middle. Note: RA Guard implementations must be kept updated – fragmented IPv6 packets or clever evasion techniques have historically bypassed some RA Guard filters, so ensure network gear has the latest firmware that addresses known RA Guard bypass vulnerabilities. RA Guard is a crucial first line of defense given the reliance of IPv6 on dynamic router discovery.
DHCPv6 Shield/Guard: Similar to RA spoofing, an attacker could run a rogue DHCPv6 server to hand out incorrect addresses or DNS information to clients. Switches can implement DHCPv6 guard (often called DHCPv6-Shield) to permit DHCPv6 replies only from authorized servers or uplink ports. On user access networks, enable this feature so that only the DOT’s official DHCPv6 server responses are accepted. This stops malicious DHCPv6 responses that could misdirect traffic or launch on-path attacks. The CISA TIC guidance specifically recommends using DHCPv6 filtering rules to drop and log unauthorized DHCPv6 packets.
Neighbor Discovery (ND) Inspection / SEND: IPv6 uses Neighbor Discovery (ICMPv6) instead of ARP to find neighbors and resolve IP to MAC. ND is vulnerable to spoofing (e.g. neighbor solicitation/advertisement spoofing, causing cache poisoning). Some enterprise switches offer ND inspection/NA guard which works like DHCP snooping/ARP inspection in IPv4 – it builds a table of valid addresses and will block unsolicited ND messages that don’t match. The DOT should enable these features if available, especially in segments with high security (like OT device VLANs) to prevent spoofing of device addresses. An even stronger (but less common) option is Secure Neighbor Discovery (SeND), which uses cryptographic signatures on ND messages. However, SeND requires a PKI and support on all hosts, which may not be practical for a diverse environment (many ICS devices likely do not support SeND). At minimum, use RA Guard and ND inspection to cover the main attack vectors on IPv6’s first-hop mechanisms.
IPv6 ACLs and Bogon Filtering: Establish IPv6 packet-filtering at various points to drop obviously malicious or irrelevant traffic. For example, filter invalid or non-routable source addresses at the network edge (bogons like ::/128, ff00::/8 if not needed, or ULA addresses coming from the internet). Internal infrastructure should filter packets with spoofed link-local addresses or disallow external traffic claiming to be from internal prefixes. Many IPv6 security issues can be mitigated by the same default deny policy principle used in IPv4, applied comprehensively. The NSA IPv6 guidance emphasizes that IPv6 traffic should be filtered according to organizational policy, with only authorized flows allowed and all others blocked. If the DOT has an existing IPv4 ACL policy, use it as a model, but account for IPv6 differences (for instance, permitting essential ICMPv6 types).
ICMPv6 Rate-Limiting and Filtering: ICMPv6 is much more integral to IPv6 operation than ICMP was in IPv4. Messages like Router Solicitations/Advertisements, Neighbor Solicitations/Advertisements, and Packet Too Big are needed for basic network functionality (neighbor reachability and path MTU discovery). The firewall and router policies must allow necessary ICMPv6 types within and between networks – e.g. allow ICMPv6 type 134 (RA) from legit routers, type 135/136 (Neighbor Solicit/Advert) within local subnets, type 128/129 (ping) as needed, and type 2 (Packet Too Big) for MTU discovery. Conversely, filter or rate-limit other ICMPv6 types not needed or potentially abused (e.g. redirect messages could be filtered or at least restricted). Implementing ICMPv6 rate-limiting on routers helps mitigate flood attacks (e.g. someone sending excessive neighbor solicitations). The key is to strike a balance: do not blanket-block ICMPv6 as is sometimes done with ICMPv4 – doing so would break IPv6. Instead, follow RFC 4890 guidelines for ICMPv6 filtering, which detail which messages are essential. The firewall policies provided should explicitly enumerate allowed ICMPv6 types with any not listed being denied by default.
IPv6 Extension Header Handling: IPv6’s flexible header structure (extension headers) can be exploited – e.g. attackers can craft packets with numerous extension headers or hop-by-hop options that some devices cannot process efficiently, potentially causing evasion or denial of service. The DOT’s routers and firewalls should be configured to drop or tightly control unusual extension headers. For example, Routing Header Type 0 (RH0) was deprecated (RFC 5095) due to its misuse potential – ensure all devices drop RH0 packets. Likewise, if the DOT is not using any IPv6 mobility features, packets containing Mobility Headers can be dropped at the perimeter. Many organizations choose to drop packets with Hop-by-Hop options or unknown extension headers at security boundaries because they are rarely needed and can be used to obfuscate attacks. Firewalls should enforce that extension headers, if present, appear in the proper order and are not excessively daisy-chained. Modern IPS/IDS systems can also be configured to flag or drop packets with suspicious header patterns.
IPsec for Sensitive Traffic: IPv6 was designed with IPsec availability in mind. While IPsec is not mandatory for all traffic, the DOT should leverage IPsec or TLS encryption for particularly sensitive data flows. For example, communications between field ICS devices and central control might be encrypted using IPsec VPN tunnels (ESP) terminating at the ICS DMZ firewall or a dedicated VPN concentrator. Similarly, any site-to-site links over untrusted networks (like the public Internet) should use IPsec (or managed MPLS with encryption) to protect data integrity and confidentiality. IPsec can also provide device authentication at the IP layer – for instance, ensuring only authentic DOT field equipment can communicate with control center systems (using certificate-based IPsec authentication). This aligns with FISMA’s mandate to protect data in transit (encryption for confidentiality). Use of IPsec should be balanced with performance considerations (some low-power OT devices may not handle encryption overhead well), but where feasible, it adds a strong security layer. Even if end-to-end IPsec is not deployed everywhere, consider IPsec or TLS on application protocols (for example, use HTTPS for web interfaces, MQTT over TLS for IoT sensors, etc., instead of cleartext).

In summary, these IPv6-specific controls – RA guard, DHCPv6 guard, ND protections, proper ACLs including ICMPv6 allowances, extension header filtering, and judicious use of IPsec – collectively harden the IPv6 network. They address many of the new attack surfaces introduced by IPv6’s expanded feature set. Administrators must ensure network hardware and software support these features and that staff are trained to monitor and maintain them (e.g., periodically verify RA guard is active on all user ports, review logs of blocked RAs or DHCP replies to spot suspicious activity, etc.).

Firewall and IDS/IPS Configuration for IPv6

Perimeter Firewalls: The DOT’s firewalls (both at the external perimeter and between internal zones) must be fully IPv6-capable and configured with a default-deny posture, similar to IPv4. All security policies should have equivalent rules for IPv6 traffic as for IPv4, providing “IPv6 protection equivalent to IPv4”. When IPv6 is first introduced, it’s common to find firewall rulesets less mature on the IPv6 side, which can lead to inadvertent holes. The DOT should conduct a thorough review of firewall policies to ensure no overlooked allow rules for IPv6 that aren’t intended. For instance, if an IPv4 rule allowed TCP port 443 to a certain server, ensure the IPv6 rule does the same (and nothing more). Modern next-gen firewalls typically unify policies for both IP versions, but administrators must still verify this.

One important difference is handling of ICMP. As noted, firewalls should explicitly permit essential ICMPv6 types even if the equivalent might have been blocked in IPv4. For example, many IPv4 firewalls block all inbound ICMP for security, but with IPv6 Neighbor Discovery and PMTU, some ICMPv6 must be allowed. NIST and NSA guidance stress adjusting firewall rulesets to account for “IPv6-specific issues” in filtering – specifically the reliance on ICMPv6 and the presence of extension headers. The firewall should be tested to ensure it correctly parses IPv6 extension headers and can apply rules based on the ultimate upper-layer protocol. Some legacy firewalls had limitations in visibility when multiple extension headers were present. DOT should use current firewall platforms that are certified for IPv6 and preferably evaluated against relevant Protection Profiles or USGv6 Testing Program criteria.

Internal Segmentation Firewalls: In addition to perimeter firewalls, the design uses internal firewalls or filter routers between major zones (IT, ICS DMZ, OT). These devices should enforce network segmentation policies (as described in the topology section) for IPv6. For example, on the firewall between Corporate and ICS DMZ, write rules that only allow the specific IPv6 addresses and ports necessary for, say, historian data retrieval or remote desktop to a jump host, etc. All other IPv6 traffic between these zones is denied. By implementing such granular controls, even if an attacker compromises an IT host with an IPv6 address, they cannot freely reach an OT device over IPv6 – the firewall will block unauthorized lateral movement. The concept of least privilege and whitelisting should drive rule creation. Use groups of addresses (by prefix) to simplify – e.g., a rule might allow the central SCADA server prefix to talk to field device prefixes on certain ports, but not vice versa unless initiated appropriately.

Intrusion Detection/Prevention Systems (IDS/IPS): All existing IDS/IPS sensors must be upgraded or configured to recognize and analyze IPv6 traffic on equal footing with IPv4. FISMA compliance requires continuous security monitoring, which means our IDS should generate alerts for suspicious IPv6 activities just as for IPv4. NIST guidance explicitly states that organizations “must upgrade intrusion detection or prevention systems, firewalls, monitoring, logging, and auditing to provide IPv6 protection equivalent to IPv4”. The DOT should verify that its IDS signatures include IPv6 attack patterns (e.g. IPv6 port scans, fragmentation abuse, RA spoof attempts, etc.). Many IDS platforms (Snort, Suricata, Zeek, etc.) now have comprehensive IPv6 support, but this may need tuning. For example, enabling frag reassembly in the IDS is important because attackers might use tiny IPv6 fragments to evade detection (some IDS have options to drop or alert on IPv6 atomic fragments or very fragmented flows). The IDS should also be aware of extension headers – patterns that include extension header fields need to be accounted for in signatures. If using a Security Information and Event Management (SIEM) system, ensure it properly logs and parses IPv6 addresses in events – older systems might truncate or mis-handle the longer addresses.

In the OT segments, consider deploying specialized ICS/OT monitoring solutions in addition to traditional IDS. These passive network monitoring tools (offered by various ICS security vendors) can understand industrial protocols (DNP3, Modbus, OPC UA, etc.) and baseline normal traffic patterns, even over IPv6. Placing such a sensor at the junction of the ICS DMZ and OT network could provide early warning of abnormal behavior in the OT network (e.g. an unusual command to a PLC).

Firewall hardening and config for IPv6: The firewalls should implement protective measures at the IPv6 protocol level, such as:

Anti-spoofing filters: Drop traffic entering an interface that claims to have a source address from an invalid or unexpected prefix (e.g. no traffic from an internal DOT prefix should come from the outside interface). This can often be done with uRPF as mentioned, or with manual prefix filters.
Deep Packet Inspection: Ensure the firewall’s application-layer proxies or inspection engines support IPv6. For example, if the DOT firewall inspects HTTP traffic for threats, it should do so equally on IPv6 HTTP flows. Many next-gen firewall features (IDS, malware filtering) need to be explicitly enabled/tuned for IPv6 traffic – verify license or performance implications.
Logging: Configure the firewalls to log allowed and denied connections with IPv6 addresses. This is vital for incident response. Because IPv6 addresses are lengthy, test that logs are properly formatted and that the logging system can handle them. The logs will feed into the centralized monitoring discussed later.

Addressing firewall management and monitoring: The management interfaces of firewalls and IDS should preferably reside on the management IPv6 network (or be dual-stacked with IPv4 if necessary for existing tools) and secured via access control. All administrative access (SSH, HTTPS) must use strong authentication (ideally with multi-factor) and be restricted to management stations. This is particularly important in IPv6 because link-local addresses might inadvertently be used for management if global addresses aren’t assigned – ensure firewall management is bound to a specified address and not accessible from arbitrary zones.

In summary, the firewalls and IDS/IPS in an IPv6-enabled DOT network will operate much as in IPv4, but administrators need to account for IPv6-specific behaviors in policy. By following the principle of least privilege, allowing only known-good traffic and denying everything else by default, and by upgrading security devices to handle IPv6 nuances, the DOT can maintain a strong security posture. As an added best practice, security teams should run penetration tests or vulnerability scans specifically over IPv6 to verify that filtering rules and IDS detections are working as expected (sometimes rules might inadvertently be v4-only and a pen test can find those gaps).

Transition Mechanisms and Dual-Stack Considerations

During the migration from IPv4 to IPv6, the DOT network may operate in a dual-stack mode (both protocols enabled) or a hybrid environment. It’s important to securely manage this transition period to avoid introducing vulnerabilities. In a dual-stack network, every device has both an IPv4 and IPv6 address, effectively doubling the attack surface. Consistent security policies must be applied to both IPv4 and IPv6 – an open port in one is just as bad as in the other. The DOT should update its security policy documents to explicitly cover IPv6, and ensure teams monitor both protocol spaces. NIST and the IETF note that running both protocols can lead to “unintended interactions” or hidden tunnels. For example, hosts might use transition tunnels (Teredo, ISATAP, 6to4) if IPv6 connectivity seems partial – these should be detected and disabled unless explicitly needed. Policy: If a network segment is not yet ready for IPv6, proactively block all IPv6 traffic on it to prevent rogue usage. Conversely, if a segment is IPv6-only, block any unauthorized IPv4. This prevents shadow networks from forming.

The target architecture aims for IPv6-only networks in the long term, but external connectivity will still require interacting with IPv4 systems (since not all external services will be IPv6-enabled immediately). For that, the design can incorporate transition mechanisms:

Dual-Stack at Edge: E.g., servers that need to talk to both IPv6 and legacy IPv4 clients can run dual-stack. The network core can route both. However, the goal is to turn off IPv4 as soon as feasible on internal networks to reduce complexity. FISMA’s risk management approach would favor eliminating the weaker protocol once the transition is complete, as “employing both protocols becomes a security risk because of increased complexity”. Administrators should create a phase-out plan to disable IPv4 on segments that achieve stable IPv6 functionality.
NAT64/DNS64: For IPv6-only internal clients that need to reach IPv4 services (e.g., an IPv6-only workstation accessing an IPv4-only external website), a NAT64 gateway with DNS64 can be deployed in the External DMZ. DNS64 synthesizes IPv6 addresses for IPv4 DNS records, and the NAT64 device translates IPv6 requests to IPv4 on the wire. This allows internal clients to communicate with IPv4 servers without themselves running IPv4. The NAT64 should be sized and secured like a traditional NAT firewall, with logging of sessions for audit. Use NAT64 as a temporary bridge; as more services become IPv6 reachable, reliance on NAT64 can be reduced.
Application Proxies: Alternatively or additionally, use layer-7 proxies that are dual-homed. For example, an explicit web proxy that listens on IPv6 from clients and fetches content over IPv4 from the Internet, or an email gateway that does similar. This can add an inspection layer as well.
Tunnels for IPv4-dependent ICS: If any OT systems absolutely cannot be upgraded to IPv6 in the near term (for instance, a legacy traffic sensor that only speaks IPv4), one approach is to encapsulate IPv4 within IPv6 to traverse the IPv6 network. This might be done with simple IP-in-IP tunnels or by keeping a small isolated IPv4 subnet for those devices and using an application-layer gateway to communicate with them. The design preference, however, is to upgrade or replace equipment to be IPv6-capable wherever possible, as maintaining parallel infrastructures is costly and risky. The architecture includes an inventory and upgrade plan for legacy devices, to drive the network toward full IPv6 compliance (a requirement echoed by OMB’s IPv6 transition mandates).
Avoiding Deprecated Mechanisms: Certain early IPv6 transition methods (Teredo, 6to4 anycast, ISATAP) are not recommended due to security concerns and complexity. The DOT network should explicitly block 6to4 and Teredo traffic at perimeters (e.g., no IP protocol 41 in from internet unless specifically expected, and likely disable Teredo via Group Policy on Windows clients). Instead, use controlled point-to-point tunnels (GRE or IPsec tunnels) if any tunneling is needed between sites for IPv6 connectivity over an IPv4-only transport.

During the transition period, the DOT must also pay attention to monitoring: ensure that security monitoring covers both protocols. Tools like SIEM and flow analysis should ingest NetFlow/IPFIX data for IPv6 traffic as well. The architecture could include deploying IPv6 flow collectors on core routers to feed traffic analytics tools, helping detect any abnormal usage of transition tunnels or policy violations.

Finally, user training and procedures should be updated for IPv6. Network administrators and security analysts need training to understand IPv6 addresses (e.g., no more dot-decimal, how to interpret IPv6 in logs, etc.), the different notation, and the new tools (such as ping6, tcpdump showing IPv6, etc.). Helpdesk procedures should also be ready for IPv6 issues. Many issues during transition arise from misconfigurations – e.g., missing DHCPv6 settings or rogue RA servers – so having staff knowledgeable in these will smooth the rollout. Documenting the IPv6 addressing plan and network diagrams with IPv6 notations is an important part of that knowledge transfer.

Logging, Monitoring, and Vulnerability Management

A secure architecture is incomplete without strong monitoring and management processes. Under FISMA, agencies must implement continuous monitoring of their information systems (per NIST SP 800-137) and maintain an effective vulnerability management program. This design integrates logging and monitoring solutions compliant with these requirements:

Centralized Logging (SIEM): All network devices (routers, switches, firewalls, IDS, servers) should send their logs to a central log management or Security Information and Event Management (SIEM) system. The SIEM must fully support IPv6 in log parsing and correlation. For example, logs from an IPv6-enabled firewall will include IPv6 addresses for source/destination; the SIEM should index these just as it does IPv4 addresses. The SIEM use cases and correlation rules should be updated to include IPv6-specific events: e.g., alerts for multiple failed login attempts should consider both protocols; correlation of an IDS alert with a firewall deny should match on IPv6 addresses, etc. Logging is especially important for IPv6 because tracking “which device had which address” can be non-trivial when privacy addresses or DHCPv6 with DUIDs are involved. For instance, if a host uses SLAAC privacy addresses that change, the DOT’s monitoring systems should rely on complementary data like switch port tracking or DHCPv6 logs to identify the host behind an IPv6 address at a given time. Implementing IEEE 802.1X or other network access control can tie device identities to used IPv6 addresses, and feeding that into the logging system can assist audits.

The design calls for FISMA-compliant audit logging, meaning that logs should capture security-relevant events (per NIST 800-53 AU controls) and be protected from unauthorized access or tampering. Logs should be retained as required (often 1 year or more for audit logs) and backed up. An Audit Log Review process must be in place – e.g., daily automated scans of logs for critical events, and manual review of summaries weekly. Particular attention should be paid to logs concerning IPv6 network functions: for example, firewall logs of blocked IPv6 traffic, IDS alerts on IPv6 exploits, and router logs of any RA/DHCP guard triggers (some switches can log when RA Guard drops a packet, which could indicate an attempted spoof). These can reveal early signs of an attacker trying IPv6-based attacks that staff might not be as accustomed to.

Vulnerability Management: The DOT must regularly scan and remediate vulnerabilities in its systems. This includes running vulnerability scanners that support IPv6 to scan servers, network devices, and even OT devices (carefully). Many modern scanners (Tenable Nessus, Rapid7, OpenVAS, etc.) can scan over IPv6 – ensure they are configured to do so. Maintain an up-to-date inventory of all IPv6 addresses in use so that scans are comprehensive. For sensitive OT environments, implement an “ICS-safe” vulnerability management approach: use passive scanning or offline testing to avoid disrupting critical devices. For instance, one could duplicate the configuration of an OT device in a lab and test IPv6 updates there before production, or use an ICS-specific vulnerability monitoring tool that passively identifies device firmware versions and matches them to known vulnerabilities (as provided by sources like the DHS ICS-CERT advisories). Any found vulnerabilities should go through the risk management process with mitigation applied (patching, compensating controls, etc.) and tracked for FISMA reporting.

Security Patching: Ensure that all infrastructure components (routers, firewalls, ICS controllers, etc.) are running firmware that addresses known IPv6 issues. For example, earlier we noted RA Guard bypass techniques – many of those were mitigated in later updates on switch operating systems. The vulnerability management program should keep an eye on IPv6-related CVEs for network gear and apply patches promptly, in line with the DOT’s change management processes.

Continuous Diagnostics and Monitoring (CDM): The DOT, possibly in coordination with DHS/CISA programs, can implement tools from the federal CDM program. These tools often include sensors for network traffic (including IPv6), agent-based checks on configurations (ensuring IPv6 settings meet policy), and dashboards that give an overall security score. Incorporating IPv6 into these continuous monitoring tools is essential to maintain situational awareness. For example, a CDM network sensor might detect an unmanaged device that only has an IPv6 address on the network, which might be missed if one only watched IPv4 space.

Incident Response Preparedness: Incident response plans should be updated to account for IPv6. Handlers need procedures for tracing an IPv6 address to a physical device (using logs, switch neighbor tables, etc.), and forensic tools need to parse IPv6 pcap data. NIST SP 800-61 (Incident Handling Guide) and the agency’s security operations guidelines should explicitly reference IPv6 scenarios. Drills or tabletop exercises should include an IPv6-based incident (e.g., a mock detection of exfiltration over an IPv6 channel) to ensure the team is comfortable in that environment.

Finally, from a FISMA perspective, all these logging and monitoring activities tie back to required controls (AU-logging, CA-7 continuous monitoring, IR-incident response, etc.). The design not only establishes technology to meet those controls but also stresses policy and procedure: e.g., defining roles for reviewing logs, setting up automated alerts (so that, say, if an RA guard blocks an RA, an event is sent to SIEM and triggers an email to network security team). The use of “central log management with analysis” is explicitly highlighted in CISA’s IPv6 guidance as necessary for effective response – the DOT should have that capability in place. By proactively monitoring the IPv6 network and keeping the security tools up-to-date, the DOT will maintain a strong security posture and FISMA compliance as the network evolves into an IPv6-dominant infrastructure.

Conclusion

This technical design provides a comprehensive approach to deploying a secure, scalable IPv6 network architecture for a State DOT. By adhering to federal best practices (NIST, DHS/CISA, NSA) and industry standards, the design addresses the unique mix of enterprise IT and critical ICS/SCADA systems in the DOT environment. Key elements of the design include a robust segmentation strategy (with layered networks and DMZs isolating critical infrastructure), careful IPv6 address planning for clarity and growth, and use of IPv6-specific security controls (RA Guard, DHCPv6 guard, IPsec, etc.) to counter new threat vectors. Secure and authenticated routing protocols ensure the network’s core is trustworthy, while firewalls and IDS/IPS tuned for IPv6 traffic enforce policy at the perimeters. The design also incorporates strategies for a smooth transition from IPv4, leveraging dual-stack and NAT64 judiciously and avoiding the pitfalls of unmanaged hybrid networks. Finally, a strong emphasis is placed on FISMA-compliant logging, monitoring, and vulnerability management, recognizing that continuous oversight is vital to maintain security in the long term.

Through this architecture, the State DOT can confidently replace IPv4 with IPv6, gaining the benefits of ample addressing and modern network features without sacrificing security. The network will be positioned to support connected infrastructure and intelligent transportation systems for years to come, with the flexibility to interconnect with federal and partner systems securely. By implementing the recommendations and following cited best practices (e.g., NIST SP 800-119 for IPv6 security, NIST SP 800-82 for ICS segmentation, CISA TIC 3.0 IPv6 guidance), the DOT will meet or exceed FISMA requirements and provide a resilient, secure foundation for its mission-critical operations.

Sources:

NIST SP 800-119 – Guidelines for the Secure Deployment of IPv6
CISA (DHS) – IPv6 Considerations for TIC 3.0 (2022)
NSA – IPv6 Security Guidance (2023)
Washington State OCIO – IPv6 Implementation Guidelines (2023)
Dragos – ICS/OT Network Segmentation Best Practices (2022) (ICS DMZ usage)
NIST SP 800-82 – Guide to ICS Security (for reference on ICS network separation).

gitezri/ipv6-architecture