ip address datatype & matching function proposal

[Bill Parducci <bparducci@gluecode.com>]

i was pondering our ip address match function (looking for the best way 
to represent a range) and began wondering if we shouldn't qualify 
addresses as ipv4 or ipv6 when invoking this function. after spending 
two hours hashing through this it reinforces my belief that this is one 
of those things that *looks* easy, but is a tough nut to crack!

to begin, since the fundamental composition of ipv6 URLs (rfc2732) are 
significantly different than that for ipv4 URLs (rfc2396) i suggest that 
we first make a few changes to the spec:

1. remove datatype
    urn:oasis:names:tc:xacml:2.0:data-type:ipAddress

2. add datatype
    urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address
    For purposes of policy writing XACML IP addresses follow rfc2396: A
    four byte octet (32 bit) written as decimal values separated by ".".
    Example: 192.168.254.252.

3. add datatype
    urn:oasis:names:tc:xacml:2.0:data-type:ipv4AddressMask
    A four byte octet (32 bit) written as decimal values separated by "."
    used to define the boundary of an IP address range when applied to an
    urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address. Example:
    255.255.255.0 specifies as 24 bit subnet mask; when applied to an IP
    address such as 192.168.254.0 it refers to all IP addresses from
    192.168.254.0 through 192.168.254.254

4. add datatype
    urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address
    For purposes of policy writing XACML IP addresses follow rfc2732: A
    128 bit number written in hex, bracketed with "[]".
    Example: [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]

3. add datatype
    urn:oasis:names:tc:xacml:2.0:data-type:ipv6AddressMask
    A 128 bit number written in hex, separated by ":" and used to define
    the boundary of an IP address range when applied to an
    urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address. Example:
    ffff:ffff:ffff:ffff:0000:0000:0000:0000 specifies a 64 bit subnet
    mask; when applied to 3ffe:ffff:0100:f101:0210:a4ff:fee3:9566 defines
    a range from 3ffe:ffff:0100:f101:0000:0000:0000:0000 through
    ffe:ffff:0100:f101:ffff:ffff:ffff:ffff.

then we correct a problem with the current ip address matching function 
(it allows for a mask but provides no mechanism to pass it, nor does it 
provide port range syntax).

A. remove function
    urn:oasis:names:tc:xacml:2.0:function:ipAddress-match

B. create function
    urn:oasis:names:tc:xacml:2.0:function:ipv4Address-match

    This function SHALL take two arguments of data-type
    urn:oasis:names:tc:xacml:2.0:data-type:ipv4Address and one argument
    of datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv4AddressMask.
    Applying the ipv4AddressMask to the first ipv4Address argument
    specifies the set of addresses that are acceptable for the match to
    be "True".  The second ipv4Address argument specifies a particular
    address to be tested against the set of acceptable values.

    This function SHALL return "True" if, after each address and mask are
    converted to their byte sequence equivalents, a) the second
    ipv4Address argument falls within the address range defined by the
    application of the ipv4AddressMask to the first ipv4Address argument.
    Otherwise, this function SHALL return "False".


C. create function
    urn:oasis:names:tc:xacml:2.0:function:ipv6Address-match

    This function SHALL take two arguments of data-type
    urn:oasis:names:tc:xacml:2.0:data-type:ipv6Address and one argument
    of datatype urn:oasis:names:tc:xacml:2.0:data-type:ipv6AddressMask.
    Applying the ipv6AddressMask to the first ipv6Address argument
    specifies the set of addresses that are acceptable for the match to
    be "True".  The second ipv6Address argument specifies a particular
    address to be tested against the set of acceptable values.

    This function SHALL return "True" if, after each address and mask are
    converted to their byte sequence equivalents, a) the second
    ipv6Address argument falls within the address range defined by the
    application of the ipv6AddressMask to the first ipv6Address argument.
    Otherwise, this function SHALL return "False".

NOTES:

this solution requires that ALL ip address matching have a mask on the 
bounding address (a 32/128 bit mask for v4 and v6 respectively will 
yield a single address if desired).

port numbers are not part of the ip addressing matching function. in 
keeping with my proposal that uri matches are broken into two components 
(host & resource), and the port number being a subset of the 'resource' 
portion, it is matched using regex (with the rest of the resource 
notation). personally i think this is a lot easier than creating yet 
another datatype (ipPortrange or something) and adding yet another 
argument to the matching function.

anyway, this is what i came up with...

b