fpoirotte/Erebot — Issue #20: Improve IPv4/v6 support in Erebot_Identity 
Author: fpoirotte
Created: 2011-11-06 20:37:52+00:00
State: open

Erebot_Identity::getHost() and Erebot_Identity::getMask() should support an additional parameter called $normalization.
This parameter can be used to hint the functions into returning a canonical form for the host. This is only useful for IPv6.

I think it should accept 3 values (defined as constants in the API) :
- CANON_NONE : does not try to canonicalize the host part (ie. it is returned as is).
- CANON_IPV6 : IPv6 addresses should be returned in a canonical format (numbers are "0"-padded on the left, "::" is expanded, etc.). IPv4-in-IPv6 addresses are returned with the IPv4 information converted into its IPv6 values.
- CANON_IPV4 : same as CANON_IPV6 except that IPv4-in-IPv6 addresses will be returned with the IPv4 information represented in dotted notation. The rest of the address (IPv6) information is canonicalized.

Erebot_Identity::match() should be updated to provide additional filtering capabilities:
* It should support notations such as "127.0.0.*" or "abcd::*" to match against IP addresses. The * wildcard should not cross dot/colon boundaries.
* It should also support network mask notations: "127.0.0.1/24" or "2001:41d0:2:37e4::1/64".
* It should also support IPv4-in-IPv6 addresses expressed in dotted notation ("0::ffff:127.0.0.*" or "0::ffff:127.0.0.1/24"). When used with a network mask, the network mask applies to the IPv6 part, not the IPv4 part. So "0::ffff:127.0.0.1/33" is valid. To make the network mask apply to the IPv4, a minus sign should be prepended to it ("0::ffff:127.0.0.1/-24"). In this case, a mask such as "0::ffff:127.0.0.1/-33" is invalid because it crosses the IPv4-IPv6 boundary. Also, please note that "0::ffff:127.0.0.1/-0" is interpreted as "ignore the IPv4 part completely" (meaning that any IPv4-in-IPv6 address will successfully match).