Re: Long overdue review of draft-ietf-6man-rfc4941bis-00

Mark Smith <markzzzsmith@gmail.com> Wed, 06 March 2019 04:23 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9D130EAE for <ipv6@ietfa.amsl.com>; Tue, 5 Mar 2019 20:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU7km4Ft8kxU for <ipv6@ietfa.amsl.com>; Tue, 5 Mar 2019 20:23:43 -0800 (PST)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A1F130EA1 for <ipv6@ietf.org>; Tue, 5 Mar 2019 20:23:42 -0800 (PST)
Received: by mail-oi1-x22c.google.com with SMTP id u128so8788424oie.2 for <ipv6@ietf.org>; Tue, 05 Mar 2019 20:23:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RqW5pvjUHZa6rYowPkdD1FtjDFGsBxsCo80zyyjCr9o=; b=I/9oMEO/8VmgzevWGr4mVPyW/ypN+XoFHMomTOO5KqK6Zue13wNfu9zYtijLy6tioX 8sjMG1RVZIW+B0GfP30fWlfmCwBwfytEKPvtfUrlZ96BrYmWG+95GLJYeIicJW+W+87t z+RTymvaPWHaBfSInMLgtLDKkLxHuAgqgvG9GQOvEAciwREWyODpvlo0lpWNMcvjBeM/ 19JhT1Ix2DHPU8JCm4+b/uWhh08mJsWfOvxCeXn0oObmWFsmVpSOwC7qK0KCijwtNqsn xdqYkJ7VmcoIxAhxAjtGi3pIwzeUEXLStgrnQ6rNIHGpot5tMZSsepxsyQssRRccfHNM vrag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RqW5pvjUHZa6rYowPkdD1FtjDFGsBxsCo80zyyjCr9o=; b=KTDFl4Ux5GDEsbkmk+utiZwG0xP1n32ngDM2blHdUg1euA1o267MPhWhG3S7zS7/uQ gjoeHV8YyNJwuwjhV0SRXGjZc0kOD0FXCxfaUa0TqPmxDgGLLNlmYnsqmDUPz16A8vOR pF1pn+LbQj7C89PXjx7y3D8NPYB669HvEQgW1FzfvdED7+8x8cQkEx+6D4erk/zYAlYM jM6L9e9nUAS97NbkatsQcyVsGOjnUe01L8rBlexe5ZgmaP9aqjVBttOBiG0NWvxIN19+ CjN5Pw5l5qJAzx9RbZ5RZCub9p9GFZeqmC6sWRK1wHK7AmETgfzj6JOVV/YUMqxd/LqU 1aZQ==
X-Gm-Message-State: APjAAAUV9g0O68Dzmr8HVAPF3UCkWWAhV6lz2wvRQU+LZ95hUn1S3J+M TpSv2S9ooCQEMH83yn7gRxb82lnZQNT8Rs42sbo=
X-Google-Smtp-Source: APXvYqzts4y2O2pgj5DAL8nIMt6ioTaHGZ90jOmz0H0ZZOC0sy+iPX+Ri5Iwu8XQVRBql9Pn1CNRkGJC4LvJST2wFoY=
X-Received: by 2002:a54:4891:: with SMTP id r17mr508467oic.7.1551846221584; Tue, 05 Mar 2019 20:23:41 -0800 (PST)
MIME-Version: 1.0
References: <CAO42Z2w+P9AgD8mq6BTUr47yYP24Fn4QoFhRpF_kfZOoRgk++Q@mail.gmail.com> <4b4977ab-a1b2-e3dd-60e3-07945e48d76a@si6networks.com>
In-Reply-To: <4b4977ab-a1b2-e3dd-60e3-07945e48d76a@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 06 Mar 2019 15:23:15 +1100
Message-ID: <CAO42Z2weUi6jArdgkCHhBowXi51s2tVL8zcSpLnPt1T7mWJJBg@mail.gmail.com>
Subject: Re: Long overdue review of draft-ietf-6man-rfc4941bis-00
To: Fernando Gont <fgont@si6networks.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/uR_uILySu_x5Z_ClXTQU2xOpdaE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2019 04:23:45 -0000

Hi Fernando,


On Sun, 3 Mar 2019 at 18:14, Fernando Gont <fgont@si6networks.com> wrote:
>
> Hello, Mark,
>
> Thanks *a lot* for your review! -- Please find my comments in-line....
>
> On 1/3/19 07:29, Mark Smith wrote:
> > IETF 102 Questions
> > ~~~~~~~~~~~~~~~~~~
> >
> > Q. Algorithms?
> >
> > - I think having a single specified and well known algorithm is best,
> > as it removes a point or points of implementation ambiguity.
> >
> > - I think "a la rfc7217" is better.
> >
> > I would think that on a normally "temporary address only" device, if
> > temporary addresses are disabled for troubleshooting or local
> > administrative policy, then the device should fall back to having
> > RFC7217 stable addresses.
> >
> > Otherwise, if a normally "temporary address only" device has temporary
> > addresses disabled, the result would be to have no IPv6 addresses on
> > the device at all, making it entirely unreachable via IPv6.
> >
> > So using and having available the RFC7217 algorithm on a normally
> > "temporary address only" device means that the fall back to RFC7217
> > stable addresses is possible.
> >
> > Of course, on a device that has both temporary and stable addresses,
> > RFC7217 algorithm can be used for both types of addresses.
>
> Do you mean that:
> 1) The "a la rfc7217" should be kept, along with the other algorithms?, or,
>
> 2) that "a la rfc7217" should be kept in the doc, and the other
> algorithms should be removed?, or,
>
> 3) something else?
>
>

Single algorithm. Stable RFC7217, with minor adjustments to input parameters.

>
>
> > Q. When to change IIDs?
> >
> > Question regarding if/how we could prevent on-ink glitches from
> > triggering IID rgeneration?
> >
> > It's my understanding that the trigger events for generating a new
> > temporary address for a prefix are:
> >
> > - Receiving an RA with new and formerly unknown PIO prefix
> >
> > - Ageing out of an existing temporary address
> >
> >
> > So a link down/up event shouldn't directly cause new temporary
> > addresses to be generated.
>
> [me thinking out loud]
>
> Maybe one additional item to consider here is whether keeping the
> addresses might expose the previous addresses on a possibly new network?
>
> Maybe one possible alternative could be to tie generation of new privacy
> addresses to the underlying MAC address in the sense that:
>
> 1) If you've produced a new randomized mac address, then you should also
> produce new temporary addresses.
>
> 2) then, despite 1), if the node implements DNAv6, and attachement to a
> new network is inferred, also regenerate the temporary address?
>
>

It really depends on whether implementations are going to be smart
about what the cause of an interface down/up event is.

If they're going to be simple, and always assume that a interface
down/up event is always a movement to a new network, then temporary
addresses will have to be removed and then generated upon every
interface down/up event. This issue will be ignored.


>
> > I think there is a case for having Link-Local temporary addresses too
> > (which I'll describe later). As there is no RA PIOs for the Link-Local
> > prefix, then I think DNAv6 is probably the only way to determine
> > whether to generate a new Link-Local temporary address or not.
>
> fwiw, at the time of this writing, there's not really such a thing as
> "temporary mac addresses".
>
>

Easy to miss, I am referring to temporary FE80:: addresses, not
temporary MAC addresses.

>
> > Q. Requirements for temporary IIDs
> >
> > I.e. incorporate into rfc4941bis or not?
> >
> > I think it is good to couple together requirements and the
> > corresponding solutoin in the same document so that people can see how
> > the soluton is solving the problem.
> >
> > However, perhaps if there is the possibility of a future alternative
> > and unrelated solution, then separating the requirements out into a
> > separate document could be useful. An example would be that that the
> > requirements for DHCPv6-PD are in a separate RFC [RFC3769] to that of
> > of DHCPv6-PD itself [RFC3633].
>
> It would seem to me that there will not be multiple solutions to this.
> If anything, this document may contain a few possible algorithms to
> generate randomized IIDs...
>
> So, in that case, it would seem that the best way to go would be to keep
> the requirements here...
>
>
>
> > Q. On by default?
> >
> >
> > I think they should be enabled by default, as it would be consistent
> > with the advice in BCP188/RFC7258, "Pervasive Monitoring Is an
> > Attack":
> >
> > "Pervasive monitoring is a technical attack that should be mitigated
> >    in the design of IETF protocols, where possible."
>
> Agreed.
>
>
>
> > I think there could be a specific exception, where it is clear and
> > obvious that the IPv6 implementation will be being used on a device
> > that does not have any privacy requirements that temporary addresses
> > satisfy. For example, I don't think a single purpose router device's
> > IPv6 implementation would have a need to have these devices enabled by
> > default, as it is usually not running any end-user applications, due
> > to it having a relatively limited CLI.
>
> I wonder what's the way to go here:
> 1) Incorporate an Applicability statement, or,
> 2) Simply assume that a router will not implement rfc4941bis
>
>
> Thoughts?
>
>

Given how critical privacy is, an Applicability statement.

I think it is reasonable to assume any time there is ambiguity about
what is required, privacy will be compromised. So we need to be
prescriptive.


>
> > Also, as discussed later, I think there should also be temporary
> > Link-Local addresses for devices that need temporary addresses. As
> > temporary global and link-local addresses would cover all current
> > types of addresses, with exception to the loopback address (which I
> > think could be considered to be a "node-local" scope address type),
> > perhaps the default temporary address recommendation should be more
> > broad - temporary addresses should be enabled by default for all
> > address types except when there are specific reasons for exceptions -
> > e.g. loopback address, the device cannot or is very unlikely to be
> > used to run end-user applications.
>
> It would seem to me that since link-locals essentially have the same
> scope as the MAC addresses, then one might want that, for temporary-only
> addresses, one might want to use the MAC address for the Network_Iface
> parameter in RFC7217, such that a new randmized mac addresses will
> result in a new link-local address.
>
> *For temporary-only hosts*, changing link-local addresses upon change of
> the underlying mac address would make sense. OTOH, if it's
> stable+temporary it wouldn't make much sense.
>
> Thoughts?
>
>

I think it is a mistake to be so tightly coupling IPv6 temporary
addresses to random MAC addresses and when they're generated.

>
> > Some Other General Thoughts
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > - Temporary Link Local Addresses Are Necessary
> >
> >
> > I think devices should also have temporary link-local addresses.
> >
> > For a stable RFC7217 link-local address, the link-local prefix is
> > constant across all networks/links, and the Network_ID parameter in
> > the RFC7217 algorithm is optional. So for implementations that don't
> > use Network_ID, a device will probably a persistent, stable, globally
> > unique Link-Local address on its interface, regardless of the network
> > it attaches to, unless one of the other RFC7217 parameters happens to
> > change e.g. DAD_Counter.
>
> How about using the MAC address for Network_Iface?
>
>
>

This is starting to sound like it is turning into a specification for
when MAC addresses need to be randomised.


>
> > Even if the implementation does use Network_ID, it is possible that
> > the value could be the same across different networks. An example
> > would be where same Wifi SSID at different locations, such as hotel,
> > cafe and shopping centre chains. The exact same Wifi SSID is also be
> > used widely by telcos who provide mobile to Wifi offload via their
> > customers' CPE.
>
> Agreed. But this should be chained to the mac address. -- I.e., changing
> the link-local address while maintaining the underlying mac address
> wouldn't make much sense...
>
>

At this point, if this is the direction, then I'd suggest:

- abandon this Internet Draft

- write a new Internet Draft that says,

  - random MAC addresses are required

  - how often MAC addresses are randomised

  - state that every time the MAC address is randomised, re-execute
stable RFC7217

  - private/temporary IPv6 addresses are not available on link-layers
that don't have link-layer addresses

I wouldn't agree with that approach, the link-layer and network layer
are supposed to be decoupled as much as possible, not coupled as
tightly as possible.

I don't really want to spend anymore time on this until it is decided
whether random MAC addresses are required, otherwise I'm going to have
to constantly be saying, "Assuming there are no random MAC addresses,
" for every comment the rest of this email.


> >
>
> > General Comments on ID Sections
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > - Abstract
> >
> > If agree with LLs also needing temporary addresses, then mention of
> > them as an address type here too in additon to global scope address
> > type.
> >
> > Or, if agree that temporary addresses should be the default all
> > address types with exception to loopback, then mention that instead.
>
> Unless a significant number of folks comment on this issue, I will start
> a new thread to get input from the wg -- particularly because this is a
> change from rfc4941.
>
>
> >
> >
> > - 2.2 Possible Approaches
> >
> > Suggested section to mention fall back to generating stable RFC7217
> > addresses if temporary addresses are disabled on a normally temporary
> > address only device, probably as part of the "On the other hand, a
> > machine that functions only as a client ..." paragraph.
>
> Point taken.
>
>
>
>
> > - 3.2.2 Hash-based Generation of Randomized Interface Identifiers
> >
> > As mentioned before, I think RFC7217 should be the single agorithm.
> >
> > However, rather than modifying it, I think it would be better to keep
> > it and its parameters inputs and parameter names the as close as
> > possible to stable RFC7217 algorithm, which better leverages reusing
> > the stable RFC7217 algorithm's implementation code.
> >
> > To use the stable RFC7217 algorithm to generate temporary addresses, I
> > think the following changes to how it is used.
> >
> > Firstly, the 'secret_key' parameter value is generated the same way as
> > for stable RFC7217 addresses, i.e. a pseudo-random number of at least
> > 128 bits. However, rather than storing it and reusing it, a new
> > 'secret_key' value is generated each and every time the RFC7217
> > algorithm is used to generate a temporary address.
> >
> > Secondly, I understand that there can be some issues with system
> > pseudo-random generators on virtual machines because the don't have
> > good hardware input sources. So as some temporary address RFC7217
> > input redundancy, I'd suggest that the DAD_Counter is incremented each
> > and every time the RFC7217 algorithm is used to generate a temporary
> > address.
> >
> > I'm certainly no expert in this area, however it seems to me that it
> > could be useful to try to avoid having the pseudo-random number
> > generator be a single-point-of-failure while trying to reuse as much
> > as possible the RFC7217 algorithm for temporary addresses.
>
> One argument that was made in favor of using the prng was that in the
> event a flaw were found, it would be addressed by the OS... whereas if
> we were to use something else, then any flaw in the algorithm we use
> would have to be specifically fixed for temp addr generation.
>
>
> However, the scheme you propose seems to be a mix of both.. so it should
> be okay.
>
>
>
> > Per the existing advice, a MAC address could be recommended as the
> > default value for Net_Iface when it is random, and new IPv6 temporary
> > addresses generated when the random MAC address is changed. It is
> > probably worth noting that some link-layers don't have link-layer
> > addresses at all e.g. PPP. I'm not sure if it is necessary to do
> > anything about those types of link-layers if 'secret_key' and
> > DAD_Counter are changed as above each time a temporary address is
> > generated.
>
> Not really. As long as one or some of the arguments to the hash function
> change, we're fine....
>
>
>
>
> > - 3.3 Generating Temporary Addresses
> >
> > Per previous private feedback, a number of the steps in this section
> > are using the generation of stable addresses as the trigger for
> > generating temporary addresses, which is probably hang over text from
> > RFC4941 text. So the text will need to be changed to decouple
> > generating temporary addresses from stable address generation events.
>
> Good point. Will do.
>
>
> > The above answer to the IETF 102 question about flapping links causing
> > excess temporary address generation relates to this section.
>
> Could you please elaborate?
>
>
>
> > - 3.4 Expiration of Temporary Addresses
> >
> > Regarding the suggested optional optimsation of removing deprecated
> > temporary addresses if theyy're not being used by applications, there
> > possible needs to be some more consideration and text for this, in the
> > context of RFC4861, "5.5.4.  Address Lifetime Expiry".
> >
> > Firstly, it would be overriding a MUST default behaviour for the use
> > of deprecated source addresses for new connections:
> >
> > "An implementation MAY prevent any new communication from using a
> >    deprecated address, but system management MUST have the ability to
> >    disable such a facility, and the facility MUST be disabled by
> >    default."
>
> Is this a quotation from RFC4861?
>
> If not, I'n unroll the double-negation , which makes it harder to parse
> the text.
>
>
>
> > Another related issue is the use of these temporary addresses for
> > incoming connections. This use isn't specifically excluded in this
> > draft, and I'm reminded of a Peter Gleitz and Steve Bellovin paper,
> > which is an idea that isn't too far from hosts having limited lifetime
> > temporary addresses independent of applications.
> >
> > "Transient Addressing for Related Processes: Improved Firewalling by
> > Using IPV6 and Multiple Addresses per Host" (TARP)
> > https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html
> >
> > RFC4861 says
> >
> > "IP and higher layers (e.g., TCP, UDP) MUST continue to accept and
> >    process datagrams destined to a deprecated address as normal since a
> >    deprecated address is still a valid address for the interface."
> >
> > So unless the use of these temporary addresses for incoming
> > connections is explicity prohibited by this specification, the
> > suggested optimsation might be too contrary to what RFC4861 specifies.
>
> I agree with this. However, this seems to go a bit over rfc4941bis -- se
> https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations
>
> ... and there's the tricky bit of how to handle connectionless protocols
> such as UDP.
>
>
> I will raise the topic in a separate thread to the wg.. but i'd believe
> that this is kind of "out of scope" for rfc4941bis
>
>
> >
> > - 3.5 Regeneration of Randomised Interface Identifiers
> >
> > Perhaps a mention of on-demand, application generation of temporary
> > addresses as possible future work, and a reference to TARP (as
> > mentioned above). I think an on-demand TARP like scheme would further
> > increase privacy, while avoiding the performance impact of timer based
> > temporary address generation with low value timers.
>
> Yes.
>
>
> >
> > Another more general observation that may be worth mentioning is these
> > timer driven temporary addresses are providing a baseline minimum and
> > also enforced level of address privacy. As these addresses will be
> > deprecated based on timer expiry, an application's of them will be
> > constrained, regardless of if the application would like to use the
> > address for longer than the temporary address lifetime.
>
> Could you please elaborate?
>
>
>
> > Regarding the final paragraph, I think it would be good to make it
> > more clear that a "new link" is a different link, and that the
> > different link would have different on-link prefixes and therefore RA
> > PIOs. The new RA PIO prefixes would trigger the generation of new
> > temporary addresses.
>
> I'd say that we could point to DNA or elsewhere... but getting into
> details on "how to detect a new link" would seem like opening a can of
> worms for this document.
>
> Thoughts?
>
>
> > (I wonder if we need to worry about a scenario where there is the same
> > prefix both on the old and new different link. It's a fault if it is
> > unintentional, however if intentional, than that is saying that the
> > prefix is an anycast prefix.
>
> Or could be ULA...
>
>
>
> > - 3.6 Deployment Considerations
> >
> > Regarding implementations providing a method to switch off temporary
> > addresses entirely, it probably doesn't need to be said how that would
> > be facilitied, as it's probably obvious that it would be an on/off
> > configuration setting or checkbox somewhere in the device.
> >
> > Disabling on a per-prefix basis on an individual device is probably
> > less obvious, however the suggestion could be that once a prefix is
> > learned via an RA PIO, there is a configuration item or user interface
> > that provides temporary address on/off setting or checkbox for the
> > learned prefixes.
> >
> > However, I don't think it is obvious how to disable temporary
> > addresses entirely or on a per-prefix basis at a site / network level.
> > Is there a mechanism available to do this, or is one being worked on
> > e.g. a DHCPv6 option? If there isn't, then it is probably best to say
> > that an IPv6 protocol mechanism for site wide disabling of temporary
> > addresses entirely or per-prefix doesn't currently exist, and that
> > this would have to be achieved via some out-of-band host configuration
> > method.
>
> My understanding is that this "site settings" are actually host-based
> settings.
>
>
>
> > A related thought to site or network level disabling is that the
> > end-user of a device may have a different and greater privacy need and
> > expectation than what the site's administrator believes is needed and
> > expected. If privacy was breached because the site administrator
> > disabled temporary addresses, the end-user would be the privacy breach
> > victim, while the site administrator is less likely to be.
> >
> > So even where the site administator is trusted, I think it should be
> > required that the device's end-user is given the final say on whether
> > temporary addresses are disabled or not, through some sort of positive
> > acknowledgement of acceptance of the policy that temporary addresses
> > are being disabled (either entirely or on a per-prefix basis.)
>
> I think this would be getting into too many details. Besides, at the end
> of the day, the site rules. e,e,g, a site mite limit the number of
> IPv6addresses per underlyng MAC address, etc.
> >
>
>
> > This sort of positive acknowledgement becomes essential if the site
> > administrator is less trusted or untrusted. For example, I wouldn't
> > want to attach my laptop or mobile phone to a hotel, conference or
> > cafe's networks and then have them disable privacy addresses on my
> > device without me accepting that. If there was an attempt to disable
> > privacy addresses, I'd instead choose not to use their network.
>
> There's no mechanism available for the network to convey this info --
> hence, you try to use temp addresses... and they may or may not work....
>
>
>
> > Regarding the comment about a single node using a single prefix, and
> > therefore the single prefix subnet identifier becomes a single node or
> > end-user identifier, a mitigating factor is that the remote malicious
> > actor needs to assume or somehow determine that this is the address
> > assignment policy. This may be easy to assume if e.g. the Autonomous
> > System Number that the IPv6 addresses come from corresponds to a
> > mobile telco, with /64s being assigned to each "User Equipment" i.e.
> > phone.
>
> Well, if you get PERIODIC connections fROM the same , say /64 , only one
> address is active at a time, and then eventually the address changes...
> then it's possible to infer that it's just a single host....
>
>
> >
> > For other ASNs that have a more diverse customers types could take
> > prefix subnet allocation measures to hide the assignment of a single
> > prefix to a single device, by e.g. allocating a /48 or /56 to each
> > customer, resembling a conventional broadband address space allocation
> > scheme, and then assigning a /64 from that allocation to the
> > individual device. The use of one or a small number of prefixes within
> > the /48 or /56, with a the single device periodically changing its
> > IID, would externally look more like multiple devices using the subnet
> > rather than a single one.
>
> THat would be the case if the addresses were "use and throw away". But
> if temp addresses are refreshed every few hours, then stability period,
> and change of active address with no overlapping period will essentially
> leak that's it's just a single host.
>
>
> > - 4. Implications of Changing Interface Identifiers
> >
> > Regarding debugging and troubleshooting, logging of which temporary
> > addresses were used by which application and when on the temporary
> > address device itself would also be useful. It probably should be a
> > capability of the temporary address implementation to be able to
> > switch this sort of logging on and off.
>
> You mean include the port numbers in the log, or what?
>
>
>
> > - 6. Future Work
> >
> > In addition to Onion routing, Transient Addresses for Related
> > Processes (referred to above) and similar, which could provide
> > applications with their own on-demand may be future work worth
> > pursuing, as it may provide better address privacy through shorter
> > lived addresses, while also avoiding the performance impact that timer
> > based temporary addresses would impose if they had low timer values.
>
> And there's the API issue, too. see
> https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations
>
> Thanks!
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>