Guava: IPv6 address validation error.

[tiwarivikash]

InetAddresses.isInetAddress("fe80::8b2:d61e:e5c:b333%15") returns false for a valid IPv6 address. Does this method not support Link-Local IP address?

[vijaykcm]

Why does your string ends with "%15"? Is that a typo?

[tiwarivikash]

Number after '%' is scope id. Please see following link for more details -
http://superuser.com/a/99753

[vijaykcm]

I see. Thank you. I looked at the code and tests, and it looks like link-local addresses with zone indices are not supported.

[noahlz]

So they're not supported....could they be?

(Assuming I or someone issues a PR)

[tiwarivikash]

Is there a reason why it is not supported?

[kluever]

At the very least, we should document that the method does not support IPv6 addresses with scope IDs.

[carl-mastrangelo]

+1 ing this issue, It's affecting my code base as well. The move to IPv6 would be eased if Guava could support this, considering how widely used it is.

I'm happy to submit a patch to just ignore everything after the % if the Guava team is interested.

[kluever]

I don't think it's as simple as just "ignoring everything after the %". For instance, is 192.168.1.1%frobber%%%%turtle% a valid address?

A few clarifying questions:

1. Is there a specific format for scope IDs? The linked S/O answers seem to indicate that they can be numbers (e.g., 1 or 3) or characters and numbers (e.g., eth0).
2. Are scope IDs only valid on IPv6 addresses?
3. Should anything after the % just be dropped on the floor when parsing?

[carl-mastrangelo]

@kluever If dropping the % and parsing as a v6 address results in a valid address, I think that is sufficient. I don't see an ABNF grammar in a quick search to the RFCs, but I don't think that is a serious issue. As long as it matches the value that Inet6Address returns should be enough, which just appends it to the end. It should be a goal of InetAddresses to parse: InetAddresses.forString(inet6Address.getHostAddress())

[kluever]

@carl-mastrangelo Thanks - do you have any addresses you'd like me to explicitly include in the unit tests? I've got a patch ready.

[kluever]

@cpovirk pointed out the following references:

• https://tools.ietf.org/html/rfc6874#section-2
  
  
  
  • ZoneID = 1*( unreserved / pct-encoded )
  
  
• https://tools.ietf.org/html/rfc3986#section-2.3
  
  
  
  • unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
  
  
• https://tools.ietf.org/html/rfc3986#section-2.1
  
  
  
  • pct-encoded = "%" HEXDIG HEXDIG
  
  

[cpovirk]

Sorry, I should have read more: RFC 6874 specifically discusses how to format scope IDs _in the context of a URL_.

It does say: "A \

But this is only a SHOULD, not a MUST, and consequently it goes on to describe escaping schemes for cases in which this is not the case.

[cpovirk]

As for dropping the scope ID:

While we're not implementing a web browser here, RFC 6874 at least says:
"It would therefore be highly desirable for a browser to remove the ZoneID from a URI before including that URI in an HTTP request."

That's at least a small point in favor of dropping it.

As a practical matter, we almost have to: Java's Inet6Address permits only 2 kinds of scope IDs: numeric and NetworkInterface. NetworkInterface can seemingly be an arbitrary string -- but only if it corresponds to an actual interface on the machine running the code. (And we don't have access to provide our own implementation of InetAddress or NetworkInterface ourselves, even if we wanted to.)

[kluever]

See also the section at the bottom of the class docs for Inet6Address, _Textual representation of IPv6 scoped addresses_:

The general format for specifying the scope_id is the following:
IPv6-address%scope_id

[carl-mastrangelo]

@kluever Sure: 0:0:0:0:0:0:0:1%eno1 is what I get on my machine when parsing ::1 with a NetworkInterface.

As a practical matter, we almost have to: Java's Inet6Address permits only 2 kinds of scope IDs: numeric and NetworkInterface. NetworkInterface can seemingly be an arbitrary string -- but only if it corresponds to an actual interface on the machine running the code. (And we don't have access to provide our own implementation of InetAddress or NetworkInterface ourselves, even if we wanted to.)

Yup, ran into the same problem. For my own unit test I tested this by using Assume and iterating the NetworkInterfaces:

https://github.com/Netflix/zuul/blob/b9f517cd46426ddde470bf088acf8eba6b258c3c/zuul-core/src/test/java/com/netflix/netty/common/SourceAddressChannelHandlerTest.java#L86-L110

[kluever]

Thanks Carl - I added that address to my test cases and it passes.

Churning this change through all of the Google tests, but I can't imagine there will be much of an issue. Will get it sync'ed out after that.

[carl-mastrangelo]

@kluever & @cpovirk thanks for the fast turn around time! Looking forward to the next release.