Zero Configuration (ZeroConf)

Zero Configuration (ZeroConf)

As anyone who’s ever tried to hook their laptop to someone else’s to use TCP/IP to play video games, transfer files, or whatever, will tell you…it’s a pain. Even though computer manufacturer’s
and software programmers will tell you that networking is supposed to be simple, it really isn’t. You need to configure several parameters (IP address, DNS or host name, etc.) properly
or you won’t be able to communicate. These parameters are usually no problem for network technicians, but what about the average person? Configuring peer-to-peer or small network networking usually involves a game of “What should my IP address be?” between the people that want to network.
Enter the Internet Engineering Task Force (IETF) and the Zero Configuration (ZeroConf) initiative. The primary goal was to make networking via TCP/IP extremely easy and “hands off” for small networks. Ideally, two computers could be connected through Ethernet jacks with only a crossover cable and be able to communicate without any further configuration. In order
to accomplish this, the ZeroConf working group of the IETF had four main areas of focus:

1. Automatic Interface address configuration
2. Automatic Multicast address configuration
3. Translation of addresses to names and names to addresses
4. Service location

In order for the ZeroConf initiative to be successful, each of these components must be implemented in the ZeroConf protocol.

Note:

Apple Computer has been a large participant in the design of the ZeroConf protocol.
It has its own protocol, called Rendezvous, which itself is an open Zero-Conf protocol that has been submitted to the IETF for approval.

Automatic Local Interface Configuration
As you may already know, a computer must have a local IP address in order to communicate. Instead of relying on static addressing (too much work and too much to know) or dynamic addressing (other hardware required), ZeroConf allows for automatic configuration by the two communicating entities themselves. In the absence of a manually configured address or a DHCP server, the communicating entities will “figure out” their own local IP addresses (known as linklocal addresses) as follows: First, for each interface, each computer chooses a random TCP/IP address somewhere in the address space 169.254.1.0 to 169.254.254.255 (that is 169.254.0.0/ 16 with the top and bottom 256 addresses reserved for future use). Then, the computer configures its local interface with this address. Of course, it wouldn’t do any good if both computers chose the same address. So, two things happen to prevent that. First of all, the random number used to select the IP address is based on several computer-specific items (including the MAC address, real time clock, etc.) so that each computer is guaranteed a unique address. In addition, after the unique address is selected, it must be tested to ensure that no other device is using the same link-local address. To do this, the computer uses ARP to tell the other computers on the network segment connected to the interface being configured what IP address it intends to use. If no devices respond that they are already using that address, the interface is configured with the chosen address and communication
can take place.

Note:

 Windows has had this capability since Windows 98. Microsoft calls it Automatic
Private IP Addressing, or APIPA. The basics of this capability have been
incorporated into the ZeroConf proposed standard.

Multicast Address Selection
Another requirement of the ZeroConf initiative is that there is a mechanism for automatically choosing multicast addresses for the network. The IETF has defined the standard for the Zero- Conf Multicast Address Allocation Protocol (ZMAAP). This protocol is used to allocate multicast addresses among the various peers in small, peer-to-peer networks.
This protocol is the polar opposite of the multicast address assignment protocol known as MADCAP, which stands for Multicast Address Dynamic Client Allocation Protocol. Where
MADCAP is a client-server multicast address allocation scheme, ZMAAP is a peer-to-peer allocation scheme. Essentially, each node on a ZeroConf network is running its own little multicast 
allocation service (called a mini-MAAS in ZeroConf parlance). Any entity that needs a multicast address will make a request to its local mini-MAAS, which will then select an address and, before permanently allocating it, inform the other local mini-MAASs of its choice. If there are any objections, the originating mini-MAAS will rechoose the address. Otherwise, it will go ahead and allocate the address.

Name Resolution
You might think that there isn’t a way around name resolution, apart from constantly exchanging HOSTS files or some other silliness. In actuality, ZeroConf relies on standard TCP/IP protocols, including one known as Multicast DNS. Traditional DNS relies on centralized servers to answer DNS queries. But the addresses of these servers must be configured (and the goal is zero
configuration), so the designers of ZeroConf decided to use Multicast DNS. Multicast DNS was a little-used protocol until ZeroConf came along. 
       Traditional name resolution works much like asking the host at a party to introduce you to the people in the party you don’t know. Let’s say you wanted to know which person in the room was named John. With the traditional DNS model, you would ask the party host (the “DNS server” in our scenario). If you were to use Multicast DNS in the same scenario, you would simply
shout in the room, “Hey, is there a John in here?”
       Multicast DNS essentially puts out a multicast transmission that asks for the address of the network name being requested. This works great in small networks, but the amount of traffic required and the introduced delays make Multicast DNS impractical for larger networks, such as the Internet.

Service Location
The final aspect of ZeroConf is service location. It is important on networks to be able to locate services. AppleTalk is the master of finding services on a network without configuration. Apple
designed it so that whenever you plugged a printer into an AppleTalk network, it would advertise itself on the network and you could just choose it. This traditionally has been difficult on
TCP/IP networks. Furthermore, the chatty nature of such services would not be welcome on large networks.
       The IETF has designed a protocol specifically for locating services on a ZeroConf network.
That protocol is known as DNS Service Discovery, or DNS-SD. DNS-SD allows clients to use regular DNS queries, without the need for a new DNS message structure, to find a list of names

of particular types of services provided within a particular domain.

Read More

The Windows Registry

The Windows Registry

All of this TCP/IP configuration information is stored in the Windows Registry database, along with lots of other hardware and software configuration information. You can change most of the
TCP/IP parameters by using the Network applet in Control Panel as you have just seen. Certain parameters, however, such as Time to Live and the default Type of Service, can be changed only by using the Registry Editor (regedit.exe or regedit32, depending on your preference). If you change some of these Registry parameters without detailed knowledge of TCP/IP configuration, you may affect the performance of TCP/IP on your system in an adverse and unexpected way.

Top:

If you are configuring TCP/IP on a Windows NT or 2000 device and you want to
know more, check out the Microsoft Knowledge Base article 120642 on the
Microsoft website at www.microsoft.com. This article covers all the standard,
optional, and nonconfigurable TCP/IP parameters and describes which parameters
are updated by using the Network applet in Control Panel and which are
changed using the Registry Editor. If you want to see the equivalent article for
Windows XP, check out article 314053.

In the next chapter, you’ll get a look at some of the utilities in the TCP/IP toolkit that you can use to view and troubleshoot your TCP/IP network. All of these tools are based on the original
UNIX tools, but these days they are available in one form or another for all operating systems, including all versions of UNIX, Novell NetWare, and Microsoft Windows. 

Read More

Virtual LANs (VLANs)

Virtual LANs (VLANs)

With the introduction of Ethernet switches, and their subsequent replacement of Ethernet hubs in corporate LAN environments, came the power to manage traffic flow much more efficiently
and in many different ways. One of those ways was to allow users on different switch ports to participate in their own network separate from, but still connected to, the other stations on the
same or connected switch. This “network-within-a-network” concept became known as Virtual LAN (VLAN) technology.
       Let’s say, for example, that you have a 24-port Ethernet switch. If you have a group of users that constantly use a particular server and produce very large amounts of broadcast traffic, you might want to separate them into their own segment. But, with VLAN-capable switches, you are able to modify the segmentation within the switch itself regardless of geographical proximity of the VLAN members, thus saving you the expense of additional network hardware or recabling. To do this, you would use the switch management software to assign the ports on which those users and their server were working to their own VLAN. The VLAN for this group could be VLAN #2, for example, and the VLAN everyone else is assigned to could be the default management VLAN #1. Users would still be able to communicate with each other and their respective servers (assuming a router was installed), but broadcast traffic would be isolated. With large, enterprise-capable switches, this benefit is realized even more so. With hundreds of ports, you can segment the network any way you’d like, even on-the-fly and into many different segments.
       Let’s say, for example, a company’s network is divided into VLANs based on the departmental affiliation of the users. Bob transfers from the finance department to the accounting
department but keeps his same office. Susan moves from one building to another but remains in the marketing department. The administrator needs simply to configure Bob’s switch port to
be in the Accounting VLAN and Bob immediately enters the Accounting broadcast domain. Of course, Bob’s computer must be reconfigured for the subnet related to the Accounting VLAN,
which can be done centrally by rescinding his DHCP lease. Once his system requests a new DHCP lease, the DHCP server with the scope for his new subnet will offer him the proper IP information. The administrator can then configure the new port on the new switch that Susan is now plugged into for the marketing department, and regardless of her physical move, Susan never notices that she is connected to different switch hardware and her IP configuration can remain the same.

Note:

In practice, each VLAN corresponds to a different IP subnet, which is why a router is required to change the VLAN affiliation of a frame. The underlying packet has to be routed to the destination subnet, even if the intended recipient happens to be connected to the switch port right beside the port leading from the source device.

Read More

The Options Tab

The Options Tab

The Options tab allows you to adjust IP security and TCP/IP filtering settings (see Figure 3.10).

FIGURE 3 . 1 0 The Options tab of the Advanced TCP/IP Settings dialog box

Highlighting the IP Security option and clicking the Properties button leads to the ability to turn off IPSec functionality or set it to one of three modes of varying aggressiveness, beginning with simply responding to requests for IP security, then progressing to requesting IP security, and finally to requiring it.
       The TCP/IP filtering option allows you to exercise quite a bit of control over which protocols are allowed to communicate with the computer. Filtering may be performed on any combination

of TCP and UDP port numbers and IP protocol number.

Read More