Using IPv6 with Messaging Server

Skip to end of metadata
Go to start of metadata

Using IPv6 with Oracle Communications Messaging Server

This information provides an overview of IPv6 with Messaging Server. It does not discuss how to configure your operating system or network for IPv6 operation. It is assumed that at a minimum you have configured the host operating system to have IPv6 network interfaces available for use by Messaging Server. The host operating system should have both IPv4 and IPv6 network interfaces enabled so that Messaging Server can communicate with IPv4-only clients and servers. Furthermore, operation in a pure IPv6 only environment is not supported by Messaging Server.

In reading this document, it is important to understand that IPv6 addresses are stored in the DNS using entries called "AAAA" records, often pronounced "quad A". DNS "A" records are, of course, the DNS entries for IPv4 addresses. In this document, we will use the phrase "address records" to collectively refer to both A and AAAA DNS records.


Basic Configuration

By default, Messaging Server only has IPv4 support enabled. Unless you change one of the configuration options described below, Messaging Server only accepts inbound IPv4 connections and only initiates outbound IPv4 connections. When you enable use of IPv6 for either inbound or outbound connections, Messaging Server continues to also allow IPv4 inbound connections and to use IPv4 outbound connections for host names which resolve to DNS A records.

The configuration options to control Messaging Server's use of IPv6 are, local.ipv6.out, and  local.ipv6.sortorder. They are configured with the configutil utility.

The following table shows the configutil parameters and their descriptions:

IPv6 Configuration Parameters

Parameter (possible values)
Description (0 or 1) Allow (1) or disallow (0) inbound IPv6 connections. When set to the value 1, all services allow inbound IPv6 and IPv4 connections (for example, POP, IMAP, SMTP, LMTP, HTTP, and so on). When set to the value 0, only IPv4 inbound connections are permitted. The default value for this option is 0.

Note: The behavior of the SNMP subagent is not altered by this option. The behavior of the platform's SNMP services as well as any SNMP subagents is controlled through the platform's SNMP configuration system.
local.ipv6.out (0 or 1) Allow (1) or disallow (0) outbound IPv6 connections. When this option is set to the value 1, all services which initiate outbound connections may use either IPv6 or IPv4 (for example, SMTP, LMTP, LDAP, remote POP and IMAP mail collection by mshttpd, and so on). The choice of IPv4 versus IPv6 may further depend on a specific service's configuration. See 3. Outbound IPv6 Connections for further discussion of this topic.
When local.ipv6.out is set to the value 1, Messaging Server will request both A and AAAA records from the DNS when performing DNS-based host name resolution. These records will be returned in whatever order the DNS sees fit. Further re-ordering may be performed by the platform's getaddrinfo() implementation. On Oracle Solaris, getaddrinfo() performs the re-ordering algorithm described in RFC 3484. See getaddrinfo(3SOCKET) for details.

If you wish Messaging Server to attempt all A records before any AAAA records, then set this option to have the value A-AAAA. To attempt all AAAA records first, use AAAA-A. To only honor AAAA records and thus only make IPv6 outbound connections, use the value AAAA. To only honor A records and thus only make IPv4 outbound connections, use A. To attempt the records in the order returned by getaddrinfo(), use the value DEFAULT.

The default setting for this option is DEFAULT.

Outbound IPv6 Connections

  1. To enable outbound IPv6 connections for all services, set local.ipv6.out to 1:
    # configutil -o local.ipv6.out -v 1 
  2. If using a compiled configuration for the MTA, run the following command:
    # imsimta cnbuild

It is not possible to enable IPv6 for specific services, it can only be enabled for all Messaging Server services.

When services attempt to connect to a remote host using a host name (as opposed to an IP address), they will first resolve the host name to one or more address records. The nature of the resulting address records will then govern whether or not an outbound IPv4 or IPv6 connection is used. For an A record, an IPv4 connection is used. For an AAAA record, an IPv6 connection is used. The local.ipv6.sortorder option may be used to influence which sort of records are used preferentially.

Services configured to use an IP address rather than a host name will establish a connection whose type-IPv4 versus IPv6-matches that of the configured IP address. An IPv4 connection for an IP address will have the form a.b.c.d, and an IPv6 connection will have the form a:b:c:d:e:f:g:h. For example, a tcp_ channel configured with daemon will only attempt IPv4 outbound connections.

Inbound IPv6 Connections

  • To enable inbound IPv6 connections for all services, set to 1:
    # configutil -o -v 1 

As with inbound connections, it is not possible to enable IPv6 for specific services. They can only be enabled for all Messaging Server services.

When inbound IPv6 connections are permitted on Oracle Solaris, all inbound connections appear to be IPv6 connections, even when the remote client is using IPv4. Specifically, when a remote client initiates an IPv4 connection to Messaging Server and Messaging Server is accepting both IPv4 and IPv6 inbound connections, then Oracle Solaris will report the remote source IPv4 address a.b.c.d as the IPv6 address ::ffff:a.b.c.d. Messaging Server will automatically map that IPv6 address back to the IPv4 address a.b.c.d before logging it or presenting it to any access tests.

TCP wrappers and MMP's Bad Guys Lists

The TCP wrappers used by service..domainallowed and service..domainnotallowed as well as the MMP's Bad Guys lists have been updated to allow specification of IPv6 addresses and IPv6 CIDRs (Classless Inter-Domain Routing). Both should be specified within square brackets. For an IPv6 address,


and for an IPv6 CIDR,


where a:b:c:d:e:f:g:h is the IPv6 address and p is the routing prefix. For IPv6, the routing prefix is an integer between 0 and 128, inclusive. IPv6 "::" short hand notation is supported.

When IPv6 support was added, the TCP wrappers and Bad Guys facilities were updated to allow IPv4 CIDRs in addition to IPv4 netmasks. Consequently, both the IPv4 CIDR format,


as well as the IPv4 netmask format


are supported.

Connection Counters

The connection counters controlled with the service.*.connlimits options have been updated to allow specification of IPv6 addresses and IPv6 CIDRs. For an IPv6 address,


and for an IPv6 CIDR,


where a:b:c:d:e:f:g:h is the IPv6 address, p is the routing prefix, and m is the connection limit.

When IPv6 support was added, the Connection Counter facility was updated to allow IPv4 CIDRs in addition to IPv4 netmasks. Consequently, both the IPv4 CIDR format,


as well as the IPv4 netmask format,


are accepted.

Formerly, the Connection Counter facility used the format\|

to specify a default limit for IPv4 connections which did not match a more specific limit. The Connection Counter facility has been updated to have a default limit for IPv6 connections as well as a more general default for connections which are either IPv4 or IPv6. This generic limit is specified using the format


And, the default limit for IPv6 connections has the format


The precedence for the connection limits are then

  1. Highest precedence to specific patterns of the forms a.b.c.d/m, a.b.c.d|w.x.y.z:m, and [a:b:c:d:e:f:g:h]:m.
  2. IPv4 connections which don't match any patterns from 1, are then limited by| (or, equivalently,, if it is specified and :m otherwise.
  3. IPv6 connections which don't match any patterns from 1, are limited by y [::0/0]:m if it is specified and :m otherwise.

Mapping Tables

The MTA mapping tables have had support for IPv6 addressing for many years; no new functionality to support IPv6 needed to be added. The basic format for specifying an IPv6 address or IPv6 CIDR in the mapping tables is:


where ipv6 is the IPv6 address or IPv6 CIDR. Refer to Mail Filtering and Access Control#Controlling Access with Mapping Tables for further details.


Messaging Server still uses its own internal resolver library to resolve MX and TXT DNS records. This is done because Oracle Solaris and other operating systems do not provide thread-safe resolver libraries for looking up MX or TXT records. (The getXbyY() routines are thread-safe but do not support MX or TXT record lookup operations.) Messaging Server's library for resolving MX and TXT records does not support the use of IPv6 for communicating with DNS servers.

MTA systems that need to do MX and TXT record lookups must be able to query DNS servers by using IPv4 network connections.

If a destination domain has an MX record(s) in DNS, the FQDN for a mail exchanger can be resolved to an IP address by using either A records, AAAA records, or both. The local.ipv6.sortorder configutil configuration parameter determines which address has precedence.

If a destination domain does not have an MX record in DNS, the domain name itself is used as the FQDN which is then resolved to an IPv4 and/or IPv6 address as previously described.

At present, Messaging Server does not provide a mechanism to bind services to specific IPv6 interfaces. Any site requiring this support should contact Oracle. This feature is absent because IPv6 doesn't provide for it; the designers of IPv6 disapproved of binding services to specific IP addresses and thus left the concept out of IPv6. However, most operating systems provide mechanisms for binding a service to a specific IPv6 interface. Unfortunately, these mechanisms are non-standard and, on some platforms, have changed with OS versions.

Use of JMQ is not supported when IPv6 is used; ENS should be used instead in that case.

messagingserver messagingserver Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.