tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Temporary IPv6 addresses vs. netgroups

    Date:        Sat, 02 Feb 2013 23:27:21 +1100
    From:        Darren Reed <>
    Message-ID:  <>

  | Not selecting the temporary address seems like a rather trivial thing

Yes, though I think we need an API that at least allows for extension
(so we don't end up with a whole bunch of specific requests that don't
necessarily play well together).

  | and not something that will completely fix the problem being described.

No, that's near where this discussion started.   Completely fixing the
problem, that is, handling every strange desire that someone might dream
up is hard.  Solving enough of the problem that it will be adequate for
most ordinary uses is fairly easy.   At least a part of a solution (as
long as we can reasonably adapt it later if we discover more that we need)
has to be better than no solution at all because a complete fix is too hard.

  | RFC 4941 looks to me like someone realised that the EID in
  | IPv6 addresses had privacy implications

Of course - though not really much worse than the original internet.
Source addresses were always supposed to identify the sender ... back
in the days when addresses were available, and assigned "for life"
the same issue existed.   It has only been the use of NAT which effectively
hides the identity of individual systems from the outside world that's
given rise to this extra expectation of privacy.

  | and so something was concocted to "fix"
  | that problem that they had created.

Yes.   Though not really "they created" but more to account for the
change the internet had undergone (do recall than when v6 development
started, NAT use was not yet widesread - that happened during the
development of v6 to help keep v4 alive long enough to avoid collapse).

  | ... it isn't just web browsers that will leak that piece
  | of private information to the Internet, it is anything that
  | connects out through the Internet, be it the web browser,
  | ftp client or ssh.

Yes - I was just giving an example of the kind of application for which
avoiding stable addresses is useful, not attempting to be exhaustive.
ftp clients would be another application.  I'm not sure ssh matters as
much, as ssh clients tend to identify the actual user, which is even more
precise identification than just identifying the host.   But it wouldn't
harm ssh clients to use temp addrs.

  | This indicates to me that the policy for when a temporary
  | address should be used is not something that we can depend
  | on an application to provide.

I don't grasp that leap - for sure, the user might want to override
the application's default, which would usually be done by telling the
application to request a different policy.  You might just as well say
that the application cannot be entrusted with selecting the destination
address, as the user might want to connect to different destinations.

  | For example, if you're using
  | a web browser on a coroporate LAN then you most likely don't
  | want to use a temporary address

By default sure I would, it makes no difference what the server is.
If the server needs some kind of authentication, I don't want it using
addresses for that if at all possible, there's no good reason for a
http client to ever require a stable address (though there should be
a way for the user to request it, if there happens to be a requirement).

  | Some example policies for when temporary addresses are to be
  | used might be as follows:

There could be all kinds of policies.   Some of the ones you gave
are likely, others don't make a lot of sense for most people, and
are probably beyond what a first attempt simple API needs to be able
to provide.

  | The bottom three policies are all attributes of the
  | relationship between the two hosts and could arguably be
  | represented by a an attribute attached to a specific route
  | entry for that destination.

Something like that might be useful, but it isn't just the hosts, but
also the application and I suspect that kind of mechanism is perhaps a
2nd level of implementation.  At least you now seem to agree that something
to allow different address types is needed.   Getting that agreement is
important, then it will make sense to start to look at what the API
might be (there have been a few ideas floated around, but nothing really
investigated yet, so avoid making judgements based on any imagined
particular API).


Home | Main Index | Thread Index | Old Index