Multi-Protocol Functionality with Oracle Connection Manager

Earlier versions of Oracle Net, back in the SQL*Net and Net8 era, described Oracle Connection Manager as a universal protocol translator. A client speaking one networking protocol and a database speaking a completely different one could still reach each other, with CMAN sitting in the middle doing the conversion. That era's typical example paired a client on an SPX/IPX network (the transport used by older Novell NetWare installations) with a database reachable only over TCP/IP, and had CMAN bridge the two.

That general-purpose conversion is gone. The Oracle Connection Manager listener always listens on the TCP/IP protocol in Oracle AI Database 26ai, which means CMAN itself no longer speaks SPX, Named Pipes, or any other non-TCP transport on the client-facing side. If your organization is still running clients or applications on one of those legacy protocols, Connection Manager is not the tool that will bridge them into a 26ai database; that migration has to happen upstream, at the client itself.

What survives under the "multi-protocol" heading today is narrower, but still genuinely useful: CMAN can mix plain TCP and TCP with TLS (TCPS) within a single deployment, and it can bridge IPv4 and IPv6 when the two sides of a connection path don't share an IP version. Both of these are current, documented features of Oracle AI Database 26ai, and this lesson covers each in turn.

Listening on TCP and TCPS at the Same Time

As covered in the fourth lesson of this module, a single cman.ora file can configure more than one listening address under ADDRESS_LIST, and there is nothing stopping those addresses from using different protocols. A common pattern is TCP on one port and TCPS (TCP/IP with TLS) on another:

CMAN=
  (ADDRESS_LIST=
    (ADDRESS=(PROTOCOL=tcp)(HOST=cman-server)(PORT=1521))
    (ADDRESS=(PROTOCOL=tcps)(HOST=cman-server)(PORT=2484))
  )

With both addresses configured, Oracle Connection Manager accepts unencrypted TCP connections on one port and TLS-protected TCPS connections on another, at the same time, from the same instance. A client configured to reach CMAN over TCPS connects on the TLS port; one still using plain TCP connects on the regular port; neither configuration affects the other.

Oracle documents specific default and officially registered port numbers for Connection Manager, worth knowing when you are deciding which ports to assign in a dual-listening configuration like the one above:

Port	Purpose
1521	Default and officially registered listening port for client connections to Oracle Connection Manager
1830	Default and officially registered listening port for administrative commands to Oracle Connection Manager, used by CMCTL
2484	Officially registered port for TCP/IP with TLS, commonly reused as the TCPS listening port for Connection Manager alongside 1521 for plain TCP

None of these are hardcoded requirements; a cman.ora file can bind to any port Oracle allows. Using the standard ports, though, means less to document and fewer surprises for anyone else who has to administer the instance later.

TLS on One Side, Plain TCP on the Other

Dual listening addresses are only part of the picture. Oracle Connection Manager can also be configured so that the connection arriving from the client uses one protocol, and the connection CMAN makes onward to the database server uses a different one entirely, TLS on one side and non-TLS on the other. This is distinct from simply listening on two ports; it means a single logical connection can change its transport security partway through its path.

In practice this is most useful at a network boundary. Picture an application server and CMAN sitting on the same trusted internal segment, with the database reachable only by crossing into a less trusted part of the network. The application server can connect to CMAN over plain TCP, since that leg never leaves trusted territory, while CMAN's own connection onward to the database runs over TCPS, so the traffic is encrypted for the leg that actually crosses the boundary. The reverse arrangement, TLS from the client to CMAN and plain TCP from CMAN to the database, works the same way for the opposite scenario, where the exposed leg is the client side rather than the database side.

Either direction depends on CMAN actually being configured to originate or terminate TLS, which means a wallet containing the certificates Connection Manager needs has to be in place on the CMAN host, not just on the client or the database server. Without that wallet configured, the TCPS side of the connection simply will not negotiate, regardless of how the ADDRESS_LIST entries are written. This is a separate, one-time setup step from the per-connection TLS/non-TLS mixing described here; once the wallet is in place, any number of connections can cross the TLS boundary CMAN is configured to enforce.

This also ties back into session multiplexing, covered in the third lesson of this module. When CMAN's gateway process already holds a TCPS connection open to the specific destination a new client request is targeting, it multiplexes the new request onto that existing connection rather than negotiating a fresh TLS handshake and opening a second one. The practical effect is that mixing TLS and non-TLS legs does not multiply the number of encrypted connections CMAN has to maintain to a given database; multiplexing still applies on the TCPS side exactly as it does on the plain TCP side.

Bridging IPv4 and IPv6

The second protocol-flexibility feature that survives into Oracle AI Database 26ai has nothing to do with TLS. Some connection paths involve a client and a database that simply use different versions of the Internet Protocol, so that at least one hop along the way has no native connectivity: an IPv4-only client trying to reach an IPv6-only database, an IPv6-only client trying to reach an IPv4-only database, or even an IPv6-to-IPv6 path that happens to cross a network segment that only routes IPv4.

Oracle Connection Manager can sit at exactly that kind of boundary and bridge the two IP versions, but only under one specific condition: the machine CMAN runs on has to be a dual-stack host, configured with at least one IPv4 interface and at least one IPv6 interface. CMAN does not convert IPv4 packets into IPv6 packets or vice versa at the protocol level; rather, it terminates the connection on whichever stack the client used, and opens a fresh connection to the database on whichever stack the database actually listens on, using the host's own dual-stack networking to make both legs possible from the same machine.

It is worth being precise about what this feature is and is not. Oracle Net Services, independent of Connection Manager, already supports IPv6 natively; a client and a database that both speak IPv6 do not need CMAN in the path at all to connect over it. The bridging feature described here is specifically for the case where the two sides disagree about which IP version to use, and CMAN's dual-stack host is what lets a single instance speak to an IPv4-only peer on one leg and an IPv6-only peer on the other, within the same connection.

Access Control Rules and IPv6 Addresses

Once Connection Manager is bridging IPv4 and IPv6, its access control rules need to be able to describe both kinds of addresses. As covered in the sixth lesson of this module, a RULE in the RULE_LIST is built from SRC, DST, SRV, and ACT fields, and CMAN's filtering feature supports writing the SRC or DST field as an IPv6 address exactly the way it supports IPv4, including the same /nn subnet notation for partial matches.

An IPv6 address is written as eight groups of four hexadecimal characters, separated by colons, with each hexadecimal character representing four bits of the full 128-bit address. Consecutive zero groups can be collapsed with a double colon. A rule written to accept traffic from a specific IPv6-only client reaching a specific IPv4-only database host, routed through a CMAN instance acting as the bridge between them, looks like this:

(RULE=(SRC=2001:0db8::203:BAFF:FE0F:C74B)(DST=192.0.2.45)(SRV=sales.example.com)(ACT=accept))

The source is the full IPv6 address of the client, the destination is the IPv4 address of the database host, and the service name identifies which database service the rule applies to, exactly as it would in a same-protocol rule. Nothing about how RULE itself works changes when the two sides of the connection use different IP versions; the bridging happens at the connection level, and the access control layer simply needs to be able to name both kinds of addresses.

The same double-colon shorthand used above, collapsing one or more consecutive all-zero groups down to ::, is standard IPv6 notation rather than anything specific to CMAN, and it can appear in either the SRC or DST field of a rule wherever the address itself contains a run of zero groups. A subnet written with /nn works the same way for an IPv6 range as it does for IPv4, just against a 128-bit address instead of a 32-bit one, so an administrator who already understands how subnet rules work for IPv4 traffic through CMAN does not need to learn a second syntax for IPv6 traffic, only the address format itself.

Where This Actually Comes Up

Both of these remaining protocol-flexibility features solve real, narrow problems rather than being general-purpose conveniences. TLS on one side and plain TCP on the other is most often reached for during a phased move toward encrypting all database traffic: an organization might require TLS on every connection that leaves a given data center, while traffic within a single trusted segment stays on plain TCP a while longer, with CMAN as the point where that boundary is enforced rather than every client needing to be reconfigured at once.

IPv4-to-IPv6 bridging shows up for essentially the same reason, on a longer timeline: most organizations are not migrating every client and every database to IPv6 simultaneously, and a dual-stack CMAN instance lets the two sides move on different schedules without either one blocking the other. Neither feature is a replacement for the old-style multi-protocol conversion this lesson used to describe; both are purpose-built for the specific transitions Oracle Net Services actually supports moving across today, TLS adoption and IPv6 adoption, rather than an open-ended claim about traversing "as many networking protocol stacks as could be installed."

A single Connection Manager instance can also combine both roles rather than only ever doing one or the other. Consider a database migrating onto a new network segment that only provisions IPv6 addresses, while most existing application servers in the organization are still IPv4-only and TLS has only been rolled out as far as the data center boundary. A dual-stack CMAN instance placed at that boundary lets the still-IPv4 application tier keep connecting the way it always has, over plain TCP to a familiar IPv4 address, while CMAN itself holds both the IPv6 reachability the new database segment requires and the TCPS leg the data center boundary requires. From the application server's point of view, nothing about how it connects has to change for either migration to proceed; both transitions happen at the CMAN layer instead of rippling out to every client.

For a broader look at how Oracle connectivity itself has evolved since the Net8 era this lesson's original material was written in, including Easy Connect Plus and OCI-native connection methods, see our guide to modern Oracle connection methods.

The next lesson concludes this module, bringing together the Connection Manager configuration, access control, and multi-protocol material covered across the previous nine lessons.