Re: [v6ops] Same interface ID under several prefixes

[Alexandre Petrescu <[e-mail]>]

for completeness, per the original request of win11 outputs, I checked a 
win11 machine too, in addition to the 22H2 win10.

the win11 IPv4 and IPv6 address formats in the ipconfig output are 
similar to that of 22H2, there seem to be no difference.

Alex

Le 10/11/2022 à 21:41, Alexandre Petrescu a écrit :
> 
> 
> Le 10/11/2022 à 21:02, Brian E Carpenter a écrit :
>> 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.)
> 
> You see below my ipconfig on wifi on a win10 22H2 on a home network 
> which offers both IPv4 and IPv6.
> 
> Carte réseau sans fil Wi-Fi :
> 
>     Suffixe DNS propre à la connexion. . . :
>     Adresse IPv6. . . . . . . . . . . . . .: 2a01:e0a:937:bc30::ec18:fe76
>     Adresse IPv6 de liaison locale. . . . .: fe80::6f44:cfe8:261a:fbaf%3
>     Adresse IPv4. . . . . . . . . . . . . .: 192.168.0.5
>     Masque de sous-réseau. . . . . . . . . : 255.255.255.0
>     Passerelle par défaut. . . . . . . . . : fe80::160c:76ff:fe8c:86f3%3
>                                         192.168.0.254
> 
> I have not obfuscated anything because I suppose the system generates 
> new IIDs relatively often.
> 
> Remark the IID in the GUA seems to be 32 signficant bits.
> 
> Alex
> 
>>
>>     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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops