> 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.
Thanks for your careful reading & great comments!!!
[fyi - If a discussion develops... I'll be off email next week.]
> 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.
So for example, can an implementation implement a sanity check that prevents
an application from choosing an anycast source address?
Yes. An implementation can prevent an application from choosing a source
address that is not in the candidate set (ie, is completely illegal), but it
can't override an application's choice of an address that is in the
candidate set. I'll clarify this.
> 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.
Also a good point!
I'm trying to allow for flexibility in how this gets implemented. Some
implementations of destination address selection might be done entirely in
user space and have imprecise or out of date or incomplete information about
the source addresses and selection of outgoing interface. Other
implementations might use a system call and have better knowledge. Both
should be allowed.
Another way to say this - suppose you have an user-level destination address
selection implementation (used inside getaddrinfo) that uses user-level
source address selection as a subroutine. And you have kernel-level source
address selection (used inside TCP's connect, for example). The user-level
source address selection could use a bigger or less-precise candidate set
and not have knowledge of the outgoing interface.
I'll try to clarify this issue in the next revision.
> 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.
I'd like to hear more feedback from the WG on this point. Should the
suggestion of configurability be "SHOULD" or "MAY" or "may" or ???
I certainly agree it should be optional, but I'd like to encourage
implementations to be configurable with mechanisms like policy table or
equivalent functionality, because those mechanisms can be used in
multi-homing situations (both sites connected to multiple ISPs and hosts
with multiple interfaces) to control choices of source & destination
address.
> 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?
I'm not suggesting that v4 stacks change how they do source address
selection. If you have a v4-only application, it shouldn't see any changes
in source address selection or the address order from gethostbyname as a
consequence of my draft.
For an application ported to IPv6, the v4-mapped stuff just makes a
difference to the order of addresses returned by getaddrinfo, for example
whether getaddrinfo returns a v4 address before a v6 address or vice-versa.
It would affect whether dual-protocol applications use v4 or v6 in
dual-protocol network environments, but by making the correct/expected thing
happen.
> 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."
Yes.
> Should use of the loopback destination restrict the source
> address to be loopback also?
I don't think so. For example if fe80::1 is assigned to my ethernet
interface, why shouldn't I be able to send to destination ::1 using fe80::1
as the source address?
(This would be on a weak host model implementation so the mismatch between
the loopback interface and the ethernet interface is not considered a
problem.)
> 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.
I agree and my absentee Pittsburgh IETF presentation talked about related
policy table issues. In my revision I plan to give "prefer matching label"
much lower priority (probably moving it to just above the
longest-matching-prefix rule).
> 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.
One issue with this simplification is that it would change the selection in
some instances. For example: global destination with choice of deprecated
site-local SA and preferred link-local SB. The current rules pick SA and
your proposal would pick SB.
If we're going to simplify this, I actually favor just giving appropriate
scope absolute priority over preferred/deprecated. The preferred/deprecated
parts of the current rule 3 are a response to comments from Erik Nordmark,
if I remember correctly.
> 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?
The requirement for applying the rules in order, and only superceding the
last rule, is to get some predictability between different implementations.
We could argue about your example (sending to 6to4 destination, choice of
public 6to4 or anonymous global source address). I think choosing the public
6to4 source address is the right answer (and really, if the implementation
is using privacy there will also be an anonymous 6to4 address that will get
chosen). But whatever the right answer is, I think customers will be even
more annoyed if some implementations do one thing and other implementations
do something different.
Predictibility in this area is a very good thing for network operations &
manageability.
Many of the individual rules are collected from other places. For example,
avoiding deprecated addresses comes from RFC 2462. Preferring anonymous
addresses comes from the privacy draft. The real contribution of this
section isn't the rules themselves, it's supplying consistency by giving
them an order.
I do agree that the higher-priority rules could be MUST, the middle-priority
rules could be SHOULD, and the lowest-priority rules (like
longest-matching-prefix) could be SHOULD or MAY.
> 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?
Yes.
> 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.
Btw: In the forthcoming revision, that greatly reduces the number of entries
in the default policy table, these destination address selection rules will
expand a bit. For example, because the default policy table won't have
separate entries for various address scopes, there will need to be a
separate rule here to prefer destination addresses of smaller scope.
To answer your question: the prefer smaller scope rule shold be SHOULD or
maybe even MUST. The longest-matching-prefix should be SHOULD or maybe MAY.
The others can be SHOULD.
> 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?
For example, consider a name that resolves to both a site-local & global
address, and the machine itself both a site-local & global address.
I think we agree that for the site-local destination, you should prefer the
site-local source, and for the global destination you should prefer the
global source.
But should getaddrinfo return the two destination addresses in any
particular order? I *think* there's consensus that using the smaller-scope
addresses is better, so getaddrinfo should return the site-local address
before the global address.
This is important if the site is trying to use site-local addresses for all
intra-site communication. If getaddrinfo returns the global address first,
intra-site communication will end up using global addresses.
Hence, I think getaddrinfo implementations SHOULD or maybe even MUST return
the site-local address before the global address - otherwise site-local
addresses will lose one of their important uses.
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 PROTECTED]
--------------------------------------------------------------------
