On Wed, Mar 02, 2005 at 09:51:45AM -0500, Steven M. Bellovin wrote:
> In message <20050302044037.GA29385@che.ojctech.com>, David Young writes:
> >
> >--LQksG6bCIzRHxTLp
> >Content-Type: text/plain; charset=us-ascii
> >Content-Disposition: inline
> >
> >The IETF Zeroconf working group has introduced "link-local"
> >IPv4 addresses (those in 169.254/16).  The "scope" of these IPv4
> >addresses is the attached link (ethernet, PPP, whatever), only.  See
> ><http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt>, which
> >describes the link-local addresses and a method for auto-configuration.
> >Link-local IPv4 addresses are widely used in PC operating systems
> >(Windows, MacOS 9, Mac0S X) and peripherals (printers).
> >
> >A host should not use a link-local source address to talk to non-link
> >local destinations.  This breaks the scope rule.  Attached is a patch
> >that makes sure a host selects non-link local source addresses for IPv4
> >packets that have non-link local destinations.
> >
> >I would like to add this to the kernel, default disabled, enabled by
> >'options IPV4_LINKLOCAL'.
> >
> >Please not that the ifa_getifa method is fairly versatile.  It could be
> >used to implement preferred source addresses, for example.  There was
> >a discussion about that a little while ago on tech-net@.
> >
> 
> Hmm -- is there any reason this can't be done via a user-level daemon?

I could make source-selection the responsibility of a user-level
daemon, but that complicates things.  I don't think we can come up
with enough source-selection policies to justify the added complexity.
I can think of just two, myself.  One is a superset of the link-local
policy, a "same-scope policy," which is that the "scope" of source and
destination should be the same: i.e., use private (192.168/16, 10/8, ...)
sources for private destinations; link-local (169.254/16) for link-local,
global for global.  The second policy is, "use source addresses with
best metric/preference."

What if the source-selection daemon dies?

A better alternative to a daemon might be an LKM.  That's also
complicating.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933