Re: Address privacy (was: Re: RFC4941bis: consequences of many addresses for the network)

[Gyan Mishra <[e-mail]>]

On Sun, Jan 26, 2020 at 8:26 AM Gyan Mishra <[e-mail]> wrote:

>
>
> On Sun, Jan 26, 2020 at 6:56 AM Jared Mauch <[e-mail]> wrote:
>
>>
>>
>> > On Jan 26, 2020, at 12:41 AM, Christian Huitema <[e-mail]>
>> wrote:
>> >
>> > the importance of address privacy increases.
>>
>> What you are saying is the cost to operate the network increases,
>> sometimes to the point where the privacy makes the network unusable. This
>> is the operational experience.
>>
>> It also means things like my ssh sessions can't last long enough to do
>> large transfers as the address is rotated away.
>>
>> There is more to the internet than browser activity. The noise of NDP for
>> all these addresses has a real cost. Some of the problems are documented in
>> 6583.
>>
>> A network that doesn't work is not the goal but it will have the privacy
>> you seem to be reaching for.
>
>
>   Gyan> I did some research on this v6ops related topic as far as
> operational impact of RFC 4941 privacy extension and Microsoft’s
> implementation.
>
> Microorganisms 2013 presentation
>
> http://download.microsoft.com/download/F/D/F/FDF4CF55-5FDE-4CFF-8539-3662BB5EB7A0/TD13Basel2-43.pptx
>
>
> So Microsoft, still being a major stakeholder In the desktop OS arena, as
> stated in the 2013 presentation above, 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.  I believe it’s 24 hours valid and 7 days preferred
> lifetimes by default.
>
> 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 - {
> link local, lan IID, depreciated temp, Preferred temp) 4x times the number
> of SLAAC RA prefixes received.  Way complex troubleshooting for
> operations.  Imagine a help desk rep asking a user “what’s your IPv6
> address”.  Not to mention doing a wireshark Trace and trying to understand
> the flow, with the end host using 4 different addresses simultaneously per
> SLAAC 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.  I think this is huge and
> the crux of the issue the IPv6 community has been faced with Day 1.
>
> 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
>
>
> Microsoft sill having a majority of the desktop marketplace ; if Microsoft
> had deployed by correctly following RFC 4941 - We would not have
> operational impact and now this discussion.
>
> However, Microsoft did follow RFC 4941 in providing the capability to
> enable or disable both the lan interface random IID or the temporary
> address show above.  So now given that “disabling” the temporary address is
> a solid workaround that most enterprises use for stability, in essence
> provides a “stable” address which is similar to what RFC 7217 provides.  I
> have been wondering why RFC 7217 has not taken off with OS vendors and I
> think the above is the reason why.
>

    (sorry - Typo above added “disabling” the temp address)

>
> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> 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]