Re: Temporary IPv6 addresses vs. netgroups

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 03 Feb 2013 10:56:24 +1100
    From:        Darren Reed <darrenr%netbsd.org@localhost>
    Message-ID:  <510DA7A8.3010106%netbsd.org@localhost>

  | The desire to use a temporary address doesn't change with
  | the application, it changes with the destination or to be
  | more precise, with the remote service with which the
  | application wishes to communicate.

No, not at all - or rather, once again, you are contemplating a different
problem than the one I am concerned with.

To be more clear, I am trying to get a mechanism that can be used by
NetBSD and pkgsrc developers, when they write/patch code for network
applications so they can have the application (as it gets shipped to
the users) can operate in the best possible mode, assuming the user
supplies no additional configuration information at all.

Anything that depends upon destinations, or which remote service
cannot possibly be relevant as except in a very tiny minority of cases
(applications like pkg_add perhaps) the developers have no idea what
the addresses will be, or with what site the application will be
communicating.

On the other hand, we know that for some applications (some network
protocols really - it doesn't matter if a http client is wget, curl,
or firefox) and with what we know about how servers are typically
configured and used throughout the network, things work better if
the source address is a stable address (for some) or if it is a
temporary address (for others).   Similarly, some apps work better if
(when/if mobile IP is ever used) if the source address is a home
address, and others if it is a care-of address.

Once again, this is not saying that the kind of policy control that
you're concerned with - which almost must be set up at the actual
user site, as they're the only ones who can know these policies, is
less important - it also doesn't mean that they cannot share some of
the same mechanism - but what you are proposing is simply not what I
am concerned with, or what I would like to be able to achieve.

  | Additionally, how is address selection policy enforced for
  | those applications for which source code is not available?

They do whatever they do now (which would include some site chosen
policy - something like net.inet6.ip6.use_tempaddr but probably a little
more general than that - my aim is to allow apps to be written to
work better, not to force them to be.   I readily admit that for many
apps there will be no change needed - for many it really makes no
difference, but for some it does.

  | When you consider the NFS problem, is it important whether
  | or not it is rpcbind or rpc.lockd or mountd or the kernel
  | that needs the non-temporary address for talking to the
  | NFS server? No. What's important is that all communication
  | with the NFS server for the purpose of using that NFS
  | server all use a stable address and preferably the same
  | one that the NFS server expects!

Yes, but it is only the NFS cients that need to use that, if I am also
communicating with a web server on the same system, then I'd prefer to
use a temporary address.   All the RPC (or at least the NFS related
RPC) apps should be selecting stable addressing (that might even be
done in the rpc library functions rather than anything higher)

And if I suddenly decide to mount from some other NFS server that I
haven't used before, I want that to be using stable addresses as well,
I dont want to have to remember to go add to my policy to make this
work correctly.   If the RPC library simply defaults all its sockets to
use stable addresses, then good things should normally happen.

  | Why do I trust the application to use the correct destination
  | address? Because if it doesn't then it doesn't give me the
  | correct service.

How do you know?   Consider the way proxy servers get used - the
app doesn't connect to the end address you tell it at all, but
somewhere else, yet you still end up with (more or less) the correct
service.   A nefarious app may do something similar for less benign purposes.

  | To go back to your examples, one of them was connecting to
  | an SMTP server. Chances are that you want the same source
  | address used regardless of whether the connection is made
  | using the telnet program or a dedicated mail program.

Yes, but from telnet, only if I am connecting to port 25 (and even
then I'm not sure it really matters, as I am probably not either
patient enough, or accurate enough with my time keeping, to get
through a greylist filter that way) - if I am using telnet to connect
to a HTTP server (port 80) I want a temporary address, and if I am
connecting to port 23, I probably don't care.  That suggests that
telnet (the program) should have no default address choice, but a
config option (command line switch, or telnet "set" command) to allow
me to choose one way or the other if I happen to need it.

  | If that is the case, why would you want to instruct each
  | of those separately as to how to choose a source address
  | rather than simply define a policy around communication
  | between the two hosts which by default governs how both
  | telnet and the mail program communicate?

Because I do not want to construct a policy at all.   Nor do 99% of
other users.   I want things to simply work as they come out of the
box, and work as well as possible.   If I find that I have some
unusual requirements, then I'll learn how to configure those (and I
certainly should have some ability to do that), but as long as I'm
just an ordinary user, I just want things to work.

kre