December 21, 2014
 
 
RSSRSS feed

Zeroconf: A Net Admin's Work is Still Never Done

A Look at the Reality

  • July 12, 2004
  • By Paul Rubens
Printers and other network devices that configure themselves so you don't have to--that's the promise of zero configuration networking (zeroconf), a set of standard protocols being developed by the Zeroconf Working Group of the Internet Engineering Taskforce (IETF.) And you have to admit, the concept does have a great deal of appeal--running and managing a corporate network is hard work, and eliminating tedious configuration tasks would certainly make the job a little bit easier.

But before you get too excited, it's worth bearing in mind that, unlike the auto-configuration capabilities built in to IPv6, zeroconf is designed for home offices and small company LANs. If you administer a big corporate network then Zeroconf isn't going to change you life--the best you can hope for is that the branch office on the other side of town will be able to add a printer to its LAN without you or one of your staff having to go and configure it.

"In theory auto configuration sounds good, but would you really want to allow it anywhere in your corporation?" "The idea of zeroconf is that it will simplify enterprise configuration," says Erik Guttman, chairman of the Zeroconf Working Group. "Enterprise network administrators want to control what servers are where and what they do, but the management of local resources is tedious. It would be much easier if it was possible to delegate printers, CD burners and other devices to the local area. So for my department, I could deploy and control a printer, and everyone could find it, and it wouldn't have to be supported by enterprise administrators."

The flip side of this, of course, is that the local branch won't have to abide by enterprise-wide IT policies anymore, and before you know it, it could be adding all sorts of equipment from all sorts of vendors without your say so. But before getting into that, let's take a look at how zero configuration networking works.

Essentially, it's made up of three components needed to get IP networking going by itself: IP addressing, name resolution, and service discovery.

Normally, a DHCP server co-ordinates the automatic allocation of IP addresses to new devices attached to a network, but the Zeroconf Working Group has devised a standard scheme enabling a host to automatically configure an interface, without a DHCP server, with an IPv4 address in the 169.254/16 range that is valid for Link-Local communication on that interface.

Many applications also assume the existence of a name server, but clearly on a LAN this will not always be the case. The protocol to make each host on a LAN its own DNS server is actually quite trivial, and Link Local Name Resolution is proven and mature.

The final part of the jigsaw is service discovery - the protocol which enables computers to find the printers or other devices that are available on the Link Local network. Various proprietary protocols, like Apple's Rendezvous and Microsoft's uPnP, exist already to carry out this function, although there is as yet no zeroconf-developed standard solution.

There are a number of problems with zero configuration networking that everyone should be aware of. The main foreseeable problem is that if you make something simple so anyone can use it there are bound to be difficulties when things don't go according to plan.

"One of the big questions yet to be answered is how to handle network boundaries," says Erik Guttman, chairman of the Zeroconf Working Group. "You could have a user with an autoconfiguring laptop which he uses in the office on a wireless network, but when he takes it to a conference it won't work on the conference's network and the user won't know why. Or if he does get connected to the corporate network, he won't be able to see the printer on his own desk. What it comes down to is when you bring up the WAN, you can't use the LAN, and vice versa."

Another problem is the age-old one of proprietary solutions emerging--while vendors wait for standards to be developed--which don't interoperate. The Zeroconf Working Group has been working for over four years, and there is a danger that if the standards don't emerge very soon there will be such a proliferation of non-compatible equipment and protocols that using zeroconf becomes impractical. "The large vendors like HP, Apple and IBM are really starting to develop their configuration capabilities," says Stephen Elliot, senior analyst at Framingham, MA-based research house IDC. "A bar to the adoption of zeroconf would be all these legacy investments, because Apple's Rendezvous, for example, won't be compatible with whatever emerges as the zeroconf standard."

The biggest barrier to widespread zeroconf adoption, however, is probably human: most network managers will be very unwilling to let unskilled users take control of a branch office LAN. "In theory zeroconf is interesting, but I don't know whether IT departments truly want it. I think many will turn around and say 'actually this is how we manage branch offices remotely and we are not going to change,'" Elliot says. It's easy to understand why: not having to go and configure a printer at a branch office may make your job a little easer, but is it worth it if the price is allowing branches the automomy to do a lot more of what they want--but without necessarily having the skills to ensure it is all implemented properly? And guess who is going to have to sort out the problems when auto-configuring hardware doesn't work as expected, or when it suddenly brings the branch LAN to its knees, or starts effecting WAN connectivity? In theory auto configuration sounds good, but would you really want to allow it anywhere in your corporation?

The question is a theoretical one at the moment, as the full zeroconfig standards aren't likely to be finished and available for mainstream use any time in the next 18 months or so. For now, at least, configuration remains a dull but necessary part of the every day life of the network administrator. Go configure.

[Editor's Note: This article originally appeared on the JupiterWeb site CrossNodes. -BKP]

Sitemap | Contact Us