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

From: "Richard Draves" <[email-masked]>
Date: Thu, 20 Jun 2002 16:22:26 -0700

This revision primarily has editorial changes & clarifications in
response to IESG comments. There are also two substantive changes that
require WG review:

1. I added definitions and requirements for IPv4-mapped and
IPv4-translatable addresses, in support of SIIT. The key paragraph is

   On IPv6-only nodes that support SIIT [13, especially section 5], if 
   the destination address is an IPv4-mapped address then the candidate 
   set MUST contain only IPv4-translatable addresses. If the 
   destination address is not an IPv4-mapped address, then the 
   candidate set MUST NOT contain IPv4-translatable addresses. 

I believe this change has already has WG consensus, based on discussion
on the list late last year and at Salt Lake City. I just forgot to
incorporate it earlier.

2. I changed the requirement for an API to control temporary vs public
address usage, from "may" to "MUST". The new text reads

   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.

The default is still to use public addresses not temporary addresses,
although implementations MAY reverse this default if they want to
emphasize privacy over application compatibility.

Thanks,
Rich

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Thu, 20 Jun 2002 20:07:33 -0400

> emphasize privacy over application compatibility.

I don't think it's reasonable to allow host implementations to reverse
this default - this will break apps.

the default should always be to use public addresses.
apps that can use temp addresses SHOULD ask for them.

Keith

---

From: Alain Durand <[email-masked]>
Date: Thu, 20 Jun 2002 18:49:45 -0700

> emphasize privacy over application compatibility.

I'm wondering why having an escape clause that only apply
to that particular rule.

	- Alain.

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Jun 2002 14:47:10 +0700

Date:        Thu, 20 Jun 2002 20:07:33 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't think it's reasonable to allow host implementations to reverse
  | this default - this will break apps.

This cannot possibly be true, as all addresses are temporary in the
current environment (all globals anyway).  The only difference is in
their expected duration.

So, to work at all, all apps always need to work with temporary addresses,
as that's all they're ever going to get.

I like the current default of preferring "normal" addresses over 3041 addrs,
and I certainly see no problem with an application toggle to change that.
But nor do I see any problem with a per system toggle.   Eg: on my laptop,
which is rarely turned on for more than 24 hours, hence no app survives
longer than that, a 3041 address (default timers) is exactly as stable as
a global address, and if I wanted, I see no reason that I shouldn't make
all apps default to using them (without having to recompile every one).

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 10:45:20 -0400

> current environment (all globals anyway).  The only difference is in

true, it might be more precise to talk about the expected duration of
addresses; all addresses are at least potentially 'temporary' in some 
sense.  however we're using the term 'temporary addresses' as it's 
used in RFC 3041, rather than in the more general sense of the term
'temporary'
 
> as that's all they're ever going to get.

that's rather unrealistic; the current architecture is nowhere close to 
supporting the ability of apps to survive arbitrary address changes.

> all apps default to using them (without having to recompile every one).

I have less problem with a per-system toggle that the user can set
than with allowing the vendor to change the default.  but the vast majority 
of users won't understand the implications of such a toggle, and 
implementors of apps for which temporary addresses are appropriate will
find it easy to enable them.  by the time your laptop's OS is upgraded
to support temporary addresses, chances are that the apps will support
them also... so I suspect that the main effect of a user-settable
per-system toggle would be to cause more apps to break with little or
no improvement in privacy.

that and I think the SHOULD clause already allows vendors to change the 
default behavior (or to allow users to do so) when they fully understand 
the implications of that behavior.  so the draft does not prohibit a 
vendor from putting such a toggle on your laptop OS, just as long as 
they explain the implicatoins of that behavior to you.

however I think it would generally be a foolish thing for vendors to do
(at least commercial vendors) as it would increase their support costs
while providing little additional functionality to users. 

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 25 Jun 2002 11:02:15 -0400

Hi All,

The Default Address Selection draft is currently with IESG, waiting
for approval for PS.  There was clear consensus in the WG to send this
document to the IESG, we held a WG last call, and it has since been 
updated based on IESG feedback.

I have followed this discussion, and it is clear that one or two people
object to the changes made based on IESG review.  However, I don't see 
any WG consensus that there are problems with this document that should 
block its publication as a PS.

Thoughts?

Margaret

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2002 11:45:36 -0400

> block its publication as a PS.

I want to reread the current version of the document in its entirety 
(haven't had time to do that yet) before stating a specific opinion 
on this document. 

I continue to have strong reservations about the use of limited-scope 
addresses; and about the expectation that hosts and applications can 
make reasonable choices from a set of addresses where some of those 
addresses will not work efficiently, reliably or at all.   Given that
such choices are forced on applications and hosts, I also have 
reservations about a "one size fits all" set of rules for address
selection, since it seems to me that different applications have 
different needs which conflict (e.g. some need address stability more 
than address portability, some vice versa)

Keith

---

From: Bob Hinden <[email-masked]>
Date: Tue, 25 Jun 2002 14:56:41 -0700

Keith,

>than address portability, some vice versa)

To clarify this issue, is your main objection is in regard to the IESG 
requested text?  Specifically:

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

Your argument is that this choice can only be made by applications and 
should not be be made on a more granular basis (e.g., host, interface, 
etc.).  Are you proposing that this text be removed?

Other views on this?

Bob

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2002 18:20:57 -0400

> etc.).  Are you proposing that this text be removed?

No, I'm not proposing that the text be removed (though the wording seems
awkward to me).  Actually I'm not sure what changes to propose yet -
I am still trying to understand all the implications of limited-scope
addresses, limited-duration addresses, and expecting apps or hosts to
do address selection.   At this point I'm guessing that I would recommend
slight tweaks to the algorithm itself, along with a strong statement
as to the (narrowness of the) applicability of the algorithm and several
of the types of addresses.  

But trying to address the question in dozens of short emails that are
quick responses to things that other people wrote, really doesn't seem
like an effective way to understand or argue for what is needed.  So 
my earlier "strong reservations" statement was mainly intended to avoid 
my silence being taken as assent to the document as it stands.  

Keith

p.s. to Bob: I don't know whether this will reach you directly, as your 
mailer has been bouncing mail from me, claiming that the host that it's 
sent from doesn't have a domain name...which of course it does.  But maybe
it will reach you via the list.
--------------------------------------------------------------------
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: Wed, 26 Jun 2002 10:40:04 -0700

> Bob

There has been a very long discussion on the fate of Site Local addresses
in the wg. There are still two opposite views of what to do about them:

a) Do not require apps to support multi-sited nodes now, but
     keep the address selection rules in place.
     This means that in the future, if SL are available,
     they will be used by ALL applications by default.

b)  Do not require apps to support multi-sited nodes now, and
       remove the address selection rule that deal with scoped addresses.
       This means that in the future, if SL are available,
       they will not be used by default, but only by applications that 
request them.

  Keith has promised a draft to explain the trade-off between those two 
approaches,
I think we should not advance draft-ietf-ipv6-default-addr-select-08.txt
until there is a clear resolution on this question.

	- Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 28 Jun 2002 00:41:10 -0400

Hi Alain,

>in the wg. There are still two opposite views of what to do about them:

Most of that discussion focused on whether or not to remove site-local
addresses from the architecture, not on this draft.  And, we have
already determined that there was no consensus to remove them from
the architecture.  So, I don't know why it would make sense to remove
them from this draft.

>     they will be used by ALL applications by default.

An application will only use a site-local destination addresses if it
is returned in the DNS and/or typed locally.  So, it can't happen
without the administrator or user doing something to make it happen.

>       they will not be used by default, but only by applications that request them.

I don't understand how this is achieved by removing the default 
selection rules.  If an application receives a site-local address
from the DNS, how will removing scoped addressing rules from the 
default address selection draft prevent the app from using the site-local
address?  The assumption is that we are dealing with old apps that don't
know anything about IPv6 scoped addressing, so we can't expect the app
to recognize a site-local address and refuse to use it...

>  Keith has promised a draft to explain the trade-off between those two approaches,

Unfortunately, Keith did not submit a draft by the deadline, so there will 
not be a draft before Yokohama.

The Default Address Selection document has been out for months, has
been reviewed several times by the WG, has undergone a WG last call and
has been reviewed by the IESG.  It doesn't seem right to delay this
draft indefinitely waiting for another draft, especially when we haven't
been told about any specific problems that this draft will cause.

If there are specific, technical objections to this draft, please state
them clearly on the mailing list.  It would also be helpful to suggest
specific text changes to the draft.  This will give others and opportunity 
to agree or disagree about whether the issues should block the publication
of this draft.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Jun 2002 12:07:42 +0200

> to agree or disagree about whether the issues should block the publication

I think that at this point we should advance the document as it is. While
I'm sympathetic to Keith's concerns, I think we have needed address selection
*defaults* for a long time, and the default behaviour recommended for SLs
is consistent and logical. 

Defaults are made to be overridden, so the behaviour can always be adjusted.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 08:58:43 -0400

> the architecture.  So, I don't know why it would make sense to remove

they really are separate issues - SL addresses could still exist and
be useful (to a very limited degree - which I think is a reasonable 
assement of their utility anyway) even if they were never selected
when other alternatives were available.  however I think that as long
as they exist at all the address selection document should mention
them for completeness, even if it says to not use them when other
alternatives are available.  otherwise it's confusing.

> without the administrator or user doing something to make it happen.

this is a bit over-simplistic.  apps obtain addresses from other sources
besides DNS and direct input, and the trend is toward more ways to get
addresses rather than fewer.  for instance, a component of a distributed
app that wishes to advertise addresses to peers may get them from the host's
interface table, because this is the most reliable source.  it has no idea 
about which of its host's addresses are advertised in dns or what their scopes 
or lifetimes are, nor even which dns names (if any) are proprely used in
that context for that application.  DNS names are not just names of
hosts any more - they're more commonly used as names of services, and
the mapping of service names onto hosts is not one-to-one but essentially  
arbitrary.  multiple service names may point to an IP address
if multiple services are provided at that IP address, and a single service
name may point to multiple IP addresses if the equivalent service is provided
on each of those hosts.  the idea that a host has "a" DNS name - especially 
for a host that supports multiple applications - is an anachronism.

> not be a draft before Yokohama.

there won't be an internet-draft, but you will have my comments by then.
since I don't expect this draft to be a work item of ipv6 wg anyway
(the issue is wider than ipv6), I don't think it violates procedure to 
consider that input any more than it violates procedure to consider input 
from an email message.

unfortunately, *I* won't be in Yokahama to discuss it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jun 2002 09:19:42 -0400

> Defaults are made to be overridden, so the behaviour can always be adjusted.

I think the appropriate goal should be to provide a consistent API - both
from one platform to another and over time.  The trick is making this API
work despite potential introduction of new address classifications 
(e.g. globally-unique non-publically-routables) or deprecation of old ones
(e.g. non-unique site-locals).  I'll be very surprised if we manage to 
make things work with the existing set of address classifications.
--------------------------------------------------------------------
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: Fri, 28 Jun 2002 17:35:01 -0700

> to agree or disagree about whether the issues should block the 

Margaret,

Publishing this draft will have the effect to stop any further discussion
on who should be responsible to make the choice of SL vs GL
when both are available: is it a kernel function by default or
an well understood application choice.

I'm not sure  about which is best at this point of the discussion.
Keith has arguments that I would like to understand better.
Too bad he couldn't publish a draft before the cut-off date...

In particular, I would like to understand what would be the impact
on applications that are not SL aware the day the site admin decides
to turn on SL by publishing them in the internal view of the DNS...

I'm not a SIP expert, so I may be wrong, but I'm worried about
what will happen to a SIP gateway when all the sudden it will receive
a request originating from Site Local scope for an external address?

I'm concerned that the only API required by the draft is about
reversing the public vs temporary rule and that nothing is require
to enable applications to reverse the other rules.

I will have much less concern if the draft was to be published as BCP,
as it is easy to change if proven wrong. I'm concerned it would be more
difficult to change in the Standard Track.

So I have 2 suggestions:
a) leave the text as it is but publish it as BCP. As there are things we 
do not clearly
      understand now, it would be easier to change later.

b) or reverse rule 2 by default and require an API to enable application
      to request SL when available.

	- Alain.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Jun 2002 17:51:20 +0200

In your previous mail you wrote:

   
   Thoughts?
   
=> I repeat my strong objection: this document should not be
on the standard track. I already explained why and the fact it was
some years and versions ago should be a good proof I was right...
I have some precise concerns about the last draft I'll develop
in another message ASAP.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Jun 2002 18:08:02 +0200

I think that at this point we should advance the document as it is.

=> this could be interpreted as an "in force" way to push the document...

   While I'm sympathetic to Keith's concerns, I think we have needed
  address selection *defaults* for a long time, and the default
  behaviour recommended for SLs is consistent and logical.
   
=> these problems are a direct consequence of the idea to put the
whole stuff in the standard track. I was against this idea not because
I disagree about some details but because of what has happened:
a document reduced to the "MUSTs" had been a PS for years, and
I don't want to imagine how the draft could reach the DS status...

=> to apply this argument you need a specification of an API (with
a consensus), or (easier) just make a part of the document informational:
Richard tries to get a near perfect document for a moving target,
of course he failed. To make a PS which should be obsolete before
to be published is not the proper solution.

Regards

PS: last minute idea: s/informational/BCP/

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Jun 2002 18:17:57 +0200

=> I don't think so: the effect will that the document will become
obsolete at the first well argumented message about the SL vs GL
or any other open questions...

=> this is in fact a bad idea because it makes the value of the draft
relied on a vague API idea, something not well suited for a standard
track document.

=> I've said the same thing for years.
IT IS TIME TO STOP THIS INFERNAL LOOP!

   So I have 2 suggestions:
   
=> MUSTs, i.e., things which must be done this way because all other ways
don't work, can stay in a standard track document. All other things should
be moved to a BCP, and both published ASAP.

=> this is not enough because there are other arguable points. Worse,
I believe there will be new arguable points, as IPv6 is not fixed.

Thanks

---

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

=> I already explained my opinion about this draft (spit it:
MUSTs in standard track, anything else in a BCP), site-locals,
RFC 3041 addresses (cf draft-dupont-ipv6-rfc3041harmful-xx.txt), etc.

   
   
=> this doesn't work as explained in this list.

Comments over draft-ietf-ipv6-default-addr-select-08.txt:

   This document also specifies policy hooks to allow administrative 
   override of the default behavior. For example, using these hooks an 
   administrator can specify a preferred source prefix for use with a 
   destination prefix, or prefer destination addresses with one prefix 
   over addresses with another prefix. These hooks give an 
   administrator flexibility in dealing with some multi-homing and 
   transition scenarios, but they are certainly not a panacea. 

=> this is not enough because some rules should be reversed/modulated too
(for instance the rules S4, S7 and D8). Another problem is you give only
the choice between a global policy and a setsockopt() when we need
on a multi-user box:
 - a global policy/swith
 - a setsockopt() (i.e., explicit and per-application)
 - an environment based way to change a policy or a switch.
IMHO the last option is enough because:
 - the environment is inherited from a default
 - an application can manipulate its own environment.

   For multicast and link-local destination addresses, the set of 
   candidate source addresses MUST only include addresses assigned to 
   interfaces belonging to the same link as the outgoing interface. 
 
   In any case, anycast addresses, multicast addresses, and the 
   unspecified address MUST NOT be included in a candidate set. 

   If an application or upper-layer specifies a source address that is 
   not in the candidate set for the destination, then the network layer 
   MUST treat this as an error.

=> please change the MUST NOT in a SHOULD NOT for the unspecified source
address or RFC 2462 doesn't work (:: is the only fallback when the
candidate source address set is empty).
IMHO some words about tentative addresses (not valid candidates) should
be added.

   Rule 4: Prefer home addresses. 
   If SA is simultaneously a home address and care-of address and SB is 
   not, then prefer SA. Similarly, if SB is simultaneously a home 
   address and care-of address and SA is not, then prefer SB. 
   If SA is just a home address and SB is just a care-of address, then 
   prefer SA. Similarly, if SB is just a home address and SA is just a 
   care-of address, then prefer SB. 

=> this is the right thing only for a common case, i.e., things are
not so simple. For instance if mobile IPv6 is used in a nomadic context
(i.e., the mobile will never move), source home address should be prefered
only for destination addresses in the home site.
The order of the rules S4 and S5 is arguable, and the fact a home address
is not really bound to a physical interface (in fact this is an open
question) doesn't make things easier.

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

=> this is clearly inadequate, at least because this assumes that
all involved applications are upgraded...

   Rule 6: Prefer matching label. 
   If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 
   Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 
   prefer SB. 

=> as this is the only rule I can play with on my KAME box,
I'd like to see what happen if it is moved just after the rule S3?
In fact, I don't know what is the best order for rule S4, S5 and S6.
Same for D4 vs. D5+D6.

   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.

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

   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.

   Rule 4: Prefer home addresses. 
   If Source(DA) is simultaneously a home address and care-of address 
   and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 
   simultaneously a home address and care-of address and Source(DA) is 
   not, then prefer DB. 
   If Source(DA) is just a home address and Source(DB) is just a care-
   of address, then prefer DA. Similarly, if Source(DA) is just a care-
   of address and Source(DB) is just a home address, then prefer DB. 

=> same comment than for S4.

   Rule 8: Prefer smaller scope. 
   If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 
   Scope(DB), then prefer DB. 

=> this is the typical rule I'd like to reverse!
(BTW are there common cases where D8 is not overruled by D6 for
not twisted policy tables?)

   Rule 9: Use longest matching prefix. 
   When DA and DB belong to the same address family (both are IPv6 or 
   both are IPv4): If CommonPrefixLen(DA, Source(DA)) > 
   CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if 
   CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), 
   then prefer DB. 

=> same comment than for S8. Of course, as they are specified today
D9 and S7 have funny interactions.

Regards

PS: about KAME implementation, what about:
 - move the policy table rules just after the common sense rules
 - put the policy table in a per-process space (u-area)?
 - limit in6_matchlen() to 64 for address selection.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------