Subject: comments on the address selection API draft

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 23 Mar 2003 19:32:22 +0900

I have some comments on draft-chakrabarti-ipv6-addrselect-api-00.txt,
in addition to those already raised in this list (I'd apologize in
advance if there's any duplication).

1.  Introduction

   Currently IPv6 socket API extensions does not provide a
   mechanism to choose a particular source address other than simple
   bind() operation.

This is not really true.  We can also specify the source address by
the IPV6_PKTINFO socket option or ancillary data item defined the
advanced API.  This does not matter much, though, because we still
need to specify a particular source address.

   Furthermore, the approach is to define two flags for each purpose, 
   so that an application can specify either that it prefers 'X' or
   prefers 'not X', or it can choose not to set either of the flags
   relating to 'X' and leave it up to the system default, perhaps while 
   specifing its preferences for some other attribute of the source
   addresses.

Hmm, I'm not sure if this is really possible with the API described...
later the draft says (in Section 3):

    The flags defined in this document are:

    IPV6_PREFER_SRC_HOME
    IPV6_PREFER_SRC_COA
    IPV6_PREFER_SRC_TMP
    IPV6_PREFER_SRC_PUBLIC
    IPV6_PREFER_SRC_CGA
    IPV6_PREFER_SRC_NONCGA
(...)
    .... If the option is not set, the system selects
    a default value. Setting conflicting flags at the same time results
    in the error EINVAL.

I read this to mean unless IPV6_SRC_PREFERENCES is explicitly
specified, the kernel will choose the default values for all the
parameters.  If my understanding is correct, how can I specify a
preference for HOME vs COA but keep the default for TMP vs PUBLIC?
Am I supposed to unset both IPV6_PREFER_SRC_TMP and
IPV6_PREFER_SRC_PUBLIC?  But isn't it a conflicting configuration
since these two are exclusive flags?

The current specification is at least unclear to me on this, and
perhaps even contradicts itself.  We could clarify this point, but I'm
afraid the result would be complicated and unintuitive...

5. IPv4-Mapped IPv6 Addresses

   IPv4-Mapped IPv6 addresses are not supported for setting preference
   on home, care-of-address, CGA, non-CGA, public or privacy auto-
   configured addresses as source addresses.

"privacy auto-configured addresses" should just be "temporary
addresses" to be consistent with the rest of this draft.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Mon, 24 Mar 2003 11:42:00 +0100 (CET)

> need to specify a particular source address.

Good point. The issue is that the existing APIs can only support specifying
a specific source address, whether bind() or IPV6_PKTINFO is used. We
can make this more clear.

> since these two are exclusive flags?

If you do a setsockopt with IPV6_PREFER_SRC_HOME (or COA) and
do not set either of _TMP or _PUBLIC, then you will leave the
TMP vs. PUBLIC selection at the system default.
Thus not specifying either of "X" and "not X" leaves the "X" property of
the address selection at the system default.

> afraid the result would be complicated and unintuitive...

The questions on this point makes it clear to me that
the document is unclear :-)

An alternate API would be to have one flag per property and always require a
get before a set. An example of that style of API is fcntl with F_SETFL and
F_GETFL where the logic for setting e.g. FASYNC is
	flags = fcntl(s, F_GETFL, NULL);
	flags |= FASYNC;
	fcntl(s, F_SETFL, flags);
and the logic for clearing it is:
	flags = fcntl(s, F_GETFL, NULL);
	flags &= ~FASYNC;
	fcntl(s, F_SETFL, flags);

Something similar could be done using getsockopt and setsockopt
for the source preferences. But this would require a getsockopt
before the setsockopt to avoid accidentally changing some preferences.

  Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 24 Mar 2003 21:33:13 +0200

> the address selection at the system default.

And if the application specifies both "X" and "not X"? 

In a classic adventure game by Douglas Adams the ability to do this
would have constituted proof of superior intelligence, however here it
is clearly an illegal combination. Having a lot of illegal parameter
combinations in an API is not very desirable, as it requires extra
sanity checks in the implementation.

> get before a set.

I think I would prefer this approach. This is clean, no special cases,
and allows simple checking of system defaults. The application can
always store the default bit vector if it creates multiple sockets.

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Mar 2003 13:17:28 +0100 (CET)

> And if the application specifies both "X" and "not X"? 

That would be an error.

> > An alternate API would be to have one flag per property and always require
> a > get before a set.
> 

A psychological aspect of such an API is that we need to nail down
what the defaults are for all implementations, since application
writers might skip invoking the API unless they are going to set
some flag. But there is indication that some implementations
want to prefer temporary addresses over public addresses, whereas
others will follow the default address selection document and do the
reverse.
So do we make the one bit PREFER_SRC_TMP or PREFER_SRC_PUBLIC?
Will applications that have a preference for either always explicitly state it
by invoking the API?

The psychological benefit of the two flags is that we don't have to choose
the default; we can say that any application which has an explicit preference
should always invoke the API to state that preference.

  Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 25 Mar 2003 20:55:13 +0200

> > And if the application specifies both "X" and "not X"? 

Exactly. The kernel needs to test this and return an error ==> bloat.

> So do we make the one bit PREFER_SRC_TMP or PREFER_SRC_PUBLIC?

PUBLIC is the obvious default since that is the current expected
behaviour, although the system administrator might decide to change it.

> Will applications that have a preference for either always explicitly state it

They should. The system default might be configurable by the admin so
the apps can't rely on a particular default.

> should always invoke the API to state that preference.

I don't follow. This is true regardless of whether there is one bit or
two. If an application doesn't care, it doesn't invoke the API at all.

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 Mar 2003 09:29:55 +0100 (CET)

> two. If an application doesn't care, it doesn't invoke the API at all.

My point is that you have a socket option to say "FOO" it is very easy for
app writers to assume that "FOO" isn't set by default; that is the case
for all the existing socket options I can think of.

But in this case the system admin is free to change the default.
Thus how do we make this departure from existing practise clear
to the app programmers? They need to turn off "FOO" is they don't
want it since "FOO" might be the default set my the system admin.

Having socket options that you use to set "FOO" or "NOTFOO"
with no hard default I think makes the departure from existing 
practise more clear.

  Erik