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

From: "Dave Thaler" <[email-masked]>
Date: Tue, 18 Mar 2003 15:01:08 -0800

> From: Erik Nordmark [mailto:[email-masked]]
>
> > 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.
> 
> 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.

The spec doesn't currently discuss this issue, but this is what I meant
by
"confuses the issue".  It currently implies that setting the flag to
PREFER_FOO will undo your orthogonal PREFER_BAR, since it implies that
setting PREFER_NOTFOO will undo a previous PREFER_FOO.
This is actually another argument for splitting the option into 3
separate
options.  Then it's clear that a set overrides any previous set, and 
doesn't interfere with the other 2 orthogonal options.
It also provides a reasonable meaning for the value 0.

As presently worded, it's unclear what the meaning of value 0 is.
 
> > 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.
> 
> 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.

Right.

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

Agree.  

My personal vote is that it's still worthwhile.  Let's see what
others say.

-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: Wed, 19 Mar 2003 00:09:54 +0100 (CET)

One other thing I forgot is that, since we need to pass flags
to getaddrinfo as well as the TCP/IP stack, there is a need to fit
all the flags (whether there are only prefer or prefer+require flags) into
the flag name space for getaddrinfo.

This has some implication on the number of flags one can invent.

  Erik

---

From: "Jeff W. Boote" <[email-masked]>
Date: Wed, 19 Mar 2003 08:47:42 -0700

> This has some implication on the number of flags one can invent.

This is the part of the draft that has me concerned.

First - I do think the PREFER_LARGEST_SCOPE is needed for a large collection of
applications. (With all the noise about site-local in this group, I wonder if a
REQUIRE_GLOBAL_SCOPE wouldn't be a good idea...)

Second - I wonder how workable it is to have flags for each "preference" type.
How likely is it that additional address "types" will come along such that these
flags need to be augmented? Will the lag time for adding new flags to working
systems make it overly difficult for the applications that need those new flags
to be developed?

That said: I agree with the direction taken in this draft. It makes the easy
things easy.

However, it does not make the hard things possible.

As an application programmer, I'm not sure this will really give me enough
control when/if I need it. What I *think* I would like to see, in addition to
this sockopt, is an interface similar to getaddrinfo - but for address pairs,
not just for destination addresses. Something that lets me specify both the
source and the destination characteristics that I care about - and have it
return a linked list of all the src/dst address combinations that are possible
given those constraints. Sorted in the same order that the system would have
used to choose. This would of course include flags such as described in this
draft. (I'm not convinced this much control is really needed yet...)

Another possible use for an interface like this is to make it possible to only
use "prefer" variants of the flags mentioned in the draft. Then if the
application really needs "require" it can examine the address combinations
directly.

So, I am in support of this draft because I think it goes in the right
direction. I just think that an additional draft may be needed down the road a
bit...

jeff

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Mar 2003 19:22:26 +0100 (CET)

> First - I do think the PREFER_LARGEST_SCOPE is needed for a large collection
> of applications. (With all the noise about site-local in this group, I
> wonder if a REQUIRE_GLOBAL_SCOPE wouldn't be a good idea...)

Or make PREFER_LARGEST_SCOPE the default? But that isn't the subject of
this draft ...

> return a linked list of all the src/dst address combinations that are
> possible given those constraints. Sorted in the same order that the system
> would have used to choose. This would of course include flags such as
> described in this draft. (I'm not convinced this much control is really
> needed yet...)

I don't quite understand this. You can only express properties about
the local addresses (you can't tell from the DNS whether the address you
looked up has any particular property).

Having said that, being able to do all of address selection in getaddrinfo
and have it return a list of src/dst pairs would make certain things simpler.
But I think that is orthogonal to adding the preferences and/or requirements
on local address types.

  Erik

---

From: "Jeff W. Boote" <[email-masked]>
Date: Wed, 19 Mar 2003 16:29:57 -0700

> looked up has any particular property).

The destination portion would include the same types of things you can specify
about a destination address request to getaddrinfo using "hints". (For example,
this would allow you to only accept IPv6 destination addresses, and that
definitely has source selection ramifications.)
 
> But I think that is orthogonal to adding the preferences and/or requirements

Agreed. That is why I suggested this as mostly an additional possibility to
provide more control to the application.

jeff