Subject: RE: Draft on IPv6 source address selection socket API

From: "Dave Thaler" <[email-masked]>
Date: Tue, 18 Mar 2003 13:51:22 -0800

I've read this document, and I would like to see it accepted as
a WG document and charter item.

Comments on the current text:

Section 3
> It is recommended that the application does a getsockopt() prior
> calling to setsockopt() call so that it can save the existing
> source address preference value, in the cases when the application
> might need to restore the preferences.

I think the above paragraph is unneeded and confuses the issue.
Setting the flags to 0 will restore the system default behavior.  
If the app is using multiple values at different times, the behavior
is really up to the app, and the issue is not specific to this 
socket option.  RFC 2553 etc do not contain a similar statement 
for other socket options which have the same issue.  I'd suggest 
deleting this paragraph.

Section 4
> The above flags are ignored for the AF_INET address family. If a
> returned address is an IPv4 address (either as AF_INET6 when
> AI_V4MAPPED, or as AF_INET) then the source preference flags have
> no effect.

If someone implements Mobile IPv4, wouldn't the HOME/COA flags
be applicable to IPv4 source addresses?

Section 7:
> Is there a need for REQUIRE flags in addition to or instead of the
> PREFER flags? Note that in general it isn't possible to verify 
> that a requirement can be satisfied until sendto() or connect()
> (when the destination address is known) thus this would result
> in late errors being reported to the application.

I agree "require" flags would be nice.  For example, if an app requires
a particular type of address and there are no such addresses available,
it may be better to fail the setsockopt than either failing all sends or
using another type of address instead.

If the consensus is go this way, it would be better in my opinion, 
to split the socket option into 3 separate options (HOME/COA, 
TMP/PUBLIC, and CGA/NONCGA).  For each of those three options, 
you'd have 5 values:
   Require A
   Prefer A
   Use system default rules
   Prefer B
   Require B

I also saw a couple of typos/grammar issues which I will just send
to the authors.

-Dave

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Mar 2003 23:46:29 +0100 (CET)

> for other socket options which have the same issue.  I'd suggest 

The issue is that by having PREFER_FOO and PREFER_NOTFOO flags
is that the absense of having any of PREFER_FOO and PREFR_NOTFOO flags
set in a setsockopt nothing about the "foo" state can change.
If it did change they the application couldn't change the state for bar
independently of foo.

A result of this is that a setsockopt with zero flags can have no effect.
So unless we change the approach we'd need a separate mechanism for
resetting to the default.

> be applicable to IPv4 source addresses?

Could be. We can relax this to allow it to work for IPv4.

> using another type of address instead.

With the complications that some failures will appear late e.g. due to
a source address of the type not (or no longer) being available on 
the outbound interface.

Another complication is that I don't know what it means to
say REQUIRE_HOA or REQUIRE_COA if the node isn't
currently mobile or when it is at home.
The softer notion of preferences avoids this, but addition
validation ("is this address a HoA") adds that complication
back in I think.

   Erik