Support for IPv6 Networks

FlexNet Manager Suite 2020 R2 (On-Premises)
FlexNet Manager Suite supports inventory collection (and limited discovery in the case of local collection of Oracle data) within IPv6 networks. However, current requirements for, and restrictions on, this functionality mean that only the following forms of gathering FlexNet inventory are supported on IPv6 zones at the 2020 R2 release:
  • Agent third-party deployment
  • FlexNet Inventory Scanner
  • Core deployment (where you use third-party technology to deploy just the core inventory executables).
Specifically, since no forms of remote execution from an inventory beacon are currently supported in an IPv6 network, automatic deployment of the FlexNet inventory agent is not possible (that is, the Adopted case is impossible); and all forms of Zero-footprint activity are excluded in IPv6 networks. Of course, these remain available in IPv4 networks, along with all other existing functionality.
There are two slightly different approaches to support IPv6 in your on-premises implementation. The first of these is best suited to the case where you have limited subnets running IPv6, while much of your network continues using the IPv4 address family. In this case, it is simplest to place your application server(s) in a subnet using IPv4, so communications with the central server(s) use either HTTP or HTTPS communications running over an IPv4 network protocol.The need to support the IPv4 protocol at the top level of the architecture, and the IPv6 protocol at the low level with the local FlexNet inventory agent, means that at least one inventory beacon must be a dual-stack server that provides the bridge between the two protocols, as shown in the following architectural sketch:
IPv6 architecture on-premises

Reading from top to bottom, this sketch shows:
  • Your application server (or in larger implementations, multiple servers) continue(s) to support HTTP or HTTPS communications over an IPv4 network layer.
  • Within IPv4 zones of your network, you may deploy as many inventory beacons as required, either as a flat layer where each communicates directly with the application server, or in a hierarchy, as dictated by your network requirements. Of course, these inventory beacons provide full functionality, supporting all forms of FlexNet inventory gathering from target inventory devices within the IPv4 network (for simplicity, these devices in the IPv4 zone are not shown in the sketch above).
  • At least one inventory beacon must be a dual stack device that supports both IPv4 and IPv6 network layers. It does not matter whether this is achieved using two Network Interface Cards (NICs) or a single configurable NIC. The IPv4 interface links upward to its parent (whether that be to another inventory beacon in the hierarchy or directly to the application server). The IPv6 interface links downward to those of its child devices that are in the IPv6 zone (of course, other devices in the IPv4 network could also communicate through this inventory beacon, given its dual stack architecture). As shown, these IPv6 children may optionally include a further hierarchy of inventory beacons (which child inventory beacons would then be operating entirely within the IPv6 network).
  • Eventually, target inventory devices within the IPv6 zone that have locally installed FlexNet inventory agents communicate with at least one inventory beacon in the same zone; or where the lightweight FlexNet Inventory Scanner has been run on a target device, this can also communicate with the inventory beacon.
A variation on this approach is possible for cases where the majority of your network uses the IPv6 address family (and in particular, all your target inventory devices are in IPv6 subnets). You can make your central application server(s) dual-stack machines, supporting IPv4 for communications between themselves (this much is mandatory); but have all communications with inventory beacons using the IPv6 address family. This produces the following variation on our architecture diagram:
IPv6 architecture on-premises for IPv6 targets

There are further restrictions and requirements to add to these general sketches:
  • All inventory beacons operating within an IPv6 network (whether as single-stack IPv6 devices or dual-stack IPv4 and IPv6 devices) must utilize Microsoft IIS as the web service. The simple alternative self-hosted web server does not support the IPv6 protocol.
  • Inside an IPv6 network, an inventory beacon cannot import Active Directory details. However, a dual-stack inventory beacon that can communicate with a domain name server (DNS) over IPv4 can still import Active Directory data. Alternatively, an inventory beacon co-installed on your central application server (which by definition must have IPv4 available to it) can still access a DNS on IPv4 and import Active Directory data.
  • Inside an IPv6 network, an inventory beacon cannot do any of the following:
    • Import inventory from third-party sources
    • Import business data from other systems (such as your purchasing or HR systems)
    • Communicate with SAP systems in your IPv6 environment
    • Perform any inventory beacon-based discovery or remote inventory collection across the IPv6 subnet, including VMware host scans (such as required for special 30-minute scans for IBM PVU license management)
    • Adopt target inventory devices that can communicate only on an IPv6 subnet (instead, use third-party deployment to install the FlexNet inventory agent on target devices within an IPv6-only subnet).
    However, once again, a dual-stack inventory beacon that can communicate with a DNS over IPv4, and contact the various sources also exclusively over IPv4, still supports all the above functionality on the IPv4 side. This is also true of an inventory beacon co-installed on the application server.

FlexNet Manager Suite (On-Premises)

2020 R2