See also:

Phases

  1. use newer socket API without supporting IPv6 at all
  2. introduce ipaddr structure, which is capable of storing IPv6 address. (but no IPv6 support)
  3. Support IPv6
  4. (maybe) support dual stack (IPv4 and IPv6 on single daemon, single socket)

Phase 1

step 0: thursday, april 29

  1. list all functions that need to be ipv6 aware. gethostbyname, gethostbyaddr, etc.

  2. create wrappers for each of the above functions if they do not exist.

  3. find all call sites for above functions and use wrapper instead

step 1: friday, april 30

  1. reimplement gethostbyname (and others) to invoke getaddrinfo() instead, and copy resulting ipv4 address into hostent structure, and return. this does not change the signature of condor_gethostbyname().

step 2: monday, may 3

  1. deal with inet_ntoa and family?

Phase 2

step 3: monday, may 10 (should be step 1 of Phase 2)

  1. introduce ipaddr class (which encapsulates both v4 and v6 addresses) and change function signatures where needed. update call sites.

step 4: wednesday, may 12 (step 2 of Phase 2)

  1. introduce condor_hostent (might actually be equivalent to addrinfo), change function signatures, update call sites. hostent was static, so also add calls to free() for the new condor_hostent structure.

everything to here done by may 14th.

step 5: (next semester)

  1. actually populate the condor_hostent and ipaddr classes with ipv6 data. watch what breaks, come up with a plan. ipverify() and many other places in HTCondor which assume 4-byte ip address or 21-byte address strings will need to be updated.

Complications

There's tricky thing on Phase 1. We decided not to remove struct hostent which is also obsolete. FYI, struct hostent is returned by gethostbyname() and is used for DNS lookup.

The newer API for gethostbyname() is getnameinfo(). Indeed, getnameinfo() does not return struct hostent. Thus, I wrote a wrapper function that returns struct hostent using getnameinfo().

The problem is that getnameinfo() does not return exact same information as gethostbyname() returns. Although getnameinfo() is replacement for gethostbyname(), they behave differently! Alternate hostname (hostname alias) could be different. I will send you the code that shows different behavior of gehostbyname() and getnameinfo().

I am not sure if it would break the compatibility. We may need to discuss how we can treat semantic difference of gethostbyname() and getnameinfo().