Thus, IPv6 mode is harmless in any case. (in theory)
+{section: IPv6 link-local address}
+
+IPv6 link-local address is currently desperately needed as CS dept does not have unicast IPv6 address.
+
+The link-local address is automatically assigned IP address when there is no valid address on the network interface.
+
+One of the interesting thing about the link-local address is that the address contains the interface name. For example, fe80::862b:2bff:fe98:65f2%eth0. The interface name is required because given address is only valid in that interface.
+
+In Condor IPv6 testing, I'd like to use link-local IPv6 address. However, one caveat is that the interface name is different from system to system. Thus, we cannot use the link-local address with the interface name as identifying machines.
+
+Instead, what I am gonna do is that each Condor system who wants to use the link-local address has to specify the network interface of use. In condor_config, NETWORK_INTERFACE is required.
+
+Each link-local address (which can be identifiable by looking at the address) will be bound to pre-configured NETWORK INTERFACE.
+
+{section: network_adapter.* and IPv6}
+
+Current method of getting network adapter is totally incompatible with IPv6 address. Current Condor uses ioctl() with SIOCGIFCONF that only returns IPv4 addresses.
+
+getifaddrs() is introduced to solve these problems. One caveat of getifaddrs() is that it does not tell you about the network interface id.
+
+We need to cross-match the result of getifaddrs() and ioctl(,SIOCGIFCONF,).
+
{section: ckpt server}
cpkt server has C functions that make it hard to convert. I'm relying on class condor_sockaddr which is c++ class. Investigate C function is really necessary.
