HTCondorWiki: Ipv Six Work Note

Page History

What should be changed?

All the deprecated BSD socket functions. These are complete list. (from Userlevel IPv6 Programming Introduction)


numbers in right denotes lines of code that has the keyword.

struct sockaddr_in : 237
gethostbyname      : 165
gethostbyname2     : 0
getservbyname      : 5
gethostbyaddr      : 23
getservbyport      : 0
inet_addr          : 13
inet_aton          : 7
inet_nsap_addr     : 0
inet_ntoa          : 114
inet_nsap_ntoa     : 0
inet_makeaddr      : 0
inet_netof         : 0
inet_network       : 0
inet_neta          : 0
inet_net_netop     : 0
inet_net_pton      : 0
rcmd               : 10
rexec              : 2
rrsevport          : 0

total 576 lines of code *must* be changed.

IP address is no longer fixed 4 bytes nor fixed 16 bytes. It can be both of them. So, every storage class should be changed. For some of source codes that use 'int' as storage for IP address, this is most troublesome because it could be hidden to simple text search.

Reading and parsing IP address from config file should be changed as well. If an existing code base entirely relied on BSD socket interface such as inet_aton or inet_addr, it would be easier. However, if the code has proprietary parsing/converting functions, every incident should be found and changed.

Zach mentioned that security and authentication code mangled with IPv4.

IPv6 address string is far longer than IPv4 address. IPv6 address [0001:0002:0003:0004:0005:0006:0007:0008], length is 41. IPv4 address 101.202.103.203, length is 15. About 3 times longer.

Printing IP address to log file should be considered since existing layout may not work well.

Current Condor Code Base

As noted earlier, Condor source has 576 lines that uses obsolete BSD functions.

What makes problem complicated is that unsigned long is used to hold IP address. There are many places to change. For example, in sock.h,

unsigned int Sock::get_ip_int()
unsigned int Sock::peer_ip_int()

It uses 'unsigned int' to pass IP address.

class Sock already has abstraction of BSD socket interface. But, IP address escapes from this class by returning it as an 4 byte int and sockaddr_in. It is required to check whether there are codes that directly calls BSD socket interface.

The method of Attack

Having some network abstraction classes, single IP address class that deals both IPv4 and IPv6. So, nobody uses sockaddr, sockaddr_in, or plain int to represent IP address.

Here is Boost IP address class. In that class, they hold both IPv4 address and IPv6 address. But I think we only need one 16 byte array instead of having both. Also, we may not need to have ipv4/v6 flag because there is IPv4 address mapping in IPv6. [Zach commented that although we do not need separate storage for each IPv4 and IPv6 address, we still need a type because when we tries to connect to other machines, we do not know whether it should be done through IPv4 network or IPv6 network]

Change every IP address storage to that IP address class.

The class itself is convertible to sockaddr_in or sockaddr_in6. However, byte-level compatibility may not be required.

It is not decided whether to have host byte order or network byte order. sockaddr_in always have network byte order in it.

Todo

Manageable daily work-list.

investigate security and authentication code that deals IPv4 address directly. IP verifier?
investigate every source code where calls obsolete BSD socket interface.
make a git branch
remove every obsolete interface.
find places where use 'int' as IP address storage. mark and count them.
make unified address class
change every incidents where use sockaddr,sockaddr_in, and int.

Done

investigate ipv6 address handling in C++ Boost library

Note

In a server, there are two choices with dealing IPv4 and IPv6 co-existence.
1. We may create only one IPv6 socket. Then, OS will fake a server program with IPv6-IPv4 mapped region. ffff::1.2.3.4 is really IPv4 host and came through IPv4 router and everything.
2. We may create two sockets, IPv4 and IPv6. Call non-blocking accept to both of them. And poll() or select() or kqueue() on both sockets. In current Linux implementation, I think we do not need this kind of complexity. Linux kernels deal smoothly with faked IPv6 address.
internet.h seems to have a lot of IPv6 incompatible functions.
why do you call <a.b.c.d:pppp> as sinful string? what does it mean 'sinful'?

This is Condor specific term. We need to extend definition to include IPv6 address. For example, <[a:b:c:d:e:f:g:h]:pppp> would work.

do we really need unified ip address class? IPv6 address space contains IPv4 and there is 1-to-1 mapping.

Current answer is no. But, we may need a 'type' flag.

Ipv Six Work Note