Richard,
I reviewed your "Default Address Selection for IPv6" draft.
I have some concerns/questions on the algorithms and what
the document requires implementations to support. Details
below.
Ken
Page 2, Section 1 last paragraph:
"The rules specified in this document MUST NOT be construed
to override an application or upper-layer's explicit choice
of destination or source address."
Is an implementation allowed to sanity check an application's
source/destination address choices based on criteria like
those defined in section 3 and reject such selections as
invalid? I believe this requirement leaves the option open,
but wanted to be sure.
Page 3, Section 2
The discussion of where different parts of this spec map
into the API is very helpful.
If I understand this correctly, destination address
selection is done during the call to getaddrinfo or
getipnodebyname. The destination address selection
algorithm uses the source address selection algorithm.
An important parameter to source address selection is
the interface. Given what invokes destination address
selection, the interface is not known.
Later on, an implementation is likely to invoke source
address selection again as the result of a connect or sendto
call. This time the interface is known. It was either
specified by the application or determined through a
routing table lookup. The previously chosen destination
address could easily be wrong for the interface.
This all leads to the concern that destination address
selection goes to great lengths to get the best address
but is hobbled by missing prior knowledge of the interface.
Page 5, Section 2.4
"IPv6 implementations SHOULD support configurable address
selection via a mechanism at least as powerful as the policy
tables defined here."
I do not understand why this is a "SHOULD" requirement today.
These tables are very interesting and I can see their power
and use, but they seem to add little practical value without
a management infrastructure capable of downloading a common
set of rules to all nodes in a site. I believe making this
table configurable should be defined as optional. Also, support
for the Label and MatchSrcLabel mechanisms in particular should
be optional.
Page 5, Section 2.4
The default policy table treats IPv4 Mapped addresses that
fall within the "autonet" and rfc 1918's private address
ranges as special, with a higher priority than the other
IPv4 mapped addresses. Is there a similar mechanism in
current IPv4 implementations? If not, could this additional
feature possibly change the behavior of applications that
were ported to IPv6 in unexpected ways?
Page 6, Section 3
Should an additional restriction like the following be
added to the candidate set of source addresses?
"For IPv4 Mapped destination addresses, the set of
candidate source addresses must only include IPv4 Mapped
addresses. For any other destination address, the set
of candidate source addresses MUST NOT include IPv4
Mapped addresses."
Should use of the loopback destination restrict the source
address to be loopback also?
Page 6, Section 4
"Rule 2, Prefer Matching Label" seems to be given too much
weight over other criteria. For example, if the destination
is a 6to4 addresses, this rule will cause a deprecated
6to4 address to be chosen as the source over a preferred
global address. If your 6to4 address is deprecated,
chances are its time to stop using it. Your site is probably
switching over to global addresses and the 6to4 address is
going away.
Page 7, Section 4
"Rule 3, Prefer appropriate scope" is complex and aught
to be broken into two rules with rule 4 in the middle
like:
Rule 3a: Avoid insufficient scope for destination.
(i.e., avoid Scope Source < Scope Dest)
Rule 4: Avoid deprecated addresses.
Rule 3b: Prefer closest scope.
If both SA and SB are of sufficient scope, choose
the one with lower scope. If both SA abd SB are
if insufficient scope, choose the one with higher
scope.
Page 7, Section 4
"Rule 8 MAY be superceded if the implementation has other
means of choosing among source addresses. For example, if
the implementation somehow knows which source address will
result in the "best" communications performance."
I think limiting implementation specific tests to
supercede only Rule 8 is overly restrictive. We cannot
predict how useful future implementation specific tests
may be for improving efficiency or avoiding connectivity
problems. Implementations should be allowed to inject their
own tests anywhere in the list of rules.
Page 7, Section 4
"The pair-wise comparison consists of eight rules, which
MUST be applied in order."
Is it mandatory to implement all these rules? I don't
see why every implementation has to implement longest
matching prefix for example. Could you break the list
down and identify which rules MUST, SHOULD, and MAY be
implemented?
The requirement of order seems overly restrictive too.
A brief list of the source address selection rules
(with my rule 3 suggestion) gives:
Rule 1: Prefer same address
Rule 2: Prefer matching label
Rule 3a: Avoid insufficient scope
Rule 4: Avoid deprecated addresses
Rule 3b: Prefer lower scope
Rule 5: Prefer home address
Rule 6: Prefer outgoing interface
Rule 7: Prefer anonymous addresses
Rule 8: Use longest matching prefix
Rule X: Implementation defined test
I tend to divide these rules into the following groups:
A) Rule 1. This is an important diagnostic feature that
makes sense where it is.
B) Rules 3a, 4, and 5. There is a good chance
communication will fail if any of these rules
are broken.
C) Rules 2, 3b, 6, 7, 8, and X seem to exist mostly
for efficiency or privacy enhancements.
I don't think we know enough to predict which of these
rules will prove more important to customers. For example,
some customers may get annoyed that their system selected
a 6to4 address over a global anonymous address simply
because the destination was a 6to4 address.
Would it make sense to specify groups of rules, where one
group MUST be applied before the other, then RECOMMEND the
order of rules within each group where order really isn't
important to interoperability?
Page 8, Section 5
It seems possible that some destination addresses could
end up with no candidate source addresses. Should a rule
be added at the top to avoid destinations with no candidate
source address?
Page 8, Section 5
"The pair-wise comparison of destination addresses consists
of four rules, which MUST be applied in order."
A summary of the rules is:
Rule 1: Prefer destination with matching source
Rule 2: Prefer destination with higher precedence
Rule 3: Use longest matching prefix
Rule 4: Use order returned by name service
Same questions as above for source address selection:
Is it mandatory to implement all these rules?
Is the order really critical for interoperability?
Please be more specific on what MUST, SHOULD, and
MAY be done.
Page 8, Section 5
"The third and fourth rules MAY be superceded if the
implementation has other means of sorting destination
addresses."
Same question as above for source address selection.
Why limit this just to the third and fourth rules?
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
