Bug 1149612

Summary:	User is able to use any-ipv6-address interface on IPv4 environment
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Petr Kremensky <pkremens>
Component:	Domain Management, IPv6 support	Assignee:	Brian Stansberry <brian.stansberry>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Kremensky <pkremens>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.4.0	CC:	dandread, jkudrnac, kkhan
Target Milestone:	DR6
Target Release:	EAP 6.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	In previous versions of JBoss EAP 6, the logic for checking for, and rejecting, the combination of an `any-ipv6-address` configuration for an interface and the `java.net.preferIPv4Stack=true` system property was done when installing the network interface service rather than waiting until the service was starting. As a result, the check could run on host controller processes that did not need the interface service, resulting in spurious failures if the server process that would actually use the interface configuration did not have `java.net.preferIPv4Stack=true` set. In this release, the consistency check is been deferred until the interface service is started, ensuring it only occurs if the service is actually in use on that process. Now a server that does not have `java.net.preferIPv4Stack=true` set can use `any-ipv6-address` in the configuration of one of its interfaces even if the domain controller or its own host controller does have `java.net.preferIPv4Stack=true` set.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-19 12:42:22 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 Petr Kremensky 2014-10-06 08:47:35 UTC

Description of problem:
BZ900315 tighten up the interface creation procedure. User cannot create any new interface with any-ipv6-address=true if java.net.preferIPv4Stack is set to true now, but he is still able to configure existing interfaces with this property. 

We also found a few use cases where this fix is too strict. We should allow user to create this interface, but fail the operations which tries to make it actually do some work.

Version-Release number of selected component (if applicable):
 EAP 6.4.0.DR3

How reproducible:
 Always

Steps to Reproduce:
 1. start OOB standalone and connect to CLI

Actual results:
CASE1:
 /interface=myIPv6:add(any-ipv6-address=true) 
 "outcome" => "failed"
 /socket-binding-group=standard-sockets:write-attribute(name=default-interface, value=myIPv6)
 ... we don't make this far
CASE2:
 /interface=public:undefine-attribute(name=inet-address)
 "outcome" => "success"
 /interface=public:write-attribute(name=any-ipv6-address, value=true)
 "outcome" => "success"

 after reload we get the same bunch of errors as in BZ900315

Expected results:
CASE1:
 /interface=myIPv6:add(any-ipv6-address=true) 
 "outcome" => "success"
 /socket-binding-group=standard-sockets:write-attribute(name=default-interface, value=myIPv6)
 "outcome" => "failed"
CASE2:
 /interface=public:undefine-attribute(name=inet-address)
 "outcome" => "success"
 /interface=public:write-attribute(name=any-ipv6-address, value=true)
 "outcome" => "failed"

Comment 1 Brian Stansberry 2014-10-06 14:08:44 UTC

(In reply to Petr Kremensky from comment #0)

> 
> We also found a few use cases where this fix is too strict.

Please provide details.

Comment 2 Jakub Cechacek 2014-10-09 08:56:21 UTC

Use case I can think of is following:

User on dual stack machine wants to pre-configure an IPv6 interface before restarting the server and removing the java.net.preferIPv4Stack property.


However after investigating a bit further I believe that the fix introduced for BZ900315 is in fact not valid (and thus we don't even need to think about some use case) because:

1) it prevents user to set up *new and unused* interface with any-ipv6-address. Such setting is harmless -- thus there is no reason to prevent it. Additionally this can be set-up directly in XML config and server will start just fine. 

2) it still allows user to change the setting of *existing interface* (including the any-ipv6-address). This setting can lead to invalid configuration after server reload (e.g. setting any-ipv6-address for public interface).

To verify the second point execute this in CLI:

/interface=public:write-attribute(name=inet-address, value=undefined)
/interface=public:write-attribute(name=any-ipv6-address, value=true)
:reload

Now check the server log.

Comment 4 Petr Kremensky 2014-11-14 10:59:21 UTC

Verified on EAP 6.4.0.DR9