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

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

> I don't agree we can declare this in the spec.  How we word 
> it I am not
> sure yet.  But mobile nodes will use global addresses not 
> site-local if
> they are roaming across routing realms.  Site-local simply won't work.

You are getting at the interaction between site-local addresses and
mobility. Can a mobile node have a site-local home address as well as a
global home address? If the implementation does not support mobility for
scoped addresses, then the destination address selection will need to be
modified.

How about a rule like this: if you are comparing two destination addresses
DA and DB, and Source(DA) is a home address and Source(DB) is not a home
address, then sort DA before DB.

In this example, DA would be a global address and Source(DA) would be a
global home address. DB would be a site-local address and Source(DB) would
be a site-local address, but not a home address.

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: Jim Bound <[email-masked]>
Date: Tue, 26 Sep 2000 02:17:09 -0400

Rich,

>scoped addresses, then the destination address selection will need to be

I see that too.  But I am coming from a much stronger issue.  I do
not think the src addr selection work should prefer less scope over
greater scope or equal scope ever as a default.

>address, then sort DA before DB.

Thats fine but this is getting out of control now we have this to check.
But this sounds right.  But I really think if this causes any
performance issues for servers that handle 50,000 requests and many
simultaneously this entire source address selection algorithm/config
will get shut off and rely on DNS ordering which can be done too at
least with BIND DNS.

I strongly suggest we have a common set of sorts that are basic and to
what we have deployed today plus 6t04 and leave the others in the spec
as TBD.  No one has shipped a base OS product or router supporting
scoping to the degree we are discussing hear and it has not been tested
at any bakeoffs.

regards,
/jim