> > 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.
>
I agree that this feature could be very useful in multi-homing
situations, but would it be used much? If each vendor implements
the management hooks their own way, network administrators would
quickly find the hassle of defining this information on every
node in a site out-weighs the benefits. I think it would be
reasonable for vendors to postpone implementation of this
mechanism until additional configuration tools are well defined.
> > 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.
I think you may have missed the point of my question. The
default policy table contains the following lines:
::ffff:169.254.0.0/112 30 7 7
::ffff:10.0.0.0/104 20 8 8
::ffff:172.16.0.0/108 20 9 9
::ffff:192.168.0.0/112 20 10 10
::ffff:0:0/96 10 11 11
Instead of just:
::ffff:0:0/96 10 11 11
I was questioning if subdividing the V4-mapped addresses
in the table is a good thing.
> > 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.
I see your point. I'm not terribly concerned what happens
when both addresses are of insufficient scope. The network
configuration is clearly broken if it comes down to this
choice anyhow. How about something like:
Rule 3a: Avoid insufficient scope for destination.
(i.e., avoid Scope Source < Scope Dest) If both
addresses have insufficient scope, prefer the one
with higher scope.
Rule 4: Avoid deprecated addresses.
Rule 3b: Prefer lower scope.
> 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.
I wouldn't do that. We should support graceful renumbering
of a network from site-local addresses to global addresses.
In this situation, one would intentionally configure a router
to advertise a deprecated site-local prefix.
>
> > 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.
I don't think we should use MUST unless violating a rule breaks
interoperability. I agree with you that inconsistency between
implementations is not good. Still, we need to allow
implementations the freedom to deal with issues not foreseen
by us today. That's why I prefer words like RECOMMEND and
SHOULD on the order of the rules.
> 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.
Agreed. Is there any other spec that specifies "avoid
insufficient scope"?
>
> > 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
<snip>
> > 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.
I agree, this all makes sense as a default mode of operation
given what we know today, but I'm not sure you caught the
concern here.
I was thinking cost, QoS, performance, or even political/
contractual considerations may become important factors
in address selection in the future. I can't say how, but
I can see why an implementer may need have such
considerations override most other rules.
>
> 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.
As stated before, given the lack of interface information in
getaddrinfo, the source addresses selected for the destination
address comparisons could be incorrect. Implementations may need
to provide some way to compensate for this problem, even if its
as ugly as a management knob to force use of global addresses
when all else fails. That said, I have no problem with SHOULD.
Ken
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
