Re: [v6ops] Same interface ID under several prefixes

[Brian E Carpenter <[e-mail]>]

On 10-Nov-22 23:13, Alexandre Petrescu wrote:
> 
> 
> Le 09/11/2022 à 21:59, Brian E Carpenter a écrit :
>> Looks like some progress in this area on Windows.
>>
>> Yesterday I applied the latest Windows 10 update, and noticed that my
>> very old IPv6 status checker was giving me an unexpected result.
>>
>> Why? Because as of yesterday, the stable IIDs for my GUA, ULA and LL
>> addresses are different. Kudos to MS.
>>
>> This is Windows 10 Pro, version 21H2, OS Build 19044.2251
>>
>> Can somebody check this on Windows 11?
> 
> I could check something on 22H2 Win10 (not Win 11), but not sure what to
> check more precisely, what commands to issue(?)

At the command prompt do:  ipconfig

The output will include something like this (slightly obfuscated):

Ethernet adapter Ethernet 4:

    Connection-specific DNS Suffix  . : fritz.box
    IPv6 Address. . . . . . . . . . . : 2406:e003:xxxx:xxxx:672e:17ef:b374:8c9d
    IPv6 Address. . . . . . . . . . . : fd63:45eb:dc14:0:6a25:e384:a462:54b9
    Link-local IPv6 Address . . . . . : fe80::8d0f:7f26:e5c8:780b%7
    IPv4 Address. . . . . . . . . . . : 192.168.178.20
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : fe80::2e3a:fdff:fea6:xxxx%7
                                        192.168.178.1

You see three different IIDs in my GUA, ULA and LLA addresses. I have
dsiabled temporary IPv6 addresses, but you might see them too. (And you
can see to its shame that my FritzBox still uses modified EUI-64.)

    Brian


> 
> I am on an IPv4-only network and there is an IID in the link-local
> address, and that IID is different than the MAC address.
> 
> I have not recorded that IID in earlier days, so I cant check whether
> something changed after windows updates.
> 
> And, I am not  even sure of the MAC address being something of the
> actual Ethernet interface, because the USB-Ethernet interface is Dell,
> the Ethernet-less computer is HP and the MAC address on Windows says it
> is of HP (first 2 bytes checked from the public oui.txt).
> 
> And, there is something in the BIOS which tries to have a unique MAC
> address for the Ethernet interface despite connecting various external
> USB-Ethernet interfaces with their various MAC addresses.
> 
> This (MAC address from BIOS) stable identifier is very necessary, even
> though it does not appear in IPv6 addresses.
> 
> This stable id is used for some protection, even though it is known that
> it can be faked.
> 
> IPv6 is still considered to not give enough protection, compared to IPv4.
> 
> Alex
> 
>>
>> Regards
>>      Brian
>>
>> On 23-Jun-22 08:46, Fernando Gont wrote:
>>> Hi, Brian,
>>>
>>> MacOS and OpenBSD also implement RFC7217/RFC8064.
>>>
>>> For embedded devices (e.g. printers), they are probably based on older
>>> versions of the Linux kernel, and probably RFC7217 has not (and will
>>> not) be back-ported to them -- so it'll take time for these devices to
>>> adopt RFC7217.
>>>
>>> As for Android, there might be a similar issue going on -- but certainly
>>> Lorenzo or Erik will be in a better position to tell.
>>>
>>> So my "concern" would probably be just the lack of support in Windows.
>>>
>>> P.S.: When it comes to Linux, it's more than just the kernel -- e.g.
>>> there's an implementation in dhcpcd (that's what you probably see in
>>> Raspberry Pi), and an implementation in NetworkManager (and there might
>>> be one in systemd-networkd).
>>>
>>> Thanks,
>>> Fernando
>>>
>>>
>>>
>>>
>>> On 21/6/22 19:56, Brian E Carpenter wrote:
>>>> Hi,
>>>>
>>>> I've done a little survey on my home network, and I don't find the
>>>> results
>>>> very encouraging for RFC7217/RFC8064 deployment. In summary, there is
>>>> some usage of pseudorandom IDs, but only Linux deserves a gold star
>>>> (the PI is also Linux):
>>>>
>>>> Linux 5.4.0   - 3 different IIDs for GUA, ULA, LLA
>>>> Raspberry PI  - 3 different IIDs for GUA, ULA, LLA
>>>> Android 7     - same IID for GUA, ULA; different for LLA (EUI64)
>>>> Android 11    - same IID for GUA, ULA; different for LLA (EUI64)
>>>> Windows 10*   - same IID for GUA, ULA, LLA
>>>> FritzBox 7530 - same IID for GUA, ULA, LLA (EUI64)
>>>> Samsung TV s6 - same IID for GUA, LLA (EUI64, but also temporary IID for
>>>> GUA & ULA)
>>>> Chromecast 2  - LLA only (EUI64)
>>>> Canon TS5100  - LLA only (EUI64)
>>>>
>>>> * with temporary addresses switched off
>>>>
>>>> Regards
>>>>       Brian Carpenter
>>>>
>>>> On 18-Jun-22 10:20, Fernando Gont wrote:
>>>>> On 17/6/22 17:51, Brian E Carpenter wrote:
>>>>> [...]
>>>>>>>
>>>>>>> I assume they don't claim to implement RFC7217. -- If they did, then
>>>>>>> yes, it would be fair to call that a bug. :-)
>>>>>>
>>>>>> Right, it would be fairer to call it a potential privacy vulnerability
>>>>>> (discover one address, get another one free of charge).
>>>>>
>>>>> Indeed, their mechanism allows for host-tracking: i.e., once you know
>>>>> the token, you can predict what's the address that that node would
>>>>> configured if it connected to a given network.
>>>>>
>>>>>
>>>>>> I don't regard
>>>>>> it as a very serious problem that an outsider can learn my ULA or
>>>>>> LLA.
>>>>>
>>>>> The biggest problem is that once the attacker learns your token, e.g.,
>>>>> he can test whether you're connected to e.g. the IETF conference
>>>>> network
>>>>> by e.g. pinging PREFIX::your_token.
>>>>>
>>>>>
>>>>>
>>>>>> Kudos to MS, anyway, for having moved to pseudo-random IIDs very
>>>>>> early,
>>>>>> before RFC7217 in fact.
>>>>>
>>>>> Yes, that was the point I was trying to make!
>>>>>
>>>>> Thanks,
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops