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

Douglas Bagnall douglas.bagnall at catalyst.net.nz
Tue Nov 3 21:55:47 UTC 2015


hi Jeff,

Aha. So it just follows RFC 5952? -- with the caveat that case
transformations are irrelevant. The documentation should perhaps mention
that.

Today my testing suggests that "::/48" is accepted, and I am not sure
what circumstances led me to think it wasn't.

thanks for your help,
Douglas

On 31/10/15 11:50, Jeff McCashland wrote:
> Hi Doug,
> 
> My research indicates the IPv6 address must be in the most efficient format so that no two strings can refer to the same subnet. While the initial prefix fields may be 0, there can be no 'leading zeros' (ie: extra zeroes to pad out the field). This applies to each of the 8 fields in the address. 
> 
> Example:
> "0:0:FF00:DA0::/120" is acceptable, "0000:0000:FF00:0DA0::/120" is not.
> 
> While the initial zeros are in the front of the string, they are not 'leading zeroes' in this context.
> 
> Also, the rule disallowing prefixes that match their mask is only for IPv4. IPv6 allows a prefix of all 1's. 
> Example: "FFFF:FFFF:F000::/36"
> 
> I'm still looking into the question of the unspecified address "::/n". I haven't been able to determine if and/or when it is allowed.
> 
> 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: Thursday, October 29, 2015 10:12 PM
> To: Jeff McCashland <jeffm at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
> Subject: Re: 115102913315679 [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range
> 
> thanks Jeff,
> 
> After a bit more testing, I have revised my questions.
> 
> I wrote:
> 
>> According to that document (and a small amount of testing against 
>> Windows 2012), a subnet IP range can't start with a leading zero.
>> But with IPv6 it is possible create subnets with implicit leading 
>> zeros. For example, "::ff00/120" and "0::ff00/120" refer to the same 
>> address range, but only the latter is forbidden. (right?)
> 
> Here, it seems "0::ff00/120" fails on Windows2012r2 because it doesn't like inefficient IPv6 zero packing. In short, you can't have "0::" or "::0" in your address. Or is there something more subtle?
> 
> MS-ADTS says "[the IP address string] does not have any leading zeros"
> which turns out not to mean zeros at the beginning of the string but zeros at the beginning of each number. That is, subnets like these are
> forbidden:
> 
>             000a:bbbb::/32
>             https://na01.safelinks.protection.outlook.com/?url=3.01.2.0%2f24&data=01%7c01%7cjeffm%40microsoft.com%7c8722fe6d3f844c3657ed08d2e0e89df1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BLqk%2b3ywuAzvGAWx8eK7FOPfCjh3TZoOW1Ixsbg2cMw%3d
>             https://na01.safelinks.protection.outlook.com/?url=3.1.2.00%2f24&data=01%7c01%7cjeffm%40microsoft.com%7c8722fe6d3f844c3657ed08d2e0e89df1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0zJ%2bN1A2Xa0lZQ3npWrbcArGHZzkWHjLB%2fCYePZsQz8%3d
>             https://na01.safelinks.protection.outlook.com/?url=22.001.0.0%2f16&data=01%7c01%7cjeffm%40microsoft.com%7c8722fe6d3f844c3657ed08d2e0e89df1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2b58ORypUD7nm8KMxHyBXlPNlV7RzgJfCYcrAiv8upYw%3d
>             https://na01.safelinks.protection.outlook.com/?url=3.01.02.0%2f24&data=01%7c01%7cjeffm%40microsoft.com%7c8722fe6d3f844c3657ed08d2e0e89df1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tgbQuGOItqeah4IS5BS9EgD64m%2fX7rWatFDY7ySu%2f38%3d
>             100a:0bbb:0023::/48
>             100a::0023/128
> 
> though MS-ADTS doesn't really say that, referring instead to leading zeros of the string as a whole. Is that right?
> 
> Also unmentioned is that no form of zero address seems to be acceptable to Windows 2012r2. Things like this are rejected:
> 
>             https://na01.safelinks.protection.outlook.com/?url=0.0.0.0%2f8&data=01%7c01%7cjeffm%40microsoft.com%7c8722fe6d3f844c3657ed08d2e0e89df1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hAEPRkFDIgUBVWPHha59LBhIMBj1wfn5HpvTajn8kyY%3d
>             0:0:0:0:0:0:0:0/8
>             ::/48
>             ::/0
> 
>> Can I thus infer that no attempt is made to canonicalise an IPv6 subnet 
>> name, and collisions are only avoided by DN uniqueness? That is, could 
>> I simultaneously have subnets called "2001:DA8::/48" and 
>> "2001:DA8:0::/48" which evaluate to the same address range?
> 
> I now understand from the first point above that the address "2001:DA8:0::/48" would be rejected, but "2001:DA8:0:0:0:0:0:0/48"
> would not be. Is that right?
> 
> cheers,
> Douglas
> 
> On 30/10/15 05:24, Jeff McCashland wrote:
>> Thank you Sree! [Sreekanth to BCC]
>>
>> Hi Douglas,
>>
>> My name is Jeff, and I would like to work with you on this issue. 
>>
>> I will research the question, and let you know as soon as I have more information.
>>
>> 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: 
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsuppor
>> t.microsoft.com%2fglobalenglish&data=01%7c01%7cjeffm%40microsoft.com%7
>> c8722fe6d3f844c3657ed08d2e0e89df1%7c72f988bf86f141af91ab2d7cd011db47%7
>> c1&sdata=kB9CKGEq6GgG22uETNUJM25cjjxTIQmrzxpq6GkV1Tg%3d | Extension 
>> 1138300 We value your feedback.  My manager is Nam Su Kang (nkang), +1 
>> (980) 776-7499
>>
>> -----Original Message-----
>> From: Sreekanth Nadendla
>> Sent: Wednesday, October 28, 2015 5:22 PM
>> To: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
>> <casemail at microsoft.com>
>> Subject: 115102913315679 [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address 
>> range
>>
>> Dochelp in Bcc
>> Casemail in Cc
>>
>> Hello Douglas,
>> Thank you for your inquiry about MS-ADTS specification. We have created incident 115102913315679 for investigating this issue. One of the Open specifications team member will contact you shortly.
>>  
>> Regards,
>> Sreekanth Nadendla
>> Microsoft Windows Open specifications
>>
>> -----Original Message-----
>> From: Douglas Bagnall [mailto:douglas.bagnall at catalyst.net.nz]
>> Sent: Wednesday, October 28, 2015 5:48 PM
>> To: Interoperability Documentation Help
>> Cc: cifs-protocol at lists.samba.org
>> Subject: MS-ADTS 6.1.1.2.2.2.1 Subnet Object address range
>>
>> hi dochelp,
>>
>> I just wish to clarify my interpretation of MS-ADTS 6.1.1.2.2.2.1 (v20150630).
>>
>> According to that document (and a small amount of testing against Windows 2012), a subnet IP range can't start with a leading zero. But with IPv6 it is possible create subnets with implicit leading zeros.
>> For example, "::ff00/120" and "0::ff00/120" refer to the same address 
>> range, but only the latter is forbidden. (right?)
>>
>> Can I thus infer that no attempt is made to canonicalise an IPv6 subnet name, and collisions are only avoided by DN uniqueness? That is, could I simultaneously have subnets called "2001:DA8::/48" and "2001:DA8:0::/48" which evaluate to the same address range?
>>
>> Also (as I understand point 6) it says the address part of an IPv4 CIDR can't exactly equal the implied mask. For example, "https://na01.safelinks.protection.outlook.com/?url=255.128.0.0%2f9&data=01%7c01%7cjeffm%40microsoft.com%7c8722fe6d3f844c3657ed08d2e0e89df1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sd9IgWL3sqxOIjoOAsNCwzg0PaTEbVDikz%2fNT%2fdj%2fUE%3d" is not allowed because the "/9" implies a mask of "255.128.0.0". Just for clarity can you confirm that there is no analogous constraint on IPv6?
>>
>> thanks
>>
>> Douglas
>>
> 




More information about the cifs-protocol mailing list