P3
Hi,
This is a bug report related to the issue tracked under JDK-8277608 in July 2022 (https://github.com/openjdk/jdk/commit/243c76f). The fix was intended to filter out ambiguous addresses, while allowing the old behavior in "ambiguous" mode, with -Djdk.net.allowAmbiguousIPAddressLiterals=true setting, when BSD-parsable literals are passed to the OS resolver.
OpenJDK handles ipv4 address literals in accordance with IETF formatting described in RFC 1123 section 2.1 "Host Names and Numbers". A majority of standard network utilities and web browsers follow BSD parsing rules. The ambiguity arises from addresses that can be interpreted differently in different systems.
Address segments with a leading zero are parsed as octal numbers in the BSD interpretation. IETF interpretation requires to parse them as decimal as in "dotted-decimal". This makes segments 0..07 unambiguous as the numeric value is the same when such a string is interpreted as either octal or decimal. All other segments with a leading zero are ambiguous as their numeric value will be different.
Addresses with segments that look like an octal number because of the leading zero, but contain a digit that is not an octal digit (8 or 9), are considered broken and rejected in BSD standard (example, https://chromium.googlesource.com/chromium/src/+/HEAD/url/url_canon_ip.cc#96).
The following test-reproducer covers the number of cases when an ambiguous address is successfully parsed by InetAddress.getByName() without throwing an exception.
------------------
Please see the attached test.
------------------
OpenJDK must reject ambiguous addresses in IPAddressUtil.textToNumericFormatV4() by returning "null".
OpenJDK must not parse ambiguous addresses successfully, treating octal numbers as decimals.
UPDATED:
This issue was converted to an enhancement from a bug report. The above description has only the historical value. The actual enhancement description is as follows.
There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX inet_addr allowing octal and hexadecimal forms [2]). Java could accept literal addresses in both notations when it's explicitly specified which form to use, for the purpose of interoperability with external tooling that supports the "loose" syntax.
At present time it's impossible in Java to constuct an InetAddress object from a literal address in POSIX (inet_addr) "loose" notation. The existing factory method .ofLireral() [3] either rejects such literals (hexadecimal, octals > 0255) or accepts without regard to the octal prefix.
It is suggested to add a new factory method .ofPosixLiteral() to Inet4Address class that accepts IPv4 literal addresses in POSIX notation. Please refer to the linked PR.
[1] https://www.ietf.org/rfc/rfc6943.html#section-3.1.1
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
[3] https://bugs.openjdk.org/browse/JDK-8272215
This is a bug report related to the issue tracked under JDK-8277608 in July 2022 (https://github.com/openjdk/jdk/commit/243c76f). The fix was intended to filter out ambiguous addresses, while allowing the old behavior in "ambiguous" mode, with -Djdk.net.allowAmbiguousIPAddressLiterals=true setting, when BSD-parsable literals are passed to the OS resolver.
OpenJDK handles ipv4 address literals in accordance with IETF formatting described in RFC 1123 section 2.1 "Host Names and Numbers". A majority of standard network utilities and web browsers follow BSD parsing rules. The ambiguity arises from addresses that can be interpreted differently in different systems.
Address segments with a leading zero are parsed as octal numbers in the BSD interpretation. IETF interpretation requires to parse them as decimal as in "dotted-decimal". This makes segments 0..07 unambiguous as the numeric value is the same when such a string is interpreted as either octal or decimal. All other segments with a leading zero are ambiguous as their numeric value will be different.
Addresses with segments that look like an octal number because of the leading zero, but contain a digit that is not an octal digit (8 or 9), are considered broken and rejected in BSD standard (example, https://chromium.googlesource.com/chromium/src/+/HEAD/url/url_canon_ip.cc#96).
The following test-reproducer covers the number of cases when an ambiguous address is successfully parsed by InetAddress.getByName() without throwing an exception.
------------------
Please see the attached test.
------------------
OpenJDK must reject ambiguous addresses in IPAddressUtil.textToNumericFormatV4() by returning "null".
OpenJDK must not parse ambiguous addresses successfully, treating octal numbers as decimals.
UPDATED:
This issue was converted to an enhancement from a bug report. The above description has only the historical value. The actual enhancement description is as follows.
There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX inet_addr allowing octal and hexadecimal forms [2]). Java could accept literal addresses in both notations when it's explicitly specified which form to use, for the purpose of interoperability with external tooling that supports the "loose" syntax.
At present time it's impossible in Java to constuct an InetAddress object from a literal address in POSIX (inet_addr) "loose" notation. The existing factory method .ofLireral() [3] either rejects such literals (hexadecimal, octals > 0255) or accepts without regard to the octal prefix.
It is suggested to add a new factory method .ofPosixLiteral() to Inet4Address class that accepts IPv4 literal addresses in POSIX notation. Please refer to the linked PR.
[1] https://www.ietf.org/rfc/rfc6943.html#section-3.1.1
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
[3] https://bugs.openjdk.org/browse/JDK-8272215
- csr for
-
JDK-8329876 InetAddress: constructing objects from BSD literal addresses
-
- Closed
-
