Subject: (IPng 7439) simple source address selection

From: Richard Draves <[email-masked]>
Date: Wed, 28 Apr 1999 10:57:42 -0700

I'm submitting a draft describing a simple algorithm for source address
selection. This is based on an email exchange on the implementor's list back
in February.

ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-simple-src
addr-00.txt

Any comments are welcome.

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

---

From: Steve Deering <[email-masked]>
Date: Wed, 28 Apr 1999 14:05:03 -0700

OK, here are some comments:

>3. Introduction
>
>   The IPv6 addressing architecture [3] allows multiple addresses to be
>   assigned to interfaces. These addresses may have different
>   reachability scopes (link-local, site-local, or global).

Some of the assignable addresses are multicast addresses, which have a
wider range of possible scope values.

>   Furthermore, addresses assigned via IPv6's auto-configuration
>   mechanisms [4] may be "preferred" or "deprecated".

Question: does DHCPv6 support the preferred/deprecated attribute for
addresses assigned via DHCP?

>   This document does not specify a "strong host" or "weak host" model
>   for source address selection [5, section 3.3.4.2]. It merely assumes
>   that the implementation has a set of candidate source addresses from
>   which one must be chosen. If the implementation uses the strong host
>   model, this MAY be the set of addresses assigned to the outgoing
>   interface that will be used for the destination address. If the
>   implementation uses the weak host model, this MAY be the set of all
>   addresses assigned to the node's interfaces.

You may want to observe that, in the case of a multicast destination,
one MUST use the "strong" host model, i.e., the source address must
belong to the originating interface (or, more accurately, to an
interface attached to the same link as the originating interface).
This is a requirement of most current multicast routing protocols.

Although I have long been an advocate of the strong host model for
unicast as well, I finally conceded the need to allow use of a source
address that belongs to a different interface than the originating one,
for unusual circumstances like responding to a ping of a unidirectional
interface.  However, I think the source-address selection rules should
cause the strong host behavior to occur whenever possible.  Thus, I
would advocate a Rule 0, preceding your other rules, that says if SA
belongs to the outgoing interface and SB does not, you MUST use
choose SA.

So, for example, if a node specifies that a packet be sent out interface
x, destined to an address that belongs to its own, different, interface y,
it should carry one of x's addresses as a source address, which contradicts
your Rule 1.  Note: this example can occur only in the case were the upper
layer has explicitly specified the outgoing interface, overriding the host
routing layer's inclination to send the packet out -- and then looped back
from -- the interface belonging to the destination address

Another issue with your language above regarding the weak model -- "this
MAY be the set of all addresses assigned to the node's interfaces" -- is
that, when sending a packet to a less-than-global destination, there may
be some of a node's unicast address that MUST NOT be used a source address
under any circumstances.  For example, when sending a packet to a site-
local destination via interface x, you MUST NOT use a site-local or
link-local source address that belongs to an interface y that is not
attached to the same site as interface x.

>4. Source Address Selection

I know this is specified elsewhere, but you might want to throw a
sentence in somewhere, reminding people that multicast addresses and
anycast addresses MUST NEVER be used as source addresses.  This is sort
of a "Rule -1", preceding all others, that takes those kinds of addresses
out of the pool of candidate source addresses.

>   Addresses that are manually configured (or otherwise not auto-
>   configured according to [4]), we treat as having "preferred"
>   configuration status.

The answer to my earlier question about DHCPv6 may require a slight
rewording here.

>   Rule 1: If one of the source addresses is equal to the destination
>   address, an implementation MUST choose that source address.

This rule (and probably all of them) needs to be qualified with language
about scopes and interfaces.  For example, if I am sending a packet to
destination site-local address A in attached site S1, I can use A as a
source address ONLY IF A is one my addresses on an interface attached
to site S1.  If A happens to be one of my addresses only on an interface
that is NOT attached to S1, it is NOT a candidate for use as source
address in that packet.

>   scope. This mapping implicitly conflates unicast site boundaries and
>   multicast site boundaries.

Nice word, "conflate".  I had to look it up.  :-)

>7. Other Format Prefixes
>
>   This document does not specify source address selection in the
>   presence of NSAP addresses, IPX addresses, or addresses with as-yet-
>   undefined format prefixes.

Rather than leaving it undefined, I suggest that we say that all address
prefixes other than link-local, site-local, and multicast be interpreted
as global-scope unicast.  If it turns out that that is the usage they
eventually take on (which I think is the most likely usage), then all
the fielded equipment will do the right thing without any modification.
If, on the other hand, those currently-unused prefixes end up being
assigned different semantics, part of their specification can be how
they fit into the source-selection rules.

End of comments.

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 28 Apr 1999 14:05:03 -0700

End of comments.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Apr 1999 09:29:07 +0100

Richard,

I'm not 100% sure about this limitation of scope:

>    This document does not address the more general problem of choosing
>    the "best" destination address / source address pair for
>    communication with another node, given a set of possible destination
>    addresses and a set of possible source addresses.

It really is a trivial extension to your draft to add a recommended
rule for choosing the pair - i.e. run your rules for choosing the
source across all destination addresses, and pick the final pair
with 1. the smallest scope and 2. the longest match.

I have a vested interest in this as it would take the special case
out of 6to4, but I think it's of general utility.

   Brian