Incorrect IPv6 link local address assigned to adapter

I'm working on an NDIS driver for a multi-adapter/port NIC. Things have been
working with the Windows network stack for IP, but problems start appearing
when IPv6 is installed/configured.

The first thing that I noticed was that the link-local IPv6 addresses are
incorrect for the adapters. Windows sets the address for each adapter to be
fe80::5445:5245:444f, the same address that is assigned to the Teredo
Tunneling Pseudo-Interface. The MAC address for the adapter shows up
correctly, but Windows is not generating the link-local address from this. Is
there something special that needs to be configured or done in the driver for
Windows to generate the link-local address correctly?

bburgin
Fri Nov 17 13:10:01 CST 2006

------=_NextPart_0001_30E3DE12
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

NDIS 5 or 6, just to be clear?

You only have control over the MAC address via your response to
OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
will be somewhere higher in the stack.

Bryan S. Burgin
bburgin@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.

------=_NextPart_0001_30E3DE12
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 NDIS 5 or 6, just to be clear?
\par
\par You only have control over the MAC address via your response to OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem will be somewhere higher in the stack.
\par
\par Bryan S. Burgin
\par bburgin@online.microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par }
------=_NextPart_0001_30E3DE12--

DZ
Fri Nov 17 15:03:01 CST 2006

The driver is NDIS 5.1.

Is it possible that the OUI of the MAC address is not recognized by the
stack and this is why a proper link local address is not created? I suppose
an easy way to test this out is just to change the OUI to something more
common to make sure it's not the OUI itself...

""Bryan S. Burgin [MSFT]"" wrote:

> NDIS 5 or 6, just to be clear?
>
> You only have control over the MAC address via your response to
> OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
> will be somewhere higher in the stack.
>
> Bryan S. Burgin
> bburgin@online.microsoft.com
>
> This posting is provided "AS IS" with no warranties, and confers no rights

DZ
Fri Nov 17 17:26:02 CST 2006

I found the issue, by chance. A query for an OID (0xff54554e to be exact)
returned success instead of not supported. After fixing this, the link local
address was correct.

Do you know what this OID is used for?

""Bryan S. Burgin [MSFT]"" wrote:

> NDIS 5 or 6, just to be clear?
>
> You only have control over the MAC address via your response to
> OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
> will be somewhere higher in the stack.
>
> Bryan S. Burgin
> bburgin@online.microsoft.com
>
> This posting is provided "AS IS" with no warranties, and confers no rights

bburgin
Fri Nov 17 18:41:50 CST 2006

------=_NextPart_0001_3213AAB7
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I looked through the WDK (build 6000/Vista RTM) for that value and anything
that started with OID_ and didn't find it, either. It strikes me odd that
it can also be viewed in ASCII as 'NUT\ff'. Returning NOT_SUPPORTED is the
right thing to do in this case. Perhaps setting a breakpoint when you
receive this and then dump the stack trace will lend some insight on who is
issuing this.

Bryan S. Burgin
bburgin@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_3213AAB7
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 I looked through the WDK (build 6000/Vista RTM) for that value and anything that started with OID_ and didn't find it, either. It strikes me odd that it can also be viewed in ASCII as 'NUT\\ff'. Returning NOT_SUPPORTED is the right thing to do in this case. Perhaps setting a breakpoint when you receive this and then dump the stack trace will lend some insight on who is issuing this.
\par
\par Bryan S. Burgin
\par bburgin@online.microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
------=_NextPart_0001_3213AAB7--

Pavel
Fri Nov 17 18:54:26 CST 2006

""Bryan S. Burgin [MSFT]"" <bburgin@online.microsoft.com> wrote in message news:FymJYpqCHHA.4372@TK2MSFTNGXA01.phx.gbl...
> It strikes me odd that
> it can also be viewed in ASCII as 'NUT\ff'.

May be, "TUN" ?

--PA

DZ
Fri Nov 17 21:05:02 CST 2006

Maybe it's wishful thinking, but TUN makes some sense in the context that
when the driver returned success for this OID, the adapter had the same link
local address as the Toredo tunneling adapter.

"Pavel A." wrote:

> ""Bryan S. Burgin [MSFT]"" <bburgin@online.microsoft.com> wrote in message news:FymJYpqCHHA.4372@TK2MSFTNGXA01.phx.gbl...
> > It strikes me odd that
> > it can also be viewed in ASCII as 'NUT\ff'.
>
> May be, "TUN" ?
>
> --PA
>
>
>

Thomas
Mon Nov 20 00:48:42 CST 2006

Aren't OIDs that begin with "0xFF" vendor-proprietary OIDs?

Thomas

"DW" <DZ@nospam.nospam> wrote in message
news:7660FEAE-E874-4C8D-A497-D30DF86FA432@microsoft.com...
>I found the issue, by chance. A query for an OID (0xff54554e to be exact)
> returned success instead of not supported. After fixing this, the link
> local
> address was correct.
>
> Do you know what this OID is used for?
>
> ""Bryan S. Burgin [MSFT]"" wrote:
>
>> NDIS 5 or 6, just to be clear?
>>
>> You only have control over the MAC address via your response to
>> OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
>> will be somewhere higher in the stack.
>>
>> Bryan S. Burgin
>> bburgin@online.microsoft.com
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights

Stephan
Wed Nov 22 15:02:22 CST 2006

Thomas F. Divine [MVP] wrote:
> Aren't OIDs that begin with "0xFF" vendor-proprietary OIDs?

Absolutely. And they are all optional by nature.

Stephan