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

[Douglas Bagnall]

Jeff,

I discovered another quirk which might be worth mentioning.

Addresses in the form "::FFFF:x:x" or "::x:x", which would map to IPv4
addresses under some old schemes are forbidden. The inet_ntop()
function in the C standard library renders these as embedded dotted
decimal addresses (i.e. "::FFFF:x.x.x.x").

The exception is "::FFFF:0:0" which Windows allows. That would map to
"0.0.0.0" under the mapping scheme.

cheers,
Douglas

On 25/11/15 06:56, Jeff McCashland wrote:
> Hi Douglas,
> 
> Here is what we came up with:
> s is a valid subnet name if:
> 1. There is only one occurrence of the character "/" in s. Let i be the index of the character "/" in s.
> 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 or compressed form (as specified in [RFC 4291]), and must meet the following constraints:
> §	IPv4 addresses must not have any leading zeros in any individual component of the address
> §	IPv6 addresses must be in canonical text representation format (as specified in [RFC 5952] section 4), except that the addresses are treated as case insensitive.
> Examples:
> Valid IPV4 subnet names:
> §	10.2.1.0/24
> §	10.20.1.0/24
> Invalid IPV4 subnet names:
> §	10.02.0.0/16
> Valid IPv6 subnet names:
> 	A:A:A:A::/64
> §	a:b::c:d:0:0/64
> §	0:0:e0::/48
> §	A:b:C::/128
> §	A:B::F:0/128
> §	12AB:0:0:CD30::/60
> §	A:a:e:b:0:d:e:f/128
> Invalid IPv6 subnet names:
> §	A:B:0C:D::/64
> §	A:B:0:0:0:0:E:F/128
> §	12AB::CD30:0:0:0:0/60
> §	12AB:0:0:CD30::F:0/60
> §	A:a:e:b::d:e:f/128
> 
> 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: Jeff McCashland 
> Sent: Thursday, November 19, 2015 9:20 AM
> To: 'Douglas Bagnall' <douglas.bagnall at catalyst.net.nz>
> Cc: cifs-protocol at lists.samba.org
> Subject: RE: 115102913315679 [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range
> 
> 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
>