In your previous mail you wrote:
=> 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.
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.
=> 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.
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...
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
[EMAIL PROTECTED]
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 PROTECTED]
--------------------------------------------------------------------
