[cifs-protocol] 115102913315679 [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range

[Jeff McCashland]

Hi Douglas,

Good observations. Thank you for the feedback!

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
We value your feedback.  My manager is Nam Su Kang (nkang), +1 (980) 776-7499

-----Original Message-----
From: Douglas Bagnall [mailto:douglas.bagnall at catalyst.net.nz] 
Sent: Wednesday, November 18, 2015 5:31 PM
To: Jeff McCashland <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: Re: 115102913315679 [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range

hi Jeff,

> To follow up on this issue, how does this look?:
> 
> 2. The substring s[0, i-1] is either a valid IPv4 address in dotted decimal notation (as specified in [RFC1166]) or a valid IPv6 address in colon-hexadecimal form (as specified in [RFC2373]), and must meet the following additional constraints:  
> 	IPV4 addresses must not have any leading zeros in any individual component of the address.
> 	IPV6 addresses must not have any leading zeros in any individual component of the address.
> 	IPV6 addresses must be in compressed form (as specified in [RFC2373]) when possible; the compressed sequence must be the longest such possible.
> 	IPV6 addresses are treated as case insensitive

That is good, though the maximally compressed criteria doesn't quite specify a unique form (which I believe is the point). For example, the subnet that in uncompressed form looks like:

    1:0:0:2:3:0:0:4/128

can be compressed equally well in either of these two ways:

    1::2:3:0:0:4/128
    1:0:0:2:3::4/128

Windows 2012R2, as far as I can tell, mandates the first representation (as does RFC5952 section 4.2.3).

Also in RFC5952 section 4.2.2 says that single zeros should not be collapsed into "::" -- that is, it wants "2001:db8:0:1:1:1:1:1"
instead of "2001:db8::1:1:1:1:1". Windows 2012R2 also seems to follow this, which is strictly speaking a violation of the compression heuristic.

It looks as if Windows 2012 does in fact follow the RFC with the caveat of case insensitivity. But not 2008R2, which allows invalid subnet names like "a:b::/31", where the masked bits are not all zero (online tools differ on whether that would refer to the same range as "a:a::/31" or "a:b::/32", but either way its a duplicate).

thanks for your help,

Douglas