> And anyone who attempts to run server style apps on a host using temporary > addresses will get all kinds of trouble anyway.
I don't believe in the client-host vs. server-host distinction. Yes, I realize that large-scape production "servers" usually need dedicated hardware. But there are lots of things that want to answer to unsolicited input that don't run on dedicated hardware. Most hosts are going to run a mixture of clients, servers, and p2p apps. A per-host "use temporary addresses by default" bit is just another bit that needs to be set to false so much of the time that you're far better off never setting it to true. The presence of this bit increases the burden for both applications (which have to work regardless of this bit setting) and sysadmins (for whom the bit creates one more obscure failure mode that they need to worry about) without any measurable benefit. You'll get far better results by not having this bit, and having apps that can use temporary addresses ask for them explicitly. The apps that can use those addresses only need to add or change one line of code; those that can't use them don't have to change at all, and sysadmins don't have to do anything. OTOH, if you do have this bit, some apps will incorporate their own address selection code (because there's no way to get the system library to do what is needed), others won't, and for the sake of those others sysadmins will have to worry about whether that bit is set correctly. This is one of those solutions that creates more problems than it solves. Life will be simpler and things will work smoother without that bit. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
