Erik Nordmark writes:
> James Carlson wrote:
>
> > I agree that catering to non-DHCP networks seems like a somewhat silly
> > thing to do, even though many of our present customers seem to be
> > unnaturally adverse to using DHCP on things classed as "servers."
>
> Sure, but I suspect those customers would have a severe allergic
> reaction if their boxes picked a random LLA.
> I DHCP is too dynamic for them (which it really doesn't have to be - it
> is a perception and dhcp server configuration issue at best), then LLA
> is off the scale.
I agree. I'm talking just about supporting networks where LLA might
be present due to unconfigured (and thus not "server") machines
somewhere on the net. I'm not talking about using LLA to configure
usable interfaces on those systems classed as "servers" -- that would
indeed be bad.
I think there are two components here -- what a system with global
addresses does when it receives packets from a system actively using
LLA, and what a system does when it has no way of getting IP
addresses.
The latter is the dynamic addressing you're rightly pointing out as
unhealthy. The former, though, is just supporting -- or even just
_viewing_ -- the machines on the network that have fallen through the
cracks.
> > One of the important deployment issues I've seen is that in some large
> > corporations, the DHCP servers are run by the Windows support group.
> > UNIX systems do not (and cannot) get addresses from them, and are not
> > allowed (by policy) to have their own DHCP servers. It's an issue
> > that has kept the old RARP-boot stuff in service long past its sell-by
> > date. (It's an open list, or I'd name that big customer.)
>
> And that customer would be well-served by the servers picking an LLA
> address? How would that improve things?
Not at all. See above.
> > So, there's probably some argument for being able to handle a system
> > that doesn't have an address as an exception case -- being able to
> > find it, and then log in and correct it (probably by something like
> > "echo xxx > /etc/hostname.hme0"). I doubt, at least at the enterprise
> > level, that non-trival and long-lived uses of LLA would be at all
> > feasible, as they're just too chaotic.
>
> But those enterprise servers have service processors that are reachable
> either on a management Ethernet, a serial port, or both.
Those management processors have exactly the same problem.
> > The other plausible argument is to be able to detect and administer
> > (through some means) any non-Solaris hosts that arrive on your network
> > and start speaking LLA. As previously noted, you can't get there
> > easily if you don't have either some LLA support or a strong
> > assumption that LLA is present only on one interface.
>
> Yes, that part is separable.
Actually, it's quite related to the point I was making above.
> But even if the host that picks an LLA
> isn't multihomed, if it plus into a network with multihomed nodes then
> the complexity appears for those nodes.
Yes.
> IPv4 LLA feels too much like a solution looking for a problem to me.
In addition to the trivial "how do I talk to my printer?" problem, I
think the underlying problems it's trying to address are:
- Too many people are stuck on SWAN-like networks where somebody
else controls the infrastructure and forbids the use of
"unauthorized" DHCP servers. If you're unable to get an address,
LLA gives you a "degraded" mode of operation where you can still
reach some local services and perhaps file a service desk ticket
on your problem. ;-}
- Many systems (including Solaris!) are designed so that boot time
is "special," and if the right things don't happen then because
one of the servers is temporarily out, then the system is in a
lame or even semi-comatose state. If this leads to a lack of an
address, LLA gives you a way to log in remotely and fix or at
least restart the system.
We can certainly just decide that we don't care about failure modes,
and that the right way to handle the problem is to make DHCP service
ubiquitous.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
