Subject: comments on address selection API

From: Sebastien Roy <[email-masked]>
Date: Tue, 22 Jul 2003 21:36:16 -0400

I have some comments on draft-chakrabarti-ipv6-addrselect-api-01.txt.

1. I'm puzzled by the following IPV6_SRC_PREFERENCES settings:

	IPV6_PREFER_SRC_TUNNEL  /* Prefer tunnel interface  as source  */
	IPV6_PREFER_SRC_NATIVE   /* Prefer native IPv6 source  addr */
	IPV6_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope source */
	IPV6_PREFER_SRC_LOWERSCOPE  /* Prefer less than largest scope */

   What do they mean?  It would be nice if there was a description of
   what source address selection rules they affect and how. One point of
   confusion is that there are no source address selection rules that
   have to do with tunnel vs. native addresses, so I can't really guess
   what was intended here.  The second pair, largest vs. lower, are
   confusing.  There is a "Prefer appropriate scope" source address
   selection rule, but neither of these constants represents the
   "default" behavior for that rule.  What was intended here?  I'm
   guessing that this was an error and that these four settings shouldn't
   exist...

2. Some of the AI_ flags have strange names.  Here's what I mean:

   AI_PREFER_SRC_LARGESTSCOPE
   I'm guessing you meant AI_PREFER_DST_LARGESTSCOPE since this settings
   presumably alters the "Prefer smaller scope" destination address
   selection rule...?

   AI_PREFER_SRC_LOWERSCOPE
   Same.  Also, why is this "LOWER" instead of "LOWEST"?  Its buddy is
   "LARGEST".

   AI_PREFER_SRC_TUNNEL
   I'm also guessing that you mean AI_PREFER_DST_TUNNEL, as this setting
   presumably alters the "Prefer native transport" destination address
   selection rule...?

   AI_PREFER_SRC_NATIVE
   Same.

3. There is no explicit text on what an implementation should do if they
   don't support Mobile IPv6 or CGA addresses.  Should they define these
   socket option constants and ignore them if set, or should they return
   EINVAL if set?  Same question for the AI_* flags for getaddrinfo()...
   My inclination would be to define them, but ignore them when set on
   such implementations.

Thanks,
-Seb

--------------------------------------------------------------------
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, 23 Jul 2003 09:28:27 +0200 (CEST)

>    My inclination would be to define them, but ignore them when set on

"Ignore" seems to be the right thing.
The motivation is to be able to write software (such as a DNS stub resolver)
where using the CoA as source is better for performance when the node is
indeed a mobile IP node away from home. But when this is not the case you
don't want to see a failure or require that the application only set 
PREFER_SRC_COA when it knows it is running on a mobile node away from home.

Makes sense to make that clear in the spec.

  Erik

---

From: Sebastien Roy <[email-masked]>
Date: Wed, 30 Jul 2003 13:27:26 -0400

I have an additional comment on the draft relating to the four new
AI_PREFER_* getaddrinfo() flags (new in version 1 of the draft).

	AI_PREFER_SRC_LARGESTSCOPE  /* Prefer largest scope */
	AI_PREFER_SRC_LOWERSCOPE	  /* Prefer lower than largest scope */
	AI_PREFER_SRC_TUNNEL	  /* Prefer address of tunnel interface */
	AI_PREFER_SRC_NATIVE	  /* Prefer native IPv6 address */

I don't know if this is the right place to be defining these
preferences.  By defining these flags, wouldn't we be suggesting that
the control of these two destination address selection rules (rules 7
and 8) belongs to application developers?  Preferring larger scope
destinations rather than smaller scope destinations seems like a
situational run-time preference, and same with preferring tunnel
output interfaces over native interfaces.  My initial though when I
saw these preferences was that we should be giving individuals running
applications the control, not individuals writing applications.

You could argue that applications could set these flags based on
additional input from the environment, but that seems ugly since every
application would need to be changed.  Otherwise some applications
would behave differently than others based on how or if they handle
this environmental input.  Instead, environmental input could be
handled directly by the library that implements the address ordering
mechanism.  I'm deliberatly not using the term "environment variable"
to stay OS neutral and to not directly suggest one method of
implementation in this context.

-Seb

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 Jul 2003 20:37:57 +0700

Date:        Wed, 30 Jul 2003 13:27:26 -0400
    From:        Sebastien Roy <[email-masked]>
    Message-ID:  <[email-masked]>

  | My initial though when I
  | saw these preferences was that we should be giving individuals running
  | applications the control, not individuals writing applications.

There's no way to avoid that.   The user (individual running the application)
can only ever express as much control as the application allows - burying
things in libraries only makes it more difficult for the application to
override, it doesn't prevent it (even to the extent of the application
ignoring the standard library routines, and doing things its own way if
the libraries insist on doing things the application doesn't like).

You seem to want to legislate in favour of intelligently written
applications that do things in wise and meaningful fashions - that
doesn't work at this level, all that can ever be done is to attempt
to get the users to prefer to use applications that work in ways
that make sense to them.

Allowing applications to set flags to control the address choices from
the library routines seems sensible to me - this doesn't mean that this
needs to be the only input to the address selection choice that an
implementation provides.

And yes, usually you do want the application to pick what is the best
default for it - "environmental controls" are usually much too crude
a control for this purpose - that is, it isn't the case that every
application should behave the same, for connections from host A to host B
for some applications one address choice is better than another, for
other applications the answer comes out exactly the other way around.

When I, the user, know better, I'm going to want a way to override the
application's preference - and if the application doesn't provide that,
I'll either fix it, if I can, or perhaps work around  it (add new names
in the DNS that only provide a subset of addresses...) or if none of
those is possible, just avoid using the application concerned.

kre