Re: RFC4941bis: consequences of many addresses for the network

[Gyan Mishra <[e-mail]>]

On Sat, Jan 25, 2020 at 3:05 PM Gyan Mishra <[e-mail]> wrote:

>
>
> On Fri, Jan 24, 2020 at 8:30 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> On 25-Jan-20 12:06, Gyan Mishra wrote:
>> >
>> > Microsoft link - forgot
>> >
>> > On Fri, Jan 24, 2020 at 6:05 PM Gyan Mishra <[e-mail]
>> <mailto:[e-mail]>> wrote:
>> >
>> >
>> >
>> >     On Fri, Jan 24, 2020 at 5:11 PM Brian E Carpenter <
>> [e-mail] <mailto:[e-mail]>> wrote:
>> >
>> >         >  I agree RFC 7217 stable address is most preferred however
>> Microsoft and Apple don’t support yet.
>> >
>> >
>> >       Gyan>On my IPv6 roadmap list with Microsoft.  So far no ETA.
>> >
>> >
>> >         I have no idea for Apple, but afaik MS switched to pseudorandom
>> stable IIDs per interface a long time ago, before Windows 7 possibly. I
>> haven't seen a modified EUI-64 address on my laptop for a very long time.
>> This is not the same thing as RFC7217 from a privacy point of view, but for
>> network operations and neighbour cache size it seems like the same thing.
>> >
>> >
>> >        Gyan> I think it’s EUI-64 and not modified.
>>
>> No. Here's what my Windows 10 says right now (WAN prefix etc obscured
>> manually). There are no EUI-64 or modified EUI-64 interface identifiers.
>>
>> Microsoft Windows [Version 10.0.17763.737]
>> (c) 2018 Microsoft Corporation. All rights reserved.
>>
>> C:\WINDOWS\system32>ipconfig /all
>>
>> Windows IP Configuration
>>
>>    Host Name . . . . . . . . . . . . : DESKTOP-xxxx
>>    Primary Dns Suffix  . . . . . . . :
>>    Node Type . . . . . . . . . . . . : Hybrid
>>    IP Routing Enabled. . . . . . . . : No
>>    WINS Proxy Enabled. . . . . . . . : No
>>    DNS Suffix Search List. . . . . . : fritz.box
>>
>> Ethernet adapter Ethernet 4:
>>
>>    Connection-specific DNS Suffix  . : fritz.box
>>    Description . . . . . . . . . . . : ASIX AX88772B USB2.0 to Fast
>> Ethernet Adapter #2
>>    Physical Address. . . . . . . . . : E8-03-9A-3C-67-7A
>>    DHCP Enabled. . . . . . . . . . . : Yes
>>    Autoconfiguration Enabled . . . . : Yes
>>    IPv6 Address. . . . . . . . . . . :
>> 2406:e002:xxxx:xxxx:80b2:5c79:2266:e431(Preferred)
>>    IPv6 Address. . . . . . . . . . . :
>> fd63:45eb:dc14:0:80b2:5c79:2266:e431(Preferred)
>>    Temporary IPv6 Address. . . . . . :
>> 2406:e002:xxxx:xxxx:89fa:eda3:4d87:293b(Preferred)
>>    Temporary IPv6 Address. . . . . . :
>> fd63:45eb:dc14:0:89fa:eda3:4d87:293b(Preferred)
>>    Link-local IPv6 Address . . . . . :
>> fe80::80b2:5c79:2266:e431%7(Preferred)
>>    IPv4 Address. . . . . . . . . . . : 192.168.178.30(Preferred)
>>    Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>    Lease Obtained. . . . . . . . . . : Saturday, 25 January, 2020 14:14:02
>>    Lease Expires . . . . . . . . . . : Tuesday, 4 February, 2020 14:14:02
>>    Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%7
>>                                        192.168.178.1
>>    DHCP Server . . . . . . . . . . . : 192.168.178.1
>>    DHCPv6 IAID . . . . . . . . . . . : 604000438
>>    DHCPv6 Client DUID. . . . . . . . :
>> 00-01-00-01-24-04-A7-BC-9C-DA-3E-8F-05-7F
>>    DNS Servers . . . . . . . . . . . :
>> fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
>>                                        192.168.178.1
>>
>>  fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
>>    NetBIOS over Tcpip. . . . . . . . : Enabled
>>
>> Wireless LAN adapter Wi-Fi:
>>
>>    Connection-specific DNS Suffix  . : fritz.box
>>    Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 7265
>>    Physical Address. . . . . . . . . : 1A-BC-EF-15-F2-27
>>    DHCP Enabled. . . . . . . . . . . : Yes
>>    Autoconfiguration Enabled . . . . : Yes
>>    IPv6 Address. . . . . . . . . . . :
>> 2406:e002:xxxx:xxxx:db7:d041:a2d:ce65(Preferred)
>>    IPv6 Address. . . . . . . . . . . :
>> fd63:45eb:dc14:0:db7:d041:a2d:ce65(Preferred)
>>    Temporary IPv6 Address. . . . . . :
>> 2406:e002:xxxx:xxxx:6029:b755:ced7:343e(Preferred)
>>    Temporary IPv6 Address. . . . . . :
>> fd63:45eb:dc14:0:6029:b755:ced7:343e(Preferred)
>>    Link-local IPv6 Address . . . . . :
>> fe80::db7:d041:a2d:ce65%23(Preferred)
>>    IPv4 Address. . . . . . . . . . . : 192.168.178.25(Preferred)
>>    Subnet Mask . . . . . . . . . . . : 255.255.255.0
>>    Lease Obtained. . . . . . . . . . : Saturday, 25 January, 2020 14:13:40
>>    Lease Expires . . . . . . . . . . : Tuesday, 4 February, 2020 14:13:38
>>    Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%23
>>                                        192.168.178.1
>>    DHCP Server . . . . . . . . . . . : 192.168.178.1
>>    DHCPv6 IAID . . . . . . . . . . . : 194828862
>>    DHCPv6 Client DUID. . . . . . . . :
>> 00-01-00-01-24-04-A7-BC-9C-DA-3E-8F-05-7F
>>    DNS Servers . . . . . . . . . . . :
>> fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
>>                                        192.168.178.1
>>
>>  fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
>>    NetBIOS over Tcpip. . . . . . . . : Enabled
>>
>> >
>> >     I found this link from Microsoft but it does not state if modified
>> is supported or not.
>> >
>> >
>> >
>> http://download.microsoft.com/download/F/D/F/FDF4CF55-5FDE-4CFF-8539-3662BB5EB7A0/TD13Basel2-43.pptx
>>
>> IPv6 has always used "modified EUI-64". What that 2013 presentation does
>> state is very clear:
>>
>> "Beginning with Windows Vista and Windows Server 2008, a randomized
>> method is utilized to determine the Interface ID instead of EUI-64" (slide
>> 26).
>>
>> In the next line it gives you the magic to revert to modified EUI-64:
>>
>> "netsh int ipv6 set global randomizeidentifiers=enabled|disabled"
>>
>> Regards
>>     Brian
>>
>
>    Gyan> I did some research on this v6ops related topic as far as
> operational impact of RFC 4941 privacy extension.
>
> So Microsoft as stated in the 2013 presentation has implemented RFC 4941
> starting with Vista with the MD5 randomize generated IID that is stored and
> persistent across reboot and only changes if the prefix changes with
> mobility and a new 128 bit address stable address is generated.
>
> The Privacy temporary address is generated from the Ethernet interface
> random IID and the first time generated after initial boot the temporary
> address is the same as the interface IID.  The temporary valid and
> preferred lifetimes are set based on a formula and is less then the LAN
> interface random IID.
>
> So what was envisioned by the author of RFC 4941 was to use the “stable”
> LAN  Random IID “Public” address for incoming connections which would be
> published via DDNS and outgoing connections for user privacy use the
> “privacy” temporary address.  The analogy used in the draft is the stable
> LAN address in the PSTN world is like publishing your phone number in the
> white pages, and your private temporary address is analogous to called ID
> block for anonymity.
>
> The operational complexity behind this approach of using multiple
> addresses is during regeneration is when the temporary address becomes
> depreciated it may still be used for existing outgoing connections while
> the new preferred address now active is being used for new outgoing
> connections.  At the same time all incoming connections are using the dns
> public published “stable” lan interface random IID.
>
> Imagine if you have multiple prefixes sent in PIO options to the host - 4x
> times the number of SLAAC prefixes received.  Way complex troubleshooting
> for operations.  Imagine a help desk rep asking a user “what’s your IPv6
> address”
>
> What Microsoft did not follow in their implementation is RFC 4941
> deployment considerations is that the temporary address should be disabled
> by default due to operational impact.
>
> Quoted from RFC 4941
>
> The use of temporary addresses may cause unexpected difficulties with
>    some applications.  As described below, some servers refuse to accept
>    communications from clients for which they cannot map the IP address
>    into a DNS name.  In addition, some applications may not behave
>    robustly if temporary addresses are used and an address expires
>    before the application has terminated, or if it opens multiple
>    sessions, but expects them to all use the same addresses.
>    Consequently, the use of temporary addresses SHOULD be disabled by
>    default in order to minimize potential disruptions.
>
>
> Disable RFC 4941 LAN interface “stable” Random IID = This should never be
> done as you revert back to OUI Mac based IID
>
> netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
>
>
> Disable temporary address:  Microsoft should have made this default.
>
> netsh interface ipv6 set privacy state=disabled store=persistent
>
>
> I will forward comment on  v6ops and OPSEC WGs and kick of a draft related
> to this critical topic.
>
>       Gyan> Fernando - As the author of RFC 7217 I am wondering as to the
reason why Microsoft and Apple have not adopted your draft for “stable”
IPv6 address.

My guess is that since the Random MD5 generated LAN IID is “stable” and OS
vendors have the option of disabling the temporary address - once that is
done you now have a “stable” random IID and best of both worlds ; single
traceable IPv6 address for incoming and outgoing connections for operations
as the IID does not change ; unless the device moves to a different LAN
drop ; with random MD5 hash generated LAN IID you have the user privacy
concerns met.  I did notice that RFC 7217 also does not preclude use of
temporary address.  So that is even more reason to stay course with RFC
4941.

>
>> >
>> >         Anyway, I hope we're all agreed that this topic, however
>> interesting is not worth more than a small comment in RFC4941bis. Isn't it
>> actually a v6ops topic ("Operational impact of numerous addresses per
>> host")?
>> >
>> >
>> >       Gyan> Agreed
>> >
>> >
>> >
>> >         Regards
>> >            Brian
>> >
>> >     --
>> >
>> >     Gyan  Mishra
>> >
>> >     Network Engineering & Technology
>> >
>> >     Verizon
>> >
>> >     Silver Spring, MD 20904
>> >
>> >     Phone: [phone]
>> >
>> >     Email: [e-mail] <mailto:[e-mail]>
>> >
>> >
>> >
>> > --
>> >
>> > Gyan  Mishra
>> >
>> > Network Engineering & Technology
>> >
>> > Verizon
>> >
>> > Silver Spring, MD 20904
>> >
>> > Phone: [phone]
>> >
>> > Email: [e-mail] <mailto:[e-mail]>
>> >
>> >
>> >
>>
>> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]