Adrien Grand commented on LUCENE-7920:

I think there are multiple ways that we could address the problem:
 1. Reject prefix queries on ipv6-mapped ipv4 addresses since they introduce a 
corner case. However we can't do it in Lucene since the ip address is already 
parsed, so we cannot distinguish ipv4 addresses from ipv6-mapped ipv4 
addresses, so we have to assume that applications take care of this special 
 2. Add a new method to query the binary representation of ip addresses 
directly (what the patch does for now, your suggestions would make it better).
 3. Change all methods to take a String instead of an InetAddress object as an 
ip address. This way we could know whether the prefix length assumes a length 
of 32 or 128 bits.

Something I like about 3 is that it moves some complexity from the user end to 
our end: even with option 2 users may still use the InetAddress-based prefix 
query factory method without knowing about its potential corner cases. I'm 
wondering what you think about it?

> Make it easier to create ip prefix queries
> ------------------------------------------
>                 Key: LUCENE-7920
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7920
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Adrien Grand
>            Priority: Minor
>         Attachments: LUCENE-7920.patch
> {{InetAddress.getByAddress}} automatically transforms ipv6-mapped ipv4 
> addresses to ipv4 addresses. While this is usually desirable, it can make ip 
> prefix query a bit trappy. For instance the following code:
> {code}
> InetAddressPoint.newPrefixQuery("a", InetAddress.getByName("::ffff:0:0"), 96);
> {code}
> throws an IAE complaining that the prefix length is invalid: {{illegal 
> prefixLength '96'. Must be 0-32 for IPv4 ranges, 0-128 for IPv6 ranges}}.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to