Jim, that is in fact the default behavior. Looking at the source address
selection rules in section 4, with the following addresses:
D - global
SA - site-local
SB - global
If SB should happen to equal D (ie this is loopback), then rule 1 says
to choose SB. Otherwise rule 1 does not apply and you fall through to
rule 2. Then Rule 2 says since
Scope(SA) < Scope(SB), and Scope(SA) < Scope(D), you should choose SB.
Rich
> -----Original Message-----
> From: Jim Bound [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 25, 2001 8:16 AM
> To: [EMAIL PROTECTED]
> Cc: Bob Hinden; [EMAIL PROTECTED]
> Subject: Re: W.G. Last Call on "Default Address Selection for IPv6"
>
>
> sorry. Do not use site-local when sending to global if one
> has a global source address should be the default.
>
> /jim
>
> On Fri, 25 May 2001, Jim Bound wrote:
>
> > Hi,
> >
> > I may still object to it being a standards document. I
> read roughly
> > the 04 draft. My main issue is that I do not believe one
> should EVER
> > use a site-local address when sending to a GLOBAL address
> unless one
> > has a global address available. This does not appear to be a
> > requirement of the algorithm, but I will check again on my
> plane ride
> > to Seattle. If it is I can't see any argument changing my mind for
> > the default behavior.
> >
> > As far as it being standards tracked I will forgo that
> issue and the
> > reason is that precedence has been changed via ngtrans with some of
> > the specs being standards tracked for transition and rich's work is
> > better than a few of those in some instances and if they
> are standards
> > track then so should this be. I do believe though we in
> the IETF are
> > on a slippery slope here and need to be careful for any
> pandora's box
> > we have opened for lets say 2006 when we are working on
> technology we
> > may not for see now as standard vs informational. I should
> probably
> > write a position paper on this for the IESG and IAB as an objective
> > treatise of IETF epistemology.
> >
> > As far as policy I hav changed my mind on this a bit
> because I think
> > we could cause a mamor problem with IPv6 if we don't at least give
> > some default guidance to the vendors and market regarding
> use of our
> > multi scoped addressing architecture. My normal
> laizze-faire view of
> > our work here and my support or not support needs to be tempered in
> > this case.
> >
> > But then we get down to what is right and wrong.
> >
> > Using same scope should be done as DEFAULT. Anything else is very
> > very bad. My belief is that what Rich did. But want to check one
> > more time on the plane.
> >
> > My other concerns are how the wording is in the selection
> process and
> > if the spec tells me how I must implement this in libc,
> APIs, and most
> > importantly how I would do the conditionals and data structures to
> > support the draft. If it is left open and not forced by any IETF
> > SHOULD or MUST I am fine with it for my reasons above. I
> will check
> > this on the plane too.
> >
> > As far as the issues not being resolved and the chairs
> sending a last
> > call. Well I will assume they belived the last call will flush the
> > final discussions out on the list. But I do think all the attached
> > issues should be resolved.
> >
> > thanks
> >
> > /jim
> >
> > On Fri, 25 May 2001 [EMAIL PROTECTED] wrote:
> >
> > >
> > > >This is a IPng working group last call for comments on advancing
> > > >the
> > > >following document as a Proposed Standard:
> > > > Title : Default Address Selection for IPv6
> > > > Author(s) : R. Draves
> > > > Filename : draft-ietf-ipngwg-default-addr-select-04.txt
> > > > Pages : 20
> > > > Date : 14-May-01
> > > >Please send substantive comments to the ipng mailing
> list, and minor
> > > >editorial comments to the author. This last call period
> will end two
> > > >week from today on June 7, 2001.
> > >
> > > were there concrete agreement made about
> standard-track/informational?
> > > i find the following on IETF50 minutes, nothing else (correct me
> > > if i'm wrong). were there any poll on mailing list made?
> > >
> > >
> http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001
> > > .txt
> > >
> > > itojun
> > >
> > >
> > > ---
> > > Jim Bound thinks this shouldn't be a standard, should be
> > > informational. Thinks is policy. This should be suggested
> > > recommendation, not default.
> > > Draves: Thinks this document does have implementation
> requirements.
> > > "Must" requirement have implementation consequences.
> Bound: Doesn't
> > > agree with some of the choices (e.g., selection of site
> scope as source
> > > to send to global destination).
> > > (snip)
> > > Nordmark: Thinks this should be standards track.
> Splitting between must
> > > and should.
> > >
> > >
> --------------------------------------------------------------------
> > > 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]
> > >
> --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > 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]
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
