Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt

From: Francis Dupont <[email-masked]>
Date: Mon, 01 Jul 2002 10:20:30 +0200

In my previous mail I wrote:

      Rule 8: Use longest matching prefix. 
      If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 
      Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 
      prefer SB. 
   
   => this rule has no meaning when CommonPrefixLen is not bound to 0..64.
   
=> I've changed a bit my mind about this: in fact the 64 boundary works
only for IPv6 addresses, not for IPv4 addresses where the right
boundary is between 96 and 128 (exclusive). So the right implementation
of the CommonPrefixLen() function must include a sound maximal value for
each prefix of the policy table.

   (BTW are there common cases where D8 is not overruled by D6 for
   not twisted policy tables?)
   
=> multicasts... I still wonder if the D8 is useful.

[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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 02 Jul 2002 00:51:57 +0900

>>>>> On Sun, 30 Jun 2002 19:28:59 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

>    Rule 7: Prefer public addresses. 
>    If SA is a public address and SB is a temporary address, then prefer 
>    SA. Similarly, if SB is a public address and SA is a temporary 
>    address, then prefer SB. 

> => even if I believe this is the right choice I don't know there is
> a strong consensus.

>    An implementation MUST support a per-connection configuration 
>    mechanism (for example, a socket option) to reverse the sense of 
>    this preference and prefer temporary addresses over public 
>    addresses. 

> => again this is inadequate and stresses the previous issue.
> This MUST must not move to the standard track part.
> Note my environment suggestion works well for this case because
> daemons (which want the public address) run with another userID
> than applications of physical users (which want a temporary address).
> We really need soemthing tunable from the outside, not a new switch
> in every applications...

I tend to agree.  I previously said a per-node switch is better for
privacy purposes (though some disagreed), but more accurately, a
per-user switch is better.

> PS: about KAME implementation, what about:

(We may change the place to discuss the implementation-specific
issues, but I'll reply to them here for now.)

>  - move the policy table rules just after the common sense rules

We can but I'm not sure if it is appropriate to do so before making a
consensus.

>  - put the policy table in a per-process space (u-area)?

It's a good idea.  However, I don't know a good API for this.  As you
mentioned in the public vs temporary case, a socket option is not
suitable.

>  - limit in6_matchlen() to 64 for address selection.

I agree that full-128bit comparison does usually not make much sense,
but I'm not sure if the assumption of the fixed prefix length is a
good idea...

					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: Alain Durand <[email-masked]>
Date: Mon, 01 Jul 2002 09:17:16 -0700

> per-user switch is better.

The same user may want to use privacy when browsing
the wild wild web and application robustness when
accessing data on a file server.
I like Francis suggestion of an environment switch.

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Jul 2002 13:41:51 -0400

> accessing data on a file server.

indeed, and that's assuming the user actually understands
the implications of the privacy vs. robustness decision -
which seems like a big stretch. 

the only party who is really in a position to make a good
choice for address selection policy is the application writer.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Jul 2002 13:51:37 -0400

> but I'm not sure if the assumption of the fixed prefix length is a

I'm reasonably certain it's a bad idea - I fully expect that some sites
will need to have prefixes > 64 bits, either because the ISP didn't
follow the rules or they really need to subnet something hanging
off a /64.  

I'm starting to think that rather than having all of these (address prefix 
and length) constants wired in to code, there might need to be a couple of
configurable tables somewhere:

one table might map prefixes onto address classes

another table might be a matrix of source vs. destination address 
classes, mapping those to preference values for each of several 
conditions to be supplied by the app (does the app prefer privacy, 
address stability, proximity, global addresses, or what?)

then the app would call a sort_addresses routine that ordered the
various possible (source, destination) address pairs according to 
which ones seemed to best fit that app's requirements.

but this is a huge mess.  even if we might end up needing something like 
this, we really ought to work on reducing the number of addresses 
that an app is expected to deal with.
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 03 Jul 2002 01:42:05 +0900

>>>>> On Mon, 01 Jul 2002 13:51:37 -0400, 
>>>>> Keith Moore <[email-masked]> said:

> follow the rules or they really need to subnet something hanging

Though I really hope the former will never be the case, I'm basically
on the same side as yours in the sense that assuming a fixed prefix
length for all addresses is a bad idea.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 03 Jul 2002 01:34:03 +0900

>>>>> On Mon, 01 Jul 2002 09:17:16 -0700, 
>>>>> Alain Durand <[email-masked]> said:

> I like Francis suggestion of an environment switch.

But in my understanding the environment switch can be inherited to
"descendents" (e.g. child processes).  (If the understanding of the
switch on this point is the same between us) so the switch has
basically the same defect as the per-node switch; we cannot perfectly
prevent a user from creating an "environment" from which a user's
application may suffer.  I don't get why you like the environment
switch while you (probably) dislike the per-node switch...

Anyway...I still believe if I were a privacy conscious user (who needs
a RFC3041-like privacy mechanism) I would rather choose the possible
pitfalls than the leakage of privacy.  However, I know some other guys
disagree on this view and I actually do not have a strong opinion on
the switch, I'll not insist on this point.

					JINMEI, Tatuya

---

From: Shannon -jj Behrens <[email-masked]>
Date: Tue, 2 Jul 2002 10:30:24 -0700

> switch while you (probably) dislike the per-node switch...

A per-node switch probably doesn't make sense because it would have an affect
on both the "server-like" applications as well as the "client-like" 
applications.  However, an environmental switch could make more sense because
each user could throw that environmental setting into their .shellrc file
and be assured that no application that they launch from that shell would 
ever use a non-temporary address by default.  I.e., the inheritance is a 
feature.

> the switch, I'll not insist on this point.

Similarly, I'm just clarifying the argument, without necessarily trying to
express an opinion.

Best Regards,
-jj

-- 
Real programmers don't draw flowcharts.  Flowcharts are, after all, the
illiterate's form of documentation.  Cavemen drew flowcharts; look how
much good it did them.
--------------------------------------------------------------------
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: [email-masked]
Date: Wed, 03 Jul 2002 02:37:01 +0900

>ever use a non-temporary address by default.  I.e., the inheritance is a 

	maybe a bit off-topic of the discussion, but i think this thread
	is assuming too much about underlying operating system - that
	they are unix-ish design.  default-addr-select is a protocol document,
	as far as i understand.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 03 Jul 2002 10:16:02 +0900

>>>>> On Wed, 03 Jul 2002 02:37:01 +0900, 
>>>>> [email-masked] said:

> 	they are unix-ish design.

That's because I wrote "*e.g.* child processes", but perhaps I was not
clear enough to distinguish particular implementation from general
issues.  Thanks for the clarification (though I think examples from
the real world help the discussion if we are clear on the limitation).

					JINMEI, Tatuya

---

From: Robert Elz <[email-masked]>
Date: Wed, 03 Jul 2002 10:29:01 +0700

Date:        Wed, 03 Jul 2002 02:37:01 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	maybe a bit off-topic of the discussion, but i think this thread
  | 	is assuming too much about underlying operating system - that
  | 	they are unix-ish design.  default-addr-select is a protocol document,
  | 	as far as i understand.

Not off topic at all, it was a point that needed to be made.

The doc says that applications get to override the default, that's all
that is needed.   The mechanism by which the application decides it should
make that decision (and whether it occurs in the app code itself, or in
some provided library routine) are way beyond the scope here.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 00:43:38 -0400

> some provided library routine) are way beyond the scope here.

I don't think this is way beyond the scope here at all - this is 
fundamentally an API issue, and it seems like it would actually be 
useful and appropriate to talk about it in those terms.  Granted 
there are multiple APIs in use.  But the point is that either
having different implementations of the same API do the address 
selection/ordering in different ways, or having new implementations 
of an API do it differently than old versions, will degrade 
interoperability.

Keith

---

From: Robert Elz <[email-masked]>
Date: Wed, 03 Jul 2002 16:00:05 +0700

Date:        Wed, 03 Jul 2002 00:43:38 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't think this is way beyond the scope here at all - this is 
  | fundamentally an API issue,

Which makes it beyond the scope of the address selection doc.   If you
want to suggest that something about it be added to one of the API docs,
then go ahead (and good luck).

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 09:56:44 -0400

> Which makes it beyond the scope of the address selection doc.   

The *entire* address selection doc is about API issues.

Keith

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Jul 2002 16:32:29 +0700

Date:        Wed, 03 Jul 2002 09:56:44 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | The *entire* address selection doc is about API issues.

Which doc are you reading?   Maybe we're talking about different ones.
The draft-ietf-ipv6-default-addr-select-08.txt that I am looking at
has nothing to do with APIs at all.

Or perhaps we have a different definition of what is an API?   To me,
that's the method by which the application interfaces with the stack/
kernel/library/...   That is, it contains function definitions, data
types, and all of that stuff (just as the API docs do, with specs on
data types for args for various system calls, etc).

The addr-select doc I'm reading contains protocol specification - that
is, if the destination address is X, and A, B C are possible source
addresses, which one should be used.  (And of also of course, when there
are multiple destination addresses, ...)  That's not API - it doesn't say
a word about where in the stack all of this should be done, nor does
it say anything about the mechanisms that might be used to influence
the choices, where such influence is possible.

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Jul 2002 10:08:46 -0400

> the choices, where such influence is possible.

One reason I say that this is an API issue is that (at least the destination
address selection stuff) is really a mechanism for encouraging or defaulting
the binding of the destination address to a socket.  But the application is
going to need to be able to explictly choose a specific destination address 
in any case, so this is just a way to help the application choose the "right" 
answer.

Another reason I say this is an API issue is that a good choice of 
destination address (and therefore source address) cannot be made 
without explicit knowledge of the application's requirements.
One application wishes to maximize privacy by using temporary addresses,
another wishes to maximize address stability, another needs global
addresses to maximize its potential for access by/to peers.

Another reason I say that this is an API issue is that we really need
all platforms that currently provide the same API to implement this
address selection procedure in such a way that they still provide the
same API- e.g. we don't need one socket-based system doing it via
a new version of gethostbyname() or whatever it is this week, and
and another socket-based system trying to do it via a new version 
of bind(), and another one writing an explicit select_dest_address()
routine.

This cannot be a protocol issue except in a few specific cases, because 
there are very few (approaching zero) protocols that explicitly and 
exhaustively define the mechanisms by which addresses are advertised to 
potential peers.   e.g. We cannot assume that all addresses in all (or even 
most) protocols are obtained exclusively through DNS.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sat, 06 Jul 2002 16:34:35 +0700

Date:        Fri, 05 Jul 2002 10:08:46 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | One reason I say that this is an API issue is that (at least the destination
  | address selection stuff) is really a mechanism for encouraging or defaulting
  | the binding of the destination address to a socket.

That is what it is, but that isn't API.

  | But the application is going to need to be able to explictly choose a
  | specific destination address in any case,

I'm not sure I agree with that in all cases, an application might want
to choose - for the vast majority of applications, anything that works
will do - regardless of which is best.

  | so this is just a way to help the application choose the "right" 
  | answer.

Yes, but affecting (or even being) the application doesn't make it API.

  | Another reason I say this is an API issue is that a good choice of 
  | destination address (and therefore source address) cannot be made 
  | without explicit knowledge of the application's requirements.

Sure, it can affect the application, and be affected by it, so an API is
needed - but what's in this draft isn't that.

  | Another reason I say that this is an API issue is that we really need
  | all platforms that currently provide the same API to implement this

Here you're saying that there needs to be a standard API, and I don't
disagree, and I doubt anyone does (or not anyone who agrees with having
the API docs) - but this doc isn't that API.

  | This cannot be a protocol issue except in a few specific cases, because 
  | there are very few (approaching zero) protocols that explicitly and 
  | exhaustively define the mechanisms by which addresses are advertised to 
  | potential peers.   e.g. We cannot assume that all addresses in all (or even 
  | most) protocols are obtained exclusively through DNS.

It isn't a protocol issue, in the sense that things will break if you
don't pick the "right" addresses, no more than there is a protocol issue
in the sense that things will break if you don't do a random delay before
sending a RS packet - but doing these kinds of things properly improves
the overall operation of the net, using the right addresses can get
packets though better.   It may be true now that nothing much in this
doc will actually achieve that, but if we know which addresses will be
selected by apps, we can engineer things so those work best.

kre

---

From: Keith Moore <[email-masked]>
Date: Sat, 06 Jul 2002 09:46:24 -0400

kre,

I agree of course that the document isn't trying to define an API
in any kind of detail, nor (mostly) does it describe what an API 
needs to do.  I'm arguing that it *should* be written in those terms, 
because there's no right address selection algorithm that works 
for all cases, and any assumptions about what constitues the 
majority of cases are fairly dubious.

Also, the big issue about e.g. privacy/temporary addresses vs.
stable addresses is best looked at as a backward compatibility
issue - new or revised apps can be encouraged to specify which 
they want in any case, but we can't change existing binaries. 

> selected by apps, we can engineer things so those work best.

I don't think it's reasonable to expect apps in general to be predictable 
in that way - the needs of apps vary from one app to another and the behavior 
of a typical app (if there is such a thing) will vary over time and from one
place to another.

Or to put it another way, if you try to engineer the network by first
defining how apps behave w.r.t address selection and then basing other
design/configuration decisions on that, you end up making the network
design/configuration favor that kind of apps (and penalize others) - 
without any regard for whether this is a reasonable or desirable
compromise.  e.g. the inability of the network to support distributed
apps, or apps that run for a long time, or apps that need privacy
(to give three examples of potential outcomes) becomes an 'unintended 
consequence'.

Keith