ODP.NET + Unexpected traffic on port 6200 (Oracle Notification Services) - oracle

Question

We've got a client using our product, which includes a windows service built using .NET 4+, Entity Framework, and ODP.NET. For some reason in one particular installation, but not any other, the windows service appears to be generating traffic on 6200. Oracle Documentation indicates this is the port Oracle Notification Services uses. This is unexpected because our product does not utilize ONS. I've found other Oracle Documentation that indicates that RAC / Fast Failover also uses ONS, but we've confirmed with the client that they do not use RAC in any environments, and we are not using the RAC options in the connection string. We are also not (to our knowledge) using Database Change Notifications or doing any cache/verification of cached data, which it sounds like also leverages ONS.
Can anyone help explain why we would be generating port 6200 traffic, and more importantly, how to get it to stop? Thanks!
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</configSections>
<connectionStrings [Redacted] />
<appSettings [Redacted] />
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
<parameters>
<parameter value="v11.0" />
</parameters>
</defaultConnectionFactory>
<providers>
<provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
<provider invariantName="Oracle.ManagedDataAccess.Client" type="Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices, Oracle.ManagedDataAccess.EntityFramework, Version=6.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
</providers>
<contexts>
<context type="[Redacted]" disableDatabaseInitialization="true" />
</contexts>
</entityFramework>
<system.data>
<DbProviderFactories>
<remove invariant="Oracle.ManagedDataAccess.Client" />
<add name="ODP.NET, Managed Driver" invariant="Oracle.ManagedDataAccess.Client" description="Oracle Data Provider for .NET, Managed Driver" type="Oracle.ManagedDataAccess.Client.OracleClientFactory, Oracle.ManagedDataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
</DbProviderFactories>
</system.data>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1" />
</runtime>
</configuration>

Answer 1

We've narrowed the culprit down to one or more of 3 Oracle / ODP.NET specific Connection String settings:
ENLIST, HA EVENTS, and/or LOAD BALANCING
Oracle's documentation on Fast Application Notification tipped us off to these settings which we had not been aware of. This lead us to Oracle's documentation on all of their Feature Connection String Attributes.
Enlist - Default "true" - Serviced components automatically enlist in
distributed transactions.
HA Events - Default "false" - Enables ODP.NET connection pool to
proactively remove connections from the pool when a RAC service,
service member, or node goes down.
Load Balancing - Default "false" - Enables ODP.NET connection pool to
balance work requests across RAC instances based on the load balancing
advisory and service goal.
We set all 3 to explicitly be false, and the port 6200 connections ended.
ENLIST=false; HA EVENTS=false; LOAD BALANCING=false;
If the defaults are to be believed then Enlist was the culprit, but client's availability did not allow for discrete testing to confirm. We've come across other various documentation linking all 3 of these pieces of functionality to Oracle Notification Services & port 6200.

Answer 2

It may depend on the installed Oracle client version. In 12.1.0.2 auto-configuration of ONS feature was released. It may have something like ONS auto-discovery at the beginning of establishing a DB connection which produces this traffic.