<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="group-replication-ip-address-permissions">
      </a>
      20.6.4 Group Replication IP Address Permissions
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045132298960">
  </a>
  <a class="indexterm" name="idm46045132297472">
  </a>
  <a class="indexterm" name="idm46045132295984">
  </a>
  <p>
   When and only when the XCom communication stack is used for
      establishing group communications
      (
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_communication_stack">
    <code class="literal">
     group_replication_communication_stack=XCOM
    </code>
   </a>
   ),
      the Group Replication plugin lets you specify an allowlist of
      hosts from which an incoming Group Communication System connection
      can be accepted. If you specify an allowlist on a server s1, then
      when server s2 is establishing a connection to s1 for the purpose
      of engaging group communication, s1 first checks the allowlist
      before accepting the connection from s2. If s2 is in the
      allowlist, then s1 accepts the connection, otherwise s1 rejects
      the connection attempt by s2. The system variable
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_ip_allowlist">
    <code class="literal">
     group_replication_ip_allowlist
    </code>
   </a>
   is
      used to specify the allowlist.
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    When the MySQL communication stack is used for establishing
        group communications
        (
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_communication_stack">
     <code class="literal">
      group_replication_communication_stack=MYSQL
     </code>
    </a>
    ),
        the setting for
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_ip_allowlist">
     <code class="literal">
      group_replication_ip_allowlist
     </code>
    </a>
    is ignored. See
    <a class="xref" href="group-replication-connection-security.html" title="20.6.1 Communication Stack for Connection Security Management">
     Section 20.6.1, “Communication Stack for Connection Security Management”
    </a>
    .
   </p>
  </div>
  <p>
   If you do not specify an allowlist explicitly, the group
      communication engine (XCom) automatically scans active interfaces
      on the host, and identifies those with addresses on private
      subnetworks, together with the subnet mask that is configured for
      each interface. These addresses, and the
   <code class="literal">
    localhost
   </code>
   IP address for IPv4 and IPv6 are used
      to create an automatic Group Replication allowlist. The automatic
      allowlist therefore includes any IP addresses that are found for
      the host in the following ranges after the appropriate subnet mask
      has been applied:
  </p>
  <div class="copytoclipboard-wrapper">
   <pre class="programlisting language-none"><div class="docs-select-all right" id="sa34986202"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-none">IPv4 (as defined in RFC 1918)
10/8 prefix       (10.0.0.0 - 10.255.255.255) - Class A
172.16/12 prefix  (172.16.0.0 - 172.31.255.255) - Class B
192.168/16 prefix (192.168.0.0 - 192.168.255.255) - Class C

IPv6 (as defined in RFC 4193 and RFC 5156)
fc00:/7 prefix    - unique-local addresses
fe80::/10 prefix  - link-local unicast addresses

127.0.0.1 - localhost for IPv4
::1       - localhost for IPv6</code></pre>
  </div>
  <p>
   An entry is added to the error log stating the addresses that have
      been allowed automatically for the host.
  </p>
  <p>
   The automatic allowlist of private addresses cannot be used for
      connections from servers outside the private network, so a server,
      even if it has interfaces on public IPs, does not by default allow
      Group Replication connections from external hosts. For Group
      Replication connections between server instances that are on
      different machines, you must provide public IP addresses and
      specify these as an explicit allowlist. If you specify any entries
      for the allowlist, the private and
   <code class="literal">
    localhost
   </code>
   addresses are not added automatically, so if you use any of these,
      you must specify them explicitly.
  </p>
  <p>
   To specify an allow list manually, use the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_ip_allowlist">
    <code class="literal">
     group_replication_ip_allowlist
    </code>
   </a>
   system variable. You can change the list while Group Replication
      is running.
  </p>
  <p>
   The allowlist must contain the IP address or host name that is
      specified in each member's
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
    <code class="literal">
     group_replication_local_address
    </code>
   </a>
   system variable. This address is not the same as the MySQL server
      SQL protocol host and port, and is not specified in the
   <a class="link" href="server-system-variables.html#sysvar_bind_address">
    <code class="literal">
     bind_address
    </code>
   </a>
   system variable for
      the server instance. If a host name used as the Group Replication
      local address for a server instance resolves to both an IPv4 and
      an IPv6 address, the IPv4 address is preferred for Group
      Replication connections.
  </p>
  <p>
   IP addresses specified as distributed recovery endpoints, and the
      IP address for the member's standard SQL client connection if that
      is used for distributed recovery (which is the default), do not
      need to be added to the allowlist. The allowlist is only for the
      address specified by
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
    <code class="literal">
     group_replication_local_address
    </code>
   </a>
   for each member. A joining member must have its initial connection
      to the group permitted by the allowlist in order to retrieve the
      address or addresses for distributed recovery.
  </p>
  <p>
   In the allowlist, you can specify any combination of the
      following:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      IPv4 addresses (for example,
      <code class="literal">
       198.51.100.44
      </code>
      )
     </p>
    </li>
    <li class="listitem">
     <p>
      IPv4 addresses with CIDR notation (for example,
      <code class="literal">
       192.0.2.21/24
      </code>
      )
     </p>
    </li>
    <li class="listitem">
     <p>
      IPv6 addresses (for example,
      <code class="literal">
       2001:db8:85a3:8d3:1319:8a2e:370:7348
      </code>
      )
     </p>
    </li>
    <li class="listitem">
     <p>
      IPv6 addresses with CIDR notation (for example,
      <code class="literal">
       2001:db8:85a3:8d3::/64
      </code>
      )
     </p>
    </li>
    <li class="listitem">
     <p>
      Host names (for example,
      <code class="literal">
       example.org
      </code>
      )
     </p>
    </li>
    <li class="listitem">
     <p>
      Host names with CIDR notation (for example,
      <code class="literal">
       www.example.com/24
      </code>
      )
     </p>
    </li>
   </ul>
  </div>
  <p>
   Host names can resolve to IPv4 addresses, IPv6 addresses, or both.
      If a host name resolves to both an IPv4 and an IPv6 address, the
      IPv4 address is always used for Group Replication connections. You
      can use CIDR notation in combination with host names or IP
      addresses to permit a block of IP addresses with a particular
      network prefix, but do ensure that all the IP addresses in the
      specified subnet are under your control.
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    When a connection attempt from an IP address is refused because
        the address is not in the allowlist, the refusal message always
        prints the IP address in IPv6 format. IPv4 addresses are
        preceded by
    <code class="literal">
     ::ffff:
    </code>
    in this format (an
        IPV4-mapped IPv6 address). You do not need to use this format to
        specify IPv4 addresses in the allowlist; use the standard IPv4
        format for them.
   </p>
  </div>
  <p>
   A comma must separate each entry in the allowlist. For example:
  </p>
  <div class="copytoclipboard-wrapper">
   <pre class="programlisting one-line language-sql"><div class="docs-select-all right" id="sa74194974"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-sql"><span class="token prompt">mysql&gt;</span> <span class="token keyword">SET</span> <span class="token keyword">GLOBAL</span> group_replication_ip_allowlist<span class="token operator">=</span><span class="token string">"192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24"</span><span class="token punctuation">;</span></code></pre>
  </div>
  <p>
   To join a replication group, a server needs to be permitted on the
      seed member to which it makes the request to join the group.
      Typically, this would be the bootstrap member for the replication
      group, but it can be any of the servers listed by the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_group_seeds">
    <code class="literal">
     group_replication_group_seeds
    </code>
   </a>
   option in the configuration for the server joining the group. If
      any of the seed members for the group are listed in the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_group_seeds">
    <code class="literal">
     group_replication_group_seeds
    </code>
   </a>
   option with an IPv6 address when a joining member has an IPv4
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
    <code class="literal">
     group_replication_local_address
    </code>
   </a>
   ,
      or the reverse, you must also set up and permit an alternative
      address for the joining member for the protocol offered by the
      seed member (or a host name that resolves to an address for that
      protocol). This is because when a server joins a replication
      group, it must make the initial contact with the seed member using
      the protocol that the seed member advertises in the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_group_seeds">
    <code class="literal">
     group_replication_group_seeds
    </code>
   </a>
   option, whether that is IPv4 or IPv6. If a joining member does not
      have a permitted address for the appropriate protocol, its
      connection attempt is refused. For more information on managing
      mixed IPv4 and IPv6 replication groups, see
   <a class="xref" href="group-replication-ipv6.html" title="20.5.5 Support For IPv6 And For Mixed IPv6 And IPv4 Groups">
    Section 20.5.5, “Support For IPv6 And For Mixed IPv6 And IPv4 Groups”
   </a>
   .
  </p>
  <p>
   When a replication group is reconfigured (for example, when a new
      primary is elected or a member joins or leaves), the group members
      re-establish connections between themselves. If a group member is
      only permitted by servers that are no longer part of the
      replication group after the reconfiguration, it is unable to
      reconnect to the remaining servers in the replication group that
      do not permit it. To avoid this scenario entirely, specify the
      same allowlist for all servers that are members of the replication
      group.
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    It is possible to configure different allowlists on different
        group members according to your security requirements, for
        example, in order to keep different subnets separate. If you
        need to configure different allowlists to meet your security
        requirements, ensure that there is sufficient overlap between
        the allowlists in the replication group to maximize the
        possibility of servers being able to reconnect in the absence of
        their original seed member.
   </p>
  </div>
  <p>
   For host names, name resolution takes place only when a connection
      request is made by another server. A host name that cannot be
      resolved is not considered for allowlist validation, and a warning
      message is written to the error log. Forward-confirmed reverse DNS
      (FCrDNS) verification is carried out for resolved host names.
  </p>
  <div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Warning
   </div>
   <p>
    Host names are inherently less secure than IP addresses in an
        allowlist. FCrDNS verification provides a good level of
        protection, but can be compromised by certain types of attack.
        Specify host names in your allowlist only when strictly
        necessary, and ensure that all components used for name
        resolution, such as DNS servers, are maintained under your
        control. You can also implement name resolution locally using
        the hosts file, to avoid the use of external components.
   </p>
  </div>
 </div>
 <br/>
</div>
