> > I respect the desire for temporary addresses (and AFAIK I was one of
> > the first people to raise concerns about embedding tracable information
> > in an IPv6 address) but I don't think it's a good idea to effectively
> > change the API in a way that would break apps at this late date.
> 
> The proposed text is trying to say that temporary addresses are preferable
> but that there might be issues (such as applications having problems)
> which consistitute a good enough reason to not follow the default.
> Thus there is significant freedom for implementors to use their best
> judgement based on their knowledge about the applications.
> 
> Do you see a problem with this approach?

absolutely.  it encourages the API to deviate from one vendor to another,
and from one installation to another.  application coders thus can't
count on predictable behavior from one platform to another - if they
care at all what kind of address they want, they always have to do
explicit binds of both source and destination addresses.  worse, it
introduces subtle failure modes where an application that works fine
in one environment will fail in a different but apparently similar 
environment, even though the network seems to be working find otherwise.

The idea that hosts, or administrators, can make reasonable address 
selections without input from the application is just wrong.  The 
application, no the host,  knows what kinds of addresses it needs - 
for some, temporary addresses will do just fine, but others needs stable,
public, globally-scoped addresses.  If this is not communicated 
explicitly then every application will have to do its own address
selection in order to work reliably.  Being able to alter the policy
on a per-host basis is not a good solution, because it makes the 
platform less predictable (see above), and because multiple applications
needing different policies will often run on the same host.
   
I'd far rather see an approach like the following:

1. the API default is to use stable addresses
2. to request a temporary address, do it this way
3. applicatons that don't need stable addresses SHOULD request 
   temporary addresses

I've got some other problems with the document  also - specifically
the idea that link-local addresses are preferable to global addresses.
Global addresses are always preferable because all applications
can tolerate them.  At most, LL addresses should be used only
when there is no other alternative, because some applications 
need to treat them specially (this isn't as bad in v6 as in v4)
But LL addresses should probably be used only when they are 
explicitly specified.

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]
--------------------------------------------------------------------

Reply via email to