Subject: draft-ietf-ipngwg-addr-select-01 comments

From: "Powell, Ken" <[email-masked]>
Date: Fri, 8 Sep 2000 15:58:27 -0400

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-masked]
--------------------------------------------------------------------

---

From: Richard Draves <[email-masked]>
Date: Mon, 25 Sep 2000 13:03:31 -0700

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

Hmm. This argument could apply reductio ad absurdum to every aspect of an
implementation's configurability. For example, router's are configurable and
there's no IETF standard for configuring them (maybe I'm just ignorant) but
network administrators still find it useful to configure routers.

In particular, RFC 2461 section 6.2.1 defines conceptual variables that MUST
be configurable, but it does not specify a standard protocol or mechanism
for configuring them.

How is this any different from my draft specifying a conceptual policy table
that SHOULD be configurable, but not having a standard protocol or mechanism
for configuring it?
 
> 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.

I've concluded that having policy entries for different scopes is not a good
thing, it's getting in the way of the rules that deal with scoping. And see
my reply to Brian - looks like we can't have v4-mapped addresses in the
policy table at all.
 
> 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:
> 
>      (i.e., avoid Scope Source < Scope Dest) If both
>      addresses have insufficient scope, prefer the one
>      with higher scope.
> 
>      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.

You are describing a scenario where a site transitions from using both
site-local & global addresses to only using global addresses?

So a node A has global address Ag and site-local address As. And node B,
that is trying to connect to A, has addresses Bg and Bs.

Now the network administrator deprecates site-local addresses across the
site.

I think this would also result in the site-local addresses being removed
from DNS. You don't want to have deprecated addresses in the DNS.

So when node B looks up node A, it only finds Ag. And source address
selection on node B will pick source address Bg.

Maybe the point you are making applies to destination address selection.
Would you want to see a destination address selection rule like this: when
comparing destination addresses DA and DB, if Source(DA) is not deprecated
and Source(DB) is deprecated, then sort DA before DB?

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

OK, I think I buy this. Off hand, this means that candidate set definition
and the source address selection rule(s) relating to scope would be MUST,
and everything else would be SHOULD.

For example, the source address selection rule saying that deprecated
addresses should be avoided, would be SHOULD instead of MUST because it does
not affect interoperability. Is everyone OK with this?
  
> > 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"?

Not in so many words, but draft-ietf-ipngwg-scoped-routing-03.txt can be
construed that way.

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

If Congress passes a law, I think that will supercede an IETF standard. :-)
More seriously, see the MUST/SHOULD discussion above.

Rich