IPv4 Link-Local Address Installation

Motivation

When a lambda is set up between two or more hosts, each time we manually have to make sure the IP addresses are configured properly so the hosts can communicate with each other. This is tedious and unneccessary work. There are perfectly valid solution to do this automatically, called IPv4 Link-Local addresses. However, this is never tried in our (optical network) community.

FreekDijkstra, VenkatVishwanath and EricHe agreed to give this technology a try, and write a short report on it. The time frame will be April 2005.

Overview of IPv4 Link-Local Addresses

IPv4 Link-Local Address is considered part of Zero Configuration technology, which aims to let device automatically configure the network. IPv4 Link-Local Addresses was standardized in March 2005 by the IETF, as RFC 3927∞.

Please see the article at WikiPedia:ZeroConf∞ for a technology overview, written by FreekDijkstra.

References

See also:
ZcipInstallation,
ZcipCode,
mDNSResponderInstallation and
LinkLocalARPMeasurements

Technologies Use

In order for two machines to "discover" each others automatically, as soon as a link has been created in between, the following has to happen:

1. The machines need to recognize that the network on a specific interface has changed (either they poll it continuously, or the note a link is coming up).
2. They need to assign a link local IP address on that interface, and check if it is unique. (using IPv4LL)
3. They need to announce a DNS names on that interface, letting other hosts know to which machine that IP address belongs to. (using mDNS or LLMNR)

Thankfully this means we can stay away from the politics in the service discovery protocols (DNS-SD vs. SSDP/UPnP vs. SLLP). So, let's stick with IPv4LL (IPv6 has already Link local IP addresses by itself). I'd say to use mDNS instead of LLMNR, since I am not aware of any implementation of LLMNR.

IPv4 Link-Local addresses

For IPv4LL, I recommend to use the zcip (zeroconfig IP) package. The page ZcipInstallation describes the progress and background information.

Multicast DNS name resolving

For mDNS, we can choose between:

• http://developer.apple.com/darwin/projects/rendezvous/∞ (mDNSResponder),
• http://sourceforge.net/projects/jmdns/∞ and
• http://freshmeat.net/projects/pyzeroconf/∞

I recommend mDNSResponer. The page mDNSResponderInstallation describes ed the progresss and background information.

I'd say just to give mDNSResonder. The mDNS draft does recommend to use DNS names ending in ".local", so I'd say we just prepend ".local" for the IP address on the "optical" interface. So the optical interface of vangogh3.uva.netherlight.nl could be looked up by querying for vangogh3.uva.netherlight.nl.local. We may decide on something more advanced later:

1. local seems odd for worldwide networks
2. what to do if vangogh3 has 2 optical interfaces, both connected to the same LAN? should be append a sequential number?.

TO DO

• Auto call zcip in background (see Red Hat Configuration and Debian Configuration at ZcipInstallation)
• Start and configure mDNS responder
• Fix ZCIP bug: When ZCIP is called, two "default" routes are added to the route table. First one for destination "169.254.0.0/16", with gateway "0.0.0.0" (the local link). This is good. Secondly, one for all destinations "0.0.0.0/0" with gateway "0.0.0.0" (the local link). This one is bad, and should not be created. It is unclear if this is set explicitly by Zcip in the set_default_route() function, or is caused by the ifup() function which always brings up the interface (Zcip assumes that the interface was down), and this somehow causes the second bad default route in the route table.
• ZCIP feature: use libnet 1.1.x instead of libnet 1.0.x

Article

We should write an article about our work. The article shoudl include:

• General background: take from above or from WikiPedia:ZeroConf∞.
• Applicability. In our opinion, there are two ways how applications can sent data on datanetworks: either use a dedicated end-to-end connection, or use the regular Internet. There are no in-betweens. End-to-end connections should in our opinion always be link-local (no router in between), and use (IPv4 or IPV6) link-local IP addresses. PieterDeBoer of SARA pointed out that a possible scenario were the data is off-loaded, but only after the "first mile", so typically a campus network, were this data goes over the regular wire on the campus, but is off-loaded by the first router where the data passes through. In that case, private IP address ranges (10/8, 172.16/12 and 192.168/16) may be used: link-local IP addresses will not work, and routable IP addresses are not strictly required.
• Installation details of ZCIP and mDNSResponder, including configuration information (+ possibly point to here or to a technical report or code base)

Question to ask ourself, or mention in the article.

1. Is ZCIP it standalone, part of the dhcp client, or part of the kernel (answer: standalone, but root access is required). Would it be a part of a provisioning system such as PIN/PDC? PDC is expected to return a set of IP addresses.
2. Does it monitor the link constantly, or only when it is brought up using ifup? (answer: it seems to be able to monitor it constantly, but that hasn't been tested)
3. Does it gracefully handle the transistion from a link-local address to a DHCP address as soon as a DHCP server is found on the network? (answer: it seems it does not)
4. Does it run under multiple OSes and hardware (Pentium, Opteron; Red Hat, Debian, Windows, Mac interoperability)? (it seems to run under Debian and Red Hat for Xeon and Opteron)
5. Does it handle conflict detection, even if another client forcefully takes the IP address? (answer: yes, it does. Note that Win2k is buggy, and it does not have a workaround for that)
6. Does it work both with short and long latencies? (answer: we still need to test that, but it seems promissing, since it seems to use the 1 second RTT limit as required by the RFC)

Host-to-host or LAN-to-LAN

Venkat asked:

• Optical (photonic) Networks can be considered as Point to Point. So how will a host broadcast its IP. As the entire network can be considered to be point to point, how will the communication take place to resolve conflicts and duplicates? If A host has to broadcast its IP, etc. then the switch needs to be configured to do multicast of this IP to all hosts continuously.

Freek responded:

• • First of all, optical networks can be point-to-point, but the more and more I talk with people, the more I realize that applications do not want point to point, but LAN-to-LAN. For example, all demo's EVL and UCSD did: all where from one cluster to another cluster (e.g. Rembrandt to Scylla or Charbydis to whatever the name of the UCSD cluster was). Never from a single host to a single host. I asked this question explicitly to Don Petravich, who is in charge of the datamanagement at Fermilab (he's got about 3 PetaByte now). His response was also LAN-to-LAN, since he often did not know in advance (during network scheduling phase) which exact hosts the data should terminate. I see some problems there (in particular on scalability), but it is good to realize optical networks will probably LAN-to-LAN, not point-to-point. I'd say to make a paper after we are done (OK, this will take longer then two weeks -- see my schedules is not that good after all!), and mention this explicitly.

• • Secondly, to answer your question on a more technical level: I assume it is like ARP. ARP message (*) are send to some broadcast ethernet address (I think, never checked this in literature). And the announcement of IP addresses is probably done using ARP or some IP multicast address. I do not know what the "SOURCE" and "DESTINATION" IP address will be in that case (I think either FF:FF:FF:FF or something like that, or some specific multicast address, or there is no IP address since ARP is used). Now, that is something I have to read in the link-local IP RFC, which is in my bag for a few weeks now, but I haven't gotten to yet.

• • (*) ARP is used to match ethernet address to IP address on a link-local network. I think if host A needs to sent something to a certain IP address, it works like this: A broadcasts an ARP packet asking "hey, I need to send something to this-and-that IP address. who's listening to that one?" And the other hosts replies "I am! My MAC address is this-and-that". From then on, host A can use (ethernet) unicast rather then broadcast (on the ethernet level, that is). I'd say to Google on "ARP explained" or so, or look at http://searchsmb.techtarget.com/sDefinition/0,,sid44_gci213780,00.html∞ if you want to know details. Tanenbaums' Computer network book probably exaplains it too.

Test Machines

We simultaneous try to get it to work in Chicago and Amsterdam.

Amsterdam

Test machine is VanGogh8 (vangogh8.uva.netherlight.nl), and later Vangogh5-VanGogh8 will be used. Vangogh runs Red Hat.

Chicago

Primary test machine is prier (prier.evl.uic.edu) - 64 bit opteron machine with Suse 9.2. and FreeBSD 5.3
Second test machine is Itanic (itanic.evl.uic.edu) - 64 bit IA 64 - HPZX200 running Debian
We have 4 working LX e1000 cards and one card is currently installed on each. The other cards will be installed too. Prier will be connected directly to the Glimmergass in the near future. Root account will be created for Freek.

Trans-Atlantic Link

Freek has asked SURFnet for a trans-Atlantic 1 GE link between April 1st and April 22nd. This is probably available, but has not been confirmed yet. If it is OK, it will probably terminated on the Cisco 6509 in Amsterdam. It is unclear where it will terminate in Chicago.

Patent Issues

Venkat Vishwanath wrote:
Microsoft received a patent on what sounds like a ZeroConf implementation.
Sources: http://www.freepatentsonline.com/6101499.html∞ and http://yro.slashdot.org/yro/05/03/23/2311234.shtml?tid=155&tid=109∞

Comment by Freek Dijkstra:
This is really very old news, which was reported completely wrong by Slashdot (that's what's slashdot is for it seems). Also, Microsoft already granted royalty free license to anyone using it long ago. There is a statement somewhere on the IETF website.

Categories

CategoryProcedures
CategoryTechnologies
CategoryZeroconf