[cifs-protocol] [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range [REG:116011913603795]
Jeff McCashland
jeffm at microsoft.com
Tue Jan 26 17:50:27 UTC 2016
Hi Douglas,
That is fine, I think the confusion is mainly mine.
The dot . in the IPv4-mapped address was a typo on my part. I meant "::FFFF:0:0/nn". I'll double-check to see if I made the same entry error with the tools.
As I understand now, you're able to create subnets using other IPv4-Mapped addresses in addition to "::FFFF:0:0/nn"?
I will look into LDAP and see what I can find.
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: Monday, January 25, 2016 9:39 PM
To: Jeff McCashland <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
Subject: Re: [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range [REG:116011913603795]
hi Jeff,
Sorry for the confusion, which is all my fault. I got mixed up.
> I have a couple of quick questions just to make sure we're on the same page:
> 1) Are we still talking about allowed Subnet Prefixes, as opposed IPv6 addresses in general?
I have only been looking at subnets.
> 2) When you 'Windows disallows', what means (steps) are you using to validate these?
I have been creating subnets over LDAP.
Until today I thought I had a test that failed to create subnets like "::ffff:1.2.3.0/128", but no, it seems I hallucinated that. Sorry.
> I had been using the AD New Subnet tool, and also DHCP New Scope Wizard. Neither appear to accept ::FFFF:0.0/nn as a prefix. It may be that they expect the high-order bits to be non-zero.
I had "::FFFF:0:0/nn", all colons, not"::FFFF:0.0/nn".
thanks for your help,
Douglas
> 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
> c4d80987450b84d6361e308d32612f456%7c72f988bf86f141af91ab2d7cd011db47%7
> c1&sdata=lHBTVXYOW8%2f%2fPN4PkMDXd8NiK9LDYUxMG85SYuLjbek%3d |
> Extension 1138300 We value your feedback. My manager is Nam Su Kang
> (nkang), +1 (980) 776-7499
>
> -----Original Message-----
> From: Jeff McCashland
> Sent: Thursday, January 21, 2016 3:39 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: RE: [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range
> [REG:116011913603795]
>
> Hi Douglas,
>
> RFC 4291 section 2.5.5 mentions that IPv4-Compatible addresses are deprecated:
> The "IPv4-Compatible IPv6 address" is now deprecated because the
> current IPv6 transition mechanisms no longer use these addresses.
> New or updated implementations are not required to support this
> address type.
>
> I'll look further at the question of using the IPv4-Mapped address range in subnet addressing.
>
> Best regards,
> Jeff McCashland
> -----Original Message-----
> From: Douglas Bagnall [mailto:douglas.bagnall at catalyst.net.nz]
> Sent: Thursday, January 21, 2016 1:36 PM
> To: Jeff McCashland <jeffm at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email
> <casemail at microsoft.com>
> Subject: Re: [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range
> [REG:116011913603795]
>
> On 22/01/16 09:06, Jeff McCashland wrote:
>> Hi Douglas,
>>
>> Are you saying that specifically for subnet addressing, Windows
>> disallows all IPv4-Compatible (::x.x.x.x, deprecated), and
>> IPv4-Mapped
>> (::FFFF:x.x.x.x) addresses except "::FFFF:0.0.0.0", which can be used
>> as a subnet prefix? Does it only allow "::FFFF:0.0.0.0/96" (all
>> IPv4-mapped addresses), or other lengths of prefix as well?
>
> Not quite. I am saying that Windows disallows addresses in the form "::ffff:x:y", for any value of "x:y" except "0:0". The "::x:y"
> addresses behave the same, though of course the zero case looks like
> "::", not "::0:0". These are not addresses with dots -- they are pure
> IPv6 addresses that wander into dangerous territory.
>
> It is as if Windows is round-tripping the address through Vixie's
> inet_pton() and inet_ntop() and comparing the strings to determine validity, but making a special case for the all zeros cases.
>
>> Where in our doc do you see this as a conflict?
>
> This restriction on allowed IPv6 addresses is undocumented.
>
> cheers,
> Douglas
>
>
>> 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%2fsuppo
>> r
>> t.microsoft.com%2fglobalenglish&data=01%7c01%7cjeffm%40microsoft.com%
>> 7
>> c7355d87c31ad433175a608d322aaea4d%7c72f988bf86f141af91ab2d7cd011db47%
>> 7 c1&sdata=Ar9EsXp86U5yHetOdwjchHrUyoY%2bJQAc0Quf%2bOWWJaE%3d |
>> Extension 1138300 We value your feedback. My manager is Nam Su Kang
>> (nkang), +1 (980) 776-7499
>>
>> -----Original Message-----
>> From: Jeff McCashland
>> Sent: Tuesday, January 19, 2016 3:05 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: RE: [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range
>> [REG:116011913603795]
>>
>> Thanks Tom! [Tom to BCC]
>>
>> Hi Douglas,
>>
>> I will look into the Subnet address issue and let you know what I find.
>>
>> 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%2fsuppo
>> r
>> t.microsoft.com%2fglobalenglish&data=01%7c01%7cjeffm%40microsoft.com%
>> 7
>> c7355d87c31ad433175a608d322aaea4d%7c72f988bf86f141af91ab2d7cd011db47%
>> 7 c1&sdata=Ar9EsXp86U5yHetOdwjchHrUyoY%2bJQAc0Quf%2bOWWJaE%3d |
>> Extension 1138300 We value your feedback. My manager is Nam Su Kang
>> (nkang), +1 (980) 776-7499
>>
>>
>> -----Original Message-----
>> From: Tom Jebo
>> Sent: Tuesday, January 19, 2016 1:55 PM
>> To: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email
>> <casemail at microsoft.com>; Jeff McCashland <jeffm at microsoft.com>
>> Subject: RE: [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object address range
>> [REG:116011913603795]
>>
>> [dochelp to bcc]
>> [casemail cc]
>> [subject changed for case #]
>>
>> Hi Douglas,
>>
>> Thank you for your question about [MS-ADTS] address formats. Jeff will begin working with you on this. I've created case 116011913603795 and added the number to the subject of this email. Please refer to this new number in future communications regarding this issue.
>>
>> Best regards,
>> Tom Jebo
>> Sr Escalation Engineer
>> Microsoft Open Specfications
>>
>> -----Original Message-----
>> From: Douglas Bagnall [mailto:douglas.bagnall at catalyst.net.nz]
>> Sent: Tuesday, January 19, 2016 1:25 PM
>> To: Jeff McCashland <jeffm at microsoft.com>
>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email
>> <casemail at microsoft.com>; Interoperability Documentation Help
>> <dochelp at microsoft.com>
>> Subject: Re: 115102913315679 [MS-ADTS] 6.1.1.2.2.2.1 Subnet Object
>> address range
>>
>> [resending because I missed dochelp in the CCs. Sorry everyone else.]
>>
>> 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:
>>> § https://na01.safelinks.protection.outlook.com/?url=10.2.1.0%2f24&data=01%7c01%7cjeffm%40microsoft.com%7c7355d87c31ad433175a608d322aaea4d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AGBb12z2xumVk7RfURc3lMkqaX%2bK3vtP7KskZJWuO2U%3d
>>> § https://na01.safelinks.protection.outlook.com/?url=10.20.1.0%2f24&data=01%7c01%7cjeffm%40microsoft.com%7c7355d87c31ad433175a608d322aaea4d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=h%2bLuqxoJLg27NtTfpBcup8kUxRB12ShB35aQ0mYWxlc%3d
>>> Invalid IPV4 subnet names:
>>> § https://na01.safelinks.protection.outlook.com/?url=10.02.0.0%2f16&data=01%7c01%7cjeffm%40microsoft.com%7c7355d87c31ad433175a608d322aaea4d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=oq1ije5WKZlHPF%2bIwxrr9pzf6CmD5BdThQfwG43ZsCk%3d
>>> 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:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsupp
>>> o
>>> rt.microsoft.com%2fglobalenglish&data=01%7c01%7cjeffm%40microsoft.co
>>> m
>>> %7c7355d87c31ad433175a608d322aaea4d%7c72f988bf86f141af91ab2d7cd011db
>>> 4 7%7c1&sdata=Ar9EsXp86U5yHetOdwjchHrUyoY%2bJQAc0Quf%2bOWWJaE%3d |
>>> 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:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsupp
>>> o
>>> rt.microsoft.com%2fglobalenglish&data=01%7c01%7cjeffm%40microsoft.co
>>> m
>>> %7c7355d87c31ad433175a608d322aaea4d%7c72f988bf86f141af91ab2d7cd011db
>>> 4 7%7c1&sdata=Ar9EsXp86U5yHetOdwjchHrUyoY%2bJQAc0Quf%2bOWWJaE%3d |
>>> 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
>>>
>>
>
More information about the cifs-protocol
mailing list