Subject: (IPng 7475) RE: simple source address selection

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 05 May 1999 15:33:28 +0900

From: Richard Draves <[email-masked]>
Subject: RE: simple source address selection
Date: Thu, 29 Apr 1999 11:02:38 -0700

> 3. There's no use of longest-matching-prefix as a tie-breaker.

False. The paper explicitly states this. And I believe that KAME(more
strictly Hydrangea) is the first implementation to use the
longest-match tie-break algorithm.

> 4. It's sort of a mix between weak model and strong model - it first tries
> to pick a suitable source address assigned to the outgoing interface, but if
> there isn't one available it will consider source addresses assigned to
> other interfaces. (The details imply that KAME assumes that all interfaces
> on a node will belong to the same site.)

More precisely speaking, KAME don't care site local addresses so much. 
This is because KAME members believe that it should be discouraged to
use site local addresses.

> 5. Not clear how v4-compatible addresses or other format prefixes are
> handled.

Right. KAME doesn't implement automatic-tunneling.

> Responding to this:
> 
> I need to add something for loopback to my draft.

Please do it.

> I think it is a mistake to completely preclude the choice of a deprecated
> source address or a source address of scope different than the destination.

Agreed.

> I think longest-matching-prefix is a good tiebreaker and it should be
> encouraged.

Agreed. According to our internal discussion, it is believed that this
algorithm doesn't give bad influence in multi-homed environments.

Comments to srcaddr-00.txt:

(1) Rule 2 says, "If the destination address scope is smaller than or
equal to SA's scope, then choose SA. Otherwise choose SB".

It seems strange to me. The destination address scope never be equal
to SA's scope by Rule 1. This language should be the following.

"If the destination address scope is smaller than to SA's scope, then
choose SA.  If the destination address scope is larger than to SA's
scope, then choose SB."

Note that I'm not confident this rule is appropriate in the case where
the destination address scope is larger than SB's scope.

(2) Just in case, "organization-local" multicast address should be
mapped to site-local scope or global-local scope. I recommend the
latter.

P.S.

I wonder that the deprecated status is valid (or practical) to
link-local addresses while it is clear that the status is invalid for
the loopback address. The ID should clearly define comparison rules
for all cases of matrix: status x scopes.

--Kazu
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Wed, 05 May 1999 11:22:54 +0200

This mail is not an answer to Kazu's one (but Kazu's one is
the last I've received :-).

As I already wrote in a previous mail, for me the issue is not
a choice between weak/strong model but what model to use for
each kind of addresses with the help of sin6_scope_id new
field from RFC 2553.

For global addresses I am in favor of weak model only because
weak model is used for IPv4 on Unixes and to keep it keeps
parameters for usual applications too.
On BSD Unixes, the default source address is the interface address
of the route to the destination and is compute by default by
the ifa_ifwithroute() function which does a kind of longest match
when nothing else is obvious (then the longest match tie-break
is not new (but is still a good thing)).
There is no "principal" address but the interface address of the
default route can play this role (then neighbor discovery/autoconf
must take care of it).

For site-local addresses one should give the site to use
(strong model at site level) because without this multi-sited
nodes can't work BUT there can be a "default site" notion
which catches all mono-sited and some multi-sited cases.

For link-local addresses the situation is exactly the same,
an interface index is needed and you can provide a global
(ie. node level) default interface when this strong model
is a bit too strong (for instance when you have only one
interface). For real multi-homed (multiple interfaces)
nodes this can make the use of link-local addresses hard
but they are not for general usage and this is the only
way to solve possible ambiguities (same link-local address
on different interfaces).

The last case is multicast addresses. My proposal is to
deal with them as with link-local addresses because
it is better to know where (ie. on which interface) to send
multicast packets. With IPv4-like rules one can get
(ie. you should get :-) a wrong interface if one doesn't
enforce it and this is not so hard to add an interface
parameter to multicast applications without it.

The last point is about the role of the network layer.
I split things in kernel and user (very similar) and
it is clear the kernel can implement only sanity and
default rules, ie. a clever address selection (or destination
address selection) can only be done at the user level
(for instance with a policy library called by getaddrinfo()).

Regards

[email-masked]

PS: even I have seen different choices, for instance for source
address of multicast, I have never seen stupid choice and
I believe we agree about source address selection guidelines.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------