Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2229768

Summary:	Cannot enroll replica on IPv6 only host
Product:	Red Hat Enterprise Linux 9	Reporter:	Tomasz Kepczynski <tomek>
Component:	ipa	Assignee:	Florence Blanc-Renaud <frenaud>
Status:	CLOSED MIGRATED	QA Contact:	ipa-qe
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.2	CC:	abokovoy, rcritten, tscherf
Target Milestone:	rc	Keywords:	MigratedToJIRA
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-18 22:54:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tomasz Kepczynski 2023-08-07 15:37:46 UTC

Description of problem:
It is not possible to enroll ipa replica on IPv6 only ipa client.

Version-Release number of selected component (if applicable):
ipa-client-4.10.1-8.el9_2.x86_64
ipa-client-common-4.10.1-8.el9_2.noarch
ipa-common-4.10.1-8.el9_2.noarch
ipa-healthcheck-core-0.12-1.el9.noarch
ipa-selinux-4.10.1-8.el9_2.noarch
ipa-server-4.10.1-8.el9_2.x86_64
ipa-server-common-4.10.1-8.el9_2.noarch
ipa-server-dns-4.10.1-8.el9_2.noarch
ipa-server-trust-ad-4.10.1-8.el9_2.x86_64

How reproducible:
Always.

Steps to Reproduce:
filippa:~# ipa-replica-install \
>     --no-ui-redirect \
>     --no-ssh \
>     --no-sshd \
>     --unattended \
>     \
>     --setup-ca \
>     \
>     --setup-dns \
>     --no-forwarders \
>     --allow-zone-overlap \
>     --no-dns-sshfp \
>     --setup-adtrust
Connection to https://triss.jot23.net/ipa/json failed with Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credential cache is empty)
Lookup failed: Preferred host filippa.jot23.net does not provide DNS.
WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing samba configuration.


Run connection check to master
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Connection check failed!
See /var/log/ipareplica-conncheck.log for more information.
If the check results are not valid it can be skipped with --skip-conncheck parameter.
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

The excerpt from /var/log/ipareplica-install.log:

2023-08-07T15:15:30Z DEBUG args=['/usr/sbin/ipa-replica-conncheck', '--master', 'triss.jot23.net', '--auto-master-check', '--realm', 'IPA.JOT23.NET', '--hostname', 'filippa.jot23.net', '--ca-cert-file', '/etc/ipa/ca.crt']
2023-08-07T15:15:31Z DEBUG Process finished, return code=1
2023-08-07T15:15:31Z DEBUG stdout=
2023-08-07T15:15:31Z DEBUG stderr=Check connection from replica to remote master 'triss.jot23.net':
Failed to connect to port 389 tcp on 192.168.16.10
   Directory Service: Unsecure port (389): FAILED
Failed to connect to port 636 tcp on 192.168.16.10
   Directory Service: Secure port (636): FAILED
Failed to connect to port 88 tcp on 192.168.16.10
   Kerberos KDC: TCP (88): FAILED
Failed to connect to port 464 tcp on 192.168.16.10
   Kerberos Kpasswd: TCP (464): FAILED
Failed to connect to port 80 tcp on 192.168.16.10
   HTTP Server: Unsecure port (80): FAILED
Failed to connect to port 443 tcp on 192.168.16.10
   HTTP Server: Secure port (443): FAILED
ERROR: Port check failed! Inaccessible port(s): 389 (TCP), 636 (TCP), 88 (TCP), 464 (TCP), 80 (TCP), 443 (TCP)

The host is IPv6 only:

filippa:~# ifconfig 
enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:fea2:1097  prefixlen 64  scopeid 0x20<link>
        inet6 2a06:a005:1991:1100::20  prefixlen 64  scopeid 0x0<global>
        ether 52:54:00:a2:10:97  txqueuelen 1000  (Ethernet)
        RX packets 86772  bytes 69805321 (66.5 MiB)
        RX errors 0  dropped 34778  overruns 0  frame 0
        TX packets 33819  bytes 4954541 (4.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 46  bytes 2696 (2.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 46  bytes 2696 (2.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ipa-replica-conncheck is NOT compliant with RFC6724. See https://datatracker.ietf.org/doc/html/rfc6724#section-6 where Rule 1 clearly states: Avoid unusable destinations. The system in question has AAAA record which should have been used in the first place:
filippa:~# dig triss.jot23.net aaaa +short
2aXX:XXXX:XXXX:1000::10

Actual results:
Cannot enroll IPv6 only replica.

Expected results:
Can enroll IPv6 only replica.

Additional info:
It is possible to skip the check with --skip-conncheck option and proceed. It should not be needed though.
The system being enrolled is on RHEL 9.2. Other replicas are on AlmaLinux 9.2.

Comment 1 Alexander Bokovoy 2023-08-14 12:54:55 UTC

Notes:

We need to extend IPA installers to be smarter and recognize IPv6-only or IPv4-only setups. This means also taking into account gai.conf configuration (default one, when /etc/gai.conf does not exist, is to prefer IPv6 over IPv4).

When only IPv6 routing is available:
 - when detecting IPv6-only configuration, filter out link-local IPv6 routes as these will not lead to working IPv6 setup
 - filter out IPv4 hosts from the list of available replicas. Assume system resolver is taking gai.conf preferences.

When only IPv4 routing is available:
 - when detecting IPv4-only configuration, filter out link-local IPv6 routes as these will not lead to working IPv6 setup
 - filter out IPv6 hosts from the list of available replicas. Assume system resolver is already taking gai.conf preferences into account.

In both cases it should be done for both client and replica deployments. Additional consideration on the client side is to filter out IPv4 hosts from IPv6-only environment (and vice-versa) and issue a warning that hosts were dropped out. 

Perhaps, we would need to add a way to tune this through /etc/ipa/installer.conf to allow either behavior (drop/not drop) in order to avoid adding new command line options.

Comment 2 Tomasz Kepczynski 2023-08-15 14:26:40 UTC

The interesting part is that the installation from dual stack system against IPv6 only master works: the connection checker is able to resolve IPv6 only destination.

Please make sure to validate connection checking both ways. Connection checker seems to check connection from client to master first and then seems to ask the master to check the other way - this can be prone to same issue as described here.

Additionally I noted that CA enrolment at least sometimes fails when CA resolves to both IPv4 and IPv6 but is not reachable by IPv4 (RFC1918 involved at least on one side of the connection). But this likely is another issue (please let me know if I should look into it a bit more and file a bug if confirmed).

Comment 3 RHEL Program Management 2023-09-18 22:54:17 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 4 RHEL Program Management 2023-09-18 22:54:32 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.